（D）DoS攻击后stream量积压？

大约25小时前，我从UptimeRobot（uptimerobot.com）收到一封电子邮件，告诉我，我的网站已经closures了。

我跑到我的服务器机房，在那里我的TP-Link路由器完全没有响应（甚至从局域网侧），路由器上的交通信号灯闪烁着不快的速度等。我收到一条“朋友”的消息，有人知道他是一个白痴，走上了一个聊天频道，告诉大家要攻击我。

在经过17个小时的stream量攻击之后（每秒大约15000个数据包），我将networking移动到一个新的WAN IP，这显然阻止了这个攻击。 据我所知，那些不愉快的人仍然在攻击旧知识产权。 我为这个地址分配给谁而感到不好。

无论如何，在我切换IP之后，路由器上的红绿灯仍然闪烁，但仍然没有响应。 我给了它和调制解调器都硬重启; 在他们回来后，红绿灯已经减慢到正常速度，路由器现在响应。

• logging时限制超过
• 更改ssh端口后的Fail2ban设置
• Windows安全日志中意外的匿名login
• “networking发送”命令到微软服务器2008 r2
• 当使用NOPASSWD时，sudo仍然要求input密码

问题是，networking仍然感觉像是在受到攻击 – 每当我ping到google.com（ 显然是 up），我都会得到大约50％的数据包丢失，往返时间大约需要100ms – 与正常的30ms左右相比。

我已经重新启动了路由器和调制解调器几次，以为可能它们仍然受到来自攻击stream量的“堵塞”。 但是这被certificate是不成功的。 局域网本身就很好 – 我在不同的节点之间得到0％的数据包丢失，延迟低至0.051毫秒，所以我推断内部networking没有任何东西可以引起问题。

有没有人知道这里发生了什么？ 有可能是我们的ISPpipe道完全积压与攻击发送的stream量？ 这对我来说没有任何意义，只是想知道有没有人经历过这样的事情。 提前致谢。

编辑：

以下是从外部pingnetworking后的一些输出，以防有人感兴趣：

（IP被省略了，因为在那次攻击之后我是偏执狂）

PING xxxx (xxxx): 56 data bytes 64 bytes from xxxx: icmp_seq=0 ttl=59 time=47.797 ms 64 bytes from xxxx: icmp_seq=1 ttl=59 time=47.103 ms 64 bytes from xxxx: icmp_seq=2 ttl=59 time=41.792 ms 64 bytes from xxxx: icmp_seq=3 ttl=59 time=51.739 ms Request timeout for icmp_seq 4 Request timeout for icmp_seq 5 Request timeout for icmp_seq 6 Request timeout for icmp_seq 7 64 bytes from xxxx: icmp_seq=8 ttl=59 time=43.218 ms Request timeout for icmp_seq 9 64 bytes from xxxx: icmp_seq=10 ttl=59 time=45.034 ms 64 bytes from xxxx: icmp_seq=11 ttl=59 time=42.263 ms Request timeout for icmp_seq 12 64 bytes from xxxx: icmp_seq=13 ttl=59 time=46.498 ms Request timeout for icmp_seq 14 Request timeout for icmp_seq 15 Request timeout for icmp_seq 16 64 bytes from xxxx: icmp_seq=17 ttl=59 time=43.183 ms ^C --- xxxx ping statistics --- 18 packets transmitted, 9 packets received, 50.0% packet loss round-trip min/avg/max/stddev = 41.792/45.403/51.739/3.031 ms 

这是来自一个地理上靠近networking的位置，并且通常在25ms左右具有0％的分组丢失。 再次感谢您的帮助。

这是一个跟踪路由，它可能比上面的ping输出更多的信息：

 traceroute to xxxx (xxxx), 64 hops max, 52 byte packets 1 10.0.0.1 (10.0.0.1) 4.767 ms 4.178 ms 4.195 ms 2 7.38.4.1 (7.38.4.1) 11.357 ms 18.649 ms 14.658 ms 3 69.63.243.209 (69.63.243.209) 15.616 ms 32.639 ms 16.381 ms 4 69.63.249.85 (69.63.249.85) 26.902 ms 13.912 ms 15.729 ms 5 67.231.220.182 (67.231.220.182) 26.328 ms 27.733 ms 15.328 ms 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * ^C 

看起来包裹在67.231.220.182之后被丢弃了，根据ARIN的WHOIS是在Mt.的一个罗杰斯开关驻地。 令人愉快 – 这应该是我和我想要达到的networking之间的最后一跳。 这使我相信，这不是我的ISP的问题，所以我不认为我的pipe道是问题。