Vraag Omgaan met HTTP w00tw00t-aanvallen


Ik heb een server met apache en ik heb onlangs mod_security2 geïnstalleerd omdat ik hierdoor veel wordt aangevallen:

Mijn apache-versie is apache v2.2.3 en ik gebruik mod_security2.c

Dit waren de vermeldingen uit het foutenlogboek:

[Wed Mar 24 02:35:41 2010] [error] 
[client 88.191.109.38] client sent HTTP/1.1 request without hostname 
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Wed Mar 24 02:47:31 2010] [error] 
[client 202.75.211.90] client sent HTTP/1.1 request without hostname 
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Wed Mar 24 02:47:49 2010] [error]
[client 95.228.153.177] client sent HTTP/1.1 request without hostname
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Wed Mar 24 02:48:03 2010] [error] 
[client 88.191.109.38] client sent HTTP/1.1 request without hostname
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

Hier zijn de fouten uit de access_log:

202.75.211.90 - - 
[29/Mar/2010:10:43:15 +0200] 
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-"
211.155.228.169 - - 
[29/Mar/2010:11:40:41 +0200] 
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-"
211.155.228.169 - - 
[29/Mar/2010:12:37:19 +0200] 
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-" 

Ik heb geprobeerd mod_security2 als volgt te configureren:

SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind"
SecFilterSelective REQUEST_URI "\w00tw00t\.at\.ISC\.SANS"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:\)"

Het ding in mod_security2 is dat SecFilterSelective niet kan worden gebruikt, het geeft me fouten. In plaats daarvan gebruik ik een regel als deze:

SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind"
SecRule REQUEST_URI "\w00tw00t\.at\.ISC\.SANS"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:\)"

Zelfs dit werkt niet. Ik weet niet meer wat ik moet doen. Heeft iemand advies?

Update 1

Ik zie dat niemand dit probleem kan oplossen met mod_security. Tot nu toe lijkt het gebruik van ip-tabellen de beste optie om dit te doen, maar ik denk dat het bestand extreem groot zal worden omdat de ip verschillende keren per dag verandert.

Ik bedacht twee andere oplossingen, kan iemand commentaar op hen geven over goed zijn of niet.

  1. De eerste oplossing die in mijn gedachten opkomt is het uitsluiten van deze aanvallen uit mijn apache-foutenlogboeken. Dit maakt het makkelijker voor mij om andere urgente fouten te herkennen als ze zich voordoen en ze hoeven niet door een lange log te spugen.

  2. De tweede optie is beter denk ik, en dat is het blokkeren van hosts die niet op de juiste manier worden verzonden. In dit voorbeeld wordt de aanval w00tw00t verzonden zonder hostnaam, dus ik denk dat ik de hosts kan blokkeren die niet in de juiste vorm zijn.

Update 2

Na het doornemen van de antwoorden kwam ik tot de volgende conclusies.

  1. Aangepast loggen voor apache zal wat onnodige bronnen kosten en als er echt een probleem is, wil je waarschijnlijk naar het volledige logboek kijken zonder dat er iets ontbreekt.

  2. Het is beter om de hits gewoon te negeren en u te concentreren op een betere manier om uw foutenlogboeken te analyseren. Het gebruik van filters voor uw logs is hiervoor een goede benadering.

Laatste gedachten over het onderwerp

De hierboven genoemde aanval zal uw machine niet bereiken als u op zijn minst een up-to-date systeem hebt, dus er zijn in principe geen zorgen.

Het kan moeilijk zijn om na een tijdje alle valse aanvallen van de echte uit te filteren, omdat zowel de foutlogboeken als de toegangslogs extreem groot worden.

Voorkomen dat dit gebeurt, kost u middelen en het is een goede gewoonte om uw middelen niet te verspillen aan onbelangrijke zaken.

De oplossing die ik nu gebruik is Linux logwatch. Het stuurt me samenvattingen van de logs en ze worden gefilterd en gegroepeerd. Op deze manier kunt u gemakkelijk het belangrijke van het onbelangrijke scheiden.

Bedankt voor de hulp, en ik hoop dat dit bericht ook nuttig kan zijn voor iemand anders.


80
2018-03-24 05:33


oorsprong




antwoorden:


Vanuit uw foutenlogboek verzenden ze een HTTP / 1.1-aanvraag zonder het host: deel van het verzoek. Van wat ik lees, antwoordt Apache met een 400 (bad request) fout op dit verzoek, alvorens over te dragen aan mod_security. Dus het ziet er niet naar uit dat uw regels worden verwerkt. (Apache die ermee omgaat voordat hij moet overdragen aan mod_security)

Probeer jezelf:

telnet hostnaam 80
GET /blahblahblah.html HTTP / 1.1 (enter)
(Vul)

U zou de 400-fout moeten krijgen en dezelfde fout in uw logboeken moeten zien. Dit is een slecht verzoek en apache geeft het juiste antwoord.

Een juist verzoek moet er als volgt uitzien:

GET /blahblahblah.html HTTP / 1.1
Host: blah.com

Een probleem met dit probleem zou kunnen zijn patch mod_uniqueid, om een ​​unieke ID te genereren, zelfs voor een mislukt verzoek, zodat apache het verzoek doorgeeft aan zijn verzoekbehandelaars. De volgende URL is een discussie over dit werk en bevat een patch voor mod_uniqueid die u zou kunnen gebruiken:   http://marc.info/?l=mod-security-users&m=123300133603876&w=2

Kon er geen andere oplossingen voor vinden en vraagt ​​zich af of een oplossing eigenlijk wel nodig is.


34
2018-03-29 13:17



Ik zie het probleem nu. Beveel je de oplossing in het artikel aan, of denk je dat het beter is om het gewoon te laten zoals het is? Het is een scanner voor alle achterdeuren in het systeem. Als ik het gewoon laat scannen, kan ik op een dag worden aangevallen. - Saif Bechan
Hallo Saif, ik denk dat zolang je je apache-installatie up-to-date houdt met je distributies (of handmatige) beveiligingspatches het goed komt. Een slecht gestructureerd HTTP / 1.1-verzoek (zoals u hebt gezien) mag niets anders dan een 400-fout van apache retourneren. Het lijkt erop mei een soort kwetsbaarheidsscan zijn geweest die zich richtte op DLink-routers. (Volgens sommige andere bronnen) - Imo
Is er op zijn minst een manier om deze velden uit mijn apache error_log te halen - Saif Bechan
U kan zijn in staat om het te doen via mod_log :: httpd.apache.org/docs/2.2/mod/mod_log_config.html#customlog - Imo
Mijn extra hint zou zijn: configureer je standaard virtualhost naast degenen die daadwerkelijk in gebruik zijn. De hierboven genoemde pogingen komen in de logboeken voor de standaard VirtualHost. - Koos van den Hout


IP's filteren is geen goed idee, imho. Waarom probeer je de string niet te filteren die je kent?

Ik bedoel:

iptables -I INPUT -p tcp --dport 80 -m string --to 60 --algo bm --string 'GET /w00tw00t' -j DROP

15
2018-05-09 16:21



spamcleaner.org/en/misc/w00tw00t.html vergelijkbare oplossing, maar een beetje meer gedetailleerd. - Isaac
Een probleem met stringfiltering in de firewall is dat het "redelijk langzaam" is. - Alexis Wilke
@ Alexis Wilke heb je bewijs dat suggereert dat iptables stringfilters langzamer is dan filteren op apache-niveau? - jrwren


Iv begon ook dit soort berichten te zien in mijn logbestanden. Een manier om dit soort aanvallen te voorkomen is door fail2ban in te stellen ( http://www.fail2ban.org/ ) en stel specifieke filters in om dit IP-adres in black op te nemen in uw iptables-regels.

Dit is een voorbeeld van een filter dat het IP-adres zou blokkeren dat hoort bij het maken van die berichten

[Tue Aug 16 02:35:23 2011] [error] [client] Bestand bestaat niet: /var/www/skraps/w00tw00t.at.blackhats.romanian.anti-sec :) === apache w00t w00t berichten jail - regex en filter === Gevangenis

 [apache-wootwoot]
 enabled  = true
 filter   = apache-wootwoot
 action   = iptables[name=HTTP, port="80,443", protocol=tcp]
 logpath  = /var/log/apache2/error.log
 maxretry = 1
 bantime  = 864000
 findtime = 3600

Filter

 # Fail2Ban configuration file
 #
 # Author: Jackie Craig Sparks
 #
 # $Revision: 728 $
 #
 [Definition]
 #Woot woot messages
 failregex = ^\[\w{1,3} \w{1,3} \d{1,2} \d{1,2}:\d{1,2}:\d{1,2} \d{1,4}] \[error] \[client 195.140.144.30] File does not exist: \/.{1,20}\/(w00tw00t|wootwoot|WootWoot|WooTWooT).{1,250}
 ignoreregex =

11
2017-08-19 17:46



Het is waar dat je ze kunt blokkeren, maar dat is niet nodig, omdat het gewoon slechte verzoeken zijn. Het is beter om ze gewoon te negeren, je te laten werken en je zult wat recources vrijmaken. - Saif Bechan
Rechts @Saif Bechan, als iemand zich zorgen maakt over dat "aanvallen testen" om succesvol te zijn, moet hij / zij beter de eigen applicatie repareren in plaats daarvan tijd verspillen om een ​​manier te vinden om dat te blokkeren. - Thomas Berger
Heeft u +1 gegeven, bedankt voor het antwoord. - Saif Bechan
@SaifBechan, ik ben het daar niet mee eens. w00tw00t is een kwetsbaarheidsscanner en een computer waarop dergelijke verzoeken worden gedaan, kan niet vertrouwd worden met andere soorten verzoeken, dus als ik een systeembeheerder ben en het mij 2 minuten kost om die clients dagenlang te verbannen, zou dat doen. Ik zou mijn hele beveiligingsimplementatie echter niet op zo'n benadering baseren. - Isaac


w00tw00t.at.blackhats.romanian.anti-sec is een hackpoging en gebruikt spoof-IP's, dus lookups zoals VisualRoute zullen China, Polen, Denemarken enz. rapporteren volgens het IP-adres dat op dat moment is gedetacheerd. Dus het instellen van een Weig IP of een oplosbare Hostnaam is bijna onmogelijk omdat het binnen een uur zal veranderen.


3
2018-06-01 11:20



Deze vulnerability-scans gebruiken geen vervalste IP-adressen. Als ze dat deden, zou de TCP 3-weg-handshake niet worden voltooid en zou Apache het verzoek niet registreren. Voor waarschuwingen (frauduleuze ISP, routeroperators, enz.), Zie security.stackexchange.com/q/37481/53422 - Anthony Geoghegan


Ik heb zelf een Python-script geschreven om IPtables-regels automatisch toe te voegen.

Hier is een enigszins verkorte versie zonder logboekregistratie en andere rommel:

#!/usr/bin/python
from subprocess import *
import re
import shlex
import sys

def find_dscan():
        p1 = Popen(['tail', '-n', '5000', '/usr/local/apache/logs/error_log'], stdout=PIPE)
        p2 = Popen(['grep', 'w00t'], stdin=p1.stdout, stdout=PIPE)

        output = p2.communicate()[0].split('\n')

        ip_list = []

        for i in output:
                result = re.findall(r"\b(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b", i)
                if len(result):
                        ip_list.append(result[0])

        return set(ip_list)

for ip in find_dscan():
        input = "iptables -A INPUT -s " + ip + " -j DROP"
        output = "iptables -A OUTPUT -d " + ip + " -j DROP"
        Popen(shlex.split(input))
        Popen(shlex.split(output))

sys.exit(0)

2
2018-03-24 07:06



Is dit om de w00tw00t-aanval te voorkomen - Saif Bechan
Ja, ik laat het de Apache-foutlogboeken scannen op eventuele "w00tw00t" IP's en deze toevoegen als ze niet bestaan, hoewel ik voor de eenvoud de controle voor duplicaten niet heb toegevoegd. - Xorlev
Dit script zou waarschijnlijk een tabel moeten gebruiken, het toevoegen van tonnen extra regels aan de iptables-ketens zal de verwerking behoorlijk vertragen. - Eric
Er wordt wel een tafel gebruikt. Ik heb er echter veel vereenvoudigd omdat het op mijn systeem was toegesneden. - Xorlev
denk je dat dit een betere oplossing is om mod_security te gebruiken - Saif Bechan


Ik denk dat de reden dat mod_security niet werkt voor jou is, omdat Apache de verzoeken zelf niet heeft kunnen analyseren, ze zijn buiten de specificaties. Ik weet niet zeker of je hier een probleem hebt - apache registreert rare rommel die op het net gebeurt, als het niet logt, zul je je niet bewust zijn dat het zelfs gebeurt. De middelen die vereist zijn om de aanvragen te loggen zijn waarschijnlijk minimaal. Ik begrijp dat het frustrerend is dat iemand je logs aan het vullen is - maar het zal frustrerender zijn als je het loggen alleen uitschakelt om te ontdekken dat je het echt nodig hebt. Zoals iemand in je webserver ingebroken heeft en je de logs nodig hebt om te laten zien hoe ze zijn ingebroken.

Een oplossing is om ErrorLogging in te stellen via syslog en vervolgens met rsyslog of syslog-ng specifiek deze RFC-overtredingen met betrekking tot w00tw00t te filteren en te verwijderen. Of u kunt ze in een afzonderlijk logbestand filteren, zodat uw hoofd ErrorLog gemakkelijk te lezen is. Rsyslog is in dit opzicht ongelooflijk krachtig en flexibel.

Dus in httpd.conf zou je het volgende kunnen doen:

ErrorLog syslog:user 

dan in rsyslog.conf heb je misschien:

:msg, contains, "w00tw00t.at.ISC.SANS.DFind" /var/log/httpd/w00tw00t_attacks.log

Houd er rekening mee dat deze benadering vaak wordt gebruikt Meer middelen dan oorspronkelijk gebruikte logboeken rechtstreeks naar een bestand. Als uw webserver erg druk is, kan dit een probleem worden.

Het is een goede gewoonte om alle logbestanden zo snel mogelijk naar een server voor logboekregistratie op afstand te sturen en dit zal u ten goede komen als u ooit wordt ingebroken, omdat het veel moeilijker is om het controletraject te wissen van wat er is gedaan.

IPTables-blokkering is een idee, maar u kunt eindigen met een zeer grote iptables-bloklijst die op zich implicaties voor de prestaties kan hebben. Is er een patroon in de IP-adressen of komt het van een groot gedistribueerd botnet? Er moet X% duplicaten zijn voordat u een voordeel van iptables krijgt.


2
2018-03-30 11:09



Leuk antwoord, ik hou van de verschillende benaderingen. Als je erover nadenkt, zal aangepaste logboekregistratie meer recourse-gebruik genereren, omdat alles eerst moet worden gecontroleerd. Ik vermoed dat deze optie er ook vanaf valt. Ik heb nu logwatch ingeschakeld. Dit stuurt me een rapport 2 keer per dag met samenvattingen van de hele systemen. De apache-logboeken worden ook gecontroleerd en er staat 300 keer een poging w00tw00t. Ik denk dat ik de installatie zal verlaten zoals het voorlopig is. - Saif Bechan


U zegt in Update 2:

Probleem dat nog steeds bestaat   Het probleem dat nog steeds bestaat, is als volgt. Deze aanvallen komen van bots die zoeken naar bepaalde bestanden op uw server. Deze specifieke scanner zoekt naar het bestand /w00tw00t.at.ISC.SANS.DFind :).

Nu kunt u het gewoon negeren, wat het meest wordt aanbevolen. Het probleem blijft echter dat als je dit bestand op de een of andere manier ooit op een dag hebt staan, je problemen hebt.

Uit mijn vorige antwoord bleek dat Apache een foutmelding terugstuurt vanwege een slecht geformuleerde HTML 1.1-vraag. Alle webservers die HTTP / 1.1 ondersteunen zouden waarschijnlijk een foutmelding moeten geven als ze dit bericht ontvangen (ik heb de RFC niet dubbel gecontroleerd - misschien laat RFC2616 ons weten).

Hebt w00tw00t.at.ISC.SANS.DFind: op uw server betekent sommige waar niet mystiek "u zit in een probleem" ... Als u het bestand w00tw00t.at.ISC.SANS.DFind: maakt in uw DocumentRoot of zelfs DefaultDocumentRoot maakt niet uit ... de scanner stuurt een gebroken HTTP / 1.1-verzoek en apache zegt "nee, dat is een slecht verzoek ... vaarwel". De gegevens in het bestand w00tw00t.at.ISC.SANS.DFind: worden niet weergegeven.

Mod_security gebruiken voor dit geval is niet nodig, tenzij je het echt wilt (geen punt?) ... in welk geval je kunt kijken of je het handmatig wilt patchen (link in een ander antwoord).

Een ander ding dat je eventueel zou kunnen gebruiken, is de RBL-functie in mod_security. Misschien is er een RBL online waarvan sommige w00tw00t IP's (of andere bekende kwaadaardige IP's) biedt. Dit zou echter betekenen dat mod_security een DNS-lookup uitvoert voor elk verzoek.


1
2018-03-31 08:52



Ik denk niet dat apache ze afwijst, het gooit gewoon de fout maar de lookup gaat nog steeds over. Ik heb dezelfde w00tw00t.at.ISC.SANS.DFind in het toegangslogboek. Het doet GET. Dus de opzoekprocedure is voltooid en als u het bestand op uw computer hebt, wordt het uitgevoerd. Ik kan de toegangslogboekvermeldingen plaatsen, maar ze zien er hetzelfde uit als het foutenlogboek alleen met een GET ervoor. Apache gooit de fout maar het verzoek verstrijkt. Daarom vroeg ik of het een goed idee zou zijn om deze aanvraag zonder hostnamen te blokkeren. Maar ik wil normale gebruikers niet blokkeren. - Saif Bechan
Natuurlijk krijg je hetzelfde item in het toegangslogboek maar kijk je naar de foutcode ... 400. Het is niet verwerkt. HTTP / 1.1 (hostnaam) wordt gebruikt om apache te vertellen welke virtuele host de aanvraag moet verzenden naar ... zonder dat het hostnaamgedeelte van de HTTP / 1.1-verzoekapache niet weet waar de aanvraag naartoe moet worden verzonden en de foutmelding "400 ongewenst verzoek" wordt geretourneerd terug naar de klant. - Imo
Probeer het zelf ... creëer jezelf een html-pagina op je webserver en probeer het handmatig te doen met "telnet hostname 80" ... de andere stappen staan ​​in mijn eerste antwoord. Ik zou er een grote bounty op zetten dat je het html-bestand niet kunt laten weergeven met HTTP / 1.1 zonder de hostnaam. - Imo
Ah ja ja dat voor het wijzen naar mij. Ik dacht altijd dat de access_log vermeldingen waren die werden doorgegeven via het foutenlogboek en daadwerkelijk in je machine werden ingevoerd. Bedankt dat je me dit hebt laten weten en ik zal mijn bericht bewerken. Ik stel je hulp zeer op prijs. - Saif Bechan
Hallo Saif, geen problemen, blij dat ik heb geholpen. Met vriendelijke groet, Imo - Imo


Hoe zit het met het toevoegen van een regel aan modsecurity? Iets zoals dit:

   SecRule REQUEST_URI "@rx (?i)\/(php-?My-?Admin[^\/]*|mysqlmanager
   |myadmin|pma2005|pma\/scripts|w00tw00t[^\/]+)\/"
   "severity:alert,id:'0000013',deny,log,status:400,
   msg:'Unacceptable folder.',severity:'2'"

1
2017-08-09 08:23





Ik zie dat de meeste oplossingen hierboven al worden behandeld, maar ik wil er graag op wijzen dat niet alles client verzonden HTTP / 1.1-verzoek zonder hostnaam aanvallen richten zich rechtstreeks op uw server. Er zijn veel verschillende pogingen om het netwerksysteem voorafgaand aan uw server te fingerprinten en / of te exploiteren, dat wil zeggen:

client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /tmUnblock.cgi

om de Linksys-routers te targeten, enz. Dus soms helpt het om je focus te vergroten en je verdedigingsinspanningen te verdelen over alle systemen met een gelijk aandeel, dat wil zeggen: implementeer routerregels, implementeer firewallregels (hopelijk heeft je netwerk er één), implementeer serverfirewall / IP-tabel regels en aanverwante diensten dwz mod_security, fail2ban enzovoort.


1
2017-10-08 18:10