Я атакован или просто глуп?

Я запускаю сервер, используя Debian Squeeze с несколькими контейнерами OpenVZ. Контейнеры работают в основном Squeeze, некоторые Lenny, а некоторые уже обновлены до Wheezy. Хост не делает ничего, кроме iptables и DHCP. Файловые серверы, прокси-серверы, почтовые серверы, Kerberos, LDAP, ... все помещены в контейнеры. Система работала стабильно в течение многих лет и не имела серьезных изменений, за исключением некоторых правил брандмауэра в течение более года.

2 дня назад внезапно произошел сбой системы. У меня было много проблем, когда я снова поднял его. Сначала это не позволило бы мне войти через ssh. вход в систему root запрещен: «Вас не существует. Уходи!' Локальный логин был в порядке. Через некоторое время SSH снова работает. По стечению обстоятельств я не использовал строку из истории bash повторно, а набрал новую команду, которая трижды проверяла, была ли она идентична строке, которая раньше не работала, но работала до сбоя.

Затем система запустилась, но сетевой трафик на большинстве протоколов был заблокирован после SYN ACK. DNS, Telnet и SSH были в порядке, но остальное было беспорядком. После пары часов рыбалки в темноте и перезагрузки брандмауэра несколько раз все внезапно прошло хорошо. Я не мог найти ничего подозрительного в журналах - но я не судебный эксперт.

Сегодня nscd файлового сервера вышел из сокетов, чтобы связаться с LDAP из-за квоты контейнера. То, что никогда не случалось раньше. Я также видел много (> 30) сокетов, заявленных smbd.

/ 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' определенно работают в разных контейнерах.

Ну, я не вижу курящего пистолета, но я, вероятно, просто слепой. Настройка системы из известных / предполагаемых хороших резервных копий слишком сильно ударит по мне, чтобы попробовать ее без веских причин.

Буду признателен за любой совет, что проверить дальше.

Спасибо за вашу помощь.

Обновление : прилагая больше усилий в поиске некоторого предварительного курсора сбоя, я нашел следующее в системном журнале:

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)

Я знаю, что это считается некритическим, но это, кажется, редкое событие. Усечение пакетов существует только в день второго сбоя. Нигде во всех доступных лог-файлах.

Это похоже на DoS, скорее всего, происходящее из nework или изнутри одного из скомпрометированных контейнеров.

Я смотрю в vmstat, запускаю его непрерывно каждые 5 секунд: vmstat 5 и записываю, куда расходуются ресурсы. Вы также можете использовать screen и запускать vmstat 60 (каждую минуту) в отдельном окне - таким образом вы можете заметить пики, когда они происходят в течение более длительного периода времени.

В этой ситуации высокая / высокая скорость системного ЦП (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

Похоже, ошибка ввода-вывода диска. Запустите fsck и проверьте ошибки.

Возможно, у вас нет ошибок файловой системы, но я уверен, что вы видите эти предупреждения в своем журнале, потому что у вас много процессов в состоянии D (ожидающих ввода-вывода), и ядро ​​информирует вас о долгом ожидании.

Ошибка указывает, что ваши процессы слишком долго (120 секунд) ждут доступа к дискам; это происходит на сильно загруженных серверах, где диски слишком заняты, чтобы реагировать на процессы.

Вы можете убедиться, проверив «Ожидание» в vmstat.