15. Manual Network Connections
Wireless penetration testing tools usually require disabling network managers because they interfere with the proper operation of the tools.
However, in some instances, we need to have Internet at the same time or sometimes even share it. While this can usually be done with network managers, we will learn how to set it up manually since they are disabled.
Needless to say, we need separate network interfaces from the ones we are using for penetration testing.
15.1. Connecting to an Access Point
Several wireless clients exist on Linux. The most common one is wpa_supplicant,1 as it is commonly used by network managers across Linux distributions to connect to Wi-Fi networks, even if they don't have any encryption or still uses WEP.
wpa_supplicant can either be used via a command line interface, with wpa_cli, or with configuration files containing the settings of the network. In a sample configuration file, each network connection is defined within a network item.
Listing 1 - Simple wpa_supplicant configuration for an open network
The above example allows the system to connect to an Open network, called "hotel_wifi" as indicated in the second line, and wpa_supplicant is instructed, in the third line, to scan for SSIDs first.
Connecting to a WPA-PSK network is a bit more involved. We need to add two parameters inside the network item:
network={
ssid="home_network"
scan_ssid=1
psk="correct battery horse staple"
key_mgmt=WPA-PSK
}
Listing 2 - Simple wpa_supplicant configuration for a WPA or WPA2-PSK network
wpa_supplicant will automatically choose between TKIP and CCMP based on availability, but it is possible to force one or the other by adding pairwise=CCMP or pairwise=TKIP to the configuration if necessary.
wpa_supplicant supports WPA3, OWE, and can handle WPA Enterprise networks as well; however, these are out of scope of this module. The configuration file provided with the wpa_supplicant source code2 provides a number of examples for various network settings, including WPA3, OWE, and WPA Enterprise.
Warning
A quick and easy alternative is wpa_passphrase.3 This tool can generate a configuration file for a basic WPA-PSK network. It requires at least one parameter, the ESSID. The second parameter, the passphrase, is optional, for security reasons. If the second parameter is omitted, it will prompt for the passphrase. This tool will output the content of a configuration file. We can redirect the output to a file with 'wpa_passphrase home_network > home_network.conf'
Using the example in the above listing, we'll create a file called wifi-client.conf. We now have to start wpa_supplicant with a couple parameters. To connect to the network, we have to start wpa_supplicant with the network interface using -i, and the configuration file with -c. Assuming the interface is wlan0, the command and the output will look like the following.
kali@kali:~$ sudo wpa_supplicant -i wlan0 -c wifi-client.conf
Successfully initialized wpa_supplicant
wlan0: SME: Trying to authenticate with 00:ef:78:be:0d:98 (SSID='home_network' freq=2437 MHz)
wlan0: Trying to associate with 00:ef:78:be:0d:98 (SSID='home_network' freq=2437 MHz)
wlan0: Associated with 00:ef:78:be:0d:98
wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
wlan0: WPA: Key negotiation completed with 00:ef:78:be:0d:98 [PTK=CCMP GTK=CCMP]
wlan0: CTRL-EVENT-CONNECTED - Connection to 00:ef:78:be:0d:98 completed [id=0 id_str=]
...
Listing 3 - Connecting to home_network
Now that we've confirmed we can successfully connect to the network, we can append -B to our wpa_supplicant command line to run it in the background.
Once connected, we usually request a DHCP lease using dhclient:
Listing 4 - Getting a DHCP lease on wlan0
1 (Jouni Malinen, 2013), https://w1.fi/wpa_supplicant/ ↩︎
2 (Jouni Malinen and contributors, 2019, 2019), https://w1.fi/cgit/hostap/tree/wpa_supplicant/wpa_supplicant.conf ↩︎
3 (linux.die.net), https://linux.die.net/man/8/wpa_passphrase ↩︎
15.2. Setting up an Access Point
Setting up an access point requires two distinct network interfaces, and involves five steps:
- Configure Internet access on the system.
- Set up a static IP for the wireless interface.
- DHCP server set up, to provide automatic IP configuration for Wi-Fi clients.
- Add routing to provide Internet access to the Wi-Fi clients.
- Configure the Wi-Fi interface in AP mode.
15.2.1. Internet Access
We first need to have Internet access on the system. It doesn't really matter if it is via Ethernet, Wi-Fi, or if it's mobile broadband.
Ethernet is fairly easy to set up, and in most cases, we just need to get a DHCP lease like we did in Listing 4.
If the connection is Wi-Fi, we can refer to the section above to configure it. It is important to note that while it is possible to do client and AP on a single Wi-Fi interface, configuration is a bit more involved, has limitations, and may not work properly (the Wi-Fi adapters recommended for this course provide this ability). Therefore, we must be careful choosing the interface to use for the access point, as not all Wi-Fi adapters support that mode. We can use iw to display what modes each of the wireless interface support.
kali@kali:~$ sudo iw list
...
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
* P2P-client
* P2P-GO
* outside context of a BSS
...
Listing 5 - Listing support modes on all wireless interfaces
We will not be covering mobile broadband, as adapter support (or lack thereof) varies from one cell phone provider to another. A mobile broadband router with Ethernet or Wi-Fi removes all the complexity of dealing with a mobile cellular connection.
15.2.2. Static IP on Access Point Wireless Interface
We now have to choose an IP address that doesn't conflict with the network and CIDR of the interface we just configured for Internet. Most routers offer an IP in the 192.168.1.0/24 range, so we will use the 10.0.0.0/24 range and set the wireless interface for the access point to 10.0.0.1. We'll assume the interface is wlan0.
Listing 6 - Setting the IP address to wlan0
15.2.3. DHCP Server
We will set up the DHCP server on the wireless interface (wlan0) using dnsmasq,1 which is a DNS and DHCP server. We'll create the following configuration file and save it as dnsmasq.conf.
# Main options
# http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html
domain-needed
bogus-priv
no-resolv
filterwin2k
expand-hosts
domain=localdomain
local=/localdomain/
# Only listen on this address. When specifying an
# interface, it also listens on localhost.
# We don't want to interrupt any local resolution
listen-address=10.0.0.1
# DHCP range
dhcp-range=10.0.0.100,10.0.0.199,12h
dhcp-lease-max=100
# Router: wlan0
dhcp-option=option:router,10.0.0.1
dhcp-authoritative
# DNS: Primary and secondary Google DNS
server=8.8.8.8
server=8.8.4.4
Listing 7 - dnsmasq configuration file, dnsmasq.conf
The listen-address and router option is the address of our wlan0 interface. The dhcp-range will be a range of IP addresses we want to provide our clients, followed by the length of the lease. The two server entries are upstream DNS servers.
Now that our dnsmasq configuration is complete, we will run dnsmasq with --conf-file followed by the path of our configuration file.
Listing 8 - Starting dnsmasq
After startup, dnsmasq will create a file containing its process ID in /var/run/dnsmasq.pid, which lets us find and kill the process when we are done. We will inspect syslog2 to confirm it started successfully.
kali@kali:~$ sudo tail /var/log/syslog | grep dnsmasq
Nov 10 19:36:39 kali dnsmasq[158592]: started, version 2.82 cachesize 150
Nov 10 19:36:39 kali dnsmasq[158592]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify dumpfile
Nov 10 19:36:39 kali dnsmasq-dhcp[158592]: DHCP, IP range 10.0.0.100 -- 10.0.0.199, lease time 12h
Nov 10 19:36:39 kali dnsmasq[158592]: using nameserver 8.8.4.4#53
Nov 10 19:36:39 kali dnsmasq[158592]: using nameserver 8.8.8.8#53
...
Listing 9 - Checking for dnsmasq in syslog
1 (Simon Kelley, 2021), http://www.thekelleys.org.uk/dnsmasq/doc.html ↩︎
2 (Stackify, 2020), https://stackify.com/syslog-101/ ↩︎
15.2.4. Routing
We now have to enable routing and add a few firewall rules so we can act as a router and allow clients to reach the Internet. We first have to enable IP forwarding, which we can do by setting the ip_forward kernel variable to "1".
Listing 10 - Enabling IP forwarding
Although this should technically suffice to forward packets over to the Internet, our clients have a different IP address range than the one of our Internet connection. Since the Internet doesn't know where to route that back, packets will get dropped. In order to resolve this situation, we have to masquerade our IP as coming from the Internet interface, which is done with a single firewall rule.
We need to install nftables1 first.
Listing 11 - Installing nftables
We'll add a rule to masquerade our Wi-Fi client's IP addresses when the traffic is going from the wireless interface to one with Internet, like our home router does. It will exchange the client's IP address with the address of the interface where the packet gets out. The kernel keeps track of the connections in memory so it knows who a packet belongs to when it gets back.
The first command adds the NAT2 table. The second one adds a chain for postrouting that is necessary because masquerade edits the IP address after the routing decision has been done and right before it gets out. The last one is the rule doing the masquerade. It will do the masquerade when the packet matches a few criteria: for any traffic going to the output interface (oifname), eth0, and has a destination IP addresses (daddr) not in the range of 10.0.0.1/24 (which is the range of our clients).
kali@kali:~$ sudo nft add table nat
kali@kali:~$ sudo nft 'add chain nat postrouting { type nat hook postrouting priority 100 ; }'
kali@kali:~$ sudo nft add rule ip nat postrouting oifname "eth0" ip daddr != 10.0.0.1/24 masquerade
Listing 12 - Doing masquerade with nftables
1 (nftables, 2021), https://wiki.nftables.org/wiki-nftables/index.php/Main_Page ↩︎
2 (Wikipedia, 2021), https://en.wikipedia.org/wiki/Network_address_translation ↩︎
15.2.5. Access Point Mode
We now only have the access point left to configure and bring up. It goes without saying that if we just wanted to provide Internet to a wired client, all we have to do is replace all the instances of wlan0 in the commands of the above steps, with the ethX interface we want to use, and skip this step.
For a simple 802.11n WPA2 PSK network called "BTTF" on channel 11 with "GreatScott" as a passphrase, the configuration look like this:
interface=wlan0
ssid=BTTF
channel=11
# 802.11n
hw_mode=g
ieee80211n=1
# WPA2 PSK with CCMP
wpa=2
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
wpa_passphrase=GreatScott
Listing 13 - hostapd configuration, hostapd.conf
Now, we need to run hostapd and provide a single parameter, its configuration file.
kali@kali:~$ sudo hostapd hostapd.conf
Configuration file: hostapd.conf
Using interface wlan0 with hwaddr 00:af:8d:09:23:f9 and ssid "BTTF"
wlan0: interface state UNINITIALIZED->ENABLED
wlan0: AP-ENABLED
...
wlan0: STA 00:e4:89:02:7a:0f IEEE 802.11: authenticated
wlan0: STA 00:e4:89:02:7a:0f IEEE 802.11: associated (aid 1)
wlan0: AP-STA-CONNECTED 00:e4:89:02:7a:0f
wlan0: STA 00:e4:89:02:7a:0f RADIUS: starting accounting session 7F52FE0899A8A460
wlan0: STA 00:e4:89:02:7a:0f WPA: pairwise key handshake completed (RSN)
Listing 14 - Starting hostapd with our AP configuration
Now that we can see hostapd is starting and clients connecting successfully, we can later run it in the background, by using -B parameter before the configuration filename.