Периметр после Code Red: минимальный рабочий набор правил iptables

После августовской волны Code Red и Nimda к нам пошли звонки примерно одного содержания: «хотим файрвол на периметре». Не «хотим разобраться с безопасностью вообще» - именно файрвол, именно на периметре. Хорошо хоть спрашивают, а не ставят что попало сами.

Большинство клиентских сетей в этот момент выглядят так: есть Linux-машина, которая раздаёт NAT и смотрит одним интерфейсом в интернет, вторым - в локалку. Ядро 2.4, то есть iptables уже на борту. Это хорошая отправная точка - не нужно отдельное железо, не нужен коммерческий продукт. Нужно написать правила.

Вот что мы делаем в базовой конфигурации.

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

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

OUTPUT пока оставляем открытым - с исходящим трафиком разберёмся отдельно. INPUT и FORWARD - на запрет. Теперь всё, что не вписано в правила, просто не проходит.

Второе - разрешить уже установленные соединения. Без этого сломается всё: запрос уходит, ответ не приходит. conntrack решает:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

Третье - разрешить нужные порты. Здесь всё зависит от того, что реально торчит наружу. Типовой набор для офисного периметра, где внутри есть почтовый сервер и веб:

iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 25 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A FORWARD -p tcp --dport 80 -j ACCEPT
iptables -A FORWARD -p tcp --dport 443 -j ACCEPT

SSH - только для управления, и обычно мы сразу добавляем ограничение по источнику: -s <ip администратора>. 25-й - если сервер принимает почту напрямую. 80 и 443 - только если есть веб-сервер, который обслуживает внешних пользователей. Всё остальное - не открываем. 135, 137, 139, 445 - Windows-порты - не открываем вообще никогда. 3389 (RDP) наружу - не открываем. Это как раз то, через что Code Red и его братья ходили в незакрытых конфигурациях.

Четвёртое - защита от флуда. Несложная, но работающая:

iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT

SYN-флуд - классическая атака, которая валит TCP-стек, просто отправляя миллион запросов на открытие соединения. Ограничение через --limit не решает проблему полностью, но существенно снижает нагрузку. ICMP-ограничение на ping - туда же, заодно убирает часть зонд-трафика.

Пятое - логировать то, что дропается. Хотя бы первое время:

iptables -A INPUT -j LOG --log-prefix "FW-DROP: " --log-level 4

Иначе не видно, что стучится и не проходит. Через неделю логи дадут понять, не заблокировали ли что-то нужное, и что реально ходит по периметру.

Это минимум. Не идеал, не законченная архитектура - но это то, что можно поднять за час и что сразу даёт контроль над тем, что проходит через шлюз.

Про что стоит сразу договориться с клиентом: файрвол - это первая линия, не единственная. Он не заменяет патчи на сервисах, антивирус внутри сети, нормальные пароли. Если IIS без патча стоит за файрволом и 80-й открыт наружу - Code Red всё равно придёт. Файрвол отсекает случайный шум и ограничивает радиус поражения, но не заменяет остальную гигиену.

Часть клиентов после этого разговора просит не просто настроить правила один раз, а чтобы кто-то следил за состоянием периметра на постоянной основе. Это уже отдельная история - в рамках сопровождения мы включаем проверку правил файрвола в регламентные работы. Потому что правила, написанные однажды и забытые, - это не намного лучше, чем их отсутствие.

Один из недавних кейсов с Code Red наглядно показал: клиенты, у которых 80-й порт не был проброшен на внутренний сервер, вообще не заметили волны. Им просто не было что атаковать. Это не хитрая защита - это закрытый порт. Файрвол, настроенный правильно, даёт именно это.

Набор правил сохраняем в /etc/iptables.rules, восстанавливаем при старте через iptables-restore. Скрипт инициализации в /etc/network/if-up.d/ - чтобы правила поднимались автоматически после ребута. Потому что если они слетают при перезагрузке, то первые секунды после старта сервис торчит без защиты - и этого достаточно.