###
  • Интернет
  • Программы
  • Игры
  • Проблемы
  • Windows
  • Социальные сети
  • Android
  • Ios

    • Как защитить SSH подключение на Linux сервере. Отключаем доступ от рута

    31.08.2020 Проблемы

    Одной из распространённых атак на службу SSH является атака методом перебора, когда удалённый атакующий бесконечно пытается залогиниться с различными паролями. Конечно, есть аргументы против аутентификации с помощью паролей для SSH, и есть альтернативные механизмы аутентификации, такие существующие варианты как аутентификация с публичным клюём или двух-факторная аутентификация сведут на нет атаку брут-форсингом. Не в даваясь в дискуссию о преимуществах и недостатках различных методов аутентификации, давайте рассмотрим ситуацию, когда необходима аутентификация паролем. Как вы защитите ваш SSH сервер против атак грубой силой?

    fail2ban - это хорошо известный, с открытым кодом фреймворк по предотвращению вторжений для Linux, он мониторит различные лог-файлы системы (например, /var/log/auth.log or /var/log/secure) и автоматически задействуют различные способы защиты против выявленных подозрительных действий. На самом деле, fail2ban может быть очень полезен для защиты против атак по перебору паролей на SSH сервер.

    В этом уроке я продемонстрирую как установить и настроить fail2ban для защиты SSH сервера против атак брут-форсингом с удалённых IP адресов .

    Установка Fail2ban на Linux

    Для установки fail2ban на CentOS или RHEL, сначала, установите репозиторий EPEL, и затем выполните следующую команду.

    Для установки fail2ban на Fedora, просто запустите:

    $ sudo yum install fail2ban

    Для установки fail2ban на Ubuntu, Debian или Linux Mint:

    $ sudo apt-get install fail2ban

    Настройка Fail2ban для SSH сервера

    Сейчас вы готовы для конфигурирования fail2ban для усиления вашего SSH сервера. Вам нужно отредактировать конфигурационный файл в /etc/fail2ban/jail.conf. Конфигурационный файл содержит секцию “DEFAULT”, где вы определяете параметры по умолчанию для всех сервисов, которые мониторятся, и специфичные для каждого сервиса секции, где вы определяете любые специфичные для сервиса джэйлы (например SSH, Apache и т. д.) для перезаписи параметров по умолчанию.

    В секции джейлов определённых сервисов (где-то после секции ) вам нужно задать секцию , где вы зададите особые настройки для джэйлов SSH. Текущий бан IP адресов делается iptables.

    Последующий пример в /etc/fail2ban/jail.conf, который содержит настройку джэйла “ssh-iptables”. Конечно, там могут быть и другие джейлы для разных приложений, в зависимости от ваших нужд.

    $ sudo vi /etc/fail2ban/jail.local # разделённый пробелами список IP адресов, CIDR префиксов или DNS имён хостов # для обхода защиты fail2ban ignoreip = 127.0.0.1 172.31.0.0/24 10.10.0.0/24 192.168.0.0/24 # количество секунд, на которое блокируется клиент bantime = 86400 # количество неудачных попыток, после которых происходит блокировка maxretry = 5 # количество секунд в течение которых накопительно фиксируются неудачные попытки findtime = 600 mta = sendmail enabled = true filter = sshd action = iptables sendmail-whois # для основанных на Debian дистрибутивов logpath = /var/log/auth.log # для основанных на Red Hat дистрибутивах logpath = /var/log/secure # специфичный для ssh порог максимальных попыток maxretry = 3

    В соответствии с приведённой конфигурацией, fail2ban будет автоматически банить любые удалённые IP адреса, с которых поступило хотя бы 3 неудачных попытки за последние 10 минут. Однажды забаненный, IP нарушителя будет оставаться заблокированным в течение 24 часов. Уведомление об этом событии будет отправлено по почте.

    После того, как конфигурационный файл готов, перезапустите службу fail2ban как показано ниже.

    На Debian, Ubuntu или CentOS/RHEL 6:

    $ sudo service fail2ban restart

    На Fedora или CentOS/RHEL 7:

    $ sudo systemctl restart fail2ban

    Чтобы проверить, успешно ли запущен fail2ban, выполните команду fail2ban-client с аргументом “ping”. Если служба fail2ban запущена нормально, вы должны увидеть ответ “pong”.

    $ sudo fail2ban-client ping Server replied: pong

    Тестирование защиты с Fail2ban на SSH от атаки перебором паролей

    Чтобы проверить, работает ли fail2ban, попробуйте войти на сервер SSH используя неверный пароль для симуляции брут-форс атаки. В то же время, проверяйте /var/log/fail2ban.log, который записывает все интересные события, которые происходят в fail2ban.

    $ sudo tail -f /var/log/fail2ban.log

    Согласно логу выше, fail2ban забанил IP адрес 192.168.1.8, поскольку выявил множественные ошибки в попытка залогиниться на SSH с этого IP адреса.

    Проверка статуса Fail2ban и разблокировка заблокированных IP адресов

    Джейл “ssh-iptables” в fail2ban использует iptables для блокировки IP адресов нарушителей, вы можете легко проверить бан, посмотрев текущие правила iptables как показано ниже.

    $ sudo iptables --list -n Chain INPUT (policy ACCEPT) target prot opt source destination fail2ban-SSH tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain fail2ban-SSH (1 references) target prot opt source destination DROP all -- 192.168.1.8 0.0.0.0/0 RETURN all -- 0.0.0.0/0 0.0.0.0/0

    Если вы хотите разблокировать IP адреса от fail2ban, вы можете также выполнить команду iptables:

    $ sudo iptables -D fail2ban-SSH -s 192.168.1.8 -j DROP

    В то время, как вы можете проверять и управлять списком заблокированных IP в fail2ban вручную с помощью команд iptables, как было показано, верным способом, на самом деле, является использование инструмента командной строки ail2ban-client. Этот инструмент позволяет вам управлять не только джэйлом “ssh-iptables”, но также любыми другими типами джэйлов fail2ban в унифицированным интерфейсе командной строки.

    Для проверки статуса fail2ban (который покажет список активных в настоящее время джейлов):

    $ sudo fail2ban-client status

    Чтобы проверить статус конкретного джейла (например, ssh-iptables):

    $ sudo fail2ban-client status ssh-iptables

    Вышеприведённая команда покажет список забаненных IP адресов.

    Для разблокировки конкретного IP адреса:

    $ sudo fail2ban-client set ssh-iptables unbanip 192.168.1.8

    Обратите внимание, если вы остановите fail2ban, все заблокированные IP адреса будут разблокированы. Когда вы перезапустите fail2ban, он найдёт список IP адресов нарушителей из /var/log/secure (или /var/log/auth.log) и перезабанит эти IP адреса, если не истекло время бана.

    Установка Fail2ban на автозагрузку и включении

    После того, как вы успешно протестировали fail2ban, последним шагов по задействованию fail2ban является автоматический запуск при включении питания сервера. На основанных на Debian дистрибутивах, автозапуск fail2ban включен по умолчанию. На основанных на Red Hat дистрибутивах, включите автостарт следующим способом.

    На CentOS/RHEL 6:

    $ sudo chkconfig fail2ban on

    На Fedora или CentOS/RHEL 7:

    $ sudo systemctl enable fail2ban

    Итог

    В этом уроке я продемонстрировал как установить и настроить fail2ban для защиты SSH сервера. Хотя fail2ban может смягчить атаку перебором паролей, пожалуйста помните, он не может защитить SSH сервера против сложных (распределённых) кампаний по брут-форсингу, когда атакующие обходят fail2ban используя тысячи подконтрольных ботам IP адресов.

    В этой короткой заметке я собрал воедино способы повышения защищённости ssh сервера. Описаны самые основные и простые в исполнении приёмы, а более сложные лишь указаны для интересующихся читателей

    Основные приёмы

    Все действия производятся в конфигурационном файле sshd демона -- /etc/ssh/sshd_config . Ниже приведу часть своего конфигурационного файла с комментариями.

    ### Network ### # Используем нестандартный порт (>1024) port 5679 # Используем только IPv4 соединения # inet = IPv4, inet6 = IPv6, any = both AddressFamily inet # Можно принимать соединения только с определённых IP-адресов #ListenAddress 0.0.0.0 # Используем вторую версию протокола, т.к. первая подвержена # известным уязвимостям Protocol 2 # Отключаем перенаправление графики (X-сервер) до тех пор # пока она явно не понадобится вам X11Forwarding no # Отключаем Disable TCPKeepAlive и используем ClientAliveInterval вместо этого, # чтобы предотвратить атаки типа TCP Spoofing TCPKeepAlive no # Выкидваем пользователя через 10min (600 sec) неактивности ClientAliveInterval 600 ClientAliveCountMax 3 ### Key configuration files ### # HostKeys для протокола версии 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key # Используем непривилегированный процесс для # обработки входящего от клиента трафика # sandbox - openSSH >= 5.9 ("yes" - для младших версий) UsePrivilegeSeparation sandbox # При изменении этих значений, требует удалить старый ключ # /etc/ssh/ssh_host_rsa_key{,.pub}, и создать новый # путём перезапуска sshd. # # Время жизни ключа, т.е. через какое время будет сгененрирован новый ключ # в случае, если предыдущий был использован. KeyRegenerationInterval 1h # сила ключа ServerKeyBits 2048 # Разрешаем авторизацию по публичному ключу PubkeyAuthentication yes # Место хранения доверенных ключей в каталоге пользователя AuthorizedKeysFile .ssh/authorized_keys ### Logging ### # Префикс для syslog SyslogFacility AUTH # уровень подробности сообщений для самого sshd LogLevel INFO ### Authentication ### # список разрешённых пользователей AllowUsers ivan # ограничиваем время для ввода пароля для ssh-ключа LoginGraceTime 30s # запрещаем удалённо входить под учётной записью root PermitRootLogin no # Включаем явную проверку прав файлов и директорий с ssh-ключами StrictModes yes # Сколько раз переспрашивать пароль при неверном вводе MaxAuthTries 3 # Запрещаем вход по пустому паролю PermitEmptyPasswords no # Запрещаем вход по паролю в принципе # (Используем публичный/приватный ключ вместо этого) PasswordAuthentication no # Отключаем использование "challenge-responce" авторизацию, # т.к. она бесполезна при использовании ключей ChallengeResponseAuthentication no # Так как мы не используем пароль, то и {PAM, login(1)} нам не нужены UsePAM no UseLogin no # Позволяем клиенту передавать лишь определённый набор переменных окружения # RH BZ#CVE-2014-2532 # ShellShock exploit AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT AcceptEnv LC_IDENTIFICATION LC_ALL

    Это те параметры, что настраиваются в конфигурационном файле sshd. После изменения настроек требуется перезапустить сервис sshd.

    Комментарии

    • При использовании авторизации по ключу, ключ требуется предварительно сгенерировать на клиентской машине и скопировать публичный ключ на сервер. Пример:
    client $ ssh-keygen client $ cat ~/.ssh/id_rsa.pub | ssh -p 5679 [email protected] "cat >> ~/.ssh/authorized_keys"
    • В файле /var/log/auth.log будут находиться сообщения от sshd . В случае, если этот файл отсутствует, вам требуется настроить вашу систему логирования. пример для syslog и syslon-ng . Я использую syslog-ng , и мне потребовалось добавить следующие строки в файл /etc/syslog-ng/syslog-ng.conf:
    destination authlog { file("/var/log/auth.log"); }; log { source(src); destination(authlog); };

    и перезапустить сервис syslog-ng .

    • При использовании нестандартного порта может потребоваться настроить ваш firewall (iptables, firewalld, etc).
      Пример настройки для iptables:
    root# iptables -A INPUT -p tcp -m state --state NEW,ESTABLISHED --dport 5679 -j ACCEPT root# service iptables save root# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW,ESTABLISHED tcp dpt:5679 ...

    Если этого мало

    Это лишь базовые настройки. Дополнительно можно настроить

    • firewall (iptables)

    Для зашиты нашего сервера от перебора паролей можно воспользоваться утилитами sshguard или sshit.

    Принципы работы.

    sshguard и sshit работают по одному принципу. Анализируют системные сообщения о неверной аутентификации и в случае достижения определенного значения заносят атакующий ip в блокирующее правило файервола. Через определенное время ip из правила удаляется.
    Соответсвенно для работы необходим настроенный файервол.

    SSHGuard

    sshguard умеет работать с

    • AIX native firewall - for IBM AIX operating systems
    • netfilter/iptables - for Linux-based operating systems
    • Packet Filter (PF) - for BSD operating systems (Open, Free, Net, DragonFly -BSD)
    • IPFirewall (IPFW) - for FreeBSD and Mac OS X
    • IP Filter (IPFILTER) - for FreeBSD, NetBSD and Solaris
    • tcpd"s hosts_access (/etc/hosts.allow) - portable across UNIX
    • null - portable do-nothing backend for applying detection but not prevention

    Я использую PF поэтому в заметке примеры на PF.

    Установка sshguard.

    FreeBSD:

    Устанавливаем из портов

    Cd /usr/ports/security/sshguard-pf/&& make install clean

    Если по каким-то причинам Вы не используете порты, скачайте последнию версию с сайта sshguard и соберите в ручную

    ./configure --with-firewall=pf && make && make install

    Debian:

    apt-get install sshguard

    Настройка ОС для работы sshguard.

    Создаем файл для хранения логов

    # touch /var/log/sshguard

    Debian (wheezy):

    Редактируем в //etc/default/sshguard следующую строчку

    #mcedit /etc/default/sshguard #ARGS="-a 40 -p 420 -s 1200" ARGS="-a 5 -p 420 -s 2400 -b 5:/etc/sshguard/blacklist"

    и перезапускаем sshguard
    service sshguard restart

    FreeBSD:

    Нам необходимо добавить две строки в конфигурацию PF

    Table persist

    объявляем таблицу куда sshguard вносит ip роботов.

    Block in quick on $if0 proto tcp from

    Собственно само блокирующее правило, его стоит разметить на самом верху блока правил конфигурационного файла PF. $if0 интерфейс на котором будут блокироваться подключения, для блокировки на всех интерфейсах замените на any.
    Перечитайте файл конфигурации

    Auth.info;authpriv.info |exec/usr/local/sbin/sshguard

    и перезапустите syslog

    #/etc/rc.d/syslogd restart

    Собственно после этих манипуляций sshguard будет блокировать атаки с параметрами по умолчанию.
    При атаке в /var/log/auth.log мы увидим примерно следующие

    Jun1611:01:40 www sshd:Invalid user test from61.172.251.183Jun1612:29:48 www sshd:Invalid user test from85.114.130.168Jun1612:29:49 www sshd:Invalid user test from85.114.130.168Jun1612:29:49 www sshd:Invalid user test from85.114.130.168Jun1612:29:50 www sshd:Invalid user test from85.114.130.168Jun1612:29:50 www sshguard:Blocking85.114.130.168:4for>420secs:4 failures over 2 seconds.

    Настройка параметров sshguard

    sshguard имеет ряд параметров которые мы можем переопределить
    -a количество неудачных попыток аутентификации после которого ip будет заблокирован. По умолчанию 4.
    -p через сколько секунд ip будет разблокирован. По умолчанию 420.
    -s сколько секунд sshguard помнит ip. По умолчанию 1200. Чтоб было понятней если с ip идет одна атака в 30 минут то он ни когда не попадет в бан при дефолтовой настройке.
    -w белые ip, сети, или путь к файлу белых адресов. Формат файла одна строка - одна запись, # определяет комментарии.
    -b определяет через сколько блокировок ip будет добавлен в черный список и путь до него. Черный список загружается при старте sshguard и автоматически не очищается.

    у sshguard нет файла конфигурации параметры задаются при старте sshguard. В нашем случае sshguard пускается syslog поэтому отредактируем syslog.conf так, что sshguard будет блокировать ip после 3 неудачных попыток аутонтификации на 30 минут, а после 5 блокировок заносить его в черный список.

    Auth.info;authpriv.info |exec/usr/local/sbin/sshguard -a 3-p 1500-b 5:/usr/local/etc/sshguard.blacklist

    первый раз блокируется на 420 секунд и удаляется через 7 минут
    второй раз на 2*420 у удаляется через 14 минут
    третий раз на 2*2*420 и удаляется через 28 минут и тд...
    2^(N-1)*420 N-й раз.

    Sshit

    Sshit - это perl скрипт соответственно необходимо чтобы в системе был perl, а так же 2 модуля

    • IPC::Shareable
    • Proc::PID::File

    Sshit умеет работать только с pf и ipfw.

    Установка sshit

    cd /usr/ports/security/sshit/&& make install clean

    Конфигации sshit.

    Sshit имеет конфигурационный файл /usr/local/etc/sshit.conf в котором можно переопредилить значения по умолчанию.

    FIREWALL_TYPE ="pf"; # Какой firewall используем MAX_COUNT =3; # Количество неудачных попыток аутентификации после которого ip блокируется WITHIN_TIME =60; # В течении сколько секунд должно произойти заданное кол-во неудачных аутентификаций RESET_IP =300; # Через сколько секунд ip будет разблокирован. PFCTL_CMD ="/sbin/pfctl"; PF_TABLE ="badhosts"#имя таблицы куда заносятся плохие ip

    Настройка ОС для работы sshit.

    По аналогии с настройкой под sshguard редактируем файл конфигурации PF

    Table persist block in quick on $if0 proto tcp from to $if0 port ssh label "ssh brute"

    перечитываем конфигурационный файл

    #pfctl -f /etc/pf.conf

    Редактируем syslog.conf

    Auth.info;authpriv.info |exec/usr/local/sbin/sshit

    и перезапустите syslog

    Несколько правил по защите доступ к ssh серверу.

    1. Добавляем в конфигурацию ssh сервера слушать еще один порт, помимо стандартного. (Для простоты запоминания можно использовать 4 повторяющихся цифры для всех своих серверов).

    $ sudo vi /etc/ssh/sshd_config Port 22 Port xxxx

    2. Ограничиваем обращения на 22 порт только доверенным ip адресам *например 8.8.8.8 (таких правил сделать можно несколько, работа/дом)

    $ sudo vi /etc/sysconfig/iptables -A INPUT -s 8.8.8.8 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

    3. Не забываем проверить не используется ли у нас ipv6, если используется, то закрываем лишнее

    $ sudo vi /etc/sysconfig/ip6tables *filter:INPUT ACCEPT :FORWARD ACCEPT :OUTPUT ACCEPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p ipv6-icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A INPUT -j REJECT --reject-with icmp6-adm-prohibited -A FORWARD -j REJECT --reject-with icmp6-adm-prohibited COMMIT

    Для того, чтобы использовать ssh только на определенном адресе достаточно в файле конфигурации sshd_config указать парметр ListenAddress (например ListenAddress 74.125.200.100). В таком случае ssh будет доступен только на этом адресе и не будет работать через ipv6

    4. Используем файл конфигурация ssh на стороне клиента.

    Расположение: ~/.ssh/config

    # fix Write failed: broken pipe ServerAliveInterval 120 TCPKeepAlive no # для использования коротких имен Host dev-vps # ip адрес или публичное доменное имя хоста Hostname 127.0.0.3 # Под каким юзером осуществлять вход User developer # Файл ключа для авторизации (если используется) IdentityFile ~/.ssh/id_rsa.dev

    И еще один пример использования файла конфигурации:
    {<1>}

    Host ssh-server-1 Hostname 1.2.3.4 User dev Port 1234 Host ssh-server-2 User root # Hostname 192.168.10.20 # nc without -q0 if RHEL based & with -q0 debian based IdentityFile ~/.ssh/id_rsa.work-pc ProxyCommand ssh -q0 ssh-server-1 nc -q0 192.168.10.20 22

    И теперь при подключении на ssh-server-1 мы сразу прыгнем на нужны нам хост. (Удобно использовать например при разных ключах на серверах)

    А так-же хипстерский прокси вариант:

    {<2>}

    Скачиваем клиент ngrok на сервер, который находится за файерволом. Запускаем бинарник и указываем какой порт нам нужно пробросить

    Стоит «засветиться» сервису в общедоступной сети, как мгновенной он становится объектом для атаки. Одна из проблем – попытка получения доступа с помощью перебора паролей (брутфорса). И SSH в данном случае не исключение.

    Анализ файла логов аутентификации /var/log/auth.log или аналогов показывает, что попытка подбора пароля обычно производится сразу с нескольких IP и растянута по времени.

    Защита от Брутфорса SSH

    Защититься от этого можно по-разному:

    • Используя возможности настройки демона SSH
    • Пакетный фильтр
    • Специальные приложения
    • Port knocking

    Самый простой и действенный способ – это изменить 22-й порт, используемый по умолчанию, например, на 2002-й, если это не мешает другим задачам. Вносим запись в /etc/ssh/sshd_config:

    После этого попытки подбора паролей практически прекращаются. Бывают случаи, когда изменить порт нельзя. Как вариант, можно ограничить доступ по SSH определенным пользователям (в частности, root) или группе. В sshd_config за это отвечает ряд параметров: AllowUsers, AllowGroups, DenyUsers и DenyGroups. Удобно, что с логином можно указать IP или подсеть. Например, разрешим доступ пользователю admin и user, последнему только с одного IP:

    Еще один действенный вариант защиты от перебора – использование для аутентификации сертификатов. Причем с помощью специального параметра match можно создать условный блок, в котором переопределить параметры глобальной секции. Например, запретим вход по SSH по паролю для пользователя root, разрешив всем остальным:

    # всем разрешаем доступ по паролю
    PasswordAuthentication yes
    # root будет использовать только сертификат
    match user root
    PasswordAuthentication no
    KbdInteractiveAuthentication no

    Используя TCP Wrapper, также можем ограничить доступ к любому сервису только с определенных IP, для этого следует лишь прописать в файл /etc/hosts.allow или /etc/hosts.deny нужное правило. Разрешим в /etc/hosts.allow доступ только с нужной подсети:

    sshd: 192.168.1.0/24: allow

    Или в /etc/hosts.deny:

    sshd: ALL: deny
    sshd: ALL EXCEPT 192.168.1.0/24: allow

    Пакетный фильтр позволяет очень точно задавать параметры соединений, отбрасывая ненужные пакеты. С его помощью легко ограничить доступ к 22-му порту только определенным адресам. Простой пример:

    iptables -A INPUT -s !192.168.0.1 -p tcp -m tcp --dport 22 ↵
    -j REJECT -reject-with icmp-port-unreachable

    Фильтрация пакетов по портам и IP-адресам не очень эффективна, если Aдмин не привязан к рабочему месту. В этом случае помогут специальные утилиты: Fail2ban , Sshguard . Fail2ban изначально разрабатывался для защиты SSH. Хотя сегодня это уже фреймворк, который можно легко настроить под любые приложения. Принцип работы очень прост. Демон периодически проверяет журналы на наличие записей о любых подозрительных действиях. Затем подозрительный IP-адрес блокируется средствами iptables или TCP Wrapper. Через указанное в настройках время блокировка обычно снимается, чтобы случайно не заблокировать легальный узел. При срабатывании правила записывается событие в журнал /var/log/fail2ban.log, и может быть отправлен email.

    Один процесс может контролировать сразу несколько сервисов, а в пакете поставляются готовые настройки для популярных приложений Linux. В настройках по умолчанию защищается только SSH.

    В Ubuntu и Debian устанавливается командой:

    $ sudo apt-get install fail2ban

    Все настройки производятся в нескольких файлах, размещенных в каталоге /etc/fail2ban. В fail2ban.conf хранятся параметры запуска самого демона, в jail.conf описываются контролируемые сервисы (внутри секции SSH).

    Enabled = true
    port = 22
    filter = sshd
    logpath = /var/log/auth.log
    maxretry = 3

    Фильтры и действия прописываются в файлах, размещенных в подкаталогах filter.d и action.d. По умолчанию все файлы имеют расширение.conf, их лучше не трогать (в т.ч. и jail.conf). Все изменения следует заносить в файл с расширением.local (например, jail.local), параметры которого замещают установки из первого, а при обновлении не будут потеряны. Для проверки работы фильтра можно использовать утилиту fail2ban-regex.