Jeg vil lige dele en idé, i håb om andre kan bruge og gerne forbedre den. Kort fortalt er jeg kommet op med en relativt dynamisk metode til at blokere kommunikation med alverdens hackeres foretrukne netværk, nemlig Tor.
Løsningen skal i nuværende form betragtes som et “proof of concept”, baseret på et Windows PowerShell script, der styrer et Active Directory »Group Policy Object« (GPO), som igen styrer »Windows Firewall with Advanced Security« (WFAS) konfigurationen på linkede Windows servere og klienter (Windows Vista og op).
Hvem er denne Tor?
Tor-netværket er en bekvem måde at gemme sig på for en angriber, da man herfra kan optræde stort set anonymt. Jeg skal ikke her gå i detaljer med teknologien bag Tor. Det vigtigste er at vide, at »Exit Nodes« er de servere, hvor Tor-klienterne routes ud anonymt.
Jeg er ganske klar over, at Tor kan anvendes til helt legitime forhold, og at det kan have sin berettigelse i mange sammenhænge, men desværre er det overvejende brugsmønster af mistænkelig karakter. En sikkerhedsbevidst virksomhed kan derfor forsvare et strategisk valg om helt at fravælge kommunikation med Tor-brugere.
Gammel vin på nye flasker?
For nogle år siden skrev jeg et VBScript, som downloadede en liste over Tor »Exit Nodes« og oprettede eksplicitte Deny-regler for hver af disse IP-adresser i regelsættet på Microsoft ISA og TMG firewalls.
Formålet med mit script var dengang at sikre, at der ikke kunne oprettes forbindelse til eller fra Tor »Exit Nodes« for interne klienter og servere på det firewall-beskyttede lokalnetværk.
I disse tider, hvor mobilitet er i højsædet i de fleste virksomheder, så er perimeter-tankegangen ikke længere tilstrækkelig. Det er ikke nok at blokere adgang i den centrale firewall, selvom det selvfølgelig stadig kan være gavnligt. Med WAN-tilsluttede laptops, split-tunneling VPN, DirectAccess og lignende teknologier, så er det i høj grad op til klienterne selv (typisk Windows) at gardere sig mod angreb.
Formålet med det nye script var derfor først og fremmest at få funktionaliteten ud på klienterne. Som en lille bonus blev det med central administration og mulighed for jævnlige opdateringer, da Tor netværket jo er relativt dynamisk.
Det kan gøres på mange måder
Jeg har gjort mig nogle forskellige overvejelser omkring hvordan funktionaliteten skulle implementeres.
Hvilken blokeringsmekanisme?
Først er der selve blokeringsmekanismen. Der er flere måder at sikre, at en Windows klient ikke kan kontakte (initiere forbindelse til) – eller kontaktes af – en given IPv4-adresse.
Først overvejede jeg faktisk at oprette »null routes« på klienten. Det findes dog ikke rigtig under Windows, men funktionaliteten kan dog emuleres med »Route Add« kommandoen. Med denne kommando kan man sikre, at en klient benytter en bestemt IP som gateway til en given destination (host eller subnet). Det kunne så være en »dummy« gateway adresse, hvilket svarer lidt til en »null route«.
Som alternativ kunne den lokale host firewall anvendes. Den indbyggede firewall i Windows (WFAS) er en oplagt kandidat, da det rent faktisk en rigtig fornuftig lokal firewall – hvis den altså er konfigureret korrekt. Dertil er den (forhåbentlig) aktiveret på alle Windows klienter og servere i forvejen (hvis ikke der anvendes 3. parts host firewalls).
Da route-tilgangen syntes lidt skrøbelig, og længst fra “best practice”, gik jeg efter en løsning baseret på WFAS.
Hvordan styrer vi så firewallreglerne?
Dernæst måtte jeg finde ud af hvordan disse firewallregler skulle oprettes og opdateres.
Én metode er at gå efter en lokal processtyring via »Task Scheduler«, hvor klienten selv henter en liste over Tor »Exit Nodes« jævnligt og ud fra denne opdaterer sin lokale WFAS konfiguration, f.eks. med »Netsh Advfirewall« kommandoen.
I stedet for »Nesh«, så kan der under Windows 8.1 og Windows Server 2012 R2 benyttes en ny PowerShell cmdlet kaldet »New-NetFirewallRule«. Hermed ville alle andre Windows klienter dog blive udelukket, hvilket er lidt synd når så mange stadig er på Windows 7 – og forhåbentlig ikke Windows XP, vel 
En absolut fordel ved den lokale tilgang er, at computere som ikke er medlem af et Active Directory domæne (hovedparten af private computere er standalone klienter), også ville have mulighed for at anvende scriptet. Dog vil det for virksomheden resultere i en alt for dynamisk og ukontrolleret tilgang til netværkssikkerheden.
Jeg valgte at fokusere på en typisk virksomheds behov, men det vil være relativt enkelt at skrive scriptet om til at virke for standalone klienter.
Synergien mellem Group Policy og PowerShell
Selve konfigurationen af WFAS kan snildt foregå fra en central Group Policy under Active Directory. Langt de fleste virksomheder er familiære med denne administrationsmetode.
En anden fordel med Group Policy er, at man ikke behøver at opdatere firewallpolitikkerne manuelt via Group Policy Management Editor. Mange policy-settings kan opdateres vha. et PowerShell script, som eksempelvis kan eksekveres fra en »scheduled task«, i kontekst af en brugerkonto som har skriveadgang til den pågældende GPO (og ikke så meget andet).
Det kræver blot, at der én gang oprettes en GPO til formålet, linker den til rette containere og/eller Organizational Units for Windows computerobjekter, og til sidst sætter korrekte filtre og rettigheder på.
Hvad har vi og hvad mangler der?
Mit script er som sagt alene udarbejdet som en inspiration til andre. Det medfører bl.a., at der formentlig er masser af ting som kan gøres mere elegant, smartere og hurtigere. Jeg har prioriteret en vis læsevenlighed, således at andre nemt kan modificere, hvor der måtte være specielle forhold, ønsker eller krav.
Scriptet har i nuværende form følgende funktioner:
- downloader en opdateret liste over »Exit Nodes« fra Tor-projektet
- udtrækker relevante IPv4-adresser fra listen
- validerer disse og konfirmere at de er offentlige (“IPv4AddressIsPublicHost”-funktionen kan pudses gevaldigt)
- opdaterer et nærmere specificeret Group Policy Object med de udtrukne IPv4-adresser (tilføje nye og slette gamle)
- skriver en logfil over processen
Der foretages minimal error handling, langt fra nok af til et professionelt driftsmiljø.
Jeg håber, at andre vil forbedre koden – og dele med os andre her på siden!
Ansvarsfraskrivelse
Enhver anvendelse af scriptet foregår på eget ansvar. Til gengæld kan det anvendes og redigeres uden omkostninger.
Funktionaliteten er testet på en Windows Server 2008 R2 Domain Controller, en Windows Server 2012 R2 Domain Controller og en Windows 7 klient med RSAT.
Download scriptet
Du kan hente scriptet i seneste version her!
Relevante links og artikler
- How to add a Null route in Windows
- Windows Firewall with Advanced Security Administration with Windows PowerShell
- How can I define null route on Windows Server 2008 R2 Standard
- Powershell: Use GPO to configure firewall settings
- Set-GPRegistryValue
- Max 1000 IPs in a WFAS rule
Skærmbilleder
GPO Unique ID (Guid) findes under Group Policy Management Console > Details fanebladet:
Under Group Policy Management Console > Settings kan man se de automatisk oprettede regler:
Her ses de oprettede inbound-regler under Group Policy Management Editor:
På de klienter og/eller servere, som rammes af GPO’en, vil de oprettede regler kunne ses under »Windows Firewall with Advanced Security«:
Scriptet opretter som standard en samlet log-fil og filer med de downloadede Tor-lister (én for hver kørsel):
Update: 31-03-2014 kl. 11:49, rettet slåfejl “Windows Server 2010″ til 2012.
Leave a Reply