jekob heidelberg bloghoved

Sådan smider du Tor ud af dit netværk!

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

Skærmbilleder

GPO Unique ID (Guid) findes under Group Policy Management Console > Details fanebladet:

Illustration: Privatfoto

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.

Kommentarer (65)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jakob H. Heidelberg

Jeg er ikke interesseret i at censurere, men at beskytte. Man må altså forholde sig til den faktiske anvendelse af Tor og overveje om det er relevant for ens virksomhed.

Tyrkiet er da ude i noget grimt skidt med blokering af Twitter, og senere Tor-projektets hjemmeside, og jeg mener ikke det kan sammenlignes med mit script, eftersom Twitter ikke anvendes som angrebsplatform. Jeg er bestemt ikke interesseret i en ny kontrakt under det regime ;-)

  • 3
  • 13
Jakob H. Heidelberg

Min holdning til at styre/blokere processer på Windows er, at der skal anvendes AppLocker i whitelist mode, styret på certifikater (code signing) og/eller hash-værdier. Jeg vil senere komme ind på det på denne blog, men det er sådan set det samme jeg skrev om da teknologien hed Software Restriction Policies her:

http://www.windowsecurity.com/articles-tutorials/authentication_and_encr...

og:

http://www.windowsecurity.com/articles-tutorials/authentication_and_encr...

Det skal måske siges, at tanken var at forhindre, at en bruger - mod sin og virksomhedens vilje - begynder at kontakte Tor-baserede services. Det kunne være kommunikation initieret af en malware eller en RAT komponenet.

  • 1
  • 1
Erik Jensen

Jeg har blokeret hele Kina på mit hjemme netværk. Var træt af at se de brute force angreb i mine logs og 99% kom fra Kina.
Da jeg ikke skal kommunikere med nogen der, går det udemærket på trods af det var en ret lang liste af adresser.

  • 2
  • 0
Jakob H. Heidelberg

Du misforstår mig - eller jeg formulerer mig dårligt.

  1. Hvis en angriber kommer fra Tor, så er det ExitNodes hans potentielle ofre skal blokere for. Det er ift. indgående trafik på klienten.

  2. Hvis et offer rammes af en malware, som initierer en forbindelse mod en angriber, som har en lyttende service på Tor netværket, så er det ligeledes ExitNodes der skal blokere for på klienten. Jeg har ikke prøvet at sætte den del op.

Med andre ord: de som potentielt angriber mit netværk kommer fra Tor ExitNode-adresser. Er vi enige?

Som alternativ kan man hente hele listen over alle Tor-nodes - kun fantasien sætter grænser ;-)

  • 0
  • 5
Pelle Söderling

Sikkerhed i min verden er at ens systemer kan stå imod hvad end TOR brugere måtte finde på - ikke at forsøge at gemme sig fra alverdens måder folk kan anonymere sig på (hvor TOR jo blot er en blandt mange).

Basicly opnår du måske at blokere dig fra mange script kiddies derude, tilgengæld får du så ikke rigtig tested og afsløret fejl lige så grundigt og hvad så når de prof. kommer på besøg som er hyret til at udføre industri-spionage mod dig?

Når man er konstant under angreb, så lærer man at beskytte sig. Det mener jeg er langt bedre end at forsøge at gemme sig.

  • 10
  • 0
Pelle Söderling

Det jeg kan være mest bekymret for er at folk i organisationen begynder at slække en anelse på tingene nu hvor man har fjernet en af de store trusler og måske ikke længere er konstant under angreb (hvilket man normalt er hvis man driver en blot nogenlunde stor side - det er forbløffende automatiseret).

Jeg er egentlig lidt af den holdning at når alle udviklere og IT folk ved at vi dagligt er under angreb, så er der ingen sovepude og det er med til at holde folk skarpe og opmærksomme på truslerne.

Og jeg vil reelt meget hellere have at en script-kiddie opdager og udnytter et hul - så kan vi få det lukket - fremfor at nogen med mere alvorlige intensioner finder og udnytter det.

  • 4
  • 0
Esben Madsen

jeg nøjes pt med at blokeret HINET og China Telecom på min VPS (som hoster 5 domæner med mail og web) - det tager 99% af alle angrebsforsøg og de resterende er relativt distribuerede over verden... jeg benytter desuden fail2ban til at smide folk af efter nogle fejlforsøg... egentlig mest for at begrænse load og gøre logfilerne mere overskuelige...

  • 2
  • 0
Henrik Kramshøj Blogger

Hvis et offer rammes af en malware, som initierer en forbindelse mod en angriber, som har en lyttende service på Tor netværket, så er det ligeledes ExitNodes der skal blokere for på klienten. Jeg har ikke prøvet at sætte den del op.

Med andre ord: de som potentielt angriber mit netværk kommer fra Tor ExitNode-adresser. Er vi enige?


Nej, vi er ikke enige.

Et stykke malware som forbinder til Tor vil kunne omgå din filtrering. Det kan den fordi:

1) En Tor client går IKKE IND via en EXIT node, den går ind i Tor netværket gennem entry node, som ikke nødvendigvis er en EXIT node.

2) Dernæst (netop for at undgå censur) kan der bruges Tor noder som ikke er listet sammen med alle de andre, se https://www.torproject.org/docs/bridges

Så vi er ikke enige :-D

  • 15
  • 0
Jakob H. Heidelberg

Så vidt jeg kan læse det er vi enige omkring den indgående trafik (fra Tor til klient). Dog måske med undtagelse af bridges, som jeg lige skal sætte mig mere ind i. Umiddelbart er min antagelse, at udgående trafik fra Tor går via ExitNodes.

Jeg vil indrømme, at jeg selv var i tvivl om hvorvidt man overhovedet skulle oprette en Outbound regel. Men jeg besluttede at gøre det i de tilfælde, at der f.eks. er tale om en Windows Server, som anvendes til proxy/router.

Et andet scenarie jeg havde i tankerne for Outbound blokeringen var, såfremt en Tor-klient kunne formå at oprette en forbindelse mod én tilfældig host på nettet, fx dr.dk:TCP80, og så have en <TorExitnodeIP:TCP16053> som en malware kunne kontakte og anvendes som "service" (såfremt den dynamisk kan opdatere malwaren til at kontakte præcis denne IP og port). Det er et tænkt eksempel som jeg ikke har testet.

  • 0
  • 2
Jakob H. Heidelberg

Jeg synes det er rimelig komisk at en senior sikkerhedskonsulent i Enterprise Risk Services hos Deloitte synes at Tor er en alvorlig risiko men har det fint med Dropbox.

Det er selvfølgelig komisk, hvis man bare uden videre antager, at jeg anvender det professionelt og til andet end fri lagerplads til denne slags deling af materiale, som bare skal publiceres offentligt alligevel...

  • 6
  • 2
Jacob Pind

Malware og andet som bruger TOR vil da køre som en hidden service og aldrig kom via en exit node.
Exit nodes er hvor ting forlader tor og tilgår det alm. offenlige net, så det virker umidelbart som om en ikke helt har sat sig ind i hvordan det virker inden man har skrevet den artikel.

  • 4
  • 2
Jakob H. Heidelberg

Exit nodes er hvor ting forlader tor og tilgår det alm. offenlige net, så det virker umidelbart som om en ikke helt har sat sig ind i hvordan det virker inden man har skrevet den artikel.

Min artikel er alene skrevet med baggrund i den risiko, som ExitNodes udgør ift. indgående trafik. Jeg har ikke skrevet om malware-varianters faktiske eller potentielle anvendelse af Tor. Hvis der er noget teknisk galt skal det selvfølgelig rettes, men forudsætningerne for artiklen er alene at beskytte mod ExitNodes, hvor jeg antager at potentielle angribere kommer fra.

  • 1
  • 2
Josef Assad

Det er selvfølgelig komisk, hvis man bare uden videre antager, at jeg anvender det professionelt og til andet end fri lagerplads til denne slags deling af materiale, som bare skal publiceres offentligt alligevel...

OK, så dette script var tænkt til privat brug? Fordi budskabet ville jo ellers være at man som sikkerhedsadmin skulle have Dropbox installeret for at tilgå dit Tor blokeringsscript.

  • 3
  • 6
Troels Henriksen

Man bør skrive "basalt set" (eller "basically", hvis det skal være udenlandsk), ikke "basicly". Det samme gør sig gældende for "offentligt" ift. "publicly".

Derudover, så kan jeg godt følge det menneskelige argument i at holde serverne under konstant angreb, så man aldrig føler sig for sikker. Men i almindelighed, hvis man ser bort fra sådanne psykologiske faktorer, så er det altid en god idé at have mange sikkerhedslag. I princippet er en firewall jo som sådan aldrig nødvendig, hvis de tjenester der kører på netværket alle er sikre, men i praksis er det rart med så mange sikkerhedslag som muligt. man skal selvfølgelig passe på, at man ikke bare ender med en stor mængde meget dårlige sikkerhedsmekanismer, således at den samlede sikkerhed alligevel bliver utilstrækkelig. Det er lidt som med en burger - der nøjes man jo heller ikke med enten bøf, salat eller dressing, men kombinerer det hele.

  • 2
  • 7
Thomas Larsen

Grundlæggende læser jeg dit indlæg sådan at du har fundet en smart teknik til at foretage klient-baseret ip-filtrering på hvilket er nødvendigt i en verden hvor en it-chef ikke længere kan regne med at han har sikret organisationen når den centrale firewall er opdateret.

Så langt så godt.

Jeg synes imidlertid at du gør dit budskab en bjørnetjeneste ved så normativt at koble TOR ind i problematikken:

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.

Jeg er ret sikker på at firmaer som Belgacom, Cetel, Siemens og Alcatel-Lucent ville være mere interesseret i at bruge din løsning hvis den var præpopuleret med en liste over NSA's "man on the side"-servere.

På samme måde er jeg ret sikker på at eksempelvis Per Palmkvist fra JP-Politikens Hus ikke ville vinde accept blandt sine journalist-brugere for en sikkerhedsløsning der forhindrer dem i at kontakte kilder der vægter deres anonymitet højt.

Så sammenfatning: Fint nok at du har øje på at perimeter-sikring ikke længere etableres i virksomhedens centrale firewall men efter min mening er dit valg af TOR som grundlag for blacklistningen lidt for farvet af hvad det er for en type virksomheder der betaler jeres konsulentregninger :-)

  • 13
  • 0
Svenne Krap

Exitnodes er som så mange andre skriver trafik fra TOR til open net. Dette er "ydersiden" af torklientens forbindelse.. Indersiden altså fra tor-klienten til tor-netværket bruger ikke exit-nodes overhovedet (andet end hvis de er cohosted med bridge nodes mm).

Hvis du blokerer exitnodes, så "sikrer" du dig mod angreb udført mod dig via tor-netværket. Du beskytter ikke mod at computere i dit netværk kan kontakte tor.

Sidstnævnte er temmeligt svært by design, ellers ville slygelstaterne jo bare kunne blokere hele netværket (hvilket de jo også prøver på via DPI osv). Hvis TOR virker som det skal, så ser du data, der ligner udgående HTTPS (altså 443/tcp) og ikke rammer annoncerede tor-noder...

  • 0
  • 0
Jakob H. Heidelberg

Så sammenfatning: Fint nok at du har øje på at perimeter-sikring ikke længere etableres i virksomhedens centrale firewall men efter min mening er dit valg af TOR som grundlag for blacklistningen lidt for farvet af hvad det er for en type virksomheder der betaler jeres konsulentregninger :-)

Hej Thomas, tak for din kritik. Jeg er sådan set enig i dine kommentarer. Forstår godt at Tor er et politisk ømtåleligt emne. Jeg er tilhænger af dette netværk, men forstår også hvis et firma ønsker at isolere sig fra det, specielt med baggrund i informationer som disse:
http://securityaffairs.co/wordpress/22861/cyber-crime/tor-network-increa...

Jeg vil lige sige, at det bare er en løs idé jeg har gået og tumlet med, ikke en kundeopgave - så ville jeg heller ikke give den gratis væk ;-)

  • 1
  • 0
Jakob H. Heidelberg

Hvis du blokerer exitnodes, så "sikrer" du dig mod angreb udført mod dig via tor-netværket. Du beskytter ikke mod at computere i dit netværk kan kontakte tor.

Jeg er ganske enig - og det er også min oprindelige forståelse. Jeg er stadig usikker på de omtalte "bridges", men min forståelse er uændret også på dette område. Det er ExitNodes der er interessant for den type blokering, som jeg har lagt op til i artiklen og tilhørende script.

Jeg sikrer med Outbound reglen (som i øvrigt kan disables ved at bortkommentere en enkelt linje i scriptet, hvis man ikke skønner den nødvendig), at klienter ikke kan kontakte (initiere forbindelse til) ExitNodes. Rent praktisk er jeg enig i, at det ikke er nødvendigt, men det er alligevel en ekstra sikring, eksempelvis hvis der måtte være en svaghed i Tor ExitNodes stateful inspection teknologi. Teoretisk, I know.

Jeg vil lade det være op til andre om de vil aktivere denne udgående regel eller ej. Som sagt var jeg selv i tvivl om jeg ville tage den med i scriptet. Better to be sure than sorry I guess.

Scriptet vil med succes blokere Inbound trafik fra Tor-klienter. Andet har jeg vist ikke lovet :)

  • 0
  • 1
Lars Sommer

Velkommen som blogger Jakob :-)
Afledt af snakken om hvad TOR måske bruges til af ting og sager, kunne det være rigtig spændende med et blogindlæg med analyse af exitnode-trafik.
Køre en exitnode og logge alt i f.eks. tre måneder, og så analysere og skrive lidt om det..

  • 1
  • 1
Jakob H. Heidelberg

Tak Lars. Ja, det kunne bestemt være interessant. Der vil dog være nogle begrænsninger omkring SSL trafik, med mindre man har succes med et Man-in-the-Middle angreb... Det kunne måske være et udmærket projekt for en PhD studerende på DTU med adgang til fri båndbredde :)

En som har forsøgt lidt i denne dur:
http://ericholzbach.net/blog/2011/10/a-breif-analysis-of-a-tor-exit-node/

  • 0
  • 0
Morten Hansen

Det er en rigtig god idé og et lækkert værktøj man kan bruge som udgangspunkt. Tak for det.
Om jeg går ind for brug af Tor eller ej har intet at gøre med mit loyalitetsforhold til min arbejdsgiver, der forventer at jeg yder det bedste i hans interesse når jeg er under kontrakt med ham.
Det ser det ud til at der er en del i tråden her som har misforstået.
Ja, trafik ind i dit netværk fra tor skal i størstedelen af tilfældene blokeres. Det er i din interesse at beskytte dit netværk som netværks-/it-operatør at gøre det besværligere at kompromittere dig, og dette er endnu et værktøj der kan assistere med det. Tak.

  • 1
  • 7
Jacob Pind

Der kommer vel også nn fremtidig artikle omkring datakilder fra nettet og om man stoler på dem.
Så vidt jeg kan se downloader det script blind en file fra en uri som du pt stoler på, det er da at indføre endnu et problem punkt i ens opsætning den dag den liste indeholder en fejl.

  • 1
  • 0
David Nielsen

Er det ikke lidt forkert at have en open-by-default rule i firewall'en til alle hosts - og så forsøge at blokere xyz net?

I det net jeg manager har vi en default closed inbound rule - og explicit åbent til de få services de forskellige hosts tilbyder til internettet - og visse som fx. ssh via jumphosts kun.
Kunne også forholdsvist nemt lave en default closed outbound rule og explicit åbne op (men har dog ikke sat dette op endnu)

  • 2
  • 0
Jakob H. Heidelberg

Er det ikke lidt forkert at have en open-by-default rule i firewall'en til alle hosts - og så forsøge at blokere xyz net?

Selvfølgelig skal man have det. Jeg tror ikke, at jeg noget sted anbefaler open-by-default tilgang ;)

Deny regler (Block-rules) behandles i WFAS før Allow regler, så hvis man har åbnet for X port på en Windows server/klient, ved en fejl eller med vilje (trust me, det sker ofte specielt når man som mange steder lader brugerne være lokale admins - også for Public profilen), så vil reglen redde dagen.
http://technet.microsoft.com/en-us/library/cc755191%28v=ws.10%29.aspx

Den eksplicitte udgående Deny-regel kunne give mening i andre tilfælde, som vi er kommet lidt ind på i kommentarerne.

PowerShell scriptet viser Windows admins derude, hvordan man automatiseret opretter firewall regler på sine Windows klienter. Disse regler kan så være ind- eller udgående.

  • 0
  • 0
Jakob H. Heidelberg

Deny regler (Block-rules) behandles i WFAS før Allow regler, så hvis man har åbnet for X port på en Windows server/klient, ved en fejl eller med vilje (trust me, det sker ofte specielt når man som mange steder lader brugerne være lokale admins - også for Public profilen), så vil reglen redde dagen.


Det skal måske også lige siges, at det i større virksomheder er normalt, at have workstation og server admins i flere "lag", dvs. man som "top admin" kan sætte en overordnet "minimums-politik", og så give ansvaret for tilføjelser (herunder service-åbninger) videre til andre. Det kunne også være en anvendelsesmulighed for ovenstående script.

Til min tidligere kommentar skal det måske lige siges eksplicit, at "Default Deny" reglen i WFAS er i kategorien "Default Rules" og derfor har laveste prioritet, jf. linket ovenfor.

  • 0
  • 0
Jakob H. Heidelberg
  • 1
  • 1
Baldur Norddahl

Jeg forstår overhovedet ikke formålet med det her. Du skal ikke blokkere indgående trafik fra TOR exit nodes. Du skal blokkere ALT indgående trafik med oprindelse udenfor dit eget netværk. Der er absolut ingen grund til at have nogle specielle regler for TOR her.

Med hensyn til at blokere udgående trafik til TOR-exit nodes, så gør du bare det, men du spilder din tid. Der er ingen udgående trafik til TOR-exit nodes. Man kan ikke lave tjenester der lytter på exit nodes.

  • 2
  • 2
Jakob H. Heidelberg

Du skal ikke blokkere indgående trafik fra TOR exit nodes. Du skal blokkere ALT indgående trafik med oprindelse udenfor dit eget netværk.

Hej Baldur, prøv at læse tråden af kommentarer igennem, så vil du se, at dine pointer allerede er behandlet. De er ganske valide, men eftersom det er et blogindlæg, så kan jeg ikke dække samtlige pointer fra starten. Det synes jeg kommentarerne gør meget fint :)

Jeg mener fortsat også, at scriptet kan have stor værdi i de nævnte tilfælde, eller ift. at oprette automatiserede firewall regler i Group Policies.

Man kan ikke lave tjenester der lytter på exit nodes.

Jeg har også været inde på denne pointe her i tråden. Du forudsætter, at stateful inspection virker efter hensigten, og det er selvfølgelig også almindeligt, men jeg kan se en teoretisk mulighed for at angribe den vej. Så kan det selvfølgelig vise sig at være spild af tid - som så meget andet sikkerheds-research ;-)

  • 0
  • 1
Baldur Norddahl

Det vil muligvis gå lidt ud over størrelsen på ens brugerskare.

På en server, men manden snakker om klienter. Hvad er det lige for en service dine brugere har kørende på deres klientmaskiner og som kræver udefrakommende initierede forbindelser?

På en server er det bare ondt at blokkere for exit nodes. Det har ikke en skid med hackerbeskyttelse at gøre, men er blot samarbejde med alverdens diktatorer.

  • 6
  • 1
Baldur Norddahl

Hej Baldur, prøv at læse tråden af kommentarer igennem, så vil du se, at dine pointer allerede er behandlet. De er ganske valide, men eftersom det er et blogindlæg, så kan jeg ikke dække samtlige pointer fra starten. Det synes jeg kommentarerne gør meget fint :)

Så nemt slipper du altså ikke. Dit blogindlæg er vrøvl. Det er fint at skrive om hvordan man kan oprette firewall regler automatisk, men TOR vinklen holder ganske simpelt ikke.

Du skriver:

Deny regler (Block-rules) behandles i WFAS før Allow regler, så hvis man har åbnet for X port på en Windows server/klient, ved en fejl eller med vilje (trust me, det sker ofte specielt når man som mange steder lader brugerne være lokale admins - også for Public profilen), så vil reglen redde dagen.

Men hvis du nu i stedet lavede en regel der hedder DENY alle SYN der ikke kommer fra 192.168.1.x/24 (eller hvad dit lokalnet nu hedder), så har du effektivt og en gang for alle blokkeret for alle fejlmuligheder af den art. Det er jo bestemt ikke kun TOR noder du ønsker at blokkere her, så hvorfor udpege lige den tilfældige liste af IP-adresser, når du bare kan blokkere alle IP-adresser?

Jeg har også været inde på denne pointe her i tråden. Du forudsætter, at stateful inspection virker efter hensigten, og det er selvfølgelig også almindeligt, men jeg kan se en teoretisk mulighed for at angribe den vej. Så kan det selvfølgelig vise sig at være spild af tid - som så meget andet sikkerheds-research ;-)

Det er jo også vrøvl. En TOR exit node vil aldrig forwarde en TCP SYN pakke. Det er ikke stateful firewalling, det er end slet ikke firewalling. De lytter simpelthen ikke efter indkommende forbindelser på de IP-adresser.

Hvis der kommer trafik til en TOR exit node hvor der ikke først har været en SYN, så aner noden slet ikke hvor den skulle aflevere trafikken. Så kan man overvejer om man kan "vende" en TCP forbindelse, men hellere ikke den går, da du jo naturligvis blokkere alle indkommende SYN. Dermed kan der ikke komme en ACK tilbage og TCP forbindelsen kan aldrig etableres. Uden en etableret forbindelse er der ikke noget at vende.

  • 3
  • 2
Baldur Norddahl

Mandan snakker om både klienter og servere ;-)

Gør han? Hvorfor mener han så at man kan glemme at man har åbnet en forkert port på en server? De bliver jo periodisk scannet for åbne porte, hvis man ellers mener noget seriøst med sikkerhed. En server skal hellere ikke være tilgængelig udefra på andet end de få porte, hvor den yder en service (eksempelvis port 80 og 443 for en webserver).

På en server er firewall reglerne endnu enklere. De er: drop alt. Tillad kun port 22 fra din jump host og port 80/443 fra det åbne internet.

En intern server skal slet ikke tillade trafik udefra, så igen er det helt pointløst specifikt at blokkere for TOR.

  • 4
  • 1
Jakob Dalsgaard

Du forudsætter, at stateful inspection virker efter hensigten

Mjoo, ellers er det vel dumpekarakter til dit OS? Det er vel heller ikke ligefrem rocket science at kigge på SYN/ACK flag?

Øvelsen ser meget sjov ud -- kan måske bruges til at hjælpe folk med et ikke-sikkerhedsopdateret operativsystem -- men præmissen synes jeg ikke helt holder, grundet:

1) Hvis du er bange for at din stateful firewall ikke kan klare mosten, så skal den maskinen ikke på nettet.

2) Hvis du er bange for at Tor exit nodes skulle være specielt slemme til at bryde alm. handshake regler for at krybe igennem en firewall, så tror jeg du tager fejl. Det vil, så vidt jeg kan forstå, kræve at nogen har overtaget exit noden og installeret malware -- og hvorfor bruge så meget krudt på at overtage en exit node, når man har et helt internet af maskiner at tage af?

  • 2
  • 0
Jakob H. Heidelberg

TOR vinklen holder ganske simpelt ikke.

Hej Baldur. Det kommer altså an på scenariet. På server-siden giver det i mine øjne fint mening (med fare for at blive beskyldt for at støtte diktatur-stater, hvilket egentlig ikke er formålet). Oprindeligt var scriptet tiltænkt offentligt eksponerede servere, baseret på ISA/TMG firewall produkterne, hvor virksomheden ønskede at sikre, at Tor-brugere ikke kunne sidde og angribe eksponerede services absolut anonymt.

Jeg har så foreslået at rykke det ind i WFAS, som både kan styre servere og klienter - vha. samme administrationmetode. Og jeg er sådan set enig i, at det kan være lidt søgt på klient-siden, men jeg har rent faktisk i praksis stødt på klienter, som har fået en FW-policy fra domænet, at der åbner 445 på alle profiler, dvs. også Public. Ja, en admin har fået en hjerneblødning, men det er sket og det vil ske igen - og hvis man havde en eksplicit Deny fra et "højere lag", så ville metoden i det mindste sørge for at beskytte mod Tor-brugere (som er et reelt problem ift. hacking).

I et utal af andre tilfælde, er det brugerne selv som er lokal-administratorer, og de får undervejs åbnet for lidt af hvert - og tænker sjældent på hvilken FW profil de åbner for. En eksplicit Deny i baggrunden vil også her "overrule" hvad end de får lavet af Allow regler.

Hvad angår dine andre pointer, så kan du have ganske ret i at det er umuligt at komme ind i Tor via ExitNodes. Jeg betragter det bare ikke som en naturlov. Men så lad være med at aktivere den udgående regel.

Lad mig spørge Tor specialisterne her, hvad hvis man tager den store Tor-node liste, som jeg linker til i selve scriptet, og seneste bridges (f.eks. med en automatisere gmail mailkonti), vil man så ikke kunne lave et udgående regelsæt, som blokerer for at brugere - eller malware - kan smutte IND i Tor, via almindelige "EntryPoints"? Eller er det mere komplekst end det? Og mon malware overhovedet benytter Tor bridges?

  • 0
  • 2
Jakob H. Heidelberg

Hvis du er bange for at Tor exit nodes skulle være specielt slemme til at bryde alm. handshake regler for at krybe igennem en firewall, så tror jeg du tager fejl.

Det var dette teoretiske scenarie jeg var inde over. Du kan have helt ret. Jeg har som skrevet ikke testet det, men synes da det ville være værd at forsøge som lidt research (hvis man havde tiden).

  • 0
  • 0
Jakob H. Heidelberg

De bliver jo periodisk scannet for åbne porte, hvis man ellers mener noget seriøst med sikkerhed.

Jeg synes, at du her indfører en ny forudsætning. Det er desværre ikke mit indtryk at det er så almindeligt, men det burde være en naturlov.

En intern server skal slet ikke tillade trafik udefra, så igen er det helt pointløst specifikt at blokkere for TOR.

Tjo, men nu forudsætter du bare, at det er en intern server vi taler om. Det kunne vel også være en webserver. Eller hvad med din SSH server - er det vitterlig nødvendigt at åbne for administration af den fra Tor-klienter. Lad os sige, at du ikke aner hvor du er i verden om 14 dage, og du vil have muligheden for at administrere via SSH udefra, men du vil udelukke, at Tor-brugere kan forsøge at pille ved SSH stacken? Det er ikke anderledes for andre protokoller.

  • 0
  • 2
Baldur Norddahl

Tjo, men nu forudsætter du bare, at det er en intern server vi taler om. Det kunne vel også være en webserver. Eller hvad med din SSH server - er det vitterlig nødvendigt at åbne for administration af den fra Tor-klienter. Lad os sige, at du ikke aner hvor du er i verden om 14 dage, og du vil have muligheden for at administrere via SSH udefra, men du vil udelukke, at Tor-brugere kan forsøge at pille ved SSH stacken? Det er ikke anderledes for andre protokoller.

Vi kører med PCI-DSS sikkerhed så en åben SSH server er ikke tilladt. Man skal ind via en jump host og med en VPN tunnel og two-factor godkendelse. Til gengæld stiller PCI-DSS ikke noget krav om at man skal blackliste tilfældige IP-adresser, da det bare er fjollet. Hackerne kommer via deres botnets og IP-adresserne er nye hver gang.

  • 4
  • 1
Jakob H. Heidelberg

Til gengæld stiller PCI-DSS ikke noget krav om at man skal blackliste tilfældige IP-adresser, da det bare er fjollet. Hackerne kommer via deres botnets og IP-adresserne er nye hver gang.

Nu var forudsætningen jo ikke, at PCI-DSS skulle tilfredsstilles. Og ja, det kommer OGSÅ hackere fra botnets, men det er altså langt fra al Tor-trafik, der er absolut uskyldigt... Mange af os der ikke lige ejer botnets, vi ville måske gå den vej...

  • 0
  • 2
Baldur Norddahl

Nu var forudsætningen jo ikke, at PCI-DSS skulle tilfredsstilles. Og ja, det kommer OGSÅ hackere fra botnets, men det er altså langt fra al Tor-trafik, der er absolut uskyldigt... Mange af os der ikke lige ejer botnets, vi ville måske gå den vej...

De fleste af os ville undlade at hacke. Jeg har ingen årsag til at tro at jeg skulle blive angrebet fra TOR exit nodes mere end fra alle andre mulige IP-adresser. Der er legitim trafik fra TOR. Derfor er det ret dumt at blokkere og jeg tror chefen vil blive ret sur, hvis vi uden årsag afviser trafik.

Vi bliver angrebet mere eller mindre konstant. Og det er på ingen måde koncentreret på nogle få IP-adresser, som TOR exit nodes udgør. Jeg har ikke specifikt undersøgt om vi overhovedet ser angreb fra TOR-exit nodes, men det vil jeg da formode at vi gør. Det er jo ligemeget, da vi er nødt til at kunne modstå disse angreb uanset hvor de kommer fra.

  • 3
  • 0
Jakob H. Heidelberg

...jeg tror chefen vil blive ret sur, hvis vi uden årsag afviser trafik.

Måske din chef, men der findes jo andre chefer, virksomheder og organisationer, som kan have andre behov. Jeg har været konsulent i mange år og den slags varierer voldsomt.

Det er jo ligemeget, da vi er nødt til at kunne modstå disse angreb uanset hvor de kommer fra.

Det er jeg også helt enig i. Her taler vi selvfølgelig begge om den helt lyserøde og ideelle verden. Men hvis man ønsker at forhindre Tor ExitNodes i at snuse rundt, så kan man bruge scriptet. Jeg har ikke krævet, at folk faktisk gør dette, men blot vist en metode.

  • 0
  • 0
Baldur Norddahl

Jaja, det skal du jo sige ;-)

Lidt afsluttende ord. Hackere bruger TOR til at styre deres botnet, men botnets til at angribe dig. TOR er for langsomt og upålideligt til et direkte angreb. Det er muligt at der er nogle amatør-hackere der kunne finde på at forsøge sig, men de er sjældent den reelle trussel.

Der findes legitime grunde til at blokkere TOR. Det kunne for eksempel være at du har et debatfora eller en gaming server, hvor der er problemer med trolls der kommer ind via TOR. Men at argumentere for at det har nogen som helst effekt i forhold til hackere, det er /snakeoil/.

Hvis du vælger at blokkere TOR-exit noder og andre mere eller mindre tilfældige IP-adresser på din webserver, så gør du skade uden at have noget gavn af det.

Hvis du gør det samme på din ssh server er det din egen sag. Men jeg vil anbefale at man i stedet bruger tiden på at konfigurere nogle firewall regler der har en reel virkning. Det kunne for eksempel være http://en.wikipedia.org/wiki/Port_knocking.

Men jeg tror vi må slutte med at blive enige om at være uenige.

  • 3
  • 0
Jakob H. Heidelberg

Men jeg tror vi må slutte med at blive enige om at være uenige.

Enig. Du kan ikke bare sige, at hackere bruger Tor til en given ting og kun det. En hacker som ikke har et botnet kan da sagtens vælge Tor til at angribe sit offer igennem. Det kommer an på hvem han/hun er. Jeg har jo intet sted skrevet, at man lukker for alle hackere - der er efterhånden en vis tendens til at ændre forudsætningerne for blogindlægget løbende.

  • 2
  • 0
Jakob H. Heidelberg

Det basere du på? Hvis du ved hvordan Tor fungere, vil du også vide at man ikke kan vide det..


Det er faktisk behandlet af andre i tråden ovenfor, hvor der linkes til studier fra exit nodes, ligesom jeg i indlægget linker til en artikel om sagen. Derudover ved jeg positivt, at Europol m.v. har kraftige problemer med Tor. Spørg endelig Troels Ørting fra EC3 hvis du er i tvivl.

  • 1
  • 1
Hans Schou

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.

For nogle år siden skrev jeg et bash-script, som downloadede en liste over Tor »Exit Nodes« og oprettede eksplicitte Deny-regler for hver af disse IP-adresser i regelsættet på Juniper 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.

Formålet med mit script var dengang at sikre, at der ikke kunne udføres et DoS angreb på en en af mine kunder.

Nu sidder der nogle teenagere ude i det ganske land der ikke helt fatter hvad det drejer sig om. Om de forstår det eller ej, er jeg sådan set ligeglad med. Hvis mit netværk er under andreb, så beskytter jeg det med de midler jeg nu har. Jeg lader ikke bare stå til. Så jeg fandt hurtigt ud af at jeg "bare" skulle blokere for TOR (som det hed dengang), så var mine problemer løst og jeg kunne gå i seng.

Angrebet varede kun få dage, så jeg fjernede mit filter igen da det stoppede.

Nu havde jeg ret mange domæner, og der var rent faktisk en del af dem hvor det gav mening at en embedsmand henvendte sig anonymt, og for at gøre det, brugte han så TOR. Hav nu venligst lidt fantasi - det giver mening! Så da angrebet døede ud, så åbnede jeg igen for TOR.

Er man "the evil one" hvis man blokere for TOR? Næh, dem der misbruger TOR til selvtægt er "the evil one". De syntes nok de havde en legitim grund til at angribe min kunde, men det syntes jeg så ikke.

(iøvrigt et spøjst tiltag med at spærre for torrent, som en anden nævnte. Ja ja, det er en glide bane, men det giver mening. Red Barnet lukker også øjnene for overgreb mod børn, uden at gøre noget ved det.)

  • 3
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize