hou worms uit je apache-logs

[Verwijderd]

hoi allemaal,

Ik heb (als zovelen) een maniertje gevonden om te voorkomen dat worms zoals nimda of code-red in je apache logs komen. Ik geloof dat deze manier zal beschermen tegen bijna alle webserver-worms maar in ieder geval tegen code-red en nimda.

Ok, een worm zoals code-red doet niets meer als een "get /default..." vraag sturen naar zoveel mogelijk ip's als die kan vinden. Een browser van een gebruikers geeft voordat het een pagina opvraagt altijd eerst de naam van de webserver waarvan hij de pagina wil hebben, er kunnen namelijk meerdere webservers op 1 ip draaien. Een manier om dus de worms van de gebruikers te scheiden is een virtual-host in te stellen die naar niet naar je webserver-naam(en) luisterd. Ik heb dit zo gedaan:

---- stukje onderuit m'n httpd.conf ----
# Use name-based virtual hosting.
#
NameVirtualHost *

<VirtualHost *>
DocumentRoot /data/htdocs/redirect/
ServerName 130.89.235.53
ErrorLog /dev/null
CustomLog /dev/null
</VirtualHost>

<VirtualHost *>
ServerName wkamphuis.student.utwente.nl
</VirtualHost>
---- einde van m'n httpd.conf ----

Elke browser die een pagina van mijn webserver wil hebben zal eerst melden dat die pagina van wkamphuis.student.utwente.nl moet komen (mijn webserver). Worms doen dat niet en worden door de default-vhost afgehandeld. Deze vhost (de 1e vhost) serveert niets anders dan een redirect pagina waar een script niets mee doet, een browser wel. Al met al worden alle worms in /dev/null gelogt en normale gebruikers netjes in de standaard logfiles. Ook kan je de default-vhost extra beveiligen door geen cgi of php toe te laten, in het geval iemand ooit een worm voor apache maakt.

Deze setup werkt bij mij zonder problemen en sinds dat ik dit heb is er geen iis-exploit meer in m'n logfiles gekomen.

Ik ben geen apache-expert what-so-ever dus kan iemand hier commentaar op geven, misschien zie ik iets over het hoofd of zou dit andere problemen geven.

alvast bedankt,
Wolter Kamphuis

[Verwijderd]

misschien dat "man sed" makkelijker was geweest

[flat]

hmm wel slim bedacht ja

maareh, ik wil die attacks juist wél in m'n logfiles hebben hoor

[Verwijderd]

misschien dat "man sed" makkelijker was geweest

ik probeer de attacks juist uit de logs te houden ipv ze er later weer uit te vissen, dit bespaart me veel werk.

[Bart Coppens]

Op zondag 23 september 2001 19:22 schreef Flat© het volgende:
hmm wel slim bedacht ja

maareh, ik wil die attacks juist wél in m'n logfiles hebben hoor

Dan laat je die eerste vhost toch gewoon naar een apart logbestand schrijven. Dan heb je je worms toch nog, en je houdt ze toch nog apart.

[Verwijderd]

Op zondag 23 september 2001 19:22 schreef Flat© het volgende:
hmm wel slim bedacht ja

maareh, ik wil die attacks juist wél in m'n logfiles hebben hoor

Mjah, als je virtual hosts hebt, dan is het je vast wel opgevallen, dat attacks inderdaad aleen richting de VHost gaan die je terug krijgt als je je IP invoert en dus niet richting namebased virtual hosts.

Ten eerste wil ik inderdaad wel dat in mijn logfiles hebben!
Ten tweede, logt dit dus niet potentiele aanvallen, die richting je IP gebeuren!!

Als ik een logfile zonder die nimda wil zien doe ik het volgende:

code:

sed -e "s/cmd.exe//" custom_log >> log_zonder_nimda

Hierin is custom_log mijn webservers logfile en log_zonder_nimda de file die aangemaakt wordt.

[Verwijderd]

Op zondag 23 september 2001 19:27 schreef wkamphuis het volgende:

[..]

ik probeer de attacks juist uit de logs te houden ipv ze er later weer uit te vissen, dit bespaart me veel werk.

veel werk?

Tja zie bovenstaande. desnoods zet je dat in een crontabje o.i.d.

Het veroorzaakt ook een potentieel security probleem, zoals je het nu doet!

[Verwijderd]

Mjah, als je virtual hosts hebt, dan is het je vast wel opgevallen, dat attacks inderdaad aleen richting de VHost gaan die je terug krijgt als je je IP invoert en dus niet richting namebased virtual hosts.

ja, dus zo kunnen we onderscheid maken tussen attacks en gebruikers die een webbrowser gebruiken.

Ten eerste wil ik inderdaad wel dat in mijn logfiles hebben! Ten tweede, logt dit dus niet potentiele aanvallen, die richting je IP gebeuren!!

de speciale vhost om attacks te (niet) loggen kan je apart beveiligen, bijv. door cgi/php uit te zetten e.d.

Als ik een logfile zonder die nimda wil zien doe ik het volgende:

code:

sed -e "s/cmd.exe//" custom_log >> log_zonder_nimda

Hierin is custom_log mijn webservers logfile en log_zonder_nimda de file die aangemaakt wordt.

ik log ook de browsers die mensen gebruiken, jij misschien ook. als ik nou eens mijn browser cmd.exe noem... dan heb jij een probleem.

[Verwijderd]

Op zondag 23 september 2001 19:34 schreef nelske het volgende:
veel werk?

wie heeft het hier over 1 machine die beveiligd moet worden, misschien beheer ik wel een hele batterij met webservers en controleer ik al die logfiles met de hand. het (correct) filteren van iis-attacs bespaart zo veel werk.

[0siris]

je kunt ook vast wel ergens aangeven welk soort problemen je in je logfiles wilt hebben, bijvoorbeeld dat je alleen kritieke meldingen erin wil hebben en niet "blabla not found" dingen.

Verder vind ik dit allemaal wel snel gevonden, maar die logfiles worden toch gewoon ge-gzipt en eens in de zoveel tijd een nieuwe voor aangemaakt enzo?

Ik heb er persoonlijk niet zo'n last van, maar als je dat WEL hebt, is de geboden oplossing best een goede vind ik!

[Verwijderd]

je kunt ook vast wel ergens aangeven welk soort problemen je in je logfiles wilt hebben, bijvoorbeeld dat je alleen kritieke meldingen erin wil hebben en niet "blabla not found" dingen.

dat kan ja maar wil je een website goed onderhouden dan moet je ook dit soort fouten loggen, hoe kom je er anders achter welke fouten er in je website zitten of welke pagina's er missen.

Verder vind ik dit allemaal wel snel gevonden, maar die logfiles worden toch gewoon ge-gzipt en eens in de zoveel tijd een nieuwe voor aangemaakt enzo?

log-rotatie, dat gebruik we ook maar waarom iets opslaan en niets mee doen? voordat we een backup van de logs ergens opslaan lezen we hem toch ff door, gewoon kijken of er vreemde dingen in staan of een bepaalde fout veel voorkomt. het ontbreken van veel, erg veel iis-attacks maakt dit werk een heel stuk simpeler.

Ik heb er persoonlijk niet zo'n last van, maar als je dat WEL hebt, is de geboden oplossing best een goede vind ik!

ik heb er zeker profijt van, met mij vele denk ik. meer dan 10.000 attacks per week is geen uitzondering met een uitbraak zoals code-red.

[Verwijderd]

Op zondag 23 september 2001 20:00 schreef wkamphuis het volgende:
ja, dus zo kunnen we onderscheid maken tussen attacks en gebruikers die een webbrowser gebruiken.

Waarom zou men niet via een broswer op je IP kunnen surfen?
Gebeurt regelmatig.

de speciale vhost om attacks te (niet) loggen kan je apart beveiligen, bijv. door cgi/php uit te zetten e.d.

Ja, maar dan nog heb je op dit momet geen log van IP's die eventueel kwaad willen.

ik log ook de browsers die mensen gebruiken, jij misschien ook. als ik nou eens mijn browser cmd.exe noem... dan heb jij een probleem.

Jaja, zou kan ik er ook nog wel een paar verzinnen! De kans dat dat gebeurt is vrij klein natuurlijk. Maar goed, dan breid je het patroon toch net iets verder uit dan de huidige expressie "cmd.exe".

Verder doe ik ua-log en referer-log in een aparte file, om enigszins overzicht te houden.

Op zondag 23 september 2001 20:03 schreef wkamphuis het volgende:
wie heeft het hier over 1 machine die beveiligd moet worden, misschien beheer ik wel een hele batterij met webservers en controleer ik al die logfiles met de hand. het (correct) filteren van iis-attacs bespaart zo veel werk.

Euhmmm.... als dat zo was, dan moet je ook voor alle machines de apache-conf aan gaan passen. Zet hetgeen ik gaf in een scriptje en je gooit dat naar alle machines en je bent klaar.

Dan er bij als je echt zo veel machines zou beheren, dan zou je weten dat logfiles heilig zijn en ga je dus ook niet een kunstgreep als deze toepassen om dingen eruit te halen. Sterker nog, dan wil je niks uit je logfiles halen!

Verder zie ik aan de directory indeling, dat je voor browsers een redirect gebruikt; ofwel je hebt een php/html paginaatje dat voor een redirect zorgt.
Hoezo minder werk?

[edit]
Typos

[Verwijderd]

Waarom zou men niet via een broswer op je IP kunnen surfen? Gebeurt regelmatig.

kan nog steeds, men krijgt wel eerst een redirect-page maar deze kan de gebruiker naar de normale pagina sturen. Tenzij je de ip-vhost gebruikt als volwaardige virtual host... dan kan dat idd niet.

Ja, maar dan nog heb je op dit momet geen log van IP's die eventueel kwaad willen.

Op een virtual host die niets mag/kan valt erg weinig kwaad te willen. desnoods log je niet in /dev/null maar in een aparte apache-crap-logfile.

Euhmmm.... als dat zo was, dan moet je ook voor alle machines de apache-conf aan gaan passen. Zet hetgeen ik gaf in een scriptje en je gooit dat naar alle machines en je bent klaar.

ik log liever iets niet dan ik het wel log en later moet weghalen. daarbij komt dat jij elke keer bij een nieuwe worm je script moet aanpassen (met kans op fouten) en ik in 1 keer klaar ben.

Dan er bij als je echt zo veel machines zou beheren, dan zou je weten dat logfiles heilig zijn en ga je dus ook niet een kunstgreep als deze toepassen om dingen eruit te halen. Sterker nog, dan wil je niks uit je logfiles halen!

klopt dus draai je ook geen scripts die de logsfiles opruimen. voor hun is deze thread dus ook niet belangerijk.

Verder zie ik aan de directory indeling, dat je voor browsers een redirect gebruikt; ofwel je hebt een php/html paginaatje dat voor een redirect zorgt. Hoezo minder werk?

<html><head>
<meta http-equiv="refresh" content="5; URL=http://blabla.com">
</head></html>
is genoeg

het idee was dat met een vrij simpele methode veel crap uit je apache log kan houden. behalve als je echt bang bent dat men security-holes in apache vind is dit een handige oplossing.