TaoSecurity Blog

I recently mentioned writings by Marcus Ranum on "deep packet inspection" and related topics. This morning while browsing the firewall-wizards list I read a profound post by MJR. Here is the most powerful part: "Basically, what's going on is that a lot of security practitioners are in the position of being asked to make something safe that is fundamentally dangerous. So we hide behind the notion of 'risk management' - basically the illusion that 'if we try hard to cover our butts it's less dangerous than otherwise.' What that has accomplished is to create an environment in which security has NO CHOICE but to compromise because senior execs know that if they don't get the answer they want out of one security practitioner, they can keep asking until they get the answer they want out of another... My feeling is that during the 90's we, as an industry, dug ourselves into a hole we're not going to be able to spend or risk manage our ...

I am writing like mad to meet a 1 June book delivery deadline for Addison-Wesley , so I won't be posting much or at all until I finish Extrusion Detection . I think crunching to meet deadlines is a common author predicament, after speaking with the other participants at the BSDCan book signing last week. Pictured with me, starting from my left, are Dru Lavigne, Greg Lehey, Marshall Kirk McKusick, and George Neville-Neil. Michael Lucas was not present for that photo but he appeared momentarily afterwards. Standing in the background is conference organizer extraordinaire Dan Langille. Thanks to Robert Bernier for posting the original photo.

Is anyone successfully running an inline deployment of Snort on FreeBSD? If so, please email me: richard at taosecurity dot com. This guide makes it look easy, but I've tried multiple variations (bridging, routing, etc.) with Snort 2.3.3 on FreeBSD 5.4 REL and nothing works completely. Thank you. Update: I got it working. snort-2.3.3.tar.gz doesn't work; snort_inline-2.3.0-RC1.tar.gz does. Who knew.

Thanks to Brandon Greenwood I learned that the current SANS ISC poll asks for your favorite Snort interface. Sguil is currently running third behind BASE and ACID . Visit SANS ISC and vote for Sguil!

I discovered a system running NetBSD 2.0 in my lab and decided to upgrade it to NetBSD 2.0.2 . I read that "this is also the first binary security/critical update since NetBSD 2.0." I found a thread which gave various forms of advice on updating to NetBSD 2.0.2 from 2.0. Here is what I did. When I started the system was running NetBSD 2.0. bash-2.05b# uname -a NetBSD juneau.taosecurity.com 2.0 NetBSD 2.0 (GENERIC) #0: Wed Dec 1 10:58:25 UTC 2004 builds@build:/big/builds/ab/netbsd-2-0-RELEASE/ i386/200411300000Z-obj/big/builds/ab/ netbsd-2-0-RELEASE/src/sys/arch/i386/compile/GENERIC i386 First I downloaded base.tgz, comp.tgz, kern-GENERIC.tgz, man.tgz, misc.tgz, and text.tgz into a directory I created called /usr/tmp. The FTP server directory listing shows what was available in total. juneau# ftp ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-2.0.2/i386/binary/sets/ Trying 204.152.190.13... Connected to ftp.netbsd.org. ...edited... ftp> ls 229 Entering Extended Passive ...

I asked security guru Marcus Ranum if he would mind commenting on using proxies as security devices. I will publish his thoughts in my new book Extrusion Detection , but he's allowed me to print those comments here and now. I find them very interesting. "The original idea behind proxies was to have something that interposed itself between the networks and acted as a single place to 'get it right' when it came to security. FTP-gw was the first proxy I wrote, so I dutifully started reading the RFC for FTP and gave up pretty quickly in horror. Reading the RFC, there was all kinds of kruft in there that I didn't want outsiders being able to run against my FTP server. So the first generation proxies were not simply an intermediary that did a 'sanity check' against application protocols, they deliberately limited the application protocols to a command subset that I felt was the minimum that could be done securely and still have the protocol work. For example, ...

I recently acquired several more specialized taps from Net Optics . I thought you might like to hear a few words about them. I plan to feature these and a few other devices in my new book Extrusion Detection , but why wait until then? I specifically requested evaluation units to meet monitoring and network access problems my clients brought to me. Perhaps you will find one or more of these products answer a monitoring question you've also been pondering. Keep in mind that I show Ethernet versions here, but a variety of optical products are offered. Also, I mention these products as they might be deployed at the perimeter, between a border router and firewall. They can certainly be used elsewhere, but for consistency here I stay with that deployment scenario. The first product I tried was the 10/100 Active Response Dual Port Aggregator Tap . The purpose of this device is to provide full duplex access to a network link to two sensor platforms. The two outputs on the left ...