Opgave CCDP - Firewall

This article is under development....

Opgave CCDP

Enterprise Edge Design

Internet

Multihomed Single Boarder Router Architecture

Internet bliver leveret af 2 forskellige ISP'er med alternativt fremførte linier, for at sikre sig mod kabelbrud, eller interne routnings problemer. Vi kører Routning med de 2 ISP'er og importerer alle internet routes til vores internet switch.
Dette gør vi for at kunne vores sekundære ISP hvis den primære har routnings problemer, men kun for de routes det er nødvendige.
Vores primære internet forbindelse bliver en 100Mbit, der bliver brugt til alt, dog med regler for at StudNet og PaNet maks kan bruge 50% så der altid er plads til dem der arbejder. Den sekundære ISP linie bliver en 50Mbit, som folk fint kan leve med, indtil den primære bliver fikset igen. Skulle det vise sig at hastigheden bliver uacceptable kan linierne opgraderes.

For at sikre os at alt trafik løber den rigtige vej ud af vores netværk skal BGP localpreference værdien på den primære linie sættes op, så det altid er den der bliver valgt til udgående trafik. Ved BGP er der utrolig mange parametre man kan bruge for at styre trafikken ud af sit netværk, men knap så mange man kan bruge til indgående.
Nogle af dem man kan bruge er AS_PATH prepending. Det vil sige man tilføjer nogle dummy AS numre. Da BGP måler afstand i AS hops, vil den tage den korteste vej fra kilde til destination. Ved at lave AS_PATH prepending på det ene link, vil AS Hop længere ud i netværket bliver større og routen vil være knap så atraktiv.

For at sikre sig at alt trafik i en optimal situation kommer den rigtige vej ind i ens netværk, laver man AS_PATH prepending på det link der ikke skal bruges, linket vil så se ud som om det hat en længere AS_PATH til dit netværk og derfor mindre attrativ. Dette kan gøres sådan:

router bgp 300
 network 10.0.0.0

 neighbor 10.10.10.10 remote-as 100

 neighbor 20.20.20.20 remote-as 200
 neighbor 20.20.20.20 route-map as_path_prepending out

!Tilføjer 2 ekstra hops til dit netværk
route-map as_path_prepending permit 10
 set as-path prepend 300 300
end

Filtrering af trafik

Når man laver en multihomed løsning er der nogle faldgrupper man skal passe på. Hvis man ikke filtrerer på de AS numrer man importerer kan man importere sin egen routing tabel, gennem sin ISP og lave et loop. Eller hvis man ikke filtrere på de paths man sender vidre, kan man være transit AS for trafik der skal et andet sted hen. Lad mig komme med nogle eksepler.

Transit trafik filtrering

Hvis man har flere ISP'er og kører fuld routning med dem via eBGP får man alle deres routes, for at forhindre trafik mellem AS 100 og AS 200 vil løbe igennem ens netværk kan man filtrere alle eksterne AS'er fra i de udgående AS_PATH's. Det vil sige at AS 100 kun kender til AS 300 gennem linket og AS 200 også kun kender til AS 300 gennem linket til vores enterprise netværk. Dette vil forhindre at de 2 ISP'er kender nogle andre veje igennem os end til AS 300.

Et eksempel på configuration med transit trafik filtrering hvor man ikke sender nogle andre AS numre med i sine udgående routes.

router bgp 300
 network 10.0.0.0

 neighbor 10.10.10.10 remote-as 100
 neighbor 10.10.10.10 route-map localonly out

 neighbor 20.20.20.20 remote-as 200
 neighbor 20.20.20.20 route-map localonly out

ip as-path access-list 10 permit ^$

route-map localonly permit 10
 match as-path 10
end

Inbound Filtering

For at forhindre at man laver et black hole hvor trafik fra sig selv, til sig selv, ryger ud til ISP A og routed videre til ISP B hvorefter det kommer ind til dig selv igen, filtrere man sine egne ipadresser fra i indkomne routing updates. Derved sikrer man at ens netværk ikke kender andre veje til sig selv.
De 2 primære grupper man skal være opmærksom på:

• Martian adresse områder
  • RFC 1918 adresser. Skal bruges internt i en virksomhed og aldrig komme ud på internettet. 10.0.0.0/8, 172.16.0.0/12 & 192.168.0.0/16
  • Loopback adresser. 127.0.0.0/8 adresserne er reserveret til internt brug på en host, og skal derfor aldrig modtages udefra, eller routes.
  • Host autokonfigurations blok. 169.254.0.0/16 adresse området skal bruges for automatisk adresse tildeling når en DHCP server ikke forefindes.
  • 0.0.0.0/8 adresser. 0.0.0.0/8 adresserne er ikke tildelt og selv om nogle firmaer bruger dem, skal de ikke findes på internettet.
  • Test netværks adresser. 192.0.2.0/24 er reserveret for test og beregnet til brug i dokumentation og sample kode.
  • Klasse D og E adresser. Klasse D adresser bruges til multicast og bør derfor ikke bruges til unicast routning. Klasse E adresser er reserveret og derfor ikke i brug. Klasse D adresser = 224.0.0.0/4. Klasse E adresser = 240.0.0.0/4
• Sit eget netværk, for at undgå black holing

Da vores offentlige adresser ikke er fastlagt har jeg ikke smidt dem i configurationen:

ip prefix-list martians seq 5 deny 0.0.0.0/8 le 32 
ip prefix-list martians seq 10 deny 10.0.0.0/8 le 32 
ip prefix-list martians seq 15 deny 172.16.0.0/12 le 32 
ip prefix-list martians seq 20 deny 192.168.0.0/16 le 32 
ip prefix-list martians seq 25 deny 127.0.0.0/8 le 32 
ip prefix-list martians seq 30 deny 169.254.0.0/16 le 32 
ip prefix-list martians seq 35 deny 192.0.2.0/24 le 32 
ip prefix-list martians seq 40 deny 224.0.0.0/4 le 32 
ip prefix-list martians seq 45 deny 240.0.0.0/4 le 32 
ip prefix-list martians seq 50 permit 0.0.0.0/0

Info trukket fra RFC1918 & RFC3330

DMZ

Der oprettes DMZ zoner til hver logiske funktion, f.eks Mail og webservere i hver sin zone. For at samle og lette administration samles de forskellige zoner i en separat dmz context. Grunden til man deler den op skal bl.a. findes i sikkerhed, hvis man havde en stor DMZ ville man kunne bruge en kompromiteret server som springbræt til alle de andre servere. Med opdelingen ville man kun tilgå servere i samme gruppe, og da de forskellige grupper ikke ville have noget at snakke sammen om, bliver der nok en stor fed deny any any imellem dem.

WAN

På Univeristets hospitalet installeres 2 alternativt fremførte 500Mbit MPLS linjer fra samme udbyder da det er her hele regionens patient data er centralizeret og den vil fungere som hub for de andre sygehuse i regionen. Hvert af de andre regions hospitaler får en redundant 100Mbit MPLS.
Nogle af de overvejelser vi har gjort os omkring MPLS linierne er at de måske skal være dynamiske. Det vil sige man får en hurtig forbindelse men gennemsnittet skal holdes under en given trafik mængde. Vi har snakket om det da gennemsnits trafikken sikkert ikke vil være mere en hvad en 50Mbit kunne klare, men skal man fx bruge en 4 GB fil ville det tage 4000*8/50=640=6 min 40 sekunder at overføre filen. Dette er lang tid hvis man skal bruge den her og nu. En måde man kan lave flex forbindelser er ved at installere en 500Mbit forbindelse, men at man kun bruger de 500Mbit i bursts, og at gennemsnitet skal ligge på 50Mbit eller under. Dette ville gøre at samme fil kun tog lidt over et minut at hente.

QoS

I samarbejde med MPLS udbyderen tilkøbes der QoS for at så vidt muligt at kunne levere end to end traffik prioritering. Detaljerne om hvilke QoS muligheder der er vil afhænge af udbyderen men et eksempel kunne være 5 forskellige klasser baseret på IP precedence, med en kø dedikeret til IP telephony. Desværre har man sjældent som kunde nogen indflydelse på hvad der ryger i hvilke kører og båndbredde tildelingen. Så man må typisk remarkere pakkerne i sin edge. Det kan skabe problemer hvis man skifter mpls udbyder da to selskaber sjældent benytter den samme QoS model, eller hvis man benytter 2 forskellige udbydere, da pakker skal markeres forskelligt.

Sikkerhed

Network Management

På alle netværks enheder opsættes syslog til en central server i datacenteret, for bedre at kunne overvåge udstyret og bistå i fejlfinding. Alle enheder sættes også i samme omgang til at rapportere ind til en MARS appliance boks også placeret i datacenteret, for at kunne give et mere komplet billede af en sikkerheds situation. For at lette administration og configuration af sikkerheds enhederne installeres CSManger som giver et centralt adgangspunkt til udstyret.

CiscoWorks benyttes til at håndtere configurations ændringer samt bistå som syslog server for at hutigt og effiktivt at kunne mitigere fejl på netværket. SNMP traps for udvalgte begivenheder sendes til en central opsamler, her bør der benyttes SNMPv3 for at kunne benytte kryptering imodsætning til SNMPv1+2 hvor community strengene sendes i klar tekst. Et ressource monitorerings system opsamler via SNMPv3 statestik for de enkelte enheder såsom båndbredde, interface statistik, hukommelsesforbrug osv. Alle porte skal monitoreres selv access porte, da man så vil kunne se hvor eventuelle flaskehalse opstår.

Alt adgang til netværks enhederne håndteres med Tacacs mod en ACS server som authentikerer op imod AD'et. Gruppe politikker sættes op således at kun netværks administratorene har adgang. I de tilfælde hvor udstyret ikke kan nå acs eller Domain controllerne benyttes et lokalt brugernavn og password på de enkelte bokse. Der anbefales at der fastlægges en runtine hvor disse passwords med jævne mellemrum ændres.

IDS

Intrusion Detection System(IDS) er en enhed der overvåger det netværkstrafik den får tilsendt, og via nogle algoritmer og kendte signaturer kan finde og overvåge skidt trafik og give alarmer når der skal tages affære.
Der placeres en IDS sensor på den offentlige side af netværket for at kunne monitorere eventuelle angreb udefra og man kan derved hurtigt og effiktivt tage hånd om problemer indefra og udefra herunder DoS og reconnacence. Dette kan involvere et tæt samarbejde med internet udbyderne. Derudover tilknyttes der også IDS sensore til edge distribution da det er det centrale knudepunkt for data til og fra hele wan og dmz og remote access til enterprise campus.

Ekstern adgang

Eksterne firmaer som skal have adgang til interne ressourcer håndteres med minimal belastning på IT afdelingen, som i praksis udeler et brugernavn, password, definerer de tilladte ip addresser, og en vejledning til hvordan de installerer og opsætter vpn klienten. Løsningen består af vpn termination på en sæt ASA appliance bokse hvor der oprettes en access-liste til hvert firma eller person således at der kun er adgang til de nøvendige ressourcer og ikke hele det interne netværk. Til dette benyttes også en certificat server placeret i DMZ'en. Afhængigt af virksomhedens præferance kan Anyconnect klienten installeres permanent eller installere/afinstallere sig selv efter behov.

Al vpn terminering sker på et sæt ASA bokse som sidder parallelt med internettet. Vpn loadbalancing slåes til for at udnytte de tilgændelige ressourcer bedst muligt. Det anbefales at kasserne er ens, men det er ikke et krav. Der kan tilmed benyttes en vpn concentrator i clusteret.

Eksempel på dele af configuration af et eksternt firma:

<output omitted>
access-list companyXXX line 1 extended permit ip any <ip address> <subnet mask>

access-list companyXXX extended deny ip any any log disable
group-policy companyXXX internal
group-policy companyXXX attributes
 vpn-filter value companyXXX
 banner value companyXXX

ldap attribute-map AD_to_group_map
  map-value memberOf CN=companyXXX,LDAPCN companyXXX
<output omitted>

For medarbejdere der arbejder hjemmefra eller som har behov for at tilgå interne ressourer fra andre netværk, benyttes microsofts indbyggede remote access klient, hvor al opsætning styres via gruppepolitikker i AD'et.

Firewall

Firewallen skal bestå af 2 ASA 5540 som skal have et context (virtuel firewall) for hver net (StudNet, AdmNet, PaNet, MedNet) og det vil være med til at lave Active-Active. Når 2 ASA'er bliver bundled, ses de som en maskine, med en configuration, hvor man så deler context ud til hver af dem, så ASA 1 fx bliver aktiv for StudNet og PaNet, og ASA 2 bliver aktiv for AdmNet og MedNet, samt de er backup for hinanden.
Hver context er sin egen virtuelle firewall med seperate sikkerhedspolitikker og fungerer som havde det været adskilt i fysisk seperate enheder. En ting man dog skal være opmærksom på er at når en asa er i firewall multimode understøttes følgende features ikke:

• VPN
• Dynamisk routings protocol
• QoS
• Multicast routing

I vores foreslåede setup vil de forskellige context dele den offenlige ip addresse via et shared interface og nat tabellen bruges til classifier ind og på udgåede traffik klafficeres der på interfacet.

<output omitted>
hostname(config-if)# interface gigabitethernet 0/1.1
hostname(config-subif)# vlan 101
hostname(config-subif)# context MedNet
hostname(config-ctx)# allocate-interface gigabitethernet 0/1.1
hostname(config-ctx)# allocate-interface gigabitethernet 1/1
hostname(config-if)# interface gigabitethernet 0/1.2
hostname(config-subif)# vlan 102
hostname(config-subif)# context StudNet
hostname(config-ctx)# allocate-interface gigabitethernet 0/1.2
hostname(config-ctx)# allocate-interface gigabitethernet 1/1
<output omitted>

For at sikre os mod at brugerne i en context ikke tager alle firewallens ressourcer(cpu,ram) ved et overdrevet antal nat translations og samtidinge forbindelser tildeles hver context en procentdel af enhedens totale ressourcer. Det er dog ikke alle ressourcer hvor det kan lade sig gøre såsom antal hosts og application inspections. Bemærk at tallene i følgende eksempel måske ikke er retvisende da det vil kræve en større indsigt i den pågældende virksomheds traffik mønster.

hostname(config)# class MedNet
hostname(config-class)# limit-resource conns 40%
hostname(config-class)# limit-resource hosts 3000

hostname(config)# class AdmNet
hostname(config-class)# limit-resource conns 20%
hostname(config-class)# limit-resource hosts 2000

hostname(config)# class PaNet
hostname(config-class)# limit-resource conns 20%
hostname(config-class)# limit-resource hosts 2000

hostname(config)# class Default
hostname(config-class)# limit-resource conns 20%
hostname(config-class)# limit-resource hosts 9000