网通安全事件报告

network

网通安全事件报告


安全监管部在此公布近期CNCNET发生的安全事件，供大家了解网络安全现状和总结规律、积累应对紧急事件的经验。

沈阳城域网用户（铁通）被攻击
事件汇报人          中国网通沈阳分公司运维部 廖承杰
事件发生日期        2002.11.9

事件发生时间        11月14-17日

受影响设备          被攻击用户设备：华为路由器  IP  210.83.31.10   210.83.31.74

                    网通路由设备：  gsr1-lnsy2   IP      

受影响主机平台版本  

受影响软件         

攻击来源            

事件类型            黑客攻击

事件描述            

　　   （ 中国网通沈阳分公司运维部 廖承杰 2002.11.4）

1、   11月9日20：10分左右，我在家中接到鞍山广电投诉，说网络延迟较大。立即上网查看，发现速度已经恢复，经询问用户，用户也证实网速恢复正常。由于历时很短，没有接到其他用户投诉，周一（11月11日）在网管上查看也没有发现9日的流量有任何异常。所以当时判断为用户侧故障或路由的动态收敛造成的瞬间延迟所致；

2、   11月11日15：50分左右，发现ping北京DNS（210.52.149.2)很慢，立即与北京网管取得联系，经询问，北京网管称DNS正常。与此同时接到鞍山广电和苏家屯广电的投诉，现象为网速慢。立即查看城域网路由，未发现异常。随即给东软工程师杨启宏打电话，请求援助。但还未等杨启宏做任何处理，故障现象已经消除。网络恢复正常。历时10分钟左右。事后询问东软杨工故障原因，他回答有可能是网络瞬间有路由收敛所致。当时查看网管，也未发现有流量异常现象。

3、   11月12日11：20分左右，发现网速忽快忽慢，ping北京DNS，网速不稳，快时延迟只有10ms，慢时则达1370ms.立即上报大区并与东软工程师杨启宏取得联系，杨工立即远程登录查看，发现gsr1-lnsy2不能远程登录，但是我在本地可以登录，并发现gsr1-lnsy2的地址仍然在路由表中存在。当时杨工判断为总部侧是否做过路由变化，随即询问总部网管，总部回答没有对沈阳做过任何路由调整，同时他们也通过网管发现沈阳侧有过瞬断现象。本次故障历时20分钟左右。

4、   11月12日晚17：45分，正在为前几次故障查找原因而未明时，发现网速突然变慢，同时二台GSR至北京的二条155流量突然增至饱和，分别达到149M左右。马上给北京网管打电话询问，北京网管已经发现沈阳侧的故障并正在处理，网管值班人员称沈阳被黑客攻击，由于流量过高，北京侧的同事已不能远程登录沈阳的路由，在电话中支持，在被攻击的GSR上加入网络监控策略，但没有收效，未发现攻击源及目标地址，大概在18：30分左右，网络自行恢复正常。

5、   11月13日早9：40分，发现昨晚的故障现象再次出现，立即上报大区及北京网管，北京网管配合查找攻击源。由于前日晚已将网络监控策略写到路由器中，所以一直观察网络流的情况，直到10：25分左右，才从沈阳的路由器中发现被攻击的目标地址210.83.31.10,系省铁通使用的地址。总部网管将该目标地址封掉，故障现象立即消除。故障历时45分左右。

现正与铁通联系以确定此IP地址的使用情况。

（中国网通总公司运维部 许荔 2002.11.14）

接着昨天的攻击事件，今天下午4点再次发生大规模黑客攻击，黑客分别从台湾中华电信、韩国DACOM、韩国电信、新加坡电信、日本KDDI、韩国HANARO以及我们的两条到REACH的国际出口展开对地址210.83.31.74的攻击，造成我们的网络质量下降。在我们在端口上实施了URPF之后，用户改为用真实地址攻击，附件是从REACH 过来的攻击的一些信息。值得一提的，该地址是一台华为路由器，昨天被攻击的对象就是这台路由器，在更换为这个地址之后于今天再次受到攻击。

事件日志（取自GSR1-LNSY2）

11月14日

SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts
PO0/0 211.155.254.19 Gi1/0.1 210.83.31.74 01 0000 0000 271
PO0/0 211.157.223.25 Gi1/0.1 210.83.31.74 01 0000 0000 207
PO0/0 211.108.60.162 Gi1/0.1 210.83.31.74 01 0000 0000 200
PO0/0 210.82.36.229 Gi1/0.1 210.83.31.74 01 0000 0000 177
PO0/0 211.98.24.49 Gi1/0.1 210.83.31.74 01 0000 0000 159
PO0/0 202.97.175.42 Gi1/0.1 210.83.31.74 01 0000 0000 145
PO0/0 61.172.251.114 Gi1/0.1 210.83.31.74 01 0000 0000 132
PO0/0 210.82.89.153 Gi1/0.1 210.83.31.74 01 0000 0000 124
PO0/0 211.99.145.5 Gi1/0.1 210.83.31.74 01 0000 0000 121
PO0/0 211.167.255.97 Gi1/0.1 210.83.31.74 01 0000 0000 119
PO0/0 210.52.44.250 Gi1/0.1 210.83.31.74 01 0000 0000 116
PO0/0 211.99.156.22 Gi1/0.1 210.83.31.74 01 0000 0000 115
PO0/0 210.83.6.11 Gi1/0.1 210.83.31.74 01 0000 0000 114
PO0/0 211.99.140.81 Gi1/0.1 210.83.31.74 01 0000 0000 112
PO0/0 210.83.2.209 Gi1/0.1 210.83.31.74 01 0000 0000 110


11月15日

SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts
PO0/0 211.155.254.19 Gi1/0.1 210.83.31.94 01 0000 0000 264
PO0/0 210.22.202.7 Gi1/0.1 210.83.31.94 01 0000 0000 261
PO0/0 211.156.161.155 Gi1/0.1 210.83.31.94 01 0000 0000 223
PO0/0 210.22.204.20 Gi1/0.1 210.83.31.94 01 0000 0000 188
PO0/0 211.108.60.162 Gi1/0.1 210.83.31.94 01 0000 0000 183
PO0/0 202.110.205.178 Gi1/0.1 210.83.31.94 01 0000 0000 158
PO0/0 210.72.195.25 Gi1/0.1 210.83.31.94 01 0000 0000 138
PO0/0 211.157.223.25 Gi1/0.1 210.83.31.94 01 0000 0000 137
PO0/0 218.24.57.207 Gi1/0.103 210.82.168.66 11 146E 2775 131
PO0/0 211.156.118.158 Gi1/0.1 210.83.29.242 11 146E 07BA 120
PO0/0 210.78.144.6 Gi1/0.1 210.83.31.94 01 0000 0000 117
PO0/0 211.156.168.5 Gi1/0.1 210.83.31.94 01 0000 0000 117
PO0/0 210.77.59.3 Gi1/0.1 210.83.31.94 01 0000 0000 109
PO0/0 210.22.204.74  Gi1/0.1 210.83.31.94 01 0000 0000 108
PO0/0 210.71.187.70 Gi1/0.1 210.83.31.94 01 0000 0000 107
PO0/0 202.96.151.212 Gi1/0.1 210.83.31.94 01 0000 0000 101
PO0/0 211.152.244.10 Gi1/0.1 210.83.31.94 01 0000 0000 101
PO0/0 211.163.115.74 Gi1/0.1 210.83.31.94 01 0000 0000 100
PO0/0 202.96.137.70 Gi1/0.1 210.83.31.94 01 0000 0000 100


11月17日

LC-Slot0>sh ip ca

LC-Slot0>sh ip cache flow

IP packet size distribution (158618 total packets):

   1-32   64   96  128  160  192  224  256  288  320  352  384  416  448  480

   .001 .377 .095 .040 .028 .017 .011 .031 .007 .005 .004 .009 .002 .019 .002

    512  544  576 1024 1536 2048 2560 3072 3584 4096 4608

   .002 .002 .060 .014 .263 .000 .000 .000 .000 .000 .000

IP Flow Switching Cache, 8913408 bytes

  248 active, 130824 inactive, 141644 added

  2421375 ager polls, 0 flow alloc failures

  Active flows timeout in 30 minutes

  Inactive flows timeout in 15 seconds

  last clearing of statistics never

Protocol         Total    Flows   Packets Bytes  Packets Active(Sec) Idle(Sec)

  Flows Sec Flow Pkt Sec Flow  Flow
TCP-Telnet 2  0.0  1  773  0.0 0.0  15.7
TCP-FTP  358 0.0  1  77  0.0  0.0  13.5
TCP-FTPD  1203 0.0 1  869 0.0 2.3 15.3
TCP-WWW  62371 0.0 1  475 0.0  0.3 15.1
TCP-SMTP 218  0.0  1  50  0.0  1.9  13.5
TCP-X  1  0.0  1  50 0.0 0.0  15.0
TCP-BGP 8  0.0  1  371 0.0  0.1 15.4
TCP-NNTP 3  0.0 1  161  0.0 0.0  15.2
TCP-other 46371  0.0 1  307 0.0  0.7  15.3
UDP-DNS 7  0.0  1  65 0.0  0.0 15.2
UDP-Frag 14 0.0  1  697 0.0 0.0  15.3
UDP-other 15012 0.0  1  195 0.0  0.5  15.4
ICMP 15813 0.0 1  1194 0.0 2.4  15.5
IP-other 18 0.0 1  140 0.0  0.0 15.5
Total: 141399 0.0  1  494 0.0  0.7  15.2




安全监管部采取措施

1提供事件分析及技术支持　（中国网通总公司安全监管部 2002.11.14）

这几次的攻击都是很严重的，因为在骨干上发生这种现象对我们网络的影响比较大的，通过昨天处理的过程以及NSA 地分析，目前的攻击主要有这些特点：

n          目标不确定性，从攻击的目的来说，似乎并不是某一台主机，更像是攻击我们的网络

n          攻击的手法比较简单，目前对我们网络造成影响的几次攻击都是DOS或者DDOS

n          攻击的原大部分都是假地址，包括私有地址和冒用公有地址的攻击（URPF不能阻挡这类的攻击）

n          攻击的流量较大，可以阻塞我们的端口增加网络设备的负载

目前针对这些攻击我们只能采取以下手段，以减少攻击的发生和处理的时间

增加防护手段：由于目前的攻击手段各种各样，实际上要想完全挡住DOS 或者 DDOS 是不太可能的，我们只能在不同的地方部署不同的策略（见下文）进行保护，提高一些关键地点设备的性能和接口的带宽。

提高处理速度：完善处理此类事情的处理流程，减少处理的时间，将性能分析系统是否可以提供给大区或者相关人员，在遭到攻击的时候，由于经常出现总部不能访问的或者速度慢的情况，影响了处理的时间，让本地的人员进行支持，或者将查询的结果通知总部，以便尽快处理，总之，我们可以将此类事件的处理细化，在提高效率的前提下合理分工。

2、对攻击源地址进行投诉

通过对日志的整理，我们对主要攻击源地址进行了投诉。可看出来源比较分散，估计都是被利用的跳板机。其中包括几个属于网通的用户。

11月14日
攻击目标：210.83.31.74
  

SrcIPaddress
IP所属用户
联系方式

211.155.254.19
北京互联通公司
hui_zh@sina.com ；dsl327@btamail.net.cn

211.157.223.25
北京市崇文区东打磨厂街7号 宝鼎中心
noc@net263.com

211.108.60.162
Korea Network Information Center
hostmaster@nic.or.kr

210.82.36.229
北京国都信业实业集团
hrydsy@bta.mail.net.cn

211.98.24.49
中国铁通
noc@railcomnet.com

202.97.175.42
锦州数据局
abuse@online.ln.cn

61.172.251.114
上海盛大网络发展有限公司
wanglin@shaidc.com

210.82.89.153
北京城域网用户
　

211.99.145.5
北京城域网用户：观景园大厦（音译）
zydjj@263.net

211.167.255.97
北京电力局
wjc1218@btamail.net.cn

210.52.44.250
华北大区用户：石家庄管委会
　

211.99.156.22
北京五矿大厦
zyddj@263.net

210.83.6.11
西安用户：西安ZHICHENG-MANSION
　

211.99.140.81
北京：Tianshui Business Center
zydjj@263.net

210.83.2.209
西安用户：西安QINTONG-MANSION
　

11月15日
攻击目标：210.83.31.94
  

SrcIPaddress
IP所属用户
联系方式

211.155.254.19
北京互联通公司
hui_zh@sina.com

210.22.202.7
网通湖北宜昌分公司
　

211.156.161.155
广东恒敦通信技术开发有限公司
johnny.chung@etns.net

210.22.204.20
网通湖北荆州分公司
　

211.108.60.162
Korea Network Information Center
hostmaster@nic.or.kr

202.110.205.178
山东数据局
hostmaster@ns.chinanet.cn.net

210.72.195.25
中国航天工业总公司一院纪委
fangguangzu@httx.com.cn

211.157.223.25
北京市崇文区东打磨厂街7号 宝鼎中心
noc@net263.com

210.78.144.67
263
noc@net263.com

211.156.168.5
北京英克科技有限公司
shirley.yang@etns.net


目前已有回复的是：

1、  263

中国网通安全监管部 网络管理员:您好！

我们263网络集团已经通知了下属城域网的用户进行调查，我们相信此事会尽快得到解决。                       263网络技术中心noc@net263.com

211.157.223.25  北京市崇文区东打磨厂街7号 宝鼎中心

210.78.144.67   263

2、   湖北分公司

210.22.204.20  网通湖北荆州分公司

IP  210.22.204.20是兄弟网吧，地址：荆州东印厂对面门面8号,李维珍 电话:8993817

   我们已和网吧取得了联系，并于11月20日下午和网吧维护人员检查了所有电脑，未发现异常，初步判断是病毒或者木马程序，被远程控制，据网吧老板说前段时间主机经常死机。我们要求维护人员将机器系统重装，今天早上询问已全部重装。

2002-11-21 陆杰  中国网通荆州分公司

210.22.202.7   网通湖北宜昌分公司

IP  210.22.202.7经查，是下面一个网吧的地址。网吧名称：宏达网吧 联系人：李建军 电话：0717-8624057

   我已经跟他联系过，要网吧网管注意此事。

2002-11-21 高波　t-gaobo@china-netcom.com



经验积累



1、 东大提供的路由设备安全监控策略  （请IP运维提供）

2、 CNC骨干网网络安全策略部署方案（安全监管部）



针对当前网内频繁发生的黑客攻击事件，建议在网内部署一些能够提高网络安全性和稳定性的路由策略。

一、提高路由器安全性配置
建议在所有的网络设备上增加如下配置，以提高路由设备本身的安全性能
1、CISCO IOS支持许多UNIX的协议，而事实上在网络中是不需要这些协议的。因为这些协议在缺省状态下是开启的，因此我们要在全局状态下将它们禁止掉，除非我们对此有特殊的需要。
no service finger
no service pad
no service udp-small-servers
no service tcp-small-servers
no ip bootp server
2、在接口状态下的安全配置：
no ip redirects
no ip directed-broadcast
no ip proxy-arp
3、增加相关的日志记录功能：
router isis cnc-core

log-adjacency-changes
router bgp 9929
bgp log-neighbor-changes

二、在所有的出口路由器上对输入的路由进行过滤，主要是根据draft-manning-dsua-08.txt对IPV4地址空间里一些有特殊用途的 prefix实施过滤。需要实施过滤的地址包括：
    0.0.0.0/8        default and broadcast

  127.0.0.0/8   host loopback

  192.0.2.0/24  TEST-NET for documentation

  10.0.0.0/8    RFC 1918 private addresses

  172.16.0.0/12 RFC 1918 private addresses

  192.168.0.0/16 RFC 1918 private addresses

  169.254.0.0/16  End node auto-config for DHCP

同时，不接受缺省路由和掩码长度大于24位的路由。
ip prefix-list rfc1918-dsua deny 0.0.0.0/0

ip prefix-list rfc1918-dsua deny 0.0.0.0/8 le 32

ip prefix-list rfc1918-dsua deny 10.0.0.0/8 le 32

ip prefix-list rfc1918-dsua deny 127.0.0.0/8 le 32

ip prefix-list rfc1918-dsua deny 169.254.0.0/16 le 32

ip prefix-list rfc1918-dsua deny 172.16.0.0/12 le 32

ip prefix-list rfc1918-dsua deny 192.0.2.0.0/24 le 32

ip prefix-list rfc1918-dsua deny 192.168.0.0/16 le 32

ip prefix-list rfc1918-dsua deny 224.0.0.0/3 le 32

ip prefix-list rfc1918-dsua deny 0.0.0.0/0 ge 25

ip prefix-list rfc1918-dsua permit 0.0.0.0/0 le 32



router bgp 9920

neighbor X.X.X.X prefix-list rfc1918-dsua in



三、在骨干网内大规模启用uRPF.
1、实施uRPF的总体原则，是既要在骨干网接入点实施以阻止CNC用户发起的攻击，又要在出口处实施以阻止外部网络对CNC网络的攻击。考虑到不同Engine 系列板卡对于PPS的处理能力有很大的差异，同时经过对我们当前出口流量的分析，决定在骨干网国际出口路由器的边缘部署uRPF,而在电信出口路由器上则不能启用uRPF。在具体实施之前，建议将几个国际出口路由器的版本升级到合适的版本，CISCO NSA推荐版本是12.0(21)S3。该版本对于Engine0和Engine2板卡上的uRPF 性能都能够提供很好的支持。在部署uRPF之前，需要检查在网络出口的地方是否都已经将RFC1918定义的地址段做了过滤，以确保在我们的网内没有这些地址的存在。
2、uRPF有三种方式，strict方式、ACL方式和loose方式。在接入路由器上实施时，对于通过单链路接入CNC网络的用户，建议采用strict方式；对于通过多条链路接入到CNC网络的用户（如长宽、重宽等），可以采用ACL方式和loose方式，建议采用ACL方式（Note：Engine2板卡不支持ACL方式的uRPF）。在出口路由器上实施时，在几个国际出口处采用loose方式，在NAP点和CERNET互连点采用loose方式，在PEER互连点采用strict方式。
3、三种uRPF方式的配置实例如下：
●strict方式：(注意在应用uRPF之前先要确保路由器上开启CEF或DCEF)
interface pos1/0
ip verify unicast reverse-path
这个功能检查每一个经过路由器的数据包。在路由器的CEF表该数据包所到达网络接口的所有路由项中，如果没有该数据包源IP地址的路由，路由器将丢弃该数据包。
●ACL方式：
interface pos1/0
ip verify unicast reverse-path 190

access-list 190 permit ip {customer network} {customer network mask} any
access-list 190 deny ip any any [log]
这个功能检查每一个经过路由器的数据包的源地址，若是不符合ACL的，路由器将丢弃该数据包。

● Loose方式

interface pos 1/0
ip ver unicast source reachable-via any
这个功能检查每一个经过路由器的数据包，在路由器的路由表中若没有该数据包源IP地址的路由，路由器将丢弃该数据包。

4、对于突发的黑客攻击事件，需要针对某些特定的IP地址进行封堵。针对攻击的不同类型，可以将攻击分为网内发起的攻击和来自网外的攻击。以往我们采取的做法主要是针对目的地址的封堵，在GSR1-HZ1路由器上将需要封堵的地址静态指向NULL0，并将静态路由注入到ISIS路由表里，这种封堵方法只适用于目的地是集中的某一个或某几个IP地址的攻击。这种实现方式的缺点有四点，第一会造成网内IGP表的规模不断增大，不利于网络的发展及稳定性，第二只能实现对目的地的封堵而不能实现对源的封堵，第三对于来自外部的黑客攻击，这种封堵方式即相当于将攻击的流量都引到GSR1-HZ1上然后再将数据包丢掉，这样做无疑增加了网内的流量以及数据包途径的路由器的负担，第四对于使用伪造假地址发起的攻击，我们无法正确定位出攻击的源。当我们在网内接入点大面积部署了strict 方式的uRPF之后，首先就抵制了使用伪地址的攻击，这样对于网内发起的攻击，我们可以通过真实的IP地址直接找到发起攻击的用户，可以及时采取手段加以制止。对于来自网外的攻击，今后也可以采取新的方式来实现地址封堵，即选取一台专门用来封地址的路由器（可以选用RTR6-SZ1），该路由器上运行BGP，但是可以没有全球路由表。该路由器的版本建议采用12.0(21)S5,基本配置建议如下：

ip bgp-community new-format

router bgp 65000

no synchronization

bgp log-neighbor-changes

neighbor CNC peer-group

neighbor CNC remote-as 9929

neighbor CNC prefix-list denyroute in

neighbor CNC update-source Loopback0

neighbor CNC send-community

neighbor CNC version 4

neighbor x.x.x.x peer-group CNC



redistribute static route-map set-next-hop

route-map set-next-hop permit 10

set ip next-hop 192.168.0.1

set community no-export



ip prefix-list denyroute deny 0.0.0.0/0 le 32

ip route 192.168.0.1 255.255.255.255 null0



当有黑客攻击事件发生时，首先判断是固定源地址的攻击还是固定目的地址的攻击，然后只需在这台指定的路由器上，增加针对攻击的源地址或目的地址的静态路由指向NULL0即可。这样做的好处，若是固定源地址的攻击，可以尽量将攻击的流量在边缘路由器上就丢掉，能够同时实现针对源和针对目的的封堵，而且不再将NULL0地址放入IGP表，也符合我们网络进一步优化和发展的大方向。当然，这只是我们从技术角度采取的对付黑客攻击的方法，总根本上我们还需要找到攻击的源然后通过安全部门帮助协调解决。

四、针对DDOS攻击，建议在出口使用CAR（Control Access Rate）限制ICMP数据包流量速率.(注意需要在路由器上事先打开CEF)

access-list 102 permit icmp any any echo
access-list 102 permit icmp any any echo-reply

interface <interface> <interface #>
rate-limit input access-group 102 256000 8000 8000 conform-action transmit exceed-action drop
使用CAR命令对ICMP包进行流量限制时，建议限到端口正常流量时的2%到3%。
可以使用show interface <interface> <interface #> rate-limit命令来查看该命令的效果，当有DDOS攻击发生时，可以看到exceeded XXXXX packets, XXXXX bytes; action: drop指示有大量的ICMP包被DROP。
五、当在一台骨干核心路由器上，同时有高速接口和低速接口存在时时，当从高速接口向低速接口有攻击发起时，尤其是当出现大量小包攻击的时候，我们会看到在高带宽的链路上存在大量的ignore,有时还会有ISIS neighbor down的现象发生。这是因为当高速接口将数据包发送至output hold queue后，低速接口的处理能力无法满足其要求，尤其是当低速板卡为engine0或engine1板卡的时候，当他们的 buffer用尽后，他们会发送消息给高速接口的LC通知他们不要再向自己发送数据包了，于是高速接口板卡就会使用自己的buffer将数据包缓存在自己的ToFab queues中。我们可以用execute-on slot <slot#> show controllers tofab queue命令来查看高速输入接口的ToFab queues。当ToFab queues也满时，就会产生丢包，若ISIS HELLO包也被丢掉后，就会导致ISIS neighbor down,从而引起SPF的重算，影响整个网络的稳定性。
建议使用 tx-queue-limit命令，对低速板卡所能够使用的buffer做一限制，防止其用尽所有的FrFab buffers后，再去借用高速板卡的ToFab buffers,这样做的好处，是尽可能将黑客攻击带来的影响推向网络的边缘，从而保证整个骨干的稳定性。建议在GSR4-SH1所有与PEER互连的接口上配置该命令，以牺牲一些网络性能为代价来保证整个骨干的安全性。对于GSR1-BJ1等其他有高速和低速接口共存的路由器，建议平时先不配置该命令，当出现从高速接口向低速接口的黑客攻击时，再在低速接口上配置该命令。

六、为了保证当黑客攻击事件发生后网络能够尽快的恢复，即尽量减少BGP路由的收敛时间，建议增加如下配置：(需在所有运行BGP的路由器上增加)
1、在每个BGP互连的接口上，增加hold-queue 1500命令，将接口的hold-queue由默认的75增加到1500。在做此配置之前需要先检查板卡的内存，确保其free memory至少为20M。

2、增加以下有关TCP的配置，增强BGP的收敛性能。
ip tcp selective-ack

ip tcp mss 1460

ip tcp window-size 65535

ip tcp queuemax 50

ip tcp path-mtu-discovery

3、在GSR上，增加ip cef linecard ipc memory 10000命令，提高download FIB的速度