Довела, що блокування вторгнень працює щоразу

Ситуація. Службу блокування зловмисників уже ловили на тому, що вона блокувала порт, на якому демон SSH не слухав. Виправлення порту закрило той конкретний випадок, але ніяк не зачепило причини, з якої помилка проіснувала так довго: збій на шляху блокування нічим себе не виявляє — служба працює, jail значиться активним, і ніщо ніде не показує, чи доходить до ядра хоч одне блокування.

Завдання. Шлях блокування треба було випробовувати під час кожного converge на живому наборі правил, а не робити висновок про його справність лише з того, що служба запущена.

Дія. Тепер converge блокує адресу з діапазону, який стандарти резервують для документації, зчитує з фільтра пакетів ядра правило, що з’явилося, і знімає блокування в блоці очищення, який виконується незалежно від того, пройшла перевірка чи ні. Ключовий вибір тут — зарезервований діапазон: тестова адреса нікому не належить, тож випадкове блокування, яке переживе невдалий прогін, не відріже справжню мережу. Друга половина — зчитування з ядра: власний вивід стану служби повідомив би про успішне блокування, навіть якщо воно не створило жодного правила, а це саме той збій, який і перевіряють. Крім того, механізм блокування закріплено явно, а не залишено на автовизначення службою, а джерело журналу, навпаки, переведено на автовизначення, бо операційна система не постачає традиційного журналу автентифікації, а за хибного вибору служба мовчки ламається, стежачи за файлом, який ніколи не з’явиться.

Результат. Якщо шлях блокування перестає працювати, converge тепер обривається, а не звітує й далі про справність, — і лише ця властивість насправді мала значення. Це коштує кількох секунд на кожному прогоні, а ще щоразу додає й прибирає правило брандмауера на продакшні — тобто справді втручається в живу систему; на це пішли, бо альтернатива вже довела, що вона гірша.