Discussion:
Opeens SSH op poort 80
(te oud om op te antwoorden)
Paul van der Vlis
2009-04-27 09:26:21 UTC
Permalink
Hallo,

Bij een klant, een school, werd ik geconfronteerd met een raar probleem.
Apache2 lag er op zondagochtend opeens uit, en in plaats van apache2
draaide er een sshd op poort 80. Dit was ontstaan tijdens de logrotate.
Uiteraard draaide sshd ook nog gewoon op poort 22.

Heeft iemand hier een verklaring voor? Is dit misschien een bekende
methode om een machine over te nemen via logrotate?

Als ik nogmaals de logrotate draai, gebeurd het niet nogmaals.

Misschien related?:
Er is door een beheerder op de school in de afgelopen week een fout
gemaakt, hij heeft 'chown -hR root /' gedraaid, waardoor er van alles
niet meer werkte. Ik heb die problemen zo goed mogelijk verholpen, maar
ik kan wat vergeten zijn.
Na dat probleem was er ook nog een netwerkstoring: er was veel
packet-loss. Een reboot van de machine verhielp dat.

Met vriendelijke groet,
Paul van der Vlis.
--
http://www.vandervlis.nl/
Bas Janssen
2009-04-27 09:43:52 UTC
Permalink
Post by Paul van der Vlis
Hallo,
Bij een klant, een school, werd ik geconfronteerd met een raar probleem.
Apache2 lag er op zondagochtend opeens uit, en in plaats van apache2
draaide er een sshd op poort 80. Dit was ontstaan tijdens de logrotate.
Uiteraard draaide sshd ook nog gewoon op poort 22.
Vreemd, welke 'banner' krijg je precies terug als je telnet naar die
poort 80? wat zeggen netstat -l en lsof -i ?

Dus welk proces opent die connectie precies?
Post by Paul van der Vlis
Heeft iemand hier een verklaring voor? Is dit misschien een bekende
methode om een machine over te nemen via logrotate?
Nog niet eerder van gehoord, maar rootkits die een ssh server starten
zijn vrij standaard.. maar om ssh dan op poort 80 te draaien?
Post by Paul van der Vlis
Als ik nogmaals de logrotate draai, gebeurd het niet nogmaals.
Er is door een beheerder op de school in de afgelopen week een fout
gemaakt, hij heeft 'chown -hR root /' gedraaid, waardoor er van alles
niet meer werkte. Ik heb die problemen zo goed mogelijk verholpen,maar
ik kan wat vergeten zijn.
auch ;-)
Post by Paul van der Vlis
Na dat probleem was er ook nog een netwerkstoring: er was veel
packet-loss. Een reboot van de machine verhielp dat.
--
Bas Janssen /. ***@dds.nl /. www.dds.nl /. PGP#0x22FA2C9F

"Very funny, Scotty. Now beam down my clothes."
Paul van der Vlis
2009-04-27 10:52:23 UTC
Permalink
Post by Bas Janssen
Post by Paul van der Vlis
Hallo,
Bij een klant, een school, werd ik geconfronteerd met een raar probleem.
Apache2 lag er op zondagochtend opeens uit, en in plaats van apache2
draaide er een sshd op poort 80. Dit was ontstaan tijdens de logrotate.
Uiteraard draaide sshd ook nog gewoon op poort 22.
Vreemd, welke 'banner' krijg je precies terug als je telnet naar die
poort 80? wat zeggen netstat -l en lsof -i ?
Dus welk proces opent die connectie precies?
Je snapt het al: ik heb het process gekilled omdat ik haast had, en nu
kan ik geen testjes meer doen. Volgens de bash_history heb ik 'netstat
-tulpn' gedaan, en daarbij zag ik dat er een sshd draaide op poort 80.

Wel een leermoment: wat doe je in zo'n geval? Ik heb me voorgenomen
voortaan de directory van het proces (/proc/nummer) te kopieren, al heb
ik dat nog niet goed getest.
Post by Bas Janssen
Post by Paul van der Vlis
Heeft iemand hier een verklaring voor? Is dit misschien een bekende
methode om een machine over te nemen via logrotate?
Nog niet eerder van gehoord, maar rootkits die een ssh server starten
zijn vrij standaard.. maar om ssh dan op poort 80 te draaien?
Het leek me ook nogal raar, vooral omdat je dat natuurlijk meteen merkt.
Aan de andere kant staat poort 80 natuurlijk open naar buiten toe, en
misschien ging er wat mis.
Post by Bas Janssen
Post by Paul van der Vlis
Als ik nogmaals de logrotate draai, gebeurd het niet nogmaals.
Er is door een beheerder op de school in de afgelopen week een fout
gemaakt, hij heeft 'chown -hR root /' gedraaid, waardoor er van alles
niet meer werkte. Ik heb die problemen zo goed mogelijk verholpen,maar
ik kan wat vergeten zijn.
auch ;-)
Post by Paul van der Vlis
Na dat probleem was er ook nog een netwerkstoring: er was veel
packet-loss. Een reboot van de machine verhielp dat.
Met vriendelijke groet,
Paul van der Vlis.
--
http://www.vandervlis.nl/
Fred Mobach
2009-04-27 18:15:57 UTC
Permalink
Post by Paul van der Vlis
Post by Bas Janssen
Post by Paul van der Vlis
Bij een klant, een school, werd ik geconfronteerd met een raar
probleem. Apache2 lag er op zondagochtend opeens uit, en in plaats
van apache2 draaide er een sshd op poort 80. Dit was ontstaan
tijdens de logrotate. Uiteraard draaide sshd ook nog gewoon op poort
22.
Vreemd, welke 'banner' krijg je precies terug als je telnet naar die
poort 80? wat zeggen netstat -l en lsof -i ?
Je snapt het al: ik heb het process gekilled omdat ik haast had, en nu
kan ik geen testjes meer doen. Volgens de bash_history heb ik 'netstat
-tulpn' gedaan, en daarbij zag ik dat er een sshd draaide op poort 80.
Was dat de gebruikelijk /usr/sbin/sshd met de bijbehorende config ?
Post by Paul van der Vlis
Wel een leermoment: wat doe je in zo'n geval? Ik heb me voorgenomen
voortaan de directory van het proces (/proc/nummer) te kopieren, al
heb ik dat nog niet goed getest.
Als je vreest dat een machine gekraakt is behoor je een heel protocol te
doorlopen aan de hand van de keus of je al dan niet aangifte wilt doen.
Heel in het kort :
- haal de netwerkkabels eruit,
- controleer welke processen er lopen met welke binaries en configs,
- haal de stroom eraf (geen shutdown),
- mount de disk(s) read-only via bv. een rescue system,
- controleer op foute binaries,
- controleer op rootkits,
- bewaar (indien gewenst) die harde schijven als bewijsmateriaal,
- bouw dat systeem opnieuw op,
- haal configs en data van een nog betrouwbare backup.
Post by Paul van der Vlis
Post by Bas Janssen
Post by Paul van der Vlis
Heeft iemand hier een verklaring voor? Is dit misschien een bekende
methode om een machine over te nemen via logrotate?
Nog niet eerder van gehoord, maar rootkits die een ssh server starten
zijn vrij standaard.. maar om ssh dan op poort 80 te draaien?
Het leek me ook nogal raar, vooral omdat je dat natuurlijk meteen
merkt. Aan de andere kant staat poort 80 natuurlijk open naar buiten
toe, en misschien ging er wat mis.
Het is *niet* natuurlijk dat poort 80 naar buiten openstaat :
- in een firewall kun je verschil maken tussen FORWARD en OUTPUT,
- dat geldt ook voor een proxy server,
- combinatie van firewall en proxy server op 1 systeem is niet slim.
--
Fred Mobach - ***@mobach.nl
website : http://fred.mobach.nl
.... In God we trust ....
.. The rest we monitor ..
Paul van der Vlis
2009-04-28 07:26:38 UTC
Permalink
Post by Fred Mobach
Post by Paul van der Vlis
Post by Bas Janssen
Post by Paul van der Vlis
Bij een klant, een school, werd ik geconfronteerd met een raar
probleem. Apache2 lag er op zondagochtend opeens uit, en in plaats
van apache2 draaide er een sshd op poort 80. Dit was ontstaan
tijdens de logrotate. Uiteraard draaide sshd ook nog gewoon op poort
22.
Vreemd, welke 'banner' krijg je precies terug als je telnet naar die
poort 80? wat zeggen netstat -l en lsof -i ?
Je snapt het al: ik heb het process gekilled omdat ik haast had, en nu
kan ik geen testjes meer doen. Volgens de bash_history heb ik 'netstat
-tulpn' gedaan, en daarbij zag ik dat er een sshd draaide op poort 80.
Was dat de gebruikelijk /usr/sbin/sshd met de bijbehorende config ?
Ik weet het niet, en realiseer me dat dit erg jammer is.
Post by Fred Mobach
Post by Paul van der Vlis
Wel een leermoment: wat doe je in zo'n geval? Ik heb me voorgenomen
voortaan de directory van het proces (/proc/nummer) te kopieren, al
heb ik dat nog niet goed getest.
Als je vreest dat een machine gekraakt is behoor je een heel protocol te
doorlopen aan de hand van de keus of je al dan niet aangifte wilt doen.
Gelukkig maak ik dit niet vaak mee, maar inderdaad, ik moet een
dergelijk prototocol gaan opstellen.
Post by Fred Mobach
- haal de netwerkkabels eruit,
Tja, het ging er vooral om dat de boel weer ging werken. Verder was het
mijn vrije zondagochtend en ik had andere dingen te doen (ahum).

Maar ik snap wat je bedoeld.
Post by Fred Mobach
- controleer welke processen er lopen met welke binaries en configs,
Dat is iets waar ik voortaan goed op moet gaan letten. En een plan maken
hoe dat te doen, "ps aux > file" waarschijnlijk.
Post by Fred Mobach
- haal de stroom eraf (geen shutdown),
Hmm, dat heb ik nog niet eerder gehoord.
Post by Fred Mobach
- mount de disk(s) read-only via bv. een rescue system,
- controleer op foute binaries,
- controleer op rootkits,
- bewaar (indien gewenst) die harde schijven als bewijsmateriaal,
- bouw dat systeem opnieuw op,
- haal configs en data van een nog betrouwbare backup.
Post by Paul van der Vlis
Post by Bas Janssen
Post by Paul van der Vlis
Heeft iemand hier een verklaring voor? Is dit misschien een bekende
methode om een machine over te nemen via logrotate?
Nog niet eerder van gehoord, maar rootkits die een ssh server starten
zijn vrij standaard.. maar om ssh dan op poort 80 te draaien?
Het leek me ook nogal raar, vooral omdat je dat natuurlijk meteen
merkt. Aan de andere kant staat poort 80 natuurlijk open naar buiten
toe, en misschien ging er wat mis.
- in een firewall kun je verschil maken tussen FORWARD en OUTPUT,
Ik begrijp dit niet, verdere uitleg wordt erg gewaardeerd.
Post by Fred Mobach
- dat geldt ook voor een proxy server,
- combinatie van firewall en proxy server op 1 systeem is niet slim.
Er is daar geen proxy. Wel een aparte firewall, maar die laat poort 80
gewoon door. Dus ik vraag me wel regelmatig af hoe zinvol dat soort
firewall's zijn. Als groot voordeel zie ik het feit dat je een veilige
plek hebt om te loggen.

Met vriendelijke groet,
Paul van der Vlis.
--
http://www.vandervlis.nl/
Bas Janssen
2009-04-28 08:08:25 UTC
Permalink
Paul van der Vlis schreef:
<snip>
Post by Paul van der Vlis
Post by Fred Mobach
- controleer welke processen er lopen met welke binaries en configs,
Dat is iets waar ik voortaan goed op moet gaan letten. En een plan maken
hoe dat te doen, "ps aux > file" waarschijnlijk.
Als je een rootkit te pakken denkt te hebben, moet je vooral tools als
'top' en 'ps' niet meer vertrouwen.. Deze worden door een rootkit
meestal vervangen door een versie die de draaiende rootkit processen
verbergt.

met tools als md5sum en chkrootkit kan je je binaries checken tegen een
database van vastgelegde md5hashes, en zien of je binaries aangetast
zijn. het beste is het om deze checks te draaien vanaf bijv een live-cd,
waarbij je je eigen systeem disks read-only hebt gemount.
Post by Paul van der Vlis
Post by Fred Mobach
- haal de stroom eraf (geen shutdown),
Hmm, dat heb ik nog niet eerder gehoord.
Als je een rootkit te pakken hebt kan het shutdown commando ook corrupt
zijn en bijv. de 'inbraaksporen' verwijderen bij het draaien..

<snip>

Hier een paper van sans over linux rootkits.
Moeite van het lezen waard:
http://www.sans.org/reading_room/whitepapers/linux/linux_rootkits_for_beginners_from_prevention_to_removal_901
--
Bas Janssen /. ***@dds.nl /. www.dds.nl /. PGP#0x22FA2C9F

Opinions expressed by the author may not actually exist in the wild.
Hans W
2009-04-29 21:59:49 UTC
Permalink
Post by Fred Mobach
Post by Paul van der Vlis
Post by Bas Janssen
Post by Paul van der Vlis
Bij een klant, een school, werd ik geconfronteerd met een raar
probleem. Apache2 lag er op zondagochtend opeens uit, en in plaats
van apache2 draaide er een sshd op poort 80. Dit was ontstaan
tijdens de logrotate. Uiteraard draaide sshd ook nog gewoon op poort
22.
Vreemd, welke 'banner' krijg je precies terug als je telnet naar die
poort 80?  wat zeggen netstat -l en lsof -i ?
Je snapt het al: ik heb het process gekilled omdat ik haast had, en nu
kan ik geen testjes meer doen. Volgens de bash_history heb ik 'netstat
-tulpn' gedaan, en daarbij zag ik dat er een sshd draaide op poort 80.
Was dat de gebruikelijk /usr/sbin/sshd met de bijbehorende config ?
Post by Paul van der Vlis
Wel een leermoment: wat doe je in zo'n geval?  Ik heb me voorgenomen
voortaan de directory van het proces (/proc/nummer) te kopieren, al
heb ik dat nog niet goed getest.
Als je vreest dat een machine gekraakt is behoor je een heel protocol te
doorlopen aan de hand van de keus of je al dan niet aangifte wilt doen.
- haal de netwerkkabels eruit,
- controleer welke processen er lopen met welke binaries en configs,
- haal de stroom eraf (geen shutdown),
- mount de disk(s) read-only via bv. een rescue system,
- controleer op foute binaries,
- controleer op rootkits,
- bewaar (indien gewenst) die harde schijven als bewijsmateriaal,
- bouw dat systeem opnieuw op,
- haal configs en data van een nog betrouwbare backup.
Ik zou ook even de eventuele webserver logfiles nakijken om te zien
of iemand niet een at job heeft weten te zetten, ga er vooralsnog van
uit dat apache niet als root liep maar je komt dat soms tegen.

Hans

Ximinez
2009-04-27 16:25:41 UTC
Permalink
Post by Bas Janssen
Nog niet eerder van gehoord, maar rootkits die een ssh server starten
zijn vrij standaard.. maar om ssh dan op poort 80 te draaien?
Dat is dan een logische keuze, want dat is de meest waarschijnlijke
poort die naar buiten open staat.

Ik zou de rootkit optie maar eens goed onderzoeken.

X.
Paul van der Vlis
2009-04-28 06:55:18 UTC
Permalink
Post by Ximinez
Post by Bas Janssen
Nog niet eerder van gehoord, maar rootkits die een ssh server starten
zijn vrij standaard.. maar om ssh dan op poort 80 te draaien?
Dat is dan een logische keuze, want dat is de meest waarschijnlijke
poort die naar buiten open staat.
Ik zou de rootkit optie maar eens goed onderzoeken.
Dat heb ik natuurlijk gedaan, chkrootkit meldt geen problemen.

Maar daarbij heb ik dan ook altijd de gedachte: hoe weet ik dat ik
chkrootkit kan vertrouwen? En als ik het opnieuw installeer, kan ik het
dan vertrouwen? Als iemand een rootkit kan installeren, dan kan hij
volgens mij in principe ook chkrootkit manipuleren...

Met vriendelijke groet,
Paul van der Vlis.
--
http://www.vandervlis.nl/
jjg
2009-04-28 08:00:51 UTC
Permalink
Post by Paul van der Vlis
Post by Ximinez
Post by Bas Janssen
Nog niet eerder van gehoord, maar rootkits die een ssh server starten
zijn vrij standaard.. maar om ssh dan op poort 80 te draaien?
Dat is dan een logische keuze, want dat is de meest waarschijnlijke
poort die naar buiten open staat.
Ik zou de rootkit optie maar eens goed onderzoeken.
Dat heb ik natuurlijk gedaan, chkrootkit meldt geen problemen.
Maar daarbij heb ik dan ook altijd de gedachte: hoe weet ik dat ik
chkrootkit kan vertrouwen? En als ik het opnieuw installeer, kan ik het
dan vertrouwen? Als iemand een rootkit kan installeren, dan kan hij
volgens mij in principe ook chkrootkit manipuleren...
Daarom is het ook handig om een Live CD te gebruiken. Dus, inderdaad:
spanning eraf (ook shutdown kan gemanipuleerd zijn), booten van liveCD,
chkrootkit ook van liveCD...
Ximinez
2009-04-29 07:12:20 UTC
Permalink
Post by Paul van der Vlis
Post by Ximinez
Post by Bas Janssen
Nog niet eerder van gehoord, maar rootkits die een ssh server starten
zijn vrij standaard.. maar om ssh dan op poort 80 te draaien?
Dat is dan een logische keuze, want dat is de meest waarschijnlijke
poort die naar buiten open staat.
Ik zou de rootkit optie maar eens goed onderzoeken.
Dat heb ik natuurlijk gedaan, chkrootkit meldt geen problemen.
Maar daarbij heb ik dan ook altijd de gedachte: hoe weet ik dat ik
chkrootkit kan vertrouwen? En als ik het opnieuw installeer, kan ik het
dan vertrouwen? Als iemand een rootkit kan installeren, dan kan hij
volgens mij in principe ook chkrootkit manipuleren...
Bereken de md5 checksums van een recente (known good) backup en
vergelijk ze met het huidige systeem. (na booten van een live-CD
natuurlijk).

Er is een programma genaamd 'tripwire' dat iets dergelijks doet als ik
het wel heb. Ik heb het zelf nooit gebruikt.

http://sourceforge.net/projects/tripwire

X.
Loading...