Comprehensive Guide to PSAD Configuration for Network Intrusion Detection on Ubuntu

Introduction

Network intrusion detection applications can monitor suspicious traffic and test network interfaces for security vulnerabilities. In this article, we will perform a psad configuration to monitor our firewall logs and determine if there are any issues.

Intrusion detection systems are used to log suspicious connections and report on anomalous activities. Some programs are purely for system alerts, while others can actively attempt to block traffic that seems intent on causing harm. The psad tool can perform port scan attack detection, and psad is software that actively monitors firewall logs to determine if scanning or attack events are underway. It can alert administrators or take active measures to block threats.

In this article, we will explore how to install and configure psad on a server running Ubuntu. If you do not have a server, I recommend using the free developer-exclusive online lab platform provided by Tencent Cloud for experimentation.

Installing psad

The psad intrusion detection system is available in Ubuntu’s default repositories, so it can be easily installed via apt:

sudo apt-get updatesudo apt-get install psad

To send alerts to the administrator via email, the system will prompt you to configure the postfix mail server.

You can select “Internet Site” and then enter the domain name associated with your server. This is used in the domain part of the “From” field of the emails generated by psad.

Configuring IPTables Rules

The method psad uses to detect activity on server ports is by watching logs generated by the firewall. By default, Ubuntu uses the iptables firewall.

While you can simply enable logging by entering the following commands, I need a more comprehensive configuration:

sudo iptables -A INPUT -j LOGsudo iptables -A FORWARD -j LOG

If you have entered the above rules, flush the rules before configuring them so that we can start anew.

sudo iptables -F

You can enter the following to view the current rules (which at this point should only include default policies):

Code language: txt复制

sudo iptables -S

-P INPUT ACCEPT-P FORWARD ACCEPT-P OUTPUT ACCEPT

Now we can begin appending our rules, primarily the inbound ones. Instruct iptables to drop connections we do not need. It is necessary to add authorized connections that we permit.

The first rule will allow all traffic generated by our server. This type of connection is typically used for services to communicate and relay information easily with one another:

sudo iptables -A INPUT -i lo -j ACCEPT

Next, we want to add rules to allow all traffic associated with existing connections. This will allow our current sessions to continue uninterrupted monitoring:

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Next, we can add the services that we wish to open to the public. For SSH, we can add a line as follows:

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

If we are running a web server on the default port 80, we can add a rule like this:

sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT

You can use the same syntax to add any other ports for services:

sudo iptables -A INPUT -p protocol --dport port_num -j ACCEPT

After adding the services, we will drop any remaining connections. We need to add a rule to instruct iptables to start logging traffic.

sudo iptables -A INPUT -j LOG

We should also add this rule to FORWARD in case we end up forwarding traffic elsewhere.

sudo iptables -A FORWARD -j LOG

Finally, let’s drop all irrelevant traffic that hasn’t been matched yet. We can do this by adding a rule that matches everything in the chain, like so:

sudo iptables -A INPUT -j DROP

Alternatively, we can use the built-in policy feature to configure what happens when packets are passed into the chain without matching any rules:

sudo iptables -P INPUT DROP

The result is functionally identical.

One thing to remember is if you need to flush iptables and set a DROP policy, you should reverse the policy before flushing:

sudo iptables -P INPUT ACCEPTsudo iptables -F

If you do not do this, your iptables rules will be flushed and will only retain the default policy of dropping all incoming packets. This will cut off all network traffic to your server, including SSH connections.

By default, iptables does not persist its rules upon reboot, so after testing your configuration and determining it meets your requirements, you can install and enable to enforce these rules:

sudo apt-get install iptables-persistentsudo service iptables-persistent start

Configuring psad to Detect Scans

Now we have configured iptables rules, we can begin configuring psad to parse the logs.

Use root privileges to open the main psad configuration file:

sudo nano /etc/psad/psad.conf

You should change the EMAIL_ADDRESSES parameter to match the email addresses you wish to notify when reports are generated. You should also modify HOSTNAME to match your domain so that it references the correct machine:

EMAIL_ADDRESSES     [email protected], [email protected];HOSTNAME            your_domain.com;

Make sure to end each line with a semicolon (;) so that psad reads the file correctly.

You may want to check psad’s “danger level” declarations. These levels are psad’s way of categorizing threat levels. They are automatically determined by the number of packets involved in an event, but you can also assign certain types of traffic to specific danger levels. The default thresholds to reach each level are:

DANGER_LEVEL1           5;DANGER_LEVEL2           15;DANGER_LEVEL3           150;DANGER_LEVEL4           1500;DANGER_LEVEL5           10000;

You can change these levels based on the sensitivity level of psad’s alerts.

You can also configure psad’s sensitivity through the PORT_RANGE_SCAN_THRESHOLD parameter. This determines the number of ports that must be scanned in a range before an alert is triggered. By default, an alert is triggered after two ports are scanned:

PORT_RANGE_SCAN_THRESHOLD       1;

One of the most important things to configure is the IPT_SYSLOG_FILE parameter since it currently does not point to the syslog’s default file. Modify this to point to the syslog file:

IPT_SYSLOG_FILE         /var/log/syslog;

If you are using certain ports for port scanning, you should instruct psad to ignore attempts on these ports so that you do not trigger alerts with your tests:

IGNORE_PORTS            ports_or_range_to_ignore;

Similarly, you can ignore the IGNORE_PROTOCOLS, IGNORE_INTERFACES, and IGNORE_LOG_PREFIXES parameters.

If you find you are receiving alerts too frequently, you can set the threshold for email by adjusting the level required to send emails:

MIN_DANGER_LEVEL           1;  # Controls psad logging and email alertsEMAIL_ALERT_DANGER_LEVEL   1;  # Applies only for email alerts

You can further directly limit the number of emails through the following:

EMAIL_LIMIT                0;

A zero means no limit. This limit is the number of emails that can be generated from a single IP address. Let’s save and close the file.

psad Intrusion Detection

Now that we have a basic psad configuration and alerting functionality, we can implement our policies and activate our system.

Before starting, we should update psad’s signature definitions so that it can correctly identify known attack types.

sudo psad --sig-update

This will fetch the latest files and update the database.

Now, we need to restart the service to make use of these updates and implement the configuration changes.

sudo service psad restart

To view the current state of events detected by psad, enter:

sudo service psad status

[+] psadwatchd (pid: 3737)  %CPU: 0.0  %MEM: 0.0    Running since: Fri Jan 10 15:36:04 2014[+] psad (pid: 3735)  %CPU: 0.0  %MEM: 0.3    Running since: Fri Jan 10 15:36:04 2014    Command line arguments: [none specified]    Alert email address(es): [email protected][+] Version: psad v2.1.7[+] Top 50 signature matches:        [NONE][+] Top 25 attackers:        [NONE][+] Top 20 scanned ports:        [NONE][+] iptables log prefix counters:        [NONE]    Total packet counters: tcp: 0, udp: 0, icmp: 0[+] IP Status Detail:        [NONE]    Total scan sources: 0    Total scan destinations: 0[+] These results are available in: /var/log/psad/status.out

As you can see, no vulnerabilities have been found yet. We can also see events detected are logged to files located in /var/log/psad/.

Conducting a Test Scan

On another machine, we use the nmap command to scan the ports of this server. Let’s see if psad can tell. We’ll perform a SYN tcp port scan from another machine.

sudo nmap -PN -sS server_domain_or_ip

Starting Nmap 5.51 ( http://nmap.org ) at 2014-01-10 15:54 ESTNmap scan report for server_domain_or_ipHost is up (0.013s latency).Not shown: 999 filtered portsPORT   STATE SERVICE22/tcp open  sshNmap done: 1 IP address (1 host up) scanned in 6.84 seconds

As you can see, this scan shows that each port in my firewall configuration is marked as “filtered,” indicating it is protected by a firewall, except for the open SSH port.

On your server, you should rerun the status command:

sudo service psad status

You should see more alerts on the list. Since this event was just a scan of 1000 ports, many different threats’ signature matches were triggered. For attacks directed at specific ports or entry points, signatures will be more helpful.

If you set up email alerts, you should have received one or two emails. If you have a domain associated with the machine you scanned from, you should see a “whois” report of the owner associated with the scan.

Implementing Intrusion Prevention

Now that we have verified we can detect activities attempting to access our server, we can choose to implement a prevention mechanism where psad can automatically modify iptables rules to deny scanners.

Before doing so, we should look at the auto_dl file:

sudo nano /etc/psad/auto_dl

This file specifies that we should automatically set the danger level for certain IP addresses. For instance, if we have an attacker persistently attempting to probe our system, we can automatically set them to danger level 5:

attacker_ip          5;

You can also exempt certain IP addresses from triggering psad’s reaction. If we have not explicitly added rules in iptables, we can add localhost here and set it to “0”.

We should add our own computer’s IP to this list to prevent psad from locking ourselves out:

local_computer_ip        0;

Save and close the file once finished.

Open the psad configuration file once again:

sudo nano /etc/psad/psad.conf

Search for the parameter ENABLE_AUTO_IDS. This allows psad to modify our firewall to block certain addresses. If you wish to automate this, change it like so:

ENABLE_AUTO_IDS         Y;

Decide what constitutes enough of a threat level to block offending IPs. We can do this by adjusting the following parameter:

AUTO_IDS_DANGER_LEVEL       5;

Another important option is the total block time in seconds:

AUTO_BLOCK_TIMEOUT          3600;

This will block them for an hour by default.

Testing Intrusion Prevention

We can test how it works. In the same configuration file, set the following parameters:

ENABLE_AUTOIDS              Y;AUTO_IDS_DANGER_LEVEL       4;AUTO_BLOCK_TIMEOUT          60;

This will turn on automatic firewall configuration, set the threshold to danger level 4, which was hit with a normal SYN scan, and set the block time to 60 seconds.

Save and close the file.

If you added your home IP address to auto_dl, open that file and temporarily comment it out.

# local_computer_ip      0;

Now, restart psad to make it read these files again:

sudo service psad restart

On your own computer, you can rerun the scan last executed:

sudo nmap -PN -sS server_domain_or_ip

At this point, after a few seconds, if you are connected to the psad machine via SSH, your connection should drop. You will not be able to reconnect for 60 seconds.

This is because psad has taken action once your scan hit enough ports to reach danger level 4. It modified the iptable rules to block your IP from scanning.

Once you are able to log back in, you can view your iptable rules to see this block:

sudo iptables -S

-P INPUT DROP-P FORWARD ACCEPT-P OUTPUT ACCEPT-N PSAD_BLOCK_FORWARD-N PSAD_BLOCK_INPUT-N PSAD_BLOCK_OUTPUT-A INPUT -j PSAD_BLOCK_INPUT-A INPUT -i lo -j ACCEPT-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT-A INPUT -j LOG-A FORWARD -j PSAD_BLOCK_FORWARD-A FORWARD -j LOG-A OUTPUT -j PSAD_BLOCK_OUTPUT

Now that you have tested this feature, restore it to the functionality you plan to use. If you plan on actually using this feature, you should increase the ban length. Additionally, you should re-add the IP addresses you plan to connect from:

local_computer_ip           0;

ENABLE_AUTOIDS              Y;AUTO_IDS_DANGER_LEVEL       5;AUTO_BLOCK_TIMEOUT          3600;

After configuring the service for actual application, remember to restart psad:

sudo service psad restart

Keep in mind that certain attacks may spoof your server using other IP addresses. An attacker could cause you to inadvertently block legitimate sites or services. Therefore, blocking operations should be carefully considered.

Conclusion

By properly configuring network intrusion detection tools like psad, you can increase the chances of getting warnings you need before a problem occurs. Tools like psad can provide early warnings and can automatically handle certain situations.

The key to effectively using psad is properly configuring danger levels and email alerts. Used in conjunction with other intrusion detection resources, it can provide quite good coverage for detecting intrusion attempts.