Security Tip van de Week: laat je server geen header-info lekken
In de Security Tip van de week geeft elke week een andere professional, expert, onderzoeker of lezer een security tip. Persoonlijke tips, variërend van het veilig configureren van Windows, een handige security tool of het juist instellen van een firewall, waarmee de tipgever zijn systeem, applicatie of netwerk veiliger maakt.
Heb jij ook een leuke, originele, maar bovenal goede security tip die niet mag ontbreken, stuur dan een mail naar redactie@security.nl.
Deze week de Security Tip van Franco Lavicka
Minder is meer!
Informatie over de gebruikte webtechnologie moet niet met het publiek worden gedeeld. Dat verbetert de bescherming tegen toevallige, ‘opportunistische’ aanvallen. Er is vandaag de dag erg veel aandacht voor de beveiliging tegen doelgerichte aanvallen. Maar in veel gevallen is het helemaal niet meteen duidelijk waarom een organisatie eigenlijk het doelwit is van een aanval.
Toch is er een reden waarom een bedrijf een aanval te verduren krijgt. Het komt doordat er een gangbare webservicetechnologie wordt gebruikt, bijvoorbeeld een eCommerce-platform, enterprise portal service, video streaming platform, een specifiek programmeerframework, enzovoort) en er over de gebruikte technologie te veel informatie wordt vrijgegeven.
Met als gevolg dat iedere internetgebruiker dit kan zien en dus ook kan gebruiken voor een cyberaanval. Het gaat dan om zogeheten random opportunistische aanvallen.
Het selecteren van een doelwit gebeurt op twee manieren:
- Doelgerichte aanvallen: speciaal gekozen voor financieel gewin of vanwege een hacktivistische of politieke reden. Is het doelwit eenmaal geselecteerd, moeten de aanvallers een of andere kwetsbaarheid weten te vinden waarvan zij gebruik kunnen maken om hun doel te bereiken.
- Random, opportunistische aanvallen: voor dit soort aanvallen is het selectiecriterium juist een specifieke, bekende kwetsbaarheid, in plaats van een specifieke organisatie. Deze aanvallen zijn grotendeels geautomatiseerd en de maat voor succes is het aantal gecompromitteerde sites.
Praktisch gezien komt het hier op neer: het doelwit van een random opportunistische aanval toont specifieke informatie over de gebruikte webservices op internet. Deze informatie wordt herkend door geautomatiseerde software die daarop scant.
Vervolgens analyseert die software de verzamelde informatie en stelt een lijst op met de belangrijkste doelen, gebaseerd op de mate van kwetsbaarheid. De lijst wordt gerangschikt en gewogen op basis van de grootste kans op succes als een cyberaanval wordt uitgevoerd.
Hieronder een voorbeeld van een deel van een http response header met informatie over de webservicetechnologie die wordt gebruikt. Dit soort informatie is zeer eenvoudig te achterhalen door op http-protocolniveau te 'luisteren' naar de communicatie tussen server en client (bijvoorbeeld met een browserplugin, zie ref1).
HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Content-Type: text/html; charset=utf-8
Expires: Mon, 01 Apr 2013 10:08:17 GMT
Last-Modified: Tue, 16 Apr 2013 10:08:17 GMT
Server: Microsoft-IIS/7.5
SPRequestGuid: 68d070fd-bf4d-47e5-b9be-59de941107e6
X-SharePointHealthScore: 0
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 14.0.0.6117
X-MS-InvokeApp: 1; RequireReadOnly
Date: Tue, 16 Apr 2013 10:08:16 GMT
Connection: Keep-Alive
Content-Length: 25484
Vary: Accept-Encoding
Content-Encoding: gzip
Het zou beter zijn om de informatie in de response headers zoveel mogelijk te beperken en alleen dat te laten zien wat hoogstnoodzakelijk is, en dan alleen generieke informatie over de gebruikte webservicetechnologieën.
Een voorbeeld van deze best practice:
HTTP/1.1 200 OK
Server: Apache
Content-Type: text/html
Vary: Accept-Encoding
Content-Encoding: gzip
Date: Tue, 16 Apr 2013 11:26:18 GMT
Content-Length: 4768
Connection: keep-alive
Dit kan op verschillende manieren worden bereikt:
- Door het aanpassen van de configuratie van de webservicetechnologie om te voorkomen dat dergelijke header attributen worden verzonden.
- Het gebruik van een web applicatie firewall die de mogelijkheid heeft om uitgaande regels te definiëren en toe te passen, waarbij dit soort informatie vóór het verzenden wordt gefilterd.
Het aanpassen van de configuratie van de webserver
De basistip om de server beveiligen is het geven van zo weinig mogelijk informatie over het type OS, de services die gedraaid worden, de geïnstalleerde pakketten en andere informatie die het hackers gemakkelijker maakt.
Hoe kunnen de Apache webserver details veranderd of afgeschermd worden?
Het is eenvoudig om het Apache (httpd) versienummer en andere informatie te verbergen. Er zijn twee config directives voor de Apache-versie. In de Apache-configuratie kan de Apache-informatie verborgen worden door het volgende te doen:
vi httpd.conf
ServerSignature Off
ServerTokens Prod
De ServerSignature directive voegt aan elk document dat door de server wordt gegenereerd een regel toe met de versie van de Apache HTTP Server en de ServerName. De ServerTokens directive geeft aan of het server response headerveld (die teruggestuurd wordt naar de clients) een beschrijving bevat van het generieke OS-type van de server, plus informatie over meegecompileerde modules. Door dit op ‘Prod’ te zetten wordt alleen ‘Apache’ als servernaam aangegeven, zonder versienummer.
Hoe je de Apache-naam kan veranderen in wat je maar wilt (zie ook deze link)
# apt-get update
# apt-get install libapache-mod-security
# a2enmod mod-security
Module mod-security reeds geactiveerd
# vi /etc/apache2/conf.d/security
ServerTokens Full
SecServerSignature Name_to_Display
Apache configuratiebestand opnieuw laden
# /etc/init.d/apache2 reload
Meer dan 70% van de aanvallen wordt momenteel uitgevoerd op het niveau van de webapplicatie. Organisaties hebben alle hulp nodig die zij maar kunnen krijgen om hun systemen veiliger te maken. Web Applicatie firewalls worden ingezet om een externe beveiligingslaag te bewerkstelligen die de beveilig versterkt door aanvallen te detecteren en te voorkomen, voor ze de webapplicaties bereiken. Hoe kan het delen van Apache-informatie via een web applicatie firewall worden geblokkeerd?
Web Application firewalls (WAFs) werken op basis van vooraf gedefinieerde regels. Zo kunnen lekken in de webservertechnologie worden tegengegaan en is het mogelijk om een website en/of webapplicaties op internet te beschermen. Met de Kona Web Application Firewall van Akamai kunnen bijvoorbeeld outbound-regels worden ingesteld.
Conclusie
Er zijn verschillende manieren om te voorkomen dat informatie over de webservicetechnologie via de browser uitlekt. Alle maatregelen worden geïmplementeerd aan de serverkant van de website. De implementatie daarvan is daarom de verantwoordelijkheid van de website provider.
Retailklanten hebben - net als ondernemingen - geen invloed op het verbergen van deze informatie als zij zich aan de client-zijde van deze communicatie bevinden. Vanwege de huidige stand van zaken op internet met betrekking tot cyberaanvallen is het raadzaam om maatregelen te nemen, om met informatie af te schermen en zo de beveiliging te verbeteren.
Franco Lavicka is Business Architect en Technical Consultant bij Akamai Technologies
Dit artikel is geschreven op persoonlijke titel van de auteur en reflecteert niet noodzakelijk de zienswijze van Security.NL.
En net zoals ik liever niet bekend maak op Facebook wanneer ik op vakantie ben (en er dus niemand op het huis past).
Dat dat op zichzelf niet voldoende is, snap ik ook wel. Maar dat is geen reden om alles maar op straat te gooien.
En net zoals ik liever niet bekend maak op Facebook wanneer ik op vakantie ben (en er dus niemand op het huis past).
Dat dat op zichzelf niet voldoende is, snap ik ook wel. Maar dat is geen reden om alles maar op straat te gooien.
Ik ben het met je eens, alleen een paar jaar geleden was het wel heel erg hip in het (commerciële/CCISP) security-wereldje om in dit soort situaties meteen "security through obscurity" te roepen.
In het php.ini configuratiebestand verander je expose_php in 'off'.
Een ander bijkomend voordeel is dat de zogenaamde PHP-Eggs ook niet meer zichtbaar zijn.
Zet deze string maar eens achter een willekeurige URL op een PHP gebaseerde server, dan weet je wat ik bedoel met PHP-Egg:
Ik ben het met je eens, alleen een paar jaar geleden was het wel heel erg hip in het (commerciële/CCISP) security-wereldje om in dit soort situaties meteen "security through obscurity" te roepen.
Echter of het zo ongewenst is weet ik niet. Het is een beetje wat helpt, zoals alle beetjes helpen. Het moet niet
de basis van je veiligheid zijn.
(overigens zeggen die versies niks, er zijn zat distributies die security fixes backporten naar de versie die oorspronkelijk
in die distributie zat. exploits die zoeken naar een bepaalde versie van Apache die kunnen dus evengoed nog wel hun
neus stoten omdat het toch niet blijkt te werken ondanks dat de versie klopt)
Ondanks dat ik dit ook op mijn eigen server heb uitgezet, krijg ik dit ook te zien, dus het helpt niet echt.
Bijkomend voordeel van het verwijderen of inkorten van deze http headers is naast wat obscurity tegen geautomatiseerde aanvallen, dat minder overbodige headers ook weer een klein beetje bandbreedte scheelt.
Maar op het moment dat je een dagje of wat achterloopt met het installeren van patches. Bijvoorbeeld om te checken of zo'n patch niet je hele productie omgeving in de war schopt, dan kan het wel eens handig zijn om niet aan de buitenwereld te vertellen op welke versie je zit.
Ik ben het dus volledig eens met de schrijver - hoe stiller je bent, hoe minder aandacht je trekt...
Ter vergelijking: ik heb wel eens het verwijt gekregen dat ik vertrouw op 'security through obscurity' door op een SSH-server een port-knocking-achtige[*] constructie te zetten die de SSH-poort pas na een bepaalde benadering van de machine tijdelijk open zet voor nieuwe verbindingen vanaf het IP-adres dat de 'knock' uitvoert. Alleen is de toegangsbeveiliging nog volledig van toepassing als de poort geopend is, je komt er ook dan niet zomaar in. De opzet verzwakt die beveiliging dus heel nadrukkelijk niet. Wat het wel doet is de kans aanzienlijk verkleinen dat een opportunist die via scans machines opspoort met een kwetsbaarheid waar nog geen patch voor beschikbaar is (of is aangebracht) deze server op het spoor komt. Dat verhoogt de veiligheid. Het simpele feit dat ik niet overspoeld word door logmeldingen van alle mislukte aanlogpogingen[**] maakt dat het onmiddelijk opvalt als er wel iets raars gebeurt. Die toegenomen overzichtelijkheid draagt indirect ook bij aan de beveiliging.
Het was 'security through obscurity' geweest als ik had gedacht dat die port-knock alleen afdoende was en ik de authenticatie verder had uitgeschakeld of zoiets stoms. Iets toevoegen aan de bestaande beveiligingsmaatregelen, en je ervan bewust zijn dat die nog even belangrijk zijn als zonder dat extraatje, is geen 'security through obscurity' maar een extra drempel die een aanvaller moet nemen. Wat Franco Lavicka aanbeveelt is een voorbeeld daarvan.
[*] Het is geen port-knocking in de strikte betekenis. Er draait ook een webserver op die machine, en het opvragen van een specifieke, niet bestaande URL op die machine zet de SSH-poort voor 30 seconden open voor nieuwe connecties. De iptables-regels die dit doen:
iptables -A INPUT -p tcp --dport ssh -m recent --rcheck --seconds 30 --name SSHOPEN -j ACCEPT
ssh user@mijndomein.tld
[**]Eerst gebruikte ik daar fail2ban voor, software die IP-adressen na een beperkt aantal mislukte aanlogpogingen blokkeert, alleen werd dat nutteloos toen botnets zo groot werden dat van een aanval (te herkennen aan usernamen die in alfabetische volgorde werden uitgeprobeerd) elke poging van een ander IP-adres kwam. Ik heb fail2ban sindsdien enthousiast aanbevolen zien worden op fora, dus ofwel hebben de makers een oplossing hiervoor weten te bedenken, ofwel zijn de botnets tegenwoordig een stuk kleiner dan ze ooit geweest zijn.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
