Как сохранить внешние IP-адреса через шлюз, чтобы продолжать использовать Fail2Ban

У меня есть CentOS 7 с двумя сетевыми картами, выступающими в качестве шлюза; один сетевой адаптер подключен к Интернету, а другой - к нашей локальной сети.

Первый сетевой адаптер принадлежит к "внешней" зоне firewalld, он имеет маскировку и настроен на перенаправление портов 22, 80 и 443 на те блоки внутри внутренней сети, которые управляют SSH и веб-серверами; скажем, из Интернета поле появляется как "ex ample.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, появляются в журнале "server.lan" как "192.168.1.1" (адрес "gateway.lan"), что делает невозможным использование Fail2Ban в поле "server.lan", чтобы препятствовать тысячам ежедневных попыток доступа.

Что я делаю неправильно? Я думаю, что включение маскировки для "внутренней" зоны концептуально неправильно, но я не мог найти другого способа заставить правило firewalld работать. У меня нет никаких сомнений в том, что я продолжаю маскироваться, но я хотел бы знать, как можно заставить Fail2Ban работать за шлюзом...

Какой-нибудь совет для любого другого способа сделать конфигурацию как эта работа, как я ожидаю?

1 ответ

Решение

Ах, мы сделали это! И это было относительно легко (ну, если вы знаете, как)...

Мы правильно предположили, что маскирование во "внутренней" зоне не должно быть включено глобально, а должно быть ограничено пакетами, исходящими из локальной сети, которые направляются к общедоступному IP.

Это подразумевает не беспорядочное включение его с помощью --add-masquerade для всей зоны, а использование маскарада ВНУТРИ конкретного правила с расширенным набором в следующей форме:

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 в адрес локальной сети блока 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 в направлении того же порта на "внутреннем";
  • позволяет машинам локальной сети безразлично использовать SSH в поле с его публичным или сетевым именем;
  • не маскирует адреса злонамеренных попыток SSH из Интернета в ящик, чтобы Fail2Ban мог выполнять свою работу.

Ура!

Другие вопросы по тегам