База данных fail2ban слишком большая (более 500 МБ). Как уменьшить ее до разумного размера?

В последнее время мои резервные копии начали выходить из строя, и я выяснил, что проблема связана с файлом /var/lib/fail2ban/fail2ban.sqlite3. Он составляет более 500 МБ. Я не уверен, увеличивался ли он со временем или это новое явление.

Как можно привести его к разумному размеру и поддерживать его на этом уровне? (Для этих целей предположим, что он должен быть менее 500 МБ.)

В fail2ban.conf есть параметр dbpurgeage, который указывает, сколько дней данных хранить в базе данных. По умолчанию это один день (1d), поэтому попробуйте уменьшить его до пары часов:

dbpurgeage = 8h

Эта настройка связана с findtime: нет смысла иметь findtime дольше, чем dbpurgeage.

Правка (2021): Примечание ниже было верным на момент написания. Однако в настоящее время посмотрите ответ neingeist: fail2ban 0.11.x, который доступен в дистрибутивах Linux (например, Debian 11 и позже, Ubuntu 20.04 и позже и позже, Fedora 33 и позже), соблюдает настройку dbpurgeage.

Устаревшее примечание: В моей собственной базе данных fail2ban настройка dbpurgeage, похоже, не работает. Поэтому единственное решение — удалять записи вручную. Например, чтобы удалить записи за прошлый год, выполните:

sqlite3 /var/lib/fail2ban/fail2ban.sqlite3 \
  "DELETE FROM bans WHERE DATE(timeofban, 'unixepoch') < '2020-01-01'; VACUUM;"

(исполняемый файл sqlite3 обычно находится в одноимённом пакете).

Похоже, нет возможности выполнить VACUUM базы данных без того, чтобы sqlite не сделал копию базы данных в том же каталоге. Однако вы можете скопировать файл в другую файловую систему перед выполнением операции, а затем скопировать обратно меньшую базу данных.

Вы можете обновиться до версии 0.11.x (которая содержит код для очистки), затем удалить огромную базу данных и перезапустить fail2ban. Это воссоздаст базу данных. Это самое простое решение без недостатков для большинства пользователей.

Хотя в fail2ban 0.11.x действительно содержится код для удаления старых записей (в более ранней версии его не было!), он не выполняет VACUUM. Поэтому другой вариант — дождаться, пока fail2ban очистит старые записи (это происходит каждый час), и вручную выполнить sqlite3 /var/lib/fail2ban/fail2ban.sqlite3 "VACUUM;". Без VACUUM файл базы данных останется того же размера.

1. Используя GNU date, простая shell команда

В дополнение к правильному ответу Петра П. Карваза я бы показал свою простую синтаксис shell, использующую GNU date (не BSD date):

Сначала покажите статистику таблицы bans:

sqlite3 fail2ban.sqlite3 'SELECT count(timeofban) FROM bans'
1147784
sqlite3 fail2ban.sqlite3 "SELECT count(timeofban) FROM bans
      WHERE timeofban < `date -d 'now -1 month' +%s`;"
1129083

Выполнение перевода UNIXEPOCH на уровне параметра командной строки быстрее, так как sqlite не нужно переводить каждую строку!

• Сравните:

  time sqlite3 fail2ban.sqlite3 "SELECT count(timeofban) FROM bans
     WHERE DATE(timeofban, 'unixepoch') < '$(date -d 'now -1 month' +'%F %T')';"
  

  94074
  real    0m0.427s
  user    0m0.363s
  sys     0m0.060s
  

  С:

  time sqlite3 fail2ban.sqlite3 "SELECT count(timeofban) FROM bans
     WHERE timeofban < $(date -d 'now -1 month' +%s);"
  

  93709
  
  real    0m0.169s
  user    0m0.121s
  sys     0m0.045s
  

  Где использование DATE() для каждого ряда делает эту операцию почти в 3 раза медленнее! (Результат отличается, потому что DATE() округляется до дня, в то время как GNU date возвращает EPOCH в секундах.)

Конечно, ответ на вашем компьютере будет другим!

Затем

sqlite3 fail2ban.sqlite3 "DELETE FROM bans WHERE 
        timeofban < $(date -d 'now -1 month' +%s); VACUUM;"

(Не пропустите VACUUM;!)

Основное преимущество использования команды date с временным интервалом заключается в том, что это можно разместить в периодическом сценарии.

Примечание: Я предпочитаю запускать это с now -1 month в качестве временного интервала каждую ночь.

2. Без GNU date, используя синтаксис sqlite3:

Изучая справочник sqlite, я, наконец, нашел правильный синтаксис:

sqlite3 fail2ban.sqlite3 "DELETE FROM bans
     WHERE timeofban <= STRFTIME('%s', DATE('now', '-1 month'));VACUUM;"

Еще раз: Используя этот синтаксис, sqlite3 будет выполнять перевод по запросу, а не на строках!!

Замечание о crontabs

Если вы планируете написать это в crontab, не забудьте экранировать все знаки процентов!!

1 2 * * * root /usr/bin/sqlite3 /var/lib/fail2ban/fail2ban.sqlite3 "delete from bans where timeofban <= strftime('\%s', date('now', '-42 days'));vacuum;"

Будет выполняться каждую ночь в 02:01. Команда также может быть добавлена в BASH-скрипт в /etc/cron.weekly, например.

sudo /etc/init.d/fail2ban stop

sudo rm -rf /var/lib/fail2ban

sudo /etc/init.d/fail2ban start

sudo reboot

решило все для меня. проверьте после перезагрузки

df -h

у меня было 25 ГБ файлов sqlite, память была 94% от 40 ГБ

Я в итоге пошел по альтернативному пути уменьшения логов.

Потому что я создал собственный код, который суммирует IP-адреса, используя простые правила.

Дан диапазон IP: если более 25% IP в списке в журналах Fail2ban, я удалю отдельные IP и заблокирую весь диапазон.

Затем я проверю более крупные и крупные диапазоны IP, если все еще более 25% IP принадлежит заблокированному диапазону, то заблокированный диапазон увеличивается.

Я использовал собственное дерево для решения, так как оно ищет в дереве, используя IP-адрес, чтобы выяснить, может ли дерево быть уменьшено.

Математика для расчета области поиска требует некоторой доработки, но в целом именно так я заблокировал 2 китайских, 1 иранского и 1 российского провайдера.

И поскольку были повторные нарушители, таймер, который их снимет с блок-листа, отсутствует.