Onderwerp: Gehacked, weer terug on-line, maar nu?

Geachte lezers,

ik heb 1 CentOS met Directadmin server draaien en volgens mijn provider was er een aanval bezig vanuit mijn server. De volgende regels uit hun log zouden dat aantonen:
2009-01-12 13:24:11.035 0.000 TCP x.x.x.x:58922 -> 22 .A....
2009-01-12 13:25:44.110 0.000 TCP x.x.x.x:56159 -> 22 .A....

Het betreft hier SSH brute forse hacking vanaf uw internet aansluiting (businessdsl verbinding).

Nou heb ik nieuwe admin en root wachtwoorden erop gezet. SSHD process gestopt, ik kan nl. ook fysiek bij de console. ik heb allerlei updates bekeken, maar leek in orde te zijn.
Daarna is mijn verbinding hersteld door xs4all, maar ja nu komt voor mij de hamvraag:
hoe kan ik controleren of de servers veilig zijn? ik heb op een pc in hetzelfde iprange wireshark ingesteld, maar eigenlijk zou dat dan op de server zelf moeten volgens mij. Maar xs4all geeft ook nog de volgende hints aan:
Check de websites op tekenen van code-injection/insertie-aanvallen of op andere manieren waarop malware de ssh-brute-force-attack heeft kunnen uitvoeren.
waar moet ik die zoektocht beginnen en hoe?
Iemand een idee?

met vriendelijke groet,
Ron.

Voor de zekerheid kan je zowiezo je systeem even herinstalleren, dan weet je zeker dat deze clean is. Verder zou ik inderdaad gaan zoeken hoe ze binnen gekomen zijn, of welke mogelijkheden daar voor zijn geweest. En zorgen dat je beveiliging wat betreft scripts etc goed voor elkaar hebt, php in cgi mode etc.

Mocht er daadwerkelijk in de server zijn ingebroken, dan zou ik toch wel degelijk het systeem herinstalleren. Daarnaast is het wellicht verstandig om SSH te gaan beveiligen

Tip: Logbestanden inzien.

Je moet ook goeie firewalls nemen, zoals bijv KISS. DDOS Deflate werkt ook erg goed.

DDos Deflate handelt bij mijn weten alleen ddos attacks af (ik kan het mis hebben), maar hij is wel goed te gebruiken in combinatie met BFD.
CSF/LFD is ook een fijne firewall om mee te werken.

Zorg dat je gebruikers geen SSH commando mogen gebruiken vanaf de server.
Als er een SSH aanval is geweest is er toch kans dat je machine geroot is geworden. In dat geval kun je eventueel in /root nog in de .bash_history kijken of je daar commando's in tegen komt die je nogal erg onbekend tegen komen, c.q. die je zelf in elk geval zeker niet gedaan hebt.

Ben jij de enige die toegang behoeft tot SSH? Zet dan sowieso root toegang dicht voor SSH en su naar root vanaf een gebruikersaccount.
Andere of extra mogelijkheid is om de ssh toegang in je firewall te beperken tot jouw ip adres als je een vast ip hebt.

Bedankt voor de tips, en als er nog meer zijn, laat ze komen. Ik heb van alles inmiddels weer verbeterd en aangepast ook mede dankzij de tips. Ik weet ook vrij zeker dat ik verder geen problemen meer tegenkom op dit moment.
Bedankt voor de tips dus.
Ron.

Ik heb bij al mijn klanten een hardwarematige firewall draaien die dit soort dingen zou moeten merken (en ook merkt) en blokkeert. Je zou hier natuurlijk onderzoek naar kunnen doen, maar het is wellicht verstandiger (met een linuxserver)

- SSH op een andere, onbekende poort te laten draaien (je mag tot 65535, dus kies bijvoorbeeld 65432)
- inloggen onder root verbieden
- het root password (om toch met su als root te kunnen opereren) niet zo kort maken als xxxx maar wellicht als wachtwoord "Ik Vind het Handig om In Te Loggen als Root v00r SuPerUserRechten @ip.add.re.ss") (dus niet te makkelijk maken, ook niet voor brute force)