Transparent Firewall for Transparent Firewall for Wireless NetworkWireless Network

-Kasom Koth -Kasom Koth aarsarsa11 , Surasak Sanguanpong , Surasak Sanguanpong22 , ,Anan PhonphoemAnan Phonphoem22

{{ Kasom.K, Surasak.S, Kasom.K, Surasak.S, Anan.PAnan.P}@ku.ac.th}@ku.ac.th

11 Engineering Computer Center, Faculty of Engineeri Engineering Computer Center, Faculty of Engineeringng

22 Department of Computer Engineering, Faculty of En Department of Computer Engineering, Faculty of Engineeringgineering

Kasetsart UniversityKasetsart University

APAN, Hawaii, Network Security, 23APAN, Hawaii, Network Security, 23rdrd Januray 2008 Januray 2008This work is partially supported by Commission of Higher Education (CHE), UniNET, Thailand

2/29

AgendaAgenda

BackgroundsBackgrounds Obstacles & OpportunitiesObstacles & Opportunities DesignDesign ImplementationImplementation ConclusionConclusion

3/29

Kasetsart University Wireless Kasetsart University Wireless NetworkNetwork

Kasetsart University Wireless Network – Kasetsart University Wireless Network – KUWiNKUWiN

Centralize control, managed by Office of Centralize control, managed by Office of Computer ServicesComputer Services

452 APs in Bangkhen campus (As of 452 APs in Bangkhen campus (As of 2008/01/18)2008/01/18) 200 more APs will be deploy within the next three 200 more APs will be deploy within the next three

monthmonth 110 Buildings110 Buildings

34,780 registered wireless devices34,780 registered wireless devices More than 2,000 maximum concurrent clientsMore than 2,000 maximum concurrent clients

4/29

KUWiNKUWiNCurrently 452 APs available (2008/01/18)

Campus

Ministry of Agriculture

1.5 km

5/29

AgendaAgenda

BackgroundsBackgrounds Obstacles & OpportunitiesObstacles & Opportunities DesignDesign ImplementationImplementation ResultsResults ConclusionConclusion

6/29

Obstacles & Obstacles & OpportunitiesOpportunities

Large number of concurrent clientsLarge number of concurrent clients More than 2,000 maximum concurrent More than 2,000 maximum concurrent

clientsclients Require large number of IP addressesRequire large number of IP addresses

Rouge DHCP server and broadcast Rouge DHCP server and broadcast storm in Wireless Networkstorm in Wireless Network

User use static IP addressUser use static IP address Conflict with the user who uses DHCPConflict with the user who uses DHCP

Wireless roaming within the campusWireless roaming within the campus

7/29

AgendaAgenda

BackgroundsBackgrounds Obstacles & OpportunitiesObstacles & Opportunities DesignDesign ImplementationImplementation ResultsResults ConclusionConclusion

8/29

Design: The Two ExtremeDesign: The Two Extreme

Single subnet for the whole wireless Single subnet for the whole wireless networknetwork Efficient IP address utilizationEfficient IP address utilization Seamless roamingSeamless roaming Suffer from broadcast problemsSuffer from broadcast problems

Multiple subnet, one for each access point Multiple subnet, one for each access point Separate broadcast domain, separate the Separate broadcast domain, separate the

problemsproblems Not smooth roamingNot smooth roaming IP address utilization is not efficientIP address utilization is not efficient

9/29

Design: Previous KUWiNDesign: Previous KUWiN

Single VLAN Single VLAN across the whole across the whole campus, dedicated campus, dedicated for wireless for wireless networknetwork

Single subnet, Single subnet, single broadcast single broadcast domaindomain

Router

Ethernet Switch

Ethernet SwitchEthernet SwitchEthernet Switch

AP AP AP AP AP AP AP AP AP

Single VLAN/Single subnet

10/29

Design: The New KUWiNDesign: The New KUWiN

Multiple VLANsMultiple VLANs Network Management VLANNetwork Management VLAN Registration VLAN (For the users to register their Registration VLAN (For the users to register their

devices’ MAC address)devices’ MAC address) Unencrypted VLAN: KUWIN (For legacy clients)Unencrypted VLAN: KUWIN (For legacy clients) WPA VLAN: KUWIN-WPAWPA VLAN: KUWIN-WPA

Shadow VLANsShadow VLANs Split the unencrypted and WPA VLAN into Split the unencrypted and WPA VLAN into

multiple VLANsmultiple VLANs Join those VLAN together with transparent Join those VLAN together with transparent

bridge/firewallsbridge/firewalls

11/29

Design: ShadowDesign: Shadow VLANsVLANs

The network management VLAN and the The network management VLAN and the registration VLAN are not shadowedregistration VLAN are not shadowed

Both the unencrypted VLAN and the Both the unencrypted VLAN and the WPA VLAN are divided into N Shadow WPA VLAN are divided into N Shadow VLAN eachVLAN each

Some broadcast packets will be filtered Some broadcast packets will be filtered using transparent firewalls, thus create a using transparent firewalls, thus create a single subnet with (somewhat) multiple single subnet with (somewhat) multiple broadcast domainsbroadcast domains

12/29

Design: Shadow VLAN/Logical Design: Shadow VLAN/Logical ViewViewRouter

Ethernet Switch

Ethernet SwitchEthernet SwitchEthernet Switch

AP AP AP AP AP AP AP AP AP

TransparentFirewall

TransparentFirewall

TransparentFirewall

Primary VLAN

Shadow VLAN #1 Shadow VLAN #2 Shadow VLAN #3

Multiple VLAN/Single subnet

13/29

Design: VLAN PartitioningDesign: VLAN Partitioning

Selecting the number of Shadow Selecting the number of Shadow VLANsVLANs Cost of firewall serversCost of firewall servers Ease of managementEase of management Effectiveness of separating the Effectiveness of separating the

broadcast domainbroadcast domain

14/29

Design: FilteringDesign: Filtering

DHCPDHCP Allow request from client side to the routerAllow request from client side to the router Allow reply from the router to the clientAllow reply from the router to the client

ARPARP Assume that all wireless users are clients, the clients Assume that all wireless users are clients, the clients

will always issue the ARP requestwill always issue the ARP request Drop requests from the routerDrop requests from the router Allow request from client side to the routerAllow request from client side to the router Allow reply from the router to the clientAllow reply from the router to the client

NetBIOS broadcast/other broadcastsNetBIOS broadcast/other broadcasts Drop allDrop all

Design a daemon to permitting DHCP Design a daemon to permitting DHCP users/blocking static IP usersusers/blocking static IP users (Adjust the ipset)(Adjust the ipset)

15/29

Design: Force User to Use Design: Force User to Use DHCPDHCP

Bridge/Transparent Firewall

Router/DHCP Server Side

Client Side

Daemon

DHCP Offer/ACK Packets

ipset MemberDatabase

update

16/29

AgendaAgenda

BackgroundsBackgrounds Obstacles & OpportunitiesObstacles & Opportunities DesignDesign ImplementationImplementation ResultsResults ConclusionConclusion

17/29

Implementation: OverviewImplementation: Overview

Use two large subnet, 16 class C Use two large subnet, 16 class C eacheach The first subnet is for unencrypted The first subnet is for unencrypted

VLANVLAN The second subnet is for the WPA VLANThe second subnet is for the WPA VLAN

Split both unencrypted and WPA Split both unencrypted and WPA VLAN into 5 VLAN eachVLAN into 5 VLAN each

Use transparent firewall/bridge to Use transparent firewall/bridge to tie those VLANs togethertie those VLANs together

18/29

Implementation: Implementation: Transparent bridge/firewallTransparent bridge/firewall

Use Linux server as a bridgeUse Linux server as a bridge Iptables + ipset & ebtablesIptables + ipset & ebtables Focus on filtering of broadcast Focus on filtering of broadcast

packetspackets DHCPDHCP ARPARP NetBIOS broadcastNetBIOS broadcast

19/29

Implementation: Implementation: HardwareHardware

Sun Fire X2100Sun Fire X2100 Opteron™ 1210 Dual core(1.8 GHz)Opteron™ 1210 Dual core(1.8 GHz) 512MB of RAM512MB of RAM 300 GB SATA hard disk300 GB SATA hard disk Built-in Gigabit Ethernet ControllerBuilt-in Gigabit Ethernet Controller

20/29

Implementation: Implementation: SoftwareSoftware

Linux 2.6.23.9+ipset patch on Linux 2.6.23.9+ipset patch on CentOS 5 (64 bit)CentOS 5 (64 bit)

bridge-utilsbridge-utils ebtablesebtables Iptables 1.3.5 + ipset patchIptables 1.3.5 + ipset patch Create a daemon for permitting Create a daemon for permitting

DHCP users/blocking static IP usersDHCP users/blocking static IP users (Adjust the ipset)(Adjust the ipset)

21/29

Implementation: Implementation: Filtering/ebtablesFiltering/ebtables

Bridge chain: FORWARD, entries: 18, policy: ACCEPT-d 1:0:5e:0:0:2 -j DROP-d 1:0:5e:0:0:5 -j DROP-d 1:0:5e:0:0:d -j DROP-d 1:0:5e:7f:ff:fa -j DROP-d 1:0:c:cc:cc:cd -j DROP-d 1:0:c:cc:cc:cc -j DROP-d BGA -j DROP-d 33:33:0:0:0:5 -j DROP-p ARP -d Broadcast -i eth2 -j DROP-p ARP -j ACCEPT-p IPX -d Broadcast -j DROP-p NetBEUI -d Broadcast -j DROP-p IPv4 -d Broadcast --ip-proto udp --ip-dport 137:138 -j DROP-p IPv4 -d Broadcast -i eth3.112 --ip-proto udp --ip-dport 68 -j DROP-p IPv4 -d Broadcast -o eth3.112 --ip-proto udp --ip-dport 67 -j DROP-p IPv4 -j ACCEPT-p IPv6 -j ACCEPT-j DROP

22/29

Implementation: Implementation: Filtering/iptablesFiltering/iptables

Chain FORWARD (policy ACCEPT)target prot opt source destinationACCEPT 0 -- 0.0.0.0 0.0.0.0/0 PHYSDEV match --physdev-in eth3.112ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in eth3.112 \

set fixip src,srcACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in eth3.112 \

set usedhcp src,srcLOG 0 -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in eth3.112 \

LOG flags 0 level 4DROP 0 -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in eth3.112

23/29

Implementation: Implementation: Filtering/ipsetFiltering/ipsetName: fixip

Type: ipmapReferences: 1Default binding:Header: from: 158.108.0.0 to: 158.108.255.255Members:158.108.X.X158.108.X.X…Bindings:

Name: usedhcpType: macipmapReferences: 1Default binding:Header: from: 158.108.0.0 to: 158.108.255.255Members:158.108.X.X:XX:XX:XX:XX:XX:XX158.108.X.X:XX:XX:XX:XX:XX:XX…Bindings:

Manually insert to allow some IP to be set statically.

Automatically insert/removeBy the daemon to allow

DHCP users

24/29

AgendaAgenda

BackgroundsBackgrounds Obstacles & OpportunitiesObstacles & Opportunities DesignDesign ImplementationImplementation ResultsResults ConclusionConclusion

25/29

ResultsResults

From our experimentsFrom our experiments ARP broadcast from the router is ARP broadcast from the router is

greatly reducedgreatly reduced Rouge DHCP server still disturbed the Rouge DHCP server still disturbed the

local VLAN in which it is connected to local VLAN in which it is connected to but no longer effect the other Shadow but no longer effect the other Shadow VLAN, thus the scope is smallerVLAN, thus the scope is smaller

The latency introduced by adding The latency introduced by adding transparent firewall is very smalltransparent firewall is very small

26/29

AgendaAgenda

BackgroundsBackgrounds Obstacles & OpportunitiesObstacles & Opportunities DesignDesign ImplementationImplementation ResultsResults ConclusionConclusion

27/29

ConclusionsConclusions A wireless network deployment that A wireless network deployment that

combine the efficient IP address combine the efficient IP address allocation of single subnet design with allocation of single subnet design with the (partial) broadcast domain the (partial) broadcast domain separation of multiple subnet designseparation of multiple subnet design Rouge DHCP server will not effect the Rouge DHCP server will not effect the

whole subnetwhole subnet The number of broadcast is reducedThe number of broadcast is reduced Roaming within the campus is seamlessRoaming within the campus is seamless

Prevent the users from using static IP Prevent the users from using static IP address in the wireless networkaddress in the wireless network

28/29

Future WorksFuture Works

Rouge Access Point Detection and Rouge Access Point Detection and BlockingBlocking

29/29

Questions?

Thank you!Thank you!