Suricata IDS/IPS on Ubuntu 20.04

No network security setup would be complete without a network-based Intrusion Detection System and Intrusion Prevention System (IPS/IDS). For many businesses, network-based IDS/IPS is a key component of maintaining a PCI-compliant environment. PCI compliance is mandated for any business that handles credit card-holder data in any way. Other businesses handle such sensitive information that literally every packet needs to be inspected for any kind of malicious activity. Financial institutions, healthcare providers and government bodies usually fall into this category.

Whatever the business need, IDS/IPS (from this point forward, I mean network-based. Host-based is another topic entirely) is yet another necessary security tool for keeping a network environment safe. Today we’ll take a look at suricata, an open-source IDS/IPS system that you can install on Ubuntu 20.04. You can even get free, regularly-updated rule lists for staying up-to-date on the latest threats. Some ruleset providers charge for their lists, but many are provided without charge. Let’s get the basics setup and see how it works!

Topology

Topology in GNS3

We’ll install Suricata on Ubuntu20.04-1, which is acting as a router between the hapless workstation and the Internet. We’ll configure Suricata to listen for threats on the “outside”, or Internet-facing interface, ens3.

Installation

Installation requires setting up the Ubuntu PPA for recent, prebuilt packages. We can add it with this command:

add-apt-repository ppa:oisf/suricata-stable

Then update apt, and install:

apt-get update
apt-get install suricata

Configuration

Now that it’s installed, we need to make a couple of configurations in text files. The first is in /etc/default/suricata, which holds the configuration mode and default interface. You’ll want to change the following lines:

LISTENMODE=nfqueue

IFACE=ens3

LISTENMODE sets whether you want suricata to be in IDS or IPS mode. IDS will passively listen and write an alert to a log file. IPS does that too, but with the option to drop detected threats. In order to perform the drop, packets needs to be sent to the nfqueue processing queue. IFACE is whatever network interface you want suricata to listen on.

Next we need to update our rules with the suricata-update command. You can see what lists are enabled by running suricata-update list-sources, but the default ones will do just fine.

suricata-update

Now we should have a set of rules at /var/lib/suricata/rules/suricata.rules. We’ll use the sed tool to mark some of the rules to drop traffic, with these commands:

sed -i -e '/ATTACK_RESPONSE/ s/^alert/drop/' /var/lib/suricata/rules/suricata.rules 
sed -i -e '/USER_AGENTS/ s/^alert/drop/' /var/lib/suricata/rules/suricata.rules 

Finally, we need to send all packets to the NFQUEUE processing queue so they can be dropped if determined to be malicious. These iptables commands will send all packets to that queue with the exception of port 22, which is usually SSH traffic. That way our SSH session to the server isn’t interrupted:

iptables -I INPUT 1 -p tcp --dport 22 -j NFQUEUE --queue-bypass
iptables -I OUTPUT 1 -p tcp --sport 22 -j NFQUEUE --queue-bypass
iptables -I FORWARD -j NFQUEUE
iptables -I INPUT 2 -j NFQUEUE
iptables -I OUTPUT 2 -j NFQUEUE

And finally reload suricata:

systemctl restart suricata

Verification

Quick note: With the way we set suricata up, you can run these tests either from the Ubuntu server where suricata is installed, or from anything behind it. Either will work. Also please rest assured neither of these tests actually does anything close to malicious.

If we send a normal HTTP request to google.com from the hapless workstation at 192.168.0.2, it should work:

curl http://www.google.com
---
<a bunch of web nonsense output here>

But if we change the HTTP user-agent string to “BlackSun”, suricata will detect this as a malware attack. Apparently BlackSun is some kind of ransomware, but just changing the user-agent string to “BlackSun” isn’t going to do anything at all, other than test whether suricata is working or not. The below command will achieve this goal:

curl -A "BlackSun" http://www.google.com
---
<no response>

Suricata is dropping these packets! Our IPS is working. Let’s check if IDS is working too. Activity is logged at /var/log/suricata/fast.log:

cat /var/log/suricata/fast.log
---
01/20/2022-13:40:00.339281  [Drop] [**] [1:2008983:8] ET USER_AGENTS Suspicious User Agent (BlackSun) [**] [Classification: A Network Trojan was detected] [Priority: 1] {TCP} 192.168.122.142:35444 -> 142.250.207.4:80

Success! We’ve been notified of a network attack. Let’s try another one. The website testmynids.com has a nice test we can run with this command:

curl http://testmynids.org/uid/index.html
---
<no response>

This well send an index.html file containing the output of the id root command, a common way for remote command-and-control servers to execute attacks. Let’s check the log:

cat /var/log/suricata/fast.log
---
01/20/2022-13:44:40.778197  [Drop] [**] [1:2100498:7] GPL ATTACK_RESPONSE id check returned root [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 13.226.78.68:80 -> 192.168.122.142:37444

Success!

Duo Security Lab – Multi-factor Authentication for RDP

Summary of Steps:

  1. Follow the doc for RDP
  2. Install Duo for Windows
  3. Set up user
  4. Set up MFA device (your phone)

It’s actually fairly quick and painless to get set up with Duo MFA for Windows, with the exception that you have to manually add a user and enroll your phone. With SSH on Linux there was some editing of text files, compiling code and command-line stuff, but with Windows it’s lots of clicking of those old familiar friends, “Next”, “Ok”, and “Finish”. Here is my topology:

First, I log into my account dashboard at https://duo.com (for which I’m MFA prompted on my phone, of course) and go to “Applications”. I click “Protect an Application” and click “Microsoft RDP”. Reading the docs at https://duo.com/docs/rdp I download the Duo Windows installer and away I go:

You can find the API hostname, integration key, and secret key by clicking “Protect this Application” for MS-RDP:

Ready to install!

And…. it’s done.

Then we need to manually add a user, as I mentioned. From the Duo dashboard, just click “Add user”. For some reason when I created this VM some time ago I name the user “solarwinds”, I think I was doing some network testing. I regret nothing.

Add my phone:

Send the activation link to you phone, and you can activate Duo Push Mobile app if you have it.

Then log in! I use Remmina on Linux, but of course any RDP client will work.

I’m prompted by Duo and a code is sent to my phone:

And I’m logged in!

There is much rejoicing.

Duo Security Lab – Multi-factor Authentication for SSH

Part of a series of posts related to the cloud security company Duo Security, Inc. I am not affiliated in any way with Duo Security (please read my more extensive disclaimer below), I’m just doing my best to understand their offering.

Following the very clear instructions I found on https://duo.com/docs/duounix, I proceed to Duo my SSH. This is my topology:

I start by getting my Ubuntu 18.04 Server ready. Duo says we’ll be building from source and I need a compiler like GCC so I just installed the build-essential package. I also need libssl-dev and libpam-dev.

sudo apt-get install build-essential libssl-dev libpam-dev

Then I need to get the pam_duo source, untar and compile.

wget https://dl.duosecurity.com/duo_unix-latest.tar.gz
tar zxf duo_unix-latest.tar.gz
cd duo_unix-1.11.2
./configure --with-pam --prefix=/usr && make && sudo make install

The make program then spits out a bunch of gibberish that I will never understand, but I know it compiled ok because it didn’t say “error” a bunch of times. I’m very precise like that.

Next up I copy the keys and API hostname (the magic link to my Duo account) found when I click “Protect this application” on my Duo account under “applications”:

Then I put them in /etc/duo/pam_duo.conf file. It should look like this, according to the Duo documentation:

[duo]
; Duo integration key
ikey = DIGHFMF9NB25BEQJGHQZ
; Duo secret key
skey = NOTGONNATELLU
; Duo API hostname
host = api-b19c01d1.duosecurity.com

Then edit the pam sshd configuration file /etc/pam.d/sshd, find this line and comment it:

@include common-auth

Then add three lines so it looks like this:

auth  [success=1 default=ignore] /lib64/security/pam_duo.so
auth  requisite pam_deny.so
auth  required pam_permit.so

Lastly, restart the sshd daemon to apply the changes to sshd and duo.

sudo systemctl restart sshd

Once I get that all in place, I try SSHing (is that a word?) from the client to the server:

james@client:~$ ssh james@142.69.3.42
Please enroll at https://api-b19c01d1.duosecurity.com/portal?code=ca487343d044ab35&akey=DAVEM6A3YS7ML96IE4BJ
james@142.69.3.42's password:

I need to enroll my MFA device (my android phone) at https://api-b19c01d1.duosecurity.com/portal?code=ca487343d044ab35&akey=DAVEM6A3YS7ML96IE4BJ, so I head on over there and follow the prompts:

Then I try again SSHing from the client to the server. This time I get an MFA prompt on the command line:

james@client:~$ ssh james@142.69.3.42
Duo two-factor login for james

Enter a passcode or select one of the following options:

 1. Duo Push to XXX-XXX-7273
 2. Phone call to XXX-XXX-7273
 3. SMS passcodes to XXX-XXX-7273

Passcode or option (1-3): 1

Entering option 1 gets me a prompt from my Duo Push app on my phone to accept or deny the request (the app restricts taking a screenshot so I couldn’t include it, sorry), options 2 and 3 are pretty much what they look like.

Success. Logging you in...
Welcome to Ubuntu 18.04.2 LTS (GNU/Linux 4.15.0-20-generic x86_64)
Last login: Mon Jun 24 20:35:10 2019
james@server:~$

There is much rejoicing.

Non-Affiliation Disclaimer:
I am not affiliated, associated, authorized, endorsed by, or in any way officially connected with Duo Security, or any of its subsidiaries or its affiliates. The official Duo Security website can be found at https://duo.com. The name Duo Security as well as related names, marks, emblems and images are registered trademarks of its owners.

Duo Security – Overview and Target Market

Part of a series of posts related to the cloud security company Duo Security, Inc. I am not affiliated in any way with Duo Security (please read my more extensive disclaimer below), I’m just doing my best to understand their offering.

History and Products

Duo Security is a cyber-security company based out of Ann Arbor, Michigan, founded in 2009 by Dug Song and Jon Oberheide. In August of 2018 they were acquired by Cisco Systems. Duo’s LinkedIn profile makes a pretty clear and concise statement that they’re going to “democratize security” and that their mission is to “protect the mission of our customers by making security simple for everyone.”

Unaltered screenshot of Duo’s Product page as of 04/29/2019

Duo’s product page makes some pretty big claims about what they can do. Their product lineup targets securing apps and data, but what stood out to me is that they say it works from any location using any device for organizations of all sizes. Duo offers a platform called “Trusted Access” that has multiple parts:

  • Multi-Factor Authentication
  • Endpoint Visibility
  • Adaptive Authentication & Policy Enforcement
  • Remote Access & Single Sign-On

I’ll take a good look at what these actually mean for their customers later, but for now it’s clear they aim to secure and authenticate their customers’ systems.

Duo’s Customers – IT Departments Big and Small

It’s also fairly clear you probably wouldn’t deploy the Trusted Access platform’s features on your home WiFi network to enable trusted secure access to your Google Chromecast, as they target enterprises. They have a really nice use cases section on their homepage that shows some of the different verticals they’re after including:

  • Education
  • Federal
  • Healthcare
  • Legal
  • Retail
  • Technology
  • Finance

I took a look at one use case in particular for their customer Etsy, an online retailer of handmade or “vintage” items.

Authentication: not as easy as it looks. Photo by Jason Blackeye on Unsplash

According to the case study, Etsy’s business problem centered around securing administrators’ access to the internal management systems of their site. They use a number of access tools including SSH and internally developed systems.

Etsy cited “single-factor” authentication as a security problem for their organization, a.k.a. authentication with only a username and associated password between the outside world and access to said management systems. Duo quotes Etsy’s Network Security Manager describing Single-Factor Authentication as a “weak-link” to illustrate this issue.

Etsy used Duo’s Multi-Factor Authentication feature to add another factor to the authentication process for administrators accessing internal management systems of the site. There are multiple options for adding a second factor to the authentication process (which I’ll explore later), but Etsy says they used the Duo Mobile app. The app enables “pushing”, or the sending of an authentication request (after entering the correct password) from Duo’s Trusted Access platform to the app on the administrator’s phone. The administrator approves access from her phone, and is allowed in to the internal management system.

Next I’ll take a closer look at the different features the Trusted Access platform offers.

Non-Affiliation Disclaimer:
I am not affiliated, associated, authorized, endorsed by, or in any way officially connected with Duo Security, or any of its subsidiaries or its affiliates. The official Duo Security website can be found at https://duo.com. The name Duo Security as well as related names, marks, emblems and images are registered trademarks of its owners.