Хочу поділитися своїм досвідом системного адміністратора-початківця. Так вже сталося, що мій перший млинець грудкою - це була пропозиція зайнятися інфраструктурою в одній маленькій компанії. Ситуація складна. Ніякої автоматизації, все вручну і за принципом: працює - не чіпай, а якщо не працює і ніхто не помітив, то вважай, що працює. Попередній співробітник не залишив майже жодної документації. Ось доступ до серверів, кавомашина - там, начебто все...
Досвід перший: маленькі симптоми великої проблеми
Було вирішено почати з інвентарю. Все розміщено у великого публічного оператора: по кілька віртуальних машин на орендований сервер з попередньо встановленим гіпервізором Xen:
Експерти можуть зі мною не погодиться, але я знаходжу KVM набагато зручніше Xen для елементарної віртуалізації інфраструктури маленьких підприємств. Xen може залучити тих, хто віддає перевагу графічному інтерфейсу управління. Але, на жаль, можливості даного графічного інтерфейсу досить обмежені, а інтерфейс управління командного рядка Xen сильно поступається за своєю простотою KVM/QEMU у разі, якщо треба зайти за рамки стандартних маніпуляцій віртуальних машин. Але схоже, що дане питання не особливо хвилювало мого попередника, який керував системами з найменшим докладанням зусиль. Як виявилося, все було встановлено за замовчуванням, а саме: сервери працювали на застарілій Ubuntu 12.4 LTS, замість звичних для таких цілей Debian.
У наставники мені визначили програміста, який заміняв звільненого сисадміна. Разом ми полізли розбиратися з діаграмою розгортання господарства на серверах підприємства.
Тут слід сказати, що будь-який сисадмін, в душі, повинен бути трохи детектив. Потрібно вміти помічати найменші аномалії, за якими можуть ховатися великі проблеми. У даному випадку мою увагу привернули дивні файли з привілеєм root. «Напевно нас хакнули», знизав плечима колега, не прийнявши моє занепокоєння всерйоз. Простих підозр було недостатньо, і ми вирішили поки нічого особливого не робити. Архівуємо підозрілі файли, змінюємо пароль користувача і продовжуємо інвентар.
Досвід другий: не зліть злих хакерів
А якщо розлютили, то готуйтеся до наслідків.
«Щось з сервером»..., напевно одне з найбільш неприємних повідомлень, яке може отримати системний адміністратор по дорозі на роботу. Особливо, якщо мова йде про нову роботу. Прискорюючи крок, перевіряємо ситуацію з телефону:
Прийшовши на роботу, натикаємося на комітет із схвильованих співробітників. Ситуація критична. Сервер недоступний, але доступний його гіпервізор через Xen. Стає ясно, що сервер працює, але повністю втрачено зв'язок з Інтернет:
Значить, проблема в маршрутизації. Ліземо до оператора:
Заодно знаходимо саму проблему:
Ну, тепер вже точно: сумнівів немає - нас зламали! І схоже, що зломщик, засмучений нашою попередньою інтервенцією, вирішив, якщо його виявили - втрачати вже нічого і використовував наш сервер для мережевої атаки. Гаразд, зате тепер мені дозволять налаштувати все по-своєму.
Першим ділом - файрвол:
Далі, змінюємо всім паролі:
Зберігаємо і трьом ключам ssh. Пізніше попросимо всіх користувачів генерувати нові. Зберігаємо, для порівняння: щоб особливо ледачі користувачі не могли використовувати старий, можливо скомпрометований доступ:
І, до речі, більше ніякого доступу з паролем: тільки ключі ssh!
Тепер нас ніхто не застане зненацька. Встановлюємо стеження за тими, хто входить в систему. Для цього додаємо до/etc/pam.d/sshd виконання простого скрипту нотифікації (loginlog):
А також підглядаємо за ключами:
Ну і під кінець, можна встановити auditd - це демон, здатний відстежувати все, що відбувається на сервері. Для цього достатньо двох рядків в/etc/audit/audit.rules:
На сьогодні все. Пишемо співробітникам про те, що в місті новий шериф про зміни з міркувань безпеки. А завтра постараємося впровадити Nagios або навіть почати переїзд на Debian. Сподіваюся, зломщик більше не пройде. Або пройде?
