Firewall без магии: закрыть всё и открыть ровно нужное
Цикл «Не светим лишнего». Выпуск 2.
Firewall часто воспринимают как стену с кучей дырок-портов. На практике полезнее думать о нём как о списке решений: этот пакет относится к такой-то сессии, пришёл отсюда, идёт туда, значит его пропускаем или выбрасываем.
Начальная позиция для защищаемого контура простая: если разрешающего правила нет, соединение не должно пройти. Это и есть default deny. Не «мы запретили несколько плохих адресов», а «мы разрешили только то, что понимаем».
Сначала не перепутаем input и forward
На MikroTik и большинстве других маршрутизаторов есть принципиальная разница.
Input — трафик к самому маршрутизатору. WinBox, SSH RouterOS, API, DNS на роутере, ICMP к его адресу. Если мы защищаем управление MikroTik, работаем здесь.
Forward — трафик, проходящий через маршрутизатор. Например, внешний клиент идёт через DNAT на RDP-сервер или внутреннюю веб-панель. Пакет адресован не самому MikroTik, он только проходит через него.
Типовая ошибка выглядит так: администратор добавляет красивое правило в input, проверяет, что WinBox закрыт, и считает, что опубликованный сервер тоже защищён. А DNAT спокойно продолжает работать через forward.
NAT не является разрешением сам по себе
DNAT отвечает на вопрос «куда переписать адрес назначения». Firewall отвечает на вопрос «пустить ли пакет дальше». Лучше держать эту логику раздельно.
Допустим, внешний 203.0.113.10:10443 переводится на внутренний 10.20.30.15:443. Это ещё не значит, что доступ должен быть разрешён всем. В forward можно потребовать одновременно:
- вход с WAN;
- состояние нового соединения;
- нужный внутренний адрес и порт после DNAT;
- наличие источника в группе
access-monitoring; - логирование начала соединения.
Тогда NAT остаётся постоянным, но без членства в разрешённой группе ресурс выглядит закрытым.
Группы лучше отдельных исключений
Если ресурсов больше двух, не стоит строить правила вокруг фамилий и разовых адресов. Удобнее завести сущности по смыслу:
- назначения
protected-monitoring,protected-dev,protected-cctv; - источники
access-admin,access-developer,access-contractor; - отдельные цепочки или правила для HTTP, SSH, RDP и управления.
Тогда пользователь или портал добавляет адрес в готовую группу. Он не получает возможность придумать себе произвольный destination. Это сильно снижает шанс, что ошибка административной панели превратится в «открыли человеку всю серверную сеть».
Плюсы обычного firewall
- работает с любыми IP-протоколами и не зависит от приложения;
- почти везде уже есть;
- поведение можно увидеть счётчиками и логами;
- хорошо масштабируется через группы адресов;
- не требует установки чего-либо на клиент.
Минусы
Главный минус — firewall обычно не знает человека. Он знает IP-адрес, иногда интерфейс, VLAN, сертификат туннеля или метку соединения. Если два пользователя выходят через один NAT, для обычного L3/L4-фильтра они выглядят одинаково.
Вторая проблема — правила статичны, пока кто-то или что-то их не изменит. Человеческие исключения имеют свойство оставаться навсегда.
Где можно больно ошибиться
Порядок правил. Firewall идёт сверху вниз. Широкий accept раньше точного drop делает точный drop декоративным.
Established, related. Состояние соединений удобно: не приходится заново проверять каждый ответный пакет. Но если правило accept established,related стоит выше проверки актуального access-list, уже открытый SSH или RDP может продолжить работу после удаления адреса из списка.
FastTrack. Он ускоряет обработку established-соединений, пропуская часть обычного пути firewall. Для трафика, который должен отключаться немедленно при отзыве разрешения, FastTrack нужно либо обходить, либо продумывать очистку connection tracking.
IPv6. Можно идеально закрыть IPv4 и оставить тот же сервер доступным по глобальному IPv6. Проверяем оба стека или сознательно отключаем неиспользуемый.
Управление самим маршрутизатором. REST API, WinBox и SSH не должны торчать в Интернет просто потому, что «там сложный пароль». Управление лучше вынести в отдельный адрес/VRF/VLAN и ограничить источники.
Слишком широкая группа назначения. Открывать /16, потому что нужный сервер находится где-то внутри, — плохая экономия строк конфигурации.
Когда этого достаточно
Обычный firewall отлично решает задачу, если источники стабильны и хорошо известны: офисы, площадки, внешние сервисы, собственный VPN-шлюз. Для людей с динамическими адресами ему нужен ещё один слой: временный список, портал, knocking или другая система, которая будет решать, кого и на сколько добавлять.