USG配置natserver.docx
《USG配置natserver.docx》由会员分享，可在线阅读，更多相关《USG配置natserver.docx（67页珍藏版）》请在冰豆网上搜索。
USG配置natserver
配置server-map表2
目的2
原理描述3
端口映射7
目的7
应用层包过滤9
ASPF简介9
ASPF介绍10
多通道协议的检测10
QQ/MSN协议检测11
ActiveXBlocking和JavaBlocking的检测11
用户自定义的协议检测12
在域间应用ASPF功能13
前提条件13
背景信息14
操作步骤14
后续处理15
配置FTP深度映射功能15
配置对报文的分片处理16
报文分片原理17
配置分片丢弃功能18
配置分片报文直接转发功能19
配置分片散列表老化时间19
配置分片报文保序19
配置IDS联动20
IDS联动简介20
配置IDS联动21
配置终端安全管理（TSM联动）22
TSM联动简介22
配置SACG与TSM控制器的连接30
管理用户与角色33
配置自定义策略35
配置URPF37
URPF37
URPF的处理流程37
配置接口URPF38
UTM39
UTM检测39
入侵防御（IPS）39
反病毒（AV）39
Web过滤40
邮件过滤41
FTP过滤41
应用控制41
UTM虚拟化42
AV简介42
原理42
支持处理的文件42
扫描方式42
处理顺序43
特殊文件的处理策略43
病毒文件处理策略44
处理AV过程44
配置AV全局参数45
启用AV功能45
置病毒扫描等级46
配置压缩文件最大解压层数46
配置AV策略47
配置IPS47
IPS产生背景48
IPS签名48
IPS策略49
攻击响应方式50
IPS配置流程51
配置IPS全局参数51
配置公共模式组52
公共模式组简介53
公共模式组分类53
匹配方式54
模式、模式组、匹配域的关系55
模式组的匹配结果56
MPLS与VPN56
L2TP配置流程56
配置server-map表
Server-map表是一个通过少量关键元素来记录部分特殊服务连接状态的特殊表项。
ASPF（ApplicationSpecificPacketFilter）是指系统为了转发一些多通道协议报文，通过解析报文数据载荷，识别多通道协议自动协商出来的端口号，并自动生成相应的Server-map表项的功能。
目的
在严格包过滤的情况下，设备通常只允许内网用户单方向主动访问外网。
但是在使用NAT或ASPF功能的情况下，可能存在外网用户通过随机端口主动访问内网服务器的情况。
由于会话表的五元组限制过于严格，会导致这些特殊服务不能正常运行。
引入Server-map表是为了解决这一问题。
ASPF是为了解决多通道协议这种特殊服务的转发而引入的。
这些协议会在通信过程中自动协商一些随机端口，在严格包过滤的情况下，这些随机端口发出的报文同样不能得到正常转发。
通过ASPF功能可以对这些协议的应用层数据进行解析，识别这些协议协商出来的端口号，从而自动为其开放相应的访问规则，解决这些协议不能正常转发的问题。
原理描述
Server-map表的引入
通常情况下，如果在设备上配置严格包过滤，那么设备将只允许内网用户单方向主动访问外网。
但在实际应用中，例如使用FTP协议的port方式传输文件时，既需要客户端主动向服务器端发起控制连接，又需要服务器端主动向客户端发起服务器数据连接，如果设备上配置的包过滤为允许单方向上报文主动通过，则FTP文件传输不能成功。
为了解决这一类问题，USG设备引入了Server-map表，Server-map用于存放一种映射关系，这种映射关系可以是控制数据协商出来的数据连接关系，也可以是配置NAT中的地址映射关系，使得外部网络能透过设备主动访问内部网络。
生成Server-map表之后，如果一个数据连接匹配了Server-map表项，那么就能够被设备正常转发，而不需要去查会话表，这样就保证了某些特殊应用的正常转发。
USG设备上生成Server-map表项目前总共有四种情况：
∙配置ASPF后，转发FTP、RTSP等多通道协议时生成的Server-map表项。
∙配置ASPF后，转发QQ/MSN、TFTP等STUN类型协议时生成的三元组Server-map表项。
∙配置NATServer或SLB时生成的静态Server-map。
∙配置NATNo-PAT时生成的动态Server-map。
下面分别对这四种Server-map表进行介绍。
端口映射
转发多通道协议时生成的Server-map表项
转发FTP、RTSP等多通道协议的数据会生成Server-map表项。
多通道协议会由客户端和服务器之间的控制通道动态协商出数据通道，即通信双方的端口号是不固定的。
而在配置ASPF功能后，设备检测到控制通道的协商，根据关键报文载荷中的地址信息动态创建server-map表项，用于数据通道发起连接时进行查找。
这个server-map表项包含了多通道协议报文中协商的数据通道的信息。
例如在FTP的port模式中，在FTP客户端随机选择一个数据通道端口号（本例中的2165），并通过控制通道将该端口号发送给FTP服务器后，FTP服务器会直接向该端口发起连接。
如果此时配置了ASPF功能，会生成如下Server-map表项：
ASPF:
40.0.0.5->40.0.0.10:
2165,Zone:
---
Protocol:
tcp（Appro：
ftp-data）,Left-Time:
00:
00:
05,Addr-Pool:
---
Vpn:
public->public
其中，tcp（Appro：
ftp-data）表示该条Server-map表项用于FTP协议的数据通道的转发。
40.0.0.5为源IP地址，即发起连接的FTP服务器的IP地址，40.0.0.10为目的IP地址，即FTP客户端的IP地址。
在采用严格包过滤情况下，由于事先没有配置对2165端口允许的包过滤策略，所以如果没有Server-map表项，会导致该连接被阻断。
ASPF自动生成Server-map表项后，由于只需要匹配四元组信息，所以就可以实现正常的数据传输了。
转发STUN类型协议时生成的三元组Server-map表项
转发QQ/MSN等STUN（SimpleTraversalofUDPoverNATs，NAT的UDP简单穿越）类型会生成的三元组Server-map表项。
QQ/MSN等协议中，当用户登录之后，用户的IP地址和端口就固定下来了，可是会向该用户发起对话的另一方的IP地址和端口号是不固定的。
通过配置STUN类型的ASPF，当QQ或者MSN等用户连接服务器时，设备会记录下用户的IP地址和端口信息，并动态生成STUN类型的Server-map。
这个server-map表项中仅包含三元组信息，即通信一方的IP地址，端口号和协议号。
这样其他用户可以直接通过该IP和端口与该用户进行通信。
只要有相关的流量存在，STUN动态的server-map就将一直存在。
在所有相关流量结束后，server-map表开始老化。
例如：
STUN:
ANY->40.0.0.10:
4967，Zone：
---
Protocol:
udp（Appro：
qq-derived）,Left-Time:
00:
00:
05，Addr-Pool:
---
Vpn:
public->public
在本例中，由于源地址为ANY，即不限制，这样任意用户都可以主动向40.0.0.10的4967端口发起连接，以实现未知用户向内网的QQ/MSN用户发起对话的情况。
配置NATServer或SLB时生成的静态Server-map
在使用NATServer功能时，外网的用户向内部服务器主动发起访问请求，该用户的IP地址和端口号都是不确定的，唯一可以确定的是内部服务器的IP地址和所提供服务的端口号。
所以在配置NATServer成功后，设备会自动生成Server-map表项，用于存放Globle地址与Inside地址的映射关系。
设备根据这种映射关系对报文的地址进行转换，并转发。
每个生效的NATServer都会生成正反方向两个静态的Server-map。
用户删除NATServer时，Server-map也同步被删除。
NATServer生成的Server-map表项实例如下所示。
NatServer,ANY->202.169.10.2:
21[10.1.1.2:
21],Zone:
---
Protocol:
tcp（Appro:
ftp）,Left-Time:
---,AddrPool:
---
Vpn:
public->public
NatServerReverse,10.1.1.2[202.169.10.2]->ANY,Zone:
---
Protocol:
ANY（Appro:
---）,Left-Time:
---,AddrPool:
---
Vpn:
public->public
∙NatServer表示正向（即外网客户端主动访问内网服务器方向）的Server-map表项。
∙NatServerReverse表示反向（即内网服务器主动访问外网客户端方向）Server-map表项。
∙Protocol表示配置NatServer时指定的协议类型。
∙202.169.10.2表示NatServer的Globle地址，即对外公布的公网IP地址。
∙10.1.1.2表示NatServer的Inside地址，即转换前的私网IP地址。
在SLB功能中，由于需要将内网的多个服务器以同一个IP地址对外发布，所以也会建立与NATServer类似的Server-map表项，只不过根据内网服务器的个数N，需要建立1个正向表项和N个反向表项。
配置NATNo-PAT时生成的动态Server-map
在使用NAT功能时，如果配置了No-PAT参数，那么设备会对内网IP和公网IP进行一对一的映射，而不进行端口转换。
此时，内网IP的所有端口号都可以被映射为公网地址的对应端口，外网用户也就可以向内网用户的任意端口主动发起连接。
所以配置NATNo-PAT后，设备会为有实际流量的数据流建立Server-map表，用于存放私网IP地址与公网IP地址的映射关系。
设备根据这种映射关系对报文的地址进行转换，然后进行转发。
NATNo-PAT生成的Server-map表项实例如下所示。
No-Pat:
10.1.1.2[202.169.10.2]->ANY,Zone:
untrust
Protocol:
ANY（Appro：
---）,Left-Time:
00:
00:
03,Addr-Pool:
61
Vpn:
public->public
No-PatReverse,ANY->202.169.10.2[10.1.1.2],Zone:
untrust
Protocol:
ANY（Appro：
---）,Left-Time:
00:
00:
03，Addr-Pool:
---
Vpn:
public->public
∙No-Pat表示正向Server-map，即指从私网IP发起的连接。
∙No-PatReverse表示反向Server-map，即指外网设备通过分配的公网IP来访问私网IP对应设备所发起的连接。
∙10.1.1.2表示映射前的私网IP地址。
∙202.169.10.2表示映射后的公网IP地址。
Server-map表在转发流程中的位置
Server-map表在转发流程中的位置请参考图1。
当一个没有会话表项的报文在通过系统的安全性检查之后，系统准备为其查找路由之前，系统会查询Server-map表。
此时查找Server-map表主要是为了两个目的：
∙对该报文所属连接的状态再次检查和确认
由于该报文没有会话表项，所以它有可能是属于需要建立Server-map的特殊业务的报文。
通过查询Server-map可以确认这个报文是否属于一个已经存在的连接。
如果这个报文既没有会话表项，又不属于一个已经存在的特殊业务，那么在严格包过滤情况下，这个报文就会被丢弃。
∙根据Server-map表对报文中一些元素进行转换
Server-map表项除了会记录报文的关键元素，还会记录系统对该报文的一些处理措施。
对于一个和Serve-map表项匹配的报文，系统在查询Server-map表后，会根据表项中的记录对报文进行转换。
例如在NATServer应用中，系统会将一个访问内部服务器的报文的目的地址从公网地址转换为私网地址。
由于Server-map中并不会记录报文的下一跳等信息，所以Server-map通常只是用检查第一个报文。
在这个报文通过检查之后，系统会生成一条会话表用于后续报文的转发。
即Server-map只是用于新通道的建立，通道建立后的报文还是根据会话表来转发。
以FTP的Port模式为例。
主机A的IP地址是192.168.1.1，使用20000端口向服务器B发起FTP连接。
服务器B的IP地址是1.1.1.1，提供服务的端口号是21。
系统已经通过配置包过滤允许了192.168.1.1向1.1.1.1的21号端口发起连接。
1.在发起连接的报文通过后，系统中创建了一条会话表项，通信双方的控制通道也就建立起来了。
类型
源IP地址
源端口
目的IP地址
目的端口
协议
会话表
192.168.1.1
20000
1.1.1.1
21
FTP
2.经过控制通道的协商，A随机选择一个数据通道端口号2165，并通过控制通道将该端口号发送给FTP服务器。
系统在获取到这个报文后为其建立Server-map表项。
类型
源IP地址
目的IP地址
目的端口
协议
Server-map表
1.1.1.1
192.168.1.1
2165
FTP-Data
3.B在收到A的协商报文之后，使用20端口主动向192.168.1.1的2165端口发起连接。
这个连接在会话表中没有对应的表项，如果域间缺省包过滤策略为禁止，则可能会被丢弃。
所以此时，系统就会查询Server-map，以确定该报文是否属于特殊业务。
由于这个报文的源IP地址、目的IP地址、目的端口和协议都与Server-map表项符合，系统允许这个报文通过。
而且此时这个新的数据通道的五元组都已经确定，所以系统同时创建一条会话表，通信双方的数据通道也就建立起来了。
类型
源IP地址
源端口
目的IP地址
目的端口
协议
会话表
1.1.1.1
20
192.168.1.1
2165
FTP-Data
4.后续数据通道上传输的数据报文都可以匹配这条会话表项并得到转发，不再需要重新匹配Server-map表项。
Server-map表项由于一直没有报文匹配，经过老化时间后就会被删除。
这种机制保证了Server-map表项这种较为宽松的检测条件能够及时被删除，保证了网络的安全性。
ASPF的实现以及ASPF与Server-map表的关系
在上述举例中，A随机选择一个数据通道端口号2165，并通过控制通道将该端口号发送给FTP服务器。
“2165”这个端口信息是包含在协商报文的应用层载荷中的。
系统在收到这个报文之后，能够将其解析出来，正是因为开启了ASPF功能。
ASPF的主要作用就是对报文的应用层数据进行解析，识别出包含在IP报文数据载荷中的各种协商信息，以供设备自动为其创建相应的访问规则。
由于各种协议的报文结构和协商方式各不相同，所以USG目前只能支持特定种类的协议的识别。
ASPF识别完成之后，系统通常会生成一条Server-map表项来记录识别结果。
之所以不直接生成会话表项，是因为识别完成时，通常通信双方都只是在协商阶段，新通道上还没有实际的数据传输，或者新通道的五元组信息还没有完全确定，所以还不能建立会话表。
通过ASPF识别，建立Server-map表项后，当系统收到新通道上的第一个报文，就会生成相应的会话表项。
后续该通道上的报文就都可以根据会话表进行转发了。
端口映射
端口映射是指将发往非知名端口的报文识别为知名协议的功能。
目的
应用层协议一般使用知名端口号进行通信。
当用户使用非知名端口提供知名服务时的业务时，可以使用端口映射功能对这些业务进行识别。
前提条件
由于端口映射功能通过ACL来匹配流量，所以在配置端口映射之前，需要首先创建用来匹配流量的ACL，且端口映射功能只能使用基本ACL进行匹配。
由于端口映射的主要目的是将发往内网服务器非知名端口的报文识别为知名服务，ACL主要定义的就是内网服务器的IP地址和它所提供的端口。
所以在定义的ACL的规则时，应将内网服务器的IP地址作为source-address。
在设备实现时，会检测发往source-address的报文。
背景信息
应用层协议一般使用知名端口号进行通信，例如FTP使用20和21端口，Web服务通常使用80端口。
但是在某些情况下，内网服务器需要通过其他自定义端口对外提供知名服务时，可以通过端口映射功能来完成相应的转换。
端口映射的原理是，创建一个协议与映射端口的关联表，当收到发往映射端口的报文时，会将其识别为对应的知名服务的报文，并进行相应的应用层识别等功能。
例如，内网服务器A希望使用21000端口对外提供FTP服务。
如果不使用端口映射功能，设备将认为发往A的21000端口的报文为普通报文。
这时如果组网场景需要使用ASPF功能，即使用户在域间配置了detectftp命令，还是不能正常提供FTP服务，因为设备并不认为发往21000端口的报文是FTP报文，也就不会进行相应的检测和分析。
所以此时需要通过端口映射功能将21000端口映射为FTP服务。
这个映射并不是指设备会将发往21000端口的报文转发给21端口，而是指设备会将发往21000端口的报文认为是FTP协议报文。
操作步骤
1.执行命令system-view，进入系统视图。
2.执行命令port-mapping protocol-name port port-number acl acl-number，配置端口映射。
执行该命令后，就会将ACL匹配的流量中，发往port-number端口的报文认为是protocol-name协议。
配置端口映射时：
∙一个协议可以配置多个映射端口。
∙一个端口可以映射为多个协议，但是必须通过基本ACL进行区分，对匹配不同的基本ACL的报文使用不同的映射关系。
在匹配时，会按照ACL的配置顺序进行匹配，先创建的ACL先进行匹配。
▪如果流量命中的规则的动作是permit，则按该ACL对应的协议进行映射。
▪如果流量命中的规则的动作是deny，则跳出该ACL的匹配，进行下一条ACL的匹配。
▪如果整个ACL中所有规则都没有命中，则进行下一条ACL的匹配。
任务示例
本例中，希望通过端口映射功能将发往10.1.1.1的21000端口的报文按FTP报文处理。
system-view
[sysname]acl2005
[sysname-acl-basic-2005]rulepermitsource10.1.1.10
[sysname-acl-basic-2005]quit
[sysname]port-mappingftpport21000acl2005
后续处理
如果查看当前系统已经配置的端口映射表，可以执行命令displayport-mapping命令。
[sysname]displayport-mapping
SERVICEPORTACLTYPE
-------------------------------------------------
ftp21systemdefined
smtp25systemdefined
http80systemdefined
rtsp554systemdefined
h3231719systemdefined
mgcp2727systemdefined
mms1755systemdefined
sqlnet1521systemdefined
pptp1723systemdefined
sip5060systemdefined
ftp210002005userdefined
在本例中，存在两个ftp协议的端口映射关系，一个是ftp与21端口的映射，一个是ftp与21000端口的映射。
通过TYPE字段可以看出，21端口是系统预定义的映射关系，21000端口是用户自定义的映射关系。
一个协议可以同时与多个端口进行映射，用户自定义的映射关系并不会替代系统预定义的映射关系，而是两者同时有效。
区别是系统预定义映射对所有流量有效，用户自定义映射只对ACL所匹配的流量有效。
应用层包过滤
由于某些特殊应用会在通信过程中临时协商端口号等信息，所以需要设备通过检测报文的应用层数据，自动获取相关信息并创建相应的会话表项，以保证这些应用的正常通信。
这个功能称为ASPF（ApplicationSpecificPacketFilter）。
∙ASPF简介
ASPF是针对应用层的包过滤。
ASPF的原理是通过检测通过设备的报文的应用层协议信息，自动维护相应的Servermap表项，使得某些在基本包过滤功能中没有明确定义要放行的报文也能够得到正常转发。
∙在域间应用ASPF功能
当需要设备转发多通道协议报文时，需要在域间配置相应的ASPF功能。
∙配置ASPF举例
在多通道协议和NAT的应用中，ASPF是重要的辅助功能。
本例将使用路由口，通过配置ASPF功能，实现内网正常对外提供FTP和TFTP服务，同时还可避免内网用户在访问外网Web服务器时下载危险控件。
ASPF简介
ASPF是针对应用层的包过滤。
ASPF的原理是通过检测通过设备的报文的应用层协议信息，自动维护相应的Servermap表项，使得某些在基本包过滤功能中没有明确定义要放行的报文也能够得到正常转发。
ASPF功能不但可以对报文的网络层信息进行检测，也可以对报文的应用层信息进行深度检测，是USG安全规则检查的重要组成部分。
ASPF的实现基础是server-map表，关于server-map表的详细信息，请参见配置Server-map表。
ASPF介绍
ASPF是针对应用层的包过滤，即基于状态的报文过滤。
ASPF能够检测试图通过设备的应用层协议会话信息，通过维护会话的状态和检查会话报文的协议和端口号等信息，使得某些特殊应用的报文能够正常转发。
ASPF可以对以下协议的流量进行监测：
∙DNS（DomainNameSystem），域名解析系统。
∙FTP（FileTransferProtocol），文件传输协议。
∙H323（H.323Protocol），用于在计算机网络中实现音频和视频通信。
∙ICQ，美国在线公司AOL出品的一款软件ICQ使用的通信协议，支持在Internet上聊天、发送消息和文件等。
∙ILS（Int
升级会员 