Denyhosts vs fail2ban vs iptables - найкращий спосіб запобігти грубі сили?

Я налаштовую LAMP-сервер і мені потрібно запобігти SSH / FTP / тощо. спроби входу в грубі сили з успіхом. Я бачив чимало рекомендацій як для denyhosts, так і для fail2ban, але мало порівнянь двох. Я також читав, що правило IPTables може заповнювати ту саму функцію.

Чому я б обрав один із цих методів над іншим? Як люди на сервері за замовчуванням вирішують цю проблему?

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

кращий спосіб запобігти жорстоким входам?

Не дозволяйте їм дістатися до вашої машини в першу чергу! Існує маса способів зупинити грубі спроби, перш ніж вони потраплять до вашого хоста або навіть на рівні SSH.

Сказавши це, захистити операційну систему чимось на кшталт fail2ban - чудова ідея. Fail2ban трохи відрізняється від DenyHosts, хоча вони грають у тому ж просторі. Fail2ban використовує iptables.

http://en.wikipedia.org/wiki/Fail2ban

Fail2ban схожий на DenyHosts ... але на відміну від DenyHosts, який фокусується на SSH, fail2ban можна налаштувати для контролю будь-якої служби, яка записує вхід у файл журналу, а замість використання /etc/hosts.deny лише для блокування IP-адрес / хостів , fail2ban може використовувати Netfilter / iptables та TCP Wrappers /etc/hosts.deny.

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

SSH:

• Не дозволяйте root входити в систему
• Не дозволяти паролі ssh (використовувати автентифікацію приватного ключа)
• Не слухайте кожен інтерфейс
• Створіть мережевий інтерфейс для SSH (наприклад, eth1), який відрізняється від інтерфейсу, від якого ви обслуговуєте запити (наприклад, eth0)
• Не використовуйте поширені імена користувачів
• Використовуйте список дозволів і дозвольте лише тим користувачам, яким потрібен доступ до SSH
• Якщо вам потрібен доступ до Інтернету ... Обмежте доступ до обмеженого набору IP-адрес. Один статичний IP ідеальний, однак блокування його до xx0.0 / 16 краще, ніж 0.0.0.0/0
• Якщо можливо, знайти спосіб підключення без доступу до Інтернету, таким чином ви зможете заборонити весь інтернет-трафік для SSH (наприклад, за допомогою AWS ви можете отримати пряме з'єднання, що обіходить Інтернет, воно називається Direct Connect)
• Використовуйте програмне забезпечення на зразок fail2ban, щоб зловити будь-які грубі напади
• Переконайтесь, що ОС завжди в курсі оновлень, зокрема пакетів безпеки та ssh

Застосування:

• Переконайтеся, що ваша програма завжди актуальна, зокрема пакети безпеки
• Заблокуйте сторінки адміністратора програми. Багато з наведених вище порад стосуються також області адміністратора вашої програми.
• Захист паролем області адміністратора, щось на зразок htpasswd для веб-консолі спроектує всі основні вразливості програми та створить додатковий бар'єр для входу
• Блокування дозволів на файли. "Завантажувати папки" є горезвісною тим, що є точками входу для всіляких неприємних речей.
• Розмістіть програму за приватною мережею та виставляйте лише балансир навантаження та стрибок (це типова установка в AWS за допомогою VPC)

Я використовую правила iptables для обмеження швидкості нових з'єднань з тієї самої IP-адреси (в основному SSH, але це також буде добре для FTP). Перевага, як я бачу, над "fail2ban" та іншими подібними інструментами полягає в тому, що маршрут iptables відбувається повністю в режимі ядра і не покладається на будь-які інструменти користувальницького режиму для хвостових / розбору файлів журналів.

Сотні невдалих реєстраційних даних ssh

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

У SSH ви дійсно повинні використовувати автентифікацію сертифікатів і жодним чином не приймати паролі.

ІНШИЙ ВЕЛИКИЙ ШЛЯХ ЗАХИСТУ SSH (я використовую це протягом десятиліття або вище) - це використовувати останні бібліотеки в iptables на самому собі (залежно від вашого дистрибутива).
В основному він може бути використаний як збивання порту, вбудований в iptables. Це позбавить вас від великої кількості головних болів. Поки ви можете підключити tcp (telnet - це один із способів. Я також використовував ssh-клієнтів і вказав їх на порт. Все, що зробить tcp-з'єднання із вказаним номером порту. Я дивлюся на вас Putty!) З клієнт, який ініціює ssh-з'єднання, ви можете використовувати це.

Нижче наведено приклад, у якому iptables будуть відкривати порт 22 для вашого хоста, коли ви передаваєте telnet від свого хоста до сервера на порт 4103. Потім ви можете використовувати telnet до порту 4102 або 4104, щоб закрити відкриття sed. Причина і для 4102, і для 4104 полягає в тому, щоб уникнути простого сканування tcp від відкриття 22. Лише tcp підключення (telnet) до порту 4103 дозволить вам увійти.

Насолоджуйтесь!

О, і я віддаю перевагу Fail2Ban. Більшу гнучкість, і мені подобається, що заборона відбувається в iptables, а не в tcpwrappers.

SSH PORTKNOCKING

iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -m recent --rcheck --name SSH -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4102 -m recent --name SSH --remove -j DROP
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4103 -m recent --name SSH --set -j DROP
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4104 -m recent --name SSH --remove -j DROP

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

Ще одна відмінність полягає в тому, що Fail2ban використовує iptables, тоді як Denyhosts використовує tcpwrappers. Інші згадували про цю різницю раніше, але є кілька бічних записок, які варто згадати.

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

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

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

Одне, що слід зазначити про Fail2Ban, - це те, що, здається, використовується приблизно на 10 Мб більше пам'яті, ніж DenyHosts. Тож, якщо ви перебуваєте на 128 Мб VPS, можливо, ви захочете вивчити це. Крім того, нестабільна панель fail2ban - це лише налаштування на SSH, а це означає, що без змін конфігурації - DenyHosts робить те саме, що менше пам'яті.

denyhosts - це для ssh. fail2ban є всеосяжнішим (HTTP, FTP тощо). Обидва використовують iptables за кадром.

Замість того, щоб возитися з виснажливими iptables або config2 fail2ban, чому б відкрита спільнота не зробила всю роботу за вас, а замість цього використати CSF / LFD? Я настійно рекомендую це понад усі згадані варіанти. Дивіться http://configserver.com/cp/csf.html про те, що це може зробити для ваших серверів. CSF не вимагає панелі управління, вона пропонує простий інтерфейс користувача для тих, хто не хоче це робити за допомогою оболонки. І це багато стабільних надійних нерезидентів сценаріїв перл.

Схоже, у fail2ban не існує механізму розпізнавання успішного входу в ssh та скидання його кількості відмов.

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

У результаті сказаного, я зараз замислююся про відхід від fail2ban. Щонайменше, у цьому відношенні краще відмовити. Однак це, мабуть, більше не є добрим варіантом і більше не підтримується в новіших версіях debian (деякі дискусії на https://www.chrissearle.org/2015/06/16/replacing-denyhosts-with-fail2ban-for- debian / )

У мене немає хорошого рішення тут.

Власне, я думаю, що denyHost здатний запобігти багатьом іншим службам, окрім sshd-сервісу. У файлі його налаштування /etc/denyhosts.confє ряд рядків коду, який сказав:

# BLOCK_SERVICE: the service name that should be blocked in HOSTS_DENY
#
# man 5 hosts_access for details
#
# eg.   sshd: 127.0.0.1  # will block sshd logins from 127.0.0.1
#
# To block all services for the offending host:  
BLOCK_SERVICE = ALL
# To block only sshd:
# BLOCK_SERVICE  = sshd

тому якщо ми встановимо BLOCK_SERVICEзмінну такою ALL, яка була вище, ми можемо спостерігати за нашою службою ssh.

Denyhosts версії 3.0: Кожен раз, коли IP-адреса з’являється у файлі журналу, Denyhosts відкриває файл hosts.deny і читає все, щоб відповідати адресу. Кожного разу. Ніщо не зберігається в пам'яті. Якщо у вас величезний файл hosts.deny і вам підлягають безліч зондів (багато записів у файлі журналу), Denyhosts стає читанням свиней CPU і перечитуванням файлу hosts.deny для кожної IP-адреси, що з’являється. Не добре.

Якщо увімкнути підтримку iptables, Denyhosts створить величезні, повільні списки заблокованих IP-адрес. Denyhosts не використовує ipset або nftables для створення ефективних IP-карт.