Transparent Firewall for Wireless Network Kasom Kotharsa 1

Transparent Firewall for Wireless Network Kasom Koth-arsa 1, Surasak Sanguanpong 2, Anan Phonphoem 2 }Kasom. K, Surasak. S, Anan. P}@ku. ac. th 1 Engineering Computer Center, Faculty of Engineering 2 Department of Computer Engineering, Faculty of Engineering Kasetsart University APAN, Hawaii, Network Security, 23 rd Januray 2008 This work is partially supported by Commission of Higher Education (CHE), Uni. NET, Thailand

Agenda Backgrounds n Obstacles & Opportunities n Design n Implementation n Conclusion n 2/29

Kasetsart University Wireless Network n n n Kasetsart University Wireless Network – KUWi. N Centralize control, managed by Office of Computer Services 452 APs in Bangkhen campus (As of 2008/01/18) n n n 200 more APs will be deploy within the next three month 110 Buildings 34, 780 registered wireless devices n More than 2, 000 maximum concurrent clients 3/29

KUWi. N Campus Currently 452 APs available (2008/01/18) Ministry of Agriculture 1. 5 km 4/29

Agenda Backgrounds n Obstacles & Opportunities n Design n Implementation n Results n Conclusion n 5/29

Obstacles & Opportunities n Large number of concurrent clients More than 2, 000 maximum concurrent clients n Require large number of IP addresses n Rouge DHCP server and broadcast storm in Wireless Network n User use static IP address n n n Conflict with the user who uses DHCP Wireless roaming within the campus 6/29

Agenda Backgrounds n Obstacles & Opportunities n Design n Implementation n Results n Conclusion n 7/29

Design: The Two Extreme n Single subnet for the whole wireless network Efficient IP address utilization n Seamless roaming n Suffer from broadcast problems n n Multiple subnet, one for each access point Separate broadcast domain, separate the problems n Not smooth roaming n IP address utilization is not efficient n 8/29

Design: Previous KUWi. N n n Single VLAN across the whole campus, dedicated for wireless network Single subnet, single broadcast domain Ethernet Switch AP AP AP Single VLAN/Single subnet Router Ethernet Switch AP AP 9/29

Design: The New KUWi. N n Multiple VLANs n n n Network Management VLAN Registration VLAN (For the users to register their devices’ MAC address) Unencrypted VLAN: KUWIN (For legacy clients) WPA VLAN: KUWIN-WPA Shadow VLANs n n Split the unencrypted and WPA VLAN into multiple VLANs Join those VLAN together with transparent bridge/firewalls 10/29

Design: Shadow VLANs The network management VLAN and the registration VLAN are not shadowed n Both the unencrypted VLAN and the WPA VLAN are divided into N Shadow VLAN each n Some broadcast packets will be filtered using transparent firewalls, thus create a single subnet with (somewhat) multiple broadcast domains n 11/29

Design: Shadow VLAN/Logical View Router Primary VLAN Multiple VLAN/Single subnet Ethernet Switch Transparent Firewall Ethernet Switch AP AP AP Shadow VLAN #1 AP AP Shadow VLAN #2 AP AP Shadow VLAN #3 12/29

Design: VLAN Partitioning n Selecting the number of Shadow VLANs Cost of firewall servers n Ease of management n Effectiveness of separating the broadcast domain n 13/29

Design: Filtering n DHCP n n n ARP n n n Assume that all wireless users are clients, the clients will always issue the ARP request Drop requests from the router Allow request from client side to the router Allow reply from the router to the client Net. BIOS broadcast/other broadcasts n n Allow request from client side to the router Allow reply from the router to the client Drop all Design a daemon to permitting DHCP users/blocking static IP users) Adjust the ipset( 14/29

Design: Force User to Use DHCP Router/DHCP Server Side DHCP Offer/ACK Packets Bridge/ Transparent Firewall ipset Member Database update Daemon Client Side 15/29

Agenda Backgrounds n Obstacles & Opportunities n Design n Implementation n Results n Conclusion n 16/29

Implementation: Overview n Use two large subnet, 16 class C each The first subnet is for unencrypted VLAN n The second subnet is for the WPA VLAN n Split both unencrypted and WPA VLAN into 5 VLAN each n Use transparent firewall/bridge to tie those VLANs together n 17/29

Implementation: Transparent bridge/firewall Use Linux server as a bridge n Iptables + ipset & ebtables n Focus on filtering of broadcast packets n DHCP n ARP n Net. BIOS broadcast n 18/29

Implementation: Hardware n Sun Fire X 2100 Opteron™ 1210 Dual core(1. 8 GHz) n 512 MB of RAM n 300 GB SATA hard disk n Built-in Gigabit Ethernet Controller n 19/29

Implementation: Software Linux 2. 6. 23. 9+ipset patch on Cent. OS 5 (64 bit) n bridge-utils n ebtables n Iptables 1. 3. 5 + ipset patch n Create a daemon for permitting DHCP users/blocking static IP users) Adjust the ipset( n 20/29

Implementation: Filtering/ebtables Bridge chain : FORWARD, entries: 18, policy: ACCEPT -d 1: 0: 5 e: 0: 0: 2 -j DROP -d 1: 0: 5 e: 0: 0: 5 -j DROP -d 1: 0: 5 e: 0: 0: d -j DROP -d 1: 0: 5 e: 7 f: fa -j DROP -d 1: 0: c: cc: cd -j DROP -d 1: 0: c: cc: cc -j DROP -d BGA -j DROP -d 33: 0: 0: 0: 5 -j DROP -p ARP -d Broadcast -i eth 2 -j DROP -p ARP -j ACCEPT -p IPX -d Broadcast -j DROP -p Net. BEUI -d Broadcast -j DROP -p IPv 4 -d Broadcast --ip-proto udp --ip-dport 137: 138 -j DROP -p IPv 4 -d Broadcast -i eth 3. 112 --ip-proto udp --ip-dport 68 -j DROP -p IPv 4 -d Broadcast -o eth 3. 112 --ip-proto udp --ip-dport 67 -j DROP -p IPv 4 -j ACCEPT -p IPv 6 -j ACCEPT -j DROP 21/29

Implementation: Filtering/iptables Chain FORWARD target prot ACCEPT 0 LOG 0 DROP 0 (policy ACCEPT) opt source destination -- 0. 0/0 PHYSDEV match --physdev-in set fixip src, src -- 0. 0/0 PHYSDEV match --physdev-in set usedhcp src, src -- 0. 0/0 PHYSDEV match --physdev-in LOG flags 0 level 4 -- 0. 0/0 PHYSDEV match --physdev-in eth 3. 112 eth 3. 112 22/29

Implementation: Filtering/ipset Name: fixip Type: ipmap References: 1 Default binding: Header: from: 158. 108. 0. 0 to: 158. 108. 255 Members: 158. 108. X. X Manually insert to allow some IP to be set statically. … Bindings: Automatically insert/remove Name: usedhcp By the daemon to allow Type: macipmap References: 1 DHCP users Default binding: Header: from: 158. 108. 0. 0 to: 158. 108. 255 Members: 158. 108. X. X: XX: XX: XX: XX … Bindings: 23/29

Agenda Backgrounds n Obstacles & Opportunities n Design n Implementation n Results n Conclusion n 24/29

Results n From our experiments ARP broadcast from the router is greatly reduced n Rouge DHCP server still disturbed the local VLAN in which it is connected to but no longer effect the other Shadow VLAN, thus the scope is smaller n The latency introduced by adding transparent firewall is very small n 25/29

Agenda Backgrounds n Obstacles & Opportunities n Design n Implementation n Results n Conclusion n 26/29

Conclusions n A wireless network deployment that combine the efficient IP address allocation of single subnet design with the (partial) broadcast domain separation of multiple subnet design Rouge DHCP server will not effect the whole subnet n The number of broadcast is reduced n Roaming within the campus is seamless n n Prevent the users from using static IP address in the wireless network 27/29

Future Works n Rouge Access Point Detection and Blocking 28/29

Thank you! Questions? 29/29