Apr 14, 2016, updated at 19:03:33 (UTC)

2404

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

Please also mark the comments that contributed to the solution of the article

Content-Key: 301854

Url: https://administrator.de/contentid/301854

Printed on: April 18, 2024 at 22:04 o'clock

24 Comments

Latest comment

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.

Zitat von @wescraven07:

Moin moin Admins,

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

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?

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.

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...

Zitat von @wescraven07:

Habe ich eben zweimal, beide male kommt keine Email an. wie funktioniert das genau mit tcpdump oder rwiresharp?

man tcpdump

oder

man wireshark

sollten Dir weiterhelfen. Allerdings ist die Frage, ob Du bei so wenig Linux-Wissen der richtige für die Analyse bist, vor allem wenn da wirklich Schadsoftware drauf sein sollte. Ruf mal Deinen Hoster an, wenn das wirklich ein managed Server ist.

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,

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..

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.

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...

Zitat von @wescraven07:

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....

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

Moin,

sieht in jedem Fall nach was häösslichem aus.

which fuckyou

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

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

Zitat von @wescraven07:

Nein.

Aber ich hab ja vorhin einein Screenshot gepostet.

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 connect

mitprotokollieren, wlche verbindungen auf und zugemacht werden.

lks

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...

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.

Zitat von @Sheogorath:

which fuckyou

könnte dich ggf. zum Ziel führen, allerdings löst das löschen höchstens ein Symtom.

Ja, 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>/cmdline

Damit wird dir ausgegeben, welche Binary (kompletter Pfad) mit welchen Parametern gestartet wurde.

Mit

ls -la /proc/<pid>/fd

kann man bei der Gelegenheit noch nachschauen, welche File-Descriptor geöffnet wurden. Das können Dateien, aber auch Netzwerkverbindungen sein.

Zuletzt 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.

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

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.