Захист серверів Linux: iptables vs fail2ban

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

Є кілька подібних питань, але жодне з них не задовольняє цю тему на мій задоволення. Коротше кажучи, я намагаюся визначити найкраще рішення для захисту серверів Linux, що піддаються впливу Інтернету (запуск звичайних сервісів, ssh, web, пошти), від грубої атаки.

Я маю гідну ручку щодо безпеки сервера, тобто блокування ssh, не дозволяючи входити в систему root або пароль, змінюючи порт за замовчуванням, забезпечуючи оновлення програмного забезпечення, перевіряючи файли журналів, дозволяючи лише певним хостам отримувати доступ до сервера та використовувати безпеку такі інструменти аудиту, як Lynis ( https://cisofy.com/lynis/ ), для загальної відповідності безпеці, тому це питання не обов'язково стосується цього питання, хоча введення та поради завжди вітаються .

Моє запитання полягає в тому, яке рішення я повинен використовувати (fail2ban або iptables), і як я можу його налаштувати, або я повинен використовувати комбінацію обох для захисту від жорстоких атак?

Є цікава відповідь на цю тему ( Denyhosts vs fail2ban vs iptables - найкращий спосіб запобігти логотипу грубої сили? ). Найцікавішою для мене особисто була відповідь ( https://serverfault.com/a/128964 ), і маршрутизація iptables відбувається в ядрі на відміну від fail2ban, який використовує інструменти користувальницького режиму для розбору файлів журналів. Fail2ban звичайно використовує iptables, але він все ще повинен розібрати файли журналів і відповідати шаблону, поки він не виконає дію.

Чи має сенс потім використовувати iptables та використовувати обмежуючі ставки ( https://www.rackaid.com/blog/how-to-block-ssh-brute-force-attacks/ ) для відкидання запитів з IP на період часу, який робить занадто багато спроб з'єднання протягом певного періоду незалежно від того, до якого протоколу він намагався підключитися? Якщо так, то тут є цікаві думки щодо використання drop vs reject для цих пакетів тут ( http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject ), якісь думки з цього приводу?

Fail2ban дозволяє налаштувати власну конфігурацію у вигляді можливості писати власні " правила " для служб, які не можуть бути адресовані в конфігурації за замовчуванням. Встановити та налаштувати його досить просто і є потужним, але чи може це бути зайвим, якщо все, що я намагаюся досягти, - це « заблокувати » IP з сервера, якщо вони роблять 2 невдалі спроби доступу до будь-якої служби / протоколу понад x кількість часу?

Мета полягає в тому, щоб відкривати щоденні звіти про перегляд журналу, а не прокручувати сторінки спроб невдалого з'єднання з сервером.

Дякуємо, що знайшли час.

я повинен використовувати fail2ban або iptables?

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

Спрощено: брандмауер бачить лише мережеві з'єднання та пакети і може зрозуміти шаблони в них, але він не має уявлення про рівень додатків, щоб відрізнити бажані та дійсні запити від шкідливих, неправильно сформованих та небажаних запитів. Наприклад, ваш брандмауер не може визначити різницю між купою запитів API HTTP та кількома помилковими спробами входу, викликаними відгадуванням пароля грубої сили на вашій сторінці адміністратора Wordpress, до брандмауера вони обоє лише підключення TCP до порту 80 або 443.

Fail2ban - це загальний і розширюваний підхід, щоб забезпечити розуміння рівня програми для вашого брандмауера, хоча і дещо опосередковано.
Часто додатки реєструють і реєструють шкідливі, неправильно сформовані та небажані запити як такі, але лише рідко вони матимуть природну здатність запобігати подальшому зловживанню. Незважаючи на те, що Fail2ban може злегка розв'язатись, вони можуть діяти на ці зареєстровані шкідливі події та обмежувати збитки та запобігати подальшому зловживанню, як правило, динамічно перенастроюючи брандмауер, щоб заборонити подальший доступ. Іншими словами, Fail2ban надає вашим наявним програмам, не змінюючи їх, засоби для захисту від зловживань.

Іншим методом надання брандмауерам відомостей про рівень застосувань був би за допомогою системи виявлення / запобігання вторгнень .

Наприклад, веб-сервер є загальнодоступною службою, і у вашому брандмауері TCP-порти 80 і 443 відкриті для Інтернету в цілому.
Зазвичай у вас немає обмежень швидкості на портах HTTP / HTTPS, оскільки кілька дійсних користувачів можуть мати одне походження, коли вони, наприклад, стоять за NAT-шлюзом або веб-проксі.

Коли ви виявляєте небажані та / або шкідливі дії щодо вашого веб-сервера, ви використовуєте fail2ban для автоматизованого блокування такого правопорушника (або блокуйте їх повністю, або лише заблокувавши їх доступ до портів 80 та 443).

З іншого боку, доступ до SSH не є публічною службою, але якщо ви не в змозі обмежити доступ SSH у брандмауері лише діапазонами ip-адрес, що перераховуються білими, вхідні з'єднання, що обмежують швидкість, - це один із способів уповільнити грубі дії -силові атаки. Але ваш брандмауер все ще не може розрізнити між тим, як користувач bob успішно входить у систему 5 разів, оскільки він працює з підручними ігровими книгами та 5 невдалими спробами увійти як корінь ботом.

я повинен використовувати fail2ban або iptables?

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

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

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

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

У вас повинна бути загальна брандмауер незалежно від того, працюєте ви з програмою fail2ban чи ні. Така брандмауер може, наприклад, заблокувати (вхідний або вихідний) трафік, який, як ви знаєте, ніколи не буде законним. Наприклад, це , що сервер бази даних дійсно потрібен мати справу з вхідними з'єднаннями на порт 25 з усього інтернету?

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

Іншими словами, настільки, наскільки їх можна легко розділити в першу чергу, ви хочете і те, і інше.

Чи може це бути зайвим, якщо все, що я намагаюся досягти, - це «заблокувати» IP з сервера, якщо вони роблять 2 невдалі спроби доступу до будь-якої служби / протоколу протягом сокири часу?

Саме такий випадок використання fail2ban призначений для вирішення. Використання інструменту за призначенням майже ніколи не буде надмірним.

Мета полягає в тому, щоб відкривати щоденні звіти про перегляд журналу, а не прокручувати сторінки спроб невдалого з'єднання з сервером.

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

Я вирішив те саме питання кілька років тому. Я вирішив використовувати iptables з останнім модулем через продуктивність та просту настройку. Мені довелося захищати багато віртуальних контейнерів на хостах. Майте на увазі, щоб не відкривати жоден вектор DOS з вашими правилами. Також використовуйте ipset для відповідності спискам мережі або ip спискам у правилах. Я використовую його для білих списків. Всі мережі однієї країни в одному списку чудово підходять для тонкої настройки. І дуже легко захистити інший сервіс тим самим набором правил, лише додавши ще один порт для відповідності. Тому я не люблю мінятися з fail2ban, але, можливо, хтось із іншими потребами буде задоволений програмою fail2ban.

Ось приклад:

  #
  # SSH tracking sample
  #
  #################################################################################
  iptables -X IN_SSH
  iptables -N IN_SSH
  iptables -A IN_SSH -m set --match-set net_blacklist src -p tcp -j REJECT
  iptables -A IN_SSH -m set --match-set net_whitelist src -p tcp --match limit --limit 5/second -j LOG --log-prefix whitelist_de_prefix
  iptables -A IN_SSH -m set --match-set net_whitelist src -p tcp -j ACCEPT
  # filter update
  iptables -A IN_SSH -m recent --name sshbf --set --rsource
  # connlimit
  iptables -A IN_SSH -m connlimit --connlimit-above 4 --match limit --limit 5/second -j LOG --log-prefix ssh_connlimit_per_ip_above_4
  iptables -A IN_SSH -m connlimit --connlimit-above 4 -j REJECT
  # filter
  iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 13 --seconds 60 --match limit --limit 5/second -j LOG --log-prefix ssh_filtered_13in60sec
  iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 13 --seconds 60 -j REJECT
  iptables -A IN_SSH -j ACCEPT

iptables -A FORWARD -p tcp --dport ssh --syn --jump IN_SSH
# iptables -A INPUT -p tcp --dport ssh --syn --jump IN_SSH

Вихід ваших повідомлень реєстрації може поєднуватися з fail2ban. Ви можете використовувати його і для правил INPUT.