Накратко: Когато сървърът изпраща спам, обикновено има една от три причини: вмъкнат или злоупотребен PHP скрипт, пощенска кутия с открадната парола или неправилно конфигуриран пощенски сървър. Запазете няколко от чакащите писма, прочетете заглавните им редове и пощенския лог и в повечето случаи ще намерите източника. След това спрете изпращането, затворете причината и едва тогава поискайте премахване от черните списъци.
Когато клиентите намират Вашите фактури в папката за спам
Рядко започва със съобщение за сигурност. Най-често се обаждат клиенти, които вече не получават Вашите оферти, или пощенската кутия се пълни с известия за връщане на писма, които никой никога не е писал. Понякога хостерът блокира изпращането и посочва като причина необичаен пощенски трафик.
За фирмата това бързо има осезаеми последици. Ако адресът на сървъра стои в черен списък, други пощенски сървъри отхвърлят и Вашите истински писма: фактури, потвърждения на поръчки, връзки за парола от магазина. Репутацията на домейна страда, а щетата расте с всеки час, в който изпращането продължава.
Изпращането на спам спада към познатите последици от компрометиране. След PHP2Shell, уязвимостите CVE-2026-109618 и CVE-2026-109619 с изпълнение на код без влизане, това е още една причина да погледнете по-внимателно. Специфично указание за PHP2Shell обаче спамът не е; потвърдени Indicators of Compromise няма. Други общи признаци описва Компрометиран ли съм вече?.
Три типични причини, когато сървърът изпраща спам
| Причина | Типична картина | Къде да погледнете |
|---|---|---|
| Вмъкнат PHP скрипт | Писма без влизане, доставени локално през sendmail |
Заглавни редове, PHP пощенски лог, нови PHP файлове |
| Злоупотребен формуляр | Писма през формуляр за контакт или препоръка към чужди получатели | Лог за достъп на формуляра, заглавни редове |
| Превзета пощенска кутия | Изпращане с валидно влизане в пощенския сървър | Пощенски лог с име за влизане, места на влизане |
| Отворен пощенски сървър | Чужди податели ползват Вашия сървър като препращане | Конфигурация на пощенския сървър, външна проверка |
Първите две причини засягат уебсайта, третата - пощенските акаунти, четвъртата - конфигурацията на сървъра. Разграничението е важно, защото противомерките са напълно различни.
Четене на пощенската опашка
На сървъри с Postfix опашката показва какво предстои да бъде изпратено. Следните команди само четат:
# Показване на съдържанието на опашката (съответства на mailq)
postqueue -p | tail -30
# Показване на заглавните редове на отделно писмо (поставете ID на опашката от списъка)
sudo postcat -q -h QUEUE-ID
# Успешни влизания в пощенския сървър с потребителско име
sudo grep 'sasl_username=' /var/log/mail.log | awk -F'sasl_username=' '{print $2}' | sort | uniq -c | sort -rn | head
Заглавните редове често издават източника още сега. Ако писмото идва от пощенска кутия с влизане, името за влизане се появява в пощенския лог. Ако там се трупа отделен акаунт с влизания от чужди страни, паролата на тази пощенска кутия е много вероятно станала известна. Ако писмото, напротив, е доставено локално, то обикновено идва от скрипт на сървъра.
Ако на Вашия сървър работи друг пощенски сървър, например Exim, командите се наричат различно, принципът остава същият: прегледайте опашката, прочетете заглавните редове, пребройте влизанията в лога. При споделен хостинг без shell достъп помолете хостера писмено за извадка от пощенския лог и за няколко примерни писма с пълни заглавни редове. Много хостери предоставят тези данни при запитване, защото и те имат интерес да се прекрати изпращането.
Запазете няколко пълни писма, преди да спрете или изпразните опашката. Те са доказателства за по-късния анализ и за разговори с хостера или операторите на черните списъци.
Намиране на отговорния PHP скрипт
Ако изпращането минава през PHP, помага пощенската конфигурация на PHP. Според PHP наръчника mail.log протоколира всяко извикване на функцията mail() с пълен път на скрипта, номер на ред, получател и заглавни редове. mail.add_x_header записва допълнително заглавен ред X-PHP-Originating-Script с идентификатора на потребителя и името на файла във всяко писмо.
; В php.ini или в FPM пула, след това рестартирайте всички worker-и
mail.add_x_header = On
mail.log = /var/log/php/mail.log
Файлът на лога трябва да е достъпен за запис от PHP процеса. Заглавният ред издава на получателите име на файл; изключете го след анализа, ако не го искате трайно.
Ако като подател се окаже непознат файл, например в директорията за качване или кеша, това е указание за уеб шел. Как да класифицирате такива файлове, описва Разпознаване и премахване на уеб шелове. Ако пък е познат формуляр за контакт, вероятно е бил злоупотребен, например защото получателят или заглавните редове се вземат от въведеното във формуляра. Това е грешка в кода, не проникване, но трябва да се отстрани също толкова бързо.
Не всеки спам ползва функцията mail(). Злонамереният код може и директно да изгради връзка към чужди пощенски сървъри. Тогава изпращането не се появява нито в опашката, нито в PHP пощенския лог, но се вижда като изходящи връзки на порт 25. Как да ги проверите, стои в Проверка на изходящите връзки на един сървър.
Спиране на изпращането и чисто пускане наново
Щом източникът е намерен, почистването следва в този ред:
- Спрете изпращането: Блокирайте засегнатия път, тоест деактивирайте скрипта, блокирайте пощенската кутия или спрете опашката. Запазете чакащите писма като доказателство.
- Затворете причината: При уеб шел приведете PHP в отстранено състояние (8.5.12, 8.4.27, 8.3.36, 8.2.35 или потвърден backport), рестартирайте всички worker-и и почистете уебсайта. При формуляр коригирайте кода. При пощенска кутия сменете паролата и проверете устройството на потребителя.
- Потърсете други следи: Който изпраща спам през уеб шел, често е оставил и други задни вратички.
- Ограничете изхода: Позволете изходящи връзки на порт 25 само за пощенския сървър, не за потребителя на уеб сървъра.
- Почистете черните списъци: Едва сега поискайте премахване от операторите на черните списъци и опишете накратко какво е отстранено.
Проверете при тази възможност SPF, DKIM и DMARC на Вашия домейн. Тези DNS записи определят кои сървъри могат да изпращат от името на Вашия домейн и затрудняват чужди лица да злоупотребяват с Вашия адрес на подател.
Как помага PHP SOS конкретно?
- Анализираме опашката, заглавните редове и пощенските логове и установяваме дали причината е скрипт, формуляр, пощенска кутия или конфигурация.
- Спираме изпращането контролирано и запазваме доказателства за хостера и черните списъци.
- Почистваме уебсайта в рамките на премахването на зловреден софтуер и затваряме входната врата.
- Ограничаваме изходящия пощенски трафик на ниво сървър и съпровождаме премахването от черните списъци.
Често задавани въпроси
По какво забелязвам, че сървърът ми изпраща спам?
Типични са известия за връщане на писма, които никой не е писал, указания от хостера, препълнена пощенска опашка и клиенти, които изведнъж намират Вашите писма в папката за спам. Записът на адреса на Вашия сървър в публични черни списъци също е ясен знак.
Как да намеря PHP скрипта, който изпраща спам?
PHP може да протоколира всяко извикване на функцията mail() с пътя на скрипта, ако е зададен mail.log. С mail.add_x_header PHP записва допълнително името на скрипта в заглавието на всяко писмо. В вече изпратени или чакащи писма помага поглед в заглавните редове.
Трябва ли веднага да изпразня пощенската опашка?
Не преди да сте запазили няколко писма като доказателство. Заглавните редове често показват кой скрипт или коя пощенска кутия е задействала изпращането. Спирането е обикновено по-добро от изтриването, докато източникът не е известен.
Как да изляза отново от черните списъци?
Първо отстранете причината, после поискайте премахване от съответните оператори на черните списъци. Повечето изискват обяснение какво е отстранено. Който поиска твърде рано и продължи да праща спам, се вписва отново.