Onderwerp: DDos vanaf server in ons netwerk

Door een klant zijn we gevraagd een aantal weken een server te monitoren omdat hij voor zijn werk naar het buitenland moet.

Nu is hij nog niet weg, of we krijgen een DDos op zijn server. Nader onderzoek en een abuse melding verder, blijkt dat de server niet het slachtoffer is, maar echter de aanvaller.

We hebben root access op die server, een FreeBSD 5.3 systeem.

Wat ik tot nu toe ontdekt heb is dat er steeds een perl script wordt uitgevoerd. Als ik het proces kill, stopt de aanval.

Tijdens het aanpassen van de apache config, kwam ik er achter dat apache gewoon weer automatisch start al ik het stop. Kan geen cron job vinden die dat doet, en er loggen ook geen users in!

Nu heb ik in httpd.conf reeds mod_perl en de perl cgi-handler uit gezet. Maar toch wordt het script weer opnieuw gestart.

Het script dat wordt uitgevoerd is /tmp/udp.perl óf /tmp/r0nin
ben ik nu achter gekomen.

Is deze server nu gehacked? Is er toch een gebruiker die dit moet doen?

Wat kan ik doen om dit op te lossen? Komt dit iemand bekend voor?

Waarschijnlijk draait er een php forum op (moet je even zoeken). Oplossing is ook vrij simpel dacht: de /tmp naar noexec zetten.

Zoek even bij google op udp.pl

Of gewoon even perl in een andere map zetten danwel renamen.

rename evt. tijdelijk het apache proces naar _httpd (zodat deze zichzelf niet automatisch kan herstarten). Draait er een controlpanel op de server ?

Even rkhunter vanuit de ports installeren en laten lopen, zodat je weet dat er geen rootkit meer opzit. Tevens /tmp noexec mounten zoals hierboven al gesuggereerd wordt.

Daarna je apachelog doorzoeken op /tmp/udp.pl, want je hebt ergens een lek script die de upload naar /tmp mogelijk maakt en laat starten.

r0nin is een linux rootkit met backdoor. Geen ssh nodig om in te loggen dus. Gewoon even rootkit verwijderen en je ziet alles weer zoals het hoort

heb je phpbb draaien op die server?

in oude versies van phpbb zitten exploits
die vaak gebruikt worden voor Ddosjes etc.

deze scripts staan altijd in /tmp

Origineel geplaatst door euro-access
deze scripts staan altijd in /tmp

Jup, apache voert dan ook iets uit als 'sh cd /tmp | wget file.pl | perl /tmp/file.pl' enzo. En daar veranderd niks aan, dus is het op zich vrij simpel om ofwel perl te renamen ofwel wget/fetch niet toe te staan in php etc etc

noexec mounten, apache logfiles scannen en misschien wel het belangrijkste: een firewall installeren die overbodige uitgaande poorten blokkeert

Misschien ook handig mod_security te installeren, dan voorkom je een hoop van die zooi.

Functies zoals wget, fetch en lynx een chmod 700 geven.

Zoals anderen al aangaven is dit een klassieke hack. Meestal komt men binnen via een phpBB, en installeert men enkele tools. Afhankelijk van de settings van apache, wordt het script uitgevoerd als de gebruiker "apache" of als de gebruiker van wie het script eigendom is.

Oplossing: /tmp idd noexec plaatsen, in logfiles gaan zoeken welke klant het forum met het gat heeft, kijken vanaf welk IP het misbruikt werd (abuse sturen), gegevens verzamelen.
Indien je geen cgi-wrapper of dergelijke scripts gebruikt, zeker overwegen (zo weet je meteen welke user het is)!

Zeker ook zoeken naar andere bestanden en sporen van andere scripts. Er zijn veel populaire plaatsen (/tmp/.<spatie> bvb). Du, find, ... allemaal je vriend. Zoek op bestanden die eigendom zijn van dezelfde gebruiker als het r0nin of udp script. Als je een rootkit vindt die de server volledig vrijgegeven heeft, dan zal er een re-install moeten gebeuren (en het gat dichten waardoor de hacker van een gewone user root geworden is).

Tevens kom ik tegenwoordig veel exploits tegen in /dev(/shm)

Origineel geplaatst door luser
Functies zoals wget, fetch en lynx een chmod 700 geven.

scriptjes schrijven die een gil geven wanneer dit aangeroepen wordt... en de orginale renamen naar iets anders.

chmod 750 /usr/bin/rcp
chmod 750 /usr/bin/wget
chmod 750 /usr/bin/lynx
chmod 750 /usr/bin/links
chmod 750 /usr/bin/scp

Het gebruik maken van noex op /tmp is niet waterdicht. Misschien kan je eens kijken naar mod_security?

Het is inderdaad niet waterdicht, maar het houd wel de meeste scriptkiddies buiten de deur