24
Webserver 75 aktive Tasks Verdacht auf Schadscripte
Moin moin Admins,
folgende Frage:
ich habe einen Managed Server und seit heute morgen ziemlich Probleme mit der Performance und einieg Aktionen laufen in einen Timeout. Ich habe den Verdacht, das irgendwelche "bösen" Scriptchen ausgeführt werden.
In der Prozessübersicht werden mir 70 aktive Task angezeigt, grösstenteils PERL Scripte (Siehe Screen)
Dazu zwei Fragen:
ich möchte die Scripte alle beenden, um zu sehen,ob das Besserung bringt.
Zum einen wie kann ich sehen, was da genau ausgeführt wird?
Zum anderen kann man ja sehen, dass bei 3 Scripten bei Time 60 oder 70 und bei einem sogar 267:07:07 steht. Sind dass Stunden:Minuten:Sekunden? Hiesse dass, der Prozess wird seit 267 Stundnen ausgeführt? Ist das normal? Wo kann ich sehen, seit wann der Prozess ausgeführt wird?
Wäre prima, wenn Ihr mir das den ein oder anderen Tip geben könnt.
Danke schonmal Greetz
folgende Frage:
ich habe einen Managed Server und seit heute morgen ziemlich Probleme mit der Performance und einieg Aktionen laufen in einen Timeout. Ich habe den Verdacht, das irgendwelche "bösen" Scriptchen ausgeführt werden.
In der Prozessübersicht werden mir 70 aktive Task angezeigt, grösstenteils PERL Scripte (Siehe Screen)
Dazu zwei Fragen:
ich möchte die Scripte alle beenden, um zu sehen,ob das Besserung bringt.
Zum einen wie kann ich sehen, was da genau ausgeführt wird?
Zum anderen kann man ja sehen, dass bei 3 Scripten bei Time 60 oder 70 und bei einem sogar 267:07:07 steht. Sind dass Stunden:Minuten:Sekunden? Hiesse dass, der Prozess wird seit 267 Stundnen ausgeführt? Ist das normal? Wo kann ich sehen, seit wann der Prozess ausgeführt wird?
Wäre prima, wenn Ihr mir das den ein oder anderen Tip geben könnt.
Danke schonmal Greetz
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 301854
Url: https://administrator.de/forum/webserver-75-aktive-tasks-verdacht-auf-schadscripte-301854.html
Ausgedruckt am: 26.12.2024 um 05:12 Uhr
24 Kommentare
Neuester Kommentar
Moin,
TIME+ zeigt die CPU-zeit an, die die entsprechenden Proizesse "verbraten" haben.
Hiesse dass, der Prozess wird seit 267 Stundnen ausgeführt?
Nein, sondern daß er schon 267 CPU_Stunden verbraten hat. Je nachdem, welchen Anteil er bekommt kann das durchaus heißen, daß er ein vielfaches davon schon läuft.
Ist das normal?
Können wir nciht wissen, solange wir nicht wissen, was auf Dienem Webserver läuft. Nutzt Du überhaupt perl?
Wo kann ich sehen, seit wann der Prozess ausgeführt wird?
Ein ps aux soltle Dir da Auskunft geben.
lks
Siehe anderen Kommentar.
Moin,
In der Prozessübersicht werden mir 70 aktive Task angezeigt, grösstenteils PERL Scripte (Siehe Screen)
Das ist aber nicht sehr aussagekräftig.
Dazu zwei Fragen:
ich möchte die Scripte alle beenden, um zu sehen,ob das Besserung bringt.
killall -9 perl
Zum einen wie kann ich sehen, was da genau ausgeführt wird?
ps aux
Zum anderen kann man ja sehen, dass bei 3 Scripten bei Time 60 oder 70 und bei einem sogar 267:07:07 steht. Sind dass Stunden:Minuten:Sekunden?
Ja.
Hiesse dass, der Prozess wird seit 267 Stundnen ausgeführt?
Nein, das heißt der hat 267 CPU-Stunden "verbraten" Laufen kann er durchaus schon mehrere Wochen.
Ist das normal?
Kommt drafu an, Manchmal schon manchmal nicht. Kommt drauf an, was Dein System so treibt und ob das so gehört.
Wo kann ich sehen, seit wann der Prozess ausgeführt wird?
ps aux
lsof
Wäre prima, wenn Ihr mir das den ein oder anderen Tip geben könnt.
s.o.
N'Abend noch.
lks
Nabend
und ein netstat -tapen sagt dir wer was wohin tut....
was sagt den dein Managed Server Admin dazu ?
Frank
und ein netstat -tapen sagt dir wer was wohin tut....
was sagt den dein Managed Server Admin dazu ?
Frank
Ja, wir nutzen PERL. Wir sind im Moment dabei einen neuen Webshop aufzusetzen und der alte, der im Moment läuft nutzt Perl.
Es ist beispielweise so, dass Bestätigungsemails bei Bestellungen seit heute nicht mehr ankommen, weder beim Kunden, noch bei unserer Buchhaltung.
Kann dass damit zusammenhängen, dass da ein Prozess im Loop läuft?
Es ist beispielweise so, dass Bestätigungsemails bei Bestellungen seit heute nicht mehr ankommen, weder beim Kunden, noch bei unserer Buchhaltung.
Kann dass damit zusammenhängen, dass da ein Prozess im Loop läuft?
Zitat von @wescraven07:
Ja, wir nutzen PERL. Wir sind im Moment dabei einen neuen Webshop aufzusetzen und der alte, der im Moment läuft nutzt Perl.
Ja, wir nutzen PERL. Wir sind im Moment dabei einen neuen Webshop aufzusetzen und der alte, der im Moment läuft nutzt Perl.
o.k Dann ist es schonmal normal, daß Perl läuft.
Es ist beispielweise so, dass Bestätigungsemails bei Bestellungen seit heute nicht mehr ankommen, weder beim Kunden, noch bei unserer Buchhaltung.
Dann wirf mal tcpdump oder wireshark an und horch mit, wenn eine mail rausgeht. ggf einfach eine Testbestellung im Shop machen.
Kann dass damit zusammenhängen, dass da ein Prozess im Loop läuft?
Möglich. Ist aber schwer zu sagen, ohne Euer System zu kennen.
lks
Habe ich eben zweimal, beide male kommt keine Email an. wie funktioniert das genau mit tcpdump oder rwiresharp?
Achso, was ich noch vergessen hatte: Es dauert seit heute acuh sicher 30 Sekunden, bis ich mit SSH eingeloggt bin, auch nicht normal...
Achso, was ich noch vergessen hatte: Es dauert seit heute acuh sicher 30 Sekunden, bis ich mit SSH eingeloggt bin, auch nicht normal...
Zitat von @wescraven07:
Habe ich eben zweimal, beide male kommt keine Email an. wie funktioniert das genau mit tcpdump oder rwiresharp?
Habe ich eben zweimal, beide male kommt keine Email an. wie funktioniert das genau mit tcpdump oder rwiresharp?
man tcpdump
man wireshark
Achso, was ich noch vergessen hatte: Es dauert seit heute acuh sicher 30 Sekunden, bis ich mit SSH eingeloggt bin, auch nicht normal...
vermutlich ziemlich hoher load. was sagt denn uptime oder iotop?
Du kannst natürlich die Radikalmethode wählen und einfach einen reboot machen. "reboot tut gut" wie der Windows-Admin zu sagen pflegt.
lks
Moin,
Logs wälzen wäre wohl die einfachere Variante.
Ansonsten mal prüfen was die ganzen "bash"-Instanzen da machen.
Letztlich kann man sich aber nur @Vision2015 anschließen: Wenn der Server managed ist, solltest du deinen Server Admin fragen, was da schief läuft, immerhin bezahlst du ziemlich genau für sowas :D Kann natürlich sein, dass dieser sagt, du baust mit deiner Anwendung Mist.
Gruß
Chris
Dann wirf mal tcpdump oder wireshark an und horch mit, wenn eine mail rausgeht. ggf einfach eine Testbestellung im Shop machen.
Logs wälzen wäre wohl die einfachere Variante.
Achso, was ich noch vergessen hatte: Es dauert seit heute acuh sicher 30 Sekunden, bis ich mit SSH eingeloggt bin, auch nicht normal...
Was sagen denn deine ping-Zeiten?Ansonsten mal prüfen was die ganzen "bash"-Instanzen da machen.
Letztlich kann man sich aber nur @Vision2015 anschließen: Wenn der Server managed ist, solltest du deinen Server Admin fragen, was da schief läuft, immerhin bezahlst du ziemlich genau für sowas :D Kann natürlich sein, dass dieser sagt, du baust mit deiner Anwendung Mist.
Gruß
Chris
Na ja, der Server wird von Strato "gemanaged" und die sagen, dass Sie an die Kundendaten nicht rankommen und dementsprechend nichts machen können. Der Tip von Strao war: Alles löschen, letzte Backup einspielen.
Habe mir eben mit ps aux nochmal die Prozesse angesehen und könnte mir vorstellen, die Ursache des Übels gefunden zu haben, es sei denn ein Prozess names "Fuck You" ist normal...siehe (screen).
Nur sehe ich nicht, wo das File liegt bzw. was da genu ausgeüführt wird...Gibt es eine Möglichkeit, das festzustellen..
Habe mir eben mit ps aux nochmal die Prozesse angesehen und könnte mir vorstellen, die Ursache des Übels gefunden zu haben, es sei denn ein Prozess names "Fuck You" ist normal...siehe (screen).
Nur sehe ich nicht, wo das File liegt bzw. was da genu ausgeüführt wird...Gibt es eine Möglichkeit, das festzustellen..
Zitat von @wescraven07:
Na ja, der Server wird von Strato "gemanaged" und die sagen, dass Sie an die Kundendaten nicht rankommen und dementsprechend nichts machen können.
Na ja, der Server wird von Strato "gemanaged" und die sagen, dass Sie an die Kundendaten nicht rankommen und dementsprechend nichts machen können.
die müsen ja nicht an die Kudnendaten. Die können den traffic überwachen und Dir sagen, ob da irgendetwas ungewöhliches vorgeht. Und administrativen Zugriff auf die Kiste müssendie ja auch irgendwie haben, um die Kiste zu administrieren (oder was genau soll denn das managed sonst heißen?).
Der Tip von Strao war: Alles löschen, letzte Backup einspielen.
das wäre eine Möglichkeit, Aber hast Du denn einfach mal einen reboot versucht?
lks
Ja, gester abend wurde der Server von Strato neu gestartet...
Hat es etwas gebracht?
lks
Nein.
Aber ich hab ja vorhin einein Screenshot gepostet.
Es ist sind viele Prozesse namens "fuckyou" am Laufen, unter anderem auch der der seit 276 Stunden läuft seit 12. April...das passt ungefärh mit dem Start der Problem zusammen...ich finde nur im Moment keine Möglichkeit herauszufinden, wo die Datei oder das Script liegt und es zu löschen....
Aber ich hab ja vorhin einein Screenshot gepostet.
Es ist sind viele Prozesse namens "fuckyou" am Laufen, unter anderem auch der der seit 276 Stunden läuft seit 12. April...das passt ungefärh mit dem Start der Problem zusammen...ich finde nur im Moment keine Möglichkeit herauszufinden, wo die Datei oder das Script liegt und es zu löschen....
hi,
wie ich schon mal sagte- ein netstat -tapen sagt dir wer was wohin tut....
das script zu löschen reicht nicht- du sollst sehen wie es reingekommen ist- und da dichtmachen!!!!
strato hätte den server sofort vom netz nehmen müssen- unverantwortlich sowas.
frank
wie ich schon mal sagte- ein netstat -tapen sagt dir wer was wohin tut....
das script zu löschen reicht nicht- du sollst sehen wie es reingekommen ist- und da dichtmachen!!!!
strato hätte den server sofort vom netz nehmen müssen- unverantwortlich sowas.
frank
Moin,
sieht in jedem Fall nach was häösslichem aus.
könnte dich ggf. zum Ziel führen, allerdings löst das löschen höchstens ein Symtom.
Ihr habt irgendwo auf dem server eine sicherheitslücke und die sollte geschlossen werden.
Gruß
Chris
sieht in jedem Fall nach was häösslichem aus.
which fuckyouIhr habt irgendwo auf dem server eine sicherheitslücke und die sollte geschlossen werden.
Gruß
Chris
Hallo,
wenn keiner von euch so ein Script gebaut hat und es Bestandteil eures systems ist, nein fuckyou ist nicht normal.
http://security.stackexchange.com/questions/87026/malware-script-upload ...
was sagt last? Das Listet die letzten Logins ins System auf. Ist da eine IP aus China oder sonstwo her?
Ist Iptables im Einsatz?
Ist der SSH Zugriff noch mit Passwort oder schon auf Keyonly gestellt?
Ist der sshlogin für root verboten?
Habt ihr eine Feste IP? Dann ssh nur für eure IP zulassen über IPTABLES.
Was für Cronjobs sind bei den einzelnen Benuzern eingerichtet?
Gibt es nues Systembenutzer?
Gruß
Chonta
wenn keiner von euch so ein Script gebaut hat und es Bestandteil eures systems ist, nein fuckyou ist nicht normal.
http://security.stackexchange.com/questions/87026/malware-script-upload ...
was sagt last? Das Listet die letzten Logins ins System auf. Ist da eine IP aus China oder sonstwo her?
Ist Iptables im Einsatz?
Ist der SSH Zugriff noch mit Passwort oder schon auf Keyonly gestellt?
Ist der sshlogin für root verboten?
Habt ihr eine Feste IP? Dann ssh nur für eure IP zulassen über IPTABLES.
Was für Cronjobs sind bei den einzelnen Benuzern eingerichtet?
Gibt es nues Systembenutzer?
Gruß
Chonta
War der screnshot vor ode rnach dem Neustart?
Weil wenn er nach dem angeblichen Neutsart geweswen sein soll, dann war da keiner. Sonst würde es keine älteren Prozesse als gestern Abend geben.
Es ist sind viele Prozesse namens "fuckyou" am Laufen, unter anderem auch der der seit 276 Stunden läuft seit 12. April...das passt ungefärh mit dem Start der Problem zusammen...ich finde nur im Moment keine Möglichkeit herauszufinden, wo die Datei oder das Script liegt und es zu löschen....
Image ziehen, Kiste platttmachen udn aus dem backup einspielen. dann das Image mit forensischen Tools analysieren.
Alles andere ist unverantwortlichm weil das nur der verbreitung von malware und SPAM Vorschub leistet.
Und vor allem jemanden himnzuziehen, der sich damit auskennt.
Stell mal ein, daß keinerlei Dienste außer ssh nach einem Reboot hochfahren und dann kannst Du Zug um Zug schauen, bei welchem Dienst die Prozesse wieder kommen. Dabei immer genau mit tcpdump mitschneiden, was auf den Interfaces passiert.
Du könntest auch mit
auditctl -A exit,always -S connectlks
Man man man, daran habe ich noch gar nicht gedacht...der Screenshot war nach dem angeblichen Neustart...
Ich denk da werd ich nochmal mit Strato sprechen müssen...
Ich denk da werd ich nochmal mit Strato sprechen müssen...
Da musst du mit fast keinem mehr sprechen. Wenn du / ihr als Betreiber des Servers nicht wisst, was "fuckyou" eigentlich ist, dann habe ihr die Kontrolle über die Kiste verloren!
Image erstellen / erstellen lassen - neues OS hochziehen. Nebenher das Image untersuchen und hoffen, das ihr herausfindet, was ihr da falsch gemacht habt. Im Zweifel Fachmann ranlassen.
Image erstellen / erstellen lassen - neues OS hochziehen. Nebenher das Image untersuchen und hoffen, das ihr herausfindet, was ihr da falsch gemacht habt. Im Zweifel Fachmann ranlassen.
Zitat von @Sheogorath:
könnte dich ggf. zum Ziel führen, allerdings löst das löschen höchstens ein Symtom.
which fuckyouJa, aber zweifelsfrei sicherstellen kannst du das damit nicht, weil der Prozess eventuell mit anderem Standardsuchpfad gestartet wurde.
Zuerst sollte man den Prozess einfrieren, damit er nicht zwischendurch beendet wird.
Bei allen nachfolgend genannten Befehlen das <pid> durch die jeweilige PID des Prozesses ersetzen:
/bin/kill -s SIGSTOP <pid>Wirklich Gewissheit bringt dir dann ein
ls -la /proc/<pid>/exe
less /proc/<pid>/cmdlineMit
ls -la /proc/<pid>/fdZuletzt sollte man noch in Erfahrung bringen, wann der Prozess gestartet wurde:
stat /proc/<pid>Dort steht dann, welcher User den Prozess gestartet hat und auch, wann er erzeugt wurde. Mit den Infos kannst du dann durch Logfiles laufen und herausfinden, was zu diesem Zeitpunkt passiert ist - z.B. merkwürdige Aufrufe gegen Dateien des Webservers oder so...
Im Zweifel holt euch professionelle Hilfe ins Haus, damit festgestellt werden kann wie es dazu kommt dass da plötzlich unbekannte Prozesse laufen.
1
Hallo,
habe zufällig einen Blogbeitrag mit dem selben Thema gesehen vielleicht hilft er bei der Fehlersuche
http://security.stackexchange.com/questions/87026/malware-script-upload ...
Lg Maximus Prime
habe zufällig einen Blogbeitrag mit dem selben Thema gesehen vielleicht hilft er bei der Fehlersuche
http://security.stackexchange.com/questions/87026/malware-script-upload ...
Lg Maximus Prime
Kurzes Update, im Moment ist der Server wohl clean. Aber am Montag wird sich ein Linuxadmin das Ding ansehen.
Eine Frage an Euch trotzdem noch:
Heute morgen war de Webseite nicht erreichbar. Top hat 300 aktive Task php56-cgi ergeben, einige davon mit dem Vermerk <defunct>. ein
PS Aux
Hat ca. 30 Zeilen
/kunden/usr/bin/php56-cgi --php-ini /kunden/config/vhosts/11065/37436.ini
ergeben. Heisst dass dass eben 30 gleichzeitige Zugriffe auf die Webseite erfolgen und man in der 37436.ini die IP´s sehen könnte? Wie kann ich die 37436.ini öffnen?
Ich weiss, dass jetzt bestimmt wieder einige den Kopp gegen die Wand hauen werden, aber irgendwie muss man´s ja lernen.
Eine Frage an Euch trotzdem noch:
Heute morgen war de Webseite nicht erreichbar. Top hat 300 aktive Task php56-cgi ergeben, einige davon mit dem Vermerk <defunct>. ein
PS Aux
Hat ca. 30 Zeilen
/kunden/usr/bin/php56-cgi --php-ini /kunden/config/vhosts/11065/37436.ini
ergeben. Heisst dass dass eben 30 gleichzeitige Zugriffe auf die Webseite erfolgen und man in der 37436.ini die IP´s sehen könnte? Wie kann ich die 37436.ini öffnen?
Ich weiss, dass jetzt bestimmt wieder einige den Kopp gegen die Wand hauen werden, aber irgendwie muss man´s ja lernen.
Zitat von @wescraven07:
Ich weiss, dass jetzt bestimmt wieder einige den Kopp gegen die Wand hauen werden,
exaktIch weiss, dass jetzt bestimmt wieder einige den Kopp gegen die Wand hauen werden,
aber irgendwie muss man´s ja lernen.
schau dem Fachmann über die Schulter.Kurzes Update, im Moment ist der Server wohl clean. Aber am Montag wird sich ein Linuxadmin das Ding ansehen.
Sagt wer und auf welcher Grundlage basierend ist diese Annahme?schau dem Fachmann über die Schulter.
Das reicht nicht.Ich würde eine Linuxschulung empfehlen und dan gezieltes Selbsstudium in die verwendeten Programme.
Gruß
Chonta
