欢迎关注:1，欢迎关注本博客，你可点击右手边的【QQ邮件订阅】订阅本博客！2，本博客推出江湖救急计划，主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析，如有需要，请在江湖救急计划页面给我留言！

HP-UX系统下的抓包工具——tcpdump与nettl

作者：易隐者 发布于：2012-3-16 17:39 Friday 分类：参考资料

HP-UX上使用tcpdump抓包的方法

1.检查是否有tcpdump软件，如果没有则安装tcpdump软件，软件在hpl3000上有
2.抓包
# netstat -in看现在用的是那个网卡，假如用的是lan0
# tcpdump -i lan0 -w /tmp/lan0.tcpdump.log -x -vv 'tcp port 53'
运行一段时间后按^C中断
注意：运行过程要监控一下/tmp的使用率，如果/tmp上升得太快则需要马上中断抓包进程。
3.格式化包输出
# tcpdump -nq -r /tmp/lan0.tcpdump.log.bak > /tmp/output.tcpdump.log
然后把/tmp/output.tcpdump.log提供出来就可以

HP-UX上用nettl抓包

HP-UX 自己提供了抓包工具，nettl 。在tcpdump不能用的时候它（比如tcpdump在HP-UX上就不能抓回环上的包）就派上用场了。总结一下nettl的主要用法，备查。

开始抓包：
# nettl -tn all -e all -maxtrace 99999 -f /tmp/tixiang

# nettl -tn loopback -e ns_ls_tcp -maxtrace 99999 -f /tmp/tixiang

# nettl -tn pduin pduout -e ns_ls_loopback -tm 100000 -f /tmp/local

# nettl -tn pduin pduout -e ns_ls_loopback -m 56 -tm 100000 -f /tmp/local

# nettl -tn pduin -e ns_ls_loopback -m 56 -tm 100000 -f /tmp/local

-m size 限制每个包的大小。我们不一定对所有的包都感兴趣，在只对包头感兴趣的时候这个选项就非常有效。
FDB协议使用的包头为16个字节，再加上IP头的20个字节，TCP头的20个字节，也就是我们只需要总共56个字节就能确定一个包的基本信息了。

-e subsytem 要抓包的类型，可以使用 nettl -status 来获取。
ns_ls_loopback
ns_ls_ip
ns_ls_tcp
ns_ls_udp
ns_ls_icmp

-tm maxsize 每个文件的最大大小，如果超过此大小，会使用下一个抓包文件。单位：KB。有效值：100~99999

抓包的输出文件为 /tmp/tixiang.xxxx，使用 ls -l /tmp/tixiang.* 来检查

说明：
在 ns_ls_loopback 上抓包如果指定了pduin 和 pduout 每个包会抓到2份，因为一进一出就是两份。
如果指定 -tn all -e all 一个包也会抓到多份，因为一个包可能属于不同的 subsystem，比如一个tcp包既属于tcp，也属于ip等。

抓的包可以使用wireshark来打开并进行分析。也可以使用HP-UX自带的netfmt来分析。

查看状态及-entity可用的信息：
# nettl -status

停止抓包：
# nettl -tf -e all
对包的分析
我们可以使用netfmt来查看捕获的包：
netfmt -N -l -f /tmp/nettl_t* | more

可以过滤我们感兴趣的包，使用 -c 来传入过滤文件
netfmt -N -l -c filter -f /tmp/nettl_t* | more
filter 为过滤文件，文件内容的类似如下：
filter tcp_sport 1234
filter tcp_dport 1234
每一行为一个过滤条件，行与行之间是或的关系。

使用行模式来显示（这种模式下不会看到包的具体数据）
netfmt -N -n -l -1 -f /tmp/nettl_t* | more

在每行的显示前加上时间戳
netfmt -T -n -l -1 -f /tmp/nettl_t* | more

参考：
http://www.compute-aid.com/nettl.html
http://docs.hp.com/en/B2355-60105/nettl.1M.html
http://docs.hp.com/en/B2355-60105/netfmt.1M.html

本文章源自网络，原始出处和作者信息请访问如下链接：
http://chenm.blogbus.com/logs/52906888.html

阅读全文>>

标签: tcpdump 抓包 HP-UX nettl

评论(0) 引用(0) 浏览(11946)

Hillstone防火墙抓包方法

作者：易隐者 发布于：2012-3-10 17:51 Saturday 分类：参考资料

debug

通过Debug定位NBC策略匹配问题相关说明如下：

使用注意：
         Debug功能开启后，有可能会产生CPU使用率高或设备打印输出大量信息，引起设备无法管理。
         请仔细理解Debug功能后，再使用相关调试功能。
         使用过程中，可以双击ESC关闭Debug功能；当设备开启Debug后无法管理设备，您也可以选择重启设备，设备重启后会自动关闭Debug功能
相关命令介绍：
         Debug dp filter src-ip X.X.X.X         //配置debug需要定位分析的源IP地址
         Show dp-filter                     //确认上一条配置的debug 数据转发过滤条件是否正确，如果配置错误可以使用“undebug dp filter id ”删除后重新配置
         debug dp policy lookup              //开启设备策略查找调试功能
         show debug                                                    //确认已经开启的设备调试功能
         clear logging debug                //清除历史调试打印信息
show logging debug                //查看debug打印日志
使用举例：
         设备配置了很多的NBC策略，目前发现172.20.10.68这个源IP没有达到客户城的NBC策略功能，现要求查看172.20.10.68访问某URL时匹配的NBC策略名称。
相应的调试过程如下（红色为输入的命令）：
SG6000-1(M)# debug dp filter src-ip 172.20.10.68
assigned id: 1
SG6000-1(M)# show dp-filter
---------------------------------------------------------------
vrouter name:trust-vr
---------------------------------------------------------------
id: 1
src-ip: 172.20.10.68 vrouter: trust-vr
---------------------------------------------------------------
SG6000-1(M)# debug dp policy lookup
SG6000-1(M)# show debug
dp:
  policy:
    lookup, enabled
SG6000-1(M)# clear logging debug
SG6000-1(M)# show logging debug
2011-05-24 10:00:32, DEBUG@FLOW: core 1 (sys up 0x169795ff ms): Pak src zone tru
st, dst zone untrust, prot 6, dst-port 80.
Auth-user id 0
Policy 37 matches, ===PERMIT=== （此处显示匹配了防火墙第37条策略，行为允许）
nbc match rule = 139\163mail   （此处显示匹配了NBC的“139\163mail”这条策略）


2011-05-24 10:00:32, DEBUG@FLOW: core 2 (sys up 0x1697962d ms): Pak src zone tru
st, dst zone untrust, prot 6, dst-port 80.
Auth-user id 0
Policy 37 matches, ===PERMIT===
nbc match rule = 139\163mail

SG6000-1(M)# undebug all               （此处非常重要，一定要在Debug使用完成后，关闭所有Debug功能）
SG6000-1(M)# undebug dp filter id 1
SG6000-1(M)# show debug
SG6000-1(M)# show dp-filter
---------------------------------------------------------------
vrouter name:trust-vr
---------------------------------------------------------------
[ FAQ88 ] 如何通过Debug定位NBC策略匹配问题？ - FAQ Information   Updated today (24 May 2011)

snoop

Snoop的语法应该跟juniper的差不多，暂无详细的相关资料。

阅读全文>>

标签: debug 防火墙 抓包 snoop Hillstone

评论(0) 引用(0) 浏览(23726)

百度空间同步插件测试文章

作者：易隐者 发布于：2012-3-2 22:35 Friday

百度空间同步插件测试文章

阅读全文>>

标签: 同步

评论(0) 引用(0) 浏览(11180)

各品牌交换机端口镜像配置大全

作者：易隐者 发布于：2012-3-1 20:34 Thursday 分类：参考资料

      该文档基本是网上最全的端口镜像设置大全文档，目前包含了26个品牌产品的端口镜像设置说明。比我以前在CSNA论坛上发表的版本，增加爱立信、hillstone SA、F5、凯创、Juniper、LinktrustSG等品牌的设置，具体的请自行下载文档查看参考。

 

阅读全文>>

附件下载：
各品牌交换机端口镜像配置大全.part1.rar 9.77MB
各品牌交换机端口镜像配置大全.part2.rar 4.07MB

标签: 端口镜像 交换机 SPAN

评论(2) 引用(0) 浏览(9333)

IPS在线升级故障分析案例

作者：易隐者 发布于：2012-2-29 20:32 Wednesday 分类：案例讨论

  1 故障环境

故障的网络拓扑结构主要如下图所示：

点击查看原图

说明：

1，防火墙做NAT，上网行为、IPS都工作在透明模式下，串接在核心互联网出口链路上；

2，防火墙内口地址为192.168.0.3，IPS管理口地址为192.168.0.4，上网行为管理地址为192.168.0.5；

2 故障现象

     IPS离线升级包升级正常，但是在线自动升级提示失败，如下图所示：

点击查看原图

 

3 故障分析

3.1 常规分析

    IPS地址、网关、DNS设置全部正常，具有访问互联网的权限，将升级失败情况跟厂家沟通，厂家已将IPS升级为最新的版本，并确认升级服务器端都是正常的，暂时无法下结论是否是IPS本身问题导致的。万般无赖之下，我觉得还是先抓包分析一下IPS升级时的数据交互情况。

3.2 数据包分析

当IPS在线升级时，我们在防火墙上通过tcpdump命令抓包，如下所示：

XX酒厂.system% tcpdump -i any host 202.85.219.10  -evv

//这条语句是在防火墙上抓取升级服务器地址的交互报文，并且显示报文的详细信息。

tcpdump: WARNING: Promiscuous mode not supported on the "any" device

tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 68 bytes

 

08:15:51.553847 R@eth12  In 00:0b:ab:2a:f5:1d ethertype IPv4 (0x0800), length 76: (tos 0x0, ttl  64, id 28482, offset 0, flags [DF], proto: TCP (6), length: 60)

 192.168.0.4.46461 > 202.85.219.10.80: S 2350953923:2350953923(0) win 5840 <mss1460,sackOK,timestamp 69524097[|tcp]>

//这个报文为IPS地址192.168.0.4发往升级服务器的SYN报文，这个报文出现在防火墙内口-eth12口。

 

08:15:51.553943 X@eth10 Out 00:13:32:06:8c:d4 ethertype IPv4 (0x0800), length 76: (tos 0x0, ttl  63, id 28482, offset 0, flags [DF], proto: TCP (6), length: 60)

 xx.242.83.189.46461 > 202.85.219.10.80: S 2350953923:2350953923(0) win 5840 <mss 1460,sackOK,timestamp 69524097[|tcp]>

//防火墙转发了IPS的SYN报文，经外网口NAT后发往服务器，走网通接口地址走的。

08:15:51.577559 R@eth10  In 00:25:9e:83:a3:2f ethertype IPv4 (0x0800), length 80: (tos 0x0, ttl 117, id 29778, offset 0, flags [none], proto: TCP (6), length: 64)

202.85.219.10.80 > xx.242.83.189.46461: S 1891282156:1891282156(0) ack 2350953924 win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]>

//防火墙外口收到服务器的SYN/ACK报文

08:15:51.577588 X@eth12 Out 00:13:32:06:8c:d2 ethertype IPv4 (0x0800), length 80: (tos 0x0, ttl 116, id 29778, offset 0, flags [none], proto: TCP (6), length: 64)

202.85.219.10.80 > 192.168.0.4.46461: S 1891282156:1891282156(0) ack 2350953924 win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]>

//防火墙将上面的报文从外网口的转发至内口，此时升级服务器的TTL为116。

 

08:15:51.579264 R@eth12  In 00:0b:ab:2a:f5:1d ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl  64, id 28483, offset 0, flags [DF], proto: TCP (6), length: 52)

 192.168.0.4.46461 > 202.85.219.10.80: ., cksum 0x1c80 (correct), 1:1(0) ack 1 win 46 <nop,nop,timestamp 69524099 0>

//IPS地址192.168.0.4对服务器的确认报文，至此，IPS与升级服务器三次握手完毕。

 

08:15:51.579269 X@eth10 Out 00:13:32:06:8c:d4 ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl  63, id 28483, offset 0, flags [DF], proto: TCP (6), length: 52)

 xx.242.83.189.46461 > 202.85.219.10.80: ., cksum 0x4e7d (correct), 1:1(0) ack 1 win 46 <nop,nop,timestamp 69524099 0>

//防火墙将上面的报文从内口转发至防火墙外口eth10。

 

08:15:51.580889 R@eth12   P 00:22:46:08:c2:b1 ethertype IPv4 (0x0800), length 230: (tos 0x0, ttl 128, id 22566, offset 0, flags [DF], proto: TCP (6), length: 214)

 202.85.219.10.80 > 192.168.0.4.46461: FP 1:175(174) ack 151 win 65535

//防火墙内口收到来自服务器IP地址的FIN标志置1的报文。

此处，我们发现几点异常：

1，IPS与升级服务器刚完成TCP三次握手过程，连接刚建立成功，服务器为什么紧接着发送FIN报文，这不符合常规的情况；

2，如果这个报文是来自外网的IPS升级服务器的，那么应该首先出现在防火墙的外网口上，而后再经防火墙转发，出现在防火墙内口上，但是防火墙外口eth10并未出现这个报文，而是直接在防火墙内口eth12口上出现；

3，如果eth12收到防火墙转发的来自升级服务器的报文，eth12应该是转发这个报文给内网的IPS地址，此处的应该显示为X@eth12，而不是R@eth12（R@eth12，R表示eth12口收到报文，X表示接口转发报文）；

4，前面已经分析发现升级服务器经过多跳路由后，至防火墙内口时，其IP报文的TTL值应为116，但是此处的TTL值为128；

 

综合以上疑问，我们可以肯定，这个FIN报文根本不是升级服务器自己发送的，而是来自内网的某个设备伪造的。

是什么设备发送的呢？我们在抓包的时候使用了-e参数，tcpdump会将报文的源MAC地址显示出来，我们可以看到这个伪造报文的源MAC是00:22:46:08:c2:b1

 

08:18:03.823668 R@eth10  In 00:25:9e:83:a3:2f ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 117, id 14719, offset 0, flags [none], proto: TCP (6), length: 40)

202.85.219.10.80 > 58.242.83.189.46461: R, cksum 0x6666 (correct), 1:1(0) ack 1 win 0

//132秒后，防火墙外口收到的来自升级服务器的RST报文，此时为升级服务器长时间未收到IPS的升级请求，连接超时发送的RST报文

 

08:18:03.823673 X@eth12 Out 00:13:32:06:8c:d2 ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 116, id 14719, offset 0, flags [none], proto: TCP (6), length: 40)

 202.85.219.10.80 > 192.168.0.4.46461: R, cksum 0x3469 (correct), 1:1(0) ack 1 win 0

//防火墙将上面的RST报文转发至内口

     我们通过防火墙的ARP表，发现00:22:46:08:c2:b1对应的IP为192.168.0.5，如下图所示：

点击查看原图

    192.168.0.5是上网行为管理设备的IP地址，结合上网行为管理设备的工作原理，我们基本上可以得出结论，是上网行为管理设备发送的伪造报文，导致IPS升级错误。

    我们可以通过跳开上网行为管理设备，直接升级IPS来验证我们分析的结论。

4 故障解决

    IPS在线升级的故障原因确定清楚了，那么我们解决问题的方式也就出来了，主要有以下几种选择：

1，调整上网行为产品的相关检测策略，让上网行为管理设备完全放行IPS地址对互联网的访问；

2，让IPS升级地址跳过上网行为管理设备，直接访问互联网；  

阅读全文>>

标签: 中间设备劫持 RST reset tcpdump IPS

评论(0) 引用(0) 浏览(13283)

Powered by 易隐者 基于emlog 皖ICP备12002343号-1