Psad Email Alerts

Email is psad's primary alerting mechanism, because an email message can include more information than a syslog alert, and because email is ubiquitous and well-integrated with cell phones and other handheld devices. There is nearly always an easy way to check email.

The following is an example of a typical psad email alert. This particular alert is sent after psad detects a TCP connect() scan from the int_scanner system shown in Figure 6-1. (We'll walk through the entire alert in the next sections because this is the first such example in the book.) The complete psad alert example discussed in the next sections can be downloaded from http://www.cipherdyne.org/LinuxFirewalls.

Scan Danger Level, Ports, and Flags

The first bits of information included in a psad email alert are the danger level assigned to the source address of a scan, the scanned ports, and the flags set in the scan (for TCP scans). In the snippet of the psad alert below, the danger level is set to 4 because the number of packets and range of ports involved in the scan exceeds the default values of 1,500 and 1 required by the DANGER_LEVEL4 and PORT_RANGE_SCAN_THRESHOLD variables, respectively, in the /etc/psad/psad.conf file. In addition, because the source IP address is not included within the /etc/psad/auto_dl file, psad does not automatically assign a danger level to the source IP address. Because the scan does not trigger any signatures that have a danger level higher than 4, we are left with a danger level that is determined based only on the packet count and range of scanned ports.

Next, we see that the minimum TCP port number is 1, and the maximum is 61,440. Not every port within this range has been scanned because that would require at least 61,440 SYN packets even without retransmissions (which would happen in this case because we are using a connect() scan). By default, if Nmap is not explicitly given a range of ports to scan, it scans for a set of interesting ports that are derived from the nmap-services file bundled with the Nmap sources, and we see that only the SYN flag is set in this scan. From the perspective of iptables, the flags imply that either the -sT or -sS command-line arguments were given to Nmap. Finally, logging prefixes are displayed, and in this example, each of the packets from the scan is logged by iptables with a prefix of DROP.

2 This does not necessarily mean any kind of automated response. As the administrator of a system that is being scanned and probed, you might want to manually pick up the telephone and talk to the upstream provider of the offending IP address.

Scanned tcp ports: [1-61440: 1522 packets]

iptables chain: INPUT (prefix "DROP"), 398 packets

Source and Destination IP Addresses

The source IP address of the scan is next, along with reverse DNS information. By default, psad performs a reverse DNS lookup on offending source IP addresses unless the --no-rdns option is specified on the psad command line. Also included is a passive OS fingerprint that psad derived from the SYN packet (more on this topic in the next chapter), followed by the destination IP address and hostname.

Source: 192.168.10.200 DNS: int_scanner

OS guess: Linux:2.5::Linux 2.5 (sometimes 2.4) Destination: 192.168.10.1 DNS: iptablesfw syslog Hostname, Time Interval, and Summary Information

The syslog hostname is included next, and this is mostly useful if the iptables log message originates from a remote syslog server. You can configure syslog to accept log messages from multiple systems that are running iptables, and keeping track of the hostname helps to differentiate psad alerts from multiple systems. Timestamp information is also included so that you know when the psad alert was generated.

Next, if ENABLE_PERSISTENCE is set to Y, the scan information will not time out or be removed from memory as psad runs. The summary information provides the time the source IP address first started behaving suspiciously, the total number of email alerts that psad has sent for the same source IP address, the complete port range that has been scanned since the source IP address attracted attention to itself, and all iptables chains and packet counts associated with the source IP address.

Syslog hostname: iptables

Current interval: Tue Jul 10 12:06:23 2007 (start) Tue Jul 10 12:06:27 2007 (end) Overall scan start: Tue Jul 10 12:01:23 2007 1

Total email alerts: Complete tcp range: chain: interface: INPUT eth1

whois Database Information

The last block of information in a psad email alert is the result of a whois query against the source IP address of the scan. The excellent whois client written by Marco d'Itri (see http://www.linux.it/~md/software) is bundled with the psad sources and used by psad for all whois queries. (You can disable whois lookups with the --no-whois command-line argument to psad.) The following information is the whois query result for the source of the scan 192.168.10.200:

OrgName: Internet Assigned Numbers Authority

OrgID: IANA

Address: 4676 Admiralty Way, Suite 330

City: Marina del Rey

StateProv: CA

PostalCode: 90292-6695

Country: US

NetRange: 192.168.0.0 - 192.168.255.255

CIDR: 192.168.0.0/16

NetName: IANA-CBLK1

NetHandle: NET-192-168-0-0-1

NetType: IANA Special Use

NameServer: BLACKHOLE-1.IANA.ORG

NameServer: BLACKHOLE-2.IANA.ORG

Comment: This block is reserved for special purposes.

Comment: Please see RFC 1918 for additional information. Comment:

RegDate: 1994-03-15

Updated: 2002-09-16

OrgAbuseHandle: IANA-IP-ARIN

OrgAbuseName: Internet Corporation for Assigned Names and Number

OrgAbusePhone: +1-310-301-5820

OrgAbuseEmail: [email protected]

OrgTechHandle: IANA-IP-ARIN

OrgTechName: Internet Corporation for Assigned Names and Number OrgTechPhone: +1-310-301-5820 OrgTechEmail: [email protected]

# ARIN WHOIS database, last updated 2006-06-09 19:10

# Enter ? for additional hints on searching ARIN's WHOIS database.

Was this article helpful?

0 0

Post a comment