Я сумніваюся, чи потрібно використовувати автентифікацію ключа під час входу в SSH, або просто перейти на fail2ban + ssh (кореневий вхід відключений).
Невдалий fail2ban чи справді краще просто продовжувати генерувати ключі та конфігурувати це на всіх моїх клієнтських машинах, які потребують підключення до ssh?
Відповіді:
Я вважаю це стабільним продуктом і вважаю його безпечним. В якості додаткової обережності я додав би вашу дирекційну IP-адресу до ignoreipдирективи, jails.confщоб переконатися, що ви не блокуєте себе.
Оскільки він аналізує журнали ssh, сеанс TCP повинен бути встановлений, щоб підробляти IP-адреси джерела, а отримання чисел послідовностей TCP правильно для створення свого роду зміни зворотного розряду здається малоймовірним.
Використання клавіш у верхній частині цього також не є поганою ідеєю. Інші параметри, які допомагають - перенести ssh до нестандартного IP, використовуючи "останній" модуль iptables або просто вирішити, що вам байдуже, чи намагаються люди спробувати паролі. Докладніше про це див. У цій публікації на сервері за замовчуванням .
Кожен раз, коли я коли-небудь реалізовував denyhosts або fail2ban у виробничому середовищі, він створював гарантований потік квитків запитів на розблокування, запитів на скидання пароля, запитів на зміну налаштувань або керування білим списком, і взагалі просто людей, які відмовляються від входу в систему. придивіться до речей і більше спирайтеся на сисадмінів на речі, які вони могли зробити самі.
Це не є технічною проблемою ні з одним інструментом, але якщо ваші користувачі налічують десятки і більше, це стане помітним змістом у навантаженні підтримки та розчарованих користувачів.
Крім того, проблема, яку вони вирішують, полягає в тому, що вони знижують ризик грубої атаки ssh-логін. Чесно кажучи, ризик цього надзвичайно малий, якщо у вас є навіть помірно гідна політика щодо паролів.
Я використовую з декількох років, і, принаймні, є хорошим захистом від дітей, які працюють із сценарієм.
Жоден кореневий вхід, а також досить довгі та випадкові паролі та fail2ban і, можливо, інший порт для більшості з нас недостатньо безпечний.
Звичайно, ключі ssh набагато краще, ніж безпека.
Я використовував denyhosts на декількох моїх виробничих та невиробничих серверах, і це працює справді чудово (у мене були проблеми з синхронізацією демона, тому я зараз його не використовую, але, можливо, він знову працює нормально).
Це не лише робить вашу систему більш безпечною, але й допомагає зберігати чистіші журнали та просто не допускати небажаних людей із ваших екранів входу ...
Я трохи запускаю Fail2Ban зараз, і зовсім недавно я бачив розповсюджені спроби проникнути на свій SSH-сервер. Вони ніколи не матимуть успіху у швидкості, що йде, але я стежу за цим.
Вони переглядають словник, кожен IP намагається двічі, після цих спроб інший IP робить те саме, і т.д. Але поки що я отримав кілька тисяч різних IP-адрес, які намагаються проникнути; і я переживаю, що навіть якщо я їх заблокую, все одно їх буде більше.
.confфайлів, а замість цього розміщувати свої конфігурації у.localфайлах. Це також значно покращує оновлення, оскільки жоден з ваших локальних файлів не перезаписується.