Які плюси / мінуси різних методів блокування жорстоких атак SSH?

Існує декілька різних пакетів, щоб вимкнути IP-адреси, з яких на вашу систему запускаються жорстокі SSH-атаки. Наприклад:

Які плюси / мінуси цих чи будь-яких інших?

Моє поточне рішення - приймати електронну пошту, яку щоденно створює logwatch, і скидати кричущі IP-адреси в текстовий файл, який я подаю в сценарій, який потім відновлює iptables. Це хакіт, трудомісткий і ручний, і я хотів би кращого способу.

(Зауважте, я не запитував, який був "найкращий" спосіб вирішити проблему, тому що немає "найкращого" способу зробити що-небудь.)

ssh security

— Енді Лестер
джерело

Відповіді:

Я використовую DenyHosts, тому можу принаймні відповісти за це:

Плюси

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

Мінуси

У мене немає непоправних мінусів, якщо ви правильно їх використовуєте:

У конфігурації за замовчуванням він не оповіщатиме вас про щойно введені у чорний список хости, тому якщо хтось атакує вашу мережу із сотень різних адрес, ви можете не помітити відразу, як ви, якщо ви стежите за своїми журналами вручну, але (як зазначено в розділ "плюси") він може надіслати вам електронною поштою або запустити виконуваний файл, щоб повідомити вас про додавання нових хостів
За замовчуванням він розміщує ваші хости в чорному списку так само, як і будь-який інший, тому ви, ймовірно, хочете додати їх /etc/hosts.allow. Я заблокував себе один раз, просто не ввівши свій пароль, і колись хтось із роботи спробував увійти до мого кореневого акаунта як жарт, і в чорний список моєї IP-адреси про роботу, і мені знадобилося кілька днів, щоб зрозуміти, чому я раптом не зміг підключитися в мою мережу з роботи більше

— Михайло Мрозек
джерело

Ще один - fail2ban , який покладається на iptables (тому він працює з будь-яким сервісом, а не тільки ssh). З програмою fail2ban ви можете:

Вкажіть шлях до будь-якого файлу журналу (apache, ssh, nginx, поштовий сервер, ...).
Вкажіть регулярний вираз для шаблонів атак (наприклад, більше 10 "404 помилок" тим самим ip у журналі доступу до nginx за 6 секунд)
Вкажіть регулярний вираз, щоб ігнорувати певні шаблони (дуже корисно!)
Вкажіть час заборони
Надіслати електронний лист (або будь-яке інше сповіщення ...)
Повністю настроюється (ви можете писати власні сповіщення та фільтри)

Одним з «недоліків» DenyHosts є те, що він вимагає обгортки tcp, тому він працюватиме лише з сервісами, які переглядають файл /etc/hosts.deny. Але для справедливості з DenyHosts, sshd складається для використання TCP Wrappers у більшості дистрибутивів Linux. Я також вважаю, що DenyHosts простіше налаштувати поза коробкою, ніж fail2ban (але менш потужний).

Посилання на подібне питання SF

— Бартелемі
джерело

fail2ban, на щастя, також працює з pf - не просто iptables

— Good Person

Простий і на практиці ефективний захист від атак на основі сканування - це не використовувати стандартний порт. 443 (порт https) відкриває вас різним нападкам, які не збираються зламати ваші слабкі паролі і, можливо, працюють через більше брандмауерів, ніж порт за замовчуванням (22).

Більшість методів запобігання ssh brute force нападам - це чудові способи самозакохатись (ой, я накрутив конфігурацію! На жаль, я зробив купу швидких rsync і мені зараз заборонено!) Або допоміг самостійно DoS (На жаль , зловмисник походить з / перекрутив машину в тій самій підмережі, що і я (динамічний діапазон IP, мережа коледжів ...), і мене також забороняють!).

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

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

Ще один метод, який ви не згадуєте - це стукання портів . Він не страждає від проблем самозакоханості (крім помилок конфігурації), але не перетинає між собою брандмауери і може додати кілька секунд затримки для встановлення з'єднання.

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

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

— Жил "ТАК - перестань бути злим"
джерело

Я погоджуюся, що потрібна певна практика, щоб не забороняти себе ;-) Зміна портів за замовчуванням і не покладатися на пароль, а на ключ, захищений паролем, також є гарною порадою. Але я дійсно не знаю, чому я повинен дозволити ботовим мережам заповнювати свої файли журналів доступу, тоді як мій ssh та веб-сервер мають відмовляти у тисячах запитів на годину. У програмі fail2ban мій журнал доступу чистий, і мої серверні програми взагалі не бачать цей трафік (крім перших X поганих запитів :-)).

— Бартелемі

Використання нестандартного порту взагалі не забезпечує особливого захисту. Сканування SSH на нестандартному порті займає лише кілька хвилин більше, ніж сканування на SSH на порт 22 (якщо припустити, що зломщик виконує сканування, а сканування не було заблоковано IDS. Але якщо у вас IDS, то затемнення портів, ймовірно, непотрібне ). Якби я був зломщиком, і я знайшов SSH на нестандартному порту, я був би навіть БІЛЬШЕ зацікавлений, бо знаю, що адміністратор вважав, що ця послуга є достатньо дорогоцінною, щоб приховати її, і покладається на безпеку через незрозумілість.

— Стефан Ласєвський

@Stefan: Більшість атак не проти певного хоста, а проти певної послуги. Для цього набагато ефективніше сканувати один порт за багатьма адресами, ніж багато портів на кожну адресу. І якщо у вас насправді нападає нападник, вам краще знати, тому ви хочете, щоб сильні або заборонені паролі та атаки були записані.

— Жил "ТАК - перестань бути злим"

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

— Бартелемі

@sudowned Вказання іншого порту навряд чи буде неприємністю. Це лише один рядок .ssh/config. Блокування є проблемою, якщо брандмауер не дозволить вам пройти, а найпростішим рішенням є приєднатися до порту 22, а також прослухати на 443. Я згоден, що перемикання порту насправді не покращує безпеку, можливо, я повинен зробити це яснішим. . Я не знаю, чому ви вважаєте неможливим, щоб демон SSH не підтримував автентифікацію пароля: це лише питання додавання рядка до sshd_configOpenSSH, найпоширенішої реалізації.

— Жил "ТАК - перестань бути злим"