Як захистити сервер ubuntu від bruteforce ssh-атак?

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

Є різні рішення. Найкращим є використання аутентифікації RSA, яка використовує публічні / приватні ключі для аутентифікації користувачів.

Перевірте цей чудовий посібник щодо різних підходів (включено аутентифікацію RSA): http://www.la-samhna.de/library/brutessh.html

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

Ось рішення, яке я використовую:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

Як згадувалося тут : це дозволить три з’єднання 22 порту з будь-якої заданої IP-адреси протягом 60-секундного періоду та потребуватиме 60 секунд жодних наступних спроб з'єднання, перш ніж воно відновиться, дозволяючи з'єднання знову. Параметр --rttl також враховує TTL дейтаграми при збігу пакетів, щоб намагатися пом'якшити проти підроблених адрес джерела.

Як зазначено у згаданому посібнику, краще використовувати білий список для відокремлення довірених користувачів від цих правил:

iptables -N SSH_WHITELIST

потім додайте надійних хостів:

iptables -A SSH_WHITELIST -s $TRUSTED_HOST -m recent --remove --name SSH -j ACCEPT

і після цього складіть правила:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

Я отримую грубі сили ssh-атаки на своїх серверах зі швидкістю від 1 до 2 на день. Я встановив denyhosts (пакунок ubuntu: denyhosts). Це дуже простий, але ефективний інструмент для цієї мети: фактично він періодично сканує ваші журнали, щоб виявити атаки грубої сили та ставить IP-адреси, звідки ці атаки походять у ваш файл /etc/hosts.deny. Ви більше не почуєте їх і навантаження має бути значно зменшено. Це дуже конфігурується через його конфігураційний файл /etc/denyhosts.conf для налаштування таких проблем, як кількість неправильних спроб складати атаку тощо.

Завдяки прозорості роботи ви можете легко побачити, що відбувається (повідомлення електронною поштою: «ага, інша кричуща атака зірвана!») Та скасувати помилки через те, що ваші користувачі неодноразово вводять паролі.

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

Крім того, обмеження швидкості нового з'єднання в iptables може бути кращим вибором, ніж заборона доступу через hosts.deny. Отже, подивіться і на fail2ban. Але якщо ви знаєте, що головна проблема - ssh brute-force (вручну перегляньте /var/log/auth.log, щоб визначити це), перейдіть за допомогою цього дуже легкого інструменту з низьким впливом.

1. Змініть порт sshd на щось нестандартне
2. Використовуйте knockdдля впровадження системи зчитування портів
3. Використовуйте iptables ' recentта hashlimitmatch, щоб обмежити послідовні спроби SSH
4. Не використовуйте паролі, а використовуйте SSH-ключі

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

https://help.ubuntu.com/10.04/serverguide/C/openssh-server.html

Використання fail2ban також може бути варіантом.

https://help.ubuntu.com/community/Fail2ban

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

Альтернативою fail2ban є CSF: безпека та брандмауер ConfigServer .

Він поставляється з LFD: Daemon Failure Daemon, який може виявити кілька невдалих спроб входу в різні сервіси, і заблокує IP-адресу, що порушує право (тимчасово або назавжди).

У нього є інші варіанти, які можуть допомогти проти наводнення та, можливо, виявити вторгнення.

Недоліки:

• Ви повинні використовувати CSF як брандмауер, щоб LFD виконував свою роботу. Отже, якщо у вас є існуючий брандмауер, вам потрібно буде замінити його на CSF та перенести конфігурацію.
• Він не упакований для Ubuntu. Вам доведеться довіряти автоматичним оновленням з configserver.com або вимкнути автоматичні оновлення.
• Я чув, що це досить популярно, тому розумні зловмисники, напевно, знають, як відключити виявлення вторгнень до їх виявлення!

Ви маєте намір дозволити службу SSH всьому світу? Або просто членам команди в певних місцях? Моя відповідь трохи залежить від серйозності вашого завдання.

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

1. У / etc / ssh / sshd_config переконайтеся, що ви ніколи не дозволяєте входити в систему root, за винятком ключа SSH.

У моїх системах у мене є цей параметр

PermitRootLogin without-password

але я помічаю, що в новіших Ubuntu вони є

PermitRootLogin prohibit-password

Якщо ви читаєте "man sshd_config", я думаю, що це означає, що цей новий "забороняючий пароль" означає те ж саме і, безумовно, більш очевидний за змістом. Це НЕ за замовчуванням у деяких системах Linux, але, мабуть, має бути.

Тепер про вашу проблему. Чи працює ваш системний сервер лише деяких користувачів у певних місцях? Зробити це!

2. відредагувати /etc/hosts.deny та вставити

   ВСІ: ВСІ

Потім відредагуйте /etc/hosts.allow і перерахуйте IP-номери або діапазон, який потрібно дозволити використовувати SSH. Позначення є трохи заплутаними, тому що якщо ви хочете дозволити всі системи з IP-номерами, наприклад, від 111.222.65.101 до 111.222.65.255, ви введете такий запис у hosts.allow

ALL: 127.0.0.1
sshd: 111.222.65.
sshdfwd-X11: 111.222.65.

Це жорстоке, потужне рішення. Якщо ваші користувачі можуть бути перелічені IP-діапазоном, зробіть це!

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

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

Ви можете досягти тієї самої основної мети, обмінюючись iptables та брандмауером. У певному сенсі це найкраще рішення, оскільки ви блокуєте ворогів на зовнішній межі. Ubuntu має "ufw" (нескладний брандмауер), а "man ufw" - безліч прикладів. Я вважаю за краще мати гарний графічний інтерфейс, щоб пройти це, я не повинен це робити постійно. Можливо, інші можуть нам сказати, чи є зараз такий.

3. Інші публікації тут пропонують використовувати відкритий ключ SSH лише для ваших користувачів. Це, безумовно, допоможе ціною складності та розчарування для ваших користувачів. У нашій лабораторії є 15 комп’ютерів. Користувачі ходять серед комп’ютерів. Потрібна автентифікація ключа SSH може спричинити великі клопоти, оскільки люди переходять з одного комп'ютера на інший.

Ще одне джерело розчарування станеться, коли деякі користувачі накопичують різні клавіші ssh для різних серверів. Оскільки у мене є ключі SSH для приблизно 12 різних проектів, тепер ssh виходить з ладу, оскільки у мене занадто багато відкритих ключів (вимагає або "ssh -o PubkeyAuthentication = false", або створення запису у .ssh / config файл. Це PITA)

4. Якщо ви повинні залишити сервер відкритим для SSH у великому широкому світі, то, безумовно, вам слід використовувати процедуру відхилення, щоб заблокувати місця, які часто намагаються увійти. Для цього є 2 приємні програми, ті, якими ми користувалися, - denyhosts і fail2ban . Ці програми мають налаштування, які дозволяють заборонити правопорушників протягом тривалого часу.

У наших системах Centos Linux я помітив, що вони скинули пакет denyhosts і пропонують лише fail2ban. Мені сподобалося denyhosts, тому що він створив список проблемних користувачів / ip-діапазонів, а потім у hosts.deny, цей список було відмічено. Натомість ми встановили fail2ban, і все в порядку. Я розумію, що ви б краще заблокувати цих поганих користувачів на зовнішньому краю сервера, тому блокатори на основі ip-таблиць, як fail2ban, насправді кращі. Denyhosts працює на вторинному рівні, після того, як вороги отримали минулі iptables, їх відкидає демон sshd.

В обох цих програмах виснажувати користувачів із в'язниці дещо нудно, якщо вони забудуть свій пароль та спробують кілька разів увійти. Повернути людей, коли вони роблять помилки входу, трохи важко. Ви могли б здогадатися, що буде графічний графічний інтерфейс, куди ви можете просто вказувати та відпускати людей, але це не так. Я повинен робити це кожні кілька місяців і забувати, як між часом, тому я написав інструкції для себе на своїй веб-сторінці http://pj.freefacturing.org/blog/?p=301