Last Updated:

PSAD on Ubuntu 18.04LTS or 20.04LTS - IDS, made quick (sorta) and easy...

operationroot IDS

For introduction from the Cipherdyne Website:

"psad is a collection of three lightweight system daemons (two main daemons and one helper daemon) that run on Linux machines and analyze iptables log messages to detect port scans and other suspicious traffic. A typical deployment is to run psad on the iptables firewall where it has the fastest access to log data."

Usual disclaimer applies. Use everything in this guide at your own risk.

This is a quick guide to get you up and running with psad on Ubuntu 18.04, Ubuntu 20.04, or similar Debian based systems. Psad requires a couple more steps than just installing the package with APT. So let's dive right into protecting the beaver or fossa...

sudo apt-get install psad

sudo vi /etc/psad/psad.conf

Here you might want to adjust a few things in the config file. My suggestions are just that, but they strike me as reasonably sane defaults. For an explanation of what these settings mean see the documentation in the file itself. This guide is adapted from this source. Below parameters that I tend to modify.

  • EMAIL_ADDRESSES - change this to your email for receiving reports
  • HOSTNAME - will help you identify from which machines reports are being emailed
  • IPT_SYSLOG_FILE /var/log/psad-iptables.log;
  • EXPECT_TCP_OPTIONS Y;
  • EMAIL_ALERT_DANGER_LEVEL 4; - or "5" can be both ok depending on your preferences
  • ENABLE_EMAIL_LIMIT_PER_DST Y;
  • EMAIL_LIMIT_STATUS_MSG Y;
  • EMAIL_THROTTLE 3;
  • ALERT_ALL N;
  • IMPORT_OLD_SCANS Y;
  • ENABLE_AUTO_IDS Y; - most important setting out of all IMHO
  • AUTO_IDS_DANGER_LEVEL 4;
  • AUTO_BLOCK_TIMEOUT 28800;
  • ENABLE_AUTO_IDS_EMAILS Y;

In case your system doesn't have UFW installed to manage the IP tables configs, take care of that now.

sudo apt-get install ufw

Next adjust the logging behavior for IPv4 and IPv6 IP Tables. Place the following rules towards the end of the *filter section but before/above the COMMIT for the section. Make sure it doesn't end up in your NAT tables.

sudo vi /etc/ufw/before.rules

# custom logging directives for psad-A INPUT -j LOG --log-tcp-options --log-prefix "[IPTABLES] "-A FORWARD -j LOG --log-tcp-options --log-prefix "[IPTABLES] "

sudo vi /etc/ufw/before6.rules

# custom logging directives for psad-A INPUT -j LOG --log-tcp-options --log-prefix "[IPTABLES] "-A FORWARD -j LOG --log-tcp-options --log-prefix "[IPTABLES] "

The optional parameter --log-tcp-options adds additional information to the IP tables log files which psad can use to detect certain scan/attack signatures.

We are using the [IPTABLES] prefix here to label and then redirect psad relevant logging so that it does not "gunk up" the syslog file, in case you still enjoy human readable logs.

sudo vi /etc/rsyslog.d/10-iptables.conf

# log kernel generated IPTABLES log messages to file# each log line will be prefixed by "[IPTABLES]", search for that:msg,contains,"[IPTABLES]" /var/log/psad-iptables.log# the following stops logging anything that matches the last rule.# this will stop logging kernel generated IPTABLES log messages to the file# that normally contains kern.* messages (e.g. /var/log/kern.log)# older versions of Ubuntu may require you to change stop to ~& stop

sudo touch /var/log/psad-iptables.logsudo chown syslog:adm /var/log/psad-iptables.logsudo chmod 0640 /var/log/psad-iptables.log

Now it is true "sudo ufw logging on" by default would create much the same output as our additions to the "before.rules" files, minus the TCP options. However, in some versions of Ubuntu, and I found this to be the case with 18.04 server, psad will complain about a missing logging rules on the firewall. There might well be something I am missing, but I did forgo a deep dive into UFW in favor of the above solution which works reliably. Also without the right text wrangling ufw logging will "gunk up" your syslog file but also write the log to the /var/log/ufw.log and /var/log/kern.log files. Which seems just rather wasteful.

sudo service rsyslog restartsudo ufw disablesudo ufw enable

Now have a look at "/var/log/psad-iptables.log" and watch it grow as IP tables starts filling it with log messages. Next quickly check whether psad is happy with your config... i.e. you didn't forget anything mentioned in this guide so far or made a typo.

sudo psad --fw-analyze

[+] Parsing INPUT chain rules.
[+] Parsing INPUT chain rules.
[+] Parsing FORWARD chain rules.
[+] Firewall config looks good.
[+] Completed check of firewall ruleset.
[+] Results in /var/log/psad/fw_check
[+] Exiting.

So, you might be inclined to close your browser tab at this point and call it a day. But you'd live to regret it. Psad needs some more attention before it can run reliably in the background without slowly depleting your storage subsystem of resource and bringing your machine to its knees eventually.

First, let's ensure "/var/log/psad-iptables.log" gets rotated properly.

sudo vi /etc/logrotate.d/psad-iptables

/var/log/psad-iptables.log{rotate 5weeklymissingoknotifemptycreate 0640 syslog admdelaycompresscompresspostrotate/usr/lib/rsyslog/rsyslog-rotateendscript}

Choose the same owner and group as used by your syslog file. For an explanation of the other parameters look at "man logrotate", or check out this article for a quick intro.

Next let's update psad's thread definitions:

psad -Rpsad --sig-updatepsad -Hpsad --Status

And then automate the process by adding this to root's crontab. If you are a masochist you can of course go systemd native for the job as well.

crontab -e@weekly /usr/sbin/psad --sig-update && /usr/sbin/psad -H | mail -s "psad signatures updated on " change@me.domain

The mail subject text in quotes and notification email address are optional of course.

As psad goes about its business it will create a new directory under "/var/log/psad/" for each host it identifies as a potential threat. Inside it will store several files including a copy of the associated threat message. Depending on how actively your system is scanned, you will end up with 100,000s of such directories and millions of files. So you may want to eventually automatically delete old ones and only keep the most recent 50,000 host directories for example. I find that most hosts scanning you will either show up regularly or stop their activity after a few days permanently. So pruning the directory count seems quite acceptable to me, but how you handle this will ultimately depend on your organization's policies. Below a small script to automate the process.

With the IMPORT_OLD_SCANS Y; option set above psad will import the available old scans and use them as part of its traffic assessment.

sudo vi /usr/local/sbin/inodecleaner.sh

#!/bin/bash#IMPORTANT – assumes this is where your psad logs are stored, otherwise you could nuke the systemcd /var/log/psadINODECOUNT=$(ls -1 | wc -l)echo $INODECOUNTif [ $INODECOUNT -gt 55000 ]thencd /var/log/psadfor i in {1..5000}; dorm -rf "$(ls -t | tail -1)"donefi

sudo chmod +x /usr/local/sbin/inodecleaner.shsudo chmod go-rwx /usr/local/sbin/inodecleaner.sh

You could also adapt the above script to just move old file to an archive destination or process them in other ways of course. Anyway, now let's add it to root's crontab. The psad relevant entries should now look like this.

crontab -e@weekly /usr/sbin/psad --sig-update && /usr/sbin/psad -H | mail -s "psad signatures updated on " change@me.domain@weekly /usr/local/sbin/inodecleaner.sh

There may be systems that you want to exclude from psad's wrath. Or other machines, or entire subnets you may want to designate as nefarious. You can do this by adding them to the auto "/etc/psad/auto_dl" file. The "how" is fairly self explanatory since the file is well documented with examples inside.

Lastly, should you want to remove a specific IP from the block list use the following command.

 psad --fw-rm-block-ip

And there you have it, you've made your world a little safer maybe. Good luck!

Authors

Tags