<< back to toc

All authorization is done with netfilter.

Netfilter basics

Netfilter is the packet filter framework in the TCP/IP stack of the Linux 2.4.x and 2.6.x kernel. The user space program used to configure the packet filter is called iptables.
Netfilter consists of with three different tables, each table contains a set of predefined chains. Each packet received on a network interface or created by a process is passed through one or more of these chains. The chains consist of a list of rules. Each rule specifies a set of parameters and an action to be taken if a packet header matches these parameters. If a packet header does not match any rule, the default target of the chain is applied to the packet.
The filter table is used for traditional packet filtering, ie rejecting or accepting packets. It contains three chains: the input chain processes all packets which have a destination IP address of this host. The output chain processes all packets which originate on this host. All packets which are merely routed to other hosts are processed by the forward chain.
The nat table is used for network address translation. It contains two relevant chains: packets are processed by the prerouting chain before a routing decision is made depending on their destination IP. Destination network address translation, where a packets destination IP gets changed, is done here. After a routing decision is made for a packet, it is processed by the postrouting chain. Source network address translation, where the source IP address gets changed, is done here.
The third table is called mangle and can be used to further alter the content of packets, but this functionality is not needed for authorization.
More information on netfilter and iptables can be found at netfilter.org.

Goals

There are five distinct goals which have to be achieved by implementing fitting netfilter rules:

• Blocking of unauthorized traffic
  Clients which are connected to the hotspot, but who have not yet authenticated themselves, should not be allowed to access the Internet. The only resources they are allowed to access are a predefined list of web sites and the Domain Name Service. (There is no point in denying outbound DNS, since one can tunnel through DNS on the application layer anyway. Also, DNS timeouts are rather long.)
• Routing of authorized traffic
  All IP packets from clients who have authenticated themselves correctly have to be routed to the desired destinations.
• Redirection of unauthorized web access
  In order to make the authentication process as smooth as possible, unauthenticated clients which try to access a web site on the Internet via HTTP or HTTPS should get redirected to the hotspots authentication web page. This is done with a combination of HTTP REDIRECT and IP destination network address translation.
• Masquerading of clients
  Since the clients are assigned IP addresses from the private IP space [RFC #1918], all IP packets originating from a client and destined for the Internet have to have their source IP address changed ("masqueraded") to that of the hotspots uplink interface. This is also called source network address translation. As an added feature, this also protects the clients from network attacks coming from the Internet, since the clients can not be addressed directly. Of course this also means that the clients cannot offer services to the internet, which could be problem when trying to use services like Internet Relay Chat or Instant Messaging.
• Enhanced security
  Of course the packet filter can be used to block unwanted traffic to the hotspot. It could also be used to watch for suspiscious-looking packets originating from a client, but this is not implemented here.

Filter Rules Design Philosophy

The filter rules where designed following the philosophy that it is sufficient to regulate outbound traffic, since due to the SNAT, there will be no inbound traffic which is not a response to an outbound request.

The whole script can be found here: firewall.sh.

Filter Architecture

All incoming packets traverse the prerouting chain first. Depending on their (possibly altered) destination address, they traverse the input or forward chain next. If they are to be forwarded (and have not been dropped yet), they traverse the postrouting chain before being handled to the interface chosen by the routing algorithm.


image #18: Filter architecture

Since different measures have to be taken in the prerouting, forward and postrouting chain for clients depending on their authentication status, three user chains are created:
$IPTABLES -t nat -N DCLIENT
$IPTABLES -t filter -N FCLIENT
$IPTABLES -t nat -N SCLIENT

All packets from clients are passed to the corresponding user chain from the prerouting, forward and postrouting chain:
$IPTABLES -t nat -A PREROUTING -i $WIFI_DEV -d ! $WIFI_SELF -j DCLIENT
$IPTABLES -t filter -A FORWARD -i $WIFI_DEV -o $INET_DEV -s $WIFI_NET -j FCLIENT
$IPTABLES -t nat -A POSTROUTING -s $WIFI_NET -d ! $WIFI_NET -j SCLIENT

The prerouting chain contains a rule to rewrite the destination IP address of HTTP/HTTPS traffic to the hotspots WLAN IP address. This rule is placed after the jump to the user chain, so only packets which are not ACCEPTed by the user chain are DNATed:
for PORT in 80 443; do
$IPTABLES -t nat -A PREROUTING -i $WIFI_DEV -d ! $WIFI_SELF -p tcp --dport $PORT -j DNAT --to $WIFI_SELF
done

The forwarding chain contains a rule to reject all packets. Only packets which have not been ACCEPTed by the user chain reach this rule:
$IPTABLES -t filter -A FORWARD -i $WIFI_DEV -o $INET_DEV -s $WIFI_NET -j REJECT --reject-with icmp-net-prohibited

The postrouting chain does nothing by default, but packets which match a rule in the user chain will get SNATed.

Now the only thing needed is a way to add authenticated clients to the user chains and to remove deauthenticated clients from them. New clients are added via the addClient keyword. This is typically called by the web script in charge of checking the user-supplied authentication data with the database backend, index.php. The calling programm has to supply an IP address / MAC address pair of the client to be added to the chains:
$IPTABLES -t filter -A FCLIENT -s $IP -m mac --mac-source $MAC -j ACCEPT
$IPTABLES -t nat -A DCLIENT -s $IP -m mac --mac-source $MAC -j ACCEPT
$IPTABLES -t nat -A SCLIENT -s $IP -d ! $WIFI_NET -j SNAT --to $INET_SELF

Clients are removed from the chains via the delClient keyword, typically called by the expire.php shell script which scans for expired authentications periodically. The calling programm has to supply the IP address / MAC address pair of the client to be removed from the chains:

$IPTABLES -t filter -D FCLIENT -s $IP -m mac --mac-source $MAC -j ACCEPT
$IPTABLES -t nat -D DCLIENT -s $IP -m mac --mac-source $MAC -j ACCEPT
$IPTABLES -t nat -D SCLIENT -s $IP -d ! $WIFI_NET -j SNAT --to $INET_SELF


Example: unauthorized Internet access

When a client who has not authenticated itself yet tries to access a non-web resource on the Internet, the following happens: The prerouting chain does nothing, since the destination port is not 80 [HTTP]. The forward chain rejects the packet since the clients IP and MAC address were not added to the FCLIENT chain, so the REJECT rule applies. Thus, access is forbidden for an unauthenticated client.


image #19: unauthorized internet access

Example: unauthorized web access

When a not authenticated client tries to access an Internet web resource, the following happens: The prerouting chain replaces the original destination IP of the packet with the IP of the hotspots WLAN interface, since the IP and MAC of the client were not added to the DCLIENT chain. Because of the new destination, the packet traverses the INPUT chain, which ACCEPTs the packet. The packet is passed to the local web server, which responds to the clients HTTP request with its own authentication page.


image #20: unauthorized web access

Example: authorized access

When an authenticated client tries to access an Internet web resource, the following happens: The prerouting chain ACCEPTs the packet (==does nothing), since the clients MAC and IP address are part of the DCLIENT chain. The forward chains ACCEPTs the packet, since the clients MAC and IP are part of the FCLIENT chain. The postrouting chain substitutes the clients source IP address with the hotspots uplink address because the clients IP address is in the SCLIENT chain, thus enabling the client to access the requested web resource.


image #21: authorized access

Loose ends

To allow the operator of the hotspot to offer the customers free access to predefined sites, the user chains DSERVER, FSERVER and SSERVER were created. They are used in a way similar to the ?CLIENT chains. All DNS traffic is routed and SNATed by default, but only to two predefined DNS servers (which have to be the same like those advertised via DHCP).