У меня есть сервер LAMP Ubuntu 10.04. На нем много (>140) пользователей и много разных веб-сайтов PHP (кастомных, разных PHP-фреймворков, CMS и т. д.).
Проблема в том, что иногда сервер рассылает "спам". А локальный Exim для этого не используется. Я обнаружил странную активность, вроде следующей:
/usr/bin/lsof -ni | grep smtp |grep -v ^exim4
perl 15177 www-data 510u IPv4 1101127040 0t0 TCP server_ip:46401->65.55.37.72:smtp (SYN_SENT)
perl 15178 www-data 510u IPv4 1101127059 0t0 TCP server_ip:51002->98.136.217.202:smtp (SYN_SENT)
perl 15179 www-data 510u IPv4 1101126982 0t0 TCP server_ip:39232->74.125.205.26:smtp (SYN_SENT)
perl 15180 www-data 510u IPv4 1101126975 0t0 TCP server_ip:53339->65.55.37.72:smtp (SYN_SENT)
perl 15181 www-data 510u IPv4 1101127014 0t0 TCP server_ip:45429->65.55.37.72:smtp (SYN_SENT)
perl 15182 www-data 510u IPv4 1101126984 0t0 TCP server_ip:49985->74.125.205.26:smtp (SYN_SENT)
perl 15183 www-data 510u IPv4 1101126971 0t0 TCP server_ip:42199->65.55.37.72:smtp (SYN_SENT)
..........
...........
perl 15184 www-data 510u IPv4 1101126968 0t0 TCP server_ip:36641->74.125.205.26:smtp (SYN_SENT)
perl 15186 www-data 510u IPv4 1101126979 0t0 TCP server_ip:57690->98.138.112.32:smtp (SYN_SENT)
...........
И я не могу узнать, кто запускает эти процессы Perl или как они запускаются. Я пытался проанализировать эти процессы (например pid 15179): /proc/15179/cmdline - пусто
/proc/15179/status
Name: perl
State: S (sleeping)
Tgid: 15179
Pid: 15179
PPid: 15176
TracerPid: 0
Uid: 33 33 33 33
Gid: 33 33 33 33
FDSize: 1024
Groups: 33
VmPeak: 10400 kB
VmSize: 10372 kB
VmLck: 0 kB
VmHWM: 8140 kB
VmRSS: 8092 kB
VmData: 6980 kB
VmStk: 88 kB
VmExe: 1200 kB
VmLib: 1980 kB
VmPTE: 32 kB
Threads: 1
SigQ: 0/16382
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000080
SigCgt: 0000000180017427
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: ffffffffffffffff
Cpus_allowed: f
Cpus_allowed_list: 0-3
Mems_allowed: 1
Mems_allowed_list: 0
voluntary_ctxt_switches: 6431
nonvoluntary_ctxt_switches: 34
lsof -n -p 15179 - здесь введите описание ссылки здесь
Я попытался найти родительский процесс: родительский pid 15179 — 15176:
/proc/15176/cmdline - тоже пусто
и
/proc/15176/status
Name: perl
State: S (sleeping)
Tgid: 15176
Pid: 15176
PPid: 1
TracerPid: 0
Uid: 33 33 33 33
Gid: 33 33 33 33
FDSize: 1024
Groups: 33
VmPeak: 11116 kB
VmSize: 11116 kB
VmLck: 0 kB
VmHWM: 8712 kB
VmRSS: 8692 kB
VmData: 7772 kB
VmStk: 88 kB
VmExe: 1200 kB
VmLib: 1940 kB
VmPTE: 32 kB
Threads: 1
SigQ: 0/16382
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000010080
SigCgt: 0000000180007427
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: ffffffffffffffff
Cpus_allowed: f
Cpus_allowed_list: 0-3
Mems_allowed: 1
Mems_allowed_list: 0
voluntary_ctxt_switches: 14467
Это случается редко (раз в 2 дня) и длится несколько минут. Поэтому сложно получить больше информации. Вся эта информация регистрируется с помощью задания cron, которое отслеживает соединение smtp. Я понятия не имею, как определить, кто запускает эти процессы или как они запускаются. Есть ли какие-то тактики, чтобы их найти?
решение1
Данные, которые вы отобразили, уже содержат много информации: UID пользователя — 33, что в моей системе соответствуетwww-данные, и я думаю, что, скорее всего, то же самое относится и к вашей системе, поскольку отображаемые вами сокеты принадлежатwww-данные.
Кроме того, я сомневаюсь, что командная строка даст вам больше информации: PPID программы perl — 15176, но PPID 15176 — 1 (то есть,в этом). Здесь нет оболочки, нет сеанса между ними.
IP-адреса, с которыми удалось связаться, не вызывают особого беспокойства: они принадлежат Microsoft и Google, а эти ребята знают, как себя защитить.
Итак, где доказательства нечестной игры? Я согласен, что статус SYN_SENT для соединения действительно вызывает беспокойство, поскольку он означает, что ваше соединение не получило надлежащего SYN/ACK, и вы остались в подвешенном состоянии.
Итак, что вы можете сделать, чтобы выкопать больше информации? Вы не можете пытаться идентифицировать пользователя напрямую: ваш пост уже показывает, что пользовательwww-данные, и что процесс не подключен напрямую к терминалу или сеансу.
Но вы можете сначала выяснить, находится ли ваш IP-адрес в черном списке, напримерздесь: если это так, то это будет доказательством спама.
Во-вторых, вам следует проверить журнал вашей почтовой программы на предмет чего-либо необычного: сайты, отказывающие в подключении из-за того, что вы находитесь в черном списке, множественные подключения с одного и того же сайта, доказательства использования в качестве ретранслятора и т. д.
В-третьих, вы можете контролировать свои порты с помощью
ss -lntp
Это сообщает вам pid процессов, использующих порт (TCP) в любой момент времени, еще раз проверяя наличие нескольких соединений. Вы можете написать скрипт для команды выше, чтобы она повторялась каждую секунду, и сохранить ее вывод (возможно, вместе с выводомпользователи) и временную метку, чтобы узнать больше информации о том, что происходит во время подозрительных подключений. Это может быть перекрестно коррелированопосмертнос пользователями, вошедшими в систему, или пользователями, подключенными к вашему сайту.
Для получения дополнительной информации вы можете просто сбросить все пакеты на часто посещаемый сайт Microsoft, например
nohup tcpdump -n -i eth0 host 65.52.0.0/14 -w outfile &
Диапазон IP-адресов — это весь блок, принадлежащий Microsoft, согласно выводукто 65.55.37.72; приведенная выше команда, скорее всего, сгенерирует довольно много выходных данных, поэтому будьте готовы отточить свои навыки фильтрации выражений с помощьюпроводная акула.
Если все это не сработает, будьте готовы заставить пользователей сменить пароли.
решение2
Просто идея. Пройдитесь по журналам Apache с помощью Grep. Если у вас есть время, то когда отправлялись письма, их можно легко найти. Особенно ищите скрипты Perl.
решение3
Получить пользователя
Обычноuidполе показываетuidпользователя, запустившего процесс.
В вашем случае это будет iser сuid 33.
Используйте getent passwd 33, чтобы увидеть имя пользователя.
Отслеживать пользователя
Вы можете легко наблюдать и регистрировать активность пользователя с помощью небольшого демона на языке C,
с использованиемэтотнебольшая библиотека для чтения /proc/pid/statusфайла и поиска пользователя.
Это может помочь вам избежать проблем с работой сервера.
(Вы также можете разрешить демону killвыполнять эти процессы)