cipherdyne.org

Michael Rash, Security Researcher



psad Frequently Asked Questions


1. General


1.1. What is psad?

psad makes use of iptables and ip6tables log messages to detect, alert, and (optionally) block port scans and other suspect traffic. For TCP scans psad analyzes TCP flags to determine the scan type (syn, fin, xmas, etc.) and corresponding command line options that could be supplied to nmap to generate such a scan. In addition, psad makes use of many TCP, UDP, and ICMP signatures contained within the Snort intrusion detection system (see http://www.snort.org/) to detect suspicious network traffic such as probes for common backdoors, DDoS tools, OS fingerprinting attempts, and more. By default psad also provides alerts for snort rules that are detected directly by iptables/ip6tables through the use of a ruleset generated by fwsnort (http://www.cipherdyne.org/fwsnort/). This enables psad to send alerts for application layer attacks. psad features a set of highly configurable danger thresholds (with sensible defaults provided) that allow the administrator to define what constitutes a port scan or other suspect traffic. Email alerts sent by psad contain the scanning ip, number of packets sent to each port, any TCP, UDP, or ICMP signatures that have been matched (e.g. "NMAP XMAS scan"), the scanned port range, the current danger level (from 1 to 5), reverse dns info, and whois information. psad also makes use of various packet header fields associated with TCP SYN packets to passively fingerprint remote operating systems (in a manner similar to the p0f fingerprinter) from which scans originate. This requires the use of the --log-tcp-options argument for iptables/ip6tables logging rules; if this option is not used, psad will fall back to a fingerprinting method that makes use of packet length, TTL and TOS val‐ ues, IP ID, and TCP window sizes.

psad reads all iptables/ip6tables log data by default from the /var/log/messages file. By parsing firewall log messages, psad is provided with data that represents packets that have been logged (and possibly dropped) by the running iptables/ip6tables policy. In this sense, psad is supplied with a pure data stream that exclusively contains packets that the firewall has deemed unfit to enter the network. psad consists of three daemons: psad, kmsgsd, and psadwatchd. psad is responsible for processing all packets that have been logged by the firewall and applying the signature logic in order to determine what type of scan has been leveraged against the machine and/or network. kmsgsd (deprecated) reads all messages that have been written to the /var/lib/psad/psadfifo named pipe and writes any message that matches a particular regular expression (or string) to /var/log/psad/fwdata. kmsgsd is only used if the ENABLE_SYSLOG_FILE variable is disabled in psad.conf. psadwatchd is a software watchdog that will restart any of the other two daemons should a daemon die for any reason.

1.2. Why are you releasing it?

Because I'm interested in seeing how far iptables/ip6tables can go towards providing data that is useful for network intrusion detection. Also, I'm releasing psad because port scans should be detected in a way that guarantees they are blocked first, and then detected and alerts sent. The most well known port scan detection software "portsentry" does not do this.

1.3. Is there a mailing list?

Yes, SourceForge is generous enough to host the psad mailing list.

1.4. What platforms are supported?

As of January, 2003 psad supports Linux systems; specifically Gentoo, Fedora, Red Hat, Mandrake, SuSE, Slackware, and Debian distributions. If you have it working on a Linux distribution not listed here, please send email to: Michael Rash.

1.5. What about Linux distributions that are not yet directly supported?

psad has been written to be as portable as possible across Linux distros, but if you are running a distro that psad does not seem to support please send email to: Michael Rash. Support for ipfilter on *BSD and OS X systems is coming soon.

1.6. Is psad available as a Debian or RPM package?

Daniel Gubser creates Debian packages, and versions of psad later than 1.2.2 are available in RPM form.

1.7. What source control system is used by the psad project?

psad uses git for source control, and the source code can be viewed over the web at gitub here.

1.8. Is detailed documentation available?

Yes. There are three primary sources of documentation: the Online Config Guide, the INSTALL file, and the psad man page. There are also man pages for psadwatchd and kmsgsd. In addition psad was the subject of a Linux Journal article and has also been referenced in several books.

1.9. How can I make a suggestion or bug report for psad?

Both suggestions and bug reports are always welcome and greatly appreciated. Just send email to Michael Rash with your suggestion or bug report. If your suggestion or bug report ends up changing the code in any way then you will be added to the CREDITS file and the online list of contributors.

2. Differences between psad and other security software

2.1. How is psad different from portsentry?

psad addresses all of the following limitations of portsentry:

* portsentry listens on ports to detect scans; this forces you to break your firewall in order for it to get any data.
* portsentry complicates administration of any firewall you deploy on your system since you have make sure you don't block packets to ports portsentry is listening on.
* portsentry allows an attacker to talk directly to your operating system's IP stack for the ports it is monitoring. This means that although operating system fingerprinting packets can be detected by portsentry, such scans will actually work against your system.
* portsentry does not use a scoring mechanism for scans. After all, repeated fin scans from the same IP against ports that are commonly used for backdoor programs should probably be treated differently than a few stray connection attempts to relatively unimportant ports.
* portsentry makes no effort to passively fingerprint the remote operating system.
* portsentry cannot detect any probes that utilize the icmp protocol.
* portsentry can only detect scans against ports it can bind to.
* portsentry makes it look like your machine is running lots of servers under the output of lsof and netstat.
* portsentry can detect advanced scans (syn, fin, xmas, etc.), but it has no provision for specifically detecting probes for backdoors or DDoS tools.
* portsentry can only detect scans that are directed against the local machine.
* portsentry does not consider the source port used in scan packets.
* portsentry does not have integrated support to issue whois lookups for IP addresses that have scanned your machine.
* portsentry does not have integrated support for sending email alerts.
* In portsentry's defense, it is portable across many different unix-style operating systems. It should be noted, however, that most modern *nix kernels have built-in firewalls, and stopping port scans in the first place is better than just detecting them.


NOTE: The above bullets apply to portsentry-1.x. Some of these issues look as though they will be fixed in the 2.x series through the use of libpcap, but as of Feb, 2003 there is only a beta release of portsentry-2.0. In addition Psionic's website has been taken down after their acquisition by Cisco so development of portsentry may have stopped.

2.2. How is psad different from Snort?

The goals of the two projects are quite different. Snort is a full-blown network intrusion detection system and uses the libpcap library to inspect not only the network and transport headers, but also the contents of packets. By contrast, psad is designed to function as a network intrusion detection system that exclusively uses firewall logs for data. It is meant to be deployed on an iptables firewall to insure it is properly configured and to analyze the data it provides as it blocks and logs packets. Note that if you combine psad with fwsnort and the iptables string match extension, then psad is capable of detecting about 50% of all Snort signatures including those that inspect the application portion of IP packets. However, if you want a full-blown network IDS that can do packet defragmentation and tcp stream reassembly, then go download Snort. :)

3. Operational

3.1. What should I do if psad catches a scan against my system?

Nmap is freely available on the internet and so anyone who wants to port scan your machine can, and they can do it quite effectively. However the vast majority of such scans are relatively harmless, especially if 1) the act of stopping them also allows you to detect them (this is the method employed by psad), and 2) the person running the scan is one of the k1dd13s. If you receive repeated scans from a particular IP, then you can use the whois information in the psad alert to determine who owns the IP and contact them directly (keep in mind of course that scans may be spoofed).

3.2. Can psad automatically block IP addresses that have scanned my system?

psad has the capability of automatically blocking IP addresses with both iptables and/or tcpwrappers. Furthermore, psad can be configured to only block an IP after it has reached a certain danger level which the admin defines. The two relevant configuration variables in the /etc/psad/psad.conf file are "ENABLE_AUTO_IDS" and "AUTO_IDS_DANGER_LEVEL". Note that the auto blocking feature is disabled by default; please see the next question.

3.3. Is it a good idea to set ENABLE_AUTO_IDS="Y" to automatically block scans?

In general no, and this feature is disabled by default. The reason for this is that a scan can be spoofed from any IP address (see the -S option to nmap). If psad is configured to automatically block scans then an attacker can spoof a scan, say, from www.yahoo.com and then you will be parsing your firewall ruleset to discover why you can't browse Yahoo's website, (or you can just execute "psad --Flush" to remove any auto-generated firewall rules). Also, an advanced scanning technique called the TCP Idle Scan requires that scan packets are spoofed by the attacker from a seemingly unrelated IP address from the viewpoint of the target. Nmap implements the Idle scan with its -sI option, and a good explanation of the technique can be found here.

3.4. Can psad submit logs to DShield?

Yes. Psad can send logs to the DShield distributed IDS. The relevant configuration variable in psad.conf is "ENABLE_DSHIELD_ALERTS", followed by three other variables that allow the admin to control the DShield alerting interval, specify a DShield user ID, and more.

3.5. How can I see how many packets psad has processed?

Run "psad --Status" (as root). The output will contain a breakdown of how many tcp, udp, and icmp packets psad has processed since psad was started. Note that not all packets logged by iptables are necessarily part of a scan and so the total number of packets displayed in the "Global packet counters" section of the status output may be more than the sum of packets associated with individual scans.

3.6. How can I see a summary of all IP addresses that have scanned my machine?

Run "psad --Status" (as root). A list of all IP addresses that have scanned your machine since psad was last started will be displayed. The --Status output will also display the danger levels each scanning IP has reached.

3.7. Does psad have a small OS footprint?

Even though the main psad daemon is written in perl, the footprint it has on the underlying operating system is quite small since psad spends most of its time sleeping and only periodically wakes up (every five seconds by default) to check if new packets have been logged by iptables. On my home system (PIII 700, 750MB) psad consistently runs at 0% CPU and 0.5% memory utilization unless I'm hit by a heavy scan.

3.8. How can I see a summary of how much cpu and memory psad is using?

There are many ways to view cpu and memory utilization (ps, top, etc.), but executing "psad --Status" (as root) will display a nice summary of all three psad daemons without requiring any additional parsing. The --Status output also displays a summary of IP addresses from which psad has detected scans or other suspect traffic.

3.9. Why am I not receiving email alerts from psad?

psad uses the mail client that is usually installed by default at /bin/mail. If you are not receiving alerts from psad, then check to make sure that you are able to send email (as root) from the system running psad to the email address(es) you have defined with the EMAIL_ADDRESSES variable in /etc/psad/psad.conf. Remember to add the -v option to the mail command to assist in troubleshooting. For example: /bin/mail -v -s "test email" you@domain.com < /dev/null

3.10. Why am I sometimes seeing "ACK,PSH" scans from some websites I just visited?

If you are running psad-1.0.0-pre5 or later, then set the IGNORE_CONNTRACK_BUG_PKTS variable to "Y" (this is the default). If you are not running at least psad-1.0.0-pre5 then I recommend upgrading to the latest version of psad. For more technical background on this issue, read on:

For iptables firewalls as of Linux kernel version 2.4.19, if the ip_conntrack module is loaded (or compiled into the kernel) and the firewall has been configured to keep state of connections, occasionally packets that are supposed to be part of normal TCP traffic will not be correctly identified due to a bug in the firewall and hence dropped. Such packets will then be interpreted as a scan by psad even though they are not part of any malicious activity. Fortunately an interim fix for this problem is to simply extend the TCP_CONNTRACK_CLOSE_WAIT timeout value in linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c from 60 seconds to 2 minutes, and a kernel patch "conntrack_patch" is included with the psad sources to change this. (Requires a kernel recompile of course, see the Kernel-HOWTO.)

3.11. Why does psad use a different whois client than the one already installed on my system?

Bundled with psad is an excellent whois client written by Marco d'Itri. It provides more accurate querying of the correct registry for almost all netblocks. The whois client that is normally bundled with Red Hat systems provided ample motivation for finding a better solution. If your system does not already have it installed, then it should.

3.12. Why are there both C and Perl versions of psadwatchd and kmsgsd?

psad originally started as a perl project for Bastille Linux, but over time the perl code is being translated into C for better performance and less memory utilization. Also, the psad installer will attempt to compile the C versions first but fall back to the perl versions just in case the compilation fails. It is always nice to have redundancy wherever possible.