Как сохранить внешние IP-адреса через шлюз, чтобы продолжать использовать Fail2Ban
У меня есть коробка CentOS 7 с двумя сетевыми адаптерами, выступающими в качестве шлюза; одна сетевая карта подключена к Интернету, а другая сетевая карта подключена к нашей локальной сети.
Первая сетевая карта принадлежит «внешней» зоне firewalld, она маскируется и настроена на пересылку портов 22, 80 и 443 тем ящики внутри внутренней сети, которые управляют SSH и веб-серверами; предположим, что из Интернета ящик отображается как «example.com» по адресу «1.2.3.4», а его имя в локальной сети - «gateway.lan» с адресом «192.168.1.1».
Все работает, со значительной оговоркой; поскольку мы хотим иметь возможность подключаться через SSH, используя Интернет-имя ящика (ssh example.com), также из локальной сети (где SSH-ящик называется "server.lan" и имеет адрес 192.168.1.10), единственный способ сделать эту работу, похоже, устанавливает правило во «внутренней» зоне firewalld, перенаправляющее все обращения к порту 22 из «1.2.3.4» обратно на порт 22 SSH-бокса:
internal (active)
target: default
icmp-block-inversion: no
interfaces: XXXXXX
sources:
services: dns
ports:
protocols:
masquerade: yes
forward-ports:
source-ports:
icmp-blocks:
rich rules:
rule family="ipv4" destination address="1.2.3.4" forward-port port="22" protocol="tcp" to-port="22" to-addr="192.168.1.10"
Одно правило не работает, если не используется маскировка включен для «внутренней» зоны; к сожалению, это также, очевидно, приводит к тому, что внешние IP-адреса, которые забивают этот ящик, пытаясь подобрать пароль root, отображаются как исходящие из «192.168.1.1» (адрес «gateway.lan») в журналах «server.lan», что делает невозможным использование Fail2Ban в поле "server.lan", чтобы препятствовать тысячам попыток доступа в день.
Что я делаю не так? Я думаю, что включение маскировки во «внутреннюю» зону концептуально неверно, но я не мог найти другого способа заставить работать правило firewalld. Я без колебаний продолжаю маскировку, но я хотел бы знать, как можно заставить Fail2Ban работать, когда он находится за шлюзом ...
Любые советы по поводу любого другого способа заставить такую конфигурацию работать как я ' м ожидаете?
Ах, мы сделали это! И это было относительно просто (ну, если вы знаете, как) ...
Мы правильно предположили, что маскировка во "внутренней" зоне не должна быть включена глобально, а должна быть ограничена пакетами, исходящими из LAN, которые направляются к общедоступному IP.
Это означает, что не следует включать его без разбора с помощью - add-masquerade для всей зоны, а использовать masquerade ВНУТРИ конкретного расширенного правила, в следующем form:
firewall-cmd --zone=internal --permanent --add-rich-rule='rule family=ipv4 source address=192.168.1.0/24 destination address=192.168.1.10 masquerade'
Некоторое время нас вводил в заблуждение тот факт, что мы настаивали на использовании общедоступного IP-адреса «1.2.3.4» в качестве «адреса назначения» вместо внутреннего «192.168.1.10» в правиле; мы не поняли, что, проходя через «внутреннюю» зону, пакеты, нацеленные на порт 22 из «1.2.3.4», уже конвертируются с помощью правила rich в LAN-адрес блока SSH. Более того, этот синтаксис НЕ позволяет указывать порт.
Окончательный статус для "внутренней" зоны следующий:
internal (active)
target: default
icmp-block-inversion: no
interfaces: XXXXXX
sources:
services: dns
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
rule family="ipv4" destination address="1.2.3.4" forward-port port="22" protocol="tcp" to-port="22" to-addr="192.168.1.10"
rule family="ipv4" source address="192.168.1.0/24" destination address="192.168.1.10" masquerade
который:
- правильно перенаправляет доступ SSH из Интернета в блок SSH - конечно, это также требует во «внешней» зоне правила пересылки для порта 22 к тому же порту на «внутреннем»;
- позволяет компьютерам LAN безразлично использовать SSH в поле с его публичным или LAN-именем;
- не маскирует адреса злонамеренных попыток SSH из Интернета на компьютер, чтобы Fail2Ban мог выполнять свою работу.
Ура!