Layer 2 port security og ACLs

Tid til lidt teknisk sikkerhed, kreativ brug af filtre på switche - ja, ikke firewalls, men switche. Vi var for nyligt 4. december til DIX.dk møde omkring ambitioner og planer for DIX, både spændende og lærerigt. Blandt andet vil DIX udvide med en lokation i Aarhus - udover de to i Lyngby og den nyeste på Interxion, Ballerup.

I den forbindelse talte vi for at der skulle konfigureres port sikkerhed på Lag 2 (L2), måske efter samme principper som der bruges på AMS-IX som har omkring "500 connected networks" på et kæmpe L2 netværk. Men er det overhovedet nødvendigt, hvad kan der ske?

Network hi-jacks

Vi oplevede desværre for nyligt at en ny type switch vi forbandt til vores netværk fik dele af netværket til at gå i sort, uden at vi kan finde ud af præcist hvad der skete - fordi loggen var utilstrækkelig. Den slags hændelser er vi naturligvis meget på vagt overfor, og vil gerne begrænse eventuel skade mest muligt. Vi har derfor forsøgt at lave et robust netværk med konfigureret spanning tree (STP) priority så bestemte switche er root, LACP til redundante links og ring strukturer med redundans fysisk mellem switchene (kræver STP).

Det viser sig dog at man ved en "vis størrelse" nok skal til at gentænke nogle dele. Eksempelvis er det generende at der sendes STP Topology changes når en server rebootes, blot fordi den pågældende switch og port ikke er konfigureret som en server port (edge, portfast alt efter leverandør).

Vi bruger ligeledes mange 10G porte til kundernes servere, og dermed skal netværket rundt være mindst 10G og typisk flere 10G konfigureret med LACP - hvoraf en del så grundet STP er inaktive ... Misforstå mig ikke, STP er fin og har en god opgave som den løser fint, under specifikke forudsætninger! Det er så op til dig at sikre at forudsætningerne opfyldes. Vi er dog bestemt heller ikke klar til at smide STP ud og springe på Juniper Q-fabric, Cisco Unified Fabric, Force10 TRILL m.fl. - better the devil you know.

Klassiske L2 problemer

Da vi nu har valgt at bruge STP vil det således være relevant at gøre vores bedste for at gøre det mere robust, og samtidig eksperimentere mere med L2 port security og ACLs - forstået bredt og inkluderende BPDU filterfunktionalitet m.v. Det er noget vi har villet gøre længe, men ikke har turdet gøre i alle de eksisterende setups. Heldigvis har vi dog jævnligt nye setup der skal konfigureres og derfor går vi nu hele vejen - med positivliste fremfor negativliste.

Men lad os lige starte med at vise hvad der sker hvis man intet gør og udsættes for basale angreb på Layer 2. Til dette brug tog jeg en lille Juniper EX2200-C med Junos 11.4R5.5 og legede med som proof of concept. Til at lave ballade valgte jeg en lille laptop med BackTrack 5 og standardprogrammerne macof og Yersinia.

Da jeg brugte macof - mac adresse overflow program kom der ret hurtigt følgende logs:

Aug 25 13:38:58 sfid[971]: ipc_pipe_write wrote only 2712 out of 2864 bytes
Aug 25 13:39:11 sfid[971]: ipc_pipe_write wrote only 2368 out of 3060 bytes
Aug 25 13:39:22 sfid[971]: ipc_pipe_write wrote only 2152 out of 3060 bytes
Aug 25 13:39:52 sfid[971]: ipc_pipe_write wrote only 2396 out of 2976 bytes

Det betyder at man nok skal forsøge generelt at begrænse antal MAC adresser pr port. Det kunne eksempelvis være max 10 pr port.

set ethernet-switching-options secure-access-port interface ge-0/0/6 mac-limit 10 action shutdown
set ethernet-switching-options port-error-disable disable-timeout 60;

Der kan yderligere vælges mellem forskellige actions, hvad der skal ske når maksimum nås: none, drop, log, shutdown - som vist er næsten selvforklarende. Jeg har også sat en automatisk enable ind, så efter 60 sekunder åbnes porten igen - det afhænger jo af hvor BOFH man vil være ;-)

Næste klassiske problem er at en switch laver ballade med Spanning Tree, enten fordi den overtager root eller blot flooder med fejl. Dette kan nemt simuleres med Yersinia STP tools, hvor specielt flooding med conf STP pakker gav bonus da switchen pludselig begyndte at logge følgende:

Aug 25 13:52:49 eswd[1024]: TASK_OS_MEMHIGH: Using 50401 KB of memory, 100 percent of available
Aug 25 13:53:48 eswd[1024]: TASK_OS_MEMHIGH: Using 51675 KB of memory, 102 percent of available
Aug 25 13:54:48 eswd[1024]: TASK_OS_MEMHIGH: Using 52113 KB of memory, 103 percent of available
Aug 25 13:55:48 eswd[1024]: TASK_OS_MEMHIGH: Using 52679 KB of memory, 104 percent of available
Aug 25 13:56:49 eswd[1024]: TASK_OS_MEMHIGH: Using 53322 KB of memory, 105 percent of available
Aug 25 13:57:49 eswd[1024]: TASK_OS_MEMHIGH: Using 53953 KB of memory, 107 percent of available
Aug 25 13:58:49 eswd[1024]: TASK_OS_MEMHIGH: Using 54583 KB of memory, 108 percent of available
Aug 25 13:59:49 eswd[1024]: TASK_OS_MEMHIGH: Using 55218 KB of memory, 109 percent of available
Aug 25 14:00:48 eswd[1024]: TASK_OS_MEMHIGH: Using 55841 KB of memory, 110 percent of available
Aug 25 14:01:48 eswd[1024]: TASK_OS_MEMHIGH: Using 56463 KB of memory, 112 percent of available
Aug 25 14:02:48 eswd[1024]: TASK_OS_MEMHIGH: Using 57090 KB of memory, 113 percent of available
Aug 25 14:03:48 eswd[1024]: TASK_OS_MEMHIGH: Using 57729 KB of memory, 114 percent of available
Aug 25 14:04:48 eswd[1024]: TASK_OS_MEMHIGH: Using 58364 KB of memory, 115 percent of available
Aug 25 14:05:49 eswd[1024]: TASK_OS_MEMHIGH: Using 59027 KB of memory, 117 percent of available
Aug 25 14:05:59 /kernel: Process (1024,eswd) has exceeded 85% of RLIMIT_DATA: used 57432 KB Max 65536 KB
Aug 25 14:06:46 fpc0 RT-HAL,rt_entry_create,2414: failed to allocate memory for route entry 
Aug 25 14:06:46 /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, err 5 (Invalid)
Aug 25 14:06:46 last message repeated 9 times
Aug 25 14:06:46 fpc0 RT-HAL,rt_entry_add_msg_proc,2702: route entry create failed 
Aug 25 14:06:46 /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, err 5 (Invalid)
Aug 25 14:06:46 last message repeated 3 times
...
Aug 25 14:15:00 last message repeated 10 times
Aug 25 14:15:00 fpc0 RT-HAL,rt_entry_create,2414: failed to allocate memory for route entry 
Write failed: Broken pipe

og min SSH faldt af - og en ping over switchen mellem to porte holdt op med at virke!

Konsollen virkede stadig så jeg kunne checke loggen og med ord som core dump bliver man aldrig helt glad :-D

Aug 25 14:22:06 fpc0 RT-HAL,rt_entry_create,2414: failed to allocate memory for route entry 
Aug 25 14:22:06 /kernel: RT_PFE: RT msg op 3 (PREFIX CHANGE) failed, err 5 (Invalid)
Aug 25 14:22:06 fpc0 RT-HAL,rt_entry_add_msg_proc,2702: route entry create failed 
Aug 25 14:22:06 fpc0 RT-HAL,rt_entry_add_msg_proc,2886: proto MSTI,len 48 prefix 00068:00000 nh 82 
Aug 25 14:22:06 fpc0 RT-HAL,rt_msg_handler,601: route process failed 
Aug 25 14:22:07 sfid[971]: task_process_events: no read/accept method for ASD.128.0.0.1 socket -1
Aug 25 14:22:07 sfid[971]: TASK_SCHED_SLIP: 9 sec scheduler slip, user: 0 sec 477339 usec, system: 0 sec, 723908 usec
Aug 25 14:23:04 mgd[1760]: UI_CHILD_SIGNALED: Child received signal: PID 1761, signal Broken pipe: 13, command='/usr/libexec/ui/show-support'
Aug 25 14:23:32 dumpd: Core and context for eswd saved in /var/tmp/eswd.core-tarball.1.tgz
Aug 25 14:24:24 /kernel: Process (1738,eswd) has exceeded 85% of RLIMIT_DATA: used 57584 KB Max 65536 KB
Aug 25 14:25:10 init: ethernet-switching (PID 1738) terminated by signal number 6. Core dumped!
Aug 25 14:25:10 init: ethernet-switching (PID 1872) started

Jeg håber lidt på at den eventuelt ville komme til sig selv, men til slut endte jeg med at reboote switchen. Jeg forsøgte efter reboot at genskabe problemet med Yersinia Attack STP "sending confg BPDU" (Configuration BPDU) og de andre STP angreb - hvilket gjorde at switchen hurtigt begyndte at beklage sig i loggen.

Switch and protect

Godt, der skal altså konfigureres noget beskyttelse mod STP BPDU, og gerne også andre ukendte protokoller - kunderne skal nok sige hvis en given protokol ikke virker. Lad os starte med det basale, vi ønsker at blokere BPDU fra "ukendte porte". Bemærk at hvis der er loops er det en MEGET dårlig ide at slå STP fra.

På Junos er der bpdu-block funktionalitet, der kan enables med

set ethernet-switching-options bpdu-block interface ge-0/0/6
set ethernet-switching-options bpdu-block disable-timeout 300

eller sætte porten i edge-mode og lade alle edge have bpdu-block

set protocols rstp bpdu-block-on-edge 
set protocols rstp interface ge-0/0/6.0 edge 
set ethernet-switching-options bpdu-block disable-timeout 300

NB: Det er normalt at BPDU block disabler en port, således at denne manuelt skal enables igen af en administrator, så pas på. Der findes på Junosmulighed for en disable-timeout, eksempelvis 300 sekunder som vist i eksemplet. Edge har yderligere den fordel at der ikke sendes BPDU ud på denne port, idet den forventes at være en end station.

Loggen når en port disables giver:

Aug 25 15:23:52 eswd[1023]: ESWD_BPDU_BLOCK_ERROR_DISABLED: ge-0/0/6.0: bpdu-block disabled port
Aug 25 15:23:52 mib2d[1011]: SNMP_TRAP_LINK_DOWN: ifIndex 510, ifAdminStatus up(1), ifOperStatus down(2), ifName ge-0/0/6

Denne løsning er fin, hvis man ikke har betalende kunder :-D

Filter it

Alternativet til at disable porten hvor der modtages BPDU er at filtrere pakkerne. Dette kan man gøre rimeligt nem med L2 filtre på mange platforme, men det er ikke noget som benyttes så ofte. Med udgangspunkt i beskrivelsen fra AMS-IX er der følgende ethertypes der skal tillades:

  • 0x0800 - IPv4
  • 0x0806 - ARP
  • 0x86dd - IPv6

AMS-IX har også forbudt al broadcast, undtagen broadcast ARP og multicast ICMPv6 Neighbour Discovery packets. Dette vælger jeg at se bort fra pt.

Jeg ender således med en configuration der indeholder dette.

ge-0/0/6 {
    unit 0 {
        family ethernet-switching {
            filter {
                input only-ip;          
            }                           
        }                               
    }                                   
}            
family ethernet-switching {
    filter only-ip {
        term allow-ip {
            from {
                ether-type [ arp ipv4 ipv6 ];
            }
            then accept;
        }
        term deny-therest {
            then discard;
        }
    }
}

Denne løsning er ekstremt simpel og dog fantastisk fleksibel - I kan selv udvide med andre Ethertypes som man kunne tænkes at ville tillade.

Konklusion

Det er muligt at filtrere på L2 og skræddersy sin egen løsning, her for at beskytte en delt infrastruktur. Specielt hvis din platform ikke har en automatisk enable af porten igen er det trist at skulle logge på en switch for at enable en port - og en service for en kunde.

Et andet brugsområde jeg har brugt L2 filtre er for at sikre at kun bestemte systemer på et VLAN kunne initiere TCP forbindelser - hvor der kunne blokeres for TCP pakker med SYN flaget til andre enheder på dette VLAN/IP-subnet.

Hvilke uløselige problemer kunne du forestille dig at løse således?

Links

https://www.ams-ix.net/technical/specifications-descriptions/port-securi... http://www.yersinia.net/ http://en.wikipedia.org/wiki/Spanning_Tree_Protocol

Henrik Kramshøjs billede
Henrik Kramshøj er internet-samurai hos Solido Networks. Han elsker netværkspakker tcpdump, wireshark, BackTrack, Metasploit og andre hackerværktøjer og blogger om sikkerhed, netværk og unix.

Kommentarer (4)

Mikkel Planck

Jeg har en stærk tro på, at forholdene er overordentligt godt struktureret på DIX'en, men desværre forholder det sig ikke sådan hos de fleste kunder, som selv har adgang til deres miljø. Af samme grund undgår jeg helst spanning tree, da kunder der selv roder i deres miljø, ofte formår at få forbundet 5 switche med minimum 15 forbindelser imellem sig. Det er her min hovedpine opstår, for lige pludseligt lyser alle switchene op, og der absolut ikke hul igennem nogen steder. Hvad er min pointe? Pointen er at hvis man ønsker at bruge spanning tree, så består kunsten i at strukturere sit miljø, så der ikke lige pludseligt opstår et totalt crash. Dette er naturligvis gældende uanset hvilke producenter man foretrækker, men har gjort at jeg typisk undlader at bruge det.

En god måde at opnå det samme på, er ved at bruge LACP, hvor du fysisk sagtens kan miste en forbindelse, uden at det hele går ned af den grund. Dog kræver det flere porte, og du kan helle ikke miste en hel switch og stadigvæk kørende, men det virker i hverdagen, hvor det er yderst sjældent at en hel switch dør.

Med hensyn til ACL'ere, så er det desværre en overset funktion, da de fleste admins ikke ønsker at lave for mange begrænsninger i selv netværket, men heller lukke af i firewall.

Per Kronborg Nielsen

Hvis man har et L2 Netvärk uden STP, uha det gaar nemt galt.
Generelt er min erfaring at man bör kigge pa alle Control Protockoller der starter med 08:xxx og overveje hvad man vil tillade.
Jeg arberder med PTO netvärk og vi bruger nogle gange MACinMAC til at tranportere L2 Control Protokoller og SP netvärket.

Jeg finder det ogsaa brugbart at isolere kunderne, saa funktioner som
MAC isolation, BRAS antispoofing og MAC FF er gode sikkerheds funktioner.

Simon Holm

Fint indlæg Henrik, men hvorfor ikke benytte nogle af de loop fri L2 løsninger du nævner? Det lyder som om du har flere forbehold end kun pris (som ikke behøver at være gal) og udnyttelse af eksisterende investering (som jeg har stor forståelse for)? Er det modenhed af produkterne eller for lidt føling med dem?

En rimelig lav autorecovery tid og hyppig monitorering af log eller traps for shutdown af porte er i øvrigt ofte et godt kompromis mellem at beskytte mod at fejlkonfiguration i kundeenden ikke lægger nettet ned for andre og at det ikke nødvendigvis betyder kunden er låst ude i lang tid hvis de får deres konfiguration på plads. Kan man nøjes med at filtrere i stedet for at lukke porte uden at netværket bliver udsat er det selvfølgeligt at foretrække.

Log ind eller opret en konto for at skrive kommentarer

IT Businesses