Httpd (apache) crashed

http://isc.sans.org/diary.html?storyid=900

"GET /w00tw00t.at.ISC.SANS.DFind:)"

It seems that we forgot to tell our whitehat readers that the search is off. We know what's behind it. It's a web vulnerability scanner that has this fingerprint. Find and use it at your own risk. We at the Internet Storm Center distance ourselves from this tool that is labeled by at least one security company as a hacker tool..

//edit

Citaat:

---

Oorspronkelijk geplaatst door BaseBoyNL

[root@webserver2 ~]# /sbin/service httpd restart
Stopping httpd: [FAILED]
Starting httpd: (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

---

Het lijkt me logisch dat apache zich niet aan ::1 / IP kon binden, het is namelijk nog in gebruik door je oude apache process welke niet succesvol gestopt is. Zie ook: "[FAILED]" in de quote hierboven.

Waarschijnlijk eerder dat het root apache process al niet meer draaide (childs wss nog wel) en het ding wat gestart word bind aan poort 80, en daardoor apache niet meer start.

Als dat zo is, moet je eens een netstat -plant |grep LIST doen, en kijk eens wat er op poort 80 draait.. zie je heel poort 80 niet meer, dan heb je zelfs een kans dat je bak geroot is en dat ze dingen zoals ps en netstat hebben vervangen om hun zaakjes te verbergen.

Daar word je niet vrolijk van :P

wat zijn de oplossingen om dit tegen te gaan ?
Ik heb gegoogled maar er word enkel verteld wat het is en niet wat je er tegen kan doen... iemand enig idee ?

Citaat:

---

Oorspronkelijk geplaatst door BaseBoyNL

Daar word je niet vrolijk van :P

wat zijn de oplossingen om dit tegen te gaan ?
Ik heb gegoogled maar er word enkel verteld wat het is en niet wat je er tegen kan doen... iemand enig idee ?

---

1) oorzaak zoeken. en account afsluiten
2) kijken wat er door aangetast is. Als je niet 100% zeker kan zeggen dat ie geroot is (en zelfs dan) moet je hem opnieuw installeren
3) beveiliging van je server aanscherpen*

* Gezien je kennis op dit gebied zou ik zeggen zoek een managed ded of vps en laat het doen ;-) of huur Randy in ;)

tjah moet het toch een keertje leren toch ;)

Wat is de beste beveiliging ?
CSF/LFD ?? dit las in in een ander topic.

Citaat:

---

Oorspronkelijk geplaatst door BaseBoyNL

tjah moet het toch een keertje leren toch ;)

Wat is de beste beveiliging ?
CSF/LFD ?? dit las in in een ander topic.

---

nope, is maar een onderdeeltje van de grote berg, en het houdt je processen op :80 niet tegen.

Hoe weten jullie nou of hij op zeker geroot is ?

Zijn apache server wordt gewoon lastig gevallen door een RFI scan tool, wat uiteraard vulnerabilities exploit en misbruikt. Hij kan geroot zijn als die auto-scanner/rooter een vuln geexploiteerd heeft, is de server secure (denk aan chrooted environment) en hoe veilig zijn de draaiende php scripts (*kuch* joomla *kuch*) ??

We need more info!!
- Welke php scripts draaien er?
- Zijn ze up2date ?
- Server draait chrooted / firewall (nee) ?
- Check of er een onbekende gebruiker zich op je doos bevind ( zie /etc/passwd ) en check ook of de gebruiker `www' /sbin/nologin als "shell" heeft.

Laat apache eens stoppen (check dmv ps -aux && kill -9 pid ) en herstart het.
Kan het zich dan nog niet binden aan poort 80 en 443, check dan netstat -a (zoek op http / https / 80 / 443 )


Maareh, again, we need info :)

ik weet het niet ik lees het alleen en zoek naar een oplossing

Probeer eens rkhunter te installeren om te zien of dit iets oplevert.
yum install rkhunter
rkhunter --update
rkhunter -c

Setting up Install Process
Parsing package install arguments
No package rkhunter available.
Nothing to do

Heb je een pm gestuurd

Precies een rootkit die wij ook hebben aangetroffen op een server van een klant (zonder beheer). Doe 's een lsattr /bin/ | grep ia

Als je daar dingen als ps, netstat, enzovoort bij hebt staan dan is dat 'm. Vanacht sloeg 'ie bij ons toe en hij bind ook op de apache poorten maar 't proces zie je niet omdat je netstat, ps, enzovoort binary's zijn gereplaced.

Ik kan 'm voor je schoon maken als je wilt. De oorzaak heb ik alleen bij die klant nog niet kunnen achterhalen. Dus de manier waarmee ze binnen kwamen. 't Rooten zelf is een kernel exploit 'vmslice'.

http://sourceforge.net/project/showf...kage_id=172567

tar zxvf rkhunter-1.3.4.tar.gz
cd rkhunter-1.3.4
./installer.sh --layout /usr/local --install

als je mod_ruid hebt draaien kun je zien onder welke user het gestart word. maaaaaaaar als ze zoals bij jesperw dmv de vmslice exploit root access hebben gekregen word het al veel lastiger omdat ze dan al waarschijnlijk hun stappen hebben gewist. Ook het vervangen van netstat en ps heeft geen zin.

Ook ik heb dit gezien bij een dedicated klant van ons die zelf het "beheer" deed. Uit einderlijk bleek dat er een "sshd " (notice de spatie) in /usr/bin was gezet. en een stel opstart scriptjes in init.d die al mn mooie opruim werk weer teniet deden door ergens een verborgen zipje uit te pakken en rustig aan weer alles vervangen. dus een reboot is geen garantie dat alle gekke processen weg zijn!!! dat je ze in ps niet ziet wil niet betekenen dat ze er niet zijn!!

vaak blijft een herinstall over.

Citaat:

---

Oorspronkelijk geplaatst door Jesperw

Precies een rootkit die wij ook hebben aangetroffen op een server van een klant (zonder beheer). Doe 's een lsattr /bin/ | grep ia

Als je daar dingen als ps, netstat, enzovoort bij hebt staan dan is dat 'm. Vanacht sloeg 'ie bij ons toe en hij bind ook op de apache poorten maar 't proces zie je niet omdat je netstat, ps, enzovoort binary's zijn gereplaced.

Ik kan 'm voor je schoon maken als je wilt. De oorzaak heb ik alleen bij die klant nog niet kunnen achterhalen. Dus de manier waarmee ze binnen kwamen. 't Rooten zelf is een kernel exploit 'vmslice'.

---

Dat is de alom bekende "suckit" kit, die wordt al sinds '98 gebruikt :thumbdown:
Als het goed is heb je dan ook nog een ssh-backdoor op een vage poort als 4343 zitten.

Draait je klant php scripts wat betrekking hebben tot RFI ? ( http://www.ossec.net/wiki/index.php/...bility_scanner <-- iets wat daartussen past)
Of andere outdated services ?

iig suc6.