HTTP niet automatisch herstartbaar

[ErikKosters]

Beste,

Heb hier 1 server van een klant staan welke het volgende probleem heeft. Om de zoveel tijd loopt de http service vast en kan deze niet automatisch zonder handmatige handelingen worden gestart.

Als ik dan handmatig kijk dan zie ik de volgende processen:


apache 21021 0.0 0.0 1976 548 ? S 05:40 0:00 /usr/local/apache/bin/httpd -DSSL ? cmx
698 25674 0.0 0.0 2688 844 ? Ss 12:10 0:00 /bin/sh -c wget -q -O /dev/null http://www.site.nl/scripts/admin/cronjobs.php >/dev/null 2>&1 >/dev/null 2>&1
698 25677 0.0 0.0 4640 1388 ? S 12:10 0:00 wget -q -O /dev/null http://www.site.nl/scripts/admin/cronjobs.php
722 25797 0.0 0.0 3236 856 ? Ss 12:11 0:00 /bin/sh -c wget -q -O /dev/null http://admin:password@www.site.nl/module.php?module=rss_import_do_import >/dev/null 2>&1
722 25798 0.0 0.0 5480 1388 ? S 12:11 0:00 wget -q -O /dev/null http://admin:password@www.site.nl/module.php?module=rss_import_do_import
722 26423 0.0 0.0 3944 852 ? Ss 12:16 0:00 /bin/sh -c wget -q -O /dev/null http://admin:password@www.site.nl/module.php?module=rss_import_do_import >/dev/null 2>&1
722 26424 0.0 0.0 3896 1388 ? S 12:16 0:00 wget -q -O /dev/null http://admin:password@www.site.nl/module.php?module=rss_import_do_import
root 26513 0.0 0.0 4704 680 pts/0 R+ 12:16 0:00 grep http


Tevens draaien dan de volgende services:


psybnc 16964 apache 4u IPv6 13562370 TCP *:http (LISTEN)
psybnc 17068 apache 4u IPv6 13562370 TCP *:http (LISTEN)
eggdrop 17909 apache 4u IPv6 13562370 TCP *:http (LISTEN)


Wat ik dus denk is dat deze processen eggdrops gaan draaien of dergelijk. Wat is de beste remedi? Accounts disabelen?

[Japje]

Wat ik dus denk is dat deze processen eggdrops gaan draaien of dergelijk. Wat is de beste remedi? Accounts disabelen?

niet gaan draaien, die draaien al. Waarschijnlijk word er 1 of andere joomla/mambo of ander standaard pakket met een lek erin misbruikt. Dan worden die files gedownload en automatisch een eggdrop botje of zelfs shelletje gestart.

Ik zou idd deze accounts uitschakelen, of iig de user van wie ze zijn er van op de hoogte stellen.

Tevens kun je natuurlijk firewallen dat ze niet naar buiten kunnen (kunnen ze nog wel gestart worden) en verschillende php settings kun je aanpassen om het moeilijker te maken ze te starten.

[ErikKosters]

niet gaan draaien, die draaien al. Waarschijnlijk word er 1 of andere joomla/mambo of ander standaard pakket met een lek erin misbruikt. Dan worden die files gedownload en automatisch een eggdrop botje of zelfs shelletje gestart.

Ik zou idd deze accounts uitschakelen, of iig de user van wie ze zijn er van op de hoogte stellen.

Tevens kun je natuurlijk firewallen dat ze niet naar buiten kunnen (kunnen ze nog wel gestart worden) en verschillende php settings kun je aanpassen om het moeilijker te maken ze te starten.

Ik ga er vanuit dat het via dat cronjob script gebeurd. Kan je wget ook uitzetten voor cronjobs?

[Dirkje]

Kijk de cronjobs na in /var/spool/cron/crontabs/

Erik, ik probeer je te mailen maar ik krijg je mail terug...

[frankske]

als die processen effectief luisteren op poort 80, heb je een probleem! Zelfs als een joombla/whatever site van je klant gekraakt is, kan het nog niet zomaar op poort 80 gaan zitten! Het lijkt erop dat je hele kist geroot is...

[Japje]

als die processen effectief luisteren op poort 80, heb je een probleem! Zelfs als een joombla/whatever site van je klant gekraakt is, kan het nog niet zomaar op poort 80 gaan zitten! Het lijkt erop dat je hele kist geroot is...

nou nou nou wat een paniekzaaierij.. als een eggdropje of iets dergeiljks door apache word gestart en deze processen kunnen niet goed gekilled worden bij een herstart zal de apache child nog steeds poort 80 in gebruik hebben, en daarom wil apache niet meer starten.

Niet zomaar iets roepen..

[daveww]

Zover ik het kan zien wordt er een website gehost wat lekken heeft, en via die reden is er eggdrop/psybnc opgekomen en tevens met een "shell php" script alles uitgevoerd oid.

Ik zou eens kijken of er joomla/mambo sites op staan, vaak betreffen het deze CMS systemen als klanten ze niet updaten.

Eventueel kun je de logs kijken via welke manier ze erop zijn gekomen, vaak valt dit nog te achterhalen.

[ErikKosters]

Krijg dit in de log te zien:



70.87.51.242 - - [08/Oct/2008:02:20:33 +0200] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 466
213.247.35.191 - - [08/Oct/2008:05:45:33 +0200] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 466
127.0.0.1 - - [08/Oct/2008:07:30:02 +0200] "GET /r57shell/version.php?version=13 HTTP/1.0" 404 564
65.111.181.37 - - [08/Oct/2008:10:39:18 +0200] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 466
127.0.0.1 - - [08/Oct/2008:14:15:03 +0200] "GET /r57shell/version.php?version=007 HTTP/1.0" 404 564
127.0.0.1 - - [08/Oct/2008:14:30:03 +0200] "GET /r57shell/version.php?version=007 HTTP/1.0" 404 564

[Japje]

voornamelijk die r57 ... die w00t w00t scan is niet echt van toepassing.

die r57 is een php shell die mega veel gebruikt word om toegang te krijgen tot de rest van een systeem (dus dan zitten ze er al op dmv een lek oid)

wat je kan proberen als die dingen draaien is: lsof |grep <pid van botje of onbekend proces> ( zonder de <> natuurlijk)

dan kun je gelijk zien waar deze vanuit gestart is.

[Wido]

Wanneer je een programma via de system functies van PHP start en daarna Apache herstart zal dit programma (indien nog actief) alle listeners over nemen van Apache, dit wordt namelijk niet opgeruimd.

Dit is al sinds 2001 zo en sinds die tijd voeren de PHP en Apache dev'vers een "oorlog" wie dit nu moet oplossen.

Het komt er op neer, een child proces in PHP krijgt alle listeners (ook tot logfiles!) mee van Apache en kan hierdoor aan poort 80 binden wanneer Apache herstart wordt.

[ErikKosters]

Ok duidelijke uitleg Wido. Ik heb de betreffende klant op de hoogte gesteld en het probleem kwam inderdaad door een verouderd Joomla script zover ik nu heb kunnen vaststellen.

[Renalpha]

no message body