transparent firewall for wireless network l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Transparent Firewall for Wireless Network PowerPoint Presentation
Download Presentation
Transparent Firewall for Wireless Network

Loading in 2 Seconds...

play fullscreen
1 / 29

Transparent Firewall for Wireless Network - PowerPoint PPT Presentation


  • 179 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Transparent Firewall for Wireless Network' - michi


Download Now 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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
transparent firewall for wireless network

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

agenda
Agenda
  • Backgrounds
  • Obstacles & Opportunities
  • Design
  • Implementation
  • Conclusion
kasetsart university wireless network
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
kuwin
KUWiN

Currently 452 APs available (2008/01/18)

Campus

Ministry of Agriculture

1.5 km

agenda5
Agenda
  • Backgrounds
  • Obstacles & Opportunities
  • Design
  • Implementation
  • Results
  • Conclusion
obstacles opportunities
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
agenda7
Agenda
  • Backgrounds
  • Obstacles & Opportunities
  • Design
  • Implementation
  • Results
  • Conclusion
design the two extreme
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
design previous kuwin
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

design the new kuwin
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
design shadow vlans
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
design shadow vlan logical view
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

design vlan partitioning
Design: VLAN Partitioning
  • Selecting the number of Shadow VLANs
    • Cost of firewall servers
    • Ease of management
    • Effectiveness of separating the broadcast domain
design filtering
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)
design force user to use dhcp
Design: Force User to Use DHCP

Router/DHCP Server Side

DHCP Offer/ACK Packets

Bridge/

Transparent Firewall

Daemon

ipset MemberDatabase

update

Client Side

agenda16
Agenda
  • Backgrounds
  • Obstacles & Opportunities
  • Design
  • Implementation
  • Results
  • Conclusion
implementation overview
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
implementation transparent bridge firewall
Implementation: Transparent bridge/firewall
  • Use Linux server as a bridge
  • Iptables + ipset & ebtables
  • Focus on filtering of broadcast packets
    • DHCP
    • ARP
    • NetBIOS broadcast
implementation hardware
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
implementation software
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)
implementation filtering ebtables
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

implementation filtering iptables
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

implementation filtering ipset
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

agenda24
Agenda
  • Backgrounds
  • Obstacles & Opportunities
  • Design
  • Implementation
  • Results
  • Conclusion
results
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
agenda26
Agenda
  • Backgrounds
  • Obstacles & Opportunities
  • Design
  • Implementation
  • Results
  • Conclusion
conclusions
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
future works
Future Works
  • Rouge Access Point Detection and Blocking
thank you
Thank you!

Questions?