Политика default deny

Почему это рекомендуемый вариант по умолчанию везде

Политика default deny безопасно "падает": всё, что вы забыли явно разрешить, просто не пройдёт, а не останется незаметно открытым. Противоположный вариант, default allow, "падает" в открытую сторону, то есть любое забытое правило оставляет дыру.

Чего это стоит на практике

Каждый легитимный сервис требует явного правила, прежде чем начнёт работать, а значит политика default deny требует реально понимать, что должен делать ваш сервер. Именно эта начальная цена делает её эффективной.

Пошаговую настройку default deny с сохранением доступа по SSH см. здесь: руководство по файрволу в Linux.

Где задаётся политика по умолчанию в каждом инструменте

В каждом инструменте файрвола Linux есть место, где задаётся политика по умолчанию, и она применяется только к пакетам, под которые не подошло ни одно правило. Поэтому важен порядок работы: сначала напишите правила разрешения, затем переключайте политику.

• ufw: ufw default deny incoming. В руководстве сказано, что команда default принимает направление: incoming, outgoing или routed.
• iptables: iptables -P INPUT DROP. В руководстве iptables(8) указано, что целью политики встроенной цепочки может быть только ACCEPT или DROP.
• nftables: policy drop; в объявлении базовой цепочки, как в примере для сервера на вики nftables.

Перед переключением цепочки iptables или nftables на drop убедитесь, что есть два правила: одно разрешает установленные и связанные соединения, чтобы ответы вашей же SSH-сессии продолжали проходить, а другое разрешает интерфейс loopback, через который общаются локальные службы. В примере nftables оба правила стоят раньше остальных.

Считайте политику страховкой, а не единственным правилом. Цепочку с policy drop и завершающим явным правилом drop или reject с журналированием проще отлаживать, потому что видно, что было отклонено. Точные команды для ufw и nftables есть в руководстве по файрволу в Linux.

Как включить политику и не потерять доступ

На удалённом сервере главный риск это потерянная SSH-сессия. Из оболочки root сохраните текущие правила и запустите таймер, который их вернёт, а затем меняйте политику:

iptables-save > /root/fw.backup
(sleep 120; iptables-restore < /root/fw.backup) &
iptables -P INPUT DROP

Откройте второе SSH-соединение. Если оно работает, отмените фоновое задание командой kill %1 и сохраните правила на постоянной основе. Если доступ потерян, через две минуты таймер вернёт прежние правила. Это работает, потому что iptables-restore заменяет текущее содержимое каждой восстанавливаемой таблицы, если не указан --noflush. Многие провайдеры также предоставляют веб-консоль, и лучше найти её заранее.

Затем проверьте снаружи. NIST SP 800-41 Rev. 1 говорит, что по умолчанию нужно блокировать весь входящий и исходящий трафик, не разрешённый явно, называет этот подход "deny by default" и считает его более безопасным, чем разрешение всего, что явно не запрещено. Правило распространяется и на IPv4, и на IPv6, поэтому проверяйте оба. Там же рекомендуется включать в проверку набора правил ручной просмотр и тестирование.

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

Связанные термины: Firewall, ufw, iptables, nftables.