Fail2Ban_AbuseIPDB 1.1.1: отчёты в AbuseIPDB и ключ в файле

Проект Fail2Ban_AbuseIPDB отделяет блокировку от жалобы: fail2ban по-прежнему мгновенно закрывает адрес локально, а действие abuseipdb-async лишь пишет событие в очередь SQLite, откуда отдельный обработчик раз в 16 минут собирает доказательства и отправляет отчёты в AbuseIPDB. Релиз 1.1.1 от 20 октября 2026 года — патч установщика, и правка там буквально одна: строка api_key_file при обновлении конфигурации дописывалась в конец файла, то есть внутрь последнего раздела, а не в [abuseipdb]. На первый взгляд мелочь, но именно из-за неё заданный вручную путь к ключу мог быть проигнорирован, а сам файл оставался формально валидным — то есть ошибка не кричала, а тихо ждала. Всё остальное — ключ в отдельном файле, самообновление, очередь и список джейлов — принесено предыдущим релизом 1.1.0 в тот же день.

TL;DR

• Fail2Ban_AbuseIPDB 1.1.1 от 20.10.2026 — патч установщика, между ним и 1.1.0 один коммит и восемь файлов.
• Исправлено место строки api_key_file при обновлении конфигурации: теперь она вставляется в конец раздела [abuseipdb], а существующая строка заменяется на месте.
• Повторный запуск установщика поверх испорченной конфигурации её чинит: лишняя строка удаляется, правильная пишется в нужный раздел.
• Обновление — sudo abuseipdb-upgrade --check, затем --upgrade; ключ, конфигурация, очередь и список джейлов сохраняются.
• Кому не нужно: тем, у кого в reporter.conf уже есть api_key_file или кто пользуется путём ключа по умолчанию.

Что нового

Разбор начинается с того, как установщик правит конфигурацию. Если в файле ещё не было строки api_key_file — типичный случай при переходе с ранней версии, — установщик добавлял её в конец файла. А конец файла в INI-конфигурации принадлежит тому разделу, который оказался последним; в примере из проекта это [category_map], где живёт сопоставление джейлов категориям AbuseIPDB. Синтаксически файл оставался корректным, парсер не падал, и потому проблема не проявлялась как ошибка.

Практическое последствие узкое, но реальное. Сам репортёр всегда брал путь по умолчанию, поэтому «штатная» установка работала. Ломался сценарий, ради которого ключ вообще вынесли в отдельный файл: если администратор задал свой путь через --key-file, в этом краевом случае репортёр его не видел — настройка лежала в чужом разделе. Теперь строка вставляется в конец [abuseipdb], а если она там уже есть — заменяется на месте, без дублей.

Второе исправление — эксплуатационное: установщик, запущенный повторно поверх такой конфигурации, приводит её в порядок. Лишняя строка удаляется, правильная записывается в [abuseipdb]. Это важно, потому что вручную такую поломку искать неприятно: файл выглядит целым, reporter.conf проходит проверку прав, а ключ «почему-то не тот».

Что	Было	Стало
Место api_key_file при обновлении	конец файла, внутрь последнего раздела (например [category_map])	конец раздела [abuseipdb]
Существующая строка api_key_file	могла дублироваться	заменяется на месте
Повторная установка поверх испорченного файла	ничего не исправляла	удаляет лишнюю строку и пишет правильную
Парсер конфигурации и путь ключа по умолчанию	работали	без изменений

Ключевые изменения

Что	Подробность
Версия	1.1.1 от 20.10.2026, между 1.1.0 и 1.1.1 — 1 коммит, 8 файлов
Затронуто	только установщик и работа с конфигурацией
Не затронуто	парсер конфигурации, путь ключа по умолчанию, обработчик, очередь
Кому важно	тем, кто задаёт --key-file своим путём и обновляется с версии без api_key_file
Как починить	повторный запуск установщика или abuseipdb-upgrade --upgrade

Файлы в релизе

Файл	Размер	SHA-256
Fail2Ban_AbuseIPDB-1.1.1.tar.gz	73 КБ (74 267 байт)	4d612d52ff3be034cff0303d4d913ab5f9891c08be41157b9390f232facd77a3
updater.json (в репозитории)	—	тот же SHA-256 для архива

Контрольная сумма сверена: скачанный архив даёт ровно 4d612d52…77a3 и 74 267 байт, то есть updater.json описывает именно опубликованный файл. Архив — не способ первой установки: его документированный потребитель — abuseipdb-upgrade, который проверяет сумму и запускает вложенный install.sh. Ручная установка из скачанного архива в репозитории не описана.

Как обновиться

Обновление сделано отдельной командой, которая сама сверяет SHA-256, распаковывает архив безопасно, сохраняет и восстанавливает файл ключа, а затем запускает штатный установщик.

sudo abuseipdb-upgrade --check
sudo abuseipdb-upgrade --upgrade

--check возвращает 0, если версия актуальна, и 10, если есть обновление; --upgrade без --yes на неинтерактивном запуске откажется работать, а --dry-run покажет шаги, ничего не меняя. Ключ, конфигурация, очередь и список джейлов при обновлении сохраняются — как и в 1.1.0.

Если установка первая, берётся закреплённый тег, а не ветка:

git clone --branch v1.1.1 --depth 1 https://github.com/paulmann/Fail2Ban_AbuseIPDB.git
cd Fail2Ban_AbuseIPDB
sudo ./install.sh --api-key "$ABUSEIPDB_API_KEY" --jails "sshd"

Что проверить после обновления

fail2ban-client get sshd actions
/usr/local/sbin/abuseipdb-report --key-status
/usr/local/sbin/abuseipdb-report --stats
systemctl list-timers abuseipdb-report.timer

Критерий «работает»: в списке действий джейла рядом с nftables есть abuseipdb-async; --key-status называет источник ключа и показывает его замаскированным; --stats печатает счётчики pending events, pending ips, reports today, reports total; таймер abuseipdb-report.timer существует и запланирован. В здоровой установке в /var/log/abuseipdb-reporter.log появляются строки вида reported ip=... -> 200 {...}. Если в конфигурации остался мусор от прежней версии, его уберёт повторный запуск установщика:

sudo ./install.sh --jails "sshd" --no-restart

Совместимость и требования

Параметр	Значение
ОС	Linux с systemd (рекомендуется) или cron
Python	3.9+, только стандартная библиотека
Fail2Ban	0.10+ (проверено с 1.1.0)
Права	root: установщик пишет в /etc, /usr/local, /var/lib
Доступ в сеть	HTTPS к api.abuseipdb.com:443, raw.githubusercontent.com и github.com для updater.json и архива
Ключ API	бесплатный в кабинете AbuseIPDB; без него установщик падает с no API key
Лицензия	MIT

Ритм задан с запасом от бесплатного тарифа: не чаще одного отчёта по одному адресу за 20 минут, до 25 отчётов за прогон, до 900 в сутки, при официальных 1000 запросах в день и одном отчёте на адрес в 15 минут. Очередь хранится 30 дней, попыток на событие — до 10.

Кому это нужно

Первый сценарий — парк серверов, где fail2ban уже стоит и уже блокирует, а жалобы в AbuseIPDB либо не отправляются вовсе, либо отправляются через curl внутри действия блокировки, из-за чего медленный API тормозит баны. Второй — узкий, но типичный случай самого патча: хост обновляли с ранней версии, ключ лежит своим путём через --key-file, и после установки отчёты уходят от чужого имени или не уходят вовсе, хотя конфигурация выглядит правильной.

Подводные камни

• Жалобы в AbuseIPDB публичны и не удаляются. Прежде чем включать широкие джейлы, внесите свои адреса управления и диапазоны CDN в [ignore] ranges: отчёт по собственному адресу отменить нельзя, а тестовая блокировка через fail2ban-client set <jail> banip обходит ignoreip и тоже приведёт к жалобе.
• --dry-run не полностью безобиден. Он не обращается к API и не помечает события отправленными, но открывает базу очереди и применяет чистку по retention_days — то есть на прогоне с истёкшими событиями данные исчезнут.
• Повторные отчёты после перезагрузки означают, что действие подключено дважды: fail2ban-client get <jail> actions покажет abuseipdb-async два раза, и один из сниппетов надо убрать.
• Ответ 429 с текстом «once in 15 minutes» — не авария. Это тот же адрес уже отправлялся с этого аккаунта; событие остаётся в очереди до следующего окна.
• Ручная установка из архива не документирована. Если хочется ставить из скачанного .tar.gz руками, вы идёте вне описанного пути: штатный потребитель архива — abuseipdb-upgrade.

FAQ

Итог

1.1.1 — образцовый патч: одна строка, названная причина, названное последствие и способ починки без переустановки. Ценность его не в функциональности, а в том, что он закрывает класс ошибок, которые не видно глазами: файл валиден, права в порядке, а настройка лежит не там. Если хост уже на 1.1.0 с ключом по умолчанию, обновляться не обязательно; если ключ задан своим путём и обновление шло с ранней версии — стоит и обновиться, и один раз посмотреть в reporter.conf, где оказалась строка.

Цитата: Конфигурация, которая парсится без ошибок, ещё не значит правильная: строка, лежащая в чужом разделе, тихо отменяет настройку, ради которой её и добавляли.

Связанные материалы

• Fail2Ban_AbuseIPDB v1.1.1 — релиз на GitHub — заметки к релизу и архив 73 КБ.
• AGENTS.md — установка и проверка для агентов — предусловия, опции установщика, коды выхода и таблица типовых сбоев.
• docs/UPDATE.md — как работает самообновление — манифест, семантика --check/--upgrade, откат.
• CHANGELOG.md — что принесли 1.0.0 и 1.1.0 — очередь, ключ в отдельном файле, самообновление, 88 тестов.

LLM Summary

• Тема: Fail2Ban_AbuseIPDB — асинхронный репортёр блокировок fail2ban в AbuseIPDB через локальную очередь SQLite; релиз 1.1.1 исправляет установщик.
• Версия: v1.1.1, опубликована 20 октября 2026 года, лицензия MIT; между 1.1.0 и 1.1.1 один коммит и восемь файлов.
• Что изменилось: строка api_key_file вставляется в конец раздела [abuseipdb] вместо конца файла, существующая заменяется на месте, повторная установка чинит испорченную конфигурацию.
• Ключевые команды: sudo abuseipdb-upgrade --check (10 — есть обновление), sudo abuseipdb-upgrade --upgrade, abuseipdb-report --key-status, abuseipdb-report --stats, fail2ban-client get sshd actions.
• Требования: Linux с systemd или cron, Python 3.9+ без внешних пакетов, Fail2Ban 0.10+, root, ключ AbuseIPDB, HTTPS к api.abuseipdb.com.
• Основные риски: отчёты публичны и не удаляются, поэтому адреса управления должны быть в [ignore] ranges; --dry-run всё равно применяет чистку по retention_days; двойное подключение действия даёт повторные отчёты.
• Проверка результата: в действиях джейла есть abuseipdb-async, --key-status называет источник ключа, --stats печатает счётчики очереди, таймер запланирован, в логе есть reported ip=... -> 200.
• Кому полезно: администраторам Linux-серверов с fail2ban, которым нужны аргументированные жалобы на атакующие адреса без задержек в пути блокировки.
• Ссылки: https://github.com/paulmann/Fail2Ban_AbuseIPDB/releases/tag/v1.1.1, https://github.com/paulmann/Fail2Ban_AbuseIPDB

Промт для агента (установка)

Готовый промт для AI-агента: скопируйте блок целиком кнопкой и отдайте своему ассистенту. Шаги и команды взяты из файла AGENTS.md в репозитории проекта — это инструкция, которую автор написал для агентов, а не пересказ.

Задача: установить Fail2Ban_AbuseIPDB 1.1.1 на Linux-хост, привязать действие к джейлу sshd и убедиться, что отчёты уходят.

Материалы:
- релиз: https://github.com/paulmann/Fail2Ban_AbuseIPDB/releases/tag/v1.1.1
- репозиторий: https://github.com/paulmann/Fail2Ban_AbuseIPDB
- инструкция для агентов (прочитать первой): https://github.com/paulmann/Fail2Ban_AbuseIPDB/blob/main/AGENTS.md
- обновление и откат: docs/UPDATE.md в репозитории

Предусловия (§2). Непройденная строка — стоп, а не обход:
uname -s
id -u
python3 --version
fail2ban-client --version
systemctl is-active fail2ban
fail2ban-client status
ls -l /var/lib/fail2ban/fail2ban.sqlite3
curl -sS -o /dev/null -w '%{http_code}' https://api.abuseipdb.com/api/v2/check

Установка первой версией (§3.1): тег закреплён, установщик запускается из каталога проекта.
git clone --branch v1.1.1 --depth 1 https://github.com/paulmann/Fail2Ban_AbuseIPDB.git
cd Fail2Ban_AbuseIPDB
sudo ./install.sh --api-key "$ABUSEIPDB_API_KEY" --jails "sshd"

Порядок на боевом хосте (§6), шаг не пропускать:
sudo ./install.sh --help
sudo ./install.sh --dry-run --api-key "$ABUSEIPDB_API_KEY" --jails "sshd"
sudo ./install.sh --root /tmp/stage --api-key "$ABUSEIPDB_API_KEY" --jails "sshd" --cron --skip-api-check --no-restart
sudo ./install.sh --jails "sshd"

Проверка (§3.3):
fail2ban-client get sshd actions
/usr/local/sbin/abuseipdb-report --key-status
/usr/local/sbin/abuseipdb-report --stats
systemctl list-timers abuseipdb-report.timer

Обновление (§3.1 заметок к релизу):
sudo abuseipdb-upgrade --check
sudo abuseipdb-upgrade --upgrade

Ограничения:
- не банить тестовые адреса через fail2ban-client set <jail> banip: это обходит ignoreip, а отчёты публичны и не удаляются;
- адреса управления и диапазоны CDN внести в [ignore] ranges до включения широких джейлов;
- --dry-run не отправляет отчёты, но применяет чистку по retention_days: на боевой очереди не запускать без предупреждения;
- не ставить из скачанного архива вручную: его документированный потребитель — abuseipdb-upgrade;
- если команда падает — остановиться и показать команду, вывод и код возврата.

Что считать успехом: в fail2ban-client get sshd actions рядом с nftables есть abuseipdb-async; --key-status называет источник ключа; --stats печатает счётчики pending events, pending ips и reports today; таймер abuseipdb-report.timer запланирован; в /var/log/abuseipdb-reporter.log есть строка reported ip=... -> 200.