Запобігання жорстоким атакам проти ssh?


49

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

Це на вікні FreeBSD, але я думаю, це було б застосовано в будь-якому місці.

Відповіді:


25

Ось хороший пост з цього приводу Райнера Віхмана.

Він пояснює плюси та мінуси методів тези:

  • Сильні паролі
  • Аутентифікація RSA
  • Використання 'iptables' для блокування атаки
  • Використання журналу sshd для блокування атак
  • Використання tcp_wrappers для блокування атак
  • Порт стукає

39

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

Поєднайте це з тестуванням на захист паролем (використовуючи john (John the Ripper)), щоб переконатися, що атаки жорстокої сили не матимуть успіху.


4
Fail2ban - відмінний. Це було просто розширити його на монітор / var / log / maillog і отримати його, щоб заборонити стійким спамерам ударяти мій поштовий сервер
Дейв Чейні

Fail2ban може поєднуватися з ланцюжком iptables, який надсилає трафік tcp до TARPITцілі, якщо ви відчуваєте себе неприємно (від xtables-addons).
Тобу


16
  • Зміна використовуваного порту (як згадував Трент )
  • Потрібні ключі шифрування замість паролів. http://novosial.org/openssh/publickey-auth/
  • Ips зловмисника
  • Білий список відомих користувачів, щоб запобігти випадковому чорному списку. (як згадував Саміуела)

15

Один з найпростіших способів уникнути цих атак - це змінити порт, який слухає sshd


1
Якщо, звичайно, система може це витримати.
К. Росс

13
Безпека через незрозумілість, ефективна щоразу.
Кріс Баланс

1
Я б не проти змінити порт так сильно, але я дізнався, що більшість брандмауерів (крім мого власного), як правило, блокують усі порти, окрім загальних (80,22, 443 тощо). Якщо я за тими брандмауерами, я не можу потрапити на свій домашній сервер на цьому нестандартному порту. Для мене це не піде.
скорботи

@grieve потім змінити наш брандмауер, щоб цей порт вийшов?
Рорі

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

12

Як зазначає Кріс, використовуйте ключі шифрування замість паролів.

Додайте до цього:

  • використовуйте білий список, де це можливо.

Скільки людей або локацій (з плаваючими загальнодоступними IP-адресами) вам дійсно потрібні для доступу до ваших загальнодоступних ssh-з'єднань?

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

Якщо це працює для вас, це може справді спростити адміністративні витрати.


2
Білий список надзвичайно важливий, якщо ви робите будь-який чорний список, якщо ви не хочете заблокувати його.
Ryaner

2
+1 - проактивний білий список.
Кріс Баланс

3
+1 за абсолютну найкращу відповідь. Ці дві речі - єдині розумні кроки, і вони справді дуже ефективні. Або поодинці варто, і обом разом. Бу з інших відповідей виступає за безпеку через невідомість!
dwc

11

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

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

Я можу щось не зрозуміти, але багато основних браузерів одночасно підключаються між 4-6 підключеннями, - хоча стандарт HTTP встановлює його на рівні 2.
Джошуа Енфілд

1
Так, це буде проблемою, якщо ви намагалися обмежити порт 80. Ви не підключаєтесь до ssh за допомогою свого веб-браузера, а сеанси ssh - це довготривалі сесії, які підтримують стан, а не недовговічні сеанси без громадянства, наприклад http. Паралелізація подібних сеансів ssh не має сенсу. Це не означає, що не існує якихось нішевих використання ssh, які б це зламали, але це рідко.
шербанг

Це рішення не так добре, якщо, як я, ви обслуговуєте Subversion через ssh. Один SVN-запит може швидко здійснити велику кількість з'єднань. Якщо ви надаєте цю послугу, ви можете використовувати другу службу sshd на іншому порту, або білий список відомих IP-адрес. Я думаю про використання fail2ban або sshdfilter, щоб зловити очевидні напади вперше, не караючи законних користувачів.
Падді

добре знати і цей варіант ...
ZEE

6

Використовуйте параметр "Дозволити користувачі" в sshd_config, щоб гарантувати, що лише невеликий набір користувачів може взагалі увійти. Усі інші будуть відхилені, навіть якщо їх ім’я користувача та пароль правильні.

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

наприклад,

AllowUsers user1 user2@host.example.com

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

Це не повністю зупиняє жорстокі напади, але допомагає зменшити ризик.


3

Використовуйте щось подібне з PF:

Таблиця <ssh-brute> зберігає
блок у швидкому журналі з мітки ssh_brute
передавати на $ ext_if proto tcp до ($ ext_if) порт ssh модулювати стан \
(max-src-conn-швидкість 3/10, перевантажувати флеш глобальним)


2

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


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

2

Контекст важливий, але я б рекомендував щось подібне:

  • Оскільки ви використовуєте FreeBSD, подумайте про запуск брандмауера PF та використання його надійних функцій обмеження швидкості з'єднання. Це дозволить вам надсилати грубі сили, якщо вони з'єднуються часто
  • Якщо до цього вікна потрібно звернутися із зовнішнього світу, подумайте про використання правила PF rdr, щоб не дозволяти трафіку до порту 22, а для перенаправлення якогось незрозумілого порту на нього. Це означає, що вам доведеться підключитися до порту 9122 замість 22. Це малозрозуміло, але він тримає стукачі подалі
  • Подумайте про перехід до аутентифікації на основі ключів, що робить атаки словника марними

2

Крім пропозиції щодо обмеження швидкості Шербанга, важлива тривалість затримки. Зі збільшенням затримки між групами з 3 спроб входу з 2 хвилин до 20 хвилин кількість різних IP-адрес, які зробили більше трьох спроб входу, зменшилась, порівнявши два тижні на одній моїй машині, з 44 спроб до 3 Жодна з цих трьох адрес не намагалася пробувати довше 11 годин.

Дуже анекдотично, але auth.log став для мене набагато більш читабельним ...


1

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


-1 Коли-небудь чули про напади DoS?
Кріс Баланс

8
Так, SSH - це єдиний сервіс, схильний до грубої атаки. Якщо у вас відкритий порт для Інтернету, його можна використовувати, щоб забити ваш апарат у небуття. Ви, напевно, ставите свій HTTP-сервер і на дивні порти, і за стуканням портів, щоб "уникнути DoS-атак" ...
Утром

1

встановити OSSEC. він не тільки стежить за повторними входами, але вводить тимчасовий блок з iptables для ip-порушника. І наприкінці він надішле вам звіт із зазначенням деталей. він записує все, що приємно. Колись Somone спробував понад 8000 імен для входу, щоб увійти. я розібрав журнали та отримав приємний список користувачів поза угодами;)

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