Tag: network

Using iwd for WiFi in Fedora

Fedora uses NetworkManager as the default for managing all the various different types of network. Underneath NetworkManager uses wpa_supplicant to connect to 802.11 based, AKA WiFi, wireless networks. There is an alternative called iwd which in a number of use cases works better, it also has the advantage that it offloads a bunch of things like crypto to the kernel interfaces which makes it smaller, and it’s under active development. iwd has a nice straight forward interface as well as being supported as an alternative NetworkManager so it just works in Fedora whether via nmcli or your chosen desktop environment.

So how do you make use of it in Fedora? Well it’s been packaged and supported for some time so it’s quite straight forward and there’s two ways to use it with NetworkManager. You can either swap it out for wpa_supplicant, or they can be installed side by side and you can change the NetworkManager default in a config to enable easy testing/swapping.

Option 1 (side by side):

sudo dnf install -y iwd
sudo cat >> /etc/NetworkManager/conf.d/iwd.conf << EOF
[device]
wifi.backend=iwd
EOF
sudo systemctl restart NetworkManager

Option 2 (swap):

sudo dnf swap -y wpa_supplicant iwd
sudo systemctl restart NetworkManager

You can now connect to WiFi networks a before with NetworkManager. Note it loses exciting configured WiFi networks.

Using nmcli to configure a static dual stack wired network interface

I recently managed to break the network on my VM that hosts this blog. Basically I removed the NetworkManager-initscripts-ifcfg-rh package because I don’t use the old style ifcfg configuration anywhere else and I had forgotten how long I’d had this VM. So I went into the web console, manually bought up the network with ip commands and reinstalled the package but it made no difference. Oh well! Time to just move it to the new config so I just worked out the nmcli options for all the bits in the old ifcfg. This VM network is nothing special, it’s basically dual IPv4/IPv6 interface with associated DNS.

Step 1: Show existing connections:

$ sudo nmcli c
NAME  UUID                                  TYPE      DEVICE 
eth0  a603bba7-fad8-3c71-9d4c-2cd5dc50e114  ethernet  eth0

Step 2: Delete existing connection:

$ sudo nmcli c del a603bba7-fad8-3c71-9d4c-2cd5dc50e114

Step 3: Create a new connection (Note the IP addresses are random, the DNS servers are the Google public ones):

$ sudo nmcli c add type ethernet ifname eth0 con-name eth0 mac 80:00:00:ab:cd:ef ip4 192.168.10.6/24 gw4 192.168.10.1 ip6 fe80::b257:377c:e7b3:29ed/64 gw6 2A03:B0C0:0003:00D0:0000:0000:0000:0001 ipv4.dns "8.8.8.8 8.8.4.4" ipv6.dns "2001:4860:4860::8888 2001:4860:4860::8844"

Now the blog is back! The new connection is stored in /etc/NetworkManager/system-connections/eth0.nmconnection

Thoughts on Project Connected Home over IP (CHIP)

In late December 2019 Google, Amazon, Apple and a number of other companies announced Project Connected Home over IP. Like all Internet of Things I thought I would dig into it and see what it’s made up of.

First thoughts before I even began to dig were basically “well they got there eventually!” as I’ve long believed that for IoT in the home to be successful as a whole there needs to be a single set of open standards that all devices speak so that the things can intercommunicate…. you know, just like the internet! But like so many of these things the big companies always attempt to see if they can control the entire market first, then realise they need to “compromise” and work with the other players on standards, which is when the market starts to actually mature and consumers start to win out!

If you look at the project’s web site there’s, at least at the time of writing, 16 company logos on the page, of which around six or seven I would consider household names. A standard such as this was always going to happen. If you look at the “Home IoT Market” it’s a mish-mash of competing and incompatible standards, none of which really have a lead and some of the big names, such as Apple with their HomeKit interface (I refuse to use the term “standard”), have been struggling to get any real level of foot hold in the market. Some of the more popular off the shelf devices have been things like Samsung’s “SmartThings” which implement a number of different radios etc as bridge/gateway devices to make other things work together, which in and of itself speaks volumes. If the companies themselves didn’t get themselves sorted out it would have ended up in governments mandating something. In short the whole category is a big mess!

So reading through the FAQ and various bits in the media about it what does it appear to do? It puts IP over stuff! Shocking right!? To quote the FAQ:

The goal of the first specification release will be Wi-Fi, up to and including 802.11ax (aka Wi-Fi 6), that is 802.11a/b/g/n/ac/ax; Thread over 802.15.4-2006 at 2.4 GHz; and IP implementations for Bluetooth Low Energy, versions 4.1, 4.2, and 5.0 for the network and physical wireless protocols.

So the technologies they’re using are WiFi, no real shock there, although there’s no mention of Wi-Fi HaLow AKA 802.11ah but for home use that’s nothing of note. Next up in Bluetooth LE, 4.1 – 5.0, again no real surprises here, there’s already a standard for IP over Bluetooth LE/mesh in the form of 6LoWPAN, the same as used by Thread and vanilla 802.15.4, slightly interesting they mentioned explicitly 3 versions of BT-LE and just didn’t say BT-LE in general as all versions support IP. The final option mentioned was 802.15.4, the bit that I find particularly interesting here is that Zigbee Alliance was one of the four companies in the original announcement, 802.15.4 is an open radio standard used by Zigbee, Thread, 6LoWPAN directly and a number of other protocols, Zigbee has their own Zigbee IP standard, which competes with Thread and others yet Thread, originally out of Google/Nest is the chosen one. I’ve also found Thread to not really be a completely open standard like TCP/IP, as while there is the OpenThread implementation, you need to be a paying member of the Thread Group organisation to have it certified!

So what else does the project offer? They mention the following but note the term “may include”.:

This may include a proposed standard for lifecycle events such as provisioning/onboarding, removal, error recovery, and software update.

I feel that the lifecycle events they mention are actually extremely important here, and standards in this area are just as important as connectivity standards such as IP for layer 3. If you look at components such as provisioning/onboarding there’s fairly new standards evolving such as the Intel/Arm FIDO secure device onboarding collaboration which are still quite new so I suspect they’re going to wait and watch these before making a decision which is actively a good thing in my opinion if it means one less new standard!

Overall there’s currently nothing actually new on offer here in terms of standards, what is new is a number of large companies committing to focusing on a single Layer 3 connectivity protocol. There’s already widely available hardware across WiFi/Bluetooth/802.15.4 as well as standard IP implementations for them all. This should actively replace Zigbee, Z-Wave and a number of other proprietary Layer 2/3 protocols and should be straight forward for adoption as there’s not actually a lot for anyone else to do.

I feel this is a move in the right direction and will make life easier for a lot of third parties who want their products to work with “the big three of Apple/Google/Amazon”, the move to more open standards is obviously good, but overall there’s really nothing particularly new other than another mechanism for closed companies to work together. I don’t think it’ll ultimately make much difference in general to the open source community as those companies will have their proprietary protocols/APIs sitting on top of IP, just like in other parts of the internet now. It’ll be interesting to see how open the process is once they release code and start to work on it.

Basically it’s a wait and watch so really I’m ¯\_(ツ)_/¯

Securing home networks and IoT for family at holiday time

Many people head home to family at some point over the holiday season, whether that be like today for Thanksgiving in the US, Christian Christmas at the end of December or one of the many and varied holidays. During that time most people that are technical will be asked to help fix or setup various computer or internet related devices that family members that are not so technical have acquired or broken since the last time they ventured home. For me it use to be the regular upgrade/replacement of the Virus Scan and anti malware software. These days it tends to be patching of phones and tablets and all sorts of other devices.

So what can the average technical person do to help minimise risks to family members, or stop them from being part of a large botnet sometime in the future, without making the technology hard or even impossible for family to use, or to minimise the calls throughout the year.

Router

The first port of call should always be the router. Often these just get stuffed in the corner, on a bookshelf or somewhere out of site and forgotten. From a security point of view they are the most important, they are the thing that primarily protects everything else as they’re the ingress/egress point of the network. So what to do and change on these devices:

  • Upgrade the firmware to the latest supported version, and configure it to auto-upgrade if it’s an option. If the last firmware is ancient consider moving to a third party firmware like LEDE Project or an OpenWRT dirivative. Worst case scenario throw it away and give them a new one as their present.
  • Change the admin password.
  • Change the SSID and set a reasonable password.
  • Ensure that the admin interface isn’t available on the WAN link, do a port scan.
  • Turn off port forwarding and UPnP on the router.
  • Switch it to OpenDNS (208.67.222.222 208.67.220.220), Google Public DNS (8.8.8.8 4.4.4.4), the new Quad9, or even better a combination of them so if one service goes down or disappears their internet will still work.

Phones and Tablets

Ensure the phone is set to auto install new OS firmware releases, also ensure that apps are set to auto update and that if the provider, such as Google Play, has a malware scan option in their App store ensure that’s turned on so it’ll clean up any apps that are discovered to be problematic.

TVs, Bluerays and other Media Players

It’s surprising the number of these devices that have network connections and never get updated. In some cases the network functionality is rarely, if ever used, I know I’ve pretty much disconnected all Blu-ray players from networks, turned off the wireless if it has it, and not ever had a complaint. Often it’s better to replace some of old network media devices with ones that are actively maintained such as Google Chromecast, Amazon Fire, Roku etc. It’s also worth checking if any of these devices have the ability to connect to via ad-hoc means and disable that to limit connections to only those that are on the standard home network.

Various IoT devices

IoT devices should generally, if at all possible, be isolated on their own network. This is easy if as part of securing the router you moved it to LEDE or something similar above, and configure it to have a strict deny-by-default policy. Check the existing network for devices that are connected to it. In some cases there may have been a device connected to it some time ago that have long been forgotten about and are no longer in use, or the manufacturer has ceased to exist and they’re just a compromise waiting to happen masquerading as an expensive paperweight. Those that are in use might not be using the IoT/network functionality, if so turn the network off. Those that remain obviously ensure they’re running the latest firmware, set for auto update, and if possible move them to the IoT network. In some cases it might be possible or better to replace connected lighting if it’s some terrible WiFi/Bluetooth globe with something like the IKEA TRÅDFRI system as it has reasonable security, is of good quality and is affordable. Also don’t forget to check for things like doorbells, locks, cameras and other such devices.

Conslusion

Securing the router and associated DNS is by far and large the most important thing to do, it will help mitigate/protect most of the other problems that loom on the inside. But disconnecting, throwing away, replacement of old devices is sometimes the easiest way to fix them too, or else isolating them.

Let me know what else people do, and what I missed.

Configuring HTTP/2 with Apache on Fedora

HTTP/2 is the new version of the well known HTTP protocol which has been at the venerable 1.1 since late last century. Version 2 was derived out of Google’s SPDY protocol and it’s a binary protocol over the text based 1.1. It introduces a bunch of improvements including reducing latency, multiplexing, and server push. There’s some useful improvements that will be great for things like apps that use WebSockets. The Apache httpd daemon has included complete support for HTTP/2 since the 2.4.17 release in the form of mod_http2.

First you should configure your site with SSL, I suggest using LetsEncrypt/certbot as documented in this Fedora Magazine article.

Then you need to make sure the module is loaded, at least in Fedora 25 this is enabled in /etc/httpd/conf.modules.d/00-base.conf by default:

LoadModule http2_module modules/mod_http2.so

Then you just need to enable the protocol in either the general configuration or in specific VirtualHost directives for specific sites:

# for a https server
Protocols h2 http/1.1

# for a http server
Protocols h2c http/1.1

Then it’s just a systemctl restart httpd to make the changes take effect.

To test whether you’re serving over HTTP/2 you can test using this HTTP/2 testing site or with the OpenSSL client (check for “ALPN protocol: h2” in the output) with the following command:

openssl s_client -alpn h2 -connect HOSTNAME:443

Note: HTTP/2 is not currently supported in the httpd shipped in RHEL.

Connect to a wireless network using command line nmcli

I use a lot of minimal installs on various ARM devices. They’re good because they’re quick to download and you can test most of the functionality of the device to ensure it’s working or to quickly test specific functionality but of course it doesn’t have a GUI to use the nice graphical tools which are useful to quickly connect to a wifi network or other things.

This where nmcli comes in handy to quickly do anything you can do with the GUI. To connect to a wireless network I do:

Check you can see the wireless NIC and that the radio is enabled (basically “Airplane” mode):

# nmcli radio
WIFI-HW  WIFI     WWAN-HW  WWAN    
enabled  enabled  enabled  enabled 
# nmcli device
DEVICE  TYPE      STATE         CONNECTION 
wlan0   wifi      disconnected  --         
eth0    ethernet  unavailable   --         
lo      loopback  unmanaged     --

Then to actually connect to a wireless AP:

# nmcli device wifi rescan
# nmcli device wifi list
# nmcli device wifi connect SSID-Name --ask

And that should be enough to get you connected. You can list the connection with nmcli connection and various other options. It’s pretty straight forward.

network bridge for libvirt host with a single live IP

The default network config for libvirt is simple and works for most basic use cases but there’s a number of use cases where you need more complex config like Adam outlined for a local bridged config.

I run a number of VMs on a hosted server on the internet and I’ve had on my ToDo list for some time to add a IPSEC site to site VPN but the default network doesn’t make that easy because libvirtd deals with the iptables networking including the NAT automagically.

The network config looks like this:

                    *-----*
192.168.100.0/24  --| Hyp |-(eth0)- internet
 (br0) VM net       *-----*

Create non routed network bridge
Initially create a basic network bridge and disable STP (spanning tree protocol). Note we don’t bind it with eth0 which is a public internet facing interface.

nmcli con add type bridge ifname br0
nmcli con modify bridge-br0 bridge.stp no

I then edited the /etc/sysconfig/network-scripts/ifcfg-bridge-br0 file and to add IP network config and adjust a few bits to get the following:

DEVICE=br0
STP=no
TYPE=Bridge
BOOTPROTO=static
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPADDR=192.168.100.254
NETMASK=255.255.255.0
IPV6INIT=no
IPV6_FAILURE_FATAL=no
NAME=bridge-br0
UUID=
ONBOOT=yes

Once we’ve done that we can bring the bridge online and check the config looks OK:

ifup br0
nmcli c show
nmcli -f bridge con show bridge-br0
ip addr

Now we have a network bridge with an IP address you can now edit any VM configuration and reassign the virtual NICs to the new bridge and adjust the VM network config to the new subnet and assign static IPs to each VM, or configure dhcpd to assign IPs on the br0 interface. Once that’s done you should be able to ping the gateway (192.168.101.254) and have local network connectivity.

Once you’ve moved everything over you can delete the original libvirtd network config.

Outbound NATed networking
Using the traditional iptables.service (firewalld investigation is on my todo list) you can add a basic outbound NAT configuration which restores the last of the missing functionality with the following basic rule set which will NAT by masquerading the br0 network out through the public IP on eth0:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state NEW -p tcp -m tcp --dport 22 -j ACCEPT
iptables -A INPUT -j REJECT --reject-with icmp-host-prohibited
iptables -A FORWARD -i eth0 -o br0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i br0 -o eth0 -j ACCEPT
iptables -A FORWARD -j REJECT --reject-with icmp-host-prohibited
iptables-save > /etc/sysconfig/iptables
systemctl enable iptables.service
systemctl start iptables.service

With the network now under complete control of NetworkManager and a IP firewall/NAT configuration under control from a single point it now makes it easier to add things like IPSEC connections and IPv6 configuration both of which are next on the list.

Simple WOL with RHEL and Fedora

I have a number of systems I use at home, they run a combination of RHEL and Fedora and are a variety of architectures (well x86 and ARM). Travelling a lot for $dayjob I don’t always want them on needlessly chewing power but on the flip side if I’m away for two weeks and I’d like to remotely use one and it’s off it’s a little tough to power it up if you’re 12 hours travel away!

So the obvious solution to this problem to get the best of both worlds is to use Wake On LAN (WOL) for supported hardware which means I can leave devices off or suspended and then just bring them up to full power when I actually want to use them from where ever I happen to be at the time, whether it be on the couch across the room or the other side of the world.

There’s a few places where you need to configure the device you wish to wake up. If you want to wake from power off you need to configure the BIOS/Firmware to have WOL enabled, this differs from device to device so this bit is an exercise for the reader. The quickest way to determine if your hardware supports WOL and its enabled in the BIOS/Firmware is to check to see if when the device is turned off and cabled up to a switch is if there’s a link light on the NIC is still lit.

Once you’ve got the HW and BIOS/Firmware sorted the next bit is pretty straight forward. First enable WOL on boot for the NIC in /etc/sysconfig/network-scripts/ifcfg- by adding the following line to the end of the file:

ETHTOOL_OPTIONS="wol g"

Then run 

# ethtool -s  wol g

to enable it now. Finally record the ether address from the output from the “ip link” command so you know what MAC address you need to use to wake it up.

On your gateway make sure you have the appropriate tool to initiate the remote wakeup. On Fedora and RHEL this is ether-wake and it’s in the net-tools package. It’s then as simple as running 

# ether-wake -i local-interface mac-address