Мой вопрос касается предотвращения отправки почты скриптами php. Он был отмечен как дубликат другого более общего вопроса о безопасности сервера, но этот вопрос не об этом.
После долгой и ожесточенной борьбы с хакерами-спамерами, которые каким-то образом внедряют вредоносные php-файлы в кодировке base64 в различные веб-каталоги на моем сервере Debian / Apache / PHP (ожесточенная борьба, включавшая сначала исправление существующих скриптов и смену паролей ftp, паролей веб-сервисов и паролей mysql, затем перестройку сайтов с нуля, установку maldet, что обуздало проблему, но не устранило ее полностью, а затем, наконец, полное отключение postfix путем остановки службы (но не удаления) и блокирования трафика порта 25 с сервера на брандмауэре) у меня все еще возникают проблемы.
Мои проблемы исчезли на много месяцев, и сервер был автоматически удален из черных списков по данным mxtoolbox. Но сегодня я получил письмо от mxtoolbox, в котором говорилось, что мой сервер снова занесен в черный список многими службами. Я не совсем понимаю, как это возможно, учитывая, что я отключил исходящий трафик порта 25.
Когда возникает проблема, мой почтовый ящик Postfix переполняется сотнями тысяч писем от определенного веб-пользователя на моем сервере.
У меня такие вопросы:
Учитывая, что я отключил трафик порта 25 с помощью
iptables -A OUTPUT -p tcp --dport 25 -j REJECT
,как это возможно, что mxtoolbox сообщает, что мой сервер все еще рассылает спам? Когда я проверяю mailq, письма резервируются. Когда я запускаю postfix, элементы в mailq не отправляются так, как я ожидал, и я вижу(delivery temporarily suspended: connect to 127.0.0.1[127.0.0.1]:10024: Connection refused)
рядом с каждой записью.Определив местоположение RAT, просмотрев
X-PHP-Originating-Script
строку в спам-письме в mailq, я могу найти и уничтожить нужный файл, что решает проблему на срок от 5 дней до нескольких месяцев.Как полностью запретить любому PHP-скрипту отправлять почту?Если я войдуdisable_functions = mail
в свой файл php.ini, я понимаю, что это предотвратит использование внутренних функций, но не пользовательских функций, которыми может воспользоваться спамер.Что еще я делаю не так?
Предостережение: я знаю, что пункт 2 не решит мою проблему в корне, но, воспользовавшись советом и укрепив безопасность моего сервера всеми доступными мне способами за последние пару лет, я работаю над «решением проблемы с репутацией почты», а не над «решением всех проблем безопасности и точка».
Это продолжение моегопоследний связанный вопросздесь, на ServerFault.
решение1
У вас есть выбор
- Удалить постфикс
- Удалить php-mail (имя пакета Ubuntu/Debian)
Однако спамеры все равно могут написать свой собственный SMTP-код.
Проверьте, действительно ли заблокирован SMTP, вот так
telnet alt4.gmail-smtp-in.l.google.com 25
решение2
Управление брандмауэром для порта 25 по-прежнему остается наилучшим вариантом, затем вы можете указать всем допустимым пользователям отправлять электронную почту через аутентифицированные серверы, такие как mandrill или другие, по протоколу smtps (tcp/587) или использовать API электронной почты сторонних ESP.
Вы по-прежнему можете написать PHP-код, который будет подключаться напрямую к MX-серверам через сокеты, если только вы не используете подход с использованием брандмауэра.
Вы также можете перенаправить TCP/25 в систему всеобъемлющего сбора данных, чтобы иметь возможность отслеживать, кто подвергается взлому или злоупотреблению.