Previous Section  < Day Day Up >  Next Section

Deploying a Linux-Based, Custom-Built Hardened Wireless Gateway

Next we have to ensure the security of the gateway that separates our AP or bridge or wireless-connected VLAN from the wired side. As was already mentioned, such gateways are nothing more (or less) than a flexible stateful or proxy firewall that treats the interface connected to the WLAN side as an interface connecting the LAN to an insecure public network. The only specific requirement for the gateway is a capability to forward VPN traffic if VPN is implemented on the WLAN. Alternatively, the gateway can be a VPN concentrator if you want to cut spending on network security (usually not a good idea). If the VPN lies on the transport layer (e.g., cIPe), forwarding the traffic is straightforward: Open the ports used by the VPN protocol and let it go. Forwarding IPSec traffic is trickier. You have to allow protocols 50 or 51 through as well as have the UDP 500 port open for the IKE exchange. An example from the Linux Netfilter script allowing IPSec traffic through is shown here:






iptables -A INPUT -i $EXT -p 50 -j ACCEPT

iptables -A INPUT -i $EXT -p 51 -j ACCEPT

iptables -A INPUT -i $EXT -p udp --sport 500 --dport 500 -j ACCEPT


A good idea is to set static ARP table entries for all access points and critical servers connected to the gateway. Place the following lines into your /etc/rc.local if applicable:








arp -s <AP1 IP> <AP1 MAC>

arp -s <AP2 IP> <AP2 MAC>

..............................................

arp -s <VPN concentrator IP> <VPN concentrator MAC>

arp -s <RADIUS server IP> <RADIUS server MAC>

arp -s <Internet Gateway IP> <Internet Gateway MAC>


You can also use the gateway as a DHCP server. Edit the /etc/dhcpcd.conf file to contain something like this:








# dhcpd.conf # # Configuration file for ISC dhcpd (see 'man dhcpd.conf') # deny unknown-clients; one-lease-per-client true; authoritative; default-lease-time 604800; max-lease-time 604800; option subnet-mask 255.255.255.192; option domain-name "domain.name"; subnet 192.168.1.0 netmask 255.255.255.192 { option broadcast-address 192.168.1.63; option routers 192.168.1.2; option domain-name-servers 192.168.1.2, 192.168.1.3; option smtp-server 192.168.1.2; option pop-server 192.168.1.2; option netbios-name-servers 192.168.1.3; #Sales Department laptops host toad1 { hardware ethernet <MAC>; fixed-address 192.168.1.1; option host-name "toad1"; } host toad2 { hardware ethernet <MAC>; fixed-address 192.168.1.2; option host-name "toad2"; } host toad3 { hardware ethernet <MAC>; fixed-address 192.168.1.3; option host-name "toad3"; } host toad4 { hardware ethernet <MAC>; fixed-address 192.168.1.10; option host-name "toad4"; } #Accounting Department laptops host gebril1 { hardware ethernet <MAC>; fixed-address 192.168.1.11; option host-name graphics/ccc.gif "gebril1"; } host gebril2 { hardware ethernet <MAC>; fixed-address 192.168.1.12; option host-name graphics/ccc.gif "gebril2"; } #Brokering Department laptops host tsetse1 { hardware ethernet <MAC>; fixed-address 192.168.1.15; option host-name graphics/ccc.gif "tsetse1"; } host tsetse2 { hardware ethernet <MAC>; fixed-address 192.168.1.16; option host-name graphics/ccc.gif "tsetse2"; } host tsetse3 { hardware ethernet <MAC>; fixed-address 192.168.1.17; option host-name graphics/ccc.gif "tsetse"; }

In this example the IP addresses are assigned on the MAC address basis so that the attacker will have to spoof the MAC address of a legal host to obtain an IP address from the DHCP server. This might confuse a low-level attacker for a while: The server is there, DHCP traffic is flowing, but no IP address is assigned.

What if the access point, gateway, firewall, authentication server, and VPN concentrator are combined on a single machine? Under Linux it is possible. It is also possible to use a BSD platform to create such a host, but writing about anything we don't have hands-on experience with is not the path we follow.

Setting a secure access point using HostAP is far more of a real network hacking challenge than setting a rogue AP on a Linux laptop, as described in Chapter 8. The reason for this is that there are many advanced HostAP features that are usually unnecessary when setting up a basic rogue AP but that come in very handy when deploying a proper AP. Such capabilities include the following:

  • MAC filtering

  • Closed ESSIDs (yes, it's possible with HostAP)

  • 802.1x authentication support

  • Wireless distribution system (WDS)

You can even plug more PCI or PCMCIA cards into a custom-built universal wireless gateway and run them using the same HostAP driver to provide access on three different channels for round-robin load balancing using Netfilter. Alternatively, one of the plugged cards can be put into the monitoring mode and used to run a network monitoring or IDS tool (see the Chapter 15 for more details).

In this chapter we do not discuss WDS deployment and other HostAP features not directly relevant to security. Playing with these settings is great hacking fun, though. Just check how many private wireless extensions can be supported by your card firmware and what configuration feats can be performed with prism2_param and hostapd. The discussion of authentication mechanisms and VPN implementations on a Linux wireless gateway belongs in Chapters 13 and 14. Here we concentrate on AP security and the capabilities of our custom-built wireless gateways.

To enable your wireless gateway access point startup, add the AP parameters to the appropriate startup file. As an example, on Debian we'll use /etc/network/interfaces and add something like this:






auto wlan0

iface wlan0 inet static

        address 0.0.0.0

        up /sbin/iwconfig wlan0 essid Arh0nt-X

        /sbin/iwconfig wlan0 channel 11

        /sbin/iwconfig wlan0 mode Master

auto eth0

iface eth0 inet static

        address 0.0.0.0

auto br0

iface br0 inet static

       address 192.168.1.1

       network 192.168.1.0

       netmask 255.255.255.0

       broadcast 192.168.1.255

       bridge_ports wlan0 eth0

       up


Because it's Linux, there are always multiple ways to do it (e.g., see Bruce Potter's and Bob Fleck's "802.11 Security" for a different approach). Pick the one you like the most.

MAC filtering with HostAP is done using its private wireless extensions:






iwpriv wlan0 maccmd <val>

        0: open policy for ACL (default)

        1: allow policy for ACL

        2: deny policy for ACL

        3: flush MAC access control list

        4: kick all authenticated stations



iwpriv wlan0 addmac <mac addr>

        add mac addr into access control list



iwpriv wlan0 delmac <mac addr>

        remove mac addr from access control list



iwpriv wlan0 kickmac <mac addr>

        kick authenticated station from AP


To create an ACL use iwpriv wlan0 maccmd <ACL number>. The README suggests keeping two ACLs: one for accepted and one for explicitly denied MAC addresses. This could be a good idea.

Alternatively, you can always use the Netfilter for MAC filtering:






$IPTABLES -N macfilter

$IPTABLES -A macfilter -i $WLAN_INTERFACE -m mac -mac-source de:ad:be:ef:co:de -j ACCEPT

$IPTABLES -A macfilter -i ! $WLAN_INTERFACE -j ACCEPT

$IPTABLES -A macfilter -j LOG

$IPTABLES -A macfilter -j DROP

$IPTABLES -A FORWARD -j macfilter


However, we recommend HostAP filtering: It's very straightforward to use and you can kick out suspicious authenticated hosts with ease.

To improve your custom-built AP security, use the prism2_param wlan0 enh_sec 3 command to employ hidden ESSID and ignore probe requests with the ANY ESSID. The AP Prism chipset card must have the latest STA firmware to support the enh_sec extension. Check which wireless extensions your current firmware supports by running the iwpriv wlan0 command and verify the firmware version with prism_diag wlan0. Look for the output line saying "(station firmware)." To update the firmware, you must have HostAP compiled with the PRISM2_DOWNLOAD_SUPPORT function. This can be done by directly modifying the driver/modules/hostap_config.h header file or compiling HostAP with make pci || pccard EXTRA_CFLAGS="-DPRISM2_DOWNLOAD_ SUPPORT". Do make install, run depmod -a, and use the prism2_srec utility to update your firmware:






arhontus:# ./prism2_srec

Usage: prism2_srec [-vvrfd] <interface> <srec file name>

Options:

  -v   verbose (add another for more verbosity)

  -r   download SREC file into RAM (volatile)

  -f   download SREC file into flash (non-volatile)

  -d   dump SREC image into prism2_srec.dump

  -i   ignore incompatible interfaces errors

       Warning! This can result in failed upgrade!


The -r and -f options cannot be used together. If -r or -f is not specified, image summary is shown and compatibility with the WLAN card is verified without downloading anything.

Check that the -f option is supported properly with your HostAP utilities version; otherwise, it will be necessary to do the firmware update with -r each time the card is reset. You can get the newer STA firmware hex images from http://www.intersil.com/design/prism/ss/p2smtrx.asp or http://www.netgate.com/support/prism_firmware/. Then run









prism2_srec -f wlan0 /path/to/firmware/<imagefile.hex>


and check if the update is successful with prism2_diag wlan0.

To enable 802.1x support, the Authenticator functionality in the hostapd daemon has to be employed. The Authenticator in hostapd relays the frames between the supplicant and the authentication server, which has to be RADIUS only. To use the authenticator, compile the HostAP driver with make pci || pccard EXTRA_CFLAGS="-DPRISM2_HOSTAPD" or edit driver/modules/hostap_config.h before the compilation. An external RADIUS server is configured with





arhontus:/#prism2_param wlan0 ieee_802_1x 1 arhontus:/#hostapd -x -o <AP IP address> -a <RADIUS server IP address> -s <shared secret graphics/ccc.gif AP-auth.serv.> wlan0

The authenticator in hostapd can automatically select a random default and broadcast WEP key shared by all authenticated stations. The selection is done with -b5 (64-bit WEP) or -b13 (128-bit WEP) flags passed to hostapd. In addition, the -i5 or -i13 option can be used to set individual unicast keys for stations. This demands individual key support in the station driver. Set the individual keys using the hostap_crypt_conf utility:






arhontus:# ./hostap_crypt_conf



Usage: hostap_crypt_conf [-123456789tpl] <device> [addr] [alg] [key]

Options:

  -1 .. -9   key index (for WEP); only one index per command

  -t         set TX key index (given with -1 .. -9)

  -p         permanent station configuration (do not expire data)

  -l         list configured keys (do not use addr or alg)

  device     wlan#

  addr       station hwaddr or ff:ff:ff:ff:ff:ff for default/broadcast key

  alg        crypt algorithm (WEP, NULL, none)

  key        key data (in hex, e.g. '0011223344', or s:string)



Algorithms:

  WEP        40 or 104 bit WEP

  NULL       NULL encryption (i.e., do not encrypt/decrypt);

             used to configure no encryption for given

             station when using default encryption

  none       disable encryption


Although you can also set HostAP client WEP keys using iwconfig, you won't be able to configure the individual keys for hostapd unicast key support using this command.

Setting a perfect access point using HostAP and ensuring that this AP supports all the features just described is not an easy task. However, it is a great way to learn about wireless and can save your business or wireless community a lot of money. Just check out how much a commercial wireless gateway supporting all capabilities a Linux-based custom-built gateway or AP can possess would cost. You will be surprised. Do not forget that the majority of high-end commercial wireless gateways do not have AP functionality and you will have to buy extra access points to build your network.

The major disadvantage of the "all-in-one" solution is a single point of failure. Thus, we suggest you unload some functions on a second machine. In particular, this applies to the RADIUS authentication server. The wireless gateway should have the minimal number of ports opened to the wireless side. Regarding the security of the gateway itself, we recommend the following hardening measures:

  • Enable access to the gateway to administrators only.

  • Remove unnecessary user accounts.

  • Do not run the X Window server.

  • Close all unnecessary ports.

  • Firewall the SSH administrative access from the wireless side.

  • Remove GCC and other compilers from the gateway.

  • Remove interpreted languages such as Perl.

  • Apply the OpenWall or Grsecurity security patch to the kernel.

  • Configure and run the StJude kernel module.

  • Use logrotate and send logs to the remote syslog server via TCP using syslog-ng.

  • Install, configure, and run Snort.

For the truly paranoid, there is always LIDS and security-enchanced Linux distributions such as National Security Agency (NSA) SELinux or Immunix. A properly configured and looked-after Linux machine is as secure as can be; do not blame the system when the real flaw is the system administrator's laziness and ignorance.

    Previous Section  < Day Day Up >  Next Section