PDA

Bekijk Volledige Versie : Opsporen van Ddos shells .php



chriske
03/12/10, 17:40
Hebben jullie ervaring met het opsporen van zo geheten ddos shells. Vaak worden er ook via deze shell scripts phising websites geupload.

Ik heb nu via clamdscan -r /home/ een scan gestart. Zou Clamd dit ook daadwerkelijk oppikken? Zijn er geen andere tools die juist hiervoor gemaakt zijn?

vDong
03/12/10, 18:02
Hebben jullie ervaring met het opsporen van zo geheten ddos shells. Vaak worden er ook via deze shell scripts phising websites geupload.

Ik heb nu via clamdscan -r /home/ een scan gestart. Zou Clamd dit ook daadwerkelijk oppikken? Zijn er geen andere tools die juist hiervoor gemaakt zijn?

De term ddos shell zegt mij even niks, van wat je beschrijft lijkt het eerder een php-shell ding te zijn.
Op zich zou je kunnen greppen op die specifieke functies, virusscanner lijkt me niet iets die het gaat vinden.

The-BosS
03/12/10, 18:13
Ik zou zeggen probeer het even met een root kit hunter (rkhunter) bvb. Maar of het iets zal uithalen lijkt me sterk, aangezien die php-shells gelijk welke naam kunnen hebben. Je beste optie is even je php.ini beveiligen en dingen als exec() system() etc uitzetten zodat deze php shells niet meer (of half werken). Naast dat kan je ook je /tmp als noexec mouten zodat hier ook niks op ge-execute kan worden.

chriske
03/12/10, 18:13
Het is zon php script zodat je bijvoorbeeld kan bladeren via je browser op de server. Zo kunnen ze zoeken welke directories er allemaal 777 hebben en dit misbruiken.

Triloxigen
03/12/10, 18:21
PHP Bestanden doorzoeken op 'eval' daar vind je het meestal wel op

chriske
03/12/10, 18:21
En eval staat voor? En iemand nog tips om dit in de apache logs te vinden? Hoe ze precies dit erop hebben gekregen?

Yourwebhoster
03/12/10, 18:23
En eval staat voor? En iemand nog tips om dit in de apache logs te vinden? Hoe ze precies dit erop hebben gekregen?

zucht
http://php.net/manual/en/function.eval.php

Daarvoor staat dat dus.

marsipulami
03/12/10, 18:24
EDIT: yourwebhoster was me voor ;)

ichosting
03/12/10, 18:26
Onderwerp is al eens vaker behandeld volgens mij. Controleer ook geregeld of je vage ftp connecties hebt in je logs. Vaak wordt het ook via gehackte ftp accounts geupload.

chriske
03/12/10, 18:30
zucht
http://php.net/manual/en/function.eval.php

Daarvoor staat dat dus.

excuus, ik heb geen ervaring met php script taal en wist dus ook zo niet wat dit betekende.


Ik heb alle wachtwooden al via mijn pc aangepast van deze klant. Het gezeik is begonnen nadat er een backup vanaf een andere host bij mij was gerestored.

In de ftp logs komen geen rare ips voor die iets uploaden. Alle wachtwoorden zijn aangepast via mijn pc. Er moet dus ergens in zijn joomla sites een script staan waarmee ze er weer bij kunnen.

Nu zijn de complete websites verwijderd en worden overnieuw gebouwd. Ik heb de backups waar een infectie in moet zitten nu gerestored onder een andere dir en ben deze aan het scannen om te zien waar het nu precies zit.

The-BosS
03/12/10, 18:31
Het is zon php script zodat je bijvoorbeeld kan bladeren via je browser op de server. Zo kunnen ze zoeken welke directories er allemaal 777 hebben en dit misbruiken.

En wie heeft er nu in godsnaam een chmod van 777 op algemene directory's staan, rechten zijn voor iets uitgevonden.

chriske
03/12/10, 18:33
Ja, dat snap ik. Bij mij staat er ook niks op 777. Ik geef enkel een voorbeeld wat ze met dit script kunnen doen.

The-BosS
03/12/10, 18:35
Als ze daar al op kunnen zoeken is er iets structureel verkeerd op je server, run je toevallig je php in cli (php-cli) mode met default apache|www-data user ofzo?

chriske
03/12/10, 18:40
Ik draai directamin met Suphp.

Kijk ik heb het script nog niet gevonden op mijn server, ik heb al wel meerdere malen deze scripts aangetroffen op andere servers. Ik weet zo ook niet of zon dergelijk script bij mij gewoon zou werken. Ik moet het eerst nog traceren hoe ze telkens phising sites op 1 bepaalde users krijgen.

In mijn php ini heb ik ook een aantal dingen disabled:

disable_functions = exec,passthru,proc_open,proc_close,shell_exec,syst em,shell

Apoc
03/12/10, 18:43
chriske; je hebt het over klanten, dus het gaat schijnbaar om een productie server. Zou je het beheer dan niet over laten aan iemand met gedegen ervaring op dit gebied?

chriske
03/12/10, 18:55
Ik denk niet dat de taak is van een systeembeheerder om een gat in een website te vinden. Er kan ook geen schade worden aangebracht aan de rest van het systeem omdat dit gewoon goed beveiligd is. Ik wil gewoon graag de fout vinden. Mijn kennis/klant installeert gewoon joomla en bouwt daar de website omheen. Deze heeft verder ook geen kennis van php scripting laat staan dat deze de fout kan vinden.

Ik heb niks te doen en wou gewoon even verder kijken dan wat ik normaal doe. Kan ik het echt niet vinden dan zal het aan de kennis/klant zijn iemand in te huren die naar zijn website kijkt.

marsipulami
03/12/10, 19:20
En wat als je klant begint te spammen?? of heb je ook iedere klant maar een eigen ip adres gegeven?

Je moet toch een zekere basiskennis hebben van scripting imo wanneer je webhosting aanbiedt. Just my 2 cents

chriske
03/12/10, 19:29
basiskennis ja, lijkt mij niet dat onder basis kennis valt het opsporen van gaten in een php script.

Daarnaast zit er voor mail een limiet op het aantal berichten wat per dag kan worden verstuurd, en mee dat er veel mail word gestuurd door een user krijg ik hier meteen mail/sms over.

Maar hier gaat het helemaal niet over en snap ook niet waarom je dit nu zegt.

Apoc
03/12/10, 21:06
basiskennis ja, lijkt mij niet dat onder basis kennis valt het opsporen van gaten in een php script.

Eh.. natuurlijk wel. Kan een beveiligingslek in een script een probleem voor jouw systeem opleveren? Ja. Dus het valt onder de verantwoordelijkheden van de systeembeheerder.

Je stelt daarnaast ook vragen als:


En iemand nog tips om dit in de apache logs te vinden? Hoe ze precies dit erop hebben gekregen?

Als je die vraag niet zelf kunt beantwoorden, ben je mijns inziens niet gekwalificeerd om een systeem te beheren waar klanten op draaien. Ik snap dat je het graag uitzoekt, maar dat moet je niet in een productiesysteem gaan doen.


Maar hier gaat het helemaal niet over en snap ook niet waarom je dit nu zegt.

Omdat het nogal amateuristisch is om als systeembeheerder van een productiesysteem dit soort vragen op WHT te moeten stellen. Als het om een hobbyprojectje zou gaan, is het een ander verhaal.

Begrijp me niet verkeerd; het is niet mijn intentie om je persoonlijk aan te vallen of iets dergelijks.

chriske
03/12/10, 23:17
Het is ook hobby, maar als je niet wilt helpen antwoord dan niet.

Mark17
04/12/10, 01:13
Mocht je willen dat ik kijk of ik wat kan vinden dan kun je mailen naar mark@sinnerg.nl. Vervolgens zal ik gratis kijken of ik iets bijzonders kan vinden. Vermeld in ieder geval even:
- IP
- Login gegevens (eventueel kun je mijn public key plaatsen: http://sinnerg.nl/mark.pub)
- OS (anders moet ik daar nog even naar kijken)

Let op: ik geef geen garanties.

The-BosS
04/12/10, 01:26
...

Ik heb alle wachtwooden al via mijn pc aangepast van deze klant. Het gezeik is begonnen nadat er een backup vanaf een andere host bij mij was gerestored.

...


Het is ook hobby, maar als je niet wilt helpen antwoord dan niet.

Dan spreek je jezelf toch redelijk tegen moet ik zeggen want hobby server en klant(en) gaan niet echt samen.

En als het om een joomla website gaat heb je de mysql databse al gecontroleerd, want het zou ook een sql injection geweest kunnen zijn.

dennis0162
04/12/10, 09:48
He Chris,

Ik wil ook wel even voor je kijken:)
Laat maar ff weten dennis@dwsmedia.nl