1 / 29

Transparent Firewall for Wireless Network

Transparent Firewall for Wireless Network. Kasom Koth- a rsa 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

kmaggard
Télécharger la présentation

Transparent Firewall for Wireless Network

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Agenda • Backgrounds • Obstacles & Opportunities • Design • Implementation • Conclusion

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

  4. KUWiN Currently 452 APs available (2008/01/18) Campus Ministry of Agriculture 1.5 km

  5. Agenda • Backgrounds • Obstacles & Opportunities • Design • Implementation • Results • Conclusion

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

  7. Agenda • Backgrounds • Obstacles & Opportunities • Design • Implementation • Results • Conclusion

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

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

  10. Design: The New KUWiN • Multiple VLANs • 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 • Split the unencrypted and WPA VLAN into multiple VLANs • Join those VLAN together with transparent bridge/firewalls

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

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

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

  14. Design: Filtering • DHCP • Allow request from client side to the router • Allow reply from the router to the client • ARP • 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 • NetBIOS broadcast/other broadcasts • Drop all • Design a daemon to permitting DHCP users/blocking static IP users(Adjust the ipset)

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

  16. Agenda • Backgrounds • Obstacles & Opportunities • Design • Implementation • Results • Conclusion

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

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

  19. Implementation: Hardware • Sun Fire X2100 • Opteron™ 1210 Dual core(1.8 GHz) • 512MB of RAM • 300 GB SATA hard disk • Built-in Gigabit Ethernet Controller

  20. Implementation: Software • Linux 2.6.23.9+ipset patch on CentOS 5 (64 bit) • bridge-utils • ebtables • Iptables 1.3.5 + ipset patch • Create a daemon for permitting DHCP users/blocking static IP users(Adjust the ipset)

  21. Implementation: Filtering/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. Implementation: Filtering/iptables Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT 0 -- 0.0.0.0 0.0.0.0/0 PHYSDEV match --physdev-in eth3.112 ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in eth3.112 \ set fixip src,src ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in eth3.112 \ set usedhcp src,src LOG 0 -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in eth3.112 \ LOG flags 0 level 4 DROP 0 -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in eth3.112

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

  24. Agenda • Backgrounds • Obstacles & Opportunities • Design • Implementation • Results • Conclusion

  25. Results • From our experiments • ARP broadcast from the router is greatly reduced • 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 • The latency introduced by adding transparent firewall is very small

  26. Agenda • Backgrounds • Obstacles & Opportunities • Design • Implementation • Results • Conclusion

  27. Conclusions • 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 • The number of broadcast is reduced • Roaming within the campus is seamless • Prevent the users from using static IP address in the wireless network

  28. Future Works • Rouge Access Point Detection and Blocking

  29. Thank you! Questions?

More Related