[apache] IIS-exploits filter

[rookie]

mijn apache log (1.3.29@linux) staat vol met dergelijke entries:

code:

x.x.x.x - - [03/Apr/2004:11:48:08 +0200] "SEARCH /\x90\x02\xb1\x02 ... \x90\x90" 414 341 "-" "-"

Het request zelf is 32732 karakters lang, en blijkt een IIS WebDAV exploit

Allemaal leuk en aardig, maar ik wil deze entries dus niet in mijn log hebben, net als alle andere IIS exploits:

code:

fragment httpd.conf:
SetEnvIfNoCase Request_URI "\/default\.ida" dontlog
SetEnvIfNoCase Request_URI "\/(msadc|_vti_bin|_mem_bin)" dontlog
SetEnvIfNoCase Request_URI "winnt\/system32\/cmd\.exe" dontlog
SetEnvIfNoCase Request_URI "\/scripts\/root\.exe" dontlog
SetEnvIfNoCase Request_URI "\/scripts\/nsiislog\.dll" dontlog
SetEnvIfNoCase Request_URI "\/(httpodbc|Admin)\.dll" dontlog
SetEnvIfNoCase Request_URI "\\x90\\" dontlog
SetEnvIf Request_Method SEARCH dontlog
...
CustomLog /var/log/httpd/access.log combined env=!dontlog

Maar nu wil het feit dat deze beide regels:
SetEnvIfNoCase Request_URI "\\x90\\" dontlog
SetEnvIf Request_Method SEARCH dontlog
het gewoon niet doen...

(het lijkt wel of apache heel de method SEARCH niet kent)

Iemand ideëen?

[ Voor 7% gewijzigd door rookie op 03-04-2004 14:31 ]

[rookie]

niemand?

[Wilke]

Heu, ik heb ook nog nooit gehoord van een Request_method 'SEARCH'.

Ik kan wel ergens vinden dat het een voorstel was om die method toe te voegen, maar ik kan het in de HTTP RFC niet terugvinden.

Waarom die andere het niet doet weet ik niet, wat voor pattern wil je daarmee afvangen precies?

[blaataaps]

Ik denk dat ie daar dezelfde mee probeert te vangen, de laatste paar weken is er namelijk een worm die SEARCH requests doet met een string van 65kbyte als ik me niet vergis, in de volgende vorm ongeveer:

code:

"SEARCH /\x90\x02\xb1\x02\xb1\x02\xb1\x02\xb1\

en dan dus nog 65k shellcode, op een webserver die verder weinig interessants doet krijg je dan dit:

-rw-r----- 1 root adm 27M Apr 10 14:33 apache/access.log

logs die ontzettend groot worden, omdat zo'n worm 1x niet voldoende vindt, een sh-oneliner toonde hier aan dat van sommige ip's richting de 100, en soms wel meer pogingen doen, elk goed voor 64k logs

[ Voor 3% gewijzigd door blaataaps op 10-04-2004 14:43 ]

[pinball]

^bump^

Ik heb hetzelfde probleem. Via een andere route weliswaar, ik probeer die requests (net als andere irritante IIS exploits) te redirecten naar een script dat de boosdoener meteen toevoegt aan m'n firewall. Dat werkt prima voor Code Red/Nimda, maar bij deze SEARCH x90/x90 krijg ik het niet werkend.

stukje httpd.conf:

Waarschuwing: alleen bedoeld ter illustratie! Niet zomaar kopieren als je niet weet wat het doet!

code:

<Directory /var/www/>
...
   RewriteEngine on
   RewriteCond %{THE_REQUEST} x90.x90 [NC,OR]
   RewriteCond %{THE_REQUEST} default.ida [NC,OR]
...
   RewriteCond %{THE_REQUEST} nsiislog [NC,OR]
   RewriteCond %{THE_REQUEST} formail [NC]
   RewriteRule .* /cgi-bin/add2firewall.pl
  
   RewriteCond %{REQUEST_METHOD} !^(GET|HEAD|POST)$ [NC,OR]
   RewriteCond %{REQUEST_METHOD} ^(SEARCH)$
   RewriteRule .* /cgi-bin/add2firewall.pl

Nu ik hierboven lees dat SetEnvIf ook niet werkt lijkt het erop dat apache éérst besluit dat de URI te lang is, en vervolgens niet verder processed.

[ Voor 7% gewijzigd door pinball op 18-04-2004 11:30 ]

[Kippenijzer]

Intressant topic dit. Valt me in ene op dat ik er idd ook last van blijk te hebben. Op de post van pinball hierboven vroeg ik me af of het "voldoende" is om enkel get,post en head requests oe te staan. Zijn er geen andere (veel gebruikte) requests?

[pinball]

Er zijn nog andere request methods (bv OPTIONS). Veelgebruikt zijn ze meestal niet, en of ze op jouw server nodig zijn moet je zelf bepalen (op mijn simpele site iig niet).

Ik heb wel even een waarschuwing toegevoegd voor de zekerheid, voor als mensen zomaar gaan Copy/Pasten :-)

[Verwijderd]

Hier hetzelfde probleem. M'n Apache Cookbook ligt helaas thuis, dus ik kan nog niet ff gauw naar een oplossing zoeken.

[Zuig]

Ik heb hier ook heel veel last van, maar ik negeer dit gewoon, ik heb een vb scriptje gemaakt wat al deze meldingen eruit vist en naar een ander log wegschrijft.
Als mijn standaard apache log groter dan xx MB wordt laat ik hem flushen.

[Verwijderd]

Na aanleiding van dit topic ook ens mn apachelog doorgespit en vind talloze requests tot iis scripts. Iemand probeerde zelfs met frontpage ofzo een website te publischen op mijn server. Veel van die SEARCH methodes worden geprobeerd met bergen tekens erachter, zo'n regel in het logboek is dan ook 32798 tekens lang en mn logboek is daardoor verschrikkelijk groot voor mn kleine website (26mb). Denk dat ik me die ook maar probeer te blokkeren.

[ Voor 18% gewijzigd door Verwijderd op 19-04-2004 16:24 ]

[blaataaps]

Zodra je de logs waarin die lange SEARCH queries zitten gaat rotaten, verdwijnt het probleem eigenlijk al. Het grootste deel van de shellcode is \x90 (NOOP), en een lange string van repeterende tekens comprimeert vrij goed

code:

# ls -lh access.log
-rw-r-----    1 root     root          27M Apr 19 16:22 access.log
# grep -c \x90 access.log
845
# gzip access.log
# ls -lh access.log.gz
-rw-r-----    1 root     root         206k Apr 19 16:22 access.log.gz
#

Het gaat dus van bijna 30M naar net iets meer dan 200k, de 845 bezoekjes van de worm comprimeren prima. Nog steeds een stukje groter dan een log waarbij deze worm niet langs is geweest, maar toch een flink stuk minder erg dan tientallen logfiles van tientallen megabytes

[ Voor 8% gewijzigd door blaataaps op 19-04-2004 16:26 ]

[Verwijderd]

ook maar ens die methode toegepast

resultaat (draait op win2k):

code:

$ ls -lh access.log
-rwxr--r--    1 mark     users         26M Apr 19 19:19 access.log
$ grep -c \x90 access.log
252
$ gzip access.log
$ ls -lh access.log.gz
-rwxr--r--    1 mark     users        808k Apr 19 19:19 access.log.gz

Niet gek, scheelt veel plaats op mn 2gig schijfje Blijkbaar wordt mn server minder lastig 'maar' 252 bezoeken van het wormpje.

[ Voor 10% gewijzigd door Verwijderd op 19-04-2004 23:14 ]