Bekijk Volledige Versie : Apache banners, ze staan bijna overal aan?
Hallo,
Ik heb in mijn Firefox de leuke ServerSpy plugin, hiermee kan ik direct zien welke webserver software een website draait.
Ik zie echter bij bijna iedereen de ServerTokens op Full staan, dit is default in Apache.
Vervolgens zie ik staan:
Apache/1.3.37 (Unix) mod_ssl/2.8.28 OpenSSL/0.9.7a PHP/4.4.7 mod_perl/1.29 FrontPage/5.0.2.2510
Dat is geweldig! Apache 1.3.39 is al uit en er zijn enkele exploits voor 1.3.37 bekend.
Ik hoef dus alleen een sniffer te maken die gaat zoeken naar oude Apache versies en klaar ben ik :)
Het is heel simpel uit te schakelen, zet in de httpd.conf:
ServerTokens Prod
Apache al nu alleen nog maar "Apache" terug geven, geen versie nummers.
Ook is het raadzaam om in de php.ini "expose_php" op "Off" te zetten, anders zal PHP ook altijd de volgende header uit sturen:
X-Powered-By: PHP/4.4.7
Niemand hoeft toch te weten welke versie Apache of PHP je draait?
Hebben veel partijen dit aan staan omdat ze het bestaan van deze opties niet kennen? Omdat het ze niet boeit of om andere redenen?
Nog leuker is om via mod security een geheel eigen banner in te stellen. Bijv "www.bedrijfsnaam.nl" ;)
Nog leuker is om via mod security een geheel eigen banner in te stellen. Bijv "www.bedrijfsnaam.nl" ;)Hehe, inderdaad. De Cisco ASA firewalls kunnen dat ook :)
Niemand hoeft toch te weten welke versie Apache of PHP je draait?
Het verbergen van je Apache versie maakt je niet veiliger.
Deze manier van 'beveiligen' noem je overigens "security through obscurity".
Je moet er van uit gaan dat je systeem pas veilig is als kwaadwillenden zelfs als ze precies weten hoe je systeem in elkaar zit nog steeds geen toegang tot je systeem kunnen krijgen.
Daarnaast zegt je Apache (of PHP) versie zeker niet altijd iets over het feit of je systeem vulnerable is voor bepaalde exploits.
Voorbeeld: Debian 4.0 komt standaard met Lighttpd versie 1.4.13. Deze versie van Lighttpd is echter wel gepatched met fixes voor alle vulnerabilities tot en met Lighttpd versie 1.4.18.
Hebben veel partijen dit aan staan omdat ze het bestaan van deze opties niet kennen? Omdat het ze niet boeit of om andere redenen?
In mijn ervaring zetten de meeste mensen dit niet uit omdat het je systeem totaal niet veiliger maakt.
Veiliger maakt het zeker niet, maar gaat een bank alle details van zijn kluis prijs geven? Nee, dat doet de bank niet, want het is weer een éxtra stukje veiligheid.
Ik weet inderdaad dat Debian en Ubuntu patchen om security fixes mee te nemen, maar er zijn er ook genoeg die dat niet doen.
Veiliger maakt het zeker niet, maar gaat een bank alle details van zijn kluis prijs geven? Nee, dat doet de bank niet, want het is weer een éxtra stukje veiligheid.
Slecht voorbeeld, een bank is een fysiek gebouw en jouw Apache is een stukje software.
Om bij de software te blijven: binnen de cryptografie is het algemeen aangenomen dat voor het bouwen van een secure systeem je er ten alle tijden van uit moet gaan dat het complete ontwerp van je systeem beschikbaar is voor kwaadwillenden, met uitzondering van cryptografische sleutels.
Zie Shannon's maxim (http://en.wikipedia.org/wiki/Claude_Shannon#Shannon.27s_maxim) en vooral Kerckhoffs' principle (http://en.wikipedia.org/wiki/Kerckhoffs'_principle).
Voor het bouwen inderdaad. Dat is wat anders dan het gebruiken ervan. Je moet er ook zeker wel vanuit gaan dat de versie en andere details bekend zijn, maar het is zeker niet af te raden om het stil te houden.
Leuk en aardig al deze wetenschappelijke benaderingen, maar het is in mijn ogen meerderemalen in de praktijk bewezen dat Wido gewoon gelijk heeft.
Paar dingen die wij gedaan hebben die hier overal als onzin / security by obscurity worden afgedaan:
- SSH Port veranderen, scheelde op sommige machines meer dan 1000 loginpogingen per dag + je loopt alle standaard ssh-exploits die gewoon in het wilde weg wat proberen alweer mis
- Apache banner etc verwijderen -> Scheelt heel veel in het aantal attemtps van standaard botjes die het web afstruinen naar vulnarable versies van bepaalde software om daar vervolgens een exploit op los te laten.
Om bij de software te blijven: binnen de cryptografie is het algemeen aangenomen dat voor het bouwen van een secure systeem je er ten alle tijden van uit moet gaan dat het complete ontwerp van je systeem beschikbaar is voor kwaadwillenden, met uitzondering van cryptografische sleutels.
Leuk en aardig, maar dat betekend niet dat je kwaadwillenden een handje moet helpen. Ik kan me zo 1-2-3 niet bedenken waarom je bewust die informatie aan derden wilt verstrekken.
Leuk en aardig, maar dat betekend niet dat je kwaadwillenden een handje moet helpen. Ik kan me zo 1-2-3 niet bedenken waarom je bewust die informatie aan derden wilt verstrekken.Exact mijn punt, waarom meer informatie prijs geven dan nodig is?
Niemand hoeft toch te weten welke versie PHP of Apache ik gebruik op mijn systeem? Denk inderdaad alleen maar aan de botjes die het net afstruinen.
crazycoder
28/09/07, 08:09
Slecht voorbeeld, een bank is een fysiek gebouw en jouw Apache is een stukje software.
Ja, maar als er op de muur "friet van piet" staat is de kans op inbraak in het pand een stuk kleiner :)
Waar Wido het over heeft is dat je jezelf als doel iets minder eenvoudig te herkennen maak.
Het kan inderdaad wat attempts schelen wanneer men eerst gaat checken welke versie het draait, echter de slimmer proberen altijd een poging ongeacht de versie. Zie het als niet eerst pingen maar direct connecten :)
Mijn visie was enerzijds dat ik de buitenwereld kon laten zien dat ik up 2 date blijf.
Paar dingen die wij gedaan hebben die hier overal als onzin / security by obscurity worden afgedaan:
- SSH Port veranderen, scheelde op sommige machines meer dan 1000 loginpogingen per dag + je loopt alle standaard ssh-exploits die gewoon in het wilde weg wat proberen alweer mis
- Apache banner etc verwijderen -> Scheelt heel veel in het aantal attemtps van standaard botjes die het web afstruinen naar vulnarable versies van bepaalde software om daar vervolgens een exploit op los te laten.
SSH poort veranderen bracht het aantal attacks van 35.000 per dag naar 0 in de afgelopen 6 weken.
De apache banner verwijderen werpt gewoon een extra hindernis op voor een aanvaller: waarom zou een scriptkiddy moeite doen om jou server zonder banner aan te vallen, als van de buurman al bekend is welke software hij gebruikt, en dus bekend is welke exploits er (waarschijnlijk) werken?
De conclusie dat velen niets eraan doen lijkt mij ongegrond, aangezien genoeg beheerders expliciet valse service versie nummers opgeven om te misleiden. Servertokens op ProductOnly en/of ServerSignature Off maakt het voor de aanvaller wellicht interessanter om verder te kijken omdat je wellicht iets belangrijks te verbergen/beschermen hebt. Desalnietemin, een goeie tip om te masken aangezien het een van de snelste/makkelijkste aanpassingen is.
Ik denk dat de groep die valse nummers opgeeft héél erg klein is. De meeste hebben het aan staan zonder weet dat het uberhaupt aan kan staan.
AlexanderOnline
28/09/07, 12:11
Hallo,
Ik heb in mijn Firefox de leuke ServerSpy plugin, hiermee kan ik direct zien welke webserver software een website draait.
Leuke plugin! De ASNumber plugin is ook handig btw :)
Ook leuk, dat doen wij: IIS5.0 teruggeven wanneer je Apache bent. In de logs zie je dan allemaal known IIS5.0 hacks langskomen, terwijl er gewoon Apache draait.
crazycoder
28/09/07, 22:00
Ook leuk, dat doen wij: IIS5.0 teruggeven wanneer je Apache bent. In de logs zie je dan allemaal known IIS5.0 hacks langskomen, terwijl er gewoon Apache draait.
Krijg je ook als je de apache banners laat staan hoor ;)
Leuke plugin! De ASNumber plugin is ook handig btw :)Die had ik ook al.
Ik heb ShowIP, ServerSpy en ASNumber :)
Ik ben het deels met je eens, maar ik weet uit de loggings dat het in principe niet uit maakt of je wel of niet naar de buitenwereld bekend maakt welke versies je draait. Je krijgt alles om je oren, IIS meuk op Linux machines en Windows vs Apache.
De gedachtegang is namelijk heel simpel vanuit de scripters gezien, waarom zou ik condities gebruiken als ik een evengrote kans op succes heb als ik het niet doe.
Kortom, ze vuren alles wat ze hebben af op je machine en dat doen ze vaak wel volledig geautomatiseerd. Ze gaan uit van bekende zaken.
- SSH Port veranderen, scheelde op sommige machines meer dan 1000 loginpogingen per dag + je loopt alle standaard ssh-exploits die gewoon in het wilde weg wat proberen alweer mis
Als je door standaard SSH exploits gepakt wordt dan heb je veel grotere problemen dan een paar extra inlogpogingen per dag.
Het feit dat je minder geprobed wordt betekent absoluut niet dat je systeem meer veilig is. Iemand die echt specifiek op je systeem binnen probeert te komen laat zich absoluut niet tegenhouden door het feit dat je een regeltje in je sshd_config hebt veranderd.
Je creeert op deze manier niets anders dan een vals gevoel van veiligheid.
Een in mijn ogen betere methode (als een strict IP filter op je SSH poort geen mogelijkheid is omdat jij of je klanten een dynamisch IP hebben) is het limiten van connection attempts per IP adres:
/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP
Of eventueel op poort niveau:
/sbin/iptables -A INPUT -m tcp -p tcp --dport 22 -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A INPUT -m tcp -p tcp -s 10.1.0.0/24 --dport 22 -j ACCEPT
/sbin/iptables -A INPUT -m tcp -p tcp --dport 22 -m state --state NEW -m limit --limit 3/min --limit-burst 3 -j ACCEPT
/sbin/iptables -A INPUT -m tcp -p tcp --dport 22 -j DROP
Mijn idee van security is en blijft: ook als jij weet dat ik versie 1.4.18 van Lighttpd draai op een server met PHP v5.2.4, dan nog kom je mijn systeem niet op.
Overigens even terzijde en iets meer on-topic: het gros van de security problemen zitten niet in Apache maar in de web applicaties die je op je Apache webserver draait.
MusicMaestro
01/10/07, 10:37
Het verbergen van je Apache versie maakt je niet veiliger.
Deze manier van 'beveiligen' noem je overigens "security through obscurity".Wat een onzin. Natuurlijk maakt verbergen van je Apache versie je veiliger. En security by obscurity werkt ook gewoon altijd; http://jult.net/archive/2007/05/18/Security_by_obscurity
Krijg je ook als je de apache banners laat staan hoor ;)
True, maar de hoeveelheid Apache shizzle neemt wel giga af.
Wat een onzin.
Uit de link die je meestuurt:
Proving why security by obscurity does work: It will confuse the person who wants to break security, and it will cause a huge time-delay for your server security to be broken, if not prevent it from happening entirely!
Dat het langer duurt voor iemand je setup kent betekent nog steeds niet dat je systeem daardoor automagisch meer veilig is.
Ter vergelijking: stel je voor dat ik een blauwe fiets heb. Als ik jou niet vertel wat voor kleur mijn fiets is, is hij dan ineens niet meer blauw?
En security by obscurity werkt ook gewoon altijd
In de woorden van Thomas Edison: "A conclusion is simply the place where you got tired of thinking."
Tuurlijk, als iemand écht wil, kan hij het wel achterhalen.
Maar waarom niet die extra barriere opwerpen, dat is toch niet zo erg?
Tuurlijk, als iemand écht wil, kan hij het wel achterhalen.
Daarmee geef je zelf al aan dat je systeem er dus niet veiliger van wordt, je maakt je setup dus alleen maar complexer zonder iets aan de veiligheid toe te voegen.
Maar waarom niet die extra barriere opwerpen, dat is toch niet zo erg?
Dit legt Bruce Schneier (http://en.wikipedia.org/wiki/Bruce_Schneier) uit in Homeland Insecurity (http://www.theatlantic.com/doc/200209/mann):
Kerckhoffs' principle applies beyond codes and ciphers to security systems in general: every secret creates a potential failure point.
Ik ben het overigens eens met eerdere posters dat het aanvallers kan vertragen, mijn punt is alleen dat je systeem hierdoor niet veiliger wordt.
dreamhost_nl
01/10/07, 13:00
Daarmee geef je zelf al aan dat je systeem er dus niet veiliger van wordt, je maakt je setup dus alleen maar complexer zonder iets aan de veiligheid toe te voegen.
"Complexer" door het aanpassen van twee config bestandjes ? Dat is wel erg overdreven. Indien het toch een kleine barrière opricht, waarom dan niet ?
Indien het toch een kleine barrière opricht, waarom dan niet ?
Ook als je je banner verandert, dan nog is het door middel van HTTP fingerprinting (http://net-square.com/httprint/httprint_paper.html) een eitje om uit te vinden welke versie je draait. Dus als je denkt dat het verbergen van de Apache banner zin heeft, dan kan je beter meteen ook even in het aanpassen van de HTTP/1.x headers duiken.
Nog een argument: Als de kids niet weten wat voor versie je draait, dan laten ze gewoon hun hele scala aan tools op je server los.
Het idee dat je je server veiliger maakt door je Apache versie te beveiligen is een denkfout: je onderschat je tegenstander en daarnaast verspil je tijd die je beter had kunnen besteden aan het beveiligen van je server.
Nee hoor, want ServerTokens pas de "Server" header aan in zijn 1.1 response.
Dus jouw opmerking gaat niet op! :)
Nee hoor, want ServerTokens pas de "Server" header aan in zijn 1.1 response. Dus jouw opmerking gaat niet op! :)
Misschien eerst even lezen wat HTTP fingerprinting (http://net-square.com/httprint en vooral http://net-square.com/httprint/httprint_paper.html) is voor je je conclusies trekt?
De server header is in het geheel niet nodig om de Apache versie uit te lezen...
Ik ben inderdaad niet de gehele pagina gaan lezen, ik heb een conclusie getrokken aan uit het feit dat je over de HTTP/1.1 headers begon.
Je kan met TCP fingerprinting ook achterhalen welk OS iemand draait, dat is allemaal mogelijk.
Maar daar gaat dit helemaal niet over, ik vraag me alleen af, waarom niet die kleine laag opwerpen die weer een groep mensen tegen houd?
Misschien eerst even lezen wat HTTP fingerprinting (http://net-square.com/httprint en vooral http://net-square.com/httprint/httprint_paper.html) is voor je je conclusies trekt?
De server header is in het geheel niet nodig om de Apache versie uit te lezen...
Getest. Geeft op al onze servers verkeerde info. Voortaan misschien even testen voordat je je conclusies trekt? :D
Getest. Geeft op al onze servers verkeerde info. Voortaan misschien even testen voordat je je conclusies trekt? :D
Hier hetzelfde, geeft ook op alle servers verkeerde info.
Dit is gewoon nog een discussie over security through obscurity. Die discussie wordt volgens mij al sinds het bestaan van de mensheid gevoerd.
Ik heb altijd geleerd te beveiligen in lagen. Elke extra laag in je beveiliging kan ervoor zorgen dat een potentiele kwaad-doener afhaakt en besluit te gaan voor een andere systeem. Zo ook het niet weggeven van enige informatie over je systeem. Een volledig up-to-date systeem hoeft immers niet veilig zijn, updates met exploit-fixes komen elke dag nog uit. En hoewel je een scriptkiddie met je andere veiligheids maatregelen nog kan afweren, iemand die echt kwaad wil komt wellicht wel binnen doordat je huidige versie van Apache/PHP/etc een exploit bevat.
Security through obscurity is dus zeker wel een vorm beveiliging. Je moet alleen goed snappen waar die veiligheid staat. Het gaat je systeem nooit beveiligen en je mag er nooit op vertrouwen dat het ook maar iets aan je veiligheid bijdraagt, maar in de praktijk kan het best voordelen opleveren en problemen afwentelen.