Clearhat

That headline is a mouthful, so let's break it down:

• How to configure Ubuntu
• via /etc/network/interfaces
• using ifupdown
• managed by Network Manager
• for Security Onion

In more simple terms I would prefer this headline: "How to configure Ubuntu with ifupdown for Security Onion," but it turns out Security Onion requires Network Manager (which thankfully is not entangled with systemd in the way that netplan and networkd are), and so... I've found a way to eliminate netplan and networkd, leaving network-manager and ifupdown like the good ol days.

From what I can tell by fairly aggressive searching on this topic over weeks, this challenge (Security Onion+/etc/network/interfaces) is getting increasingly difficult to do over time, as "the octopus" of systemd exerts its World Domination Plan upon us, creeping, as it does, in its petty pace, day by day. So here's the latest iteration of the journey.

I've installed many variations of this little stack (detailed after my rant; the astute reader will skip down immediately) easily two dozen times, searching for the combo that works, and I've found one. It's not yet perfect, but it works every time now, and I'm ready for the next stage (network taps) so I'm writing about this stage here. If I knew more about networking, I think this would have gone quicker. The upside of all this is: now I know more about networking.

My goal is to try and get Security Onion working on Debian (yeah yeah unsupported, but theoretically a much more stable approach than either of its current defaults: slippery Ubuntu¹ or yummmy CentOS), which is a step toward an even more obscure goal recognizable only by Old World Unix Admins. To those admins: I'm aiming at the original ideal of stability and security promised by the Debian project long ago, when it first began. Yes, I'm old enough to remember when Debian began, and why it began, and what was happening in the Free Software... er, Open Source community... as it came into being. Even then I was already a long-time fan of Richard Stallman's groundbreaking efforts in liberating software from the proprietary moguls. So I remember hearing Bruce Perens mention Wikipedia during his radio interview, to which I eagerly tuned in because I was a fan of his for his work with Debian by then. (Remember how Wikipedia exploded into our awareness soon after? In my mind, it was because a lot of people started following the influencers who heard that episode.) So yes, I know the link between Bruce Perens and Debian, and I think his manifesto was right up there with Thomas Jefferson's. And lastly, since you're still listening, I know what ^H^H^H^H means because I encountered it personally on a green screen VT100 terminal back in the 80s. Um, okay, so I'll continue with the relevant part of the rant:

1. slippery, yes -- with a name like Canonical, you'd think they'd be, you know, canonical. But I guess they mean a moveable cannon, not the immoveable canon meant by old Unix Admins when they use words like canonical.

Don't get me wrong, I like Ubuntu. But I like Debian more, and for all the right reasons. I've watched Debian's progress all along. Watched it become the foundation upon which others are built, and watched many attempts to erode that foundation, which for the most part have been ably avoided by sticking to their first principles. This may seem paradoxical, but I watched Debian's progress from within the Windows world; as a budding software engineer in the early 2000s (a techie much earlier, but a pro by then), I fell in love with Visual Studio early enough to find Eclipse and Java both tediously pedantic and abstruse, compared to the elegance and ease combined with immense power of .NET in Visual Studio. Likewise, from my Windows window, I laughed heartily at the "deweirdifier" plugin for Linux GIMP, which made it behave more like Windows PhotoShop -- still one of the most elegant, intuitively-designed pieces of software I've ever had the enjoyment to operate. I laughed then because I knew Eclipse needed a deweirdifier plugin, to make it behave more like Visual Studio (attempts were made). It was not funny however, that Linux could never get its drivers right until System76 came out with PopOS and everything just works like it was supposed to all along. (Now I have a distro I can give to grandma, which I recently did.) So there I was, in love with Linux but needing to make a living. And thanks to the awesomeness of the Studio, I spent two decades firmly embedded in the Windows world, always tinkering on the side with Debian -- and other flavors, but always returning to Debian -- because it was so reliably pure in ideal and in practice. I knew it was awesome long before Canonical decided it was awesome, and the many others who have followed suit because it remains awesome (as I hope it always does, standing firmly even with subtle attacks like this one, God forbid!). Imagine how happy I was to discover Windows had finally embedded Linux inside of itself as a first-class citizen a few years ago (albeit, 3rd-class on the visual layer). Knowing Debian was awesome, I used the new Windows Subsystem for Linux to install it inside Windows at the first opportunity. And that's probably the beginning of the end for my Windows career. They intended for me to receive a more subtle 2nd Generation of Embrace, Extend, and Extinguish, but the opposite happened. I jumped ship. I got better at the command line, and then... I left my cozy Windows home of 3 decades. Mind you, I was using 1.0, believe it or not, before it was even a separate OS yet, when the amazing desktop layout program that ran on it was written in BASIC. I left and I'm not going back. In the past couple years I finally got so weary of the ever-creeping bloat and Manifest-Destinyware² of Windows that I finally abandoned hope of getting a functional workday out of it. It reminds me of my own ego -- beautiful in theory, but hopelessly, fundamentally flawed in reality. Too many restarts in the middle of the night which changed essential elements of my workstation without permission and without an easy fix. And why does it need to restart itself so often, it's 2021 for Pete's sake? Too many hours spent searching for things that used to be easily available. Too many hours finding dead ends in forums because Microsoft doesn't care about certain important things. Too much disgust at the new interface which is not designed "to be easy" but -- to those who knew what you used to be able to do -- to make people stupid and keep them there. Too many alerts-I-can't-disable-without-powershell alerting me that some cool tool I installed was a security risk, when in fact it was a workaround for Windows ego problems. And of course, tooooooooo much telemetry: finding and stopping each one of those holes into my private world was getting overwhelming.

2. "there can be only one!"-ware

So finally, like all other Genuine Bona Fide Old School Unix Admins did years before, I jumped in to the Open Source world with both feet, no looking back. And for the past couple years, it's been Linux everywhere for me. These days, I only use Windows in a virtual machine for rare access to obscure things like Paint.Net (Pinta is not quite there yet), EditPlus, and obscure drivers made in China for a 3-way (rewind, play, fast-forward) footpedal used to navigate audio recordings -- oh, and a pane of glass with various other Microsoft products needed to keep up with my coworkers, who still live in the Windows world. These days, to say "thanks for all the fish" to Microsoft, I even have a legitimate license for Windows that I paid for myself. But it runs in an easily-ignored self-updating virtual machine, and stays out of my way for the important stuff. So at this point I'm trying to sidestep the anti-Unix-first-principles conflagration of bloatware known as systemd, otherwise known as The Octopus, a not-subtle reference to the cancer growing inside of Unix so pervasively that even Debian, usually so noble and principled and above the fray, succumbed to the enchantment. I'm waiting for Debian to backtrack and eventually remove systemd, but until that happens, I have spent a couple hundred hours trying to get various packages working on various versions of Debian minus systemd, enough to know that getting Security Onion working without systemd is out of scope for me. The tentacles of systemd are nasty and fierce, two grow wherever you kill one. (Remove a systemd network stack and now your boots go verrrry veryyyy slow and nobody seems to know how to fix it, etc.) But getting Security Onion working on Debian... that may be in scope, and if I do it well, maybe the upstream might consider the idea... So I've spent a few dozen hours attempting to get there, and this is what I have so far, a blog post on the subject: "Security Onion running on Ubuntu with ifupdown." In closing my rant, I suspect a large part of my impetus on this noble journey, aside from the ideals noted above, is the practical fact that most of the information on the Internet for getting network bridges working for Security Onion mostly refers to /etc/network/interfaces configuration. Well THAT doesn't work out of the box now like it did two years ago, even in Ubuntu 18.04 (how do you make large changes to a network stack in a minor version release?), so I started down this path innocently trying to get a few online tutorials working. Of course the tutorials didn't work, because netplan has completely replaced ifupdown, not just side-by-side like it was in the beginning, but replaced. It's gone! The systemd tentacles quickly eliminated the ability to sidestep netplan by using kernel install flags (an early fix which no longer works). I didn't know that, so I dove in initially thinking it would be easy, as if kernel install flags are easy. (New skill: how to install Linux with no install media whatsoever. Wheee!) Now, weeks later, I know it's not easy, but I came back out of the rabbit hole with my own online tutorial which makes those 2-year-old network bridge tutorials viable again. At this point now I'm two weeks behind on my larger project, and still have to get taps working, but here's the latest bit of guerilla warfare against the redcoats^H^H^H^H^H^H^H^Hsystemd:

Security Onion running on Ubuntu with ifupdown in 2021

Security Onion currently requires Ubuntu 18.04. I did the following with a vanilla install of 18.04.05 Server. I've tried dozens of variations of these steps, and this is the flow that works reliably. Let's identify a few prerequisites before we get into the config:

1. I strongly recommend doing this in a Virtual Machine instead of using bare metal, even though Security Onion kind of expects you to be using bare metal. Why? Because you're going outside-the-box for a reason, or you wouldn't be reading these instructions. That means you're going to make mistakes, and you will need to start all over again eventually, even if these instructions work for you the first time. Snapshotting a "good state" within a Virtual Machine is trivial. Making those mistakes with bare metal is... a lot harder because you really do need to start over at the beginning. How many times have I destroyed my network stack _before_ downloading the tools I need to fix it? Too many. I use Proxmox to manage virtual machines, but you can use ESXI or VirtualBox or any other VM layer to do these steps.
2. Use a minimum 250Gb drive. I know Security Onion says you need minimum 200Gb, but I ran into issues with that, and reliably got past them only by starting with 250Gb. (I tried 215Gb, etc. 250 works. Yes, you can get a 99Gb version working for so-analyst, yes the ISO install will work on 200Gb), but for Ubuntu and the Standalone version I'm using, 250Gb works as advertised. 
3. During the Ubuntu installation, custom partition your drive like Security Onion describes in the Partitioning section of documentation. I configured "/nsm" to 135Gb, "/" to 120Gb, and the remaining Gb were used for swap, /tmp, and a half-gig /boot. That's minimal. For example, the Security Onion documentation describes a 1Tb disk, but since that's my whole Proxmox machine, I opted for 250Gb.
4. Likewise, I used the minimal 12Gb recommended for memory, etc, as described in Security Onion documentation. I may expand these numbers later as I get used to working with the product more, but this is a workable baseline for now. It's up and running and alerts are in realtime. Yay.
5. Assign your network cards -- using their MAC Address -- statically with your DHCP endpoint (usually your router/gateway, but sometimes your firewall). THIS IS IMPORTANT. Do not let DHCP assign a "random" IP Address to Security Onion even if you do this with all other devices. It must be the same IP Address every time you boot, or Security Onion will cry, and I would too if I were doing all they're doing with IP Addresses. So, go to your router/DHCP endpoint(s) and give the network card(s) a static IP Address BEFORE you install any software.
6. You can do this with 2 network cards, and probably should. I'm using 3 -- one management interface, and two sniffing interfaces, one each for the two legs of my internal network (aka internal WAN and even-more-internal LAN). After install I discovered Security Onion will default to sniffing on your management interface, so you can skip the extra NIC if you want, but I'm keeping it for now. So you'll see 3 interfaces defined below, 1 bridged to vmbr0 and 2 more to vmbr1. The 2nd bridge on vmbr1 doesn't even have an IP Address -- it's just for sniffing -- you can skip it along with the third interface. (The subtleties of sniffing taps on bridges are out of scope for these instructions, I'll cover that in a future post... after I get that part working smoothly.)
7. Make things easier on yourself during installation: enable only the management's network interface. (For example, in Proxmox, click "Disconnect" to disable while adding a new network card, so that network interface is DOWN during installation.) The network-auto-detect scripts of Ubuntu and Security Onion will thank you for making only one interface available during installation (Security Onion will see all, but will default properly to the UP management interface, and ask you to identify the DOWN network card(s) as sniffing endpoints, which is what you want.) After install, you can UP/connect/enable the cards. Note, alas, the boot (and shutdown) process will pause for a long time (minutes!) trying to figure out what you're doing with those DOWN network cards. This is why we're using ifupdown2 instead of ifupdown, by the way: ifupdown2 handles boot/shutdown much better than its mother, ifupdown. So, until ifupdown2 is working, expect long waits. If this works for you the first time, you will only have one of those.

Okay, so here's an abbreviated version of what you need to do:

1. I do this step first for any new image in Proxmox. If you're using some other kind of Virtual Machine, install the guest agent that is appropriate for yours. If you're installing on bare metal, you can ignore this line. You need a guest agent so it's easy to start/stop your machine, as well as see stats, etc.

sudo apt install qemu-guest-agent

2. You may like cloud-init, if so, keep it. I remove mine because it interferes with network settings and I'm not even using it, which is not The Linux Way.

sudo dpkg-reconfigure cloud-init
#uncheck everything except "None"
sudo apt remove --purge cloud-init
sudo rm -rf /etc/cloud/ && sudo rm -rf /var/lib/cloud/

3. Now install ifupdown and Network Manager. Note the wisdom here: install _before_ you break the network, not after.

sudo apt -y install ifupdown2 network-manager

4. Now configure ifupdown:

sudo nano /etc/network/interfaces

Here is what I used. Note that "allow-hotplug" instead of "auto" fixes the boot time issue mentioned earlier -- but doesn't solve the shutdown time issue. Your network cards may have different names; use "ip a" to find out what they're called, use those names instead of "ens#" as I show below. And the optional card here, ens20, is the one marked "manual" because it's just a sniffing interface, doesn't even have an IP address.

auto lo
iface lo
inet loopback allow-hotplug
ens18 iface
ens18 inet dhcp allow-hotplug
ens19 iface
ens19 inet dhcp allow-hotplug
ens20 iface
ens20 inet manual allow-hotplug
vmbr0 iface
vmbr0 inet manual bridge-ports
ens18 bridge-stp off bridge-fd 0 allow-hotplug
vmbr1 iface
vmbr1 inet manual bridge-ports
ens19 bridge-stp off bridge-fd 0

You'll need to tweak Network Manager to play nicely with ifupdown:

sudo touch /etc/NetworkManager/conf.d/10-globally-managed-devices.conf
sudo systemctl disable NetworkManager-wait-online.service
sudo nano /etc/NetworkManager/NetworkManager.conf managed=true
sudo nano /etc/NetworkManager/conf.d/90-dns-none.conf
[main] dns=none

Managed is originally "false" in the NetworkManager.conf, just set it true. The second .conf you'll be creating from scratch, but it only has those two lines. Now get rid of netplan:

sudo apt -y purge netplan.io
sudo rm -rf /etc/netplan

...and systemd-network:

sudo systemctl stop systemd-networkd.socket systemd-networkd networkd-dispatcher systemd-networkd-wait-online systemd-resolved.service
sudo systemctl disable systemd-networkd.socket systemd-networkd networkd-dispatcher systemd-networkd-wait-online systemd-resolved.service
sudo systemctl mask systemd-networkd.socket systemd-networkd networkd-dispatcher systemd-networkd-wait-online systemd-resolved.service

Now get rid of an unused hook and delete the symlink for resolv.conf.

Then recreate the resolv.conf file from scratch, with a single line pointing toward your internal DHCP/DNS provider. Mine is at 10.0.0.1, yours may be something like 192.168.1.1, or whatever.

sudo rm /etc/dhcp/dhclient-enter-hooks.d/resolved
sudo rm /etc/resolv.conf
sudo nano /etc/resolv.conf
nameserver 10.0.0.1

Okay all done. Tidy up:

sudo apt autoremove

and restart networking:

sudo service network-manager restart
sudo service networking restart

You should now be ready to install Security Onion. Snapshot this once it's working, and have at it.