The fish just haven't been biting here in the Land of Cheese this year. So that has gave me tons more time in my lab geekin' and phrackin'. I was playing around in my lab the other day trying to build out a low to no cost SMB security design and hide out from my in laws. Of course many vendors already offer good solutions to this problem. But as a victim of the IBM, Unisys days of "My way or the highway" I never ever like to turn over control of my network to a vendor. Plus it really helps me to see the value add of what a vendor is really providing. If it is just a X-Window interface over Linux; then it's "Thanks for lunch, there's the door."
I wanted to see what it would take to build out a full SMB network that would pass audits and be secure enough that hackers would classify it as non low hanging fruit and move on to the next target.
I started messin' around with Port Knocking and Single Packet Authentication. I grabbed one of my favorite Linux reference guides; "Linux Firewalls" by Michael Rash. If you have not read this book, you're missin' out on the best thing since cornbread found pinto beans. Super friggen awesome book!
On my way to chapter 12, I happened to stumble across Port Scan Attack Detector (PSAD). Wholly smokes! I have completely overlooked this awesome utility! PSAD at one time in a galaxy not so far away was called Bastille Linux NIDS. It is still part of the that awesome package but now called PSAD. If you are looking for a great OS hardening package look no further then: http://bastille-linux.sourceforge.net/
PSAD is basically, a active log grep-ing tool that scans logs and takes action based upon already classified information. It works on common sense. Did the firewall (IPtables) detect and flag a packet that did not conform to a local security policy? Then let's do something about it!
But it is really more then that. PSAD can detect not only port scans but also the OS of the machine that initiated the scan (most of the time). It can also detect DDOS's and reuse the Snort signature set to generate alerts. PSAD integrates very well into the normal system processes. Heck even the three daemons each start their own unique process.
PSAD is wrote in Perl with some C as well. It's a place of cake to install. Especially, if you use Ubuntu/Deb:
sudo apt-get install psad
Make sure you also config syslogD to pass data to PSAD. I did this by piping kernel info with the append:
kern.info |/var/lib/psad/psadfifo
Config'ing up PSAD is normal and nothing out of the ordinary. Just editing out the /etc/psad/psad.conf file with you favorite editor. Like any good open source prog it's the options that really add the value. I config up email alerts, danger levels, enable_persistence and a few others as the mood strikes me. Start to finish install and config is only around 30 minutes max from a base level system. Heck fire it's even easier if you go to:
http://www.cipherdyne.org/LinuxFirewalls/ch05/ cut, copy, paste the conf file!! After editing both syslog and PSAD restart each process.
A simple: psad -S confirmed everything was up and kickin' it. Time to test it out! In some baseline setting testing; I ran a NMAP TCP and UDP scan against a couple servers.
nmap -sT -n 192.168.1.55 and nmap -sU -n 192.168.1.55
Sure enough and true to form, PSAD flagged detected the scan and shot me over an email on my Postcast Server once I hit the Danger Level I config'ed with the info and a reverse DNS lookup on the attacker a OS guess on TCP scans which means it must be pulling it from the SYN packet.
I love the common sense approach Michael Rash took with not only coding up PSAD but with also writing a great book. Due to the portability of this code and low overhead involved, I am going to start trying to install/port this on my DD-WRT imagine. More on that to be posted later...
PSAD can be downloaded at: http://www.cipherdyne.org/psad/ as well as install and config guides.
I was thinking about ending with a cheesy used car salesman tag line like; "You won't Be Sad with PSAD" But that is too goober-ific and would never work...
Jimmy Ray Purser
Trivia File Transfer Protocol
James Brown's wife tried to get her traffic tickets dismissed because of "diplomatic immunity" in June of 1988. She claimed her husband is the official "ambassador of soul". She lost the case
Jimmy Ray Purser is the technical co-host for Cisco's TechWise and BizWise TV. Jimmy Ray also conducts advanced training for engineers across North America and Europe and regularly speaks at industry conferences such as VON, CeBIT, N+I, and Networkers. As a field engineer, Jimmy Ray experiences networking first hand behind the console or in the rack. He is an active member in the IEEE and the Ethernet Alliance and has designed, installed and tested numerous networks for Fortune 500 companies, the United States military and other institutions worldwide. He holds 3 U.S. patents for Ethernet security algorithms with two others pending and one defensive publication, as well as numerous other vendor certifications in networking and security.
Purser holds a Bachelor of Science degree in electrical engineering from Southern Illinois University is currently pursuing a master of science degree in electrical engineering.
The Leader in Network Knowledge
minor correction
I've preferred PSAD for years on RH-based boxes. A minor correction, however: PSAD was written by Jay Beale, at least originally.
Reply
Is that right? Thank you for the correction and my apologies to Jay Beale. I though Jay coded up Bastille and Michael Rash and Peter Watkins wrote NIDS for Bastille, then Michael split off to go solo with PSAD as a stand alone?
Thank you for the correction
Jimmy Ray
Re: minor correction
Hi -
I collaborated with Jay on Bastille Linux, but the Bastille-NIDS project (the precursor to psad) was started and developed by me. Jay wrote the Bastille architecture, and Bastille-NIDS was developed to fit within this architecture. Jim, thanks for a great article.
Michael Rash
http://www.cipherdyne.org/
Reply to Michael Rash
The creator!!! I feel like Ve-ger from Star Trek One! Michael, thank you for the correction and first hand account here. And certainly thank you for such a smokin' awesome tool and book
Respectfully
Jimmy Ray
using FWSNORT
Another useful security tool from the PSAD community is FWSNORT (http://www.cipherdyne.org/fwsnort/) that use Netfilter string matching capability to translating Snort IDS attack signatures to what iptables can detect in application layer and make your linux firewall as an NIPS with little impact on traffic throughput.it can translate almost 60% of snort rules to iptables rule set.the netfilter string matching capability is very similar to Cisco FPM (Flexiable Packet Matching) that is the new generation of ACL.
Reply to Ali
Thank you Ali for the great tip and call out to another great security tool! I am a huge fan a FPM and it is always great to get another option that is open source and not so localized. FWSnort is a smokin' awesome feature set that can even be paired up with PSAD. By the way FWSnort also has a few sections in the book I mentioned in the blog; "Linux Firewalls"
Jimmy Ray
Addational info
both "Netfilter String Matching" and "FPM" has great functionality to filtering packets at the application layer.i work with both of them and theses are pros and cons for both :
[Linux Netfilter String matching]
Pros :
1- supported nativly on linux kernel > 2.6.14
2- very low performace penalty regarding to the Netfilter handel packet on kernel space (kernel app are more faster than user land app).my Linux firewall with 800 FWSNORT enabled rules on a server with [2 X cpu intel Xeon 2.4 / 1GB RAM] and 10Mbps traffic rate , the CPU usage was 40 percent.
3- can search the entire packet payload and any offset.
4- both ASCII and HEX value
5- it is FREE and supported with open-source community.
Cons :
1- regarding to "Netfilter String Matching" shortcoming that is Case-Sensitive for string to matched , someone can bypass your rules.as i know there is a patch for linux kernel to overcome the problem , but it is not on the official linux kernel tree.
2- the FWSNORT can only translate 60% of Snort rules to what you can filter via "Netfilter String Matching" .this is regarding that Snort 2.8.x use PCRE (a powerful Perl module for regexp) while still there are some limitation with "Netfilter String Matching" linux kernel features.
3- the "Netfilter String Matching" is not stateful.so FWSNORT can't detect complexed attack or attacks that attack payloads fragmented on multiple packets (that is why i prefer to block any fragment packet on the Internt edge).
Example:
as you know in the midde of 2008 , there was mass SQL-Injection attack (i am not sure , but i think the attack driven by BotNet) poor wrriten ASP aaplication and inject I-Frame to the vulnerable web site.i filter the "DECALRE%20" (SQL statement the you should never see in your http traffic, if you see there are SQL Injection) via the "Netfilter String Matching" as follow :
iptables -A FORWARD -p tcp --dport 80 \
-m string --string "DECLARE%20" --algo bm -j DROP
Cico FPM
Pros :
1- make your router as a powerful NIPS when you encounter an attack that is Zero-Day and no IPS signature offered by vendor.Cisco has a great docs and example on it's website.
2- unlike linux "Netfilter String Matching" , FPM is Case-insensitive.
3- unlike NBAR that is stateful and have impact on Router CPU , FPM like "Netfilter String Matching" is stateless.
4- you need at least Cisco-IOS 124.15T8 for FPM to work.
5- i lo
Cons :
1- as i remeber it can search up to 500 byte of the packet payload.
2- the Cisco MQC language is complex to build such rules with DPI and there is no GUI tool like "Cisco Configuration Professional" to support that features.
3- there is no real measurement about the FPM performance (this is also true regarding Netfilter String Matching).but i think it can't be enabled on high-speed interface while the Cisco-Sup-32 PISA that support NBAR/FPM on Hardware with max 2Gbps throughput.
Example : like the previous example but use FPM as tool
class-map type stack match-all ip_tcp
match field IP protocol eq 6 next TCP
class-map type access-control match-all SQL_INJECTION_1
match start TCP payload-start offset 20 size 10 regex "DECLARE%20"
Match field TCP dest-port eq 80
!
policy-map type access-control SQL_ATTACK
class SQL_INJECTION_1
drop
log
!
policy-map type access-control FPM-SL
class ip_tcp
service-policy SQL_ATTACK
i am a big fan of your blog because you blog about any things , from Cisco to linux , from Navy Seal civilian course (you last blog) to your TechVise-TV .
thank jimmy.
Reply to Ali
Thank you Ali for this great detail and information!! This is really good stuff!!
Jimmy Ray
>>PSAD is wrote in Perl with
>>PSAD is wrote in Perl with some C as well.<<
written, not wrote.
Post new comment