Ha próbált már valaki publikus WIFI hozzáférést konfigurálni, ami még egy kicsit biztonságos is, viszont nagyon rugalmas és még egyszerű használni is, nos akkor az tudja, hogy ez nem annyira egyszerű.
Persze lehetne készíteni egy SSID-t ami egyszerűen open. Nos én nem ez az ember vagyok…
Nálunk az épületben 15 AP-van és minden AP több SSID-t sugároz (vagy mi 🙂 )
A volt a cél, hogy legye egy biztonságos (min. wpa2/aes-ccm) privát hálózat és egy nyitott ami fölött valamiféle kontroll azért van és nem kell a felhasználóknak segíteni a használatában. Erre a jó megoldás a Captivate Portál.
Az internetet böngészve az első jó megoldás (Cisco Acces Pontokról lévén szó) az Cisco wifi controller. Mi sem egyszerűbb ennél… csak meg kell venni. Nos mondjuk azt, hogy a max 25 AP-t vezérlő wifi controller nem olcsó.
Más megoldás kell ide.Vannak tűzfalak amikben van Captivate portal képesség, de az csak az internetre kijutást akadályozza. Biztos van jobb megoldás!
Én a Packetfence nevű (szerintem félkész és bug hegyeket valamit félkész megoldásokat felvonultató) szoftver találtam. Ez a legjobb!! 🙂
A Packetfence egy OpenSource NAC megoldás. Tud 802.1X hitelesítést, izolációt(karantén), felismeri a kártékony eszközöket a hálózaton stb.
A dolognak mindjárt kétféleképpen lehet nekikezdeni:
-Telepíthetünk egy nekünk tetsző Redhat vagy Centos linuxot és magunk telepíthetjük rá a Packetfence-t vagy
-Letöltjük a Pf-Zen (Zero effort nac) virtuális gépet.
Én természetesen az utóbbit választottam, hiszen a lustaság fél egészség 🙂
A letöltött ovf fájlt Vmware ESXi 4-es szerverre telepítettem. Ügyelni kell arra, hogy az ESXi olyan switch portba legyen bekötve, ami trunk modba van konfigurálva, mert szükségünk lesz számos vlan-ra a packetfence használatakor. Ezutná már csak az ESXi-n kell egy megfelelő port group-ot konfigurálni amit az a következő képen látható.
A pz-zen gép hálózati kártyáját ebbe a port group-ba kell „bedugni”.
Azért van két kártya a gépben, mert a SNORT-nak kelleni fog egy külön kártya!
A PF-ZEN az alábbi előre konfigurált beállításokkal érkezik:
VLAN 1 = management VLAN (ez nem túl szerencsés beállítás)
VLAN 2 = registration VLAN (a még nem regisztrál eszközök először ide kerülnek)
VLAN 3 = isolation VLAN (azok az eszközök kerülne ide amket nem szeretünk 🙂 )
VLAN 4= MAC detection VLAN (üres VLAN: no DHCP, no routing, no nothing)
VLAN 5= vendég VLAN (a vengégek elkülönítője… )
VLAN 10 = “normál” VLAN (ahol a többi működő munkaállomás van mondjuk)
A Packetfence a következőképpen működik a mi esetünkben:
- Felhasználó csatlakozik a nyílt wifi hálózathoz . Az access point/controller egy radius mac auth kérést küld a packetfence gépen futó freeradius szervernek, az pedig egy allowed, VLAN 2 választ küld és feljegyzi a MAC címet
- Mint minden rendes felhasználó, elkezd(ene) böngészni az interneten. Igen ám, de a dns szerver maga a packetfence gép (ahogy a dhcp szerver is) és minden kérésre a saját címét adja vissza.
- Felhasználó megkapja az arcába a Captivate portal névre keresztelt weboldalt, ahol a mi általunk választott/konfigurált módszerek egyikével regisztrálja a gépét (MAC cím) a hálózaton. (a pf. megjegyzi a MAC címet a rendszerben beállított időpontig)
- A packetfence egy deauthenticate üzenetet küld az acces pointnak/controllernek ami ennek hatására egy pillanatra „ledobja magáról” a felhasználót aki azonal vissza is csatlakozik. Mac auth kérés megint megy a freeradius szervernek, csakhogy az adatbázisban most már az szerepel, hogy ehhez a géphez (MAC) a VLAN 10 tartozik, hiszen már regisztráltuk. A válasz ebben az esetben tehát allowed, VLAN 10
- A felhasználó megkapja az új DNS beállításokat és már használhatja is a hálózatot
Fontos:
- Figyelni kell, hogy a kliens gépeken ne legyen fix ip vagy dns szerver beállítva, mert úgy a rendszer működésképtelen.
- Az, hogy meddig ne kelljen újra regisztrálni állítható. (nálunk 1 év, de lehet néhány óra is akár)
- A hálózati forgalom így nincsen titkosítva, de a rendszer kombinálható mondjuk egy WPA / AES hitelesítéssel/titkosítással és úgy már elég biztonságos, (viszont kényelmetlenebb)
Izoláció
A rendszer által kártékonynak tekintett gépek izolációja úgy működik, hogy a pf. folyamatosan figyeli a hálózati forgalmat (snort) és ha kártékonynak tűnő gépet fedez fel, akkor az adatbázisban átállítja az adott gépe VLAN számát 3-ra (isolation) majd küld egy deauth üzenetet az access pointnak. Mikor a kliens visszacsatlakozik már a 3-as vlan-ba kerül.
Egy Cisco Ap konfig (érintett részei) így néznek ki:
aaa group server radius rad_mac
server-private 10.0.10.1 auth-port 1812 acct-port 1813 key 7 xxxxxxxxxxxxxxxxxxxxxxxx
…
aaa authentication login mac_methods group rad_mac
…
dot11 mbssid
dot11 vlan-name normal vlan 10
dot11 vlan-name isolation vlan 3
dot11 vlan-name registration vlan 2
…
dot11 ssid Packetfence-Hotspot
vlan 2 backup normal isolation
authentication open mac-address mac_methods
mbssid guest-mode dtim-period 10
no ids mfp client
…
interface Dot11Radio0
ssid Packetfence-Hotspot
…
interface Dot11Radio0.10
encapsulation dot1Q 10
no ip route-cache
bridge-group 55
bridge-group 55subscriber-loop-control
bridge-group 55block-unknown-source
no bridge-group 55source-learning
no bridge-group 55unicast-flooding
bridge-group 55 spanning-disabled
!
interface Dot11Radio0.2
encapsulation dot1Q 2
no ip route-cache
bridge-group 52
bridge-group 52 subscriber-loop-control
bridge-group 52 block-unknown-source
no bridge-group 52 source-learning
no bridge-group 52 unicast-flooding
bridge-group 253 spanning-disabled
!
interface Dot11Radio0.3
encapsulation dot1Q 3
no ip route-cache
bridge-group 53
bridge-group 53 subscriber-loop-control
bridge-group 53 block-unknown-source
no bridge-group 53 source-learning
no bridge-group 53 unicast-flooding
bridge-group 53 spanning-disabledinterface FastEthernet0.10
encapsulation dot1Q 10
no ip route-cache
bridge-group 55
no bridge-group 55 source-learning
bridge-group 55 spanning-disabled
!
interface FastEthernet0.2
encapsulation dot1Q 2
no ip route-cache
bridge-group 2
no bridge-group 52 source-learning
bridge-group 52 spanning-disabled
!
interface FastEthernet0.3
encapsulation dot1Q 3
no ip route-cache
bridge-group 53
no bridge-group 53 source-learning
bridge-group 53 spanning-disabled
!
interface BVI1
ip address 10.0.10.50 255.255.255.0
…
radius-server attribute 32 include-in-access-req format %h
radius-server retransmit 10
radius-server timeout 10
radius-server vsa send authentication
Cisco ap esetén nem snmp-t használ a pf hanem ssh-t!
Illesztés Cisco WLC 4400 vagy 5500 kontrollerhez:
Nagyon fontos, hogy a tapasztalatok szerint 7-es operációs rendszerrel nem működik a dolog! A kontroller nem reagál helyesen a deauth üzenetekre.
Az érintett beállítások képekben:
Packetfence konfig.
Amiben matatni kell:
switches.conf
[default]
vlans=2,3,5,10
normalVlan=10
registrationVlan=2
isolationVlan=3
…
#Egyedi AP
[10.0.10.50]
type=Cisco::Aironet_1130
mode=production
cliTransport=SSH
cliUser=PacketfenceUsr
cliPwd=yyyyyyyyyyyy
radiusSecret=xxxxxxxxxxxx1
…
#Kontroller
[10.0.10.51]
type=Cisco::WLC_4400
mode=production
cliTransport=SSH
cliUser=wlcadmin
cliPwd=yxyxyxyx
radiusSecret=yzyzyzyzyzy
/etc/raddb/clients
client-ap-1 {
secret = xxxxxxxxxxxx1
ipaddr = 10.0.10.50
}
client szlk-WLC-4400 {
secret = yzyzyzyzyzy
ipaddr = 10.0.10.51
}
pf.conf
[vlan]
#interfaces
[interface eth0.2]
mask=255.255.255.0
type=internal
gateway=192.168.51.10
ip=192.168.51.10
enforcement=vlan
type=internal,monitor
gateway=192.168.53.10
ip=192.168.53.10
enforcement=vlan [interface eth0.10] mask=255.255.255.0
type=dhcplistener
gateway=192.168.1.254
ip=192.168.1.1 [interface eth1] type=monitor
Kb ez a lényeg. Az igazat megvallva nekem hetekig tartott mire minden jól kezdett működni 🙂
A fenti példában nem használtam a guest vlan funkciót és még számos extra szolgáltatást.
A variációk száma egyébként is elég nagy. Mindenki állítgathatja kedvére 🙂