Журналы доступа для чтения электронной почты, отправленной с хоста

Это записи журнала из файла журнала доступа http-серверов, они описывают http-запросы, а не события электронной почты. Запросы поступают с разных адресов, что типично сегодня: такие зомби-сайты используются распределенными бот-сетями для своих целей. Это значительно затрудняет идентификацию людей, стоящих за этим. Путь, который вы видите в запросах, является конечной точкой API, используемого для доступа к серверу, это похоже на SOAP API, предлагаемый вашим сайтом.

Вопрос для журнала SMTP не так тривиален для ответа. Это на самом деле зависит от как ваши php-скрипты отправляют сообщение. 4 основных варианта должны быть рассмотрены:

1. в этой системе вы используете локальный SMTP-сервер, который действительно может предоставить вам файлы журналов для сообщений. В этом случае расположение файлов журнала зависит от того, какое серверное программное обеспечение вы используете, например exim или же postfix, Вам придется проверить файлы конфигурации серверов или просто немного покопаться в папке, где хранятся файлы журналов, обычно что-то вроде /var/log/..., Однако этот вариант маловероятен, так как вы написали, что используете какую-то хостинговую компанию. Использование локального SMTP-сервера требует полного контроля над системой, поэтому root доступ. Если бы у вас было это, вы бы знали 🙂

2. сообщения отправляются по стандартному маршруту, настроенному в php с помощью phps mail() функция. В этом случае это, очевидно, зависит от той конфигурации, на которую на самом деле указывает SMTP-сервер ретрансляции, но это, скорее всего, будет не быть сервером, работающим в вашей локальной системе. Это будет означать, что вам придется получить файлы журналов той удаленной системы, на которой работает SMTP-сервер. это может быть быть системой, которую предоставляет ваша хостинговая компания, но это маловероятно, поскольку они рискуют, что их системы будут снова и снова попадать в черные списки. В любом случае, вы должны проверить это с вашей хостинговой компанией.

3. наиболее вероятный сценарий — отправка сообщений с использованием некоторых клиентских классов SMTP, доступных для php. Они предлагают гораздо более гибкую обработку сообщений, поэтому их обычно предпочитают встроенным функциям. В этом случае конфигурация / инициализация класса определяет, какой SMTP-сервер используется в качестве ретранслятора, поэтому вам придется взглянуть на ваши php-скрипты для получения этой информации. Как и в варианте 2, это почти наверняка не быть локально управляемым сервером, но некоторым типичным ретранслятором, таким как GMail или Mandrill. Тогда вы не сможете получить доступ к файлам журналов, если у вас нет конкретного контракта с этими компаниями, о чем, опять же, вы бы знали 🙂

4. в качестве варианта варианта 3 злоумышленник может перезаписать или заменить данную конфигурацию и предоставить собственные данные о подключении. Скорее всего, это возможно, поскольку, по-видимому, злоумышленнику удалось выполнить внедренный код в вашей системе. Чтобы он мог делать более или менее то, что он хочет. В этом случае вы можете или не сможете найти следы этих деталей …

Однако, честно говоря, я не понимаю, почему вы интересуетесь этими записями в журнале или, точнее, информацией, по которой эти сообщения были отправлены.

Имейте в виду, что типичный злоумышленник в таком случае не использует адреса, связанные с атакованным сайтом. Вместо этого обычно используется каталог адресов, которые были собраны либо путем очистки общедоступных веб-сайтов, таких как форумы (произвольные, украденные адреса), либо путем «угадывания» адресов, что позволяет объединять типичные имена учетных записей с известными доменными именами, свободно доступными в Интернете. Вас это не интересует, так как оно полностью отсутствует, если у вас контроль и вообще не связано с вами или вашим бизнесом.