Как заблокировать SSH и FTP-доступ к определенному IP-адресу и диапазону сети в Linux

Обычно все мы часто используем службы SSH и FTP для доступа к удаленным серверам и виртуальным частным серверам. Как администратор Linux вы должны знать, как заблокировать доступ SSH и FTP к определенному IP-адресу или диапазону сети в Linux, чтобы еще больше усилить безопасность.
- 25 советов по усилению безопасности серверов Linux
- 5 полезных советов по защите и защите SSH-сервера
Из этого туториала Вы узнаете, как заблокировать SSH и FTP-доступ к определенному IP-адресу и/или диапазону сети на сервере CentOS 6 и 7. Это руководство было протестировано на версиях CentOS 6.x и 7.x, но, вероятно, оно будет работать и в других дистрибутивах Linux, таких как Debian, Ubuntu, SUSE/openSUSE и т. Д.
Сделаем это двумя способами. Первый метод использует IPTables/firewallD, а второй метод использует TCP-оболочки с помощью файлов hosts.allow и hosts.deny.
Обратитесь к следующим руководствам, чтобы узнать больше о IPTables и Firewalld.
- Основное руководство по IPTables (брандмауэр Linux). Советы/команды.
- Как настроить брандмауэр Iptables для включения удаленного доступа к службам в Linux
- Как настроить FirewallD в RHEL/CentOS 7 и Fedora 21
- Полезные правила FirewallD для настройки и управления брандмауэром в Linux.
Теперь вы знаете, что такое IPTables и FirewallD и что это такое.
Метод 1: заблокировать доступ по SSH и FTP с помощью IPTables/FirewallD
Теперь давайте посмотрим, как заблокировать SSH и FTP-доступ к определенному IP (например, 192.168.1.100) и/или диапазону сети (например, 192.168.1.0/24) с помощью IPtables в версиях RHEL/CentOS/Scientific Linux 6.x и FirewallD на CentOS 7.x.
Чтобы новые правила вступили в силу, вам необходимо использовать следующую команду.
Теперь попробуйте подключиться к серверу по SSH с заблокированного хоста. Помните, что здесь 192.168.1.150 — это заблокированный хост.
Вы должны увидеть следующее сообщение.
Чтобы разблокировать или включить доступ по SSH, перейдите на удаленный сервер и выполните следующую команду:
Сохраните изменения, используя следующее, чтобы получить доступ к вашему серверу через SSH.
Обычно порты по умолчанию для FTP — 20 и 21. Итак, чтобы заблокировать весь FTP-трафик с помощью IPTables, выполните следующую команду:
Чтобы новые правила вступили в силу, вам необходимо использовать следующую команду.
Теперь попробуйте получить доступ к серверу с заблокированного хоста (192.168.1.100) с помощью команды:
Вы получите сообщение об ошибке, подобное приведенному ниже.
Чтобы разблокировать и снова включить доступ по FTP, запустите:
Сохраните изменения командой:
Теперь попробуйте получить доступ к серверу через FTP:
Введите имя пользователя и пароль ftp.
Метод 2: заблокируйте доступ по SSH и FTP с помощью TCP Wrappers
Если вы не хотите связываться с IPTables или FirewallD, то TCP-оболочки — лучший способ заблокировать SSH и FTP-доступ к определенному IP-адресу и/или диапазону сетей.
OpenSSH и FTP скомпилированы с поддержкой TCP-оболочек, что означает, что вы можете указать, каким хостам разрешено подключаться, не касаясь вашего брандмауэра, в следующих двух важных файлах:
- /etc/hosts.allow
- /etc/hosts.deny
Как следует из названия, первый файл содержит записи о разрешенных хостах, а второй — адреса заблокированных хостов.
Например, давайте заблокируем SSH и FTP-доступ к хосту с IP-адресом 192.168.1.100 и сетевым диапазоном 192.168.1.0. Этот метод одинаков для CentOS серий 6.x и 7.x. И, конечно же, он будет работать в других дистрибутивах, таких как Debian, Ubuntu, SUSE, openSUSE и т. Д.
Откройте файл /etc/hosts.deny и добавьте следующие IP-адреса или диапазон сети, который вы хотите заблокировать, как показано ниже.
Сохраните и выйдите из файла.
Теперь перезапустите службы sshd и vsftpd, чтобы изменения вступили в силу.
Теперь попробуйте подключиться к серверу или с заблокированного хоста по SSH.
Вы увидите следующий результат:
Теперь попробуйте FTP-сервер или с заблокированного хоста.
Вы увидите следующий результат:
Чтобы снова разблокировать или включить службы SSH и FTP, отредактируйте файл hosts.deny, закомментируйте все строки и, наконец, перезапустите службы vsftpd и sshd.
Заключение
На этом пока все. Подводя итоги, сегодня мы узнали, как заблокировать определенный IP-адрес и диапазон сети с помощью IPTables, FirewallD и TCP-оболочек. Эти методы довольно просты и понятны.
Даже начинающий администратор Linux может сделать это за пару минут. Если вы знаете другие способы заблокировать доступ по SSH и FTP, не стесняйтесь делиться ими в разделе комментариев. И не забывайте делиться нашими статьями во всех социальных сетях.
Ограничение доступа к оболочке с помощью SFTP в CentOS 7
SFTP (SSH File Transfer Protocol) – это протокол передачи файлов SSH. Как следует из его названия, это безопасный способ передачи файлов на сервер с использованием зашифрованного SSH-соединения. Несмотря на то, что названия FTP и SFTP очень похожи, SFTP –совершенно другой протокол, хотя он широко поддерживается современными FTP-клиентами.
SFTP доступен по умолчанию без дополнительной настройки на всех серверах, имеющих доступ к SSH. Он безопасен и прост в использовании, но имеет недостаток: в стандартной конфигурации сервер SSH предоставляет доступ к передаче файлов и к оболочке терминала всем системным пользователям с учетной записью.
В некоторых случаях только определенные пользователи должны иметь возможность передавать файлы. Этот мануал поможет настроить SSH-демона и в индивидуальном порядке ограничить пользователей одним каталогом без доступа к SSH.
Требования
- Сервер CentOS 7.
- Пользователь с доступом к sudo.
- Редактор nano (опционально).
Все инструкции вы найдете в руководстве по начальной настройке сервера.
1: Создание нового пользователя
Для начала создайте нового пользователя, у которого будут только права на передачу файлов. В руководстве пользователь условно зовется 8hostfiles.
sudo adduser 8hostfiles
Затем установите пароль для нового пользователя:
sudo passwd 8hostfiles
Далее нужно создать каталог для передачи файлов и настроить необходимые привилегии.
2: Создание каталога для передачи файлов
Чтобы ограничить доступ пользователя к SFTP одним каталогом, сначала нужно убедиться, что каталог соответствует требованиям к привилегиям сервера SSH. Эти привилегии имеют ряд особенностей.
В частности, сам каталог и все каталоги над ним в дереве файловой системы должны принадлежать root, а другие пользователи не должны иметь права на запись в них. Следовательно, невозможно просто предоставить ограниченный доступ к домашнему каталогу пользователя, поскольку домашние каталоги принадлежат собственно пользователям, а не root.
Примечание: В отличие от большинства современных дистрибутивов Linux (включая CentOS 7), некоторые версии OpenSSH не имеют таких строгих требований к структуре каталогов и правам собственности.
Существует целый ряд способов решения этой проблемы. В этом руководстве в качестве целевого каталога загрузки будет использоваться /var/sftp/uploads. Каталог /var/sftp будет принадлежать пользователю root и будет заблокирован для других пользователей. Подкаталог /var/sftp/uploads будет принадлежать пользователю 8hostfiles, так что он сможет загружать в него файлы.
sudo mkdir -p /var/sftp/uploads
Передайте права на /var/sftp пользователю root.
sudo chown root:root /var/sftp
Передайте пользователю root право на запись в этом каталоге. Остальные пользователи должны иметь только права на чтение и исполнение.
sudo chmod 755 /var/sftp
Передайте каталог uploads пользователю 8hostfiles.
sudo chown 8hostfiles:8hostfiles /var/sftp/uploads
3: Ограничение доступа к каталогу
На этом этапе нужно изменить конфигурацию сервера SSH и заблокировать пользователю 8hostfiles доступ к терминалу, но разрешить доступ к передаче файлов.
Откройте конфигурационный файл сервера SSH с помощью vi или другого текстового редактора.
sudo vi /etc/ssh/sshd_config
Перейдите в конец файла и вставьте следующий код:
. . .
Match User 8hostfiles
ForceCommand internal-sftp
PasswordAuthentication yes
ChrootDirectory /var/sftp
PermitTunnel no
AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
Сохраните и закройте файл.
- Match User позволяет серверу SSH применять следующие команды только к указанному пользователю (в данном случае – к 8hostfiles).
- ForceCommand internal-sftp:сервер SSH будет запускать SFTP во время логина без доступа к оболочке.
- PasswordAuthentication yes включает поддержку парольной аутентификации.
- ChrootDirectory /var/sftp/ блокирует пользователю доступ ко всем каталогам, кроме /var/sftp.
- AllowAgentForwarding no, AllowTcpForwarding no и X11Forwarding no отключают форвардинг, туннелирование и X11 для указанного пользователя.
Этот набор команд, начиная с Match User, можно скопировать и повторить для разных пользователей. Обязательно измените имя пользователя в соответствующей строке.
Примечание: Для повышения безопасности вы можете опустить строку PasswordAuthentication yes и вместо этого настроить доступ к SSH-ключам. Обязательно сделайте это прежде, чем отключить доступ к оболочке для пользователя. Чтобы протестировать настройку, вы должны иметь доступ к компьютеру с парой ключей.
sudo systemctl restart sshd
Теперь SSH-сервер ограничивает доступ к передаче файлов, поддерживая её только для пользователя 8hostfiles.
4: Тестирование конфигурации
Убедитесь, что новый пользователь 8hostfiles может только передавать файлы.
Войти на сервер как 8hostfiles с помощью обычного доступа к оболочке больше невозможно. Проверьте это:
ssh 8hostfiles@localhost
Error message
This service allows sftp connections only.
Connection to localhost closed.
Это значит, что 8hostfiles больше не может использовать обычную оболочку SSH.
Убедитесь, что этот пользователь может использовать SFTP для передачи файлов.
Эта команда должна выполниться успешно.
Connected to localhost.
sftp>
Просмотрите содержимое каталога с помощью ls:
Команда выведет созданный ранее каталог uploads и вернет вас в командную строку sftp>.
Чтобы убедиться, что пользователь действительно ограничен этим каталогом и не может получить доступ к каталогам высшего порядка, попробуйте перейти в родительский каталог.
Эта команда не выдаст ошибку, но запросив содержимое каталога, вы увидите, что пользователь по-прежнему в каталоге sftp и не смог перейти в родительский каталог.
Все ограничения работаю правильно.
Недавно созданный пользователь 8hostfiles может получить доступ к серверу только с помощью протокола SFTP для передачи файлов и не имеет доступа к остальной оболочке.
Заключение
Вы ограничили доступ пользователя к SFTP одним каталогом без полного доступа к оболочке. Повторите описанный в руководстве процесс, чтобы расширить настройку до нескольких пользователей и нескольких каталогов.
Сервер SSH поддерживает более сложные схемы конфигурации, включая ограничение доступа к группам или нескольким пользователям одновременно.
Двенадцать советов по повышению безопасности Linux
Мы живём в опасное время: едва ли не каждый день обнаруживаются новые уязвимости, на их основе создают эксплойты, под ударом может оказаться и обычный домашний компьютер на Linux, и сервер, от которого зависит огромная организация.
Возможно, вы уделяете внимание безопасности и периодически обновляете систему, но обычно этого недостаточно. Поэтому сегодня мы поделимся двенадцатью советами по повышению безопасности Linux-систем на примере CentOS 7.
Защита терминала
Для того, чтобы повысить безопасность системы, можно защитить консольный доступ к ней, ограничив root-пользователя в использовании определённых терминалов. Сделать это можно, задав терминалы, которые может использовать суперпользователь, в файле /etc/securetty .
Рекомендуется, хотя это и не обязательно, позволить суперпользователю входить в систему только из одного терминала, оставив остальные для других пользователей.
Напоминания о смене пароля
В наши дни сложный пароль — вещь совершенно необходимая. Однако, ещё лучше, когда пароли регулярно меняют. Об этом легко забыть, поэтому хорошо бы задействовать какой-нибудь системный механизм напоминаний о возрасте пароля, и о том, когда его надо поменять.
Мы предлагаем вам два способа организации подобных напоминаний. Первый заключается в использовании команды chage , второй — в установке необходимых значений по умолчанию в /etc/login.defs .
Вызов команды chage выглядит так:
Тут мы используем ключ -M для того, чтобы установить срок истечения актуальности пароля в днях.
Использовать эту команду можно и без ключей, тогда она сама предложит ввести необходимое значение:
Второй способ заключается в модификации файла /etc/login.defs . Вот пример того, как могут выглядеть интересующие нас значения. Вы можете изменить их на те, которые нужны вам:
Помните о том, что вам, если вы играете роль администратора, следует способствовать тому, чтобы пользователи применяли сложные пароли. Сделать это можно с помощью pam_cracklib.
После установки этой программы, вы можете перейти в /etc/pam.d/system-auth и ввести примерно следующее:
Уведомления sudo
Команда sudo , с одной стороны, упрощает жизнь, а с другой, может стать причиной проблем с безопасностью Linux, которые могут привести к непоправимым последствиям. Настройки sudo хранятся в файле /etc/sudoers . С помощью этого файла можно запретить обычным пользователям выполнять некоторые команды от имени суперпользователя. Кроме того, можно сделать так, чтобы команда sudo отправляла электронное письмо при её использовании, добавив в вышеупомянутый файл следующее:
Также надо установить свойство mail_always в значение on :
Защита SSH
Если мы говорим о безопасности Linux, то нам стоит вспомнить и о службе SSH. SSH — это важная системная служба, она позволяет удалённо подключаться к системе, и иногда это — единственный способ спасти ситуацию, когда что-то идёт не так, поэтому об отключении SSH мы тут не говорим.
Тут мы используем CentOS 7, поэтому конфигурационный файл SSH можно найти по адресу etc/ssh/sshd_config . Сканеры или боты, которых используют атакующие, пытаются подключиться к SSH по используемому по умолчанию порту 22.
Распространена практика изменения стандартного порта SSH на другой, неиспользуемый порт, например, на 5555 . Порт SSH можно изменить, задав нужный номер порта в конфигурационном файле. Например, так:
Кроме того, можно ограничить вход по SSH для root-пользователя, изменив значение параметра PermitRootLogin на no :
И, конечно, стоит отключить аутентификацию с применением пароля и использовать вместо этого публичные и приватные ключи:
Теперь поговорим о тайм-аутах SSH. Проблему тайм-аутов можно решить, настроив некоторые параметры. Например, следующие установки подразумевают, что пакеты, поддерживающие соединение, будут автоматически отправляться через заданное число секунд:
Настроив эти параметры, вы можете увеличить время соединения:
Можно указать то, каким пользователям разрешено использовать SSH:
Разрешения можно назначать и на уровне групп:
Защита SSH с использованием Google Authenticator
Для ещё более надёжной защиты SSH можно использовать двухфакторную аутентификацию, например, задействовав Google Authenticator. Для этого сначала надо установить соответствующую программу:
Затем запустить её для проверки установки:
Так же нужно, чтобы приложение Google Authenticator было установлено на вашем телефоне.
Отредактируйте файл /etc/pam.d/sshd , добавив в него следующее:
Теперь осталось лишь сообщить обо всём этом SSH, добавив следующую строку в файл /etc/ssh/sshd_config :
Теперь перезапустите SSH:
Когда вы попытаетесь войти в систему с использованием SSH, вам предложат ввести код верификации. Как результат, теперь SSH-доступ к вашей системе защищён гораздо лучше, чем прежде.
Мониторинг файловой системы с помощью Tripwire
Tripwire — это замечательный инструмент для повышения безопасности Linux. Это — система обнаружения вторжений (HIDS).
Задача Tripwire заключается в том, чтобы отслеживать действия с файловой системой, следить за тем, кто меняет файлы, и когда происходят эти изменения.
Для того, чтобы установить Tripwire, нужен доступ к репозиторию EPEL. Это задача несложная, решить её можно следующими командами:
После установки репозитория EPEL, вы сможете установить и Tripwire:
Теперь создайте файл ключей:
Вам предложат ввести сложный пароль для файла ключей. После этого можно настроить Tripwire, внеся изменения в файл /etc/tripwire/twpol.txt . Работать с этим файлом несложно, так как каждая строка оснащена содержательным комментарием.
Когда настройка программы завершена, следует её инициализировать:
Инициализация, в ходе которой выполняется сканирование системы, займёт некоторое время, зависящее от размеров ваших файлов.
Любые модификации защищённых файлов расцениваются как вторжение, администратор будет об этом оповещён и ему нужно будет восстановить систему, пользуясь файлами, в происхождении которых он не сомневается.
По этой причине необходимые изменения системы должны быть подтверждены с помощью Tripwire. Для того, чтобы это сделать, используйте следующую команду:
И вот ещё одна рекомендация, касающаяся Tripwire. Защитите файлы twpol.txt и twcfg.txt . Это повысит безопасность системы.
У Tripwire есть множество параметров и установок. Посмотреть справку по ней можно так:
Использование Firewalld
Firewalld — это замена для iptables , данная программа улучшает сетевую безопасность Linux. Firewalld позволяет вносить изменения в настройки, не останавливая текущие соединения. Файрвол работает как сервис, который позволяет добавлять и менять правила без перезапуска и использует сетевые зоны.
Для того, чтобы выяснить, работает ли в настоящий момент firewalld , введите следующую команду:

Просмотреть предопределённые сетевые зоны можно так:

Каждая из этих зон имеет определённый уровень доверия.
Это значение можно обновить следующим образом:
Получить подробные сведения о конкретной зоне можно так:
Просмотреть список всех поддерживаемых служб можно следующей командой:

Затем можно добавлять в зону новые службы или убирать существующие:
Можно вывести сведения обо всех открытых портах в любой зоне:
Добавлять порты в зону и удалять их из неё можно так:
Можно настраивать и перенаправление портов:
Firewalld — это весьма продвинутый инструмент. Самое примечательное в нём то, что он может нормально работать, например, при внесении изменений в настройки, без перезапусков или остановок службы. Это отличает его от средства iptables , при работе с которым службу в похожих ситуациях нужно перезапускать.
Переход с firewalld на iptables
Некоторые предпочитают файрвол iptables файрволу firewalld . Если вы пользуетесь firewalld , но хотите вернуться к iptables , сделать это довольно просто.
Сначала отключите firewalld :
Затем установите iptables :
Теперь можно запустить службу iptables :
После всего этого перезагрузите компьютер.
Ограничение компиляторов
Атакующий может скомпилировать эксплойт на своём компьютере и выгрузить его на интересующий его сервер. Естественно, при таком подходе наличие компиляторов на сервере роли не играет. Однако, лучше ограничить компиляторы, если вы не используете их для работы, как происходит в большинстве современных систем управления серверами.
Для начала выведите список всех бинарных файлов компиляторов из пакетов, а затем установите для них разрешения:

Создайте новую группу:
Затем измените группу бинарных файлов компилятора:
И ещё одна важная вещь. Нужно изменить разрешения этих бинарных файлов:
Теперь любой пользователь, который попытается использовать gcc , получит сообщение об ошибке.
Предотвращение модификации файлов
Иммутабельные файлы не может перезаписать ни один пользователь, даже обладающий root-правами. Пользователь не может модифицировать или удалить такой файл до тех пор, пока установлен флаг иммутабельности, снять который может лишь root-пользователь.
Несложно заметить, что эта возможность защищает вас, как суперпользователя, от ошибок, которые могут нарушить работу системы. Используя данный подход, можно защитить конфигурационные файлы или любые другие файлы по вашему желанию.
Для того, чтобы сделать любой файл иммутабельным, воспользуйтесь командой chattr :

Атрибут иммутабельности можно удалить такой командой:

Так можно защищать любые файлы, но помните о том, что если вы обработали таким образом бинарные системные файлы, вы не сможете их обновить до тех пор, пока не снимите флаг иммутабельности.
Управление SELinux с помощью aureport
Нередко система принудительного контроля доступа SELinux оказывается, по умолчанию, отключённой. Это не влияет на работоспособность системы, да и работать с SELinux довольно сложно. Однако, ради повышения безопасности, SELinux можно включить, а упростить управление этим механизмом можно, используя aureport .
Утилита aureport позволяет создавать отчёты на основе лог-файлов аудита.

Список исполняемых файлов можно вывести следующей командой:

Можно использовать aureport для создания полного отчёта об аутентификации:

Также можно вывести сведения о неудачных попытках аутентификации:

Или, возможно, сводку по удачным попыткам аутентификации:

Утилита aureport значительно упрощает работу с SELinux.
Использование sealert
В дополнение к aureport вы можете использовать хороший инструмент безопасности Linux, который называется sealert . Установить его можно так:
Теперь у нас есть средство, которое будет выдавать оповещения из файла /var/log/audit/audit.log и даст нам дополнительные сведения о проблемах, выявленных SELinux.
Использовать его можно так:

Самое интересное тут то, что в оповещениях можно найти советы о том, как решать соответствующие проблемы.
Итоги
Надеемся, приведённые здесь советы помогут вам сделать вашу установку Linux безопаснее. Однако, если речь идёт о защите информации, нельзя, применив те или иные меры, считать, что теперь вам ничто не угрожает. К любым программным средствам защиты всегда стоит добавлять бдительность и осторожность.
Уважаемые читатели! Знаете ли вы какие-нибудь простые, но неочевидные способы повышения безопасности Linux?
How To Protect SSH With Fail2Ban on CentOS 7

While connecting to your server through SSH can be very secure, the SSH daemon itself is a service that must be exposed to the Internet to function properly. This comes with some inherent risk and offers a vector of attack for would-be assailants.
Any service that is exposed to the network is a potential target in this way. If you pay attention to application logs for these services, you will often see repeated, systematic login attempts that represent brute-force attacks by users and bots alike.
A service called Fail2ban can mitigate this problem by creating rules that automatically alter your iptables firewall configuration based on a predefined number of unsuccessful login attempts. This will allow your server to respond to illegitimate access attempts without intervention from you.
In this guide, we’ll cover how to install and use Fail2ban on a CentOS 7 server.
Install Fail2ban on CentOS 7
While Fail2ban is not available in the official CentOS package repository, it is packaged for the EPEL project. EPEL, standing for Extra Packages for Enterprise Linux, can be installed with a release package that is available from CentOS:
You will be prompted to continue—press y, followed by Enter:
Now we should be able to install the fail2ban package:
Again, press y and Enter when prompted to continue.
Once the installation has finished, use systemctl to enable the fail2ban service:
Configure Local Settings
The Fail2ban service keeps its configuration files in the /etc/fail2ban directory. There, you can find a file with default values called jail.conf . Since this file may be overwritten by package upgrades, we shouldn’t edit it in-place. Instead, we’ll write a new file called jail.local . Any values defined in jail.local will override those in jail.conf .
jail.conf contains a [DEFAULT] section, followed by sections for individual services. jail.local may override any of these values. Additionally, files in /etc/fail2ban/jail.d/ can be used to override settings in both of these files. Files are applied in the following order:
- /etc/fail2ban/jail.conf
- /etc/fail2ban/jail.d/*.conf , alphabetically
- /etc/fail2ban/jail.local
- /etc/fail2ban/jail.d/*.local , alphabetically
Any file may contain a [DEFAULT] section, executed first, and may also contain sections for individual jails. The last vavalue set for a given parameter takes precedence.
Let’s begin by writing a very simple version of jail.local . Open a new file using nano (or your editor of choice):
Paste the following:
This overrides three settings: It sets a new default bantime for all services, makes sure we’re using iptables for firewall configuration, and enables the sshd jail.
Exit and save the new file (in nano , press Ctrl-X to exit, y to save, and Enter to confirm the filename). Now we can restart the fail2ban service using systemctl :
The systemctl command should finish without any output. In order to check that the service is running, we can use fail2ban-client :
You can also get more detailed information about a specific jail:
Explore Available Settings
The version of jail.local we defined above is a good start, but you may want to adjust a number of other settings. Open jail.conf , and we’ll examine some of the defaults. If you decide to change any of these values, remember that they should be copied to the appropriate section of jail.local and adjusted there, rather than modified in-place.
Default Settings for All Jails
First, scroll through the [DEFAULT] section.
You can adjust the source addresses that Fail2ban ignores by adding a value to the ignoreip parameter. Currently, it is configured not to ban any traffic coming from the local machine. You can include additional addresses to ignore by appending them to the end of the parameter, separated by a space.
The bantime parameter sets the length of time that a client will be banned when they have failed to authenticate correctly. This is measured in seconds. By default, this is set to 600 seconds, or 10 minutes.
The next two parameters that you want to pay attention to are findtime and maxretry . These work together to establish the conditions under which a client should be banned.
The maxretry variable sets the number of tries a client has to authenticate within a window of time defined by findtime , before being banned. With the default settings, Fail2ban will ban a client that unsuccessfully attempts to log in 3 times within a 10 minute window.
If you wish to configure email alerts, you may need to override the destemail , sendername , and mta settings. The destemail parameter sets the email address that should receive ban messages. The sendername sets the value of the “From” field in the email. The mta parameter configures what mail service will be used to send mail.
This parameter configures the action that Fail2ban takes when it wants to institute a ban. The value action_ is defined in the file shortly before this parameter. The default action is to simply configure the firewall to reject traffic from the offending host until the ban time elapses.
If you would like to configure email alerts, you can override this value from action_ to action_mw . If you want the email to include the relevant log lines, you can change it to action_mwl . You’ll want to make sure you have the appropriate mail settings configured if you choose to use mail alerts.
Settings for Individual Jails
After [DEFAULT] , we’ll encounter sections configuring individual jails for different services. These will typically include a port to be banned and a logpath to monitor for malicious access attempts. For example, the SSH jail we already enabled in jail.local has the following settings:
In this case, ssh is a pre-defined variable for the standard SSH port, and %(sshd_log)s uses a value defined elsewhere in Fail2ban’s standard configuration (this helps keep jail.conf portable between different operating systems).
Another setting you may encounter is the filter that will be used to decide whether a line in a log indicates a failed authentication.
The filter value is actually a reference to a file located in the /etc/fail2ban/filter.d directory, with its .conf extension removed. This file contains the regular expressions that determine whether a line in the log is bad. We won’t be covering this file in-depth in this guide, because it is fairly complex and the predefined settings match appropriate lines well.
However, you can see what kind of filters are available by looking into that directory:
If you see a file that looks to be related to a service you are using, you should open it with a text editor. Most of the files are fairly well commented and you should be able to tell what type of condition the script was designed to guard against. Most of these filters have appropriate (disabled) sections in jail.conf that we can enable in jail.local if desired.
For instance, pretend that we are serving a website using Nginx and realize that a password-protected portion of our site is getting slammed with login attempts. We can tell Fail2ban to use the nginx-http-auth.conf file to check for this condition within the /var/log/nginx/error.log file.
This is actually already set up in a section called [nginx-http-auth] in our /etc/fail2ban/jail.conf file. We would just need to add an enabled parameter for the nginx-http-auth jail to jail.local :
And restart the fail2ban service:
Monitor Fail2ban Logs and Firewall Configuration
It’s important to know that a service like Fail2ban is working as-intended. Start by using systemctl to check the status of the service:
If something seems amiss here, you can troubleshoot by checking logs for the fail2ban unit since the last boot:
Next, use fail2ban-client to query the overall status of fail2ban-server , or any individual jail:
Follow Fail2ban’s log for a record of recent actions (press Ctrl-C to exit):
List the current rules configured for iptables:
Show iptables rules in a format that reflects the commands necessary to enable each rule:
Conclusion
You should now be able to configure some basic banning policies for your services. Fail2ban is very easy to set up, and is a great way to protect any kind of service that uses authentication.
If you want to learn more about how Fail2ban works, you can check out our tutorial on how fail2ban rules and files work.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.