Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 128 reacties

Een beveiligingsonderzoeker heeft een tool uitgebracht waarmee Apache-servers op de knieŽn kunnen worden gekregen. De hacktool Slowloris zou dit weten te bereiken door de webserver te bestoken met 'oneindige' http-requests.

De tool verstuurt incomplete http-requests naar een Apache-server en blijft deze 'aanvullen' met nieuwe gegevens, zodat de webserver gedwongen wordt om voor elke aanvraag min of meer permanent een socket te reserveren. Op deze manier worden de resources van een Apache-server langzaam maar zeker uitgeput, waarna geen nieuwe http-requests meer kunnen worden verwerkt. Uit een test door onze servergoeroe Kees bleek overigens dat 'langzaam' een relatief begrip is: hij wist een Apache-server met de tool in enkele seconden om zeep te helpen.

Hansen noemt een aanval met Slowloris - die met slechts een enkele machine kan worden uitgevoerd - een slow denial of service attack, omdat het enige tijd kan duren voordat alle sockets op een Apache-server zijn bezet. Hij benadrukt echter dat het niet gaat om een klassieke tcp-dos-aanval, waardoor een specifieke virtuele webserver kan worden aangevallen, zonder dat de machine die de server huisvest, daar last van heeft. Volgens de beveiligingsonderzoeker zijn met name Apache-servers die gebruik maken van threading kwetsbaar, omdat het aantal threads beperkt is. Slowloris kan bovendien de inhoud van de host-headers variëren, waardoor aanvallen minder makkelijk in de logbestanden ontdekt zullen worden.

Met een aanval van Slowloris wordt door Hansen een kwetsbaarheid in Apache blootgelegd die volgens hem veroorzaakt wordt door structurele ontwerpfouten in de opensource-webserver. Ook kan de configuratie van Apache volgens hem onvoldoende worden aangepast om dergelijke aanvallen met succes af te slaan, al liet Apache weten dat er mogelijkheden zijn om de aanvallen minder effectief te maken. Dat kan echter wel ten koste van de functionaliteit van de server gaan. Het SANS-instituut laat weten dat er met behulp van de Perlbal-reverse proxy wel een effectieve verdedigingswal kan worden opgeworpen.

De publicatie van Slowloris is van diverse kanten bekritiseerd omdat de beveiligingsonderzoeker nieuw hackgereedschap aan kwaadwillenden ter beschikking stelt. Hansen meent echter dat de ontwikkelaars van webservers beter moeten gaan nadenken over het probleem. Bovendien zouden de Apache-ontwikkelaars voldoende op de hoogte zijn van de kwetsbaarheden in het ontwerp. Dat kan kloppen, zegt ook Kees: "Dit is al jaren bekend. De vraag is vooral hoeveel mensen het nu gaan uitproberen."

Moderatie-faq Wijzig weergave

Reacties (128)

Voor de Ubuntu/Debian'ners onder ons even een snelle tijdelijke IPtables + Cron + Netstat fix (zelfde idee als Leaseweb)

sudo -i
cd /tmp/
wget http://hosting.servxs.net/files/install-antiloris.sh
/bin/sh install-antiloris.sh
exit

Code:
Install script
Antiloris script

[Reactie gewijzigd door wietse.cc op 20 juni 2009 01:39]

Enigzins een lapmiddel, maar inderdaad effectief. Er zit wel een schoonheidsfoutje in het script;
RESPONSE=`iptables -L |egrep "$ip"`
moet zonder resolving;
RESPONSE=`iptables -n -L |egrep "$ip"`
Eens, maar inderdaad effectief. Ik heb inmiddels (sinds gisteren) 19 IP's in IP tables staan door dit scriptje.

Dank voor de tip, ik heb de 'source' aangepast.
Ik bekijk 't install script net en zie dit:
echo "# Anti Loris Attack" >> /etc/crontab
echo "* * * * * root /bin/sh /bin/antiloris" >> /etc/crontab
echo "* * * * * root sleep 15; /bin/sh /bin/antiloris" >> /etc/crontab
echo "* * * * * root sleep 30; /bin/sh /bin/antiloris" >> /etc/crontab
echo "* * * * * root sleep 45; /bin/sh /bin/antiloris" >> /etc/crontab
Sorry, maar dat kun je toch echt niet maken hoor ...

Edit:
Om hier nog maar over te zwijgen:
ISINCRNTB=`more /etc/crontab |egrep "antiloris"`

[Reactie gewijzigd door tomhagen op 20 juni 2009 14:30]

'more' aangepast naar 'cat' en sleep is misschien niet de mooiste oplossing, maar eens in de minuut vind ik toch iets te weinig.

Eh "dat kun je echt niet maken": het doet zijn werk, en als je het liever anders doet: je hoeft het niet te gebruiken :)
'more' aangepast naar 'cat'
Ah, je gaat voor de "useless use of cat"-award? ;-), Je kunt 't, m.i. mooier zo oplossen:
ISINCRNTB=`grep antiloris /etc/crontab`
Echter gaan we er hier wel vanuit dat alles in /etc/crontab staat en niet in, bijv. /var/spool/cron/crontabs/$USER. Mooier is dan ook om crontab zelf de contents maar te laten tonen:
ISINCRNTB=`crontab -l | grep antiloris`
sleep is misschien niet de mooiste oplossing, maar eens in de minuut vind ik toch iets te weinig
`man 5 crontab`. Niemand weerhoudt je om ranges te gebruiken. Het maakt 't in ieder geval een stuk schoner en leesbaarder. Verder kun je /bin/sh ook al weghalen, je hebt immers antilors al een +x gegeven.

De plaats van 't script in /bin/ vind ik ook nog discutabel. Ik zou 't zelf eerder in /usr/local/sbin dan wel /usr/local/bin gooien.

Anyways, om 't wat generieker te maken, zou ik zoiets doen (not tested!)
(crontab -l; echo "*/15 * * * * /bin/antiloris") | crontab -
Hiermee laat je crontab zelf 't werk opknappen en met de /15 geef je aan dat 't iedere 15 seconden moet gebeuren. Je mag natuurlijk ook "0,15,30,45 * * * * ..." gebruiken, mocht je dat fijner vinden.
Van leaseweb kreeg ik hierover ook al een email.
Zij hebben een script gemaakt wat continue netstat check, en ip's met een count > 50 in iptables zet.

script laten ze draaien via de crontab.
wget -O /usr/local/sbin/antilotis.sh http://www.leaseweb.com/antiloris.sh

chmod 755 /usr/local/sbin/antilotis.sh

echo \"* * * * * /usr/local/sbin/antilotis.sh\" >> /etc/crontab
nadeel daarvan is wel dat iptables gelimiteerd is tot de hoeveelheid geheugen in je machine.

dus, wellicht geen DoS op apache, maar omdat je geheugen vol zit, wel een DoS op de rest :)
Een ip adres is 4 bytes. er zijn 4,294,967,296 adressen.

Oftewel alle ip adressen in je geheugen zetten zou 16 Gigabyte kosten. Er gaat natuurlijk nog wel wat overhead bij en bepaalde ranges weer af. Een groffe schatting alle adressen in iptables levert je 32Gb op. (theoretisch, gaat in het echt niet lukken)

Voor een gemiddelde host met 1 gb is het eigenlijk geen probleem. Er gaat wat af voor je os enz. Laat er 512mb over zijn voor dit gedonder.
Dan kan je nog steeds 130 miljoen adressen blokkeren. Voordat je zover bent dat je os volledig op zijn nek gaat is je hacker al lang gestopt.
Of beter nog ben je zelf al lang gestopt omdat je gebruikers beginnen te klagen dat ze niet op je site (of andere diensten op de pc) kunnen komen vanwege het hoge aantal geblockte adressen.

note) als je hem plat wil hebben kan hij altijd plat. ik illustreer alleen dat het prima kan werken met blokkeren, maar dat het geen goeie structurele oplossing is. Zelf zou ik er overigens ook een timer opzetten (zeg 4uur blokkeren per adres)

[Reactie gewijzigd door siepeltjuh op 19 juni 2009 23:16]

Bij deze attack kun je geen IP's spoofen. De exploit zit in de http request en om die te kunnen versturen moet je de "syn, syn-ack, ack" handshake gedaan hebben.

Je hoeft dus geen rekening te houden met grote aantallen verschillende IP's. Het gaat hier om het maximale aantal poorten dat de server heeft. Dat zijn er "maar" 65536.
@daank: Ligt het nu aan mij of staat er een typo in dat script? Antilotis ipv Antiloris. :X

@arjankoole: Heb je enig idee hoeveel IP adressen er geblokkeerd moeten worden om al het geheugen van een webserver te hoggen? Ik denk dat de meeste servers aardig wat headroom hebben en niet met hun kop tegen het plafond zitten qua geheugengebruik. :)

[Reactie gewijzigd door Mike Post op 19 juni 2009 22:11]

@arjankoole: Heb je enig idee hoeveel IP adressen er geblokkeerd moeten worden om al het geheugen van een webserver te hoggen? Ik denk dat de meeste servers aardig wat headroom hebben en niet met hun kop tegen het plafond zitten qua geheugengebruik. :)
Nou, ik had een machine met 4GB geheugen (waarvan normaal gesproken 3GB vrij) in een half uurtje vol.

Als je echt met een individu te maken hebt die vervelend wil doen, zoals ik al een paar keer heb gehad, kom je met zo'n script niet ver :)
Als die 'individu' via ťťn IP adres werkt, dan gooi je z'n IP adres toch gewoon in een IP table en dan drop je toch gewoon al de gegenereerde traffic vanaf dat IP adres? Kijk, als ie een botnet heeft en deze tool gebruikt-- damn, wat omslachtig.. een botnet kan makkelijk anders DDoS'en, maar whatever-- dan is het een ander verhaal, dan gaat het om een hoop IP adressen.

Maar hoe krijg je in vredesnaam 4GB geheugen vol met IP tables?
die individue had een botnet ;)

nog even nagekeken, en het is van de 4GB, 1GB vrij. dan gaat het al wat makkelijker.
Zoals siepeltjuh aangeeft kun je met ongeveer 32GB aan geheugen ALLE mogelijke IPv4 adressen blokkeren. Ik neem aan dat die individu een botnet had van een paar honderd of duizend bots..

100 bots met 100 verschillende IP adressen = 100*4B = 400B.
1000 bots met 1000 verschillende IP adressen = 1000*4B = 4kB.

1000 bots zou dus 4kB vullen in jouw IP table. Het is dus onmogelijk dat die 1GB aan vrij geheugen vol is gemaakt door IP tables.
Yes .. je hebt gelijk :O .. zo gaat het natuurlijk nooit werken }:O
Is dit sarcastisch bedoeld of niet? Zo niet, dan is het misschien handig om even een email te sturen naar Leaseweb met een gecorrigeerd script. :)
was niet sarcastisch bedoeld, en heb leaseweb al een mail gestuurd hierover ;)
Reverse nginx proxy naar apache is makkelijker, voor PHP is het dan nog even handig om auto_prepend_file te gebruiken zodat $_SERVER[''REMOTE_ADDR"] geupdate wordt met de $_SERVER["HTTP_X_REAL_IP"] (die je nginx door laat sturen). En dan is je apache ook redelijk bestand.

mijn nginx config (standaard debian install met default site uit en deze site aan):

server {
listen 8080;
server_name foo.bar;

access_log off;

location / {
proxy_pass http://127.0.0.1:80/;
proxy_pass_header Server;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

}
}

En dan op de server nog even deze regel:
iptables -t nat -A PREROUTING -d ! 127.0.0.1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080

in php.ini:

auto_prepend_file = /etc/php5/proxyfix.php

/etc/php5/proxyfix.php:

<?php
if (isset($_SERVER['HTTP_X_REAL_IP']))
{
$_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_REAL_IP'];
unset($_SERVER["REMOTE_HOST"]);
}
?>

En verder geen veranderingen aan de config van apache.
Oke, dit is dus weer een andere dan degene die op Phrack ontdekt is. http://www.phrack.com/issues.html?issue=66&id=9#article Exploiting TCP Persist Timer Infinitenes. Overigens wel een Ddos maar waar nog geen patch voor te krijgen is, althans tot aan gistermiddag.

[Reactie gewijzigd door regmaster op 19 juni 2009 21:13]

Jammer dat dit nodig is om de developers weer even wakker te schudden. In princiepe zijn er altijd wel exploits te vinden maar door de release van deze POC scripts is het zonder enige moeite en kennis over de werking door iedereen te ge(mis)bruiken.

Valt me overigens op dat dit specifieke script nogal wat opschudding veroorzaakt. Kwam het vanmorgen al tegen op een gehackte server, om maar even aan te geven hoe snel zoiets zich verspreidt (script is 17e online gezet dus binnen 1 dag).

Mogelijke opties in Apache die enige bescherming kunnen bieden tot hier een patch voor bedacht is:

- LimitRequestFields
- LimitRequestFieldSize

Hier overigens een lighttpd gebruiker, gelukkig zelf dus geen last van.

[Reactie gewijzigd door thys op 19 juni 2009 21:55]

De IP-gebaseerde oplossingen zijn voor kleine aanvallen doeltreffend, maar als een aanvaller Tor aanzet ben je alsnog ver van huis.

Een duurzamere oplossing is om het onderdeel dat de verbindingpool beheert ook verbindingen te laten verbreken. Dit niet zozeer op basis van de ouderdom van een verbinding, maar vooral op de ouderdom van een enkele onvoltooide request. Als de client bijvoorbeeld vijf minuten geleden aan een GET-request is begonnen, maar deze nog steeds niet volledig geformuleerd is, kun je maar beter voorrang geven aan requests waarvan de formulering pas tien seconden geleden begonnen is. Er moet natuurlijk wel een minimum gesteld worden aan de leeftijd van een onvoltooide request voordat de verbinding weggesmeten mag worden.

POST- en PUT-requests (voor zover die laatste wordt gebruikt) is het weer een iets ander verhaal, aangezien die ook nog een hoeveelheid gegevens bevatten. Het laatste wat je wilt is om een upload van een groot bestand te blokkeren (zit je client aan de andere kant te vloeken als net 99% was geupt over z'n trage lijntje), maar er is dan haast geen beginnen aan om onderscheid te maken tussen bona- en malafide verzoeken.
Op FreeBSD heb je het httpready accept filter, een filter dat ervoor zorgt dat Apache alleen wordt lastiggevallen met volledige requests.

Wellicht dat het inschakelen van een dergelijk filter deze aanval (in ieder geval gedeeltelijk) kan voorkomen?
En het is inmiddels al wijd bekend dat deze attack op lang niet alle Apache-configuraties invloed heeft, dat dit gebrek al sinds de jaren negentig present was, en bovendien op te lossen is door oude connecties gewoon te kicken.
En toch heeft het invloed op een zeer groot scala aan apache configuraties, en natuurlijk kunje oude connecties gewoon kicken, maar voor je dat doet ben je al 'plat'. Het is gewoon kinderspel om apache op deze manier op de grond te krijgen, en jaren geleden hebben we het als serverbeheerders onderling ook wel eens over gehad 'hoe zouden wij het doen (en hoe kunnen we het voorkomen)' waarbij 'alle connecties vullen met een trage request' ook wel duidelijk een probleem kon zijn.

Natuurlijk kun je het bagitaliseren, maar feit blijft dat het een eenvoudige (is, en altijd al geweest) manier is om een server plat te leggen. Overigens was de manier waarop wij het van zouden doen nog iets vervelender en iets geavanceerder.
een DoS of DDoS is ook doodsimpel eigelijk :)

Ik heb er al weet ik het hoeveel voor m'n kiezen gehad, en ik wist ze doorgaans wel te counteren met wat slimme truukjes (in datzelfde apache).

het is eigelijk een potje high speed schaak.
Dan heb je het over "simpele DoS" attacks van (b.v.) wat script-kiddies en niet over "echt grote" (R)DDoS attacks, dat is een wereld van verschil. Grote attacks - via b.v. botnets - zijn een serieuze bedreiging voor de continuiteit van ISPs (waar je o.a. zelf ook ervaring mee hebt).

Want hoe ga je in Apache een request flood van b.v. 300 Mbps of 10000 requests/s vanaf vele duizenden source-IPs counteren als andere netwerk-devices overbelast worden en je server(s) niet/amper bereiken ?

Natuurlijk heb je allerlei load-balance, filter- en defensie-mechanismen, maar als een "netwerk bom" arriveert, dan los je dat niet zomaar 1.2.3. op zonder hulp van b.v. je (telco) upstream providers en/of allerlei slicke software/hardware/appliances, kennis en tijd. Die multi-10gbit $$$ border-routers van ISPs kunnen ook maar zoveel per seconden doen, en 1 "zwakke schakel/switch" is voldoende om de aanval te doen slagen.

Ontopic: Volgens mij is deze "hacktool" is gewoon een HTTP variant van het aloude PortFuck, dat aan "TCP socket starvation" deed en ookal vanaf 1 IP in luttele seconden een simpele (b.v.) 100Mbps web-server/applicatie kon lamleggen. Die tool werd echter vooral doodgezwegen en "geblacklist" (o.a. nu - 12 jaar later - nog steeds door sommige AVs) en kreeg niet zoveel positieve aandacht als Slowloris.

EDIT @arjankoole: ik doel niet op een apart beheer-netwerk ; ik bedoel "hoe gaan je servers pagina's aan je bezoekers serveren als je netwerk dicht zit en bezoeker-requests dus nooit aankomen". Dat jij op je beheer-netwerk aan de achterkant er geen last van hebt, is niet relevant. Je opmerking over de "kwaliteit van de hardware" is gewoon pure arrogantie, alle hardware heeft z'n breaking point.

[Reactie gewijzigd door SKiLLa op 20 juni 2009 15:04]

Want hoe ga je in Apache een request flood van b.v. 300 Mbps of 10000 requests/s vanaf vele duizenden source-IPs counteren als andere netwerk-devices overbelast worden en je server(s) niet/amper bereiken ?
De indeling van mijn netwerk en de kwaliteit van de hardware is dusdanig dat ik in dergelijke situaties ALTIJD bij m'n servers kan.

Denk maar eens goed na, hoe ik dan vervolgens de rest van de 'aanval' tackle.
Ik ben waarschijnlijk te dom, maar kun je een tipje van de sluier ophalen?
Don't bother, tegen doordachte (R)DDos (al zijn puur RDDOS aanvallen juist makkelijker te counteren) aanvallen doet arjan ook niets behalve in foetushouding huilen in een hoekje.
Dat hoeft natuurlijk niet waar te zijn. Als je een apart beheer lijntje hebt dan kun je in elk geval altijd bij je servers. Daarnaast heb je tegenwoordig deep inspection firewalls die wel degelijk in staat zijn om een groot deel van de DDOS aanvallen met rate control mechanismes te temperen. De denial of service werkt dan wel, maar alleen zolang de aanval echt stand houdt. Je server blijft netjes overeind en draait na de DDOS gewoon verder.

Natuurlijk is het een wedloop en komt er af en toe weer een nieuwe aanval om de hoek zetten, maar tegen de script kiddies, die zelf niks bedenken maar gewoon bestaande tools gebruiken om ellende aan te richten, kun je je goed beschermen.
Ik ben persoonlijk banger voor socketstress dan voor deze 'hoe zuig ik een toch aan trage webserver van het web af'-tool.
maar, mijn vraag is dan, kun je niet een module laden die het aantal incomplete conecties, vergelijkt met een aantal wel complete .. en vervolgens daarop bij een bepaalde afwijking van de baseline - een dropkick plaatst voor ALLE incomplete requests.. of desnoods naa een micro-timeout van enkele ms...
Dat is security vs useability. Wat altijd het geval is. Overigens is op de site van Robert Hansen (ook wel bekend als RSnake) meer te lezen. Ik denk dat hij in dit geval terecht heeft gereageerd op de laksheid van apache.

Zie

http://ha.ckers.org/blog/20090617/slowloris-http-dos/

Als je als apache arrogant genoeg bent om een complete proof of concept voor een aanval te beantwoord met een mail van 3 regels (waarin ook nog duidelijk wordt dat ze de plank helemaal mis slaan), tja...

En maar roepen dat apache geweldig is een iis kut...
"Als je als apache arrogant genoeg bent om een complete proof of concept voor een aanval te beantwoord met een mail van 3 regels (waarin ook nog duidelijk wordt dat ze de plank helemaal mis slaan), tja..."

Als ik dat bericht goed lees heeft Apache dit gewoon verkeerd begrepen, hun reactie ging over TCP DoS attacks en hij bedoelde een HTTP DoS attack. Als hij na het kortzichtige berichtje van Apache niets teruggestuurd heeft in de trant van "Je mist mijn punt", dan ligt wat mij betreft alle gevolgen voor het gebruik van dit progje bij de maker van de tool. Zij begrepen hem gewoon verkeerd. Hun reactie was volstrekt logisch als hij een gewone TCP DoS attack proof-of-concept had gezonden, daar kunnen ze ook niets tegen doen.

In zijn tekst geeft hij duidelijk aan dat hij denkt dat ze het verkeerd begrepen hebben, dus hij snapt goed wat er mis ging bij Apache. En laten we wel wezen, iedereen maakt fouten. Als hij daar hen niet op gewezen heeft is hij in gebreke, niet Apache.

Mijns inziens had hij veel meer kunnen doen voordat hij een dergelijk progje uitbracht.

[Reactie gewijzigd door Atsjie op 20 juni 2009 11:38]

Dat ben ik met je eens. Erg fijn dat mijnheer, omdat iemand bij Apache zijn mailtje verkeerd begreep, direct duizenden beheerders van servers die draaien op Apache maar verder weinig met Apache zelf van doen hebben met een probleem opzadelt. Hoezo, wie niet horen wil moet maar voelen? Degenen die het gaan voelen zijn de beheerders van de sites die plat gaan door deze tool. Maar dat zijn nu juist de mensen die niets aan het probleem kunnen doen. Way to go, Hansen... |:(
ach, Microsoft doet tenminste alsof het niet bestaat, en antwoord niet eens.

probleem is dat ook developers vaak security issues onderschatten, en systeem/netwerk engineers zijn al geen haar beter. dat is een menselijke zwakheid.

die tool publiceren zal wel wat actie tot gevolg hebben :)

In mijn ogen blijft Apache een stuk beter en flexibeler dan IIS, ook al kun je IIS misschien beter met een Tomcat of Jboss vergelijken.

[Reactie gewijzigd door arjankoole op 19 juni 2009 21:47]

Ach, gelukkig heeft IIS geen last van dit probleem, de tool is al door de hacker uitgeprobeerd op IIS maar IIS heeft er geen last van, deze gebruikt namelijk geen thread per request model.

Apache / IIS / Tomcat zijn vergelijkbaar maar ook niet helemaal omdat Apache voornamelijk statische pagina's levert (zonder configuratie van extra plugins). Tomcat kan JSP / Servlet aan en IIS volgens mij ook weer een taal.

De vergelijking met JBoss gaat helemaal niet op omdat JBoss een applicatie server is (en een web container) in tegenstelling tot tomcat wat alleen een webcontainer is.
Als je Apache (op Debian) standaard installeert, wordt mpm_worker gebruikt. Deze 'Multi processing module' (vandaar de MPM- prefix) is multithreaded (en multiprocess) en dus kwetsbaar voor deze hack. Echter, zodra je PHP installeert, is deze MPM niet meer bruikbaar en wordt overgeschakeld op mpm_prefork. Deze spawnt geen nieuwe thread voor elke request, maar doet een fork(). mpm_prefork kan wel nieuwe processen starten als het druk wordt, maar in de configuratie kan worden aangegeven hoeveel er child processess er maximaal mogen worden gestart. Als je die limiet niet te hoog zet, kun je ook de server (in zijn geheel, maar daar draait deze hack niet om) op de knieŽn krijgen.

[Reactie gewijzigd door Jaap-Jan op 20 juni 2009 09:16]

Jboss is net zoals Tomcat een applicatieserver (ongeacht wat voor termen je er aan hangt) en dat geld voor IIS (met .NET) ook.

Apache is een webserver, die ook scripting en cgi talen aankan (en C++ als je dat zou willen). Overigens hang ik bij voorkeur Apache voor Tomcat of Jboss, omdat je dan meer kan afconfigureren en afvangen.

Jboss en Tomcat zijn goed in java, maar slecht / inefficient qua zaken als css, js en image bestanden. (ja, ik weet het, er zijn webservers NOG meer efficient dan apache - dat is maar net waar je op standardiseert). Bovendien kun je in Apache een hoop dingen net wat beter inrichten waar nodig, die in Tomcat en Jboss echt niet kunnen.
Jboss is niet net zoals tomcat een applicatie server. Tomcat is een Webcontainer (in JEE termen), en JBoss is een applicatie server. Tomcat ondersteund geen EJB, JMS, e.d. wat je nodig hebt wil je jezelf een applicatie server noemen.

Apache is echt een webserver, die is inderdaad beter met leveren van statische content. Maar daar gaat dit bericht niet over.
Tomcat6 schijnt nogal wat sneller te zijn dan apache 2.2 met het worker threadmodel bij het serveren van statische files. Enige nadeel van Tomcat tov Apache is dat je webserver zo instabiel is als de slechtste applicatie die erop draait. Aangezien tomcat een applicatieserver is, wil het nog wel eens gebeuren dat een applicatie alle geheugen opvreet en daardoor tomcat in de soep draait.
Apache / IIS / Tomcat zijn vergelijkbaar maar ook niet helemaal omdat Apache voornamelijk statische pagina's levert (zonder configuratie van extra plugins). Tomcat kan JSP / Servlet aan en IIS volgens mij ook weer een taal.
En IIS levert standaard zonder uitbreidingen wťl dynamische pagina's wilde je zeggen? ;)

ASP(.NET, lichte versie geloof ik) die je bij IIS krijgt, is ook gewoon een DLL die geladen word binnen IIS alleen heeft MS dat al voor je gedaan en hoef je het niet zelf te doen.
Ik vraag me af of jullie (Only.Holoris en arjankoole) ooit daadwerkelijk contact hebben opgenomen met de security afdeling van microsoft of dat het gewoon "van horen zeggen" is omdat iedereen zegt dat het zo is.

Ik heb namelijk meerdere malen contact gehad (via mijn werk) en zij hebben daar mensen zitten die letterlijk 24/7 binnenkomende security issues checken (mits je natuurlijk een bekende/betrouwbare bron bent natuurlijk) en voor kritieke bugs zsm patches maken en vrijgeven.

Het fabeltje van jullie is al zo oud als windows 98 :p

Sterker nog, in dit geval heeft apache gereageerd met RTFM (oke niet letterlijke, maar dat was wel de strekking) :9

[Reactie gewijzigd door Data-base op 19 juni 2009 22:15]

(mits je natuurlijk een bekende/betrouwbare bron bent natuurlijk)
Tja, says it all eigenlijk. Als je dat dus niet bent (en dat is praktisch iedereen) gaan ze er ook niet op in. Je geeft dus zelf al aan waar de zwakte van Microsoft zit als ik jouw verhaaltje eventjes domweg analyseer. In dat geval vind ik de reacties van Onle.Holoris en arjankoole ook terecht.
op zich niet zo onlogisch
ik zit zelf op een afdeling waar veel klachten binnenkomen en als elke klacht zou moeten onderzoch worden is dat gewoon niet te betalen, dat kost te veel mankracht
perfect normaal dus dat ze klachten van bepaalde bron hoger op de prioriteitenlijst zetten
Er daarbij vallen grote enterprises (zoals gesuggereerd wordt) dus onder 'hoge prioriteit', omdat daar het grote geld zit. Microsoft blijft natuurlijk een profit organisatie, dus dat is vanuit hun perspectief niet meer dan logisch. Maar even ontopic, nu het behoorlijk bekend is hoe deze exploit werkt denk ik dat apache ook snel met een hotfix komt.
Ja, microsoft reageert werkelijk zo, ook nog tamelijk recentelijk.

je bent namelijk niet snel betrouwbaar in hun ogen als je geen dikbetalende enterprise klant bent.
Sorry hoor, tis wat offtopic maar:

@arjankoole:
je bent namelijk niet snel betrouwbaar in hun ogen als je geen dikbetalende enterprise klant bent.
Ik heb enkele maanden geleden een irritante (niet eens security gerelateerde) bug gemeld bij MS. Ik had al vrij snel contact met de product-manager van het product waar het om ging(WPF designer van Visual Studio in dit geval) en binnen enkele dagen had ik een test-patch om te kijken of het mijn probleem oplosde, wat het niet deed. Paar dagen later 2e test-patch en het probleem was opgelost. Binnen DAGEN het probleem opgelost. En dat zonder aan te geven wie ik was, gewoon per email, geen serials/klantcodes/contractcodes/wat_dan_ook hoeven door te geven.

Menig software bedrijf kan daar nog een stevig puntje aan zuigen!!

Ben soms wel eens anti-MS, maar hier was ik toch wel van onder de indruk.

[Reactie gewijzigd door beany op 20 juni 2009 00:51]

Zo heb ik hier ongeveer eenzelfde verhaal, ik zit nu al jaren in het Windows beta-team (al voor Longhorn/Vista), maar ik ben geen dikbetalende gebruiker o.i.d., toen ik erbij kwam was ik nog gewoon een thuisgebruiker met iets meer interesse voor computers (en programmeren een heeeel klein beetje).
Vind men het dan ook gek dat hackers deze tools de wereld in gooien?

Je ziet een groot probleem in belangrijke software, the maker reageert met drie zinnen.
Nou wie niet horen wilt die moet maar voelen dan.

Tja je kunt je er wel tegen wapenen maar hoeveel webservers zijn hiertegen goed geconfigureerd?
Denk wel minder dan 10%.

Zal de script ook even op mijn servers uittesten.
hoeveel bedrijven/beheerders werken met de instelling 'don't fix it if it ain't broken' (oid)
kan me voorstellen dat sommige servers jaren draaien zonder downtime (linux :+)
en dat men uit lakkigheid niet altijd de vereiste updates/fixes doorvoeren
dat is niet een probleem dat apache kan oplossen/dient op te lossen.
Niks mis met die instelling toch?
Sterker nog: wat valt er te fixen aan iets dat niet kapot is?
Een server die jaren draait zonder downtime doet precies wat zo'n server moet doen.
Ik heb meer downtime gezien door "vereiste" updates/fixes dan door DDOS aanvallen.
Oud nieuws.

Apache gaat niet plat alleen tijdelijk zijn er geen connecties meer beschikbaar.

Oplossing o.a. mod_limitipconn.
Naast tcp/ip stack hardening en FW/IDS/IPS.
Voor wie interesse heeft:

http://dominia.org/djao/limitipconn.html

Werkt alleen goed als Keepalive uit staat (anders: false positives mogelijk)

Of:
# apt-get install libapache-mod-limitipconn
# a2enmod limitipconn

... En dan je vhost of apache config aanpassen ;)

== EDIT==
Blijkt volgens comments op de site (http://ha.ckers.org/slowloris/) niet te werken.

[Reactie gewijzigd door wietse.cc op 20 juni 2009 10:58]

Je kan het denk ik beter filteren met een Hardware Firewall die maxconnecties per Ip restrict.
Tevens staan er bij veel artikelen meerdere bronnen hoe je het kan disablen.
Veel noemen het ook een storm in een glaswater.
Maarja, zolang Kees zijn servers protect vindt ik het niet erg :+
Waarom een Hardware Firewall? iptables will do :)
Ik heb meer vertrouwen in een hardware firewall die dedicated is. Een server preformed gewoon minder. Kan ook mijn Windows minded zijn dat je liever een hardware firewall gebruikt. Maar ik zou het IIG niet zelf door de server willen laten afhandelen.

@ hieronder :
Ik heb het over een dedicated doos, ik heb het nergens over OS'en of iets anders ;)
Een PFsense bak die het afhandelt voldoet ook, zolang maar niet alles direct op een webserver komt.
Geef dat teveel verkeer en dan creŽer je een Denial of service.


En het ligt ook vooral aan het budget.
Met een juniper is er gewoonweg meer mogelijk dan IPtables.
Maar dan moet je wel je remotewebserver (vanaf de buitenwereld) dichthebben.
Iets met een Apache lek :+

[Reactie gewijzigd door LuckY op 19 juni 2009 21:57]

Juniper = FreeBSD ;)
Ja maar als je een probleem hebt met je IPtables, staat er dan ook een support team klaar die je case nabouwt en helpt waarnodig.
Begrijp me niet verkeerd iedereen heeft een eigen mening, ik kies liever voor een Known merk.
En niet dat het altijd beter is, er zijn momenteel ook genoeg exploits voor juniper om reboot en fysiek compleet te firmware te overschrijven met gedeeltelijk eigen brouwsel.
Alleen aan een Compleet os als freeBSD kan meer kapot gaan en er is meer te exploiten, zowel software matig als hardware matig.
Tuurlijk zijn er cases waar zo een server beter in is, maar er zijn ook cases waar het niet goed gebruikt kan worden.

En het gaat om het doel(stabiele en veilige omgeving draaien), niet om de manier om naar het doel te komen(windows/linux/BSD/apple).
Ja maar als je een probleem hebt met je IPtables, staat er dan ook een support team klaar die je case nabouwt en helpt waarnodig.
Dan zou ik me als ik jou was maar eens gaan verdiepen in de ICT sector. Er zijn heel veel bedrijfjes op security gebied die de nodige oplossingen aanbieden inclusief support. Zo kun je zonder problemen een iptables (wat overigens een Linux oplossing is en helemaal niets met FreeBSD te maken heeft aangezien het er niet eens op werkt; we hebben het hier dan over pf en/of ipfw) support contractje afsluiten bij zo'n toko. Dan heb je in principe hetzelfde verhaal als zo'n bak van Juniper of welk bekend merk dan ook. Nou moet je er ook wel bij vertellen dat de support van bepaalde firewall firma's (Netasq is zo'n mooi voorbeeld) van een dermate niveau is dat je eigenlijk helemaal niets hebt (ze willen je niet helpen). Kwaliteit van zo'n support contract is ook erg belangrijk: hoe hard lopen die lui waar je de support hebt uiteindelijk voor je?

Afgezien hiervan zullen heel veel zaken prima op te lossen zijn door eigen kennis. Zo'n supportcontract is handig voor als je er net niet uit komt op die wijze of omdat het apparaat defect is.

Overigens zijn veel van die firewall fabrikanten nogal fervent gebruiker van open source producten die je als gewone consument ook kunt gebruiken. Datzelfde geldt ook voor de hardware. Je betaald zo'n firewallfabrikant dus domweg om de hardware plus de software te mixen tot 1 handig apparaat met de mogelijkheid voor een supportcontract. Dat kun je ook zelf doen en dan zul je met een even stabiele en veilige omgeving kunnen komen (de hardware en software verschillen immers niet bepaald). Hou je als enige verschil nog de support en de specifieke zaken van zo'n firewall over (denk hierbij aan een handige interface om dingen in te stellen). Niet bepaald zaken die erg veel bijdragen aan een stabiele en veilige omgeving, wel zaken die bijdragen aan het afvangen van risico's en dingen als beschikbaarheid.

Je bent nu die dedicated firewallkastjes als silver bullet aan het presenteren t.o.v. de wat meer homebrew dingen. Moet je niet doen aangezien de tools die men gebruikt hetzelfde zijn. Ze doen op technisch gebied niet voor elkaar onder.
@Arjankoole
een probleem los je zelf op vind ik. Ik ben self-supporting.

Ik kan een BSD bak zo uitkleden dat ie zowat nog kaler is dan je juniper. Niet dat een juniper niet goed is, ik ben gek op die dingen, maar ik kan het met de hand ook.

ik ga er niet vanuit dat 'een merk' per definitie betekend dat het goed is, soms wel, soms kan ik het beter (een factor 20 beter zelfs).
Wat jij kan hoeft niet iedereen te kunnen ;)
Toch heb ik er wel respect voor dat je het kan.
@PPL
Gedeeltelijk ben ik het met je eens, er zijn inderdaad toko;s die het supporten maar hoe goed is die kennis werkelijk(en hoe goed is de kennis bij juniper of cisco).
Het voordeel van een bekend product is updates die gemaakt worden (als de gemaakt worden) voor lekken die kenbaar gemaakt zijn (als ze kenbaar gemaakt zijn) daar zitten engineers achters en testers en al die meuk.

(het volgende gaat over homebrew op iptables/pfsense (en ja ik weet dat het unix en linux is) ik heb er zelf ook mee getest) Als jij een eigen homebrew draait op/over iptables en er zit een lek in dan ben je screwed als je het zelf niet kan vinden. En dan kan jij bij juniper een fix eisen (supportcontract+reclame contract enzo) Bij zo een firma heb ik altijd mijn twijfels, als ze zo goed zijn waarom zijn ze dan nog zo klein.
Als jij een Juniper engineer neemt en die draagt een JNCIS-FWV titel dan mag je verwachten dat hij kennis heeft van producten. Zover ik weet heb je geen PFsense of Iptables Certification. En TBH vergelijk ik eigenlijk iptables met een windows firewall (als je kijkt naar windows, ook al weet ik dat iptables _veel_ meer kan) en Pfsense zou ik dan vergelijken met ISA.

Maar waar je ook van uit moet gaan, niet iedereen heeft die kennis. Ik denk dat iets van 6/10 beheerders Windows minded is (heeft verder hier niks mee te maken) maar die snappen/weten niet hoe je een Pfsense/Iptable doos configureert. Die huren dan liever een gerenommeerd bedrijf in die gerenommeerde merken levert.
Ze doen op technisch gebied niet onder van elkaar. Dat klopt inderdaad maar toch nemen ze het to the next level met extra's zoals je al beschrijft.
En zoals ik al eerder zei : Ieder ze eigen mening (en het recht om die te verdedigen :+).

Waarschijnlijk kijk ik er over andere jaren heel anders tegenaan. maar momenteel zijn mijn ervaringen met Cisco/Juniper beter dan die van PFsense.
Maar het enigste wat ik bedoelde aan het begin was zoals jjkewl zegt :dat je de ellende aan de deur wil hebben en niet achter de deur.

En hoe je dat bereikt maakt niet uit ;)

Moeheid slaat toe, neem het niet persoonlijk op ;) en als ik wartaal uitslaat correct me when im wrong!

[Reactie gewijzigd door LuckY op 20 juni 2009 01:17]

Het voordeel van een bekend product is updates die gemaakt worden (als de gemaakt worden) voor lekken die kenbaar gemaakt zijn (als ze kenbaar gemaakt zijn) daar zitten engineers achters en testers en al die meuk.
Dat is bij opensource ook hoor. Een bug wordt geproduceerd, nagejaagd, gepatched, getest en DAN pas komt de patch in het opensource product.

En als het een grove security issue is (zoals dit met apache) is er soms dezelfde dag al een nieuwe versie inc fix. Dan moet het nog wel door de distro's heen in het geval van Linux, wat ook weer tijd vergt. (een zwakke plek van Linux, vind ik persoonlijk)
Maar waar je ook van uit moet gaan, niet iedereen heeft die kennis.
maar die zouden ze wel moeten hebben in dit vak. Je kunt niet leunen op anderen, je moet het zelf kunnen in eerste instantie. Die mentaliteit moet vind ik echt drastisch om.
@ Guru Evi
Je hebt geen certificaten nodig om een goede firewall constructie op te zetten intern.
Alleen als je een extern bureau inhuurt, heb jij zin om 10x150 euro uur loon te betalen voor een prutser? Of heb je liever 12x150 euro uurloon voor iets dat wel goed opgezet wordt.
Veel IT'ers zijn bang om in hun organisatie over te stappen op alternatieve OS'en (linux,BSD).En tja een sonicwall oid opzetten is inderdaad niet moeilijk. Hell dat heb ik zelf een aantal keer gedaan terwijl ik (nog)niet echt, super veel van firewalls weet.

@ Arjankoole 10.15:
Nodig? Noch ik noch m'n collega's zijn gecertificeerd, en ik denk dat wij toch een zeer fraaie cisco opstelling hebben hoor :) (en ook echt niet voor een klein bedrijf)
Tuurlijk is het mogelijk ik draai zelf ook een mooie ISA setup al zeg ik het zelf, en ik ben ook niet gecertificeerd. Alleen je moet een verschil hebben tussen 2 beheerders.
Degene die intern zitten en degene die naar klanten gaan. Certificatie is geen must, maar als jij een aanbesteding wilt doen van de nederlandse regering kijken ze daadwerkelijk naar (alle) certificaten van alles medewerkers ook die er niks mee temaken heeft. Dan wordt het toch wel belangrijk.

@ Arjankoole 10.19

Jij hebt het hier over een product gesupport door de community, en ik had het over een homebrew. Ik heb zelf een kleine ervaring met linux (draai het op laptop en denk zo een 10 servers ingericht(geen netbook meuk maar zelf voor gekozen)) Linux heeft voor mij voor en nadelen die ik niet ga noemen om offtopic te gaan.
Maar waar je ook van uit moet gaan, niet iedereen heeft die kennis.

maar die zouden ze wel moeten hebben in dit vak. Je kunt niet leunen op anderen, je moet het zelf kunnen in eerste instantie. Die mentaliteit moet vind ik echt drastisch om.
Ik probeer persoonlijk zoveel mogelijk bij te leren, maar als je een leerprocess hebt, kan je dan garanderen dat alles perfect veilig is? En nog sommige bedrijven hebben geen interne beheerders die besteden _alles_ uit.
Men kan niet _alles_ weten, hell anders hadden we geen verschillende beroepen.
Maar ik begrijp wat je bedoelt, maar voor educatie en studie is tijd nodig. Tijd is geld, als jij niet die mogelijkheden krijgt. zit er een organisatie fout.
Ik vind het altijd enorm sterk dat je een certificatie nodig hebt om een firewall op te zetten.

Er zijn bepaalde mensen die die producten nodig hebben (zoals bedrijven of misschien zelfs sattelietkantoren die geen (competente) IT persoon hebben) maar als je een uitgeklede linux-doos krijgt met iptables (zoals SonicWall, CheckPoint en de goedkopere versies van 'grote' merken) dan denk ik dat menig systeembeheerder dit toch wel zelf zou moeten kunnen.

Voor een groter bedrijf (zoals in mijn geval) ga je toch wel voor de betere hardware geintegreerd met andere systemen zoals een Intrusion Detection/Protection en Network Management (IBM, Cisco).
Ik vind het altijd enorm sterk dat je een certificatie nodig hebt om een firewall op te zetten.
Nodig? Noch ik noch m'n collega's zijn gecertificeerd, en ik denk dat wij toch een zeer fraaie cisco opstelling hebben hoor :) (en ook echt niet voor een klein bedrijf)
een probleem los je zelf op vind ik. Ik ben self-supporting.

Ik kan een BSD bak zo uitkleden dat ie zowat nog kaler is dan je juniper. Niet dat een juniper niet goed is, ik ben gek op die dingen, maar ik kan het met de hand ook.

ik ga er niet vanuit dat 'een merk' per definitie betekend dat het goed is, soms wel, soms kan ik het beter (een factor 20 beter zelfs).
Als je problemen hebt met IPtables dan staat Google tot je beschikking. Ook heb ik liever software die ik zelf kan debugen en fixen dan een zwarte doos van een duur merk. Noem mij para maar ik wil precies weten wat er in en uit gaat en hoe.

Maar ik ben het wel met je eens dat je de ellende aan de deur wil hebben en niet achter de deur. Dus ik heb wel m'n firewalls op eigen hardware draaien.
En raad eens wat er op het gros van die 'hardware' firewalls draait? Juist, een OS. Doorgaans is dat een (al dan niet aangepaste) Linux of BSD variant. ;)

Edit: Ik heb het dus over een dedicated doos, waar jij op doelt.

[Reactie gewijzigd door warp op 19 juni 2009 21:53]

Om de heel simpele reden dat bij een software firewall, de hacker al op je server zit voordat ie geblocked word.
Tja, hardware firewall, vertel dat maar aan de hobbyist met een LAMP servertje die ineens plat ligt omdat iemand hem vervelend vind. Die gewoon een redelijk default prefork config draait, of vrijwel elke default config met maxclients op 255.

Storm in een glas water voor de grotere sites, maar het kan erg vervelend zijn voor een kleinere site die niet de capaciteit of mankracht heeft om erop te letten; laat staan de duizenden virtueel gehoste servers die expres met een laag aantal max clients geconfigged staat.

Ach ja, het Blaster worm was ook eenvoudig te verhelpen door je windows up to date te houden, zie hoe dat ging.
Wat is er zo super aan een hardware firewall? Meeste 'hardware firewalls' hebben een instance van iptables draaien :O
Hardware firewall? Installeer Squid als front-side-proxy. Dat gebruik ik al jaren om bijvoorbeeld de bandbreedte van crawlers in te perken en andere malheur buiten te houden. Vooral Google had/heeft (?) er een handje van om de server maximaal te belasten.

Edit: net even getest. Het lukt niet om de server plat te krijgen. Ik zie ook (netstat -n) dat de meeste verbindingen worden afgesloten. Geen idee of dat aan de ADSL router ligt (de meeste ADSL routers hebben een beperkte NAT tabel = beperkt aantal simultane verbindingen) of aan de server zelf.

[Reactie gewijzigd door ncoesel op 20 juni 2009 09:37]

ik begrijp de gevolgde werkwijze niet zo goed. Ten eerste lijk het op die manier openbaar maken van de kwetsbaarheid te interpreteren als medeplichtigheid aan misbruik, ten tweede zou het aandragen van mogelijke oplossingen, wat gezien het open bron karakter van de bedoelde software, perfect mogelijk is, een veel positievere benadering zijn, dan dit spelletje "eigen schuld dikke bult".
Ik heb ook weleens lekken of misbruikbare features gerapporteerd bij o.a. Parallels. Op elke webserver die Plesk draait kan ik root krijgen als ik een beetje mijn best doe. Zeg jij maar wat ik moet doen, vorig jaar rond deze tijd heb ik het gerapporteerd. Nu heb ik het erg druk, maar ik ga er ook ernstig over denken om maar te "dreigen" het gewoon in de openbaarheid te gooien.

Hetzelfde geldt voor nog wel meer software. Lang niet alle developers nemen anderen serieus, vooral niet als ze niet begrijpen wat de potentiŽle impact kan zijn op hun software. En ook bij de grootste softwarefabrikanten lopen zulke jongens rond die niet willen toegeven dat ze misschien iets over het hoofd zien of onderschatten.
dreig daar gerust mee, laat ze vooral zien (proof of concept) hoe je 't doet.

als ze dan nog niet luisteren, laat ze maar voelen.

Maar laat het wel onafhankelijk verifieren door iemand die je vertrouwd :)

[Reactie gewijzigd door arjankoole op 20 juni 2009 10:26]

Ach, maak een Perl script en zet het op milw0rm. Even ernaar linken en een mailtje naar de makers van Plesk.. en dan denk ik wel dat ze van gedachte veranderen. Eventuele uitleg over het script en (financiŽle gevolgen) van het niet dichten van die exploit zou misschien ook handig zijn voor de developers.
Dit noemen ze nou Proof of Concept.. en eerlijk gezegd zie ik het niet als "eigen schuld, dikke bult". De developers worden nu gewoon geforceerd deze exploit te fixen-- en deze exploit is er al ken ik al maanden (zo niet, langer), dus eigenlijk hadden ze allang aan een fix kunnen beginnen. :>

Misschien hebben ze dat ook wel gedaan, dat weet ik niet, maar "eigen schuld, dikke bult", daar ben ik het niet mee eens.

Misschien is het wel zo (en zeker als ik bovenstaand artikel lees) dat er gigantische lappen code herschreven moeten worden en is het geen makkie. ;)

[Reactie gewijzigd door Mike Post op 20 juni 2009 22:49]

Dit is al mogelijk sinds de allereerste versies van Apache, het is niet alsof het een recente fout/exploit is, het is al jaren bekend, en ik heb al meerdere DDoS'sen gezien die op zo'n manier werken; alleen werden die niet in de openbaarheid gebracht.
hij heeft apache gewaarschuwd en werd niet serieus genomen.

ik denk dat ie nu wel serieus genomen wordt.

een onderzoeker heeft haast de plicht om z'n onderzoek openbaar te maken, zodat iedereen profijt heeft :)
Tja, als ik het bericht lees heeft hij dat gedaan, maar schijnbaar hebben de mensen achter apache geen zin om te luisteren of mee te denken of gewoon bedankt te zeggen en er wat mee doen..

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True