Renaming interfaces in Ubuntu 16.04

If you have built any recent Linux servers (particularly Ubuntu) you may have noticed a drastic change in default interface names. This spurred me to want to organize my interfaces better and more clearly. This post will describe how to rename your interfaces, but more importantly why you should! Along the way I will describe how to build a network bridge inside of the Security Onion using IPTables.

TL;DR

First, let me give you the steps to editing interface names (in case that is all you are here for). Create (or edit) /etc/udev/rules.d/70-persistent-net.rules with a line for each interface in the following format

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="aa:bb:cc:dd:ee:ff", ATTR{dev_id}=="0x0", ATTR{type}=="1", NAME="new0"

This will have the effect of assigning the name new0 to the interface that has the MAC address aa:bb:cc:dd:ee:ff on startup.

Background

When you initially startup a Ubuntu server (or VM instance) you should take note of the assigned names and MAC addresses of all NIC cards. On most machines this will be around one to three physical NICs  (Ethernet and wireless) and one or more virtual NICs (the Local Loopback plus whatever the system has configured). However, that isn't always the case. Especially when talking about enterprise hardware. I recently built a server to support the Security Onion platform built on top of Ubuntu 16.04. It has 7 physical interfaces (1 Onboard Ethernet NIC + 4 Port PCIe Ethernet NIC + 2 External Wireless NICs). Trying to remember which interface was being assigned to which functionality was becoming hard given the default names. Take as an example the IPTables routing rule:

iptables -A FORWARD -p tcp --syn -m physdev --physdev-in enp0s16 --physdev-out enp0s10 -j LOG

Given those interface names, can you describe what this traffic might represent? In my case enp0s16 matched the onboard NIC (being used as the isolated management interface) and enp0s10 was a member of a network bridge (described below). What I did to simplify this was rename each interface based on it's function and location within the network. When I was done, I had the interfaces:

• man0 - Isolated management interface (Ethernet) must be used when interacting with the SO server.
• vpn0 - Ethernet interface reroutes accepted packets to and from the OpenVPN server (a later post, perhaps).
• cap0 - This is one of the Ethernet capture interfaces. Fed data from a managed switch.
• ofc0 - Ethernet link to a small office subnet 0.
• ofc1 - Ethernet link to a different small office subnet 1.
• wcap0 - Wireless NIC in promiscuous mode. Sniffs Even channels
• wcap1 - Wireless NIC in promiscuous mode. Sniffs Odd channels

I suggest following the loose convention for interface names of: <identifier><number>. However, you can choose anything you like. Now, we can rewrite the previous rule in a way that makes more sense "TCP syn traffic originating from the management interface and destined for the office subnet 0 should be logged"

iptables -A FORWARD -p tcp --syn -m physdev --physdev-in man0 --physdev-out ofc0 -j LOG

Setting up the bridge

Setting up a network bridge is pretty straightforward now that we have sanely named interfaces to work with. First we create a new bridge, and then continue with adding as many interfaces to it as needed. In this example I will only add one for the office subnet 0 but you can more by issuing a brctl addif <bridge> <interface> command for each.

brctl addbr br0
brctl addif br0 man0
brctl addif br0 ofc0
ifconfig br0 netmask 255.255.255.0 192.168.32.1 up

This defines a new virtual bridge interface between man0 and ofc0 with a /24 net mask in the 192.168.32.X range. You should change this to a subnet which is not likely to clash with any other subnets the two systems may also be members of.

Say that people from the Office subnet 0 are allowed to use full Internet (so no filtering there), but can only do ssh (port 22) and https (port 443) into the management network. They are not allowed to use IRC (port 6667) anywhere. Of course, users are not meant to notice these restrictions, therefore we build the bridge and filter traffic there. This is a snippet of the rules to achieve this:

# log everything which comes in from the Office. remember, we're paranoid :)
iptables -A INPUT -p udp -m physdev --physdev-in ofc0 -j LOG
iptables -A INPUT -p tcp -m physdev --physdev-in ofc0 -j LOG
iptables -A INPUT -p icmp -m physdev --physdev-in ofc0 -j LOG

# allow ssh and https on the management interface
iptables -A INPUT -p tcp --dport 22 -m physdev --physdev-in ofc0 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -m physdev --physdev-in ofc0 -j ACCEPT

# reject all other connections to the router from the office subnet 0
iptables -A INPUT -p tcp --syn -m physdev --physdev-in ofc0 -J REJECT

# allow the same on the FORWARD chain
iptables -A FORWARD -p tcp --dport 22 -m physdev --physdev-in ofc0 --physdev-out man0 -j ACCEPT
iptables -A FORWARD -p tcp --dport 443 -m physdev --physdev-in ofc0 --physdev-out man0 -j ACCEPT

# reject irc to anywhere, from the office subnet 0
iptables -A FORWARD -p tcp --dport 6667 -m physdev --physdev-in ofc0 -j REJECT

# reject all other connections to the management interface
iptables -A FORWARD -p tcp --syn -m physdev --physdev-in ofc0 --physdev-out man0 -j REJECT

Conclusion

I hope you'll agree that this set of rules is much easier to read and comprehend with the interface names chosen to reflect their position and function within the network. This is just one example of where this change can be helpful. Suppose you have some old programs that use hard coded interface names. Rather than refactoring you could simply rename an interface as expected. Not to mention how much easier it was to diagram the connections. Ultimately, adding a few udev rules to make your interfaces conform to your needs is to easy and beneficial to leave it off your system administration to-do list.