Як визначити, чи потрапила в мою скриньку Linux?

Нещодавно я прочитав статтю про аналіз шкідливих спроб входу в SSH. Це змусило мене замислитись, чи не рідкість імені SSH, комбінацій паролів у вікні Debian? Чи був я націлений напад грубої сили словника? Давайте подивимось на /var/log/auth.log.0 :

Sep 23 07:42:04 SLUG sshd[8303]: Invalid user tyjuan from 210.168.200.190
Sep 23 07:42:09 SLUG sshd[8305]: Invalid user tykeedra from 210.168.200.190
Sep 23 07:42:14 SLUG sshd[8307]: Invalid user tykeem from 210.168.200.190
Sep 23 07:42:19 SLUG sshd[8309]: Invalid user tykeshia from 210.168.200.190
Sep 23 07:42:25 SLUG sshd[8311]: Invalid user tyla from 210.168.200.190
Sep 23 07:42:30 SLUG sshd[8313]: Invalid user tylan from 210.168.200.190
Sep 23 07:42:35 SLUG sshd[8315]: Invalid user tylar from 210.168.200.190
Sep 23 07:42:40 SLUG sshd[8317]: Invalid user tyler from 210.168.200.190
Sep 23 07:42:45 SLUG sshd[8319]: Invalid user tylerfrank from 210.168.200.190
Sep 23 07:42:50 SLUG sshd[8321]: Invalid user tyliah from 210.168.200.190
Sep 23 07:42:55 SLUG sshd[8323]: Invalid user tylor from 210.168.200.190

Тож це не виглядає добре. Тепер, коли я знаю, що на мене потрапила атака, і що деякі мої ім’я користувача, комбінації паролів є слабкими, я хотів би знати, як я можу ...

• ... визначте, чи проникла моя скринька Linux?
• ... скасувати будь-яку шкоду, яку залишили винні особи?
• ... не допустити цього в майбутньому?

ОНОВЛЕННЯ

Будь-яка порада щодо скасування будь-якої шкоди, яку залишили винні особи?

Дуже багато людей пропонують DenyHosts, але я побачив великий успіх із Fail2Ban у своїх системах. Він спостерігає за (настроюваною) кількістю відмов, а потім виконує дію - на моїх серверах ця дія полягає у використанні iptables для скидання всього трафіку з хоста. Після 10 збоїв входу в систему вони заборонені, і на цьому все закінчено.

Я використовую це в поєднанні з Logcheck, так що я завжди знаю, що відбувається на моїх серверах.

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

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

Я використовую DenyHosts для моніторингу моїх журналів на предмет підозрілого трафіку SSH, і у мене це налаштовано для автоматичного брандмауера від хостів у певний момент.

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

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

Ви також повинні зробити всебічний аналіз журналу, дивлячись на auth.log та інші, на предмет несподіваних речей. Аналіз файлів журналів - це конкурентоспроможний ринок, і ця проблема ще не вирішена, але є безкоштовні інструменти, такі як logwatch, які можна налаштувати, щоб надсилати вам підсумки щодня.

Безпека через шари!

Забудьте про Tripwire, його досить дорого. Використовуйте замість AIDE. Його безкоштовний, простий у налаштуванні (хоча потрібно трохи часу, щоб вирішити, які тимчасові каталоги виключити та іншим чином налаштувати).

Ви запускаєте його, він створює базу даних усіх файлів. Запустіть його ще раз, і він підкаже, які файли змінилися.

Ще одне, що потрібно зробити, - це встановити CSF, у якому є блокатор типу denyhost, оскільки люди не вдається повторно ввійти, він додасть їх до правил вашого брандмауера. Ви також можете вимагати, щоб входи в SSH також мали відкритий ключ, діти сценарію можуть намагатися виконати стільки входів, скільки їм подобається тоді.

"* ... determine if my Linux box has been infiltrated?"

• шукати ознаки дивних процесів. Я зазвичай використовую інструменти, які постачаються з chkrootkit ( http://www.chkrootkit.org )
• Зробіть порт-скан з nmap з іншої машини. Якщо ваша скринька була порушена, шанси на те, що зловмисник встановив задню панель

"* ... скасувати будь-яку шкоду, яку залишили винні особи?"

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

"* ... не допустити цього в майбутньому?"

• оновлення безпеки

• щільний брандмауер

• надійні паролі

• вимкнути непотрібні послуги

поглянути на інструменти , такі як LogCheck , PortSentry і натяжної . це дуже часто для випадкових спроб SSH-словника, тому я би не надто хвилювався цим. ви можете змінити порт для випадкової обфускування, але ви все одно час від часу будете бачити випадкові спроби, це життя з машиною в Інтернеті.

Одне, що я використовую на своїх серверах, щоб запобігти цим атакам, - DenyHosts . DenyHosts зупинить зловмисного користувача від спроби входу. З моменту її встановлення у моїх журнальних файлах було значно менше записів для входу.

Це хороша практика використання пар публічних / приватних ключів як додаткової автентифікації; Таким чином користувач не може увійти через SSH без правого ключа; що було б неможливо вгадати для грубого форсера. Приємну статтю про це можна знайти тут .

Це одне лише із парольною фразою було б досить твердим для аутентифікації SSH; Але є більше вразливості! Слідкуйте за всіма програмами, які використовують відкритий порт; Якщо вони містять помилок, експлуататори можуть наздогнати вашу систему. Хорошим прикладом був спам-бот, який встановлений на нашому сервері через помилку у програмному забезпеченні веб-статистики, яке ми використовуємо в даний час.

Fail2ban - аналізатор журналу доступу в режимі реального часу. Він може бути налаштований для блокування будь-якого IP з низкою невдалих спроб входу. Це дозволяє уникнути атак словника без необхідності переміщення порту ssh. chkrootkit і rootkithunter - хороші утиліти для перевірки на вторгнення. Якщо вторгнення було успішним, найкращою практикою є копіювання даних (і лише даних, а не виконуваних файлів), стерти та перевстановити, оскільки справді важко бути 100% впевненим, що система чиста.

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

Але якщо ви знаєте, що ваші паролі слабкі, тоді зміцніть їх! Мені особисто подобається pwgen (який упакований Debian). Під час кожного запуску він створює велику кількість сильних, але відносно невимовних кандидатів у пароль, які (як мінімум, для мене) досить легко запам'ятовуються, наприклад, yodieCh1, Tai2daci або Chohcah9.

Однак якщо є інші докази, які свідчать про те, що ваша система була порушена ... Запустіть її з орбіти. Це єдиний спосіб бути впевненим.

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

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

Використання iptables:

$ iptables        -A INPUT      -p tcp --dport 22 -m state --state ESTABLISHED,RELATED -j ACCEPT
$ iptables        -A INPUT      -p tcp --dport 22 -m state --state NEW -m limit --limit 3/min --limit-burst 3 -j ACCEPT
$ iptables        -A INPUT      -p tcp --dport 22 -j DROP

Існує кілька поганих порад щодо цієї теми, таких як:

• використання нестандартного порту для ssh (неправильно!)
• використання інструменту захисту сторонніх виробників (додавання зайвої залежності / складності)
• налаштування вашого брандмауера для блокування чи списку білого списку (технічне обслуговування)

Просто налаштуйте /etc/ssh/sshd_configнатомість, щоб покращити безпеку:

• PermitRootLogin no
• Налаштуйте AllowUsers лише для користувачів у системі, які мають облікові записи ssh
• Подумайте про використання лише фізичних ключів із позначкою "Ні, ніж пароль"

Якщо ви в коробку проникли. Відновіть коробку.

Буде весь час із включеним ssh. Перемістіть його до високого порту.

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

Потрібно встановити виявлення вторгнень, перш ніж підключити апарат до Інтернету.

І це гарна ідея встановити IP-з'єднання білого списку просто, щоб бути впевненим, що весь світ навіть не може спробувати подібні речі.

Як я можу визначити, чи потрапила в мою скриньку Linux?

Завантажте медіа-файл лише для читання (livecd) та порівняйте файли із резервною копією чи оригінальним носієм.

Просто дивіться навколо, щоб не дивно поводитись. Звичайно, це найпростіше, якщо ви витратите час перед виламуванням, щоб добре відчути, що є "нормальним".

Опубліковані вами помилки не вказують на компроміс. Просто те, що хтось намагається.

Як я можу скасувати будь-яку шкоду, яку залишили винні особи?

Перевстановіть і відновіть із резервної копії до того, як система була порушена.

Подивитися:

• /server/6159/aftermath-of-hack
• Перевстановити після кореневого компромісу?

Як я можу запобігти цьому в майбутньому?

Подивитися:

• Запобігання жорстоким атакам проти ssh?
• Сотні невдалих реєстраційних даних ssh
• Ubuntu Server SSH
• Які дії ви зробите для захисту сервера Debian?

Ви можете переглянути поле, щоб побачити, що відбувається і виходить, і шукати щось підозріле. Дивіться цей пост: /programming/124745/sniffing-network-traffic-for-signs-of-virusesspyware

Psad у поєднанні з Shorewall - це хороший спосіб компліментувати правила iptables.

Я також використовую Fail2ban для відстеження моїх реєстраційних даних

використовувати rkhunter або chkrootkit або те і інше; скануйте своє поле зовні, щоб побачити, які порти відкриті

у будь-якому випадку, якщо все, що ви маєте, недійсний користувач, хвилюватися не потрібно :)

Щось зовсім інше: спробуйте використовувати Google за IP-адресою! Хакер, який називає себе STARTURK з Туреччини, можливо, спробував зламати ваш сайт.

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

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

Одне, що може допомогти вам принаймні почати - це використовувати базу даних RPM для перевірки md5sum ваших файлів. Основна суть у цьому:

rpm -qa | xargs rpm -V

Це не ідеально з різних причин. По-перше, ваша локальна база даних RPM теоретично могла бути змінена. По-друге, більшість дистрибутивів використовують попереднє посилання, і RPM не знає попереднього посилання. Здається, MD5s були змінені під час цього процесу, що є законним.

Найкраща порада така: якщо ви не впевнені в тому, що вас зіпсували, справді настає час перебудови.

Щоб уникнути майбутніх проблем із безпекою, ви можете ознайомитися з OSSEC , я використовую його для перевірки цілісності файлів і моніторингу журналів на наших серверах, це дуже повно і легко налаштувати. Він може надсилати повідомлення поштою, ви можете перевіряти сповіщення за допомогою командного рядка або веб-інтерфейсу ...

http://www.ossec.net/

взяті з веб-сайту:

"OSSEC - це система виявлення вторгнень на основі відкритого коду. Вона виконує аналіз журналів, перевірку цілісності файлів, моніторинг політики, виявлення руткітів, оповіщення в режимі реального часу та активне реагування."

• Аналіз журналу Він може перевірити файл журналів на ваших серверах та оповістити вас за допомогою правил (заздалегідь визначено багато, і ви можете додати свої власні)

• цілісність файлу tripwire / aide на зразок функціональності, тож ви побачите, чи який файл було змінено на вашому сервері

• моніторинг політики: перевірте деякі правила безпеки "Кращі практики"

• виявлення rootkit: rkhunter, chkrootkit як функціональність

• оповіщення в режимі реального часу та активна відповідь: Ви можете налаштувати ossec на автоматичне реагування на сповіщення (я не використовую це, але ви можете використовувати його для блокування ssh доступу до хостів, що робить занадто багато спроб підключення)

Дійсно хороший продукт, і він дуже активний

Для того, щоб затвердіти ваш ящик ви також можете використовувати Lynis або Бастилію

• http://www.rootkit.nl/projects/lynis.html

• http://bastille-linux.sourceforge.net/