我受到攻击还是愚蠢?


11

我使用带有多个OpenVZ容器的Debian Squeeze运行服务器。这些容器主要运行Squeeze,一些运行Lenny,有些已经更新为Wheezy。主机除了iptables和DHCP之外没有做其他事情。文件服务器,代理,邮件服务器,Kerberos,LDAP等都放入容器中。该系统运行稳定多年,除了一年多的一些防火墙规则外,没有任何重大变化。

2天前,系统突然崩溃了。我有很多问题要重新提出来。起初它不会让我通过ssh登录。root登录被“您不存在。走开!' 本地登录很好。一段时间后,ssh再次起作用。碰巧的是,我没有重复使用bash历史记录中的行,而是键入了一个新命令,该命令经过三遍检查与该行相同,该行之前不起作用,但在崩溃之前起作用。

然后系统开始运行,但是在大多数协议上的网络流量在SYN ACK之后被阻止。DNS,Telnet和SSH都不错,但其余的一团糟。在黑暗中钓鱼几个小时并重新加载防火墙几次后,突然一切恢复正常。我在日志中找不到任何可疑的东西-但我不是法医专家。

今天,由于容器配额的原因,文件服务器的nscd不再使用套接字来与LDAP联系。以前从未发生过的事情。我还看到了smbd声称有很多(> 30个)套接字。

/ var / log / messages看起来与syslog完全相同。/var/log/kern.log具有有关崩溃原因的以下附加信息:

/var/log/kern.log:2950:Sep 19 10:46:57 asgard kernel: [6529441.320086] INFO: task sendmail:32181 blocked for more than 120 seconds.
/var/log/kern.log:2982:Sep 19 10:48:57 asgard kernel: [6529561.324525] INFO: task kdmflush:1932 blocked for more than 120 seconds.
/var/log/kern.log:3005:Sep 19 10:48:57 asgard kernel: [6529561.324694] INFO: task xfssyncd:10162 blocked for more than 120 seconds.
/var/log/kern.log:3027:Sep 19 10:48:57 asgard kernel: [6529561.324934] INFO: task postgres:16827 blocked for more than 120 seconds.
/var/log/kern.log:3060:Sep 19 10:49:51 asgard kernel: [6529561.325129] INFO: task imapd:31749 blocked for more than 120 seconds.
/var/log/kern.log:3084:Sep 19 10:49:51 asgard kernel: [6529561.325248] INFO: task cleanup:32194 blocked for more than 120 seconds.
/var/log/kern.log:3106:Sep 19 10:50:57 asgard kernel: [6529681.324028] INFO: task flush-253:3:3216 blocked for more than 120 seconds.
/var/log/kern.log:3142:Sep 19 10:50:57 asgard kernel: [6529681.324224] INFO: task kjournald:6859 blocked for more than 120 seconds.
/var/log/kern.log:3166:Sep 19 10:50:57 asgard kernel: [6529681.324366] INFO: task syslogd:11720 blocked for more than 120 seconds.
/var/log/kern.log:3198:Sep 19 10:50:57 asgard kernel: [6529681.324574] INFO: task postgres:16827 blocked for more than 120 seconds.
/var/log/kern.log:7152:Sep 19 19:29:41 asgard kernel: [ 1440.617090] INFO: task sendmail:11892 blocked for more than 120 seconds.

最终的“ sendmail”崩溃是在重新启动计算机之后。从那以后,不再发生此类事件。“ imapd”和“ postgres”肯定在不同的容器中运行。

好吧,我看不到任何吸烟枪,但我可能只是瞎子。如果没有充分的理由,从已知/假定的良好备份设置系统会使我很难尝试。

我将不胜感激任何建议接下来要检查什么。

谢谢你的帮助。

更新:投入更多的精力来寻找崩溃的前兆,我在syslog中发现了以下内容:

Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (10490->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (17442->8232)
Sep 19 10:11:02 asgard ntop[7965]:   **WARNING** packet truncated (11650->8232)
Sep 19 10:11:02 asgard ntop[7965]:   **WARNING** packet truncated (10202->8232)
Sep 19 10:11:29 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:13:27 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:20:33 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)

我知道这被认为是不重要的,但这似乎是罕见的事件。数据包截断仅在第二次崩溃的那一天存在。在所有可用的日志文件中没有其他地方。

Answers:


2

这看起来像DoS,最有可能源自网络或受损容器之一的内部。

我将调查vmstat,每5秒连续运行一次:vmstat 5并记下消耗资源的位置。您还可以使用屏幕并在单独的窗口中运行vmstat 60(每分钟)-这样,当长时间出现峰值时,您就可以注意到它们。

在这种情况下,高/尖峰的系统CPU(sy),高上下文切换速率(cs)和高IO(它同时显示网络和磁盘)将指示DoS:

$ vmstat 5
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0   9584   6820 132432  23256    1    1   136    12    1    1 83  1 15  0  0
 0  0   9584   6696 132432  23256    0    0     0     0   20   32  0  0 99  0  1

同时监视主机上的网络流量,我建议使用ntop,即:

$ nload -t 10000 -u H eth0


0

也许您没有任何文件系统错误,但是我敢肯定,您会在日志中看到该警告,因为您有许多处于D状态的进程(正在等待I / O),并且内核正在通知您漫长的等待。


我想情况就是这样。但为什么?在正常情况下,没有处于D状态的进程。如果实际上网络中断,则可以解释这一点。但是为什么只对某些服务下降呢?为什么这种情况在重启后仍然存在?又为什么又出现了?
Lars Hanke 2013年

0

该错误表明您的进程正在等待太长时间(120秒)以访问磁盘。在磁盘非常繁忙而无法响应进程的高度拥挤的服务器上会发生这种情况。

您可以通过检查vmstat下的“等待”来确保。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.