Я хотел бы узнать мнение сообщества по безопасности серверов linux об атаках грубой силы и использовании fail2ban против пользовательских iptables.
Я пытаюсь определить лучшее решение для защиты серверов linux, выходящих в интернет (работающих с обычными службами, ssh, web, mail), от атак методом грубой силы. Я неплохо разбираюсь в безопасности серверов, т. е. блокирую ssh, не позволяя входить под root или паролем, меняю порт по умолчанию, слежу за обновлением программного обеспечения, проверяю файлы журналов, разрешаю доступ к серверу только определенным хостам и использую инструменты аудита безопасности, такие как Lynis (https://cisofy.com/lynis/), для общего обеспечения безопасности, поэтому данный вопрос необязательно касается этого, хотя вклад и советы всегда приветствуются.
Мой вопрос заключается в том, какое решение я должен использовать (fail2ban или iptables) и как я должен его настроить, или я должен использовать комбинацию обоих решений для защиты от атак методом перебора?
Наиболее интересным решением было указание на то, что маршрутизация iptables происходит в ядре, в отличие от fail2ban, который использует инструменты пользовательского режима для разбора файлов журналов. Fail2ban, конечно, использует iptables, но ему все равно приходится разбирать лог-файлы и искать соответствие шаблону, пока он не выполнит действие. Имеет ли смысл тогда использовать iptables и ограничение скорости (https://www.rackaid.com/blog/how-to-block-ssh-brute-force-attacks/), чтобы отбрасывать запросы от IP-адреса, который делает слишком много попыток подключения в течение определенного периода времени, независимо от того, к какому протоколу он пытался подключиться? Если да, то здесь (http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject) есть интересные мысли по поводу использования drop vs reject для этих пакетов, есть какие-нибудь размышления по данному вопросу?
Fail2ban позволяет настраивать конфигурацию в виде возможности писать собственные «правила» для служб, которые могут быть не учтены в стандартной конфигурации. Его легко установить и настроить, он мощный, но может ли он быть излишеством, если все, чего я пытаюсь достичь, — это «заблокировать» IP с сервера, если он сделал 2 неудачные попытки доступа к любому сервису/протоколу в течение «x» времени?
Цель состоит в том, чтобы открывать ежедневные отчеты logwatch и не прокручивать страницы неудачных попыток подключения к серверу.
Ответ 1
Вы используете fail2ban в дополнение к решению брандмауэра, чтобы по требованию расширить существующие правила брандмауэра правилами блокировки определенных ip-адресов систем, которые выполняют нежелательные действия на общедоступных сервисах. Они работают согласованно друг с другом.
Упрощенно: брандмауэр видит только сетевые соединения и пакеты и может понять некоторые закономерности в них, но у него нет понимания на уровне приложений, чтобы отличить желаемые и действительные запросы от вредоносных, неправильно сформированных и нежелательных запросов. Например, ваш брандмауэр не может отличить совокупность HTTP API запросов от нескольких неправильных попыток входа в систему, вызванных перебором паролей на странице администратора Wordpress. Для брандмауэра они оба являются лишь TCP соединениями с портом 80 или 443.
Fail2ban — это общий и расширяемый подход для предоставления брандмауэру информации на уровне приложений, хотя и несколько косвенно.
Часто приложения регистрируют и записывают в журнал вредоносные, неправильно сформированные и нежелательные запросы, но лишь в редких случаях они имеют встроенную возможность предотвратить дальнейшее злоупотребление. Хотя Fail2ban немного сложен, он может действовать на основе этих зарегистрированных вредоносных событий, ограничивать ущерб и предотвращать дальнейшие злоупотребления, обычно динамически перенастраивая ваш брандмауэр, чтобы запретить дальнейший доступ. Другими словами, Fail2ban предоставляет существующим приложениям, не изменяя их, средства защиты от злоупотреблений. Другой метод обеспечения брандмауэров информацией на уровне приложений — это система обнаружения/предотвращения вторжений.
Например, веб-сервер является общедоступной службой, и в вашем брандмауэре TCP-порты 80 и 443 открыты для интернета в целом. Обычно вы не ограничиваете скорость на портах HTTP/HTTPS, потому что несколько действительных пользователей могут иметь один источник, когда они находятся, например, за NAT-шлюзом или веб-прокси.
Когда вы обнаруживаете нежелательные и/или злонамеренные действия по отношению к вашему веб-серверу, вы используете fail2ban для автоматического блокирования таких нарушителей (либо блокируя их полностью, либо блокируя их доступ только к портам 80 и 443). С другой стороны, доступ к SSH не является публичной услугой, но, если вы не в состоянии ограничить доступ к SSH в вашем брандмауэре только диапазонами ip-адресов из белого списка, ограничение скорости входящих соединений является одним из способов замедления атак методом перебора. Однако ваш брандмауэр все равно не сможет отличить пользователя «Вася», успешно вошедшего в систему 5 раз, потому что он работает с плейбуками ansible, от 5 неудачных попыток бота войти в систему под именем «root».
Ответ 2
Какое решение я должен использовать: fail2ban или iptables?
Прежде всего, помните, что fail2ban — это инструмент для автоматического обнаружения повторяющихся записей в текстовых файлах и выполнения некоторой команды, когда они соответствуют заданному порогу. Мы часто используем его для блокировки хостов, нарушающих определенную политику, о чем свидетельствуют повторяющиеся записи в журнале, указывающие на нарушение политики, но это не единственное, для чего его можно использовать. Вы можете использовать fail2ban для добавления (и удаления) правил iptables по требованию. Вы также можете добавлять и удалять правила iptables вручную, а можете использовать fail2ban для выполнения совершенно других действий в ответ. Все зависит от того, как вы его настроите.
У вас должен быть установлен общий брандмауэр, независимо от того, используете вы fail2ban или нет. Такой брандмауэр должен, например, блокировать (входящий или исходящий) трафик, который, как вы знаете, никогда не будет легитимным. Например, действительно ли серверу базы данных нужно иметь дело с входящими соединениями на порт 25 со всего интернета? Кроме того, если fail2ban будет реагировать на нарушение политики, отсекая на некоторое время IP-адреса нарушителей, это не сильно поможет защитить ваш сервер как таковой (хороший эксплойт должен пройти через ваш брандмауэр только один раз), но это снизит уровень шума в вашей системе, включая, но не ограничиваясь системными журналами. Простой способ сделать это — заставить fail2ban запустить iptables, чтобы настроить ядро на отбрасывание пакетов на некоторое время. Если вы можете перенастроить брандмауэр периметра, а не только брандмауэр хоста, то тем лучше. Другими словами, в той степени, в которой их можно легко разделить, вам нужны оба.
Может ли fail2ban быть излишеством, если все, чего я пытаюсь достичь, — это «заблокировать» IP с сервера, если он сделал 2 неудачные попытки доступа к любому сервису/протоколу в течение «x» времени?
Это именно тот случай, для решения которого предназначен fail2ban. Использование инструмента по назначению почти никогда не является излишеством. Цель здесь — открывать ежедневные отчеты logwatch и не пролистывать страницы попыток неудачных подключений к серверу.
Отступление, не имеющее прямого отношения к вашему вопросу: всякий раз, когда вы фильтруете журналы для просмотра, подумайте, что вы будете делать с той или иной записью. Если все, что вы собираетесь сделать с записью, — это сказать «ой, да ну…» и идти дальше, то, вероятно, лучше отфильтровать ее. Обязательно сохраняйте полные журналы для просмотра, если в этом возникнет необходимость, но включайте в свой обычный рабочий процесс мониторинга только те записи, с которыми вы действительно собираетесь что-то делать, когда они появятся. Если вы настроили fail2ban на блокировку хоста после нескольких неудачных попыток подключения, есть все шансы, что вам не понадобится просматривать их вручную и вы сможете исключить их из уведомлений мониторинга. Если легитимный пользователь жалуется на потерю доступа, просто достаньте полные журналы и посмотрите в них.
Ответ 3
Я разобрался с этим же вопросом несколько лет назад. Я решил использовать 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.
Linux