ufw запретить сетевое правило не работает

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

Я изменил порт прослушивания сервера dovecot, но он находит новый порт и продолжает попытки входа в систему.

Сеть, которую я хочу отфильтровать, - 185.211.245.128 - 185.211.245.255.

У меня есть постфикс и порты ssh открыты, но он ориентирован на голубятню.

Это правила, которые я установил в ufw

Anywhere                   DENY        185.211.245.128/25
Anywhere                   DENY        185.211.245.0/24
Anywhere                   DENY        185.211.245.170
996                        DENY        185.211.245.170
996/tcp                    ALLOW       Anywhere

Только последнее отрицание имело силу. Теперь у меня есть попытки подключения с другого адреса из этой сети.

Я добавил сетевые правила запрета с помощью следующей команды:

# ufw deny from 185.211.245.128/25

Почему ufw не принимает во внимание эти правила запрета?

Обновление 1 : я перезагрузился и получил час облегчения, но снова получаю попытки подключения. iptables выглядит правильно:

Chain ufw-user-input (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    3   180 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:xxx
   32  1672 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
   19  1092 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443
   22  1268 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:25
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:587
    7   424 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:465
    0     0 DROP       all  --  *      *       141.98.80.16         0.0.0.0/0           
    0     0 DROP       all  --  *      *       5.79.252.176         0.0.0.0/0           
    0     0 DROP       all  --  *      *       5.53.119.178         0.0.0.0/0           
    5   200 DROP       all  --  *      *       185.211.245.128/25   0.0.0.0/0           
    0     0 DROP       all  --  *      *       185.211.245.0/24     0.0.0.0/0           
    0     0 DROP       all  --  *      *       185.211.245.170      0.0.0.0/0           
    0     0 DROP       tcp  --  *      *       185.211.245.170      0.0.0.0/0            tcp dpt:996
    0     0 DROP       udp  --  *      *       185.211.245.170      0.0.0.0/0            udp dpt:996
    0     0 DROP       all  --  *      *       168.228.151.234      0.0.0.0/0           
    0     0 DROP       all  --  *      *       185.211.245.198      0.0.0.0/0           
   34  2160 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:996

По-видимому, 5 пакетов отклонены правилом deny 185.211.245.128/25. Но у меня сейчас снова соединения от 185.211.245.170.

Это то, что я вижу в auth.log. Перезагрузился до 12:00.

Feb 18 12:37:28 srv01 auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=xxx rhost=185.211.245.170
Feb 18 12:37:31 srv01 auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=xxx rhost=185.211.245.170
Feb 18 12:37:58 srv01 auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=xxx rhost=185.211.245.170
Feb 18 12:38:00 srv01 auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=xxx rhost=185.211.245.170
Feb 18 13:11:12 srv01 auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=xxx rhost=185.211.245.170
Feb 18 13:11:14 srv01 auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=xxx rhost=185.211.245.170
Feb 18 13:11:33 srv01 auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=xxx rhost=185.211.245.170
Feb 18 13:11:36 srv01 auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=xxx rhost=185.211.245.170

Похоже, что iptables не работает должным образом или его можно обойти.

Процесс dovecot прослушивает 0.0.0.0:996 и ::: 996.

Обновление 2 : еще более странно. Заглянув в журнал ufw.log, я вижу, что попытки подключения из моего дома к серверу через порт 996 были отклонены этой ночью. Но вчера вечером мне удалось получить доступ к моему серверу imap через тот же порт. Что-то действительно подозрительно.

Обновление 3 : у меня был запущен fail2ban. Поскольку я остановил fail2ban, что привело к удалению правил в iptables, больше не сообщается о неудачных попытках подключения в auth.log. Может быть, это fail2ban, который их сгенерировал, а я думал, что это dovecot. В iptables я вижу медленно увеличивающееся количество отбрасываемых пакетов для правила 185.211.245.128/25. Чего я и ожидал. Похоже, что fail2ban мешает iptables, или просто ведение журнала было неправильным. Но через 4 часа и сразу после публикации этого обновления я получил четыре новых попытки подключения.

Update4 : Я добился некоторого прогресса. Попытки входа в систему блокируются, когда правила отбрасывания помещаются перед всеми разрешающими правилами.Похоже, что злоумышленник извлекает выгоду из других разрешающих правил, чтобы обойти запрещающее правило. Как это возможно, пока неясно. Если эта интерпретация верна, ufw имеет дыру, которая является проблемой безопасности!

Правила запрета, очевидно, должны быть на первом месте. Я могу убедиться в этом сам, но наивное использование ufw может обнажить хост. Я бы посоветовал ufw всегда вставлять запрещающие правила перед любыми разрешающими правилами в качестве меры предосторожности.

0
задан 21 February 2019 в 10:12
3 ответа

Перезагрузить службу sudo ufw reload и sudo service iptables restart , не забудьте разрешить ssh, если вы находитесь на сервере.

1
ответ дан 4 December 2019 в 13:21

Во-первых, UFW очень прост, и я считаю его ужасным. Кажется, что это очень легко, но по какой-то причине люди, которые разрабатывают такие вещи, думают, что это легко означает запутать вас и затруднить изучение чего-либо, вместо того, чтобы просто делать то, что вы просите, даже если это иногда означает блокировку себя или блокирование неправильных сетей. Вам, вероятно, следует использовать что-нибудь получше, например shorewall.

И во-вторых, я предлагаю всякий раз, когда вы используете расплывчатый и ограниченный пользовательский интерфейс UFW, также проверяйте с помощью iptables -nvL , чтобы получить четкое и полное описание того, что текущая конфигурация iptables на самом деле есть. Увидев этот вывод, я уверен, что ваша проблема будет ясна (если не для вас, то для меня), но не уверен, сможете ли вы затем найти команду UFW для создания правильных настроек iptables (я никогда не устраняю неполадки UFW так далеко ... Я просто заменяю его на shorewall, если вообще возникнут проблемы).

1
ответ дан 4 December 2019 в 13:21

запустите sudo ufw enable или sudo ufw reload , если он уже включен после создания правил

0
ответ дан 12 April 2020 в 21:53

Теги

Похожие вопросы