USG配置nat - server

发布时间 : 星期日 文章USG配置nat - server更新完毕开始阅读

保护网络不受有害Java Applets的破坏。 ?

ActiveX Blocking

保护网络不受有害ActiveX的破坏。

提供这两种控件的ASPF功能是因为它们通常被包含在报文的净载荷中进行传输,只检查报文头信息无法将其识别出来,但是它们又非常容易被制作为木马与病毒,所以必须通过应用层检测将其识别出来,以保护内网主机。

用户自定义的协议检测

在TCP/IP协议族中,通过端口号来判断报文的协议类型。如果用户有某些特殊应用不在上述支持的应用协议范围内,设备不能解析其应用层数据,但是用户又了解该应用的协议原理,可以通过ACL来对某一类流量进行定义,通过自定义协议的ASPF功能自动为其创建STUN类型的server-map表项,以保证报文的转发。

用户自定义的协议检测是一种特殊的ASPF应用。通过该功能根据用户的源地址、源端口创建三元组的server-map,可以解决使用同一个端口的多通道应用的问题——即有些应用其控制通道和数据通道共用客户端的端口号。最典型的应用是TFTP。

例如,在一个TFTP应用中,内网用户A的IP地址为10.1.1.1,它会通过一个随机选择的端口22787向外网服务器B的端口69发起TFTP连接。之后B会重新随机选择一个端口主动向A的22787端口发起连接。 ?

在不开启ASPF功能并且域间缺省包过滤为禁止的情况下,如果包过滤策略只允许A与B的69端口的连接,那么设备会建立一个会话表项以保证这两个端口之间的报文传输。但是B随机选择的端口与A之间的连接不能预先知道,也就没有相应的允许的策略,所以这个连接最终不能建立成功。 ?

在开启自定义的ASPF功能的情况下,管理员可以预先定义一条ACL规则为rule permit udp source 10.1.1.1 0。通过在自定义的ASPF中引用该条ACL,设备会对报文做如下处理: 1. 当内网用户A首先发起连接后,设备将自动识别用户发起连接的端口,并创建一条

server-map表项允许任意IP和端口访问A的22787端口。

2. 当服务器发送的报文到达时,会命中这条server-map表项,设备将解析服务器的IP

与端口号并为这个连接建立一个会话表项 3. 删除之前建立的server-map表项。

这个机制在最大程度保证安全性的基础上,更加精确地保证了业务的运行。

说明:

定义该条ACL规则的原则是其限定的范围约精确越好,这样可以最大限度地降低安全风险。所以在使自定义的ASPF时需要对协议原理有一定的了解。例如在本例中,如果服务器B的IP地址是固定的,为1.1.1.1,那么ACL规则可以更加精确地定义为rule permit tcp source 10.1.1.1 0 destination 1.1.1.1 0。 报文处理流程如图2所示。

图2 TFTP协议ASPF检测机制

父主题: 配置应用层包过滤(ASPF)

在域间应用ASPF功能

当需要设备转发多通道协议报文时,需要在域间配置相应的ASPF功能。

前提条件

配置ASPF功能与配置NAT ALG功能使用的是同一条命令。所以如果已经在域间配置过NAT ALG功能的话,可以不需要再重复配置ASPF功能。 两者的区别在于: ? ?

ASPF功能的目的是识别多通道协议,并自动为其开放相应的包过滤策略。

NAT ALG功能的目的是识别多通道协议,并自动转换报文载荷中的IP地址和端口信息。

在域间执行detect命令,将同时开启两个功能。

在配置用户自定义的ASPF的时候,需要首先定一条基本ACL规则或高级ACL规则用于匹配流量。

其中规则的动作应设置为permit才能让设备对该条流量进行应用层检测。关于ACL的详细信息请参见《配置指南 防火墙》。

在配置ASPF的包过滤的时候,需要首先定义一条基本ACL或高级ACL用于判断是否为流量生成三元组Server-map表项。其中规则的动作应设置为deny才能让设备不为该条流量生成三元组Server-map表项。没有生成三元组server-map表项的多通道协议流量是不能得到正常转发的。

背景信息

配置detect msn时请注意: ?

MSN用户使用私有协议MSNP进行通信。MSNP的通话端口是随机分配的。在严格包过滤情况下,设备开放的端口很少,当外网向内网发起呼叫请求时,由于设备无法解析MSNP协议,不能获得外网主机的IP地址,会导致业务不通。这时需要在包过滤中配置允许端口号为1000~9999的UDP数据流通过设备,以便设备能够获得MSN的外网主机地址,使MSN会话能够顺利进行。 ?

由于MSN同时使用1863和443号端口作为登录和文字聊天的通道,故需要在包过滤中配置允许端口号为1863和443的数据流通过,使MSN会话顺利进行。

操作步骤

1. 执行命令system-view,进入系统视图。 2. 执行命令firewall

interzone [ vpn-instance vpn-instance-name ] zone-name1 zone-name2,进入安全域间视图。

3. 根据需要进行检测的应用层协议类型,执行以下命令:

?

如果需要检测设备目前支持的知名协议,执行命令detect [ ipv6 ] protocol。 对于USG2110-X/2100/2200/5100,缺省情况下,已开启dns、ftp、h323、icq、ils、mgcp、mms、msn、netbios、pptp、qq、rtsp、sip、sqlnet协议的该功能;对于USG2100/2200/5100 BSR/HSR、USG5500,缺省情况下,不开启任何协议的该功能。 ?

如果需要检测自定义协议,执行命令detect

user-defined acl-number { inbound | outbound },配置自定义协议的ASPF功能。 其中引用的ACL应当预先创建完成,创建ACL的原则可以参考ASPF简介。所应用的方向应该是首次发起连接的报文的方向。

说明:

由于自定义协议的ASPF是通过生成Server-map表项来实现报文转发的。在执行命令undo detect user-defined后,只能阻止新表项的生成,不能立即删除已经生成的表项,所以已经建立起来的业务只有当相应的Server-map表项老化后才会被中断。

? 如果需要检测并阻断下载ActiveX控件或Java控件,执行命令detect { activex-blocking | java-blocking }。

4. 可选:需要对QQ、MSN、User-define等STUN类型协议的ASPF作用范围进行一步限定的

情况下,可以通过执行aspf packet-filter acl-number { inbound | outbound },配置命中三元组Server-map表的报文过滤规则。

说明:

该命令只对STUN类型协议有效。关于STUN类型协议的详细信息,请参见Server-map表简介。

请严格定义ACL规则的匹配范围,对命中三元组ServerMap表的报文进行过滤,实现更精细化的包过滤控制。

该条命令的功能与包过滤功能类似。包过滤功能可以通过检测报文的五元组信息决定是否转发报文和建立会话,aspf packet-filter则可以对命中Server-map表的数据进行ACL包过滤,将不允许通过的报文丢弃。

由于ASPF功能建立的Server-map表项放宽了会话的五元组限制,在保证了业务得到转发的同时,也使得某些端口的访问被放开,存在一定的安全隐患。所以一方面,在配置ASPF功能的时候,用于匹配流量的ACL应配置得越精确越好,另一方面,对于已经建立了Server-map表项的报文,虽然不会进行包过滤规则的检查,但是通过aspf packet-filter命令,也可以阻止其中的一部分报文被转发。

该条命令所应用的方向和选取原则与包过滤一致,对于动作为permit的流量会正常转发,对于动作为deny的流量,会进行丢弃。例如,希望阻止Trust区域的用户1.1.1.1与Untrust区域的QQ通信,则可以将ACL规则设计为rule deny source 1.1.1.1 0,然后通过aspf packet-filter命令将其应用在Trust区域的Outbound方向上。

后续处理

由于ASPF功能决定了很多特殊协议能够得到正常转发,所以当这些业务出现问题时,可以通过以下两种方式来进行问题定位: ? ?

执行命令display interzone查看域间的配置,核对域间是否正确配置了ASPF功能。 执行命令display firewall server-map查看当前设备上已经创建的Server-map表项,详细信息请参见查看Server-map表。 ?

执行命令display firewall ipv6 server-map查看当前设备上已经创建的IPv6 server-map表项。

配置FTP深度映射功能

当需要严格控制内部FTP用户的get或put的操作权限时,需要配置FTP深度检测功能。

联系合同范文客服:xxxxx#qq.com(#替换为@)