发信人: ccaatt()
整理人: ipaq(2001-05-28 13:59:40), 站内信件
|
对于SecuRemote连接FIREWALL-1的简单通道协议证明在bootstrapping inse
rtion attacks against
stateful inspection非常有用，这个协议(FWZ tunnelling via IP protocol 9
4)
pre-inspection最开始时解封装，在任何实际分析之前执行，被解封装的信息包
然后在通过inspection进程来提交。为了使用这个封装协议就没有必须去认证或
者加密信息包。此外，我们发现没有方法来关闭这项功能。
一个普通的FWZ封装IP是按照这样的方式的：原始源地址IP地址和协议作为一
个尾部trailer追加到信息包得到最后，并通过目标地址（防火墙的其中一接口）
和IP协议94来代替原始头。这个TRAILER的长度是5个字节数，在IP ID上通过使用
KEYD HASH并XOR使其杂乱。虽然我们不能恢复用在HASH中的KEY，但我们的工具通
过修改IP ID和XOR来欺骗一个静态HASH。
在这种方式下，FWZ封装可以用来通过防火墙发送目的信息包到本来不可路由
的地方，如一些DMZ或者INTRANET到INTERNET的信息包，或者那些被指定为多播地
址，或者信息包地址在NAT后面的或者是RFC1918所定义的一些非公开网络地址。
[如图：
--------------------------
| s-addr=131.159.1.1 | IP Header
| d-addr=194.221.6.19 |
--------------------------
| d-addr=10.0.0.1 | 封装信息
--------------------------
---------- ---- -------------
|10.x.x.x|--|防|<-------------------------- |131.159.1.1|
---------- |火| -------------
|墙|
----
信息包达到不可路由的地方
]
3.3 IP Spoofing Protection
--------------------------
FIREWALL-1中的IP伪造保护(IP spoofing protection)在每一个接口级别上
的网络模块都被配置。一般典型的配置如下面所示：
1，DMZ和INTRANET接口设置为“This Net” 或者可能是“This Net +”，限
制接口上的合法源IP地址直接到达网络或者路由到它的网络。
2，外部接口设置为“Others”，不允许信息包的地址是源自任何DMZ或者内
部网络的地址。
这样的配置看起来已经足够了，但它没有保护最重要的一个IP地址--防火墙
的外部接口，拒绝来自防火墙接口的伪造信息包一般在所有FIRWALL-1中都默认激
活的，除了version 4.1 Service Pack 1。同样默认规则还有一条允许ISAKMP信
息包，这个漏洞允许攻击者发送任何UDP数据帧到外部防火墙接口。
还有一个存在的问题就是默认规则允许ISAKMP信息包，这个漏洞允许攻击者
发送任何UDP数据包到外部防火墙接口。
另一个逃避IP伪造保护的可能就是使用目的地址是多播地址(224.0.0.1) ，
作为提交信息包到防火墙底下的操作系统，在我们的演示中，我们使用FWZ封装来
伪造一个从多播地址的信息包到我们的攻击主机，允许我们回应发送到多播地址
的信息包到我们攻击的主机，允许我们辉映一个以多播地址的信息包，通过防火
墙。这个攻击方法也可以使用广播地址来实现。
[我们在用图来解释下上面关于多播的情况：
1. -------------------------- 2.------------------------
| s-addr=224.0.0.1 | | s-addr=191.168.0.2 |
| d-addr=192.168.0.1 | | d-addr=192.168.0.1 |
-------------------------- ------------------------
| s-port=161 | | s-port=53 |
| d-port=53 | | d-port=161 |
-------------------------- ------------------------
| d-addr=192.168.0.2 | | d-addr=224.0.0.1 |
-------------------------- ------------------------
---- 1,伪造的 DNS 请求 -------------
|防|<-------------------------- |131.159.1.1|
|火| 2，防火墙通道 -------------
|墙|
----
4 Stateful Inspection
---------------------
Stateful inspection firewalls
4 Stateful Inspection
---------------------
[ 首先介绍下Firewall-1的Stateful Inspection 技术：
Stateful Inspection由CHECKPOINT 公司开发的技术，已经成为一种企业级
网络安全的解决方案。Stateful Inspection结合了所有传统防火墙技术所定义的
的安全需求，如一些包过滤和应用级网关，大家可以从下面的表中获得一些对比
信息：
Table1: 防火墙技术对比
防火墙能力 包过滤 应用级网关 Stateful Inspection
Communication Information 局部 局部 Yes
Communication-derived State No 局部 Yes
Application-derived State No Yes Yes
Information Manipulation 局部 Yes Yes
这里的防火墙能力指的是防火墙访问，分析，利用下面所示的能力：
Communication Information --指的是所有7层总信息包的信息
Communication-derived State--指的是源自以前的通信状态，如：一个FTP会话
出去的PORT命令可以被保存，因此进来的FTP数据连接可以被重新效验。
Application-derived State--指的源自其他应用程序的状态信息。如：一个以前
认证的用户只允许访问通过防火墙授权的服务。
Information Manipulation--指的处理任何信息包部分在数据上逻辑或者算术功
能的能力。
通过Stateful Inspection,为最佳的性能，信息包在网络层被截获，但再后
来的源自所有通信层的数据将被访问和分析来提高安全。它使用了一个叫INSPEC
T引擎来提高在网关上的安全措施。要更多的信息，请你去查看http://www.chec
kpoint.com的站点内容。
]
Stateful inspection firewalls在信息接替交换处理的时候加强了部分语义
机制，这个机制就是利用stateful inspection来完成的，但类似与被动网络监视
遇到的问题对于简单的插入，逃避检查等缺少完整的处理
FireWall-1s stateful inspection存在一些在检查中有关层冲突的问题，许
多攻击依靠一些对IP伪造保护不正确，或者与其他机制不平衡如FWZ封装插入等问
题而引起的。
4.1 FTP 数据连接(FTP Data Connections)
--------------------------------------
4.1.1 FTP PORT
--------------
Firewall-1的FTP处理尝试限制FTP数据连接到FTP客户目的地相关的连接控制
，防止经典的FTP BOUNCE攻击，在以前的FIREWALL-1版本中，这个能通过把PORT
命令分开成多个数据包而简单的旁路过，或者在版本3.0中可以通过”PoRT”这样
的拼法来旁路。即使现在FIREWALL-1对这样的欺骗使用限制一个信息包里只有一
个命令在信息包，也可以旁路，只是增加了一些难度而已。
其中最主要的思想是FIREWALL-1对IP地址的解析和一般服务器上的解析不一
样造成的，大家可以先看看下面图形的解释：
[ FTP “PORT” Parsing
----------------------------------------------------------------------
“PORT 172.16.0.258,P1,P1”
| |
解析 --------- ---------- 解析
172.16.0.2<-----|FTP机器| |过滤模块|------>172.16.1.2
--------- ----------
------------ ”PORT 172,16,1349632,2,p1,p2” -------------
|---->|172.16.0.2|<------------------------------|192.168.0.2|
data | ------------ 1349632 = -------------
connection| | 65536 * (192 - 172) + 256 * (168 - 16)
--------
应用于：Bounce 攻击
]
在我们的测试中，我们演示了使PORT命令解析中使用模糊化的处理来允许我
们通过防火墙这个限制.FIREWALL-1处理IP地址的规则是提取每个提供的IP地址的
八位字节作为一个长整数，并移动适当的位置处理成的IP方式，而一些FTP服务机
器如我们现在的目标机器Solaris 2.6是以系数为256来解释每一个八位组。
由如图上面所描写的。[具体本人不明白，请大家分析下，偶太苯了:(].
我们攻击的演示是针对ToolTalk RPC守护程序，我们通过FTP服务器上载了两
个文件到公共可写的目录，再通过精心编制的PORT命令指示FTP守护程序上载这些
文件到他们自己的ToolTalk守护端口，第一个文件是成功的杀死守护进程，第二
个文件是缓冲溢出，并产生SHELL。
我们也演示了使用FWZ封装来欺骗从我们受害机器到我们想要攻击的机器的一
个FTP控制连接信息包。这个信息包装载了一个PORT命令，可以让FIREWALL的FTP
stateful inspection 模块解释为合法的数据连接并通过防火墙。
[我们可以用图形来解释下：
--------------------------
| s-addr=172.160.2 | IP Header
| d-addr=192.168.0.1 |
--------------------------
| ”PORT | TCP header+payload
| 172,16,0,2,128,7 |
--------------------------
| d-addr=192.168.0.2 |封装信息
--------------------------
------------ ---- -------------
|172.16.0.2|--|防|<-------------------------- |192.168.0.2|
------------ |火| -------------
|墙|
----
192.168.0.1
4.1.2 FTP PASV
--------------
我们本来想演示这种攻击方法在我们的测试中，但这个漏洞已经由Mikael O
lsson发布到VULN-DEV了，所以没有独立的演示。
为了演示目的。我们使用了“ftp-ozone”工具通过直接连接在FTP服务器上
打开了 TOOLTALK守护程序，允许我们执行远程溢出。
[让我们来看下关于FTP PASV的图形解释：
--------- ”XXXXXXXXXXXXXX227(172.16.0.2.128.7)”
| | <------------------------------------ ---------
| | ------------------------- -- | |
--------- |500 Invalid command giv| | | |
172.16.0.2 ------------------------- | | |
|en: XXXXXXXXXXXXXX | |---------> | |
------------------------- | ---------
|227 (172,16,0,2,128,7) | | 192.168.0.2
------------------------- --
]
4.2 简单(Simplex TCP Connections)
---------------------------------
一个连接在FIREWALL-1连接表中限制数据流向其他的方向(从一端到另一端)
,第一个信息包包含TCP数据连接的连接方向，并且任何数据流向其他方向会引起
这个连接被连接表丢弃。在FIREWALL-1 4.1版本之前，检查这个数据只考虑一系
列信息帧中的第一个帧。因而，其可能通过发送一个TCP数据包在两个IP帧中来旁
路这个限制，第一个包含TCP头，第二个包含数据(这个是利用小数据帧攻击静态
信息包过滤的一个变种).
[下面用图形解释下上面的情况：
TCP Header + payload
---- --------------------
|过| <-------| | 被丢弃
----------------- |滤| --------------------
| 内部网络 | |模| ----- -------------
| INTRANET | |块| <-------| |--| | 被接收
----------------- | | ----- -------------
---- TCP TCP
Header payload
-------------------------------------------------->
建立连接
]
CHECKPOINT在以后的版本中修正了这个问题，但还是有另外的方法来旁路它
，要注意这里一个很重要的问题，是防火墙它不尝试拆卸这个连接，它只是简单
把它从连接表去掉这个表项和丢弃后续的信息包而已，因为FIREWALL不效验TCP序
列号号码，所以存在可能使用同样的源和目的参数来重新建立连接，允许重新发
送以前丢弃的TCP数据来为连接设置一个新的数据通道，使数据重新通过防火墙。
To exploit this, a small program running in an
infinite loop that constantly re-opens the FTP data connection can be
used to leak the return data through, although somewhat inefficiently.
[我们可以看看下面的图形解释：
| open one-way connection |
|<----------------------------------------- |
| datagram A |
-------- |<----------------------------------------- | --------
| | | datagram B ---------- | | |
| | |------------->|过滤模块| | | |
| | | ---------- | | |
-------- | open one-way connection | --------
172.16.0.2 |<----------------------------------------- | 192.168.0.2
| retransmission of B |
|-----------------------------------------> |
| ...... |
]
4.3 RSH stderr
--------------
RSH上一另一个协议允许插入攻击来允许重新建立连接并通过防火墙，类似于
前面的FTP PORT EXPLOIT利用。这需要合法的RSH客户端在防火墙里面，并且防火
墙要配置成允许RSH/REXEC stderr连接。
RSH stderr连接处理也表现出一个问题，存在在它的管理连接状态表中，虽
然我们没能够在4.1版本椭蟮陌姹纠贸稣飧雎┒矗颐谴蛩惆颜飧鎏致鄯诺
轿颐嵌訤IREWALL-1中使用的一些状态跟踪机制的阐述。
当FIREWALL-1接收到第一个RSH或者REXEC连接的SYN包，它就记录源地址，源
端口，和目的地址，和一个MAGIC号码，并把TCP序列号+1放到pending 表,防火墙
记录这些信息是为了它能认出第一个连接数据包中包含的数据，当第一个RSH连接
的数据信息包(即SYN后面的一个包)通过防火墙后，它在pending table中的表目
将由一个新的条目代替，包含源IP地址，error port (由TCP PAYLOAD展开的)，
目的IP地址，同样的MAGIC号码，和IP协议。防火墙在截获第一个SYN的错误连接
，防火墙检查它在pending表中的参数并增加其中的连接到连接表中.
在使用pending table中存在一个冲突可以被利用，如果我们提供一个初始化
值为5，那样在pending表中加1变为6--与第一个信息包建立的条目，因此，通过
伪造一个来字intranet或则DMZ机器的的数据包--其数据包由ISN初始化序列号值
为5，包含我们要访问的源端口，我们要攻击的机器的目的IP地址，和RSH服务的
目的端口组成，这样的一个SYN包就会把这个表项增加到连接表中以允许我们连接
到“RSH client”.
在版本4.1中，这个问题不能被利用，因为初始化SYN包不能被通过.
[我们可以参照下面的图形来帮助理解：
-- -------------------- ---------------------
| |s-addr:s-port | |s-addr:s-port |
| |d-addr:magic | |d-addr:magic |
| |seq+1 | |seq+1 |
SYN <----| -------------------- ---------------------
| -------------------- ||
| |172.16.0.2:1024 | ||
| |192.168.0.2:magic | ||
| |250001 | ||
-- -------------------- ||
-- -------------------- ||
| |s-addr:error-port | ||
| |d-addr:magic | ||
| |protocol | ||
packet#2<----| -------------------- vv
(port info) | -------------------- ---------------------
| |172.16.0.2:1025 | |172.16.0.2:32775 |
| |192.168.0.2:magic | |192.168.0.2:magic |
| |6(TCP | |6 = seq + 1 = TCP |
-- -------------------- ---------------------
]
4.4 UDP Replies
---------------
在FIREWALL-1 4.0默认安装下，允许DNS通讯所有的主机，当和不严格的IP伪
造保护结合起来的时候，这个规则将允许我们从DMZ或者INTRANET伪造UDP数据包
到我们所要攻击的机器，如果UDP回应允许，我们可以回答那些数据包--即有效的
允许我们可以和防火墙后面的任意UDP服务通信。
我们这里的演示攻击了目标机器是SOLARIS2.6系统的SNMP守护程序，使用“
tun”同居，我们发送FWZ封装的数据包到防火墙的外部接口，当被解封装的时候
，被认为是来自内部机器的SNMP服务，并指定端口为53/UDP。
[先看看下面的图形解释：
--------------------------
| s-addr=172.160.2 | IP Header
| d-addr=192.168.0.1 |
--------------------------
| s-port=161 | UDP header
| d-port=53 |
--------------------------
| d-addr=192.168.0.2 |封装信息
--------------------------
------------ ---- -------------
|172.16.0.2|--|防|<-------------------------- |192.168.0.2|
------------ |火| 伪造的DNS请求 -------------
DNS被请求 |墙|
----
192.168.0.1
]
这样其实是对172.16.0.2的DNS作出了请求。
5 一些推荐
----------
5.1 Non-reliance on NAT
-----------------------
就想上面提到的，FWZ封装可以用来发送信息包通过不能被路由的防火墙，这
包括信息包指定在NAT或则RFC 1918私人网络后面的地址，举一个例子，在防火墙
默认配置中，由于“allow all port 53” 规则一个攻击者可以直接访问INTRAN
ET或者DMZ中的DNS服务。如果ICMP的“allow all”规则允许，一个攻击者可以M
AP任意INTRANET或者DMZ的子网络。
NAT和不能路由地址不必要的提供任何固有安全，虽然FWZ封装对FIREWALL-1
很有效，类似攻击使用其他VPN封装技术可以更加广泛的应用--GRE，为IPSEC的I
P协议，和甚至在IPV4中的IPV6通道。
5.2 推荐配置
---------
一些简单的规则：
1，尽可能运行最新的FIREWALL-1版本。
2，关闭一些规则，包括DNS，管理控制连接和ICMP
3，在定义规则的时候尽量明确--没有如“any”这样的源或者目的IP地址，
拒绝多播和广播地址等等。
4，在所有接口中激活所有IP伪造保护机制。
5，Pre-filter IP protocol 94
6，给公共服务的使用的虚拟地址。
7。到目前使用FWA1认证。
5.3 补丁信息
-----------
CHECKPOINT已经发表对这些问题的补丁，当前的SERVICE PACK，HOTFIX和警
告可以到下面的地址：
http://www.checkpoint.com/techsupport/
http://www.checkpoint.com/techsupport/alerts
在这个建议里，我们概括了我们发现的和提供了一些安全配置的建议，并且
提供了一些补充用的图片和源代码，大家可以到下面地方去查找：
http://www.dataprotect.com/bh2000/
[上面地址包含测试工具的源程序，和帮助你理解的图形解释，虽然我这里为了方
便大家，尽力把这些图文本化了，可你如果要色彩或者更明了的话就下载上面的
.pdf文件，希望有点帮助。]
--
※ 来源:．月光程序代码网 http://www.moon-soft.com．[FROM: 202.130.232.129]
|
|