Benutzer Apache lastet Server mit Befehl dev aus

Guten Morgen,

Ich stehe vor einem Problem.

Und zwar habe ich eine 100% Auslastung von eine CentOS 7 Maschine durch den Benutzer apache Es wird seit über 30 Tagen ein Befehl ausgeführt „DEV“

Die Webentwickler können sich das nicht erklären.

Die Logs von httpd sehen alle ziemlich gesund aus, auch andere haben auf dem ersten Blick keine große Einträge.

Habt Ihr einen Tip? Wo würdet Ihr suchen?

# netstat -a -v
Aktive Internetverbindungen (Server und stehende Verbindungen)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:mysql           0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN
tcp        0      0 HOSTE:smtp 0.0.0.0:*               LISTEN
tcp        0      0 HOST:https IPbla.dip0.t-:49933 SYN_RECV
tcp        0      0 HOST:https IPbla.dip0.t-:49931 SYN_RECV
tcp        0      0 HOST:https IPbla.dip0.t-:49935 SYN_RECV
tcp        0      0 HOST:https IPbla.dip0.t-:49934 SYN_RECV
tcp        0      0 HOST:https IPbla.dip0.t-:49932 SYN_RECV
tcp        0     64 HOSTE:ssh  MEINEIP:54952    VERBUNDEN
tcp        0      0 HOST:59600 static.111.58.9.5:45560 VERBUNDEN
tcp6       0      0 [::]:http               [::]:*                  LISTEN
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN
tcp6       0      0 localhost:smtp          [::]:*                  LISTEN
tcp6       0      0 [::]:https              [::]:*                  LISTEN
tcp6       0      0 HOST:https HOST:34254 TIME_WAIT
tcp6       0      0 HOST:https HOST:34226 TIME_WAIT
tcp6       0      0 HOST:https HOST:34258 TIME_WAIT
tcp6       0  19088 HOST:https IPbla.dip0.t-:49931 VERBUNDEN
tcp6       0      0 HOST:https HOST:34270 TIME_WAIT
tcp6       0      0 HOST:https HOST:34262 TIME_WAIT
tcp6       0   1017 HOST:https IPbla.dip0.t-:49935 VERBUNDEN
tcp6       0      0 HOST:https HOST:34242 TIME_WAIT
tcp6       0      0 HOST:https IPbla.dip0.t-:49932 VERBUNDEN
tcp6       0   2772 HOST:https IPbla.dip0.t-:49927 VERBUNDEN
tcp6       0      0 HOST:https HOST:34250 TIME_WAIT
tcp6       0      0 HOST:https node-ams.servergu:41396 TIME_WAIT
tcp6       0      0 HOST:https HOST:34238 TIME_WAIT
tcp6       0      0 HOST:https HOST:34234 TIME_WAIT
tcp6       0      0 HOST:https HOST:34246 TIME_WAIT
tcp6       0      0 HOST:https HOST:34266 TIME_WAIT
tcp6       0   8811 HOST:https IPbla.dip0.t-:49934 VERBUNDEN
tcp6       0      0 HOST:https HOST:34216 TIME_WAIT
tcp6       0   1804 HOST:https IPbla.dip0.t-:49933 VERBUNDEN
tcp6       0      0 HOST:https HOST:34214 TIME_WAIT
tcp6       0      0 HOST:https HOST:34230 TIME_WAIT
tcp6       0      0 HOST:https HOST:34222 TIME_WAIT
netstat: no support for `AF INET (sctp)' on this system.  
netstat: no support for `AF INET (sctp)' on this system.  
udp        0      0 l6.HOSTDOM:ntp 0.0.0.0:*
udp        0      0 l6.HOSTDOM:ntp 0.0.0.0:*
udp        0      0 HOSTE:ntp  0.0.0.0:*
udp        0      0 HOSTE:ntp  0.0.0.0:*
udp        0      0 0.0.0.0:ntp             0.0.0.0:*
udp6       0      0 l6.HOSTDOM:ntp [::]:*
udp6       0      0 l6.HOSTDOM:ntp [::]:*
udp6       0      0 localhost:ntp           [::]:*
udp6       0      0 [::]:ntp                [::]:*

Liebe Grüße

Ich

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 346553

Url: https://administrator.de/forum/benutzer-apache-lastet-server-mit-befehl-dev-aus-346553.html

Ausgedruckt am: 05.04.2025 um 00:04 Uhr

3 Kommentare

Neuester Kommentar

Moin
nun wenn des schon über 30 Tage bekannt ist und bislang "nichts" unternommen wurde.. nunja....

YouTube> Peer Heinlein: Totalschaden: Ein gehackter Server auf dem Seziertisch

möglich das der Server "übernommen" wurde wodurch es Fraglich ist ob die netstat Ausgabe auch unverändert gemacht wurde oder ob diese ersetzt...

Zudem ob nach der Langen Zeit noch was zu Finden ist, ist Fraglich da in der Zeit ja schon die Logfiles rotieren und ggfs Spuren auf der Platte Überschrieben wurden...

Ich würde das System als Kompromittiert ansehen und entsprechend alles neu Aufsetzten und nur Backups >30 Tage verwenden nach Gründlichen Checks.
Zudem hast du dort auch eine Fehlermeldung

netstat: no support for `AF INET (sctp)' on this system.
netstat: no support for `AF INET (sctp)' on this system.

Guten Tag,

Hammer. Danke für das Video.

dev     32594 apache    6u  IPv4 611659      0t0  TCP MYHOST:51920->static.IPbla.clients.your-server.de:45560 (ESTABLISHED) 

Der wurde unter dem folgenden Verzeichnis versteckt.

/var/lib/php/session/.d/*

Nach dem ich das Ding umbenannt habe und Prozess gekillt habe, läuft der Server nun normal.

Jetzt muss ich mir Gedanken machen wie es dahin gekommen ist. Es ist nur Port 80 und 443 offen. Magento ist schon eine Angriffsfläche aber wirklich so tief?

Liebe Grüße

Ich

Hallo,

eigentlich jedes CMS bietet schön Ansätze.
Meist wenn das System oder ein Plugin oder Theme einen Bug hat.

Wir sehen hier fast täglich immer Muster mit ähnlichen URLs wo nach bestimmten Plugins gesucht wird.
Wenn nix gefunden wird gehen die Angreifer einfach weiter.

FTP- und SSH-Accounts sind auch immer schöne Vektoren wenn man von einem PC die Kennwörter geschnappt hat.

Viele Grüße

Stefan

Frage Linux Webserver

Mehr von OIOOIOOIOIIOOOIIOIIOIOOO

Captive Portal durch UAP-AC läst sich nicht aufrufenOIOOIOOIOIIOOOIIOIIOIOOO - 21 Kommentare

Zertifikat mit rsync oder scp in pfSense einspielenOIOOIOOIOIIOOOIIOIIOIOOO

Raid10 mit mdadm löst sich nach jedem NeustartOIOOIOOIOIIOOOIIOIIOIOOO - 9 Kommentare

Mit QEMU eine VM in der Konsole erstellenOIOOIOOIOIIOOOIIOIIOIOOO - 5 Kommentare

Heiß diskutiert