Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Prozess mit komplettem Aufruf anzeigen?
15 views
Skip to first unread message
Paul Lenz
Jan 26, 2012, 4:04:32 PM1/26/12
to
Auf meinem Server liegt allerhand selbstgebasteltes Zeug, und irgend
eins von diesen Perl-Skripts erzeugt manchmal (wenige Male pro Monat)
eine extrem hohe CPU-Auslastung.
Das Ärgerliche dabei ist, dass ich völlig im Dunkeln tappe, welches
Skript das sein könnte, geschweige denn, mit welchen Parametern aus
welchem Web-Formular es aufgerufen wurde.
"top" zeigt nur, dass es sich um ein Perl-Skript handelt:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27225 www-data 20 0 4812 2660 1228 R 98.7 1.1 37:31.82 perl
"ps -Af" zeigt noch weniger:
UID PID PPID C STIME TTY TIME CMD
www-data 27220 27094 0 10:46 ? 00:00:00 [sh] <defunct>
www-data 27225 1 99 10:46 ? 00:34:59 -
Gibt es andere Möglichkeiten, mehr über diesen Prozess herauszufinden?
Zum Beispiel die genaue Uhrzeit, sodass ich im access.log nachschauen kann?
Paul Lenz
eins von diesen Perl-Skripts erzeugt manchmal (wenige Male pro Monat)
eine extrem hohe CPU-Auslastung.
Das Ärgerliche dabei ist, dass ich völlig im Dunkeln tappe, welches
Skript das sein könnte, geschweige denn, mit welchen Parametern aus
welchem Web-Formular es aufgerufen wurde.
"top" zeigt nur, dass es sich um ein Perl-Skript handelt:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27225 www-data 20 0 4812 2660 1228 R 98.7 1.1 37:31.82 perl
"ps -Af" zeigt noch weniger:
UID PID PPID C STIME TTY TIME CMD
www-data 27220 27094 0 10:46 ? 00:00:00 [sh] <defunct>
www-data 27225 1 99 10:46 ? 00:34:59 -
Gibt es andere Möglichkeiten, mehr über diesen Prozess herauszufinden?
Zum Beispiel die genaue Uhrzeit, sodass ich im access.log nachschauen kann?
Paul Lenz
Bjoern Bosselmann
Jan 26, 2012, 5:10:05 PM1/26/12
to
Hallo Paul,
Paul Lenz wrote:
> Gibt es andere Möglichkeiten, mehr über diesen Prozess herauszufinden?
> Zum Beispiel die genaue Uhrzeit, sodass ich im access.log nachschauen
> kann?
Versuche mal "ps -ww -f -p 27225".
"-ww" sorgt dafür, dass die Ausgabe nicht abgeschnitten wird. So sollte sich
die komplette Kommandozeile ausgeben lassen.
Falls dir die Zeitangabe unter "STIME" nicht ausreicht, solltest du
"ps -o lstart -p 27225" versuchen. Das sollte dir eine sekundengenaue Angabe
liefern.
Viele Grüße,
Björn
Paul Lenz wrote:
> Gibt es andere Möglichkeiten, mehr über diesen Prozess herauszufinden?
> Zum Beispiel die genaue Uhrzeit, sodass ich im access.log nachschauen
> kann?
"-ww" sorgt dafür, dass die Ausgabe nicht abgeschnitten wird. So sollte sich
die komplette Kommandozeile ausgeben lassen.
Falls dir die Zeitangabe unter "STIME" nicht ausreicht, solltest du
"ps -o lstart -p 27225" versuchen. Das sollte dir eine sekundengenaue Angabe
liefern.
Viele Grüße,
Björn
Sven Mascheck
Jan 26, 2012, 5:58:37 PM1/26/12
to
Paul Lenz wrote:
> Das Ärgerliche dabei ist, dass ich völlig im Dunkeln tappe, welches
> Skript das sein könnte, geschweige denn, mit welchen Parametern aus
> welchem Web-Formular es aufgerufen wurde.
>
> "top" zeigt nur, dass es sich um ein Perl-Skript handelt:
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 27225 www-data 20 0 4812 2660 1228 R 98.7 1.1 37:31.82 perl
>
> "ps -Af" zeigt noch weniger:
> UID PID PPID C STIME TTY TIME CMD
> www-data 27220 27094 0 10:46 ? 00:00:00 [sh] <defunct>
> www-data 27225 1 99 10:46 ? 00:34:59 -
Falls das Skript nicht explizit als Argument, sondern auf STDIN
> Das Ärgerliche dabei ist, dass ich völlig im Dunkeln tappe, welches
> Skript das sein könnte, geschweige denn, mit welchen Parametern aus
> welchem Web-Formular es aufgerufen wurde.
>
> "top" zeigt nur, dass es sich um ein Perl-Skript handelt:
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 27225 www-data 20 0 4812 2660 1228 R 98.7 1.1 37:31.82 perl
>
> "ps -Af" zeigt noch weniger:
> UID PID PPID C STIME TTY TIME CMD
> www-data 27220 27094 0 10:46 ? 00:00:00 [sh] <defunct>
> www-data 27225 1 99 10:46 ? 00:34:59 -
übergeben wurde, hilft Dir vielleicht ls -l /proc/27225/fd/0 weiter.
Dort gibt's auch noch anderen hilfreiche Einträge, wie cmdline.
Message has been deleted
Burkhard Müller
Jan 26, 2012, 8:51:59 PM1/26/12
to
*Paul Lenz* wrote:
[..snip..]
detaillierteren Output. Einen Versuch ist's wert.
HTH, BM
[..snip..]
> Das Ärgerliche dabei ist, dass ich völlig im Dunkeln tappe, welches
> Skript das sein könnte, geschweige denn, mit welchen Parametern aus
> welchem Web-Formular es aufgerufen wurde.
>
> "top" zeigt nur, dass es sich um ein Perl-Skript handelt:
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 27225 www-data 20 0 4812 2660 1228 R 98.7 1.1 37:31.82 perl
Kennst du htop? Das ist ähnlich wie top aber erzeugt wesentlich
> Skript das sein könnte, geschweige denn, mit welchen Parametern aus
> welchem Web-Formular es aufgerufen wurde.
>
> "top" zeigt nur, dass es sich um ein Perl-Skript handelt:
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 27225 www-data 20 0 4812 2660 1228 R 98.7 1.1 37:31.82 perl
detaillierteren Output. Einen Versuch ist's wert.
HTH, BM
Claudius Hubig
Jan 27, 2012, 2:15:09 AM1/27/12
to
es sich vielleicht an, dieses direkt nach Entdecken mit kill -SIGSTOP
anzuhalten, um in Ruhe analysieren zu können.
Beste Grüße,
Claudius
--
we:
The single most important word in the world.
Please use GPG: ECB0C2C7 4A4C4046 446ADF86 C08112E5 D72CDBA4
http://chubig.net/ http://nightfall.org
Helmut Hullen
Jan 27, 2012, 2:06:00 AM1/27/12
to
Hallo, Andreas,
Du meintest am 26.01.12:
>> Versuche mal "ps -ww -f -p 27225".
>> "-ww" sorgt dafür, dass die Ausgabe nicht abgeschnitten wird. So
>> sollte sich die komplette Kommandozeile ausgeben lassen.
> Wow, den "-ww" kannte ich gar nicht. Danke.
Ich bevorzuge "-www", zeigt noch ein wenig mehr. Wo die (sinnvolle)
Obergrenze liegt, habe ich noch nicht getestet.
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Du meintest am 26.01.12:
>> Versuche mal "ps -ww -f -p 27225".
>> "-ww" sorgt dafür, dass die Ausgabe nicht abgeschnitten wird. So
>> sollte sich die komplette Kommandozeile ausgeben lassen.
Ich bevorzuge "-www", zeigt noch ein wenig mehr. Wo die (sinnvolle)
Obergrenze liegt, habe ich noch nicht getestet.
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Paul Lenz
Jan 27, 2012, 3:05:03 AM1/27/12
to
Am 27.01.2012 02:51, schrieb Burkhard Müller:
> *Paul Lenz* wrote:
> [..snip..]
>> Das Ärgerliche dabei ist, dass ich völlig im Dunkeln tappe, welches
>> Skript das sein könnte, geschweige denn, mit welchen Parametern aus
>> welchem Web-Formular es aufgerufen wurde.
> *Paul Lenz* wrote:
> [..snip..]
>> Das Ärgerliche dabei ist, dass ich völlig im Dunkeln tappe, welches
>> Skript das sein könnte, geschweige denn, mit welchen Parametern aus
>> welchem Web-Formular es aufgerufen wurde.
> Kennst du htop? Das ist ähnlich wie top aber erzeugt wesentlich
> detaillierteren Output. Einen Versuch ist's wert.
An dieser Stelle erst mal herzlichen Dank für all die Tipps, mit denen
> detaillierteren Output. Einen Versuch ist's wert.
ich förmlich überschüttet wurde.
Leider kamen sie zu spät, gestern kurz vor Mitternacht passierte es
wieder (ich lasse gegenwärtig die CPU-Auslastung per Cronjob alle 5
Minuten überwachen und bei Bedarf eine E-Mail an mich schicken), aber da
hatte ich erst den Tipp von Björn, der leider nichts neues gebracht hat.
Jedenfalls denke ich, dass ich für den nächsten Vorfall gut gerüstet
bin, dann melde ich mich wieder. Habe mir gerade auch htop installiert,
das sieht wirklich super aus.
Paul Lenz
Paul Lenz
Jan 31, 2012, 2:11:24 PM1/31/12
to
Am 27.01.2012 02:51, schrieb Burkhard Müller:
>> "top" zeigt nur, dass es sich um ein Perl-Skript handelt:
>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>> 27225 www-data 20 0 4812 2660 1228 R 98.7 1.1 37:31.82 perl
>
> Kennst du htop? Das ist ähnlich wie top aber erzeugt wesentlich
> detaillierteren Output. Einen Versuch ist's wert.
Heute war es wieder so weit: PID 25263. htop brachte nichts neues.
>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>> 27225 www-data 20 0 4812 2660 1228 R 98.7 1.1 37:31.82 perl
>
> Kennst du htop? Das ist ähnlich wie top aber erzeugt wesentlich
> detaillierteren Output. Einen Versuch ist's wert.
Der Tipp von Sven brachte:
ls -l /proc/25263/fd/0
lr-x------ 1 www-data www-data 64 31. Jan 19:43 /proc/25263/fd/0 ->
/dev/null
Ich habe dann kill -SIGSTOP ausgeführt und mal ein bisschen in
/proc/25263 herumgeschaut, ohne aber etwas zu finden. Auch in der Datei
"cmdline" war nichts zu sehen.
Analog zum obigen Tipp habe ich hier am alle Einträge in /fd:
0 -> /dev/null
1 -> pipe:[253028115]
2 -> /var/log/apache2/error.log
3 -> socket:[253028128]
35 -> /tmp/.xcache.0.0.1955829363.lock (deleted)
40 -> socket:[252980002]
Kommt man mit der Nummer hinter "pipe" irgendwie weiter?
Oder bei anderen Einträgen in /proc/25263/ ?
Paul Lenz
Claudius Hubig
Jan 31, 2012, 3:05:25 PM1/31/12
to
Paul Lenz <pa...@lenz-online.de> wrote:
>Am 27.01.2012 02:51, schrieb Burkhard Müller:
>
>>> "top" zeigt nur, dass es sich um ein Perl-Skript handelt:
>>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>>> 27225 www-data 20 0 4812 2660 1228 R 98.7 1.1 37:31.82 perl
>>
>> Kennst du htop? Das ist ähnlich wie top aber erzeugt wesentlich
>> detaillierteren Output. Einen Versuch ist's wert.
>
>Heute war es wieder so weit: PID 25263. htop brachte nichts neues.
>
>Der Tipp von Sven brachte:
>ls -l /proc/25263/fd/0
>lr-x------ 1 www-data www-data 64 31. Jan 19:43 /proc/25263/fd/0 ->
>/dev/null
>
>Ich habe dann kill -SIGSTOP ausgeführt und mal ein bisschen in
>/proc/25263 herumgeschaut, ohne aber etwas zu finden. Auch in der Datei
>"cmdline" war nichts zu sehen.
Eigentlich sollte "cmdline" den kompletten Aufruf angeben (ohne
>Am 27.01.2012 02:51, schrieb Burkhard Müller:
>
>>> "top" zeigt nur, dass es sich um ein Perl-Skript handelt:
>>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>>> 27225 www-data 20 0 4812 2660 1228 R 98.7 1.1 37:31.82 perl
>>
>> Kennst du htop? Das ist ähnlich wie top aber erzeugt wesentlich
>> detaillierteren Output. Einen Versuch ist's wert.
>
>Heute war es wieder so weit: PID 25263. htop brachte nichts neues.
>
>Der Tipp von Sven brachte:
>ls -l /proc/25263/fd/0
>lr-x------ 1 www-data www-data 64 31. Jan 19:43 /proc/25263/fd/0 ->
>/dev/null
>
>Ich habe dann kill -SIGSTOP ausgeführt und mal ein bisschen in
>/proc/25263 herumgeschaut, ohne aber etwas zu finden. Auch in der Datei
>"cmdline" war nichts zu sehen.
Newline am Ende!). Vermutlich ist dieser aber auch nur perl.
>Analog zum obigen Tipp habe ich hier am alle Einträge in /fd:
>0 -> /dev/null
>1 -> pipe:[253028115]
>2 -> /var/log/apache2/error.log
>3 -> socket:[253028128]
>35 -> /tmp/.xcache.0.0.1955829363.lock (deleted)
>40 -> socket:[252980002]
>
>Kommt man mit der Nummer hinter "pipe" irgendwie weiter?
alle Inhalte, die über die Pipe geschickt wurden, sehen.
>Oder bei anderen Einträgen in /proc/25263/ ?
Stelle). Weiterhin interessant ist möglicherweise, welche
Seitenzugriffe dein Apache (das Fehlerlog ist ja
offen, da kannst du ja mal reingucken :)) um 19:43 beantwortet hat
(also zu dem Zeitpunkt, zu dem dieser ominöse Prozess gestartet
wurde). Das sollte in /var/log/apache2/access.log stehen.
Viele Grüße,
Claudius
--
<Teller> where am I and what am I doing in this handbasket?
Stefan Reuther
Jan 31, 2012, 4:02:07 PM1/31/12
to
Paul Lenz wrote:
> Ich habe dann kill -SIGSTOP ausgeführt und mal ein bisschen in
> /proc/25263 herumgeschaut, ohne aber etwas zu finden. Auch in
> der Datei "cmdline" war nichts zu sehen.
Bei einem Perl-Prozess hätte ich da aber schon was erwartet.
> Ich habe dann kill -SIGSTOP ausgeführt und mal ein bisschen in
> /proc/25263 herumgeschaut, ohne aber etwas zu finden. Auch in
> der Datei "cmdline" war nichts zu sehen.
Zeigt /proc/25263/exe auf das korrekte Programm (Perl-Interpreter)?
> Analog zum obigen Tipp habe ich hier am alle Einträge in /fd:
> 0 -> /dev/null
> 1 -> pipe:[253028115]
> 2 -> /var/log/apache2/error.log
> 3 -> socket:[253028128]
> 35 -> /tmp/.xcache.0.0.1955829363.lock (deleted)
> 40 -> socket:[252980002]
>
> Kommt man mit der Nummer hinter "pipe" irgendwie weiter?
ist das Lese-Ende, "l-wx------" ist das Schreibe-Ende. Höchstwahrschein-
lich wirst du da einen Apachen finden.
Solange der Prozess hängt, bekommst du mit netstat auch noch raus, was
das für Sockets sind (netstat -p, "PID/Program name").
Stefan
Paul Lenz
Jan 31, 2012, 8:11:39 PM1/31/12
to
Am 31.01.2012 22:02, schrieb Stefan Reuther:
> Zeigt /proc/25263/exe auf das korrekte Programm (Perl-Interpreter)?
Danke, das war der entscheidende Hinweis!
> Zeigt /proc/25263/exe auf das korrekte Programm (Perl-Interpreter)?
Bei der Zeile "exe -> /usr/bin/perl" ist "exe" in magenta dargestellt,
und zwei Zeilen darüber fiel mir noch etwas ins Auge wegen der gleichen
Farbe: "cwd -> /tmp/shm"
Aus purer Neugierde habe ich dort mal reingeschaut und unter anderem
auch Perl-Skripte gefunden:
#!/usr/bin/perl
# ----------------------------------------------------------- #
# ilegalbrain PerlBot v4.5 #
# Fuck Off All #
# ----------------------------------------------------------- #
Die älteste Datei dort namens passfinder.tgz ist von heute 19:42. Also
mal auth.log angeschaut. Ab 19:46 jede Menge "FAILED su for root by
www-data", aber nur eine Minute lang. Ansonsten nichts außergewöhnliches.
Zurück zu /tmp. Ich habe erst mal den ganzen Inhalt an einen anderen
Platz verschoben. Wenn ich die Sachen richtig verstehe, handelt es sich
um Skripte, irgendetwas mit IRC zu tun haben.
Nun frage ich mich, wie kommt "www-data" dort hinein, wenn nicht mit dem
Apache?
Paul Lenz
Helmut Hullen
Feb 1, 2012, 3:22:00 AM2/1/12
to
Hallo, Paul,
Du meintest am 01.02.12:
> Aus purer Neugierde habe ich dort mal reingeschaut und unter anderem
> auch Perl-Skripte gefunden:
> #!/usr/bin/perl
> # ----------------------------------------------------------- #
> # ilegalbrain PerlBot v4.5 #
> # Fuck Off All #
> # ----------------------------------------------------------- #
http://pastebin.com/4NAAi0tC
Werkelt anscheinend seit Anfang Januar.
> Die älteste Datei dort namens passfinder.tgz ist von heute 19:42.
> Also mal auth.log angeschaut. Ab 19:46 jede Menge "FAILED su for root
> by www-data", aber nur eine Minute lang. Ansonsten nichts
> außergewöhnliches.
[...]
> Nun frage ich mich, wie kommt "www-data" dort hinein, wenn nicht mit
> dem Apache?
Namen sind Schall und Rauch.
Wenn ich solches Dreckszeug schreiben würde, dann würde ich mich hinter
einem häufig werkelnden und scheinbar unverdächttigen Account
verstecken.
Du meintest am 01.02.12:
> Aus purer Neugierde habe ich dort mal reingeschaut und unter anderem
> auch Perl-Skripte gefunden:
> #!/usr/bin/perl
> # ----------------------------------------------------------- #
> # ilegalbrain PerlBot v4.5 #
> # Fuck Off All #
> # ----------------------------------------------------------- #
Werkelt anscheinend seit Anfang Januar.
> Die älteste Datei dort namens passfinder.tgz ist von heute 19:42.
> Also mal auth.log angeschaut. Ab 19:46 jede Menge "FAILED su for root
> by www-data", aber nur eine Minute lang. Ansonsten nichts
> außergewöhnliches.
> Nun frage ich mich, wie kommt "www-data" dort hinein, wenn nicht mit
> dem Apache?
Wenn ich solches Dreckszeug schreiben würde, dann würde ich mich hinter
einem häufig werkelnden und scheinbar unverdächttigen Account
verstecken.
Message has been deleted
Paul Lenz
Feb 4, 2012, 2:13:25 AM2/4/12
to
Am 01.02.2012 13:12, schrieb Heiko Schlenker:
> * Paul Lenz<pl...@arcor.de> schrieb:
> zusammengestrickten PHP-Anwendung. :->
So ist es wahrscheinlich. Ein Freund von mir hat einen Account auf
meinem Server und hat vor Jahren etwas mit PHP installiert und niemals
upgedatet. Der Eindringling hatte bei ihm alles mögliche hochgeladen und
offensichtlich auch sein Login-Passwort herausgefunden. Sehr ärgerlich,
aber auf der anderen Seite freut es mich, dass nicht - wie anfangs
befürchtet - eins meiner Perl-Skripte Schuld war.
Jedenfalls noch mal besten Dank an alle für die vielen Tipps!
Paul Lenz
> * Paul Lenz<pl...@arcor.de> schrieb:
>> Nun frage ich mich, wie kommt "www-data" dort hinein, wenn nicht mit
>> dem Apache?
>
> Typischerweise über eine Sicherheitslücke in einer halbgar
>> dem Apache?
>
> zusammengestrickten PHP-Anwendung. :->
So ist es wahrscheinlich. Ein Freund von mir hat einen Account auf
meinem Server und hat vor Jahren etwas mit PHP installiert und niemals
upgedatet. Der Eindringling hatte bei ihm alles mögliche hochgeladen und
offensichtlich auch sein Login-Passwort herausgefunden. Sehr ärgerlich,
aber auf der anderen Seite freut es mich, dass nicht - wie anfangs
befürchtet - eins meiner Perl-Skripte Schuld war.
Jedenfalls noch mal besten Dank an alle für die vielen Tipps!
Paul Lenz
0 new messages