Захист SSH-сервера від грубої сили

У мене є маленький сервер SVN, старий dell optiplex, який працює під управлінням debian. У мене немає таких високих вимог до мого сервера, тому що це лише невеликий SVN-сервер ... але я хочу, щоб він був захищеним.

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

Я знаю, що можу запобігти входженню root та використовувати sudoers ... та змінити порт SSH, але що я можу зробити?

Тож у мене є кілька питань:

1. Як я можу запобігти входу в систему протягом 5 хвилин після кількості неправильних спроб X. Або повільна спроба знизитися після кожної неправильної спроби?

2. Чи є якийсь центральний чорний список, до якого може підключитися сервер? Чорний список, який відслідковує "небезпечні" IP-адреси та ніколи не повинен мати доступ?

3. Що ще я можу зробити, щоб застосувати безпеку до свого сервера?

Як я вже говорив раніше, я запускаю Debian 5 з Apache (www-data user problem?), Svn, mysql, php, phpmyadmin, hudson. Він знаходиться в домашній мережі з переадресацією портів на 80, 443, 8080, 8180, 23 і 22.

Fail2ban і Port Knocking повинні відповідати більшості ваших потреб.

Рекомендується також змінювати порт SSH та дозволяти лише автентифікацію на основі ключа.

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

Також непогана ідея заборонити вхід у систему.

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

Fail2Ban має кілька хороших прикладів того, як налаштувати все, що ви просили ... однак він не має універсального сховища поганих адрес. Я не думаю, що такого сховища немає в будь-якому місці через простоту отримання іншого IP-адреси (dhcp відновлення / атаки bot-net / тощо ...). Я також заборонив би ввійти через ssh за допомогою загальних імен користувачів типу "адміністратор" (root / admin / administrator / sysop / тощо), оскільки це найчастіше відбувається на цьому.

Я зупинив грубі напади за допомогою:

• fail2ban
• sshd.config:
  • Аутентифікація пароля Ні
  • No PermitRootLogin Ні
• Обмеження швидкості SSH Connect за допомогою iptables ( http://www.debian-administration.org/articles/187 )

Тут пропонується ряд хороших пропозицій. Я з повагою пропоную, що три речі повинні зробити це відносно безпечним:

1. Запустіть sshd на випадково високому порті. Як правило, боти йдуть лише після порту 22 та варіацій на порту 22, як 2222.
2. Вимкнення автентифікації на основі пароля в налаштуваннях sshd:

UsePAM no

3. Автентифікуватися на цьому сайті можна лише за допомогою загальнодоступних пар ключів SSH. Людина на ssh-keygen для початку роботи з аутентифікацією на основі PKI.

Сподіваюсь, це допомагає.

Я завжди був великим шанувальником CSF / LFD, який може блокувати IP-адреси людей, які намагаються виконувати грубі дії, portscan та деякі інші варіанти. Це в основному величезна perl-обгортка для IP-таблиць, але файл конфігурації не важко прочитати і документація непогана.

Ви також можете заглянути в sshguard. Я не користувався цим, але чув хороші речі.

Джерела:
http://isc.sans.edu/diary.html?storyid=9370

http://www.sshguard.net/

http://www.sshguard.net/docs/faqs/

"Sshguard відстежує сервери за їхньою реєстраційною діяльністю. Коли журнали повідомляють, що хтось робить погану річ, sshguard реагує, блокуючи його на деякий час. Sshguard має чутливу особистість: коли неслухняний тик наполягає на заважанні вашого хоста, він реагує твердіший і міцніший ».

У мене SSH-сервер, підключений до Інтернету на порту за замовчуванням, і жодного разу не виникав проблем.

• tcp_wrappers (тобто. hosts.allow hosts.deny) для SSH .. Я не думаю, що там є SSH, який не підтримує підтримку.
• iptables це спільно з tcp_wrappers усунуло близько 99% моїх випадкових сканувань портів / спроб грубої сили .. Єдина проблема полягає в тому, що вам потрібно знати, звідки ви будете підключатися, щоб дозволити ці діапазони IP / IP ... Я просто зробив пошук популярних провайдерів у моїй області, щоб побачити їхні діапазони IP-адрес і дозволити їм .. більшість сканів, здається, надходять із далеких країв :)
• PermitRootLogin без пароля (тобто лише пари ключів RSA / DSA, зашифровані фразою пропуску) чудово працює для автоматизованих завдань .. Коли я входжу для взаємодії, я, очевидно, використовую свій акаунт (регулярний), який налаштований з доступом до sudo
• судори
• постійні оновлення .. Я часто оновлюю це поле разом із усіма оновленнями безпеки / критичними
• зміни пароля / парольної фрази
• запускайте chkrootkit раз і знову, щоб побачити, чи є у мене якісь проблеми .. (є кілька таких, які виконують цю функцію)

сподіваюся, що це допоможе!

Є кращий спосіб зробити це, використовуючи fail2ban означає, що вам потрібно додати додаток, і воно працює на рівні додатків.

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

Використовуйте останній модуль iptables http://www.snowman.net/projects/ipt_recent/

iptables -N SSHSCAN
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j LOG --log-level info --log-prefix "SSH SCAN blocked: "
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j DROP
iptables -A SSHSCAN -j ACCEPT

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

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

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

DenyHosts, http://denyhosts.sourceforge.net/ , це хороший проект, з яким мені пощастило. Якщо ви встановите denyhosts до синхронізації, він завантажить нові IP-адреси, щоб додати їх до списку заборон, які мали змусити насильницькі інші системи за допомогою denyhosts. Він також закінчує термін дії IP-адрес, які протягом певного часу не намагалися жорстоко застосовувати сили.

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

Що для мене було ефективним:

1. Як вже говорили інші, у кореневому режимі sshd_config немає кореневого входу, пароль PasswordAuthentication встановлено на ні (лише w / ключі)

2. Лише одному або двом користувачам дозволяється входити через ssh, і вони мають квазі-неясні імена, які не містяться у загальних списках імен користувачів брутальної сили (тобто не "адміністратор" чи "апаш" чи "веб" чи " johnny ")

3. Правила обмеженого брандмауера (в основному все заблоковано, крім мого сервісного порту та ssh). Я навіть обмежую пінг, щоб запобігти більш грубим скануванням (сильно на прикрість мого партнера).

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

5. І мій улюблений: модуль активного реагування OSSEC для блокування ряду умов грубої сили та попередження про інші помилки. Він виявляє x недійсні входи через y кількість часу, а потім блокує (за допомогою команди iptables firewall-drop) протягом певного періоду часу. Я зараз блокую близько 12 годин для розваги. :)

Я хочу зробити тут, щоб переконати, що я не блокував занадто багато неправильної речі, - це те, що в /etc/ossec.conf я встановлюю активну відповідь на високий рівень (який не існує в конфігурації за замовчуванням), а потім пройдіть через sshd_rules.xml і встановіть правила, які я хочу заблокувати, до цього рівня та змініть пороги для блоку проти попередження, якщо потрібно.

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