Я нападаю чи просто дурний?


11

Я запускаю сервер за допомогою Debian Squeeze з декількома контейнерами OpenVZ. У контейнерах працюють переважно Squeeze, деякі - Lenny, а деякі вже оновлені до Wheezy. Хост не робить це набагато понад iptables та DHCP. Файлові сервери, проксі-сервери, поштові сервери, kerberos, LDAP, ... все складаються в контейнери. Система працювала стабільно багато років і не мала великих змін, крім деяких правил брандмауера протягом року.

2 дні тому раптом система вийшла з ладу. У мене було багато проблем із його вихованням. Спочатку це не дозволило мені увійти через ssh. root gin was was denied denied denied denied denied denied denied '' «Ви не існує Йди геть!' Локальний вхід був чудовий. Через деякий час 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' безумовно працюють у різних контейнерах.

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

Буду вдячний за пораду, що слід перевірити далі.

Спасибі за вашу допомогу.

Оновлення : Доклавши більше зусиль у пошуку якогось попереднього курсору аварії, я знайшов у 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)

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

Відповіді:


2

Це схоже на DoS, який, швидше за все, походить з новорічного або зсередини одного зі збитих контейнерів.

Я б заглянув у vmstat, запускайте його постійно кожні 5 секунд: vmstat 5 і занотуйте, де витрачаються ресурси. Ви також можете використовувати екран і запускати 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

0

Схоже на помилку вводу / виводу диска. Запустіть fsck і перевірте наявність помилок.


Я спробую запланувати час простою для цього. Однак ніде не існують журнали, пов'язані з відмовою вводу / виводу диска. Або ти бачив якусь?
Ларс Ханке

0

Можливо, у вас немає жодних помилок файлової системи, але я впевнений, що ви бачите це попередження у своєму журналі, оскільки у вас є багато процесів у стані D (очікування вводу / виводу), і ядро ​​повідомляє про тривале очікування.


Я здогадуюсь, що це було так. Але чому? У нормальних умовах у D стані немає процесів. Якщо насправді мережа знизилася, це може пояснити це. Але чому це знизиться лише для деяких послуг? Чому цей стан пережив перезавантаження? І чому це знову придумали?
Ларс Ханке

0

Помилка вказує на те, що ваші процеси чекають занадто довго (120 сек) для доступу до дисків; це відбувається на дуже переповнених серверах, де диски занадто зайняті, щоб реагувати на процеси.

Ви можете переконатися, встановивши галочку "Очікування" під vmstat.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.