DLP浅谈(续) – 网络安全设备的实现

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




翻了几家公司的手册,都是英文数百页,样本并不全面。

1.Web FW类

1.1Barracuda (梭子鱼)

“All server responses are deep inspected for leakage of sensitive information like credit card data and social security numbers. Users can also specify custom patterns for data leak prevention. ”

以pattern match的方式识别信用卡号以及社会安全号(老美的东西,大体类比身份证号)。

例如,对于Visa信用卡的正则表达式为:4[[:digit:]]{12}|4[[:digit:]]{15}。

参照“Barracuda Web Application Firewall Administrator’s Guide Version 7.3”。

1.2 Cisco ACE

image

基本类似梭子鱼,上图是replace的action,对于泄露信息替换xxxx一下。

参照“Cisco ACE Web Application Firewall User Guide Software Version 6.0”

1.3 Citrix

image

类似上面两产品,上图是其signature库中的信用卡模式一瞥。

参照“Citrix Application Firewall Guide Release 8.1”。

从样本来看,WEB FW中的DLP实现相当之弱智,但也无可厚非,WAF地处咽喉要道,容易堵车,权衡利弊,情非得已。

2.NGFW类 – PAN

先看看他是怎么吹的:

image

如果仅仅和前面几款WAF差不多,真的没有什么值得夸耀的。不过PAN的产品实现确有亮点。

首先就是结构文件的解码功能:

image

如上可见,PAN支持docx,gzip,ppt等文件分析。看似是功能的小进步,对于架构影响甚大。至少需要对于整个文件进行缓存了。已经同UTM的需求类似了。

其次,PAN支持文件类型的识别,足以应付改改文件名就想蒙混过关的毛贼了。

其原文如下:“File blocking by type: Controls the flow of a wide range of file types by looking deep within the payload to identify the file type (as opposed to looking only at the file extension). ”

这个小进步也需要系统引入新的一个文件类型模式库。

3.UTM类 – FortiGate

DLP对于fortinet,应该是UTM的feature。第一段描述就震了我一下:

image

对于无法确定字符集的情况,fotinet会尝试所5种编码格式来解码并且逐一匹配。设计者扣得可是够细致的。无论运行效率如何,先给Forinet一朵小红花。

对于DLP支持的协议和文件类别, Fortinet也给出了清晰列举:

支持下述的protocols:

Email (IMAP, POP3, SMTP)

IM (AIM, ICQ, MSN, Yahoo!)

Session control content (SIP, SAMPLE, SCCP)

FTP, HTTP

支持SSL内容扫描:(肯定是终结在本盒子上的)

HTTPS, IMAPS, POP3S, SMTPS

支持下述文件类型:

image

似乎没有看到文件类型识别的支持。解码后内容的识别还是老一套信用卡号和社会安全号。

综上所述,根据样本实现,网络设备中的DLP实现目前还属于弱智时代。

(没有打分)

雁过留声

“DLP浅谈(续) – 网络安全设备的实现”有9个回复

  1. caijimin 于 2010-01-07 6:50 下午

    我想可大体分为2个步骤,1是正规化(解码),2是解码后的内容识别,第1步包括 文件类型的识别、解密、内容的提取、转换为统一的编码(UTF-8)等等,要做好每一部分都有很多细节要考虑。

    另外我对SSL扫描有点疑问(包括以前看到Hillstone的防火墙可以解密https的内容)。是要有server的private key才行,还是进行 Man-in-the-Middle攻击,浏览器不会给出警告吗?

  2. 杰克 于 2010-01-07 7:15 下午

    Hillstone的防火墙可以解密https的内容

    很怀疑这个功能的真实性。有背景的同学出来8一下。

  3. appleleaf 于 2010-01-07 7:25 下午

    肯定是“Man-in-the-Middle”,暴力破解加密数据是不可能的。

    但并不是攻击。如果是攻击则SSL fix这个bug之后这个功能就不work了,没有人敢提供这样的feature。

    我估计是用户端要配置一些东西,信任Hillstone的证书,实现Man in Middle。也请用过的达人给个说法。

  4. 杰克 于 2010-01-07 9:44 下午

    信任Hillstone的证书? 如果这样的话,跟SSL代理有啥区别?
    正常的数据不需要解密,异常的数据不会让它解密。

  5. appleleaf 于 2010-01-07 9:51 下午

    我愚蠢的小脑瓜也只能逻辑推理出这种方式了。
    估计Hillstone的人正在耻笑我等。

    另问,“异常的数据不会让它解密”是什么意思?都要解密啊,作为代理可以看到的东东同sever是一样的啊。

  6. caijimin 于 2010-01-07 10:25 下午

    还看到比蒙科技(http://www.bmst.net/cn/tech.htm)的资料,
    * 业界唯一的远程桌面操作(RDP)会话的透明支持与完全记录及回放
    * 业界唯一的SSH、SCP等多种协议的透明支持与完全记录及回放

  7. 老韩 于 2010-01-07 10:29 下午

    从实现机制上来说,网关产品整合DLP难度很大,而且不会很全面。DLP是相对独立的一套体系,完整实现必须是方案级的。
    另外从不同用户对DLP的需求来看,真重视这块的(金融、政府、……),短时期内也绝不会选择网关整合方案。
    必须研究不同产品形态目标客户群对DLP的需求模型,PAN为代表的网关型发展路线走得没错。另外,SWG产品形态更容易整合DLP,建议关注Websense即将发布的Websense Web Security Gateway 7.5,将整合旗下DLP解决方案中部分模块。Bluecoat、麦咖啡、RiverBed同样有类似产品(计划)。

  8. sbilly 于 2010-01-07 11:13 下午

    自签名的证书都很容易被中间人,没有客户端认证的证书也是可以中间人的

  9. appleleaf 于 2010-01-08 12:56 上午

    多谢老韩。
    老韩见多识广,有信息一定要披露啊。