Wilhelm Käll. Rapport nätverkssäkerhet

Transkript

1 Rapport nätverkssäkerhet Wilhelm Käll

2 Innehåll Introduktion Topologi / design Installation enheter Konfiguration av nätverksutrustning Konfiguration av switch s1a9.a9.se VLAN Portar SSH DHCP Konfiguration av router r1a9.a9.se Tillgång till internet SSH BIND Installation av BIND Konfiguration av BIND OpenLDAP Installation av OpenLDAP Konfiguration av OpenLDAP FreeRADIUS Installation av FreeRADIUS Konfiguration av FreeRADIUS Logging Accesspunkt ACL Förbättringar Reflektion Referenser Appendix A r1a9.a9.se - router... Appendix B s1a9.a9.se switch... Appendix C eap.conf - FreeRADIUS... Appendix D LDAP - FreeRADIUS... Appendix E default - FreeRADIUS... Appendix F inner-tunnel - FreeRADIUS... Appendix G zone-a9.se - BIND... Appendix H db-index.ldif - OpenLDAP... Appendix I init-tree.ldif - OpenLDAP... Appendix J ldap.conf - OpenLDAP... Appendix K rsyslog.conf - Rsyslog server... Appendix L rsyslog.conf Rsyslog klient... Appendix M clients.conf FreeRADIUS...

3

4 1.0 - Introduktion Uppgiften bygger på scenariot att ett företag vill implementera en centraliserad lösning för autentisering via 802.1x. Anställda på företaget skall kunna ansluta till det trådlösa nätverket med användaruppgifter som finns lagrade på en katalogserver. Användarnas lösenord skall lagras i krypterad form för att undvika spridning av dessa vid ett eventuellt angrepp av katalogservern. Nätverket skall även vara designat på ett sätt där säkerhet sätts i fokus. När gruppen planerade arbetet valde vi från början att hålla topologin så simpel som möjligt. Anledningen till det valet är att administrationen blir hanterbar på ett sätt som inte nödvändigtvis hade varit möjlig ifall en mer komplex design hade valts. Målsättningen från gruppens sida var att hålla det enkelt, säkert, funktionabelt samt effektivt. I rapporten kommer kodsnuttar att demonstreras för att visa hur viss funktionalitet implementerades. Koden som demonstreras kommer även att återfinnas i sin helhet som appendix. 1.1 Topologi / design Följande utrustning och system användes i laborationen för att skapa den fullständiga topologin: Cisco router r1a9.a9.se. Cisco switch s1a9.a9.se. VMWare ESXi Debian 7.0 radius.a9.se. Debian 7.0 ldap.a9.se. Debian 7.0 dns.a9.se. Debian 7.0 logging.a9.se. Windows 7 Zyxel accesspunkt De fyra Debian 7.0 installationerna är virtuella gästsystem installerade på den fysiska enheten med VMWare ESXi. De virtuella systemen kommer att tillhandahålla tjänster som behövs för att hålla nätverket fungerande. Exempel på detta är DNS(Domain Name System) som tillhandahålls av servern dns.a9.se. Routern r1a9.a9.se, switchen s1a9.a9.se och den trådlösa accesspunkten utgör själva fundamentet för nätverket. Alla enheter kommer att vara anslutna till en och samma switch s1a9.a9.se, av den anledningen skapades två VLAN(Virtual Local Area Network), ett för anställda och ett för administratörer. Utöver segmenteringen med VLAN skapades två subnät för varje grupp av användare. Följande information ger en beskrivning över hur nätverket är konfigurerat för att skilja på de två användargrupperna: VLAN 10: Management subnät: /24 VLAN 20 : Employees subnät: /24 De fyra Debian-servrarna och Windows-klienten ligger på VLAN 10 medans övriga klienter kommer att tillhöra VLAN 20. Via en trunk-port kopplas routern och switchen samman i ett router on a stick utförande för att möjliggöra initial obehindrad kommunikation mellan de två subnäten. Kommunikation mellan enheter på de två olika subnäten skall i slutskedet vara begränsad i viss mån för att öka säkerheten. Olika trafiktyper kommer dock att tillåtas för att klienter på nätverket för de anställda skall kunna nå tjänster som befinner sig på administratörs-nätet. För att de två användargrupperna skall kunna kommunicera med varandra kommer trafiken att gå via routern. Av den anledningen kommer att olika säkerhetsrutiner att implementeras där. 1

5 Domänen som skapades för laborationen är a9.se. Alla enheter kommer att använda sig av a9.se i sina respektive FQDN(Fully Qualified Domain Name). 1.2 Installation enheter De fyra servrarna som skall användas för att tillhandahålla diverse tjänster kommer att vara virtuella för att undvika att använda fler fysiska maskiner än för oss nödvändigt. För att möjliggöra installationen av de fyra systemen installeras VMWare ESXi på en av de två fysiska systemen. När installationen av värdsystemet är färdigställd installeras de fyra virtuella Debian-systemen som gästsystem. Installationen av Debian görs i ett minimalt utförande för att undvika att för oss onödig programvara installeras på systemen. Varje system tilldelas 10GB i utrymme för filsystem. Under installationen av de virtuella systemen valdes alternativet att använda hela det tillgängliga utrymmet för ett filsystem där all data sedan kommer att lagras. Filsystemet som valdes för de virtuella servrarna är ext4. Under installationen av de virtuella systemen namngavs de även. Gruppen ansåg det vara lättast att ha namn som är direkt ansluta till den typen av tjänst de tillhandahåller. Det innebär att servern som tillhandahåller OpenLDAP namnges till ldap.a9.se och servern som tillhandahåller FreeRADIUS namnges till radius.a9.se. Enheten som skall agera klient installerades med Windows 7 x64. Inga modifikationer gällande konfiguration utfördes på enheten. Installation av VMWare client utfördes för att kunna hantera de virtuella servrarna via ett grafiskt gränssnitt. Senare under projektets gång konfigurerades VMWare till att automatiskt starta de installerade gästsystemen vid uppstart vilket resulterade i att client.a9.se blev onödig. 1.3 Konfiguration av nätverksutrustning De två olika användargrupperna som befinner sig på samma fysiska topologi skall hållas i sär. Av den anledningen måste viss konfiguration utföras på nätverksutrusningen. Delar av konfigurationen är den samma på både switchen s1a9.a9.se och routern r1a9.a9.se. Exempel på detta är att lösenord sätts för anslutningar via konsollen samt lösenord för att kunna komma in i privileged exec mode. Alla lösenord som finns i konfigurationsfilerna lagras i krypterad form med hjälp av kommandot: service password-encryption Hur de två enheterna säkrades med lösenord för allt annat än SSH kommer inte att nämnas ytterligare Konfiguration av switch s1a9.a9.se Switchen som användes i laborationen har 24 portar av typen FastEthernet samt ytterligare två portar av typen GigabitEthernet. De 24 portarna av typen FastEthernet kommer att användas för enheter på båda näten medans en av portarna av typen GigabitEthernet kommer att användas för trunklinje mellan switchen och routern för att kunna skicka trafik från de två VLANen till routern r1a9.a9.se VLAN Två VLAN skapas på switchen för att kunna dela upp de tillgängliga portarna för de två användargrupperna som skall finnas. Tidigare i rapporten nämndes det att VLAN 10 och VLAN 20 skall skapas för de två grupperna. Stycket nedan behandlar hur portarna sedan tilldelades respektive VLAN. Genom att köra följande kommandon i konfigureringsläget på s1a9.a9.se skapas önskade VLAN: vlan 10 name management På samma sätt som beskrivet ovanför skapas det andra VLAN 20 för employees Portar De 24 portarna delades upp i två grupper, en grupp för management och en grupp för employees. Detta 2

6 innebär att port 1-12 tillhör VLAN 10 och är ägnade åt management. Koden nedan visar hur konfigurationen för ett interface tillhörande VLAN 10 ser ut, konfigurationsfilen finns tillgänglig i sin helhet i Appendix B: interface FastEthernet0/1 switchport access vlan 10 switchport mode access Portarna kommer att tillhöra VLAN 20, det vill säga employees. Konfiguration för en av dessa portar går att se nedan, konfigurationsfilen finns tillgänglig i sin helhet i Appendix B: interface FastEthernet0/16 switchport access vlan 20 switchport mode access När en enhet kopplas in till någon av de två spannen av portar kommer de automatiskt att tillhöra aktuellt VLAN. Exempelvis: om en enhet kopplas in i port 3 på switchen s1a9.a9.se kommer den att tillhöra VLAN 10 och ha större rättigheter än en klient som skulle vara inkopplad på port 16 och tillhöra VLAN 20 som är nätet för de anställda på företaget. För att trafik från de två separata VLANen skall kunna färdas till routern r1a9.a9.se behövs en trunk. För detta syftet dedikerades en GigabitEthernet-port. Nedan kan ni se konfigurationen för aktuell port, konfigurationsfilen finns tillgänglig i sin helhet i Appendix B: interface GigabitEthernet0/1 switchport trunk allowed vlan 10,20 switchport mode trunk Porten FastEthernet 0/24 konfigureras som trunk. Den aktuella porten kommer att användas för att koppla samman switchen s1a9.a9.se och den trådlösa accesspunkten. Kodstycket nedan demonstrerar konfigurationen för porten, konfigurationsfilen finns tillgänglig i sin helhet i Appendix B: interface FastEthernet0/24 switchport trunk allowed vlan 10,20 switchport mode trunk SSH För att säkra tillgången till switchen byttes Telnet ut mot SSH(Secure Shell). Följande rader kod är ett utdrag ur konfigurationsfilen efter att Telnet hade bytts ut mot SSH, konfigurationsfilen finns tillgänglig i sin helhet i Appendix B: line vty 0 4 login local transport input ssh line vty 5 15 login local transport input ssh SSH kräver att ett domännamn är konfigurerat samt att RSA-nycklar är genererade innan det kan användas. Två kommandon krävs för att utföra detta: ip domain-name a9.se crypto key generate rsa 3

7 För att kunna logga in via SSH lades en specifik användare till på s1a9.a9.se som skall användas vid inloggning via SSH. Utdraget nedan är användaren som skall användas vid SSH-anslutningar och det krypterade lösenordet. username admin privilege 15 secret 5 $1$DLFp$K4nG32DDUd3Rf1w/8qCme. För att kunna få tillgång till switchen via SSH sattes det en IPv4-adress på VLAN 10. Följande stycke kod är ett utdrag ur konfigurationsfilen, konfigurationsfilen finns tillgänglig i sin helhet i Appendix B. interface Vlan10 ip address no ip route-cache DHCP Klienter som ansluter till switchen skall automatiskt bli tilldelade en nätverkskonfiguration via DHCP(Dynamic Host Configuration protocol). För att möjliggöra detta skapades två DHCP-pooler, en pool som ansvarar för tilldelning av adresser till klienter som ansluter till management och ytterligare en för employees. Koden nedan är ett utdrag från konfigurationen för s1a9.a9.se, konfigurationsfilen finns tillgänglig i sin helhet i Appendix B: ip dhcp pool S1A9V10 network default-router dns-server domain-name a9.se Konfigurationen ovanför talar om för s1a9.a9.se att dela ut adresser inom subnätverket /24, vilken gateway som skall användas, vilken DNS-server som skall användas och slutligen vilken domän de tillhör. För att inga adresskonflikter med servrarna eller nätverksutrusning skall uppstå vid utdelning av adresser tillåts det endast att adresser efter och delas ut. Spannet med adresser som finns tillgängligt är således och Utdraget nedan visar hur begränsningen av DHCP-poolen utförs, konfigurationsfilen finns tillgänglig i sin helhet i Appendix B: ip dhcp excluded-address ip dhcp excluded-address Konfiguration av router r1a9.a9.se Routern konfigureras för att stödja trafik mellan de två näten som skapades för management och employees samt trafik som skall gå ut till internet. Tidigare i rapporten nämndes det att switchen och routern skall konfigureras i ett router on a stick utförande. För att routern skall kunna stödja trafik mellan de två olika VLANen skapas två subinterfaces för respektive VLAN. Följande kodsnutt visar hur subinterfacet för VLAN 10 skapades, konfigurationsfilen finns tillgänglig i sin helhet i Appendix A: interface GigabitEthernet0/0.10 encapsulation dot1q 10 ip address ip nat inside Ytterligare ett subinterface skapas för att stödja trafik från VLAN 20. Efter att de två subinterfacen har skapats och konfigurerats kommer routern r1a9.a9.se att kunna skicka trafik mellan enheter som tillhör olika VLAN. Trafik mellan VLAN 10 och VLAN 20 kommer i ett senare skede att begränsas. 4

8 1.3.7 Tillgång till internet Subnätet /30 blev tilldelat för att kunna komma ut på internet. För att kommunikation skall kunna ske måste ett NIC(Network Interface Card) konfigureras. Gränssnittet GigabitEthernet 0/1 valdes för uppgiften. För att möjliggöra kommunikation måste gränssnittet konfigureras med en IP-adress samt att en route skapas. Multipla enheter på de två separata näten skall även kunna kommunicera med enheter på internet. För att möjliggöra detta implementerades PAT(Port Address Translation). Först konfigureras GigabitEthernet 0/1. En adress lades till på gränssnittet. Följande kod är konfigurationen för nätverksgränssnittet, konfigurationsfilen finns tillgänglig i sin helhet i Appendix A: interface GigabitEthernet0/1 ip address ip nat outside ip virtual-reassembly in duplex auto speed auto För att enheter skall kunna använda gränssnittet för att kommunicera med enheter på internet lades en default-route till för att all trafik som inte är ämnad för enheter på de två nätverkssegmenten skall passera via det aktuella gränssnittet. Kommandot nedan visar hur routen lades till: ip route För att multipla enheter skall kunna kommunicera samtidigt med enheter på internet konfigureras PAT. GigabitEthernet 0/1 konfigureras för att vara outside interface medans de två subinterfacen för VLAN 10 och VLAN 20 konfigureras för att vara inside interface. För att PAT skall veta vilka adresser som tillåts att översättas skapas en ACL(Access Control List) som innehåller regler som tillåter att enheter som ingår i något av de två subnäten listade nedan kan översättas. Utdraget nedan beskriver aktuell ACL, konfigurationsfilen finns tillgänglig i sin helhet i Appendix A : ip access-list extended NAT permit ip any permit ip any Sist startas PAT genom att köra följande kommando i konfigureringsläget på r1a9.a9.se: ip nat inside source list NAT interface GigabitEthernet0/1 overload System som ligger på de två nätverkssegmenten skall nu kunna kommunicera samtidigt med enheter som finns på internet med hjälp av PAT SSH SSH aktiveras på r1a9.a9.se på samma sätt som beskrivs i Klienter på de två nätverkssegmenten kan ansluta till routern via adressen och Initialt är det tillåtet för klienter som tillhör subnätverket /24 att ansluta till r1a9.a9.se via SSH, det kommer dock att nekas i ett senare skede. 5

9 1.4 - BIND Servern med FQDN dns.a9.se skall ansvara för DNS på nätverket. Anslutna enheter på de två nätverkssegmenten skall använda servern som primär server för DNS-uppslagningar. Domänen som användes i laborationen är a9.se. Det innenär att den aktuella servern kommer att vara den som ansvarar för tidigare nämnd domän. Mjukvaran som användes i laborationen för namnuppslagningar är BIND(Berkeley Internet Name Domain) Installation av BIND För att installera BIND användes verktyget APT(Advanced Packaging Tool) som ingår i Debian. Med hjälp av APT kan förkompilerade paket hämtas hem från ett bibliotek med samlad mjukvara och sedan installeras. (Gustavo Noronha Silva, 2005) Följande kommando användes för att hämta hem och installera BIND på servern dns.a9.se: apt-get install bind Konfiguration av BIND När BIND har installerats har dess konfigurationsfiler placerats i mappen /etc/bind. Standardkonfigurationen har stöd för namnuppslagningar på internet med hjälp av root-hints som finns lagrade i filen /etc/bind/db.root. För att namnuppslagningar inom domänen a9.se skall fungera måste ett antal tillägg göras i konfigurationen. Det första steget är att deklarera zonen a9.se i filen /etc/bind/named.conf.local. Utdraget kod nedan visar hur deklarationen utförs samt det fullständiga innehållet i konfigurationsfilen: zone "a9.se" IN { ; type master; file "/zones/zone-a9.se"; Koden ovanför talar om för BIND att den ansvarar för zonen a9.se samt att zone-datan finns tillgänglig i filen /zones/zone-a9.se. Filen zone-a9.se är den filen som innehåller alla DNS-poster samt information om zonen. Alla systems vars FQDN skall kunna användas vid kommunikation inom nätverket skall finnas tillgängliga i filen. Ett exempel på hur DNS-poster defineras i filen går att se nedan, filen finns tillgänglig i sin helhet i Appendix G: r1a9 IN A ldap IN A De två raderna kod ovan talar om för BIND att r1a9.a9.se har adressen samt att ldap.a9.se har adressen Anslutna klienter som utför en namnuppslagning på ldap.a9.se kommer få ett svar av BIND att adressen är Slutligen måste dns.a9.se konfigureras för att använda sig själv när namnuppslagningar utförs. Detta utförs genom att modifiera filen /etc/resolv.conf. Raderna kod nedan talar om för servern att den skall använda sig själv vid uppslagningar samt information om domänen: search a9.se domain a9.se nameserver

10 1.5 - OpenLDAP I laborationen valdes OpenLDAP för katalogiseringen av användare. I katalogen kommer uppgifter om de olika användarna lagras. De användarkonton som finns i katalogen är de som senare skall kunna användas för att autentisera sig via det trådlösa nätverket. Användarnas uppgifter sparas som uidobjects i LDAP-katalogen(Lightweight Directory Access Protocol). Varje objekt har två attribut som är centrala för autentiseringen: uid(user Identity) samt userpassword. OpenLDAP har stöd för en mängd olika krypteringsmekanismer vilket tillåter att användarnas lösenord lagras i krypterad form.(openldap Foundation, 2011) Servern som skall ansvara för driften av OpenLDAP är maskinen med FQDN ldap.a9.se Installation av OpenLDAP Installationen av OpenLDAP utförs med hjälp av verktyget APT. Paketet som skall hämtas och installeras för OpenLDAP heter slapd. Genom att köra kommandot nedan kommer OpenLDAP att installeras. apt-get install slapd Konfiguration av OpenLDAP Under installationen av OpenLDAP anges det lösenord som skall användas för administratörer. En mapp med konfigurationsfiler har även skapats på filsystemet. Mappen där samlingen av konfigurationsfiler befinner sig är /etc/ldap/. Den första filen som behöver modifieras är /etc/ldap/ldap.conf, i filen är det två rader som skall modifieras för att stämma överens med övriga system. Utdraget nedan är från konfigurationsfilen, konfigurationsfilen finns tillgänglig i sin helhet i Appendix J: BASE URI dc=a9,dc=se ldap://ldap.a9.se/ Med de två raderna konfiguration instrueras mjukvaran att dess URI(uniform resource identifier)är ldap.a9.se samt att dess base är dc=a9,dc=se. För att indexera katalogstrukturen skapas en fil av typen LDIF(Lightweight Directory Interchange Format) med namnet db-index.ldif. Filen finns tillgänglig i sin helhet i Appendix H. Genom att köra kommandot kommandot nedanför kommer LDAP-katalogen att indexeras. ldapmodify -Y EXTERNAL -H ldapi:/// -f./db-index.ldif OpenLDAP konfigurerades även för att logga information som senare skall skickas till servern som ansvarar för centraliserad loggning. För att starta loggandet av data skapades en fil med namnet log-stats.ldif. Koden nedan är innehållet i aktuell fil: dn: cn=config changetype: modify replace: olcloglevel olcloglevel: stats Kommandot nedan körs sedan för att importera den skapade filen och aktivera loggning: ldapmodify -QY EXTERNAL -H ldapi:/// -f log-stats.ldif Användarna som skall lagras i katalogen kommer att ligga i ett OU(Organizational Unit) med namn people. För att skapa trädstrukturen med nämnt OU skapas ytterligare en fil av typen LDIF som namnges till inittree.ldif. Innehållet i filen går att se nedan, filen finns även tillgänglig i Appenix I: dn: ou=people,dc=a9,dc=se ou: people objectclass: organizationalunit 7

11 dn: ou=groups,dc=a9,dc=se ou: groups objectclass: organizationalunit För att sedan införa datan i katalogen körs följande kommando: ldapadd -cxwd cn=admin,dc=a9,dc=se -f init-tree.ldif I detta skedet är installationen och konfigurationen av OpenLDAP färdigställd, dock behöver användare läggas till i katalogen. Med hjälp av verktyget ApacheDirectoryStudio kan en anslutning till servern skapas och där efter administreras. I verktyget kan användare läggas till i katalogen samt placeras i rätt OU. Modifkationer av de attribut som tillhör ett uidobject går att modifiera med enkelhet. En användares lösenord går att ställa in samt vilken typ av kryptering som skall användas för lösenordet FreeRADIUS Servern som tillhandahåller RADIUS(Remote Authentication Dial-In User Service) är maskinen med FQDN radius.a9.se. Mjukvaran som används är FreeRADIUS. Servern skall kunna kommunicera med ldap.a9.se för att kunna söka efter användare lagrade i katalogen. Den trådlösa accesspunkten skall kunna kommunicera med radius.a9.se för att användare skall kunna autentisera sig när de ansluter sig till det tråslösa nätverket Installation av FreeRADIUS FreeRADIUS installeras med hjälp av verktyget APT på samma sätt som de andra mjukvarorna i projektet installerades. Kommandot som användes för att installera mjukvaran går att se nedan: apt-get install freeradius Konfiguration av FreeRADIUS Ett antal modifikationer måste göras i de konfigurationsfiler som tillhör FreeRADIUS för att den trådlösa accesspunkten skall tillåtas kommunicera med FreeRADIUS samt att FreeRADIUS skall kunna utföra uppslagningar i LDAP-katalogen. Den första filen som modifieras är /etc/freeradius/clients.conf. Accesspunkten kommer att skicka förfrågningar till RADIUS-servern från en adress inom subnätverket /24. FreeRADIUS måste vara konfigurerad för att kunna godkänna dessa förfrågningar. Följande stycke konfiguration är ett utdrag ur /etc/freeradius/clients.conf, konfigurationsfilen finns även tillgänglig i sin helhet i Appendix M: client /24 { hostname = radius.a9.se shortname = radius.a9.se secret = y0urm0m När accesspunkten kommunicerar med RADIUS-servern använder den sig av lösenordet specificerat i konfigurationen demonstrerad ovanför. För att knyta samman FreeRADIUS och OpenLDAP görs modifikationer i följande filer: /etc/freeradius/modules/ldap /etc/freeradius/sites-available/default /etc/freeradius/sites-available/inner-tunnel Först modifieras konfigurationen för LDAP-modulen så inställningarna i filen är korrekta, detta för att anslutningar till ldap.a9.se skall kunna etableras samt att sökningar i katalogen skall kunna utföras. Raderna konfiguration nedan är ett utdrag ur filen /etc/freeradius/modules/ldap, konfigurationsfilen finns tillgänglig i sin helhet i Appendix D: 8

12 server = "ldap.a9.se" identity = "cn=admin,dc=a9,dc=se" password = 9393Syp basedn = "ou=people,dc=a9,dc=se" filter = "(uid=%{%{stripped-user-name:-%{user-name)" base_filter = "(objectclass=person)" Efter modulen för LDAP är konfigurerad skall FreeRADIUS konfigureras för att använda LDAP som en autentiseringsmetod. Konfigurationen för detta kommer att göras i filen /etc/freeradius/sitesavailable/default och /etc/freeradius/sites-available/inner-tunnel. I filen /etc/freeradius/sites-available/default läggs LDAP i sektionen authorize. Detta kommer aktivera LDAP-modulen och låta den användas för verifiering av användaruppgifter. Utdraget nedan visar hur authorize-sektionen är strukturerad. Kommentarer och viss data är borttaget i utdraget nedan för att spara utrymme men finns tillgängliga i konfigurationsfilen som finns tillgänglig i sin helhet i Appendix E: authorize { ldap I samma konfigurationsfil måste LDAP läggas till som ett alternativ i sektionen authenticate. Konfigurationen nedan demonstrerar hur det utförs: authenticate { Auth-Type LDAP { ldap LDAP måste även aktiveras i filen /etc/freeradius/sites-available/inner-tunnel. Det aktiveras på samma sätt som i filen /etc/freeradius/sites-available/default. Konfigurationsfilen finns tillgänglig i sin helhet i Appendix F. I sektionen authorize läggs LDAP till för att FreeRADIUS skall använda sig av modulen. authorize { ldap I sektionen authenticate läggs LDAP till som en Auth-Type: authenticate { Auth-Type LDAP { ldap Den sista konfigurationen som behöver utföras är att ställa in GTC(Generic Token Card) i konfigurationsfilen /etc/freeradius/eap.conf. GTC stödjer användandet de krypterade lösenorden i LDAP-katalogen. (Deploying RADIUS Partnerships, 2008) De parametrar i konfigurationsfilen som ändrades för att GTC skulle aktiveras är att sätta följande parameter i sektionerna peap och eap i filen /etc/freeradius/eap.conf, konfigurationsfilen finns tillgänglig i sin helhet i Appendix C: default_eap_type = gtc De trådlösa klienterna som användes i laborationen var av typen Macbook Pro vars operativsystem är OS X. I operativsystemet finns stöd för GTC implementerat.(apple, 2014) 9

13 1.7 Logging Logfiler samlas in från samtliga serversystem på servern logging.a9.se. Rsyslog installerades på samtliga serversystem. Konfigurationsfilen /etc/rsyslog.conf modifierades på logging.a9.se för att instruera mjukvaran om att den skall ta emot logdata från andra system och sedan spara informationen på filsystemet. Datan från de olika systemen kommer att sparas i en mapp som har samma namn som sändarens IP-adress. Konfigurationen nedan är ett utdrag från konfigurationsfilen för logging.a9.se. Konfigurationsfilen finns tillgänglig i sin helhet i Appendix K. $ModLoad imudp $UDPServerRun 514 $template FILENAME,"/var/log/%fromhost-ip%/syslog.log" *.*?FILENAME De andra serversystemen som skall skicka logdata till logging.a9.se konfigureras på följande vis, en fullständig konfigurationsfil finns tillgänglig i Appendix L: Konfigurationen ovanför instruerar rsyslog att skicka alla former av logdata till logserven. 1.8 Accesspunkt Accesspunkten ansvarar för att det trådlösa nätverket finns tillgängligt till användare. Konfigurationen av enheten utfördes via dess webgränssnitt. En statisk IP-adress konfigureras på enheten, vilket VLAN enheten tillhör samt vilket VLAN som är management-vlan. Accesspunkten konfigureras med WPA2-Enterprise och RADIUS-profilen konfigureras för kommunicera med radius.a9.se så anslutande användares inloggningsuppgifter kan verifieras med de kontouppgifter lagrade på LDAP-servern. 1.9 ACL Den nätverkstrafik som passerar routern r1a9.a9.se skall kontrolleras. Viss trafik tillåts medans annan nekas. Det är huvudsakligen trafik från subnätverket /24 som skall kontrolleras. Nämnt nätverkssegment är det som som är tilldelat användargruppen employees och anses inte vara pålitligt. Trafik som har sin härkomst från det nätverkssegmentet kommer därför att kontrolleras med hjälp av de regler som defineras i brandväggen. Två extended ACL(Access Control List) skapades för att kunna utföra de kontroller som är nödvändiga. En ACL skapas för att hantera trafiken från subnätverket /24 och ytterligare en ACL skapas för att hantera trafik som kommer från internet. Utdragen konfiguration nedan demonstrerar innehållet i den ACL som hanterar trafik från /24. Namnet på listan är fire, konfigurationsfilen finns tillgänglig i sin helhet i Appendix A: 1 permit udp any eq domain host gt permit udp any eq domain host eq domain 3 permit udp any eq domain host eq domain 4 permit udp any eq domain host gt deny tcp host eq www 6 deny tcp host eq deny tcp host eq ftp 8 deny tcp host eq 22 9 deny tcp host eq telnet 10 deny tcp eq 22 10

14 11 permit ip any any De första fyra raderna i listan fire hanterar DNS-trafik. Trafik av den typen skall tillåtas för att enheter skall kunna göra namnuppslagningar. Rad fem till rad nio hindrar klienter från subnätverket /24 att kommunicera med den trådlösa accesspunkten när något av följande protokoll som används: HTTP, SSL, FTP, SSH och TELNET. Rad tio hindrar att klienter från att etablera SSH-anslutningar till någon av servrarna som finns på management( /24). ACL-konfigurationen som demonstrerades ovanför appliceras på GigabitEthernet 0/0.20 som är gatewayinterface för alla enheter som befinner sig på employees-segmentet. Följande kommandon användes: ip access-group fire in ip access-group fire out Ytterligare en ACL skapas för att hindra att SSH-anslutningar skall kunna passera in till nätverket. Nedan går den fullständiga ACL-konfigurationen att se: ip access-list extended ssh deny tcp any any eq 22 permit ip any any ACL-konfigurationen appliceras på GigabitEthernet 0/1 vilket är det nätverksgränssnittet som används för anslutningen till internet. Följande kommando användes i konfigurationsläget för gränssnittet: ip access-group ssh in 1.10 Förbättringar Det som skulle kunna förbättras är accesspunkten som används. Det var mycket problematik kring den. Trafiken som är avsedd för serversystem på subnätverket /24 borde analyseras av en dedikerad brandvägg. Detta skulle troligen förbättra säkerheten samt öppna upp för mer avancerad analys av trafiken. Att ha en förbättrad lösenordspolicy skulle även kunna vara fördelaktigt. ACL-filtreringen av trafik skulle kunna ha utförs på ett mer detaljerat sätt Reflektion Laborationen var kul och givande. Storleken på gruppen var dock ett problem. Att vara tre personer som jobbar samtidigt leder allt för ofta till att någon av gruppdeltagarna inte får tillräckligt att göra. Problematik kan även uppstå ifall någon i gruppen tar på sig mer arbete än de andra. Två personer i en grupp skulle leda till att ett tätare samarbete skulle kunna uppstå. 11

15 Referenser OpenLDAP Foundation(2011). OpenLDAP Software 2.4 Administrator's Guide: Security Considerations. Tillgänglig på internet: [Hämtad ] Gustavo Noronha Silva(2005). APT HOWTO. Tillgänglig på internet: [Hämtad ] Deploying RADIUS Partnerships(2008). Protocol and Password Compatibility Tillgänglig på internet: [Hämtad ] Apple(2014). Mac OS X 10.5: How to configure Network preferences for 802.1X Tillgänglig på internet: ] 12

16 Appendix A r1a9.a9.se - router hostname R1A9 boot-start-marker boot-end-marker enable secret 5 $1$tINF$iSdvhASFePDTvGkPksjpz/ no aaa new-model no ipv6 cef ip source-route ip cef no ip domain lookup ip domain name a9.se multilink bundle-name authenticated crypto pki token default removal timeout 0 license udi pid CISCO2901/K9 sn FCZ1545C6R2 username admin privilege 15 secret 5 $1$5xCG$TbKoVZYLJvQKMAheqSWwU/ redundancy ip ssh version 2 interface Embedded-Service-Engine0/0 no ip address shutdown interface GigabitEthernet0/0 no ip address duplex auto speed auto interface GigabitEthernet0/0.10 encapsulation dot1q 10 ip address ip nat inside ip virtual-reassembly in interface GigabitEthernet0/0.20 encapsulation dot1q 20 ip address ip access-group fire in ip access-group fire out ip nat inside 13

17 ip virtual-reassembly in interface GigabitEthernet0/1 ip address ip access-group ssh in ip nat outside ip virtual-reassembly in duplex auto speed auto interface Serial0/0/0 no ip address shutdown no fair-queue clock rate interface Serial0/0/1 no ip address shutdown clock rate router ospf 1 network area 0 network area 0 network area 0 ip forward-protocol nd no ip http server no ip http secure-server ip nat inside source list NAT interface GigabitEthernet0/1 overload ip route ip access-list extended NAT permit ip any permit ip any ip access-list extended fire permit udp any eq domain host gt

18 permit udp any eq domain host eq domain permit udp any eq domain host eq domain permit udp any eq domain host gt 1023 deny tcp host eq www deny tcp host eq 443 deny tcp host eq ftp deny tcp host eq 22 deny tcp host eq telnet deny tcp eq 22 permit ip any any ip access-list extended ssh deny tcp any any eq 22 permit ip any any control-plane line con 0 logging synchronous line aux 0 line 2 no activation-character no exec transport preferred none transport input all transport output pad telnet rlogin lapb-ta mop udptn v120 ssh stopbits 1 line vty 0 4 logging synchronous login local transport input ssh line vty logging synchronous login local transport input ssh scheduler allocate end 15

19 Appendix B s1a9.a9.se switch no service pad service timestamps debug datetime msec service timestamps log datetime msec service password-encryption hostname S1A9 boot-start-marker boot-end-marker enable secret 5 $1$LrmB$zuZRjZtvQgrtu64sgIPSI0 username admin privilege 15 secret 5 $1$DLFp$K4nG32DDUd3Rf1w/8qCme. no aaa new-model system mtu routing 1500 ip subnet-zero no ip dhcp use vrf connected ip dhcp excluded-address ip dhcp excluded-address ip dhcp pool S1A9V10 network default-router dns-server domain-name a9.se ip dhcp pool S1A9V20 network default-router dns-server domain-name a9.se no ip domain-lookup ip domain-name a9.se 16

20 crypto pki trustpoint TP-self-signed enrollment selfsigned subject-name cn=ios-self-signed-certificate revocation-check none rsakeypair TP-self-signed crypto pki certificate chain TP-self-signed certificate self-signed A9 A D0609 2A F70D E30 2C F532D 53656C66 2D E65642D D E17 0D A170D A E302C F 532D5365 6C662D E65 642D D F300D 06092A F70D D CED6E1D8 C5BB87D6 B BD37E A5C3E31B B 40FA B106D 68905EEE 4D6D341F E4ACCCB3 E07C02E2 7FBE61AC AE95A2F1 ACCDD513 CABCDED0 0DC C94C 5BBF5F1F 38CD1604 DAF4F526 9E7773A2 75E63F01 C2D506EE F3B3FC9C B 892B95BB 3F3BDCBE 6B7C54EE 62B721E3 5ACEAA8A 1E1ED A36A F D FF FF D 11040E30 0C820A E 61392E F D FA8 248A7D82 0BC24F7D 50E9F5BC 74C DF301D D 0E FA824 8A7D820B C24F7D50 E9F5BC74 C DF300D06 092A F70D CE5E70 E31E3443 A9968D6C AF EFEBAE CB F 6C43207A 4B10F7AF B43E9DBE 5C818C87 A986FD05 1F C95DBDF0 212D1275 C56E25FF 4E080D02 1F40BEF3 7D6BCE2F 34C2F1C1 67CD3038 BEB3D21F 80BA ED770D E02AC30F DDC8469B 5643FFC9 F04EC9FB B1DCE5ED B1DCC617 6B2949D C26 quit spanning-tree mode pvst spanning-tree extend system-id vlan internal allocation policy ascending interface FastEthernet0/1 switchport access vlan 10 switchport mode access interface FastEthernet0/2 switchport access vlan 10 17

21 switchport mode access interface FastEthernet0/3 switchport access vlan 10 switchport mode access interface FastEthernet0/4 switchport access vlan 10 switchport mode access interface FastEthernet0/5 switchport access vlan 10 switchport mode access interface FastEthernet0/6 switchport access vlan 10 switchport mode access interface FastEthernet0/7 switchport access vlan 10 switchport mode access interface FastEthernet0/8 switchport trunk native vlan 10 switchport mode trunk interface FastEthernet0/9 switchport access vlan 10 switchport mode access interface FastEthernet0/10 switchport access vlan 10 switchport mode access interface FastEthernet0/11 switchport access vlan 10 switchport mode access interface FastEthernet0/12 18

22 switchport access vlan 10 switchport mode access interface FastEthernet0/13 switchport access vlan 20 switchport mode access interface FastEthernet0/14 switchport access vlan 20 switchport mode access interface FastEthernet0/15 switchport access vlan 20 switchport mode access interface FastEthernet0/16 switchport access vlan 20 switchport mode access interface FastEthernet0/17 switchport access vlan 20 switchport mode access interface FastEthernet0/18 switchport access vlan 20 switchport mode access interface FastEthernet0/19 switchport access vlan 20 switchport mode access interface FastEthernet0/20 switchport access vlan 20 switchport mode access interface FastEthernet0/21 switchport access vlan 20 switchport mode access 19

23 interface FastEthernet0/22 switchport access vlan 20 switchport mode access interface FastEthernet0/23 switchport access vlan 20 switchport mode access interface FastEthernet0/24 switchport trunk allowed vlan 10,20 switchport mode trunk interface GigabitEthernet0/1 switchport trunk allowed vlan 10,20 switchport mode trunk interface GigabitEthernet0/2 interface Vlan1 no ip address no ip route-cache interface Vlan10 ip address no ip route-cache interface Vlan20 ip address no ip route-cache interface Vlan99 no ip address no ip route-cache ip http server ip http secure-server control-plane 20

24 banner motd ^CThis switch belongs to group A9, contact line con 0 password B1E05022D5D logging synchronous line vty 0 4 login local transport input ssh line vty 5 15 login local transport input ssh en 21

25 Appendix C eap.conf - FreeRADIUS eap { Invoke the default supported EAP type when EAP-Identity response is received. The incoming EAP messages DO NOT specify which EAP type they will be using, so it MUST be set here. For now, only one default EAP type may be used at a time. If the EAP-Type attribute is set by another module, then that EAP type takes precedence over the default type configured here. default_eap_type = gtc A list is maintained to correlate EAP-Response packets with EAP-Request packets. After a configurable length of time, entries in the list expire, and are deleted. timer_expire = 60 There are many EAP types, but the server has support for only a limited subset. If the server receives a request for an EAP type it does not support, then it normally rejects the request. By setting this configuration to "yes", you can tell the server to instead keep processing the request. Another module MUST then be configured to proxy the request to another RADIUS server which supports that EAP type. If another module is NOT configured to handle the request, then the request will still end up being rejected. ignore_unknown_eap_types = no Cisco AP1230B firmware 12.2(13)JA1 has a bug. When given 22

26 a User-Name attribute in an Access-Accept, it copies one more byte than it should. We can work around it by configurably adding an extra zero byte. cisco_accounting_username_bug = no Help prevent DoS attacks by limiting the number of sessions that the server is tracking. Most systems can handle ~30 EAP sessions/s, so the default limit of 4096 should be OK. max_sessions = 4096 Supported EAP-types We do NOT recommend using EAP-MD5 authentication for wireless connections. It is insecure, and does not provide for dynamic WEP keys. md5 { Cisco LEAP We do not recommend using LEAP in new deployments. See: Cisco LEAP uses the MS-CHAP algorithm (but not the MS-CHAP attributes) to perform it's authentication. As a result, LEAP *requires* access to the plain-text User-Password, or the NT-Password attributes. 'System' authentication is impossible with LEAP. leap { 23

27 Generic Token Card. Currently, this is only permitted inside of EAP-TTLS, or EAP-PEAP. The module "challenges" the user with text, and the response from the user is taken to be the User-Password. Proxying the tunneled EAP-GTC session is a bad idea, the users password will go over the wire in plain-text, for anyone to see. gtc { The default challenge, which many clients ignore.. challenge = "Password: " The plain-text response which comes back is put into a User-Password attribute, and passed to another module for authentication. This allows the EAP-GTC response to be checked against plain-text, or crypt'd passwords. If you say "Local" instead of "PAP", then the module will look for a User-Password configured for the request, and do the authentication itself. auth_type = PAP EAP-TLS See raddb/certs/readme for additional comments on certificates. If OpenSSL was not found at the time the server was built, the "tls", "ttls", and "peap" sections will be ignored. 24

28 Otherwise, when the server first starts in debugging mode, test certificates will be created. See the "make_cert_command" below for details, and the README file in raddb/certs These test certificates SHOULD NOT be used in a normal deployment. They are created only to make it easier to install the server, and to perform some simple tests with EAP-TLS, TTLS, or PEAP. See also: Note that you should NOT use a globally known CA here! e.g. using a Verisign cert as a "known CA" means that ANYONE who has a certificate signed by them can authenticate via EAP-TLS! This is likely not what you want. tls { These is used to simplify later configurations. certdir = ${confdir/certs cadir = ${confdir/certs private_key_password = whatever private_key_file = ${certdir/server.key If Private key & Certificate are located in the same file, then private_key_file & certificate_file must contain the same file name. If CA_file (below) is not used, then the certificate_file below MUST include not only the server certificate, but ALSO all of the CA certificates used to sign the server certificate. 25

29 certificate_file = ${certdir/server.pem Trusted Root CA list ALL of the CA's in this list will be trusted to issue client certificates for authentication. In general, you should use self-signed certificates for 802.1x (EAP) authentication. In that case, this CA file should contain *one* CA certificate. This parameter is used only for EAP-TLS, when you issue client certificates. If you do not use client certificates, and you do not want to permit EAP-TLS authentication, then delete this configuration item. CA_file = ${cadir/ca.pem For DH cipher suites to work, you have to run OpenSSL to create the DH file first: openssl dhparam -out certs/dh 1024 dh_file = ${certdir/dh random_file = /dev/urandom This can never exceed the size of a RADIUS packet (4096 bytes), and is preferably half that, to accomodate other attributes in RADIUS packet. On most APs the MAX packet length is configured between In these cases, fragment size should be 1024 or less. fragment_size =

30 include_length is a flag which is by default set to yes If set to yes, Total Length of the message is included in EVERY packet we send. If set to no, Total Length of the message is included ONLY in the First packet of a fragment series. include_length = yes Check the Certificate Revocation List 1) Copy CA certificates and CRLs to same directory. 2) Execute 'c_rehash <CA certs&crls Directory>'. 'c_rehash' is OpenSSL's command. 3) uncomment the line below. 5) Restart radiusd check_crl = yes CA_path = ${cadir If check_cert_issuer is set, the value will be checked against the DN of the issuer in the client certificate. If the values do not match, the cerficate verification will fail, rejecting the user. In and later, this check can be done more generally by checking the value of the TLS-Client-Cert-Issuer attribute. This check can be done via any mechanism you choose. check_cert_issuer = "/C=GB/ST=Berkshire/L=Newbury/O=My Company Ltd" If check_cert_cn is set, the value will be xlat'ed and checked against the CN in the client certificate. If the values do not match, the certificate verification 27

31 will fail rejecting the user. This check is done only if the previous "check_cert_issuer" is not set, or if the check succeeds. In and later, this check can be done more generally by checking the value of the TLS-Client-Cert-CN attribute. This check can be done via any mechanism you choose. check_cert_cn = %{User-Name Set this option to specify the allowed TLS cipher suites. The format is listed in "man 1 ciphers". cipher_list = "DEFAULT" This command creates the initial "snake oil" certificates when the server is run as root, and via "radiusd -X". As of , it *also* checks the server certificate for validity, including expiration. This means that radiusd will refuse to start when the certificate has expired. The alternative is to have the 802.1X clients refuse to connect when they discover the certificate has expired. Debugging client issues is hard, so it's better for the server to print out an error message, and refuse to start. make_cert_command = "${certdir/bootstrap" Elliptical cryptography configuration 28

32 Only for OpenSSL >= f ecdh_curve = "prime256v1" Session resumption / fast reauthentication cache. The cache contains the following information: session Id - unique identifier, managed by SSL User-Name - from the Access-Accept Stripped-User-Name - from the Access-Request Cached-Session-Policy - from the Access-Accept The "Cached-Session-Policy" is the name of a policy which should be applied to the cached session. This policy can be used to assign VLANs, IP addresses, etc. It serves as a useful way to re-apply the policy from the original Access-Accept to the subsequent Access-Accept for the cached session. On session resumption, these attributes are copied from the cache, and placed into the reply list. You probably also want "use_tunneled_reply = yes" when using fast session resumption. cache { Enable it. The default is "no". Deleting the entire "cache" subsection Also disables caching. You can disallow resumption for a particular user by adding the following 29

33 attribute to the control item list: Allow-Session-Resumption = No If "enable = no" below, you CANNOT enable resumption for just one user by setting the above attribute to "yes". enable = no Lifetime of the cached entries, in hours. The sessions will be deleted after this time. lifetime = 24 hours The maximum number of entries in the cache. Set to "0" for "infinite". This could be set to the number of users who are logged in... which can be a LOT. max_entries = 255 As of version , client certificates can be validated via an external command. This allows dynamic CRLs or OCSP to be used. This configuration is commented out in the default configuration. Uncomment it, and configure the correct paths below to enable it. verify { A temporary directory where the client certificates are stored. This directory 30

34 MUST be owned by the UID of the server, and MUST not be accessible by any other users. When the server starts, it will do "chmod go-rwx" on the directory, for security reasons. The directory MUST exist when the server starts. You should also delete all of the files in the directory when the server starts. tmpdir = /tmp/radiusd Filename" The command used to verify the client cert. We recommend using the OpenSSL command-line tool. The ${..CA_path text is a reference to the CA_path variable defined above. The %{TLS-Client-Cert-Filename is the name of the temporary file containing the cert in PEM format. This file is automatically deleted by the server when the command returns. client = "/path/to/openssl verify -CApath ${..CA_path %{TLS-Client-Cert- OCSP Configuration Certificates can be verified against an OCSP Responder. This makes it possible to immediately revoke certificates without the distribution of new Certificate Revokation Lists (CRLs). ocsp { Enable it. The default is "no". Deleting the entire "ocsp" subsection Also disables ocsp checking 31

35 enable = no The OCSP Responder URL can be automatically extracted from the certificate in question. To override the OCSP Responder URL set "override_cert_url = yes". override_cert_url = yes If the OCSP Responder address is not extracted from the certificate, the URL can be defined here. Limitation: Currently the HTTP Request is not sending the "Host: " information to the web-server. This can be a problem if the OCSP Responder is running as a vhost. url = " The TTLS module implements the EAP-TTLS protocol, which can be described as EAP inside of Diameter, inside of TLS, inside of EAP, inside of RADIUS... Surprisingly, it works quite well. The TTLS module needs the TLS module to be installed and configured, in order to use the TLS tunnel inside of the EAP packet. You will still need to configure the TLS module, even if you do not want to deploy EAP-TLS in your network. Users will not be able to request EAP-TLS, as it requires them to 32

36 have a client certificate. EAP-TTLS does not require a client certificate. You can make TTLS require a client cert by setting EAP-TLS-Require-Client-Cert = Yes in the control items for a request. ttls { The tunneled EAP session needs a default EAP type which is separate from the one for the non-tunneled EAP module. Inside of the TTLS tunnel, we recommend using EAP-MD5. If the request does not contain an EAP conversation, then this configuration entry is ignored. default_eap_type = md5 The tunneled authentication request does not usually contain useful attributes like 'Calling-Station-Id', etc. These attributes are outside of the tunnel, and normally unavailable to the tunneled authentication request. By setting this configuration entry to 'yes', any attribute which NOT in the tunneled authentication request, but which IS available outside of the tunnel, is copied to the tunneled request. allowed values: {no, yes copy_request_to_tunnel = no The reply attributes sent to the NAS are usually based on the name of the user 'outside' of the tunnel (usually 'anonymous'). If you want to send the 33