Overzicht #
Het volgende artikel beschrijft een praktijkvoorbeeld voor een internetprovider of hostingprovider, waarbij de HTTP/S Load Balancer reverse proxy het belangrijkste toegangspunt is tot alle openbare webdiensten. Deze configuratie laat zien hoe eenvoudig het is om een geavanceerde en krachtige WAF-regelset te configureren om webapplicaties te beveiligen op basis van een blacklist van bron-IP-adressen. Elke VirtualHost beheert zijn eigen blacklist, zodat een bepaald openbaar IP-adres geen verbinding mag maken met een webdomein zoals www.company1.com , maar wel met www.company2.com.
We zullen dit artikel in twee delen opsplitsen. In het eerste deel wordt uitgelegd hoe het HTTPS-profiel als reverse proxy functioneert met een lijst van verschillende services. In het tweede deel wordt beschreven hoe een webapplicatie-firewall (WAF) kan worden geconfigureerd met een aparte blacklist voor elke HTTP/S-service.
Milieu #
Het volgende diagram beschrijft de RELIANOID WAF-interne onderdelen. Zoals te zien is, is de eerste laag de WAF-module, die tot doel heeft om er in een vroeg stadium voor te zorgen dat alleen veilige verzoeken naar de load-balancing-module mogen gaan en het verzoek vervolgens doorsturen naar de backends.
Allereerst wordt de HTTP Host- header geëvalueerd en wordt het IP-adres van de client gecontroleerd aan de hand van de reeds geconfigureerde blacklist. Als de Host- header en het IP-adres van de client overeenkomen, wordt de verbinding verbroken en wordt een 403 Forbidden HTTP-respons naar de client verzonden. Als het IP-adres van de client en de gevraagde Host- header niet overeenkomen, wordt het verkeer als niet-kwaadwillend beschouwd en doorgestuurd naar de load balancer-module. Daar wordt de bestemming gekozen op basis van de HTTP-verzoek -Host- header en uiteindelijk doorgestuurd naar de beschikbare backend-server.
Hier vindt u een schema van de interne onderdelen van de Web Application Firewall voor het gegeven voorbeeld.
Configuratie van virtuele HTTP-service #
Configureer één specifiek virtueel IP-adres , in ons voorbeeld 192.168.100.58 , door te navigeren naar Netwerk > Virtuele interfaces > Virtuele interface maken, zoals hieronder weergegeven:
Laten we nu de HTTP-loadbalancing-service configureren. Ga naar LSLB > Farms en klik vervolgens op de knop 'Create Farm' . Voer de details van de virtuele service in zoals hieronder weergegeven:
Druk vervolgens op 'Maken'.
Klik nu op het tabblad 'Services' bovenaan en maak evenveel services aan als het aantal verschillende websites dat u beheert. Klik vervolgens op de knop ' Nieuwe service' . In ons geval maken we twee verschillende services aan: één voor het beheer van www.mycompany1.com en één voor www.mycompany2.com.
Nadat de service is aangemaakt, voegt u het Virtual Host- filter en de backends toe zoals weergegeven in de onderstaande afbeelding.
Als u meerdere websites heeft, hoeft u alleen maar meer services toe te voegen om één speciale service te definiëren om elk web vanaf hetzelfde IP-adres te beheren.
Nu de taakverdelingsconfiguratie is voltooid, kunnen we de IPDS Web Application Firewall-module configureren.
Configuratie van zwarte lijsten #
We gaan per webservice een blacklist aanmaken om in elke blacklist de gewenste IP-adressen in te voeren die we willen blokkeren. In ons voorbeeld maken we twee verschillende blacklists aan met de namen blacklistmycompany1 en blacklistmycompany2 , één per service.
Deze zwarte lijst wordt opgeslagen in het pad /usr/local/relianoid/config/ipds/blacklists/lists/Blacklistmycompany1.txt.
We hebben voor testdoeleinden 2 IP-adressen toegevoegd; voeg naar behoefte meer IP-adressen toe. De bestaande blacklists in de IPDS- module kunnen ook worden gebruikt.
Deze tweede zwarte lijst wordt opgeslagen in het pad /usr/local/relianoid/config/ipds/blacklists/lists/Blacklistmycompany2.txt.
Houd er rekening mee dat we in deze blacklist het IP-adres 192.168.1.191 hebben opgenomen . Dit IP-adres wordt alleen gebruikt voor testdoeleinden, van waaruit we HTTP-verzoeken zullen uitvoeren.
Configuratie van de Web Application Firewall-regelset #
Het doel van deze configuratie is om verschillende IP-zwarte lijsten per website bij te houden, om te voorkomen dat dezelfde zwarte lijst voor het hele toegangspunt van de boerderij wordt aangehouden.
We gaan een regelset configureren , een groep regels, met de naam HostingBlacklisting . Deze regelset bestaat uit twee eenvoudige regels (regel-ID 1000 en regel-ID 1001 in ons voorbeeld). Elke regel is gedefinieerd als een overeenkomst en een actie. Als aan de voorwaarde wordt voldaan, wordt de actie uitgevoerd. In ons voorbeeld gebruiken we dezelfde actie in beide regels: als aan de voorwaarde wordt voldaan, wordt een 'Reject'-actie uitgevoerd met een 403 'Access Denied' -respons.
Ga naar IPDS > WAF , klik vervolgens op 'WAF-regelsset maken' en geef de regelsset een beschrijvende naam, in ons voorbeeld 'HostingBlacklisting '.
Configureer het veld 'Standaardfase' op 'Verzoekheaders worden ontvangen' . Dit veld betekent dat de WAF-module de binnenkomende verzoekheaders van de client analyseert.
Ga vervolgens naar het tabblad Regels en maak de eerste regel van het type Actie aan , zoals hieronder weergegeven.
Nu de eerste regel van de regelset is aangemaakt, gaan we de voorwaarden definiëren om het client-IP-adres in de blacklist te matchen voor elke Host- header. Ga naar Voorwaarden en maak een voorwaarde aan op basis van de variabele REMOTE_ADDR , zoals hieronder weergegeven.
Maak vervolgens een andere voorwaarde voor de overeenkomst met de virtuele host op basis van de variabele SERVER_NAME als volgt:
Op dit punt beheert de eerste gehoste website www.mycompany1.com een IP-adres van een webapplicatie-blacklist uit de reeds geconfigureerde blacklist, waarnaar wordt verwezen in Blacklistmycompany1.txt.
Laten we een nieuwe regel aanmaken voor de tweede website www.mycompany2.com en dezelfde configuratie gebruiken als bij de vorige regel, maar in dit geval moet u de SERVER_NAME wijzigen in mycompany2.com en de volgende blacklist2.txt raadplegen.
Bekijk de volledige configuratie van de samengestelde WAF-regelset:
Voeg tot slot deze regelset toe aan de reeds aangemaakte farm, ga naar het tabblad Farms en verplaats de farm Hosting (in ons voorbeeld) naar de sectie Ingeschakelde farms , zoals hieronder weergegeven.
Start nu de WAF-regels voor de farm, klik op de actie ' Afspelen' linksboven in dit venster en het systeem begint met het filteren van HTTP-verkeer voor de farmhosting.
Het testen van de Web Application Firewall-regelset #
Het client-IP-adres 192.168.1.191 zal de websites http://www.mycompany1.com en http://www.mycompany2.com opvragen . Volgens onze configuratie zal het WAF-systeem de verbinding met de eerste website met dezelfde naam toestaan, maar de verbinding met mycompany2.com zal worden geweigerd omdat dit IP-adres is opgenomen in de blacklist met de naam Blacklistmycompany2.
Van IP-adres 192.168.1.191 naar VIP die de website www.mycompany1.com opvraagt via de load balancer:
root@192.168.1.191:# curl -H "Host: www.mijnbedrijf1.com" http://192.168.100.58 -v * URL opnieuw opgebouwd naar: http://192.168.100.58/ * 192.168.100.58 geprobeerd... * TCP_NODELAY set * Verbonden met 192.168.100.58 (192.168.100.58) poort 80 (#0) > GET / HTTP/1.1 > Host: www.mycompany1.com > User-Agent: curl/7.52.1 > Accepteren: */* > HTTP / 1.1 200 OK < Server: nginx/1.10.3 < Datum: dinsdag, 10 september 2019 15:36:22 GMT < Inhoudstype: tekst/html < Inhoudslengte: 11383 < Laatst gewijzigd: do, 13 december 2018 11:01: 49 GMT < Verbinding: keep-alive < ETag: "5c123c1d-2c77" < Accept-bereiken: bytes
Van IP-adres 192.168.1.191 naar VIP die de website www.mycompany2.com opvraagt via de load balancer:
root@192.168.1.191:# curl -H "Host: www.mijnbedrijf2.com" http://192.168.100.58 -v * URL opnieuw opgebouwd naar: http://192.168.100.58/ * 192.168.100.58 geprobeerd... * TCP_NODELAY set * Verbonden met 192.168.100.58 (192.168.100.58) poort 80 (#0) > GET / HTTP/1.1 > Host: www.mycompany2.com > User-Agent: curl/7.52.1 > Accepteren: */* > * HTTP 1.0, ga uit van close after body HTTP/1.0 403 Verzoek verboden < Content-Type: text/html < Content-Length: 17 < Verloopt: nu < Pragma: no-cache < Cache-control: no-cache,no-store < * Curl_http_done: voortijdig genoemd == 0 * Verbinding sluiten 0 heeft geantwoord verbodenp
Zodra het antwoord 'Forbidden' is gegenereerd, meldt de WAF-module de afwijzing in het Syslog-bestand van de load balancer.
root@zva6000:# tail -f /var/log/syslog 10 sep 15:38:44 zva6000 pond: Hosting, ModSecurity: Waarschuwing. Matched "Operator `StrMatch' met parameter `mycompany2.com' tegen variabele `SERVER_NAME' (Waarde: `www.mycompany2.com') [bestand "/usr/local/relianoid/config/ipds/waf/sets/HostingBlacklisting.conf"] [regel "17"] [id "1001"] [rev ""] [msg "Custom Match 2"] [data ""] [ernst "0"] [ver ""] [volwassenheid "0"] [nauwkeurigheid "0"] [hostnaam "192.168.100.58"] [uri "/"] [unique_id "156812992458.770641"] [ref "v0,13v21,18"] 10 sep 15:38:44 zva6000 pond: Hosting, [WAF,service mycompany2, backend 192.168.100.22:80,] (7f6cfac3c700) [client 192.168.1.191] ModSecurity: Toegang geweigerd met code 403 (fase 1). Matched "Operator `StrMatch' met parameter `mycompany2.com' tegen variabele `SERVER_NAME' (Waarde: `www.mycompany2.com') [bestand "/usr/local/relianoid/config/ipds/waf/sets/HostingBlacklisting.conf"] [regel "17"] [id "1001"] [rev ""] [msg "Custom Match 2"] [data ""] [ernst "0"] [ver ""] [volwassenheid "0"] [nauwkeurigheid "0"] [hostnaam "192.168.100.58"] [uri "/"] [unique_id "156812992458.770641"] [ref "v0,13v21,18"] 10 sep 15:38:44 zva6ktpl1 pond: Hosting, service mycompany2, backend 192.168.100.25:80, (7f6cfac3c700) WAF heeft een verzoek van 192.168.1.191 geweigerd
Nu kunt u uw aangepaste firewallregelsets samenstellen om uw webapplicaties te beschermen met behulp van HTTP/S deep packet inspection-technieken.
