[Linux] Vulnerability scanner

[Verwijderd]

Mijn server is drie dagen geleden gehacked(ik weet het ik zuig ) - niet op een van de meest geweldige manieren maar goed, het waren newbies, heb zelfs al hun IP addy's in de apache logs staan(alleen nu nog weten wat er mee te doen).

Ik ben de laatste tijd 'heel' veel met security bezig vooral omdat ik geen zin had om gehacked te WORDEN.

maar goed, om een lang verhaal kort te houden:

Weet iemand een goeie vulnerability scanner die een Linux systeem om "alle(onmogelijk maar je snapt wat ik bedoel)" mogelijke vulnerability scanned en dat dan aan mij laat weten.

[MAZZA]

't Makkelijkst vind ik zelf om bugtraq bij te houden. Even op een rijtje zetten wat je zoal draait en aan de hand daarvan kijken of er vulns zijn voor die progjes.

Gewoon je software up-to-date houden werkt ook goed

/nieuwsgierig: Waarop is je bak gehacked

[ralfbosz]

Hij had het over apache, dus ik denk dat hij de SSL-bug in apache bedoelt...

[zwik]

chkrootkit

die controleerd gruwelijk veel.

[Hagar]

Daar moet je toch echt zelf voor zorgen.
Het enige wat je kan scannen zijn de poorten die je open hebt en je daarvan afvragen of het nut heeft dat die open staan. Dus houdt je server up to date, lees nieuwsberichten over services die jij draait en veel succes

[Verwijderd]

Hoe ik gehacked ben is nog een vraag(meer een mysterie) ik heb een groot vermoeden dat de personen in kwestie me eerst grondig(met z'n 3e) gescanned hebben

code:

[Thu Oct  3 19:33:36 2002] [error] [client 212.0.157.52] File does not 
exist: /webspace/default/scripts/..À¯../winnt/system32/cmd.exe

[Thu Oct  3 19:33:38 2002] [error] [client 212.0.157.52] File does not
 exist: /webspace/default/scripts/..Á~\../winnt/system32/cmd.exe

[Thu Oct  3 19:33:46 2002] [error] [client 212.0.157.52] File does not 
exist: /webspace/default/scripts/..%5c../winnt/system32/cmd.exe

En anders hadden ze er niet bijster veel verstand van(system32 op een Linux systeem, juist)
Dat soort zooi staat dus hier en daar in mijn apache.log net voordat de server offline ging.

Hoe het verder is gegaan weet ik niet, ze hebben / gewoon verneukt maar gezien mijn webspace op een andere schijf staat hebben ze die laten staan(vergeten dus).

een SSL functie had ik niet in apache zitten, en chkrootkit ken ik en draai ik ook af en toe.
Het is dus echt een bekende exploit geweest in een van de Suse7.3 rotzooi.

Updaten deed ik ook al en nieuwsberichten kom ik soms ook tegen, heb niet echt een idee waarvoor ik daar percies moet zijn. maillisten zijn ook humor maar die ken ik nog pas een.

Dus als iemand wat sites kent of maillisten laat het ook maar weten.

Voor jullie die geintereseerd zijn in de IP addy's:
- 212.0.157.52
- 172.177.218.178
- acb1dab2.ipt.aol.com

[ Voor 0% gewijzigd door Verwijderd op 06-10-2002 22:39 . Reden: layout :P ]

[Verwijderd]

Da's toch code red

[MAZZA]

Dat ziet eruit als een standaard Code Red scan.. Die is puur gericht op win32 machines..

[Verwijderd]

Verwijderd schreef op 06 oktober 2002 @ 22:38:
Da's toch code red

???

Oh ps, waar vindt ik bugtraq?!

[MAZZA]

Verwijderd schreef op 06 oktober 2002 @ 22:39:
[...]


???

Code Red is een worm (virus) die zichzelf verspreidt door IIS dozen automatisch op security holes te scannen. Het virus kijkt niet of de host eventueel apache of een andere webserver draait en daarom staan jou logs vol met die scans van Code Red.

Heb je die gehackte machine nog steeds draaien trouwens?

[MAZZA]

Bugtraq: http://online.securityfocus.com/archive/1

[Verwijderd]

Nee die gehackete machine is ondertussen opnieuw geinstaleert met debian3.3(woody) het hele / filesysteem was leeg daar viel dus niets uit te halen.

[scorpie]

nessus is wat jij zoekt.
www.nessus.org
have phun
en hebben ze wat verwijderd ofzo van je website? --> crackers...
hebben ze je zelf ingelicht? ja? --> hackers.. leer het eens

anyway, die log die jij post is idd code red, daar hebben meer mensen last van

[root@liquid /]# grep "cmd.exe" /www/logs/access_log | wc -l
461

[Verwijderd]

Nou over de webspace, het is inderdaad vreemd dat de inhoud van een pagina die wordt gehost op mijn server weg is - en de rest intact is.

Mogelijk waren ze het niet eens met de inhoud van http://www.eminemforlife.com/

Helaas hebben de hackers me niet ingelicht, ze hebben dus echt heel me filesystem verwijderd, iets waar ik dus niet echt veel waardeering voor heb - Ik zou deze personen ook eerder met de benaming scriptkiddie(s) assioceren dan hackers.

Ik had nessus al gevonden en ben er nu meer bezig , iig bedankt voor je tip

[MAZZA]

code:

9/tcp      open        discard
13/tcp     open        daytime
22/tcp     open        ssh
37/tcp     open        time
80/tcp     open        http
111/tcp    open        sunrpc
113/tcp    open        auth
3306/tcp   open        mysql

port 9, 13, 37, 111, 113 kunnen sowiezo dicht op die bak. MySQL kan je eventueel ook blocken voor access van buiten af. Let op dat je SSHD up-to-date is en je Apache ook.

SSH heeft nogal wat remote root exploits gehad de laatste tijd en Apache had er de afgelopen maand 1.

[Verwijderd]

Ik ben op het moment nog bezig met het securen van de bak, die poorten moeten idd dicht - ben net klaar met de debian install .

mySQL ga ik gewoon restricten tot 127.0.0.1(localhost dus) SSH versie is 3.4-p1(alleen SSH2 (NIET SSH1 ))

En apache/php/mysql en dat soort zooi is altijd wel up-to-date bij me. Ik doe regelmatig kijken voor updates, minstens 1x per week.

Nog meer security tips iemand?

[MAZZA]

Kernel versie

[Verwijderd]

2.2.20-idepci standaard uit debian3.3(woody) install

[scorpie]

Verwijderd schreef op 06 oktober 2002 @ 23:02:
Ik ben op het moment nog bezig met het securen van de bak, die poorten moeten idd dicht - ben net klaar met de debian install .

vergeet niet alleen remote vulnerabilities te dichten, maar ook local, het klinkt lullig, maar als je je van buitenaf niet goed kunt verdedigen, mag je ze niet de weg vrij geven als ze eenmaal binnen zijn. (remote vulns met rootshell tot gevolg worden over het algemeen snel gepatched door sysadmins..)

mySQL ga ik gewoon restricten tot 127.0.0.1(localhost dus) SSH versie is 3.4-p1(alleen SSH2 (NIET SSH1 ))

wat is er mis met ssh1?

En apache/php/mysql en dat soort zooi is altijd wel up-to-date bij me. Ik doe regelmatig kijken voor updates, minstens 1x per week.

apache maakt niet zo heel veel uit, php is meestal de boosdoener icm apache, let daar dus op.
laat je mysql dbases ook md5 encrypten, wel zo handig..
wanneer je je opgeeft voor de bugtraq mailinglist, hoef je alleen nog maar je mail te checken, goej he?

Nog meer security tips iemand?

nie genoeg?

[Hagar]

Scorperito schreef op 06 oktober 2002 @ 23:15:

[...]

wat is er mis met ssh1?

In feite is er niks mis met SSH1
Maar als je een server hebt die beide protocollen ondersteund is deze minder veilig. Het is verstandiger om maar 1 protocol te gebruiken.
Ik heb er laatst een artikel over gelezen (een linkje in een van de NOS topics) waarin dat werdt uitgelegd.

Het is trouwens debian 3.0

[scorpie]

Verwijderd schreef op 06 oktober 2002 @ 23:11:
2.2.20-idepci standaard uit debian3.3(woody) install

zou je niet upgraden naar 2.4.* met grsecurity kernelpatch eroverheen?

[MAZZA]

Beter ff updaten naar 2.2.22.. Laatste stable..

Ja of overstappen naar de 2.4.x tree..

[Verwijderd]

Ik had idd gehoord dat 2.4.* niet echt stabiel was, en ik heb nog niet geupdate gezien ik nog geen tijd heb gehad om te compilen etc.

Verder aan Scorpertio:
- SSH1 had gehoord dat die al redelijk insecure was.

[MAZZA]

2.4.19 is behoorlijk stabiel nu..

[Hagar]

http://www.phrack.org/show.php?p=59&a=11

Daar staat wat meer info over mijn vorige post

[deadinspace]

Mja, het is misschien cliché, maar:

* Zorg dat alleen services die je ook echt aan wilt bieden naar buiten toe open staan (anders service verwijderen of firewallen ofzo).
* Als je dingen firewallt, vergeet dan niet UDP (dns, dhcp) te firewallen.
* Houdt security updates bij, vooral van de services die naar buiten open staan (in het geval van Debian: deb http://security.debian.org/ stable/updates main )
* Configureer je services goed

Dan heb je nog wat opties die in sommige gevallen overdreven en in andere gevallen verstandig zijn:

* Subscribe op bugtraq
* Installeer externe services in een chroot jail
* Draai een IDS (Intrusion Detection System) en logcheck

En wbt kernels: 2.2.20 en 2.2.21 zijn afaik safe, en voor 2.4 zijn 16 - 19 afaik in orde.
Ik gebruik al een redelijke tijd overal (zowel servers als workstations) 2.4, omdat ik 2.4 goed genoeg acht (sinds 2.4.15 geen serieuze problemen meer gezien).

[Verwijderd]

'ik ben de laatste tijd veel met security bezig.... euh jongens waar kan ik bugtraq vinden?'

Hier klopt iets niet Haha

[Verwijderd]

ssh1 is vulnerable voor Man-in-the-middle attacks van oa dsniff en hunt

[Wilke]

Nessus is inderdaad behoorlijk zwaar briljant ja.

NMap is ook een handig tooltje.

Bugtraq lezen.

Doos dichtspijkeren, een IDS (bv. Snort) installeren.

Die scans zijn van Code Red trouwens, het zijn wel hele erge n00bs als ze proberen je Linux-bak te hacken met Code Red. Zal dus wel unrelated zijn?

[Verwijderd]

Hagar schreef op 06 oktober 2002 @ 23:16:
[...]


In feite is er niks mis met SSH1
Maar als je een server hebt die beide protocollen ondersteund is deze minder veilig. Het is verstandiger om maar 1 protocol te gebruiken.
Ik heb er laatst een artikel over gelezen (een linkje in een van de NOS topics) waarin dat werdt uitgelegd.

Het is trouwens debian 3.0

alleen ssh2 aanzetten 1.0 kan gehacked worden nl.

simpel edit /etc/ssh/sshd.config oid

[scorpie]

Wilke schreef op 07 oktober 2002 @ 12:55:
Die scans zijn van Code Red trouwens, het zijn wel hele erge n00bs als ze proberen je Linux-bak te hacken met Code Red. Zal dus wel unrelated zijn?

Like, Code Red verspreid zichzelf?

[Verwijderd]

Ja maar 't was gewoon vreemd dat het laatste dat in mijn logs stond die 'aanval' van dat Code Red virus was. Misschien toch maar gewoon op server crash gooien, het boeit me allemaal niet meer.

Verwijderd schreef op 07 oktober 2002 @ 12:19:
'ik ben de laatste tijd veel met security bezig.... euh jongens waar kan ik bugtraq vinden?'

Hier klopt iets niet Haha

Bugtraq kende ik nog niet nee, dunno why

Wilke schreef op 07 oktober 2002 @ 12:55:
Nessus is inderdaad behoorlijk zwaar briljant ja.
NMap is ook een handig tooltje.

Nessus is inderdaad heel cool precies wat ik zocht, en nmap doet niet meer als dat een 'netstat -an|grep LISTEN' zou doen maar mjah NMap is ook wel leuk.

Doos dichtspijkeren, een IDS (bv. Snort) installeren.

Ben ook al bekend met Snort stond ook op de vorige install, leuk dingetje.

[Verwijderd]

Ok, zijn al veel goede tips hier gegeven, maar ik ga mij er toch ook nog even tegenaan bemoeien.

Ik wil nog even benadrukken dat bugtraq absoluut verplichte kost is voor elke sysadmin. Samen met de security mailing list van je distro.

Nog even een opmerking die ik al eens eerder heb gemaakt, maar ik doe het nog maar een keer. Ik zie dat mensen blindelings vertrouwen op chkrootkit en er gelijk vanuit gaan als dit programma niks vindt dat ze dan niet gehacked zijn. Deze aanname is dus fout. Chkrootkit is zeker een handig programma, maar dit programma herkend lang niet elke rootkit die in het wild voorkomt. Verder controleert chkrootkit standaard met de binaries (ls, ifconfig, ps, enz) die op de machine zelf aanwezig zijn. Deze binaries kunnen dus vervangen zijn door een rootkit en de enige controle die chkrootkit standaard doet is het greppen naar bepaalde strings in die binaries. Je moet dus altijd met een betrouwbare set binaries vanaf cd ofzo chrootkit draaien. Verder zijn er ook rootkits die zich weten te verstoppen voor chrootkit. De adore rootkit is er zo een.

Verder is er nog een groep rootkits die zich in kernel memory laden via het dev filesysteem en waarden direct in kernel memory wijzigen en deze groep is door chkrootkit niet te detecteren. Voor zover ik weet is er zowiezo geen tool die dit kan. Wat je zou kunnen doen is een kernel zonder modules compilen en vervolgens met een patch als openwall (2.2.x) of gr security (2.4.x) kernel memory (/dev/kmem) beter kunnen beschermen. (deze patches doen veel meer dan dit en zijn een aanrader op high security servers).

Ook is het belangrijk om de ruleset van Snort regelmatig te updaten. Er komen met grote regelmaat nieuwe rulesets uit om meer typen scans en aanvallen te herkennen. Snort rules zijn namelijk opgebouwd om ongewoon verkeer ipv van gewoon verkeer te herkennen en op al het overige alarm te slaan, helaas. Zowiezo is het nut van Snort beperkt, omdat het alleen maar verkeer analyseert en volgens mij nog geen aanvallen kan afweren met TCP resets. Je moet het dus zien als een verrekijker zodat je wat eerder aanvallen kan zien aankomen, maar niet stoppen. Ik geloof dat Debian nog bezig was om een aparte package te maken met update rulesets. Ik denk dat dit nog niet in de stable tree zit, dus houd daar rekening mee.

[ Voor 0% gewijzigd door Verwijderd op 07-10-2002 23:30 . Reden: snort debian toevoeging ]

[deadinspace]

Verwijderd schreef op 07 oktober 2002 @ 16:47:
...en nmap doet niet meer als dat een 'netstat -an|grep LISTEN' zou doen maar mjah NMap is ook wel leuk.

Met nmap vanaf een remote host controleer je wel meteen of je firewall rules goed werken e.d.

[Verwijderd]

Jullie zijn alleen heel hulpzaam geweest in deze 'moeilijke' tijd.

Ik heb ondertussen een nieuwe kernel compiled en ben bezig met mijn IPtables firewall te herschrijven.

Dank gaat uit aan iedereen die me geholpen heeft, en aan balou en deadinspace voor hun 'enorme' lappen tekst

Ik zou bijna een traantje wegpinken

ps. Het is idd jammer dat Snort ook niet gewoon IPtables kan updaten als hij bv erachter komt dat pietje hem scanned.

[ Voor 0% gewijzigd door Verwijderd op 08-10-2002 04:29 . Reden: snort ]

[Wirf]

Als je debian hebt draaien (en dat heb je) is het ook erg handig om:

deb http://security.debian.org woody/updates main contrib non-free

in je /etc/apt/sources.list te hebben en dan regelmatig apt-get update; apt-get dist-upgrade te draaien. Kan misschien wel als een crontabje elke week.

[Verwijderd]

Verwijderd schreef op 08 oktober 2002 @ 04:26:
ps. Het is idd jammer dat Snort ook niet gewoon IPtables kan updaten als hij bv erachter komt dat pietje hem scanned.

Nah, dat wil je niet. Als een cracker daar achter komt zou hij UDP verkeer met een random afzender naar je machine sturen in een patroon waar Snort op triggert en dan worden al die ip's geblocked. Lijkt mij niet echt handig voor een webserver. Je kan het doen, maar ik vind dat soort constructies erg gevaarlijk.

Je zou beter kunnen zorgen dat je machine optimaal beveiligd is en bij veel portscans vanaf een ip adres een abuse mailtje naar de betreffende provider sturen. Soms doen ze daar wat mee, soms ook niet.

Verder kun je ook voor UDP connection tracking toepassen, zie onderstaande link. (Ik neem aan dat je dit al connection tracking gebruikt voor TCP).
http://www.sns.ias.edu/~j...s/iptables_conntrack.html
Verder is ook de rate limit optie in iptables interessant voor ICMP verkeer en natuurlijk een default DROP policy gebruiken.

Succes met beveiligen en als je hulp nodig hebt horen we het wel.

[Verwijderd]

Verwijderd schreef op 07 oktober 2002 @ 16:47:
... en nmap doet niet meer als dat een 'netstat -an|grep LISTEN' zou doen maar mjah NMap is ook wel leuk.

Nmap doet iets heel anders dan dat jij denkt, Lees de manual page er maar eens goed op na. Nmap is (voor zover ik weet) de meest veelzijdige poortscanner in-existance. En een poortscanner != netstat