Почему Iptables не блокирует сеть спамеров?
В логах почтовика вижу попытки перебора паролей или шумовых коннектов с определенной сети
пример лога
Mar 11 17:18:13 mail postfix/submission/smtpd[3391]: connect from unknown[46.148.40.151] Mar 11 17:18:17 mail postfix/submission/smtpd[3391]: warning: unknown[46.148.40.151] SASL LOGIN authentication failed: UGFzc3dvcmQ6 Mar 11 17:18:17 mail postfix/submission/smtpd[3391]: lost connection after AUTH from unknown[46.148.40.151] Mar 11 17:18:17 mail postfix/submission/smtpd[3391]: disconnect from unknown[46.148.40.151] ehlo=1 auth=0/1 rset=1 commands=2/3 Mar 11 17:18:20 mail postfix/submission/smtpd[3964]: warning: hostname unused-space.coop.net does not resolve to address 206.168.32.3: Name or service not known Mar 11 17:18:20 mail postfix/submission/smtpd[3964]: connect from unknown[206.168.32.3] Mar 11 17:18:20 mail postfix/submission/smtpd[3964]: lost connection after STARTTLS from unknown[206.168.32.3] Mar 11 17:18:20 mail postfix/submission/smtpd[3964]: disconnect from unknown[206.168.32.3] ehlo=1 starttls=1 commands=2 |
Mar 11 17:18:13 mail postfix/submission/smtpd[3391]: connect from unknown[46.148.40.151] Mar 11 17:18:17 mail postfix/submission/smtpd[3391]: warning: unknown[46.148.40.151] SASL LOGIN authentication failed: UGFzc3dvcmQ6 Mar 11 17:18:17 mail postfix/submission/smtpd[3391]: lost connection after AUTH from unknown[46.148.40.151] Mar 11 17:18:17 mail postfix/submission/smtpd[3391]: disconnect from unknown[46.148.40.151] ehlo=1 auth=0/1 rset=1 commands=2/3 Mar 11 17:18:20 mail postfix/submission/smtpd[3964]: warning: hostname unused-space.coop.net does not resolve to address 206.168.32.3: Name or service not known Mar 11 17:18:20 mail postfix/submission/smtpd[3964]: connect from unknown[206.168.32.3] Mar 11 17:18:20 mail postfix/submission/smtpd[3964]: lost connection after STARTTLS from unknown[206.168.32.3] Mar 11 17:18:20 mail postfix/submission/smtpd[3964]: disconnect from unknown[206.168.32.3] ehlo=1 starttls=1 commands=2
Команда iptables -A INPUT -s 46.148.40.0/24 -j DROP
не дает эффекта - бот как ломился так и ломится
ОС Ubunta с почтовиком на борту
Дополнительно:
Возможно, разрешающее правило для почтовика стоит раньше в цепочке.
- Как удостовериться в этом?
ЗЫ не силен в этой теме, сорри - Михаил, sudo iptables -L INPUT
- Rsa97,
root@mail:~# sudo iptables -L INPUT Chain INPUT (policy DROP) target prot opt source destination ufw-before-logging-input all -- anywhere anywhere ufw-before-input all -- anywhere anywhere ufw-after-input all -- anywhere anywhere ufw-after-logging-input all -- anywhere anywhere ufw-reject-input all -- anywhere anywhere ufw-track-input all -- anywhere anywhere DROP all -- 46.148.40.0/24 anywhere
root@mail:~# sudo iptables -L INPUT Chain INPUT (policy DROP) target prot opt source destination ufw-before-logging-input all -- anywhere anywhere ufw-before-input all -- anywhere anywhere ufw-after-input all -- anywhere anywhere ufw-after-logging-input all -- anywhere anywhere ufw-reject-input all -- anywhere anywhere ufw-track-input all -- anywhere anywhere DROP all -- 46.148.40.0/24 anywhere
- Михаил, У вас UFW включен. Его правила работают первыми. Вместо iptables используйте команду ufw
sudo ufw insert 1 deny from 46.148.40.0/24 to any
И посмотрите результат
sudo ufw status numbered - Rsa97,
Похоже на конфликт, не дает вставить правилоroot@mail:~# sudo ufw insert 1 deny from 46.148.40.0/24 to any Пропуск вставки существующего правила root@mail:~# sudo ufw status numbered Состояние: активен В Действие Из - -------- -- [ 1] 22/tcp LIMIT IN Anywhere [ 2] 53 ALLOW IN Anywhere [ 3] 25/tcp ALLOW IN Anywhere [ 4] 465/tcp ALLOW IN Anywhere [ 5] 587/tcp ALLOW IN Anywhere [ 6] 993/tcp ALLOW IN Anywhere [ 7] 995/tcp ALLOW IN Anywhere [ 8] 4190/tcp ALLOW IN Anywhere [ 9] 80/tcp ALLOW IN Anywhere [10] 443 ALLOW IN Anywhere [11] Anywhere REJECT IN 46.148.40.0/24 [12] Anywhere REJECT IN 187.192.0.0/11 [13] 22/tcp (v6) LIMIT IN Anywhere (v6) [14] 53 (v6) ALLOW IN Anywhere (v6) [15] 25/tcp (v6) ALLOW IN Anywhere (v6) [16] 465/tcp (v6) ALLOW IN Anywhere (v6) [17] 587/tcp (v6) ALLOW IN Anywhere (v6) [18] 993/tcp (v6) ALLOW IN Anywhere (v6) [19] 995/tcp (v6) ALLOW IN Anywhere (v6) [20] 4190/tcp (v6) ALLOW IN Anywhere (v6) [21] 80/tcp (v6) ALLOW IN Anywhere (v6) [22] 443 (v6) ALLOW IN Anywhere (v6)
root@mail:~# sudo ufw insert 1 deny from 46.148.40.0/24 to any Пропуск вставки существующего правила root@mail:~# sudo ufw status numbered Состояние: активен В Действие Из - -------- -- [ 1] 22/tcp LIMIT IN Anywhere [ 2] 53 ALLOW IN Anywhere [ 3] 25/tcp ALLOW IN Anywhere [ 4] 465/tcp ALLOW IN Anywhere [ 5] 587/tcp ALLOW IN Anywhere [ 6] 993/tcp ALLOW IN Anywhere [ 7] 995/tcp ALLOW IN Anywhere [ 8] 4190/tcp ALLOW IN Anywhere [ 9] 80/tcp ALLOW IN Anywhere [10] 443 ALLOW IN Anywhere [11] Anywhere REJECT IN 46.148.40.0/24 [12] Anywhere REJECT IN 187.192.0.0/11 [13] 22/tcp (v6) LIMIT IN Anywhere (v6) [14] 53 (v6) ALLOW IN Anywhere (v6) [15] 25/tcp (v6) ALLOW IN Anywhere (v6) [16] 465/tcp (v6) ALLOW IN Anywhere (v6) [17] 587/tcp (v6) ALLOW IN Anywhere (v6) [18] 993/tcp (v6) ALLOW IN Anywhere (v6) [19] 995/tcp (v6) ALLOW IN Anywhere (v6) [20] 4190/tcp (v6) ALLOW IN Anywhere (v6) [21] 80/tcp (v6) ALLOW IN Anywhere (v6) [22] 443 (v6) ALLOW IN Anywhere (v6)
- Михаил, А, у вас уже есть это правило с номером 11.
sudo ufw delete 11 sudo ufw insert 1 deny from 46.148.40.0/24 to any sudo ufw status numbered
sudo ufw delete 11 sudo ufw insert 1 deny from 46.148.40.0/24 to any sudo ufw status numbered
- Rsa97, Да помогло! Бот отвалился :)
В дальнейшем при обнаружении других ботов работаем по этой же схеме? - Михаил, Смотря какой бот. В целом смотрите, что надо блокировать или разрешать и в какой последовательности.
- Rsa97, Понял, благодарю вас!
- Михаил, правильная команда пишется по другому: iptables -I INPUT -s 46.148.40.0/24 -j DROP
P.S. И не спрашивайте, в чём же разница...
Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.
Пока нет других ответов. Будьте первым, кто поможет автору.
Ответить на вопрос
Прежде всего, если вы уверены, что Iptables правильно настроен для блокировки сети спамеров, но при этом они все равно продолжают отправлять спам, есть несколько возможных причин, по которым это может происходить.
1. Неправильные правила iptables: Убедитесь, что правила iptables настроены правильно для блокировки сети спамеров. Проверьте, нет ли ошибок в вашем конфигурационном файле iptables. Убедитесь, что вы используете правильные IP-адреса и порты для блокировки.
iptables -A INPUT -s SPAMMER_IP -j DROP
2. Проблемы с обновлением правил: Убедитесь, что вы правильно применяете обновленные правила iptables. После внесения изменений в конфигурационный файл, убедитесь, что вы перезапустили службу iptables для применения новых правил.
service iptables restart
3. Сетевые настройки могут быть обходом: Спамеры могут использовать различные методы для обхода блокировки с помощью iptables, например, использование анонимизаторов или VPN. Для более надежной блокировки спамеров вы можете рассмотреть другие методы, такие как использование IDS/IPS систем или специализированных анти-спам фильтров.
4. Ресурсы сервера: Если ваш сервер не имеет достаточных ресурсов для обработки всех входящих соединений, спамеры могут обходить блокировку, отправляя большое количество запросов одновременно. Убедитесь, что ваш сервер имеет достаточные ресурсы для обработки всех входящих соединений и блокировки спамеров.
5. Постоянное обновление правил: Спамеры постоянно изменяют свои IP-адреса и методы атаки, поэтому важно регулярно обновлять правила iptables для блокировки новых угроз. Рассмотрите автоматизацию процесса обновления правил для более эффективной защиты от спамеров.
Проверьте вышеперечисленные причины и внесите необходимые изменения для улучшения работы iptables и более эффективной блокировки сети спамеров.