Ich habe einen LAMP Ubuntu 10.04-Server. Es gibt viele (>140) Benutzer und viele verschiedene PHP-Websites (benutzerdefiniert, verschiedene PHP-Frameworks, CMS usw.).
Das Problem ist: Manchmal sendet der Server „Spam“. Und dafür wird das lokale Exim nicht verwendet. Ich habe seltsame Aktivitäten wie die folgende entdeckt:
/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)
...........
Und ich kann nicht herausfinden, wer diese Perl-Prozesse ausführt oder wie sie ausgeführt werden. Ich habe versucht, diese Prozesse zu analysieren (zum Beispiel pid 15179): /proc/15179/cmdline - ist leer
/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 - hier Linkbeschreibung hier eingeben
Ich habe versucht, den übergeordneten Prozess zu finden: Die übergeordnete PID von 15179 ist 15176:
/proc/15176/cmdline – ebenfalls leer
Und
/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
Es passiert selten (einmal alle 2 Tage) und dauert ein paar Minuten. Daher ist es schwierig, weitere Informationen zu erhalten. Alle diese Informationen werden mithilfe eines Cron-Jobs protokolliert, der die SMTP-Verbindung überwacht. Ich habe keine Ahnung, wie ich herausfinden kann, wer diese Prozesse ausführt oder wie sie ausgeführt werden. Gibt es irgendwelche Taktiken, um sie herauszufinden?
Antwort1
Die von Ihnen angezeigten Daten enthalten bereits viele Informationen: Die UID des Benutzers ist 33, was auf meinem System entsprichtwww-Daten, und ich denke, das Gleiche gilt höchstwahrscheinlich für Ihr System, da die von Ihnen angezeigten Sockel zuwww-Daten.
Außerdem bezweifle ich, dass die Befehlszeile Ihnen mehr Informationen liefern wird: Die PPID des Perl-Programms ist 15176, aber die PPID von 15176 ist 1 (dh,drin). Es gibt keine Shell, keine Sitzung dazwischen.
Die kontaktierten IP-Adressen sind nicht besonders besorgniserregend: Sie gehören Microsoft und Google, und diese Leute wissen, wie sie sich verteidigen können.
Wo sind also die Beweise für ein Foul? Ich stimme zu, dass der Status SYN_SENT für die Verbindung tatsächlich Anlass zur Sorge gibt, denn er bedeutet, dass Ihre Verbindung kein ordnungsgemäßes SYN/ACK erhalten hat und Sie hängen gelassen wurden.
Was können Sie also tun, um weitere Informationen zu erhalten? Sie können nicht versuchen, den Benutzer direkt zu identifizieren: Ihr Beitrag zeigt bereits, dass der Benutzerwww-Datenund dass der Prozess nicht direkt mit einem Terminal oder einer Sitzung verbunden ist.
Aber Sie können zunächst einmal feststellen, ob Ihre IP auf einer schwarzen Liste steht, zum BeispielHier: Wenn das der Fall ist, wäre das ein Beweis für Spamming.
Zweitens sollten Sie das Protokoll Ihres Mailers auf Ungewöhnliches überprüfen: Sites, die die Verbindung verweigern, weil Sie auf einer schwarzen Liste stehen, mehrere Verbindungen von der gleichen Site, Hinweise auf die Verwendung als Relay, …
Drittens können Sie Ihre Ports überwachen mit
ss -lntp
Dies zeigt Ihnen die PIDs der Prozesse an, die zu einem bestimmten Zeitpunkt einen (TCP-)Port verwenden, und prüft erneut, ob mehrere Verbindungen bestehen. Sie können den obigen Befehl so skripten, dass er sich jede Sekunde wiederholt, und seine Ausgabe speichern (möglicherweise in Verbindung mit der Ausgabe vonBenutzer) und einen Zeitstempel, um mehr Informationen darüber zu erhalten, was zum Zeitpunkt der verdächtigen Verbindungen vor sich geht. Das kann kreuzkorreliert werdenObduktionmit angemeldeten Benutzern oder Benutzern, die mit Ihrer Site verbunden sind.
Für weitere Informationen können Sie einfach alle Pakete auf die oft wiederkehrende Microsoft-Site übertragen, etwa so:
nohup tcpdump -n -i eth0 host 65.52.0.0/14 -w outfile &
Der IP-Adressbereich ist der gesamte Block, der zu Microsoft gehört, gemäß der Ausgabe vonwhois 65.55.37.72; der obige Befehl wird wahrscheinlich eine ganze Menge an Ausgabe erzeugen, also seien Sie darauf vorbereitet, Ihre Fähigkeiten im Filtern von Ausdrücken zu verfeinern mitWireshark.
Wenn das alles fehlschlägt, müssen Sie damit rechnen, dass Ihre Benutzer zur Änderung ihrer Passwörter gezwungen werden.
Antwort2
Nur eine Idee. Durchsuchen Sie Ihre Apache-Protokolle. Wenn Sie Zeit haben, können Sie die E-Mails, wann sie gesendet wurden, leicht finden. Suchen Sie insbesondere nach Perl-Skripten.
Antwort3
Abrufen des Benutzers
NormalerweiseBenutzerkennungFeld zeigt dieBenutzerkennungdes Benutzers, der den Prozess gestartet hat.
In Ihrem Fall ist dies der Iser mit demBenutzerkennung 33.
Wird verwendet getent passwd 33, um den Namen des Benutzers anzuzeigen.
Verfolgen Sie den Benutzer
Sie können die Aktivitäten des Benutzers ganz einfach mit einem kleinen C-Daemon beobachten und protokollieren.
mitDaskleine Bibliothek zum Lesen der /proc/pid/statusDatei und Suchen nach dem Benutzer.
Dadurch können Sie ggf. Probleme mit der Serverlaufzeit vermeiden.
(Sie können killdiese Prozesse auch dem Daemon überlassen)