Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2179795
  • 博文数量: 230
  • 博客积分: 9346
  • 博客等级: 中将
  • 技术积分: 3418
  • 用 户 组: 普通用户
  • 注册时间: 2006-01-26 01:58
文章分类

全部博文(230)

文章存档

2015年(30)

2014年(7)

2013年(12)

2012年(2)

2011年(3)

2010年(42)

2009年(9)

2008年(15)

2007年(74)

2006年(36)

分类: LINUX

2013-01-02 19:30:34

好久没写博文了,今天心血来潮,与大家分享一下,欢迎大家随时和我联系!

cu.platinum & gmail.com


现象

一次偶然的机会,发现一台服务器出现了极不正常的情况:CPU 消耗巨大

通过用 top 观察,发现 snmpd 进程持续走高

top - 16:51:31 up 546 days,  7:33,  1 user,  load average: 2.28, 1.72, 1.39
Tasks: 108 total,   4 running, 104 sleeping,   0 stopped,   0 zombie
Cpu0  : 32.8% us,  3.3% sy,  0.0% ni, 62.3% id,  0.7% wa,  0.3% hi,  0.7% si
Cpu1  : 70.0% us,  2.0% sy,  0.0% ni, 26.4% id,  0.0% wa,  0.3% hi,  1.3% si
Mem:   4149884k total,  3988352k used,   161532k free,   100788k buffers
Swap:  2048248k total,     8916k used,  2039332k free,  2231908k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
11272 root      20   0 12320 6012 2340 R 98.1  0.1 139:16.01 snmpd
29036 root      20   0  949m 783m 2660 S  5.0 19.3   2201:41 top
 3891 root      20   0  406m 405m  428 R  0.3 10.0   0:00.46 kswap0
14332 root      20   0 55948  50m 2992 S  0.3  1.3 811:43.05 kswap1
14907 root      20   0 26600  24m 2508 S  0.3  0.6  85:10.33 pdflush
    1 root      20   0  1684  564  476 S  0.0  0.0   6:32.74 init
    2 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 kthread

抓包

重启 snmpd 进程,在正常了几分钟后突然又重现异常,此时感觉是有特殊数据包进来造成的。
为了验证猜测,对 UDP/161 端口进行了抓包,发现了些端倪。

[root@platinum-PT ~]# tcpdump -ieth0 -nnnvvv udp and port 161
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
16:50:07.035719 IP (tos 0x0, ttl  64, id 32494, offset 0, flags [+], proto 17, length: 1500) platinum-PT > 209.59.150.117.161:  { SNMPv2c { GetResponse(35) R=20039  .1.3.6.1.2.1.1.1.0="Linux C" } }
16:50:12.035509 IP (tos 0x16,ECT(0), ttl  49, id 30047, offset 0, flags [none], proto 17, length: 65) 209.59.150.117.161 > platinum-PT: [udp sum ok]  { SNMPv2c { GetBulk(22) R=20039  N=0 M=2250 .1.3.6.1 } }
16:50:12.046640 IP (tos 0x16,ECT(0), ttl  49, id 30078, offset 0, flags [none], proto 17, length: 65) 209.59.150.117.161 > platinum-PT: [udp sum ok]  { SNMPv2c { GetBulk(22) R=20039  N=0 M=2250 .1.3.6.1 } }
16:50:12.058869 IP (tos 0x16,ECT(0), ttl  49, id 30075, offset 0, flags [none], proto 17, length: 65) 209.59.150.117.161 > platinum-PT: [udp sum ok]  { SNMPv2c { GetBulk(22) R=20039  N=0 M=2250 .1.3.6.1 } }
16:50:12.063363 IP (tos 0x16,ECT(0), ttl  49, id 30039, offset 0, flags [none], proto 17, length: 65) 209.59.150.117.161 > platinum-PT: [udp sum ok]  { SNMPv2c { GetBulk(22) R=20039  N=0 M=2250 .1.3.6.1 } }
16:50:12.074612 IP (tos 0x16,ECT(0), ttl  49, id 30095, offset 0, flags [none], proto 17, length: 65) 209.59.150.117.161 > platinum-PT: [udp sum ok]  { SNMPv2c { GetBulk(22) R=20039  N=0 M=2250 .1.3.6.1 } }
16:50:12.075511 IP (tos 0x16,ECT(0), ttl  49, id 30092, offset 0, flags [none], proto 17, length: 65) 209.59.150.117.161 > platinum-PT: [udp sum ok]  { SNMPv2c { GetBulk(22) R=20039  N=0 M=2250 .1.3.6.1 } }
16:50:12.080521 IP (tos 0x16,ECT(0), ttl  49, id 30015, offset 0, flags [none], proto 17, length: 65) 209.59.150.117.161 > platinum-PT: [udp sum ok]  { SNMPv2c { GetBulk(22) R=20039  N=0 M=2250 .1.3.6.1 } }
16:50:12.086440 IP (tos 0x16,ECT(0), ttl  49, id 30031, offset 0, flags [none], proto 17, length: 65) 209.59.150.117.161 > platinum-PT: [udp sum ok]  { SNMPv2c { GetBulk(22) R=20039  N=0 M=2250 .1.3.6.1 } }
16:50:12.089447 IP (tos 0x16,ECT(0), ttl  49, id 30001, offset 0, flags [none], proto 17, length: 65) 209.59.150.117.161 > platinum-PT: [udp sum ok]  { SNMPv2c { GetBulk(22) R=20039  N=0 M=2250 .1.3.6.1 } }
16:50:12.137224 IP (tos 0x16,ECT(0), ttl  49, id 30034, offset 0, flags [none], proto 17, length: 65) 209.59.150.117.161 > platinum-PT: [udp sum ok]  { SNMPv2c { GetBulk(22) R=20039  N=0 M=2250 .1.3.6.1 } }
16:50:12.179586 IP (tos 0x16,ECT(0), ttl  49, id 30044, offset 0, flags [none], proto 17, length: 65) 209.59.150.117.161 > platinum-PT: [udp sum ok]  { SNMPv2c { GetBulk(22) R=20039  N=0 M=2250 .1.3.6.1 } }
16:50:14.799292 IP (tos 0x0, ttl  64, id 32495, offset 0, flags [+], proto 17, length: 1500) platinum-PT > 209.59.150.117.161:  { SNMPv2c { GetResponse(35) R=20039  .1.3.6.1.2.1.1.1.0="Linux C" } }
16:50:23.250338 IP (tos 0x0, ttl  64, id 32496, offset 0, flags [+], proto 17, length: 1500) platinum-PT > 209.59.150.117.161:  { SNMPv2c { GetResponse(35) R=20039  .1.3.6.1.2.1.1.1.0="Linux C" } }
16:50:35.448431 IP (tos 0x0, ttl  64, id 32497, offset 0, flags [+], proto 17, length: 1500) platinum-PT > 209.59.150.117.161:  { SNMPv2c { GetResponse(35) R=20039  .1.3.6.1.2.1.1.1.0="Linux C" } 

通过抓包发现,原来真的有攻击,从抓包看,攻击是突发性质的,当有攻击时:
频率:≈ 10Hz
周期:≈ 0.1s
类型:请求 snmpd 的根信息 "Linux C"
原理:通过请求比较高级别的根内容,使系统处于高负载状态;由于频率较高,高负载状态很难消除。
恶意性:为了突破某些无状态防火墙,来源端口 sport 特意也是用了与 snmpd 服务相同的 UDP/161,很阴险。

规则检查

不过奇怪的问题来了,我的防火墙是基于状态检测的,可以轻易区分进来的报文是主动请求进来的,还是我主动发出后的回包。
既然这样,为何 snmpd 报文还是会被系统收到并处理呢?是不是 iptables 规则使用存在问题?

经查看,规则很简单,大体如下:

iptables -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p udp --dport 161 -s IP1 -j ACCEPT
iptables -A INPUT -p udp --dport 161 -s IP2 -j ACCEPT
iptables -A INPUT -p udp --dport 161 -s IP3 -j ACCEPT
iptables -A INPUT -j DROP

通过观察,未发现异常,针对 snmpd 报文,系统只允许了 3 个特殊 IP 访问,那么就奇怪了,这个攻击报文是怎么进来的呢?

conntrack 特性分析:UDP 与 TCP 的差异

众所周知,iptables 只是 userspace 的 controller,真正的主体是 netfilter,而 conntrack 则是 netfilter 的一个重要组成部分。
conntrack 的核心价值,就是为 Linux 实现了基于状态的防火墙。

在 Linux 中,当启用了 conntrack 后,即使是 UDP 报文,也是有“新建连接”(NEW)和“已连接”(ESTABLISHED)概念的。

不过与 TCP 不同的是,TCP 是有三次握手的,通过分析三次握手时数据报文头部的合规性可以知道当前数据是否有效。
但是,UDP 则不同,在 Linux 中,只有“去”和“回”两个概念,当系统第一次看到 UDP 包,视为 NEW,看到该包的回包后,视为 ESTABLISHED。

推理

知道了这个,大概可以猜出问题所在了,一定和 conntrack 有关。
猜测失控过程:
1、系统未启动 conntrack 时,已经有攻击报文 request 进来了
2、当系统启动 conntrack 机制时,恰好有系统回 response 包,被系统 conntrack 当做了主动发出数据,是 NEW 状态
3、系统的 iptables 规则最后有阻断功能,这个包虽然被拦掉
   但后续攻击报文用同样的 SIP/SPORT 访问同样的 DIP/DPORT,导致 hash 后认为是同一条连接
   此次的攻击报文被无当做上一次 NEW 状态的回包,此次该连接变成了 ESTABLISHED 状态
4、今后所有 SIP/SPORT 到 DIP/DPORT 的数据均通行无阻,导致最开始看到的场面

验证

为了证明推理是正确的,刻意写了一个 shell,在第一行 -m state --state RELATED,ESTABLISHED -j ACCEPT 后加入 sleep 以增加重现概率

实验表明,推理完全正确,UDP 攻击报文的回包被当做了 NEW,而真正的攻击则成了 ESTABLISHED。
第一句的位置,也是导致问题出现的主要原因。

尝试解决

为了杜绝这种情况的发生,思考,将 state 匹配放到最后是否可行?
答案是“不可以”,因为一样可能发生前面说的时间差导致的状态误判情况发生。
怎样做才是最稳妥的办法呢?

想了个办法:
1、先 service iptables stop
2、先写第一行规则,无条件 -j DROP 任何东西
3、写其他规则,该怎么写怎么写
4、当规则生效后等一段时间(保证此时间超过 snmpd 报文打进来后的系统响应时间),再删掉第一行规则,让数据涌进来(像开闸放水)

可惜,通过实测,攻击报文仍然可以进来,这个太奇葩了!

/etc/init.d/iptables stop 行为分析

看到上述疑点,不得不怀疑 iptables 脚本中 stop 功能的实现了。
理论上 iptables 在 stop 的时候,不仅会清除所有规则,也会删掉所有 iptables 所用到的模块,这其中也包含了 conntrack。
推理:如果 iptables 的 stop 功能工作异常,那么就无法正确卸载 conntrack,那么上述方法就无济于事了。

stop() {
    # Do not stop if iptables module is not loaded.
    [ -e "$PROC_IPTABLES_NAMES" ] || return 1

    flush_n_delete
    set_policy ACCEPT

    if [ "x$IPTABLES_MODULES_UNLOAD" = "xyes" ]; then
        echo -n $"Unloading $IPTABLES modules: "
        ret=0
        rmmod_r ${IPV}_tables
        let ret+=$?;
        rmmod_r ${IPV}_conntrack
        let ret+=$?;
        [ $ret -eq 0 ] && success || failure
        echo
    fi

    rm -f $VAR_SUBSYS_IPTABLES
    return $ret
}

红色部分是清除 conntrack 的关键语句。继续跟踪:

IPTABLES=iptables
IPV=${IPTABLES%tables} # ip for ipv4 | ip6 for ipv6

脚本最初有上述定义,也就是说,最后 IPV 的取值是 "ip",卸载模块时卸载的是 ip_conntrack。

手动验证一下:
[root@platinum-PT ~]# modprobe ip_conntrack
[root@platinum-PT ~]# iptables -A INPUT
[root@platinum-PT ~]# /etc/init.d/iptables stop
Flushing firewall rules:                                   [  OK  ]
Setting chains to policy ACCEPT: filter                    [  OK  ]
Unloading iptables modules:                                [  OK  ]
[root@platinum-PT ~]# lsmod |grep conntrack
nf_conntrack_ipv4      22028  0
nf_conntrack           67784  1 nf_conntrack_ipv4
[root@platinum-PT ~]#

通过观察发现,conntrack 确实没有被卸载,但注意到了一点,模块名字不是 ip_conntrack 而是 nf_conntrack

似乎明白了,验证一下:
[root@platinum-PT ~]# cat /etc/redhat-release
Red Hat Enterprise Linux AS release 4 (Nahant Update 2)
[root@platinum-PT ~]# uname -r
2.6.24.4-7
[root@platinum-PT ~]#

知道原因了:
  • 系统是 RHEL 4U2,默认内核应该是 2.6.9,那时的 netfilter 使用的 conntrack 模块叫 ip_conntrack
  • 系统的当前内核是 2.6.24.4,此时的 netfilter 所使用的 conntrack 模块叫 nf_conntrack 和 nf_conntrack_ipv4
  • 由于 RHEL 4U2 的 /etc/init.d/iptables 脚本是为 2.6.9 内核写的,因此在 stop 时不能正确卸载 2.6.24.4 内核的 conntrack

卸载 conntrack 解决方案

修改
        rmmod_r ${IPV}_conntrack
改为
        rmmod_r nf_conntrack

因为是定制系统,未做详细的判断和动态自适应等工作。

总结

  • 特殊时机生效的 ACL 导致 conntrack 误认为攻击报文的回包是 NEW
  • 攻击报文恶意使用固定 sport,使 conntrack 误认为是同一个 connection
  • iptables 规则的逻辑问题致使穿透攻击有可能发生(虽然是小概率事件)
  • System script 与 kernel 的不匹配导致不能正确卸载 conntrack,使问题依然存在
阅读(13116) | 评论(2) | 转发(10) |
给主人留下些什么吧!~~

flyzzy2013-03-06 17:25:01

学习了,这个问题彻底解决了吗?

ztsda2013-02-26 23:32:15

人缘网 http://www.renyuanw.com