# ispconfig-server gehackt?



## Sigix (3. Dez. 2013)

Hallo,

ich habe ein großes Problem; ich vermute das mein ISP-Config Server von Dritte übernommen wurde!

Distribution: Debian squeeze (6.0.8)
ISP-Config: 3.0.3.3

Folgendes kann ich beobachten:
in den Prozessen (top) starten sich Dienste mit dem Namen s, vi, k, ....

Wenn sich so ein Dienst startet, hat mein Server 99.98 % Auslastung und ich kann enorm hohe Netzwerkaktivität beobachten;

Hier die Prozesse:
 www-data 7842 93.7 0.4 29520 4296 ? S 12:43 75:48 /usr/sbin/acpid www-data 11279 4.6 0.1 41032 1572 ? Ssl 13:21 2:01 m64 -o stratum+tcp://5.254.102.165:3333 -O judge.1:x -B root 13973 0.0 0.0 10452 492 ? Ss 14:04 0:00 vzctl: ttyp0 

in den Logs habe ich folgendes gefunden:

[Tue Dec 03 12:10:46 2013] [error] [client 94.102.51.238] --2013-12-03 12:10:46--  (try: 3)  http://hecks.ddosdev.com/pwnnetd
[Tue Dec 03 12:10:46 2013] [error] [client 94.102.51.238] Connecting to hecks.ddosdev.com|192.151.144.234|:80...
[Tue Dec 03 12:10:46 2013] [error] [client 94.102.51.238] --2013-12-03 12:10:46--  (try: 3)  http://hecks.ddosdev.com/pwnnetd3
[Tue Dec 03 12:10:46 2013] [error] [client 94.102.51.238] Connecting to hecks.ddosdev.com|192.151.144.234|:80...
[Tue Dec 03 12:11:07 2013] [error] [client 94.102.51.238] failed: Connection timed out.
[Tue Dec 03 12:11:07 2013] [error] [client 94.102.51.238] Retrying.
[Tue Dec 03 12:11:07 2013] [error] [client 94.102.51.238]
[Tue Dec 03 12:11:07 2013] [error] [client 94.102.51.238] failed: Connection timed out.
[Tue Dec 03 12:11:07 2013] [error] [client 94.102.51.238] Retrying.
[Tue Dec 03 12:11:07 2013] [error] [client 94.102.51.238]
[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


rkhunter hat nichts gefunden!

chkrootkit sagt folgendes:
Checking `bindshell'...INFECTED (PORTS:  465)
Searching for suspicious files and dirs, it may take a while... The following suspicious files and directories were found: /usr/lib/pymodules/python2.6/.path /lib/init/rw/.ramfs


Kann mir hierzu wer helfen ????


----------



## Till (3. Dez. 2013)

Wahrscheinlich wurde "nur" eine Wesebiet gehackt und nicht dein Server übernommen, also der Angreifer ist nicht root. In welchem Log genau stand das?

Der chkrootkit output ist ok und hat nichts zu bedeuten, das bindshell INFECTED ist ein bekannetr false positive.

Nutzt Du in allen webseiten php-fcgi + suexec oder nutzt du mod_php?

Checke Deinen server mal mit maldet:

HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials - View Single Post - Linux Malware Detect on Debian 6 with ISPConfig 3


----------



## Sigix (3. Dez. 2013)

Zitat von Till:


> Wahrscheinlich wurde "nur" eine Wesebiet gehackt und nicht dein Server übernommen, also der Angreifer ist nicht root. In welchem Log genau stand das?
> 
> Der chkrootkit output ist ok und hat nichts zu bedeuten, das bindshell INFECTED ist ein bekannetr false positive.
> 
> ...


Das stand im apache-error log!
Ja hab bei allen Seiten SuPHP eingetragen!

ich check mal gleich mit maldet durch!

lg


----------



## Sigix (3. Dez. 2013)

Zitat von Sigix:


> Das stand im apache-error log!
> Ja hab bei allen Seiten SuPHP eingetragen!
> 
> ich check mal gleich mit maldet durch!
> ...


Soeben ist wieder ein Prozess gekommen "perl"
18062 www-data  25   0 29520 4292 1424 S 94.9  0.4   6:07.60 perl

Hier der Prozessinhalt:
-r--------   1 www-data www-data 0 Dec  3 16:42 auxv
-r--r--r--   1 www-data www-data 0 Dec  3 16:37 cmdline
-rw-r--r--   1 www-data www-data 0 Dec  3 16:42 coredump_filter
-r--r--r--   1 www-data www-data 0 Dec  3 16:42 cpuset
lrwxrwxrwx   1 www-data www-data 0 Dec  3 16:42 cwd -> /tmp
-r--------   1 www-data www-data 0 Dec  3 16:42 environ
lrwxrwxrwx   1 www-data www-data 0 Dec  3 16:37 exe -> /usr/bin/perl
dr-x------   2 www-data www-data 0 Dec  3 16:42 fd
dr-x------   2 www-data www-data 0 Dec  3 16:42 fdinfo
-r--r--r--   1 www-data www-data 0 Dec  3 16:42 io
-r--r--r--   1 www-data www-data 0 Dec  3 16:42 limits
-rw-r--r--   1 www-data www-data 0 Dec  3 16:42 loginuid
-r--r--r--   1 www-data www-data 0 Dec  3 16:42 maps
-rw-------   1 www-data www-data 0 Dec  3 16:42 mem
-r--r--r--   1 www-data www-data 0 Dec  3 16:42 mounts
-r--------   1 www-data www-data 0 Dec  3 16:42 mountstats
-r--r--r--   1 www-data www-data 0 Dec  3 16:42 numa_maps
-rw-r--r--   1 www-data www-data 0 Dec  3 16:42 oom_adj
-r--r--r--   1 www-data www-data 0 Dec  3 16:42 oom_score
lrwxrwxrwx   1 www-data www-data 0 Dec  3 16:42 root -> /
-r--r--r--   1 www-data www-data 0 Dec  3 16:42 schedstat
-r--r--r--   1 www-data www-data 0 Dec  3 16:42 smaps
-r--r--r--   1 www-data www-data 0 Dec  3 16:42 stack
-r--r--r--   1 www-data www-data 0 Dec  3 16:37 stat
-r--r--r--   1 www-data www-data 0 Dec  3 16:37 statm
-r--r--r--   1 www-data www-data 0 Dec  3 16:42 status
dr-xr-xr-x   3 www-data www-data 0 Dec  3 16:42 task
-r--r--r--   1 www-data www-data 0 Dec  3 16:42 wchan

????????


----------



## Till (3. Dez. 2013)

irgend was in /tmp, wenn Du mit ls -la checkst? Schau Dir mal den Prozess mit lsof näher an.


----------



## Sigix (3. Dez. 2013)

Zitat von Till:


> irgend was in /tmp, wenn Du mit ls -la checkst? Schau Dir mal den Prozess mit lsof näher an.


es waren 2 Dienste:
perl und sh ....

jetz muss ich warten bis diese wieder kommen damit ich checken kann ob irgendetwas im tmp drinnen ist!

Wenn ich den Dienst "sh" mit pkill beende, verliere ich auch die ssh verbindung zum server und muss diesen komplett neu starten damit ich wieder drauf komme! ??


----------



## Till (3. Dez. 2013)

Checke mal die crontab vn www-data, ob da was drin steht. die sollte an sich leer sein.

crontab -u www-data -e


----------



## Sigix (3. Dez. 2013)

Zitat von Till:


> Checke mal die crontab vn www-data, ob da was drin steht. die sollte an sich leer sein.
> 
> crontab -u www-data -e


nee ist nicht leer

* * * * * /tmp/update >/dev/null 2>&1

???


----------



## Sigix (3. Dez. 2013)

Zitat von Sigix:


> nee ist nicht leer
> 
> * * * * * /tmp/update >/dev/null 2>&1
> 
> ???


maldet ergebnis:
root@mail2:~# /usr/local/maldetect/maldet -a /
Linux Malware Detect v1.4.2
            (C) 2002-2013, R-fx Networks <proj@r-fx.org>
            (C) 2013, Ryan MacDonald <ryan@r-fx.org>
inotifywait (C) 2007, Rohan McGovern <rohan@mcgovern.id.au>
This program may be freely redistributed under the terms of the GNU GPL v2

maldet(7773): {scan} signatures loaded: 11355 (9483 MD5 / 1872 HEX)
maldet(7773): {scan} building file list for /, this might take awhile...
/usr/bin/find: `/proc/7825/task/7825/fd/5': No such file or directory
/usr/bin/find: `/proc/7825/task/7825/fdinfo/5': No such file or directory
/usr/bin/find: `/proc/7825/fd/5': No such file or directory
/usr/bin/find: `/proc/7825/fdinfo/5': No such file or directory
maldet(7773): {scan} file list completed, found 313210 files...
maldet(7773): {scan} found ClamAV clamscan binary, using as scanner engine...
maldet(7773): {scan} scan of / (313210 files) in progress...
maldet(7773): {scan} processing scan results for hits: 144 hits 0 cleaned
maldet(7773): {scan} scan completed on /: files 313210, malware hits 144, cleaned hits 0
maldet(7773): {scan} scan report saved, to view run: maldet --report 120313-1651.7773
maldet(7773): {scan} quarantine is disabled! set quar_hits=1 in conf.maldet or to quarantine results run: maldet -q 120313-1651.7773



{HEX}gzbase64.inject.unclassed.14 : /usr/src/maldetect-1.4.2/files/clean/gzbase64.inject.unclassed
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/vmail/example.co.at/office/new/1353518993.M529823P10071V0000000000009039I000000000554C522_0.mail2.sx-it.com,S=5153
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/H/virus-HhANJdyVkNFz
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/H/virus-H-3hD0hxiyjc
{CAV}Heuristics.Phishing.Email.SSL-Spoof : /var/lib/amavis/virusmails/5/virus-5bMONeQH3J0V
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/W/virus-W3xAq6vLcGin
{CAV}Heuristics.Phishing.Email.SSL-Spoof : /var/lib/amavis/virusmails/W/virus-WhhYsuCaTGRb
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/W/virus-WgbnyI5wMO-x
{CAV}Heuristics.Phishing.Email.SSL-Spoof : /var/lib/amavis/virusmails/W/virus-WatxDP2jsxul
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/W/virus-WQBMGH40ei1K
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/W/virus-Wa-YxnvnOoAR
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/W/virus-WY4ecV4HgR9S
{CAV}Heuristics.Phishing.Email.SSL-Spoof : /var/lib/amavis/virusmails/0/virus-07mUDlqKTh7d
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/0/virus-0D-xoFHEEeHr
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/0/virus-0uNZSEUnl6yB
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/0/virus-0jTdAMFBH6ZA
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/0/virus-0-8XLgTxenhh
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/0/virus-0Ozlyvl9297V
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/B/virus-BQJWgVDASc7f
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/B/virus-BqFMsAahPAeK
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/t/virus-tfUucyh03MUf
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/t/virus-txvWjB8iDueE
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/m/virus-mBtqEBkMfjK4
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/m/virus-mI8J+yUziQmn
{CAV}Heuristics.Phishing.Email.SSL-Spoof : /var/lib/amavis/virusmails/v/virus-vol4n8hgET-1
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/E/virus-E3jCJxQ6azO0
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/M/virus-MqIQa+xd-Y4V
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/M/virus-M5U6l0bxz-D3
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/6/virus-6WTDg2RMiaXa
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/n/virus-n9HpveH1a19G
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/n/virus-nDmYskDzn2Up
{CAV}Heuristics.Phishing.Email.SSL-Spoof : /var/lib/amavis/virusmails/n/virus-nAAexjCI1s4F
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/k/virus-kbRCzTIVQBhg
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/k/virus-kafFQ6neduSg
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/k/virus-ksaCY3gD1V7I
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/k/virus-kAnIOeyLWRl8
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/k/virus-krsT42hN+a6n
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/z/virus-zyfCY+9uV8uq
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/z/virus-zMKRbim8i8Rr
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/z/virus-z6SWUqt5cM+L
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/g/virus-gth6xx4M5-Bj
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/4/virus-4mPlwlS-pDlb
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/4/virus-4zMgKyf4buAi
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/4/virus-4KSs5uYxhoYx
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/h/virus-hNzYkvC8AErF
{CAV}Heuristics.Phishing.Email.SSL-Spoof : /var/lib/amavis/virusmails/h/virus-hX5v5Cs4cnwc
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/h/virus-hgJFFcXsDNld
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/h/virus-hkfykmkpE2Ht
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/1/virus-1w3Y5vYp4mAJ
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/1/virus-1LdNcAkkDdHi
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/1/virus-1qx1NyYtQD-w
{CAV}Heuristics.Phishing.Email.SpoofedDomain : /var/lib/amavis/virusmails/1/virus-19p9EUTFyKtP


----------



## Sigix (3. Dez. 2013)

So die Dienste sind wieder da ....

hier lsof des Dienstes

pwnnetd   17846 www-data  cwd    DIR               0,43     475136  214040585 /tmp
pwnnetd   17846 www-data  rtd    DIR               0,43       4096  213992283 /
pwnnetd   17846 www-data  txt    REG               0,43     592464  214041280 /tmp/pwnnetd
pwnnetd   17846 www-data  mem    REG               0,43     128744  214041320 /lib/ld-2.11.3.so
pwnnetd   17846 www-data  mem    REG               0,43      31744  214041325 /lib/librt-2.11.3.so
pwnnetd   17846 www-data  mem    REG               0,43     131258  214041317 /lib/libpthread-2.11.3.so
pwnnetd   17846 www-data  mem    REG               0,43    1437064  214041464 /lib/libc-2.11.3.so
pwnnetd   17846 www-data  mem    REG               0,43      51728  214041275 /lib/libnss_files-2.11.3.so
pwnnetd   17846 www-data  mem    REG               0,43      22928  214041602 /lib/libnss_dns-2.11.3.so
pwnnetd   17846 www-data  mem    REG               0,43      80712  214041277 /lib/libresolv-2.11.3.so
pwnnetd   17846 www-data    0r   CHR                1,3        0t0  214028481 /dev/null
pwnnetd   17846 www-data    1w  FIFO                0,6        0t0 1695036699 pipe
pwnnetd   17846 www-data    2w  FIFO                0,6        0t0 1695036133 pipe
pwnnetd   17846 www-data    3r   REG               0,43    8385936  214024391 /usr/lib/cgi-bin/php5

was soll ich da machen ???? Der Dienst ist 4 mal da!!


----------



## Sigix (3. Dez. 2013)

lsof vom Dienst "s"

root@mail2:/# lsof | grep 24484
s         24484 www-data  cwd    DIR               0,43       4096  219037713 /tmp/.,
s         24484 www-data  rtd    DIR               0,43       4096  213992283 /
s         24484 www-data  txt    REG               0,43       7360  213991580 /usr/bin/perl
s         24484 www-data  mem    REG               0,43     128744  214041320 /lib/ld-2.11.3.so
s         24484 www-data  mem    REG               0,43    1495784  214036835 /usr/lib/libperl.so.5.10.1
s         24484 www-data  mem    REG               0,43      14696  214041622 /lib/libdl-2.11.3.so
s         24484 www-data  mem    REG               0,43     530736  214041631 /lib/libm-2.11.3.so
s         24484 www-data  mem    REG               0,43     131258  214041317 /lib/libpthread-2.11.3.so
s         24484 www-data  mem    REG               0,43    1437064  214041464 /lib/libc-2.11.3.so
s         24484 www-data  mem    REG               0,43      35104  214041574 /lib/libcrypt-2.11.3.so
s         24484 www-data  mem    REG               0,43      19920  214036796 /usr/lib/perl/5.10.1/auto/IO/IO.so
s         24484 www-data  mem    REG               0,43      25976  214036798 /usr/lib/perl/5.10.1/auto/Socket/Socket.so
s         24484 www-data  mem    REG               0,43      51728  214041275 /lib/libnss_files-2.11.3.so
s         24484 www-data  mem    REG               0,43      22928  214041602 /lib/libnss_dns-2.11.3.so
s         24484 www-data  mem    REG               0,43      80712  214041277 /lib/libresolv-2.11.3.so
s         24484 www-data    0r  FIFO                0,6        0t0 1699083772 pipe
s         24484 www-data    1w  FIFO                0,6        0t0 1699083786 pipe
s         24484 www-data    2w  FIFO                0,6        0t0 1699083774 pipe
s         24484 www-data    3r   REG               0,43    8385936  214024391 /usr/lib/cgi-bin/php5
s         24484 www-data    4u  IPv4         1699117251        0t0        TCP mail2.sx-it.com:41104->ipbrick.cades.fr:6670 (ESTABLISHED)
s         24484 www-data   78r  FIFO                0,6        0t0 1690944073 pipe
s         24484 www-data   79w  FIFO                0,6        0t0 1690944073 pipe
s         24484 www-data   80r  FIFO                0,6        0t0 1690944074 pipe
s         24484 www-data   81w  FIFO                0,6        0t0 1690944074 pipe


 in dem Ordner "/tmp/.," ist folgendes vorhanden:
 -rwxr-xr-x 1 www-data www-data     74 Feb 24  2009 .u
-rwxr-xr-x 1 www-data www-data    319 Feb 22  2009 autorun
-rw-r--r-- 1 www-data www-data     41 Dec  3 18:52 cron.d
-rwxr-xr-x 1 www-data www-data 152108 Jun  1  2001 crond
-rwxr-xr-x 1 www-data www-data   8687 Jan 24  2006 f
-rwxr-xr-x 1 www-data www-data  14679 Nov  3  2005 f4
-rw-r--r-- 1 www-data www-data      8 Dec  3 18:52 fl.dir
-rwxr-xr-x 1 www-data www-data     81 Aug 17  2006 fwd
-rwxr-xr-x 1 www-data www-data  10848 May 29  2005 j
-rwxr-xr-x 1 www-data www-data  13850 May 29  2005 j2
-rwxr-xr-x 1 www-data www-data  22983 Jul 30  2004 mech.help
-rwxr-xr-x 1 www-data www-data    446 Dec  1 17:22 mech.set
-rwxr-xr-x 1 www-data www-data     18 Dec  3 18:49 run
-rwxr-xr-x 1 www-data www-data  15078 Feb 20  2005 s
-rwxr-xr-x 1 www-data www-data  13089 Dec  1 17:01 shit
-rwxr-xr-x 1 www-data www-data  16776 Sep 19  2002 sl
-rwxr-xr-x 1 www-data www-data     39 Dec  1 20:51 start.sh
-rwxr-xr-x 1 www-data www-data  15195 Sep  2  2004 std
-rwxr-xr-x 1 www-data www-data   8790 Jan 24  2006 stream
-rwxr-xr-x 1 www-data www-data   7091 Jan 24  2006 tty
-rwxr--r-- 1 www-data www-data    157 Dec  3 18:52 update
-rwxr-xr-x 1 www-data www-data  13687 Nov 20  2002 v
-rwxr-xr-x 1 www-data www-data  14841 Jul 22  2005 v2
-rwxr-xr-x 1 www-data www-data    915 Mar  2  2005 x


 Was kann ich machen damit mein Server wieder clean wird ???


----------



## F4RR3LL (3. Dez. 2013)

Also suphp und owner www-data passt aber nicht zusammen.
Irgendwas muss bei dir mit www-data laufen. Roundcube o.ä. installiert und mit modphp laufen? 
Ist /tmp bei dir eine extra partition? Falls ja, mounte sie mit noexec. 
Die Seite(n) mit modphp offline nehmen und schaun welche Version des CMS oder wasauchimmer dort installiert ist rennt, ggf neu installieren in der aktuellen Version und Backup von Hand einspielen damit du nicht die Lücke gleich wieder einspeist.

Gruß Sven

Für Openvz gehts mit noexec so: http://www.stronghub.com/securing-tmp-and-vartmp-on-openvz-container/


----------



## Sigix (3. Dez. 2013)

Hi, danke für deine Antwort,...

 ich habe diesen Server nach dem howtoForge - Perfect Debian Server installiert (vor ca. 2 oder 3 Jahren) ..... das einzige was hier läuft ist das Webmail und phpmyadmin

 sonst nichts.....

 Nein mein Filesystem sieht folgendermassen aus:

 Filesystem            Size  Used Avail Use% Mounted on
/dev/vzfs              50G   17G   34G  34% /
tmpfs                 512M     0  512M   0% /lib/init/rw
tmpfs                 512M     0  512M   0% /dev/shm

 also kein eigener Mount-punkt!

 ich habe jetzt alle Seiten durchgesehen bei allen ist SuPHP ausgewählt!
 ?????????


----------



## F4RR3LL (3. Dez. 2013)

Wie werden roundcube und phpmyadmin aufgerufen, wann wurden sie das letzte mal aktualisiert?

mount -t tmpfs -o noexec,nosuid,size=2G tmpfs /tmp/
mount -t tmpfs -o noexec,nosuid,size=2G tmpfs /var/tmp/

^^so bekommste tmp erstmal auf noexec


----------



## Sigix (3. Dez. 2013)

Zitat von F4RR3LL:


> Wie werden roundcube und phpmyadmin aufgerufen, wann wurden sie das letzte mal aktualisiert?
> 
> mount -t tmpfs -o noexec,nosuid tmpfs /tmp/
> mount -t tmpfs -o noexec,nosuid tmpfs /var/tmp/
> ...


okay 

/dev/vzfs              50G   17G   34G  34% /
tmpfs                 512M     0  512M   0% /lib/init/rw
tmpfs                 512M     0  512M   0% /dev/shm
tmpfs                 512M   44K  512M   1% /tmp
tmpfs                 512M     0  512M   0% /var/tmp

 sind gemountet

 ich habe squirrelmail (Version 1.4.21)
 phpmyadmin ist noch uralt.... 3.3.7deb7

 phpmyadmin kann ich aktualisieren!
 squirrelmail auf Version 1.4.22 ???


----------



## Till (3. Dez. 2013)

> ich habe squirrelmail (Version 1.4.21)
> phpmyadmin ist noch uralt.... 3.3.7deb7
> 
> phpmyadmin kann ich aktualisieren!
> squirrelmail auf Version 1.4.22 ???


das uralt in der Versionsnummer hat nichts zu sagen, Debian patch Sicherheitslücken ohne die Versionsnummer der Software zu erhöhen, erkennbar am Zusatz deb7, ist also der 7. patch. Debian 6 ist noch unterstützt, also ist Dein System sicher solange Du alle aktuellen Debian Updates mit:

apt-get update
apt-get upgrade

installiert hast.


----------



## Till (3. Dez. 2013)

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.


----------



## Till (3. Dez. 2013)

Und poste mal die ausgabe von:

/usr/lib/cgi-bin/php5 -v

bevor Du debian oder ispconfig updatest.


----------



## F4RR3LL (3. Dez. 2013)

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


----------



## Sigix (3. Dez. 2013)

Zitat von Till:


> Und poste mal die ausgabe von:
> 
> /usr/lib/cgi-bin/php5 -v
> 
> bevor Du debian oder ispconfig updatest.


 root@mail2:~# /usr/lib/cgi-bin/php5 -v
PHP 5.3.9-1~dotdeb.3 with Suhosin-Patch (cgi-fcgi) (built: Jan 12 2012 23:01:28)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
    with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH
root@mail2:~#


----------



## Sigix (3. Dez. 2013)

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


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


----------



## Till (3. Dez. 2013)

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.


----------



## Sigix (3. Dez. 2013)

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.


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


----------



## F4RR3LL (3. Dez. 2013)

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


----------



## Till (3. Dez. 2013)

Was sagt lsof zu der PID 9569 des perl Prozesses, was hat der so geöffnet.


----------



## F4RR3LL (3. Dez. 2013)

Zitat von Sigix:


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


Welches update? Ispconfig / Debian oder einfach pauschal?


----------



## Till (3. Dez. 2013)

Zitat von Sigix:


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


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.


----------



## Sigix (3. Dez. 2013)

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


 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 !


----------



## Sigix (3. Dez. 2013)

Zitat von Till:


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


okay danke!


----------



## Sigix (3. Dez. 2013)

Zitat von Till:


> Was sagt lsof zu der PID 9569 des perl Prozesses, was hat der so geöffnet.


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


----------



## Sigix (3. Dez. 2013)

Zitat von F4RR3LL:


> Welches update? Ispconfig / Debian oder einfach pauschal?


lediglich zu ispconfig ...aber till hat diese Frage schon beantwortet !


----------



## Till (3. Dez. 2013)

Zitat von Sigix:


> /home/backup/php5


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


----------



## Sigix (3. Dez. 2013)

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


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


----------



## Till (3. Dez. 2013)

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


----------



## Sigix (3. Dez. 2013)

Zitat von Till:


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


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!

????


----------



## F4RR3LL (3. Dez. 2013)

https://www.weminecryptos.com/forum/topic/665-a-black-sheep-called-regexkshf1/
PHP PHP CGI configurations code execution (HTTP_PHP_CGI_Exec)


----------



## TobiTo (6. Dez. 2013)

*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


----------



## Till (6. Dez. 2013)

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


Besser wäre php-fcg und suexec zusammen zu aktivieren. denn suphp verwendet ja auch das php cgi binary, wodurch es sein kann dass man dann deine Webseiten angreift. php-fcgi ist von dem Problem nicht betroffen und man sollte es auch nehmen da es schneller ist.


----------



## TobiTo (6. Dez. 2013)

Zitat von Till:


> Besser wäre php-fcg und suexec zusammen zu aktivieren. denn suphp verwendet ja auch das php cgi binary, wodurch es sein kann dass man dann deine Webseiten angreift. php-fcgi ist von dem Problem nicht betroffen und man sollte es auch nehmen da es schneller ist.



PHP-FCGI wird mir zumindest nicht angeboten:

Disabled
 Fast-CGI
 CGI
 Mod-PHP
 SuPHP


----------



## Till (6. Dez. 2013)

PHP-FCGI = Fast-CGI


----------



## TobiTo (6. Dez. 2013)

Zitat von Till:


> PHP-FCGI = Fast-CGI


oh dann habe ich hier was missverstanden dachte FAST-CGI war das Problem

check. SUPHP und FAST-CGI aktiviert

Danke!


----------



## Sigix (6. Dez. 2013)

Hi,
Bei mir hat schlussendlich das killen der Dienste (perl, k, st, k , ..... ) sowie das Verschieben des php5 Ordners, dass umstellen auf fcgi + suexec sowie das offline-nehmen der betroffenen (gehackten) Seite geholfen!

Danke nochmals an Till für seine überaus tolle Hilfe!

Lg Sigi


----------



## TobiTo (10. Dez. 2013)

hm die betroffene seite konnte ich bisher nicht ermitteln.

Obwohl ich alle dateien im tmp gelöscht habe lieht da schon wieder zeugs rum.  

Alles von www-data.

was kann ich noch machen um das loch zuzubekommen?

Es laufen mehrere Perl Prozesse wenn ich die kille kommen neue.
cat /proc/20131/cmdline
lifert mir WATCHDOG zurück.

Kann mir noch jemand tipps geben?

Vielen Dank und Gruß

TobiTo


----------



## Till (10. Dez. 2013)

Das kommt auch nicht aus einer webseite sondern durch den debian default vhost. Du hast die php cgi Binaries entfernt wie in Post #22 beschrieben?


----------



## TobiTo (10. Dez. 2013)

Zitat von Till:


> Das kommt auch nicht aus einer webseite sondern durch den debian default vhost. Du hast die php cgi Binaries entfernt wie in Post #22 beschrieben?


noch nicht aber jetzt ja.


----------



## TobiTo (10. Dez. 2013)

ich habe jetzt mal mit lsof auf den perl prozess geschaut da steht irgenwas von einer TCP connection auf eine ip die laut tracert in den asiatischen raum geht, das macht mir jetzt etwas angst.


----------



## Till (10. Dez. 2013)

Zitat von TobiTo:


> noch nicht aber jetzt ja.


Ok, dann ist es kein Wunder dass die Prozesse wieder aufgetreten sind. gehe bittenochmal den ganzen thraed durch und überprüf ob Du alles so gemacht hast, /tmp gesichert und die php binaries entfernt. Dann kille alle php prozesse.

Längerfristiig musst Du dann aber auf jeden Fall Dein Linux updaten. Denn sonst ist es nur eine Frage der Zeit bis Du wieder ähnliche Probleme bekommst. Das Betriebssystem immer auf aktuellem stand zu halten ist eine der wichtigsten Aufgaben wenn Du einen Server sicher betreiben möchtest.


----------



## TobiTo (10. Dez. 2013)

dann gehe das mal nochmal durch:

Post 7 cron tab checken:
* * * * * /tmp/update >/dev/null 2>&1
Zeile entfernt.
Anmerkung: da war letzte mal nichts

Post 14 tmp noexece mounten:
mount -t tmpfs -o noexec,nosuid,size=2G tmpfs /tmp/
mount -t tmpfs -o noexec,nosuid,size=2G tmpfs /var/tmp/

Filesystem            Size  Used Avail Use% Mounted on
/dev/hda3              78G   14G   61G  18% /
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
tmpfs                 2.0G     0  2.0G   0% /tmp
tmpfs                 2.0G     0  2.0G   0% /tmp
tmpfs                 2.0G     0  2.0G   0% /var/tmp

nu ist doppelt auch doof oder?

Post 16 updates:
F...! da standen die paket fürs update auf das nächste release drin... nicht gesehen. 

Mal sehen was jetzt passiert.... man sollte den krams nicht nebenbei machen... ich mich meld wieder falls mein system nochmal wieder leben sollte... F....! F...!

Danke und Gruss


----------



## TobiTo (10. Dez. 2013)

so weiter gehts

Post 16 check (System war übrigens so aktuell wie lenny sein kann)

Post 18 Und poste mal die ausgabe von: /usr/lib/cgi-bin/php5 -v
bash: /usr/lib/cgi-bin/php5: No such file or directory

Post 19 Und nicht vergessen das ganze rebootfest zu machen mit einem Eintrag in der /etc/fstab. 
check

Post 22: done

so jetzt muss ich vermutlich abwarten oder?

ich hatte mich ja damals mal hingesetzt und wollte auf squeeze aber irgendwie drüber weggekommen.

Darf ich um einen rat bitten:

Stand ISPConfig

This Version: 3.0.4.6
New Version : 3.0.5.3

Stand Debian: 5.0.10

In welcher Reihenfolge sollte ich updaten?

Danke und Gruß

TobiTo


----------



## nowayback (10. Dez. 2013)

Ich glaube weniger fehleranfällig wäre es bei dir, alles was ispconfig angeht (user/webs/emails/etc.) sichern und aktuelles debian und ispconfig 3.0.4.6 installieren dann alles einspielen und ispconfig updaten. aber ne 2. meinung schadet hier sicher nicht


----------



## Till (11. Dez. 2013)

An sich gehen Debian updates recht gut, aber man weiß nie. Ich würde Dir raten alles so zu sichern dass Du eine Neuinstallation wie von Nowayback vorgeschlagen machen könntest, also alle Daten und Konfiguration sicher aufbewahrt auf einem anderen speichermedium und dann einfach das Update versuchen. wenn es funktioniert, gut, wenn es fehlschlägt dann machst Du eine neuinstallation und spielst die Daten wieder ein.

Zum Debian Update:

Da Du noch Debian 5 einsetzt, würde ich erst auf debian 6 aktualisieren und dann erst auf debian 7. Zuesrt debian updaten, dann ispconfig. der ispconfig installer korrigiert bzw. aktualisiert dann auch einige Config Dateien, die nicht mehr zur neuen debian Version passen.


----------

