cipherdyne.org

02 January, 2013

The 2.2.1 release of psad is available for download. This release adds new support for detecting a type of scan that psad has been previously blind to - IP protocol scanning (nmap -sO). Also in this release is the ability to detect Topera IPv6 scans and differentiate them from Nmap IPv6 scans. Other important changes include a new test suite, email throttling, and auto blocking timeouts that can be set for each danger level. Here is the complete ChangeLog:

• Added IP protocol scan detection (nmap -sO). A new psad.conf variable PROTOCOL_SCAN_THRESHOLD defines the minimum number of different IP protocols (default = 5) that must be scanned before an alert is triggered.
• Added detection for Topera IPv6 scans when --log-ip-options is used in the ip6tables logging rule. When this option is not used, the previous psad-2.2 release detected Topera scans. An example TCP SYN packet generated by Topera when --log-ip-options is used looks like this (note the series of empty IP options strings "OPT ( )":

  Dec 20 20:10:40 rohan kernel: [  488.495776] DROP IN=eth0 OUT=
  MAC=00:1b:b9:76:9c:e4:00:13:46:3a:41:36:86:dd
  SRC=2012:1234:1234:0000:0000:0000:0000:0001
  DST=2012:1234:1234:0000:0000:0000:0000:0002 LEN=132 TC=0 HOPLIMIT=64
  FLOWLBL=0 OPT ( ) OPT ( ) OPT ( ) OPT ( ) OPT ( ) OPT ( ) OPT ( )
  OPT ( ) OPT ( ) PROTO=TCP SPT=61287 DPT=1 WINDOW=8192 RES=0x00 SYN
  URGP=0
  

• Bug fix in --Analyze mode when IP fields are to be searched with the --analysis-fields argument (such as --analysis-fields "SRC:1.2.3.4"). The bug was reported by Gregorio Narvaez, and looked like this:

  Use of uninitialized value $_[0] in length at
  ../../blib/lib/NetAddr/IP/UtilPP.pm (autosplit into
  ../../blib/lib/auto/NetAddr/IP/UtilPP/hasbits.al) line 126.
  Use of uninitialized value $_[0] in length at
  ../../blib/lib/NetAddr/IP/UtilPP.pm (autosplit into
  ../../blib/lib/auto/NetAddr/IP/UtilPP/hasbits.al) line 126.
  Bad argument length for NetAddr::IP::UtilPP::hasbits, is 0, should be
  128 at ../../blib/lib/NetAddr/IP/UtilPP.pm (autosplit into
  ../../blib/lib/auto/NetAddr/IP/UtilPP/_deadlen.al) line 122.
  

• Added --stdin argument to allow psad to collect iptables log data from STDIN in --Analyze mode. This makes it easier to run an iptables logs through psad from arbitrary files like so:

  # grep "IN=.*OUT=" /var/log/kern.log | psad -A --stdin
  

• Added the ability to acquire Snort rule 'msg' fields from fwsnort if it's also installed. A new variable FWSNORT_RULES_DIR tells psad where to look for the fwsnort rule set. This fixes a problem reported by Pui Edylie to the psad mailing list where fwsnort logged an attack that psad could not map back to a descriptive 'msg' field.
• Added the ability to set per-danger level timeouts when psad is configured to run in auto-blocking mode. These timeouts are implemented with new AUTO_BLOCK_DL*_TIMEOUT variables - one for each of the five possible danger levels that may be assigned to a scanning IP address.
• Added the ability to throttle emails generated by psad via a new EMAIL_THROTTLE variable which is implemented as a per-IP threshold. That is, if EMAIL_THROTTLE is set to "10", then psad will only send 1/10th as many emails for each scanning IP as it would have normally.

The complete psad-2.2.1 ChangeLog can also be found here via the psad gitweb interface.

21 April, 2012

After a long development cycle, the 2.2 release of psad is available for download. This release adds major new functionality for the detection of malicious traffic that is delivered over IPv6 by parsing ip6tables logs. A significant portion of this capability is enabled by the excellent NetAddr::IP CPAN module that can properly handle IPv6 addresses. In addition, speed optimizations have been made that result in psad-2.2 being about 15% faster than previous releases, several bugs have been fixed (including one that caused compile time warnings on recent versions of perl), and a comprehensive test suite has been added. psad-2.2 is a stepping stone to the upcoming psad-3.0 release that will include support for both PF and ipfw firewalls running on *BSD systems. Quite a bit of this work has already been done in the openbsd_integration branch.

Here is an excerpt of the psad-2.2 ChangeLog:

• Added support for detection of malicious traffic that is delivered via IPv6. This is accomplished by parsing ip6tables log messages - these are in a slightly different format than the iptables log messages. Here is an example:
  
  Mar 17 13:39:13 linux kernel: [956932.483644] DROP IN=eth0 OUT= MAC=00:13:46:3a:41:36:00:1b:b9:76:9c:e4:86:dd SRC=2001:0db8:0000:f101:0000:0000:0000:0002 DST=2001:0db8:0000:f101:0000:0000:0000:0001 LEN=80 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=TCP SPT=50326 DPT=993 WINDOW=5760 RES=0x00 SYN URGP=0
  
  Detection of malicious IPv6 traffic can be disabled via a new ENABLE_IPV6_DETECTION config variable.
• For ICMP6 traffic, added protocol validation for ICMP6 type/code combinations.
• Added a new test suite in the test/ directory to validate psad run time operations (scan detection, signature matching, and more). To support this, a new '--install-test-dir' option was added to the install.pl script. Once this is executed, the test suite can be run via the test-psad.pl script in the test/ directory.
• Added a new MAX_SCAN_IP_PAIRS config variable to allow psad memory usage to be constrained by restricting the number of unique IP pairs that psad This is useful for when psad is deployed on systems with little memory, and is best utilized in conjunction with disabling ENABLE_PERSISTENCE so that old scans will also be deleted (and thereby making room for tracking new scans under the MAX_SCAN_IP_PAIRS threshold).
• Bug fix for 'qw(...) usage as parenthesis' warnings for perl > 5.14
• Bug fix that caused psad to emit the following:
  
  Undefined subroutine &main::LOG_DAEMON called at ./psad line 10071.
  
  This problem was noticed by Robert and reported on the psad mailing list.
• Bug fix for ICMP packet handling where psad would incorrectly interpret ICMP port unreachable messages as UDP packets because the UDP specifics are included in the iptables log message. This bug was first reported by Lukas Baxa to the Debian maintainers and was followed up by Franck Joncourt: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596240 An example ICMP log message that exposed the bug is included below:
  
  Sep 8 18:04:26 baxic kernel: [28241.572876] IN_DROP IN=wlan0 OUT= MAC=00:1a:9f:91:df:ae:00:21:27:e8:0a:a0:08:00 SRC=10.0.0.138 DST=192.168.1.103 LEN=96 TOS=0x00 PREC=0xC0 TTL=254 ID=63642 PROTO=ICMP TYPE=3 CODE=3 [SRC=192.168.1.103 DST=10.0.0.138 LEN=68 TOS=0x00 PREC=0x00 TTL=0 ID=22458 PROTO=UDP SPT=35080 DPT=33434 LEN=48 ]

The complete psad-2.2 ChangeLog can be found here via the psad gitweb interface.

22 August, 2010

Recently a psad user notified me via email that the psad-2.1.7.tar.gz tarball was flagged by ClamAV as being infected with Exploit.HTML.MHTRedir-8. After checking a few things, it turns out that ClamAV is triggering on a Snort rule in the Emerging Threats rule set which is bundled in both psad and fwsnort. The following analysis shows exactly what ClamAV is detecting and why, and also provides some guidance for how to avoid this for any software projects that distribute Snort rules. Similar logic would apply to other software engineering efforts - including commercial intrusion detection systems - that are (by their nature) looking for malicious artifacts on the filesystem or within network traffic.

First, let's download psad-2.1.7.tar.gz and check the gpg signature (just to make sure we're talking about exactly the same file): $ wget --quiet http://www.cipherdyne.org/psad/download/psad-2.1.7.tar.gz
$ wget --quiet http://www.cipherdyne.org/psad/download/psad-2.1.7.tar.gz.asc
$ gpg --verify psad-2.1.7.tar.gz.asc
gpg: Signature made Wed 14 Jul 2010 06:01:42 PM EDT using DSA key ID 0D3E7410
gpg: Good signature from "Michael Rash (Signing key for cipherdyne.org projects) <mbr@cipherdyne.org>" Ok, now here is what clamscan says about the psad-2.1.7.tar.gz tarball: $ clamscan psad-2.1.7.tar.gz
psad-2.1.7.tar.gz: Exploit.HTML.MHTRedir-8 FOUND

----------- SCAN SUMMARY -----------
Known viruses: 816934
Engine version: 0.96.1
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 6.42 MB
Data read: 1.16 MB (ratio 5.55:1)
Time: 7.169 sec (0 m 7 s) Let's see which file within the psad-2.1.7 tarball matches the Exploit.HTML.MHTRedir-8 signature: $ tar xfz psad-2.1.7.tar.gz
$ clamscan -r -i psad-2.1.7
psad-2.1.7/deps/snort_rules/emerging-all.rules: Exploit.HTML.MHTRedir-8 FOUND

----------- SCAN SUMMARY -----------
Known viruses: 816934
Engine version: 0.96.1
Scanned directories: 41
Scanned files: 405
Infected files: 1
Data scanned: 12.55 MB
Data read: 6.41 MB (ratio 1.96:1)
Time: 8.446 sec (0 m 8 s) Intuitively, this makes sense. That is, given that ClamAV is out to identify nasty things within files, and given that Snort rules are designed to identify nasty things as they communicate over the network, it stands to reason that there might be some overlap. This overlap is not an indication of something wrong in either the Snort rules or in ClamAV. Now, let's find out specifically which Snort rule within the emerging-all.rules file is triggering the ClamAV match. We first take a look at the Exploit.HTML.MHTRedir-8 signature: $ cp /var/lib/clamav/main.cvd .
$ sigtool --unpack main.cvd
$ grep Exploit.HTML.MHTRedir-8 main.ndb
Exploit.HTML.MHTRedir-8:3:*:6d68746d6c3a66696c653a2f2f{1-20}2168 The last line above is the entire ClamAV signature, and the pattern 6d68746d6c3a66696c653a2f2f is the key. The ":3:" part identifies the signature as type "normalized HTML", so ClamAV matches the pattern 6d68746d6c3a66696c653a2f2f against the "normalized HTML" representation of each processed file. We can decode the pattern as follows: echo 6d68746d6c3a66696c653a2f2f | xxd -r -p
mhtml:file:// So, within the emerging-all.rules file, we are interested in any Snort rule that contains the string mhtml:file://. There is also the "{1-20}2168" criteria which says to match the hex bytes 2168 anywhere from 1 to 20 bytes after the first pattern match. $ grep mhtml psad-2.1.7/deps/snort_rules/emerging-all.rules
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET MALWARE Bundleware Spyware CHM Download"; flow: to_server,established; content:"Referer\: ms-its\:mhtml\:file\://C\:counter.mht!http\://"; nocase; content:"/counter/HELP3.CHM\:\:/help.htm"; nocase; classtype: trojan-activity; sid: 2001452; rev:4;)
Sure enough, sid:2001452 "ET MALWARE Bundleware Spyware CHM Download" has the keyword content:"Referer\: ms-its\:mhtml\:file\://C\:counter.mht!http\://". Even though there are escaping backslashes, the normalized HTML processing in ClamAV takes this into account and matches the pattern anyway from the ClamAV signature.

So, how can we keep the original Snort rule, but change it so that ClamAV not longer flags it?

Fortunately, ClamAV does not interpret the Snort rules convention of specifying non-printable bytes between "|" characters within content fields, so we simply need to change one of characters to hex notation. Snort will still offer the same detection if network traffic matches the rule, and ClamAV won't flag it. So, let's just change the "m" in "mhtml\:file\://" to its hex equivalent, like so: "|6d|html\:file\://". Once we make this change and save the psad-2.1.7/deps/snort_rules/emerging-all.rules file, we rerun clamscan: $ clamscan -r -i psad-2.1.7

----------- SCAN SUMMARY -----------
Known viruses: 816934
Engine version: 0.96.1
Scanned directories: 41
Scanned files: 405
Infected files: 0
Data scanned: 17.23 MB
Data read: 6.41 MB (ratio 2.69:1)
Time: 10.024 sec (0 m 10 s) That's better. Over the next few days I'll re-release all affected versions of psad and fwsnort with the above change to ensure that there aren't any additional ClamAV matches.

In conclusion, if you are involved in any software engineering effort that distributes or makes use of Snort rules, it is probably a good idea to run distribution packages through ClamAV and see if there are any matches. If so, it may be possible to take advantage of Snort rule syntax options to still achieve the same signature coverage while not having ClamAV flag anything.

14 July, 2010

The 2.1.7 release of psad is available for download. This release adds some relatively minor functionality to switch whois lookups to the destination IP whenever the source IP is part of a directly connected subnet. This change gives better reporting data in normal psad email alerts. The complete ChangeLog entries are displayed below. The psad-2.1.6 release was also made a few days ago, and fixes a bug that caused psad to die on some Ubuntu systems when using the Date::Calc Decode_Month() function, and it also added the --Override-config feature so that alternate configuration variables can be specified via config files besides psad.conf (implemented by Franck Joncourt).

• (Dan A. Dickey) Added the ability to use the "ip" command from the iproute2 tools to acquire IP addresses from local interfaces. Dan's description is as follows: "...A main reason for doing this is in the case of multi-homed hosts. ifconfig sets these up on an interface using aliases, iproute2 does not. So, for a multi-homed interface (eth0 with multiple addresses), ifconfig -a only shows the first one configured and not the rest. ip addr shows all of the configured addresses...".
• Added ENABLE_WHOIS_FORCE_ASCII to replace any non-ascii characters in whois data (which is common with whois lookups against Chinese IP addresses for example) with the string "NA". This option is disabled by default, but can be useful if errors like the following are seen upon receiving an email alert from psad:
  
  <<< 554 5.6.1 Eight bit data not allowed
  554 5.0.0 Service unavailable
  
  
• Updated psad to issue whois lookups against IP addresses that are not directly connected to the local system. This is useful for example when an internal system is scanning an external destination system, and the scan is logged in the FORWARD chain. Issuing whois lookups on the internal system (frequently on RFC 1918 address space) is not usually very useful, but issuing the whois lookup against the destination system gives much more interesting data. This feature can be disabled with the new ENABLE_WHOIS_FORCE_SRC_IP variable.

22 August, 2008

The 2.1.4 release of psad is available for download. This release moves all dependencies into a new deps/ directory - including all perl modules, Snort rules files, and the whois client (from Marco d'Itri). This makes for a cleaner integration of psad with the Debian Linux distribution, thanks to Franck Joncourt. There are also a couple of minor bugfixes and feature enhancements according to the ChangeLog entries below. Finally, all cipherdyne.org projects are now signed with a new GnuPG key available here.

• Restructured perl module paths to make it easy to introduce a "nodeps" distribution of psad that does not contain any perl modules. This allows better integration with systems that already have all necessary modules installed (including the IPTables::ChainMgr and IPTables::Parse modules). The main driver for this work is to make all cipherdyne.org projects easily integrated with distributions based on Debian, and Franck Joncourt has been instrumental in making this process a reality. All perl modules are now placed within the "deps" directory, and the install.pl script checks to see if this directory exists - a separate psad-nodeps-<ver> tarball will be distributed without this directory. The Debian package for psad can then reference the -nodeps tarball, and a new "psad-nodeps.spec" file has been added to build an RPM from the psad sources that does not install any perl modules.
• Updated to use the normal system whois client if the /usr/bin/whois_psad path does not exist, and moved the whois/ directory into the deps/ directory. This removes /usr/bin/whois_psad as a strict dependency.
• Bugfix to honor the IPT_SYSLOG_FILE variable in --Analyze-msgs mode.
• Switched from the deprecated bleeding-all.rules file to the new emerging-all.rules available from Matt Jonkman at Emerging Threats (http://www.emergingthreats.net).

20 January, 2008

Erik Heidt who runs the Art of Information Security Blog has started a dedicated blog about psad. He discusses monitoring of psad via a custom shell script, as well as some of the attack information that psad reports on. This information is derived from Snort rules/signatures that are matched by psad within iptables LOG messages. Such signature matching is possible (for signatures that do not contain content matches) because of the completeness of the iptables logging format, which includes most of the interesting fields in the network and transport layer headers. Here is an example of the type of reporting that Erik has included in one of his blog posts:
"ICMP PING" (icmp), Count: 223, Unique sources: 89, Sid: 384
"MISC Windows popup spam attempt" (udp), Count: 154, Unique sources: 38, Sid: 100196
"MISC Microsoft SQL Server communication attempt" (tcp), Count: 37, Unique sources: 16, Sid: 100205
"MISC VNC communication attempt" (tcp), Count: 14, Unique sources: 6, Sid: 100202
"PSAD-CUSTOM Nachi worm reconnaisannce" (icmp), Count: 10, Unique sources: 5, Sid: 100209
"MISC Ghostsurf communication attempt" (tcp), Count: 6, Unique sources: 1, Sid: 100203
"MISC HP Web JetAdmin communication attempt" (tcp), Count: 6, Unique sources: 2, Sid: 100084
"BACKDOOR DoomJuice file upload attempt" (tcp), Count: 4, Unique sources: 1, Sid: 2375
"MISC Radmin Default install options attempt" (tcp), Count: 2, Unique sources: 1, Sid: 100204 There was also more publicity for psad and fwsnort at linux.com where John Bambenek referenced both projects in an article entitled "iptables as a replacement for commercial enterprise firewalls". I completely agree that in many cases iptables can function as a complete replacement for commercial firewall products. While not appropriate perhaps for all deployments depending on various corporate factors (such as the level of expertise of the local IT staff and the need for support), I think these barriers are waning in importance considering the quality of iptables, modern Linux distributions, and user interfaces (mentioned by John in his article) such as Firewall Builder.

04 January, 2008

Drew Bentley, a long time user of psad, emailed me to mention that he had voted for psad to be included within the 2007 LinuxQuestions.org Members Choice Awards in the category of Network Security Application of the Year. Although there are many security projects out there that outstrip the Cipherdyne projects, my personal hope would be that eventually fwknop might be included in the Members Choice Awards someday. The rise of service authorization via passive means embodied by Single Packet Authorization allows the security model employed by VPN services and software such as SSH to be strengthened with a default-drop packet filter. This reduces the number of functions - any one of which has a non-zero probability of containing a security vulnerability - that an attacker can tweak from arbitrary source IP addresses.
     I personally sleep better at night knowing that my SSH daemon can only be reached after a would-be client is passively authenticated and authorized to communicate through the iptables policy by sending a properly encrypted and non-replayed SPA packet. Anyone scanning for my SSH daemon with nmap cannot even see that it is listening.

20 December, 2007

The EnGarde Linux distribution, which focuses on security, has announced that they now bundle both fwknop and psad within their latest release (3.0.18). Here is a quote from their press release:

   Guardian Digital is happy to announce the release of EnGarde Secure Community 3.0.18 (Version 3.0, Release 18). This release includes many updated packages and bug fixes, some feature enhancements to Guardian Digital WebTool and the SELinux policy, and a few new features.

In distribution since 2001, EnGarde Secure Community was one of the very first security platforms developed entirely from open source, and has been engineered from the ground-up to provide users and organizations with complete, secure Web functionality, DNS, database, e-mail security and even e-commerce.

Coupled with the EnGarde annoucement, linuxsecurity.com has published an article about how to configure fwknop on EnGarde systems to add a strong default-drop stance for SSHD:

   This article will walk the reader through an EnGarde Secure Linux implementation of fwknop, from the initial iptables rules setup to the deployment of fwknop on both the server and client side. By the end of the article, the user will be able to explicitly shutdown all access to the EnGarde Secure Linux SSH daemon to only those with fwknop credentials.