Logical Foundations

Even though I want to dive right in to posting Deontic proofs and proposing dialogues on the differences between s4, s5, and M logical systems, I figured I should lay some groundwork. I didn't want to direct you to just a Wikipedia article to lay the groundwork as the articles tend to go off on tangents at a rapid pace, although I will occasionally reference some articles for odd bits.

Below is a set of operators:

v - Disjunction (or)
& - Conjunction (and)
¬ or ~ - Negation (not)
→ - Conditional (implication)
↔ - Bi-conditional (Equivalence)

Some less common operators:

↓ - Pierce Arrow - A↓B = ~(AvB)
↑ or | - Sheffer Stroke - A↑B = ~(A&B)

Parenthesis are used where order of precedence in applying operators may need to be modified for the current statement, or in cases where the author of the statement may just want to make their case more clear. Precedence will be discussed later.

A common way to discuss the validity of certain statements is with a truth table. Below is an example of such a table.

While I believe that truth tables are useful in demonstrating the differences between tautologies and contingent truths to intro students, I feel it is best to breeze straight past them and on to Semantic Tableaux in the next issue.

Scope Creep

After much deliberation, I have decided to expand the topics covered in this blog to include Security, Networking, Culinary Creations, and Logical Proofs. The reason for the scope creep is that there is already a veritable morass of avenues to get the latest news on Security, however I figure I can blog about all of my interests and not feel like I am merely regurgitating ideas that are already out there.

Hogger

I just put up my new FOSS, Hogger, on google code. While it's still in beta, I think the functionality lent itself to distribution before I finished the intended feature set. Last week while I was at Snort IDS/IPS + Rules Writing class from Sourcefire, I found out that pretty much the best way to make a giant leap towards tuning a Snort installation is tuning the pre-processors (namely frag3 and stream5); since natively an IDS doesn't know how each host will reassemble fragmented packets or reassemble streams, they usually are set to some default -- not that good if you want reliable results. The long way of tuning this is adding an entry for each host or group of hosts in your config file -- not really appealing to me -- the other option was write an XML file detailing the attributes of all of your hosts -- also not that appealing, as who likes writing XML?

So, with a little inspiration from the instructor I set out to write Hogger, which currently takes the output file from an nmap scan and parses it for host information, and then creates a Host Attribute Table in XML format for Snort to read.

Now to be able to use the Host Attribute table, you need to have Snort compiled with –enable-targetbased. Once that is done, just add the line attribute_table filename /path/to/file to your snort.conf file.
Word of caution here, is that filename actually has to be present, do not substitute this for the name of your file.

And if you don't believe me that the Host Attribute Table will completely rock your socks off, check out Joel Esler's post at Computer World.

Network Magic & Linksys Easylink Advisor vs IDS

So a few weeks back, I was asked to investigate a possible SYN flood attack on the VPN segment. SYN flood, really? Well, packet capture after packet capture indicated multiple users on the VPN segment sending, sure enough, SYN packets through the VPN to other machines on the VPN -- pretty odd, why would an end machine try to communicate with other end machines on a VPN connection? Sounds suspicious right? Why and how would vpn clients be allowed to talk to each other in the first place? Well I don't agree with it, but hairpinning is the culprit, and after requests to turn it off were denied, I needed to find another way to halt the activity. Well that's when I decided to tap that connection and listen in on the VPN segment with my Snort box. For a while I didn't get any alerts, then I started getting packets that look like the one below:

GET / HTTP/1.0..

Authorization: Basic YmFkY3JlZDpoaW1vbQo=
..User-Agent: Mozilla/4.0 (compatible;MSIE 5.5; Win32)
..Host: 172.29.136.250
..Connection: Keep-Alive....

Well, Base64 encoding isn't exactly used in my usual packets... so this was a bit odd:

Basic YmFkY3JlZDpoaW1vbQo=..

Decoding it:

:badcred:himom:

That's curious. What's more curious is that every host that was exhibiting the SYN scanning behavior was passing these credentials as well in an intermittent port 80 packet. It turns out that this behavior was programmed into Pure Network's Network Magic product designed years ago. Then Cisco bought them, and it became Cisco's Network Magic. Well, it turns out that the very same behavior is exhibited by Linksys Easylink Advisor (LELA), and all new Linksys Routers come with the software. Now, mind you LELA is a great tool for people that don't know how to setup a network, but when it's on a computer that connects to a corporate network via VPN, your ASA will go nuts with SYN flood alerts and your IDS will cough up alerts as well for suspicious activity. Lesson learned.

Windows 7 on Macbook

So I finally went ahead and installed Windows 7, and I have only run into one problem. The audio drivers from Boot Camp for my macbook don’t work. The optical audio light is constantly on, and I get no audio out of the speakers. It appears that this is a pretty widespread problem, but takes some looking around to find the right driver, and if you go to the manufacture’s site, it may take you a very long time to download. Go to http://www.mechainfo.com/centralgadgetdotcom/wp-content/uploads/2009/01/Vista_R208.exe for the 25 MB download and all your problems will be solved.

Sniffing SSL Traffic with your IDS

As far as evading IDS/IPS/Network Forensic Analysis, the days of using techniques outlined in the 1998 Ptacek and Newsham paper aren’t exactly dead, but Snort addresses these techniques in its Frag3 and Stream5 preprocessors. These days however, the easiest way to evade any network-based IDS or IPS is to fire up an SSL tunnel and enjoy the wonderful shield of data encryption. That is, unless your security team is packing some serious gear to handle the decryption on the fly at line speed. At a Snort Conference, I checked out the Netronome SSL Inspector™ Transparent SSL Proxy, and wow does it do the job.

You have two options with The Transparent SSL Proxy:

1. Run off of a tap – copy your server’s certificates and private keys over to the Transparent Proxy so that it can decrypt your SSL traffic. *NOTE* You will only be able to decrypt traffic that you have certificates for.
2. Run in-line – The Transparent Proxy will terminate the SSL traffic and resign with it’s own certificate. Distribute this certificate to all of your corporate machines as a trusted CA, and this will remain transparent to the user community. If you have any smart policy violators that are using SSL to bypass your IDS, they will probably notice that they have been man-in-the-middled, but at that point you have all of the relevant data. Additionally,with the in-line any SSL encrypted traffic coming from bots on your network or other malicious traffic, you can now analyze with your security devices.

Excellent, I have been looking for this for a long time, but how efficient is it I asked? The accelerator card has 4 1 Gbps ethernet interfaces that it can sniff at, and it can handle a sustained rate of 1 Gbps of SSL traffic with a latency of less than 40 ns. Pretty impressive. Sign me up!

On a side-note, when I asked about what else their accelerator cards can do, they said that due to direct user-space memory access along with 6 cores on the NIC, they have been able to hit the 10 Gbps mark for throughput. Nice.

Managing Your Snort Signatures

I’m a huge fan of Snort, but in an enterprise deployment where you are managing multiple sensors, a back-end database, web front-end and possibly correlating with other Security tools like in OSSIM, managing your ruleset can get tedious at best. Enter PulledPork – like Oinkmaster it will keep your rules up to date, but making your life easier, you can manage which rules are disabled when it downloads your new ruleset.

Now there are two scenarios for your sensors in a distributed IDS:

1. Your sensors are running the same rules and looking for the same traffic –> run a daily cron job of pulledpork (pulledpork.pl -c pulledpork.conf -i disablesid.conf) on one server and rsync to the other sensors in your environment.
2. Your sensors have disparate rulesets –> use pulledpork to download all of your rules on your database server, and rsync to your sensors. Then run pulledpork on the sensors themselves, but only invoke the disablesid.conf (pulledpork.pl -i disablesid.conf) file to disable the sids you don’t want to use.

You still need to register with Snort and get yourself an Oinkcode — this is what lets you download the updated signatures. Once you have your Oinkcode, just place it in the config and unless you paid for a subscription you will want to change the following:

rule_file=snortrules-snapshot-2.8_s.tar.gz

to:

rule_file=snortrules-snapshot-2.8.tar.gz

All pretty easy, but now you don’t have to remember to update your signatures or touch each of your sensors when you do!