Чи варто докладати зусиль, щоб заблокувати невдалі спроби входу

Чи варто запускати fail2ban , sshdfilter або подібні інструменти, які чорний список IP-адрес, які намагаються і не ввійти?

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

Скажімо, мій сервер "належним чином захищений", і я не переживаю, що жорстока атака насправді матиме успіх - чи ці інструменти просто підтримують чисті мої реєстраційні файли, чи я отримую якусь корисну користь від блокування спроб атаки грубої сили?

Оновлення : Дуже багато коментарів щодо грубої сили вгадування паролів - я згадав, що не хвилювався з цього приводу. Можливо, я повинен був би бути більш конкретним і запитати, чи не має fail2ban якісь переваги для сервера, який дозволяє лише ключові sh входи.

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

1. Законні користувачі іноді забувають свої паролі. Я не хочу забороняти законним користувачам свого сервера, змушуючи мене знову вручну ввімкнути їхні акаунти (або ще гірше, спробуйте розібратися, який із 100/1000 заборонених IP-адрес є їхнім).
2. IP-адреса не є хорошим ідентифікатором для користувача. Якщо у вас є кілька користувачів за одним ІС (наприклад, школа, яка працює NAT на 500 учнівських машинах), один користувач, який зробить кілька поганих здогадок, може поставити вас у світ болю. У той же час більшість спроб вгадування пароля, які я бачу, поширюються.

Тому я не вважаю fail2ban (і подібні засоби автоматизованого реагування) дуже хорошим підходом до захисту сервера від грубої атаки. Прості правила IPTables, встановлені для скорочення спаму журналу (який у мене є на більшості моїх серверів Linux), є приблизно таким:

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

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

Такі інструменти, як fail2ban, допомагають зменшити непотрібний мережевий трафік та зберегти журнали трохи меншими та чистішими. Це не велике оздоровлення, але полегшує життя систематично; ось чому я рекомендую використовувати програму fail2ban у системах, де ви можете собі це дозволити.

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

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

Що ж, це рятує вашу мережу від нападів відмови в деякій мірі та економить накладні витрати на обробку відмов.

Не бути найслабшим сервером у списку дітей для сценаріїв - це завжди добре.

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

PasswordAuthentication no