Brute Force Hacking op SSH vanaf mijn server

[Tead]

In een datacenter heb ik een webserver hangen. Op deze server zijn er een aantal mensen die een website draaien. Deze mensen kunnen via FTP inloggen en hebben geen toegang tot de Shell. Nu kreeg ik een waarschuwing dat er vanaf mijn server Brute Force hacking wordt gedaan naar een andere server in polen. De log die ik kreeg op gestuurd was dit:

code:

auth 01:53:21 sshd sshd[21608]: Invalid user negweb from 12.34.56.67
auth 01:53:21 sshd sshd[21608]: Failed password for invalid user negweb from 12.34.56.67 port 50121 ssh2
auth 01:53:21 sshd sshd[21610]: Invalid user neg1 from 12.34.56.67
auth 01:53:21 sshd sshd[21610]: Failed password for invalid user neg1 from 12.34.56.67 port 50165 ssh2
auth 01:53:20 sshd sshd[21604]: Invalid user ccit from 12.34.56.67
auth 01:53:20 sshd sshd[21604]: Failed password for invalid user ccit from 12.34.56.67 port 50063 ssh2
auth 01:53:20 sshd sshd[21606]: Invalid user ragateway from 12.34.56.67
auth 01:53:20 sshd sshd[21606]: Failed password for invalid user ragateway from 12.34.56.67 port 50098 ssh2

IP 12.34.56.78 is mijn IP adres. Dit is nog een klein gedeelte en is steeds met een andere user en andere poort.

Nu heb ik al een scan gedaan met rootkit hunter en mijn apache GET en POST logs nagekeken echter zonder resultaat.

Mijn server draait Debian 4.0 met Direct Admin als administratie pakket. Alle software is up to date.

Weten jullie nog manieren om te achterhalen waar het mis gaat?

[ralpje]

Kan je server niet als proxy misbruikt worden?

[Eijkb]

Je zou eens kunnen kijken ofdat er vreemde processen draaien onder gebruiker apache. Wellicht zijn er scriptjes uit je /tmp log of uit een world writable dir onder een vhost gestart. Die lopen dan over het algemeen als gebruiker apache.

[TrailBlazer]

Ik zal als eerste in je firewall op die bak SSH sessies naar buiten denyen. Verder weet je wat ze zeggen als je bak eenmaal gecompromiteerd is is opnieuw beginnen de enige oplossing.

[DiedX]

TrailBlazer schreef op maandag 13 oktober 2008 @ 16:22:
Ik zal als eerste in je firewall op die bak SSH sessies naar buiten denyen. Verder weet je wat ze zeggen als je bak eenmaal gecompromiteerd is is opnieuw beginnen de enige oplossing.

+1. Check met ls -la /tmp, /var/tmp en /dev/shm. Let daarop op directories met .'tjes erin.

[TrailBlazer]

tja vervolgens is ls al vervangen voor een versie die nou net die specifieke directories niet meer laat zien.

[Tead]

onder (h)top kom ik het volgende tegen:

Er draaien 10 processen onde de gebruiker apache, alle 10 zijn de volgende:
/usr/sbit/httpd -k start -DSSL

Daarnaast wordt dit zelfde process ook onder root gedraaid. (plaatje toegevoegd)

[Boudewijn]

Dat is vrij logisch, apache spawnet een stel threads om de requests af te handelen.
Niets raars.

Het root-proces spawnet die prut.

[DiedX]

Boudewijn schreef op maandag 13 oktober 2008 @ 16:52:
Het root-proces spawnet die prut.

Mag hopen van niet, want dan ben je dus "geroot"

Ik denk dat het proces wel draait als de gebruiker apache, maar niet als een apache webserver

[Tead]

ondertussen heb ik alle succes volle ssh logins bekeken en kwam vlak voor dat de brute force aanval begon tegen dat een gebruiker is ingelogd. Wat blijkt, het password was het zelfde als de username

Deze gebruiker is ingelogd geweest van vlak voor de brute force attack begon tot 7:00:01 vanmorgen. De .bash_history is uiteraard leeg. Nu gaat het om een normale gebruiker, dus niet om root oid. Kan een gebruiker via ssh zo veel kwaat doen datik mijn server opnieuw moet installeren?

[Boudewijn]

Ja dat zou ik wel doen.

Uhhh apache werkt gewoon met een proces dat een aantal andere processen spawnt, diedx. Daar is weinig raars aan hoor .

[Verwijderd]

Tead schreef op maandag 13 oktober 2008 @ 18:10:
Kan een gebruiker via ssh zo veel kwaat doen datik mijn server opnieuw moet installeren?

Normaal gesproken niet. Dat ligt er maar weer aan of je machine exploitable is. Dat kan door tal van zaken zijn. Met shell toegang heeft een kwaadwillend persoon wel gelijk een zwitsers zakmes om de boel te analyseren. Ik zou het wachtwoord van die ene gebruiker wijzigen, en even goed in de gaten houden of er rare dingen gebeuren.

Log bijvoorbeeld connecties naar remote servers via bekende poorten. Dit kun je met iptables vrik gemakkelijk doen.

[Boudewijn]

Ik raad de TS aan te reinstallen want hij kan met zijn kennis van zaken mijns inziens niet goed beoordelen of die doos geroot is.
iptables moet je dan ook maar net vertrouwen he cheatah .

[soulrider]

log ook even van waar die ene user komt.
wellicht zijn ze door een brute-force ssh-aanval eerst bij jou binnengeraakt,
en zijn ze nu gewoon opzoek naar het volgende slachtoffer.

(dit zorgt er ook voor dat je ten minste bewijs materiaal hebt mocht je zelf in de problemen komen, bij het hostingsbedrijf, dat bedrijf in Polen, of anderen)
je kan altijd eens kijken op http://isc.sans.org/diary.html ivm info hoe je bewijsmateriaal kan verzamelen.
(ze zijn daar even een special bezig daarover - bekijk ook de vorige dagen in hun posts)

dit doet me ergens denken aan nieuws - dat ik me meen te herinneren - dat er problemen zijn met sommige ssh-programma's. effe zoeken op de sans pagina.
er is in ieder geval een algemene brute-force aanval op ssh bezig:
http://isc.sans.org/diary.html?storyid=5114, http://isc.sans.org/diary.html?storyid=5047 en eentje die verwijst naar een rootkit die er verantwoordleijk voor kan zijn en hoe je die ev. kan vinden:
http://isc.sans.org/diary.html?storyid=4937
(andere info google je ev. maar zelf )

en een tip van mezelf: beperk het aantal connectie's die gemaakt kunnen worden via ssh naar andere servers.
bv. max. 5 per minuut ofzo - wat is de kans dat er iemand ssh naar buiten toe moet doen op je server ?

[ Voor 42% gewijzigd door soulrider op 14-10-2008 01:42 ]

[Boudewijn]

Tipje voor de volgende keer : denyhosts .

[Verwijderd]

Iptables kan je wat nuttige informatie geven.
iptables -I OUTPUT -m tcp -p tcp --dport 22 -j LOG --log-uid
Als het goed is, logt dat de userid van het proces wat een uitgaande verbinding naar ssh initieert. Dat is nuttige debug info, als het blijkt dat user "httpd" dat doet, hoef je niet bang te zijn voor een rootkit.

Verder nog iets nuttigs, geen oplossing, maar even symptoombestrijding: zet je firewall op uitgaande verbindingen eens aan.
iptables -I OUTPUT -m tcp -p tcp --dport 22 -j REJECT

Dat geeft je tijd om eens rustig te zoeken waar het vandaan komt, zonder nog meer servers tot last te zijn.

edit:
ik moet eens leren om de opvolgposts ook te lezen. however, toch nuttige informatie voor de knowledge base :-)

[ Voor 9% gewijzigd door Verwijderd op 14-10-2008 09:58 ]