2024-02-14 09:52:00
年底整理资料，发现很多收藏的文档都没有打开看过，虽然过去蛮久了，但我觉得还是值得一读，一方面整理过滤出自己关注的内容，另一方面给自己的收藏做一个交代。说起读材料还是挺喜欢做的一件事，小时候会去读字典，那时候每一页会有一个故事，就这样不知不觉也顺带把字典看了一遍；乌云挂了之后，也想把漏洞读一遍，就像乌云疯狗所说：“阅尽天下漏洞，心中自然无码”，每个事件型的漏洞都代表了一个场景、一个姿势，以及下面的评论也都蛮有意思，只可惜时间线拉的有点长，最终并没有坚持下来，看了几个类型漏洞后就结束了。因此这次读PDF一来趁热情高涨，速战速决，二来形成一个流程化，尽可能可持续，同时也把过程中比较有意思的tricks记录下。
梳理了大约100G左右材料，还剩23G大杂烩过程中再慢慢整理了，这次精力主要在安全会议上，虽然说是读，但最多只牵强算是泛读，感兴趣的多看一会，可能用到的标记下，不感兴趣的直接略过。
关于自动化流程，除了常规TODO外，很推荐DEVONthink 3工具，做本地文档检索、监控、管理都非常适合，比如你关注某个领域，那么构造好关键词，即可实现本地持续监控，一劳永逸。
在浏览及梳理了近几十个G会议材料后，最直接有这几个感受：
2023-11-26 18:14:00
最近接触到MasterGo这款在线设计工具，发现挺不错的。一方面类似Sketch，学习成本比较低，另一方面资源比较多，组件套用、协同配合上也比较方便，因此学习一番，便于更高效运用这款工具。
参考团队资产管理方式，团队项目可以按照业务产线区分，文件可以按照功能模块或产品版本号分组，便于内容直观查看与管理。同时可以对每个文件设置封面，以及对文件内容以层级树方式管理版本，便于内容查看与方案复用。
2022-08-25 19:46:00
最近分析一批恶意样本数据，考虑到数据量以及开箱即用的图表分析，所以决定把数据放在ES上，用Kibana来分析。因为是自己在用，所以只要能快速跑起来，撑的住小几T数据的秒级查询、分析即可。综合速度、便捷性等方面，工作流大致如下：写streaming_bulk，存es、分词ik_max_word、检索kibana、迁移elasticdump/logstash。这个过程没啥高深技术卷入其中，更多只是从众多功能项中，筛选出满足需求，适合单机快速运转的小方案，记上一笔，方便日后用到节省时间。
⚠️ 由于软硬件选用、性能调优出发点是个人单机，线上环境可能并不适合。
基本环境部署没什么好说的，跟着网上步骤走一遍即可，软件用的是ELK 7.10.1，主环境安装在windows上，同时为了方便调试本地也拉了个docker测试环境；硬件上4核CPU（性能高建议8核~16核）、HDD+SSD、24G内存（性能高建议64G）。推荐两个部署源：
https://github.com/deviantony/docker-elk
https://mirrors.huaweicloud.com/elasticsearch/根据官方给出的建议，JVM配置为机器一半的内存，不超过32G，且Xms和Xmx值尽可能保持一致。
config/jvm.options
-Xms12g
-Xmx12g# 关闭交换分区，防止内存置换降低性能。 将/etc/fstab 文件中包含swap的行注释掉
sed -i '/swap/s/^/#/' /etc/fstab
swapoff -a
# 单用户可以打开的最大文件数量，可以设置为官方推荐的65536或更大些
echo "* - nofile 655360" >> /etc/security/limits.conf
# 单用户线程数调大
echo "* - nproc 131072" >> /etc/security/limits.conf
# 单进程可以使用的最大map内存区域数量
echo "vm.max_map_count = 655360" >> /etc/sysctl.conf
# 修改立即生效
sysctl -p索引优化
Elasticsearch近实时的本质是：最快1s写入的数据可以被查询到。 如果refresh_interval设置为1s，势必会产生大量的segment，检索性能会受到影响。 所以非实时的场景可以调大，设置为30s，甚至-1。即：在写入过程中修改刷新时间和副本数来提升写入的速度，等到写入结束后再修改回去。
GET /ASM_Assets/_settings
PUT /ASM_Assets/_settings
{
"index" : {
"refresh_interval" : "-1",
"number_of_replicas": 0
}
}同时用buk或streaming_bulk批量写的方式，目前主要用的streaming_bulk基本能够达到数据录入的时间、文档的要求。根据不同场景、侧重需求情况，可以参考py-elasticsearch的stream_bulk、parallel_bulk、bulk性能对比作者给出的测试结果选择适合的批量写入的方式。
PUT index_two
{
"mappings":
{
"properties":
{
"name":
{
"type": "keyword"
}
}
},
"settings":
{
"index":
{
"number_of_shards": 1,
"number_of_replicas": 2
}
}
}# 删除索引数据，保留结构
POST index_one/_delete_by_query
{
"query": {
"match_all": {
}
}
}
# 删除索引
DELETE /index_one,index_two# 查看A开头索引
GET /_cat/indices/A*?v
# 查看索引状态
GET /_cat/indices/ASM_ips
# 查看索引设置
GET /ASM_ips/_settings
# 查看索引mapping
GET /ASM_ips/_mapping# 查询response字段中包含200的文档对象
response:200
# 模糊查询response字段中包含200的文档对象
response:*200或者response:200*
# 不区分大小精确查询某字符串
message:"hello world yes"
# 不区分大小无序查询包含其中某个字符串
message:hello world
# 关系查询
(name:jane and addr:beijing) or job:teacher
response:(200 or 404)
not response:200
response:(200 and not yes)
@timestamp < "2021"
# 查询所有包含response字段的文档对象。
response:*
# 查询搜索列machine开头，字段内容包含hello的数据记录
machine*:hello# 返回结果中需要有http_host字段
_exists_:http_host
# 不能含有http_host字段
_missing_:http_host
# 通配符模糊匹配
kiba?a, el*search
# 范围匹配
sip:["172.24.20.110" TO "172.24.20.140"]
date:{"now-6h" TO "now"}#!/usr/bin/env python
# -*- coding: utf-8 -*-
# @Author : Coco413
# @Summary : Batch import source data to elasticsearch
# @Usage : python3 import_es.py
try:
import simplejson as json
except ImportError:
import json
from elasticsearch import Elasticsearch, helpers
from datetime import datetime
import csv
ES = Elasticsearch(
hosts=[{"host": "127.0.0.1", "port": "9200"}],
http_auth=("xxx", "xxxx"),
retry_on_timeout=True,
max_retries=10)
def importdata_TXT(filename="ips.txt", index_name="xxx", count=0, all="N/A"):
with open(filename, "r", encoding="utf8") as fr:
for line in fr:
count += 1
pass # <根据自身需求，处理文本结构至base>
temp = {
"_op_type": 'index',
"_index": index_name,
"_source": base
}
print("[{}/{}]{}".format(count, all, temp))
yield temp
def importdata_CSV(filename="domains.csv", index_name="xxx", count=0, all="215612"):
with open(filename, "r", encoding="utf8") as fr:
for row in csv.DictReader(fr):
count+=1
pass # <根据自身需求，处理文本结构至base>
temp = {
"_op_type": 'index',
"_index": index_name,
"_source": base
}
print("[{}/{}]{}".format(count, all, temp))
yield temp
def importdata_JSON(filename="ioc.json", index_name="xxx", count=0, all="N/A"):
with open(filename, "r", encoding='utf-8') as fr:
for line in fp:
count+=1
pass # <根据自身需求，处理文本结构至base>
temp = {
"_op_type": 'index',
"_index": index_name,
"_source": base
}
print("[{}/{}]{}".format(count, all, temp))
yield temp
for ok, response in helpers.streaming_bulk(client=ES, max_retries=5, chunk_size=5000, actions=importdata_TXT()):
if not ok:
print(response)elasticdump --input=http://xxx:[email protected]:9200/ASM_Assets --output=./my_index_mapping.json --type=mapping
elasticdump --input=http://xxx:[email protected]:9200/ASM_Assets --output=./my_index_data.json --timeout=10 --sizeFile=1gb --type=data
elasticdump --input=http://xxx:[email protected]:9200/ASM_Assets --output=$ | gzip > ./my_index_data.json.gz --timeout=10 --type=data
elasticdump --input=./my_index_data.json.gz --output=http://xxx:[email protected]:9200/ASM_Assets --type=datainput {
elasticsearch {
hosts => ["127.0.0.1:9200"]
user => "xxxx"
password => "xxx"
index => "*"
# query => '{ "query": { "query_string": { "query": "*" } } }'
docinfo => true
size => 5000
# schedule => "0 * * * *"
}
}
output {
file {
path => "./1.json"
# path => "./test-%{+YYYY-MM-dd HH:mm:ss}.txt"
}
stdout {
codec => json_lines #console输出， 可以注释stdout部分
}
}Elastic Stack 实战手册-藏经阁-阿里云开发者社区
2022-05-22 23:43:00
在这个信息过载的时代，我既是一名知识汲取的受益者，同时也是知识反噬的焦虑者。作为一名信息安全从业者，需要具有大量的阅读和碎片知识的积累，来帮助自己完善知识体系、提升对安全认知的见解。在这个成长的过程中，同时也会伴随着反噬、焦虑，比如自己的精力和意志时常产生矛盾互相打架，收藏的paper、想做的 ideas 积压的越来越多，生活和技术分配的时间失去了平衡等等，导致陷入在信息洪流和知识焦虑中难以自拔。
之前有一段时间，我大部分信息来源渠道，甚至娱乐相关的APP几乎都被技术相关话题所淹没，我被自己困在了自己勾勒的信息茧房中，抛开技术仿佛就是一只小白懵懵糟糟，唯一换来的可能就是朋友的调侃只要发给我的paper，好像都被我提前看过了，而得到的那一丝丝“奇怪的自豪感”。
无休止的奔跑、野蛮的阅读、仅靠意志力和信息洪流正面刚，诚然量变会产生质变能够带来不少帮助，并且这种“野蛮”、“痛”的过程我一直也认为是很有必要的，只是在经历过后，需要能够把自己拽出来，进而更好更有效率的学习沉淀。当下不敢说摆脱了知识焦虑的困扰，自己偶尔也还是会出现焦虑，“禁闭”个一两天和自己作对下，但相比之前好了很多，同时在这个过程中也有了一些自己的感悟，拿出来和大家一起交流，共同捍卫我们的信息流。
无休止的奔跑，会让信息积压的更多，既给自己增添焦虑感，也不利于内容吸收。因此需要阶段性的按下暂停键，回顾整理沉淀，降低知识的焦虑感。如何降低知识焦虑感？我有如下这几个小 tips 和大家分享：
之前零碎信息管理上有个明显的问题，就是入口过多，多个信息渠道收藏、转发，甚至有时候图一时方便直接截图或粘贴备忘录，导致回顾整理起来非常耗费精力。因此开始缩减入口，减少在不同渠道平台上使用收藏功能，把过滤后的信息入口，统一都放入在 Cubox 进行回顾。
之前会有因为担心“单节点故障”漏掉了某些信息内容，所以在不同信息渠道上交叉重复订阅相同的信息源，导致阅读时候产生不少重复的内容。但其实这样意义并不大，更多只是增重了重复过滤的精力，并且有了这种“冗余机制”，在浏览的时候也会不自觉产生出一定惰性和依赖性，阅读也不够有耐心。
所以重复交叉订阅没有太多必要，就像个人知识管理体系系列 - 捕蛇者说里所说：
当第一次遇到一篇文章的时候可以不用打开，当第二次又出现在你眼前的时候再去阅读，真正重要的东西是会出现第二遍的。
乍一听鸡汤味十足，但细细想来还是挺有道理，即使信息源只保留一个，重要的内容比如某个漏洞爆发还是自然而然可以通过朋友圈、工作群等方式获取到，及时性固然重要，但重复筛选所耗费的精力也应当被呵护。因此我逐渐清理了一些没必要的群、公共号以及其他重复信息源，仅保留方便日常和较为关注的信息源做交叉订阅，把生活和技术的信息界限感划分的更清晰些，既不影响信息获取，同时也释放了一定精力跳出来，回归到生活。
之前有段时间，总想着把积压的内容一个个 check 掉，但却不断陷入在收藏-消化、再收藏-再消化的恶性循环中，归根到源头还是不够聚焦、导致信息过滤失败，处理太多“有益但无意义”的信息流，分散了精力。所以在过滤信息的时候应当更加谨慎一些，评估自己是否能够做到稍后阅读，从而适当舍弃掉一些信息流，聚焦在自己的分支上，避免被大量都是有益的信息所干扰到。比如收藏某篇文章的时候，可以问问自己是因为确实需要还是惯性收藏？最近是否有时间去研究？是否能解决当下某个问题？如果不收藏今后找不到吗？等等问题，然后给自己一个过滤信息的答案。
如何放平心态，去看待知识焦虑，我的理解就是把它当做一个件在正常不过的事情，因为这种焦虑不仅仅我们会产生，很多其他人也都有遇到过，它只是这个信息时代的一个现象，而非问题，因此只要放平心态去接纳这种现象，找到适合自己的工作流就好，当工作学习的时候就进入这个框架好好工作，非工作的时候跳就出来好好享受生活。这里摘录了几条大佬们的语录：
Project Zero （Google P0安全团队 - Blog）
ringzero猪猪侠（ringzero的个人主页 - 微博）
不爱吃鱼的蓝鲸（也许生活本该碎片化：聊聊 flomo 这款工具如何改变我的生活 - 少数派）
通过这些语录不难看出，大家都面临过相类似的困扰，也都在不断探索寻找适合自己的信息相处方式，所以对于知识焦虑，要能从心态上平静的接纳这一现象。
知识管理工作流简单来说即：从信息输入到输出的过程中，挑选顺手的工具连贯而形成一套信息管理使用流程。知识管理这类工具有很多，比如Flomo、Zotero、Obsidian、Notion等都是很好的工具，是否适合自己，需要在尝试过程中发现问题解决问题。以下是我在这个过程中挑选的一些工具，并形成适合我自己的简易工作流。流程、工具选用因人而异，仅供参考：
在RSS订阅工具上我主要使用Inoreader，在订阅一些国外Feed上速度能够更快一些，不过由于 RSS 会存在一定信息延迟，所以部分源会配合上 Distill 添加页面监控提醒。在RSS内容筛选管理上我大致有如下这几个小习惯：
关注行业内一些综合订阅源更新动态，定期去重、合并、筛检做融合补充。目前主要关注zhengjim/Chinese-Security-RSS、r0eXpeR/Security_RSS、Han0nly/SecurityRSS、zer0yu/CyberSecurityRSS这几个仓库，如果也有类似需求的小伙伴，在处理opml文件时，注意这几个小tips：（1）同订阅源，不同协议，例如http://www.example.com/rss.xml 和 https://www.example.com/rss.xml（2）同订阅源，URL路径格式，例如http://www.example.com/rss.xml 和 http://www.example.com/rss.xml/ （3）同订阅源，多订阅地址，例如http://www.example.com/rss.xml 和 http://api.example.com/rss.xml （4）同订阅源，不同烧制方式，例如同一个站点可能会出现有的用Feed43、有的用RssHub烧制。
比较关注的、高质量订阅源独立在一个目录，便于忙的时候优先取舍浏览。
一些每天更新频繁的比如 HackerNews、Freebuf 或者本身就是聚合的站点比如unsafe、doonsec等独立出来，避免积压过多，影响其他源信息查看。
Github是我比较高频的信息获取渠道，由于之前顺手 Fork 积压了不少仓库，管理起来比较麻烦，并且事后也基本都没有再看过、查找也不方便，所以 GitHub 更多只是用来项目浏览和仓库更新提醒，不做收藏。遇到感兴趣的项目打标签放到 Cubox 或者直接整理到 DEVONthink Awesome-Security，方便需要的时候能快速找到某个项目或某类项目集。
对于闪现灵感、草稿随笔这类只言片语主要用备忘录、Procreate。备忘录记录会比较随意，放飞的写写画画，然后定期再去清理。
在文档阅读流程上，我主要采用 iCloud云盘 + DEVONthink方式，需要看哪些文件通过 iCloud 云盘同步，看完后再归档到本地目录，替换新的文件到云盘。交替同步一方面不会有太多的阅读压力，另一方面也避免大量文件同步耗时、占用空间。
在文档阅读设备上，习惯用iPad看文档，周末打着dota，嚼着脆司令，再来口冰阔乐，读秒时刷刷PDF，一大乐事。
在技术类文档管理上，习惯重标签轻分类，即所有的文档都放在一个目录下，通过命名方式 + 标签进行管理，同时用标签自带的颜色区分属性大类，如红队、蓝队。
信息筛选过滤后，交由 Cubox 标记分类，作为统一的信息中转入口，承载稍后阅读和整理归档的中抠作用。
由于 DEVONthink 自带的编辑器不好用，所以内容编辑使用 Typora 或者飞书在线文档代替。
SecNavi是我一个在持续更新的安全站点导航，主要是为了简化一部分浏览器书签、方便平时资料查找，发现不错的网站就补充添加进去。
DEVONthink总的来说是一款 ALL-IN-ONE 的信息管理工具，既可以 RSS 订阅、稍后阅读，也可以文件管理、全文检索等，同时也有比较方便的同步方案，基本贯穿了输入到输出整个工作流。
从内心来说我是希望有这么一款全方位覆盖工作流 ALL-IN-ONE 的工具，但深入使用下来并不适合我，在细节、方便程度、功能覆盖上等都不够顺畅。不过DEVONthink在文件管理上非常方便，并且其标签能够和 Finder 系统标签完全同步保持一致，因此我使用 DEVONthink 主要是用于管理输出的笔记、文档等，同步Finder&iCloud归档备份。
工作流除了对输入&输出管理外，日程安排也尤为重要，目前我主要使用 Things 3 来管理工作流任务、生活琐事、重要提醒等。
工作流除了软件外，硬件设备也必不可少，我日常主力MBP，闲暇外出iPad，配合飞书的在线文档 + iCloud云盘，能够方便流畅的内容编辑&文档阅读。
适合的工作流、良好的心态，能够帮助我们更从容的面对，每天扑面而来的信息流。除此之外，还应当不断提升独立思考、信息检索的能力，反哺工作流的输入与输出，进而去完善知识体系，让自己对事物的认知理解能更趋势于准确且全面。
以上就是我的知识管理方式，希望能给你带来一些帮助。
2022-03-06 18:28:00
看到一篇笔风挺意思的文章让安全团队快速倒闭的十条建议，模仿也写了几条关于安全产品的忠告建议，行之是否有效，也请自行甄别尝试，过程所产生的一切风险责任由践行者承担~~
1、不必重视安全产品运营，交由客户自由发挥
2、不必量化指标自证产品能力，看不见的价值无需呈现
3、无需在意产品使用“安全感”，尽管强迫用户适应你的想法
4、不必方法论定战略做规划，直接一把搜就开干
5、无需明确产品定位，尽量发散尽善尽美
6、不必深入了解安全，对着标书抄抄改改即可
7、不必落地解决方案、场景流程，只要功能具备，其他依赖使用者水平就好
8、不必提高核心竞争力，产品同质化是常态
9、不必倾听一线声音，他们使用很流畅
10、不必客观展示全貌数据，片面断节数据不影响分析
11、不必透明指标定义、研判机制，懂的人自然懂
12、功能流程不必闭环，细节交互逻辑无需在意
13、尽管把故障运维压力交由研发，不必为其考虑自动化
14、不必管控产品演示质量，无需考虑演示标准化
15、不必考虑安全产品质量，安全产品自然安全
2022-01-18 20:26:00
安全网闸（SGAP）全称安全隔离网闸，又称“安全隔离与信息交换”，是一种由带有多种控制功能专用硬件在电路上切断网络之间的链路层连接，用以实现不同安全级别网络之间的安全隔离，并提供可管可控的数据交换软硬件系统，从而抵御各种已知和未知的攻击，提高内网的安全强度。
网闸最早出现在美国、以色列等国军方，它相当于一个高速开关在内外网之间来回切换，同一时刻内外网间没有连接，处于物理隔离状态，在隔离内外网业务连接的前提下，实现安全的数据交换。
网闸通常使用 “2+1” 架构，即内网处理单元、外网处理单元和DTP物理隔离通道，确保内外网之间没有TCP/IP连接，通过协议剥离、信息摆渡、安全检查、病毒扫描等方式确保内外网在隔离的情况下进行信息交互。
多套网络技术
隔离卡技术
传统网闸技术
在安全隔离方面也曾出现过其它多种技术方案，比如在隔离卡建立起的两套系统间设立数据缓冲区，进行分时连接和切换，还有就是基于电子开关的方式进行隔离系统两端网络通断的控制。传统网闸技术在一定程度上能够解决信息交换和隔离的需求，但在安全功能实现和系统性能上仍不能完全满足安全建设的要求。
SGAP技术的基本原理：首先切断网络之间的TCP/IP等通用协议连接，将数据包进行分解或重组为静态数据，然后对静态数据进行安全审查，包括网络协议检查、代码扫描等，确认后的安全数据流入内部单元，内部用户通过身份认证机制获取所需数据。
安全网闸在功能上基本包含：安全隔离、内核防护、协议转换、病毒查杀、访问控制、安全审计、身份认证等。
SGAP在系统单元上一般由三部分构成：内网处理单元、外网处理单元和专用隔离硬件交换单元。三个单元都要求其软件的操作系统是安全的，也就是采用非通用的操作系统，或改造后的专用操作系统。一般为Unix BSD或Linux的变种版本，或者其他是嵌入式操作系统VxWorks等，但都要对底层不需要的协议、服务删除，使用的协议优化改造，增加安全特性，同时提高效率。
系统中的内网处理单元连接内部网，外网处理单元连接外部网，两模块间没有直接的物理连接，形成物理隔断，从而保证可信网和非可信网之间没有数据包的交换，没有网络连接的建立。专用隔离硬件交换单元在任一时刻点仅连接内网处理单元或外网处理单元，与两者间的连接受硬件电路控制高速切换，其交换单元的这种交换并不是数据包的转发，而是应用层数据的静态读写操作，因此可信网的用户可以通过安全隔离与信息交换系统放心的访问非可信网的资源，而不必担心可信网的安全受到影响。单元模块具体负责处理的内容如下：
隔离与交换控制单元
是网闸隔离控制的摆渡控制，控制交换通道的开启与关闭。控制单元中包含一个数据交换区，就是数据交换中的摆渡船。对交换通道的控制的方式目前有两种技术，摆渡开关与通道控制。摆渡开关是电子倒换开关，让数据交换区与内外网在任意时刻的不同时连接，形成空间间隔GAP，实现物理隔离。通道方式是在内外网之间改变通讯模式，中断了内外网的直接连接，采用私密的通讯手段形成内外网的物理隔离。该单元中有一个数据交换区，作为交换数据的中转。
这种独特设计保证了专用隔离硬件交换单元在任一时刻仅连通内部网或者外部网，既满足了内部网与外部网网络物理隔离的要求，又能实现数据的动态交换。同时SGAP软件系统会内置一些协议分析引擎、安全检测、病毒查杀等多种安全检测机制，根据用户需求配置不同的安全策略等。
信息通过网闸传递需经过多个安全模块的检查，以验证被交换信息的合法性。当访问请求到达内外网主机模块时，首先由网闸实现 TCP 连接的终结，确保 TCP/IP 协议不会直接或通过代理方式穿透网闸；然后内外网主机模块会依据安全策略对访问请求进行预处理，判断是否符合访问控制策略，并依据 RFC 或定制策略对数据包进行应用层协议检查和内容过滤，检验其有效载荷的合法性和安全性。一旦数据包通过了安全检查，内外网主机模块会对数据包进行格式化，将每个合法数据包的传输信息和传输数据分别转换成专有格式数据，存放在缓冲区等待被隔离交换模块处理。这种“静态”的数据形态不可执行，不依赖于任何通用协议，只能被网闸的内部处理机制识别及处理，因此可避免遭受利用各种已知或未知网络层漏洞的威胁。
隔离交换单元模块采用固化控制逻辑，与内外网模块间只存在内存缓冲区的读写操作，没有任何网络协议和数据包的转发。隔离交换子系统采用互斥机制，在读写一端主机模块的数据前先中止对另一端的操作，确保隔离交换系统不会同时对内外网主机模块的数据进行处理，以保证在任意时刻可信网与非可信网间不存在链路层通路，实现网络的安全隔离。 当内外网主机模块通过隔离交换模块接收到来自另一端的格式化数据，可根据本端的安全策略进行进一步的应用层安全检查。经检验合格，则进行逆向转换，将格式化数据转换成符合 RFC 标准的 TCP/IP 数据包，将数据包发送到目的计算机，完成数据的安全交换。
安全隔离网闸通常布置在两个安全级别不同的两个网络之间，如信任网络和非信任网络，管理员可以从信任网络一方对安全隔离网闸进行管理。
实现隔离不难，难在隔离后的数据交换，因此需要一套解决方案来实现既要物理隔离来保护数据安全，又可以兼顾数据交换，同时又不像隔离卡那样复杂麻烦。
传统的U盘、FTP来实现数据交换既不方便，也缺少过程审计，在发生数据泄露时候难以溯源，需要一套解决方案来实现做到隔离数据交换可管可控。
无法确保TCP/IP协议、防火墙本身的安全，因此需要一套解决方案加强隔离程度，应对未知、APT等攻击。
通常见到的木马大部分是基于TCP的，木马的客户端和服务器端需要建立连接，而安全隔离网闸由于使用了自定义的私有协议（不同于通用协议）。使得支持传统网络结构的所有协议均失效，从原理实现上就切断所有的TCP连接，包括UDP、ICMP等其他各种协议，使各种木马无法通过安全隔离网闸进行通讯，从而可以防止未知和已知的木马攻击。并且从目前的安全技术，无论防火墙、UTM等防护系统都不能保证攻击的一定阻断，入侵检测等监控系统也不能保证入侵行为完全捕获，所以最安全的方式就是物理的分开。
最高人民法院《安全隔离与信息交换平台建设要求》FYB/T 53001—2020
业安全网闸主要服务于电力、工业、医院、银行等一些对数据安全合规要求较高的单位。
根据IDC 2020年发布的《中国安全隔离与信息交换市场份额，2019：各方需求驱动，市场发展长期向好》研究报告，安全网闸市场规模达到1.05亿美元，较2018年同比增长20.5%，启明和奇安信市场份额占比前列。
网闸是一种隔离设备，是在保障安全的基础上实现通讯，而防火墙是保障通讯的基础上尽量做到安全。防火墙一般在进行IP包转发的同时，通过对IP包的处理，实现对TCP会话的控制，但是对应用数据的内容不进行检查。这种工作方式无法防止泄密，也无法防止病毒和黑客程序的攻击。
| 特性 | 安全网闸 | 防火墙 |
|---|---|---|
| 访问控制 | 基于物理隔离的白名单控制 | 基于连通网络的黑名单控制 |
| 硬件特点 | 多主机形成纵深防御，保证隔离效果 | 单主机多宿主 |
| 隔离类型 | 专用隔离硬件 | 无专用数据交换硬件 |
| 软件特点 | 不允许TCP会话 | 允许TCP会话 |
| 访问类型 | 不允许从外到内的访问 | 允许从外到内的访问 |
| 安全性特点 | 可以最大程度防止未知攻击 | 不能防止未知攻击 |
| 性能与应用特点 | 确保安全性能所需的管理和维护工作量小 | 需要7x24监控，确保安全性能 |
| 数据通过性 | 性能适中 | 高性能 |
| 隔离方式 | 需要与应用系统结合 | 对应用透明 |
安全隔离网闸与物理隔离卡最主要的区别是安全隔离网闸能够实现两个网络间的自动的安全适度的信息交换，而物理隔离卡只能提供一台计算机在两个网之间切换，并且需要手动操作，大部分的隔离卡还要求系统重新启动以便切换硬盘。
安全隔离网闸在网路间进行的安全适度的信息交换是在网络之间不存在链路层连接的情况下进行的。安全隔离网闸直接处理网络间的应用层数据，利用存储转发的方法进行应用数据的交换，在交换的同时，对应用数据进行的各种安全检查。路由器、交换机则保持链路层畅通，在链路层之上进行IP包等网络层数据的直接转发，没有考虑网络安全和数据安全的问题。
单向网闸在发现攻击后只会阻断外网的电路， 双向网闸在发现攻击后内外两边的电路都阻断。
防火墙是网络层边界检查工具，可以设置规则对内部网络进行安全防护，而IDS一般是对已知攻击行为进行检测，这两种产品的结合可以很好的保护用户的网络，但是从安全原理上来讲，无法对内部网络做更深入的安全防护。安全隔离网闸重点是保护内部网络，如果用户对内部网络的安全非常在意，那么防火墙和IDS再加上安全隔离网闸将会形成一个很好的防御体系。
并且即使网闸隔离效果很好，但是也不能取代防火墙，防火墙一般是基于网络层和传输层来进行访问控制。对于应用层控制不如网闸，而网闸对于应用层的控制更加细致化，更加深度化，但是对于网络层和传输层的控制则不如防火墙。防火墙的主要在作用就是安全域的划分（逻辑隔离）以及边界的访问控制而网闸则是在内外网之间进行数据的“摆渡”（物理隔离），相比之下，网闸的安全级别大于防火墙，但是处理报文的速率要低于防火墙。
支持交换哪些数据取决于安装了哪些应用模块及配置的访问策略，例如可以安装流量网页、邮件、访问数据库等应用。
大多安全隔离网闸支持百兆网络，如果要支持千、万兆网络，需要多台安全网闸做负载均衡。
安全网闸物理隔离相对来说已经比较安全了，但也会存在一些物理社工、配置策略不当等进行攻击，例如：从Fastjson绕WAF到打穿网闸、用激光入侵系统——腾讯玄武实验室 BadBarcode 研究的新进展。
不会，所有的请求都是由安全网闸主动发起，不接受外来请求，不提供任何系统服务；可以隔离两个网络相同网段。
