Monday, March 30, 2009

TechNet Subscriptions

So over this past weekend, I wanted to do some testing with netcat on a variety of Microsoft OS platforms, but since I don't have a license for W2K3, W2K8, etc... I was unable to complete what I set out to do. So this got me started on looking at TechNet subscriptions. I think the price is reasonable - whether a "Microsoft TechNet Plus Direct Subscription" or "
Microsoft TechNet Plus Single User Subscription" is purchased. If you have the bandwidth and the patience (to wait for the downloads), the Direct subscription might be best. After searching for coupons/discounts online, I was able to get the Single User Subscription down below 500 bucks. I think I will be purchasing this in the next couple of weeks, but for those who may already be subscribers, or previously were, what is your overall opinion of a TechNet subscription? I'm looking for feedback regarding any pluses and minuses from the experience. Seems to be quite reasonable to me, but I'm looking for more insight prior to making a purchase.


Tuesday, March 17, 2009

SSL Man-in-the-Middle "sslstrip"

Last night, I decided to take a break from some of my other studies, and spent some of my time perusing through some of the Black Hat DC 2009 presentations. Black Hat has consistently done a superb job of getting great speakers who present on new "cutting edge" content (Dan Kaminsky on DNS Cache Poisoning), or show us geeks better ways we might be able to more efficiently do something with the tools we currently have. It appears that this conference was no exception.

One of the presentations that specifically caught my attention was, "New Techniques for Defeating SSL/TLS", by Moxie Marlinspike. The tool he created 'sslstrip' is able to perform some 'EVIL' tasks - if in the hands of the wrong person. The author states, "This tool provides a demonstration of the HTTPS stripping attacks that I presented at Black Hat DC 2009. It will transparently hijack HTTP traffic on a network, watch for HTTPS links and redirects, then map those links into either look-alike HTTP links or homograph-similar HTTPS links. It also supports modes for supplying a favicon which looks like a lock icon, selective logging, and session denial. "

So, I did some testing with sslstrip this evening, and was quite excited by the results! What did I find? Well, for every site I went to on the 'attacked' machine, sslstrip was able to obtain passwords for "ALL" of the protected sites I visited (from my testing, this included: Yahoo, Cisco, Juniper, Gmail, Myspace, LinkedIn, some various banking sites, etc...I think you get the picture here)!!! There were no browser errors on the client, no special files to configure on the attacking machine; it worked great. I haven't done an in depth analysis of all the bits and pieces to sslstrip, but I'd have to say based on the little use I have had with it, the tool kicks @55!

Now there are other tools that are similar out there, ettercap in combination with a few other tools was the first to come to mind for me, but I haven't worked with one that made it this easy to obtain 'private' credentials. Everything is very well documented in the python script, and the README contains all the information you require to get started. Rather than make this a long drawn out post/tutorial, I figured I would leave the reader with something to play with themselves - and if you have any questions, please post to the blog.

Now as far as caveats, it does require that the attacker have local network access in order to perform the attack. This brings to mind a few things though, specifically in our mobile world - what is local access:

1. Is the wireless your connected on secure/trusted? (think of Starbucks, or your other favorite 'hot spot' that might be outside the network/security administrators control)
2. Do you browse financial or other 'important' sites from your local library or some other public location?

I just wanted to toss a few ideas out there for the reader, since we aren't necessarily talking about our Local Area Network (LAN) when I state local network access. This access can be obtained remotely from many vectors, like the couple I mentioned.

Once I got this tool working - which took no time - I started to think of all the other devious ways you could use this tool (leveraging with other proxies, Karma, etc...). I'm not going to elaborate anymore (sure some of you with a bright imagination can conjure up a bunch of ways to use it too), but it does make a person think about the security, or lack there of, in the technologies that we use today. I've argued the side of IPSec vs SSL for a long time, and don't want to start that here again, plus I think there definitely are applications where SSL is more feasible than IPSec, and vice versa. What I want to do is make people aware, whether it is the reader here or my employer, that if your using some type of technology and you think it is the most secure technology around and the best thing since sliced bread, there are some pretty good chances that it isn't! Hat's off to researchers like Moxie who are publishing tools like this, which help to further the security community as a whole!

More Information:

Website and Tool:

Black Hat Presentation (PDF) "New Techniques for Defeating SSL/TLS":



Saturday, March 14, 2009

iptables Tutorial

iptables Tutorial

This brief tutorial is meant to assist those unfamiliar or just getting started with iptables. All facets of iptables will not be covered, and for those looking for more information on the topic, please refer to the references I've included at the end of this article for further assistance. Specific items I will cover are:

1. Overview of what iptables is, and the components of the program.
2. What are 'Tables'?
3. Enabling the Firewall and clearing the old rules
4. Creating custom chains for logging
5. Getting started and defining a restrictive 'filter' table chain for the INPUT and OUTPUT chains.
6. Viewing and manipulating rules
7. Summary

Let's get started!

1. Overview of what iptables is, and the components of the program.
So what is netfilter and iptables? I'll use the explanation provided by Michael and Scott Shinn from their book "Troubleshooting Linux Firewalls", "netfilter comprises the kernel level code that Linux can use to conduct packet filtering, state management, NAT, packet mangling, QOS, and other neat tricks. iptables is the userland tool that can manipulate these kernel hooks to do these things." In essence, we use iptables to create and manage our firewall ruleset. Let's now look at what makes iptables.

2. What are 'tables' and 'chains' for?
iptables consists of 4 different tables (see below). Each table is used to control different functions for your iptables firewall. In some instances you will use more than one of the tables (for example, when your firewall is configured as the gateway device for which all network traffic will traverse), but for a single host performing basic filtering, the only table required is the filter table.

4 Tables that make up iptables:

Within each table you have various chains which you can use to define access for. The filter table consists of 3 chains by default. Each of the filter chains are used for different purposes. For traffic passing through your firewall, say you have a multihomed firewall/server, you would define what is allowed to pass in the FORWARD chain. Since we will be creating a personal firewall, which consists of only one Network Interface Card (NIC), we will be utilizing only the INPUT and OUTPUT chains. These will define access allowed to our machine (DHCP Offer or ping requests for instance) and traffic leaving our machine (DNS lookups or Web Browsing) respectively.

Default chains for the filter table:
FORWARD : This is for traffic which will traverse your firewall. We will not be using this chain, since our firewall will not be a gateway.
INPUT : For traffic destined to the firewall. This would be used to define access rights for allowing administrators to use SSH to connect to the firewall.
OUTPUT : For traffic leaving the firewall. If this machine is your personal computer, you might want to allow http traffic outbound in this chain.

Next are targets, which triggers an action when a packet matches the rule. Targets are preceded by '-j' which tells the rule to jump to a specific chain or target. For this you could have it point to a custom chain, or one of the targets below.

Target actions which will be present in our rules:
ACCEPT - Allows the traffic matched by the rule
DROP - Traffic is dropped and no further processing is performed
LOG - Logs a packet to syslog, and the rules continue to be processed

As for all the other options available, I will discuss them when we proceed further to building our actual ruleset. I would like for those who have never worked with iptables before, to read the 'NOTE' I have posted after this paragraph. Since we will be configuring the firewall for stateful operation, instead of basic packet filtering, it is important that the connection tracking module be loaded in the kernel. If it isn't, please utilize the references I provided in order to install and enable the necessary modules.


Like I mentioned earlier, this tutorial assumes you have iptables installed already, and that the connection tracking module (provides the ability to perform stateful filtering) is loaded. For this tutorial, I am using Fedora 9, and didn't have to make any special changes or tweaks to the kernel, in order to add stateful filtering. For a much more exhaustive look into this, look at the references below for more information (you will want to keep this in mind if you ever configure your firewall as a passthrough device and want to utilize ftp, since ftp has its own separate module - which was not loaded for me by default). You can verify whether the module is loaded with the command below. I also included output concerning my kernel version below:

Validate whether the connection tracking module is currently loaded, in order to allow stateful filtering:

lsmod |grep nf_conntrack
nf_conntrack_ipv4 11528 3
nf_conntrack_ipv6 15864 3
nf_conntrack 51424 3 nf_conntrack_ipv4,nf_conntrack_ipv6,xt_state
ipv6 230260 20 ip6t_REJECT,nf_conntrack_ipv6

Verify Kernel Version:
uname -r

3. Enabling the Firewall and clearing the old rules
Getting started, we will want to ensure that iptables is running. If it's not, we will go aheaad and enable iptables for runlevels 3,4,5 and then start the service.

In order to validate what runlevels iptables is configured to run at:
chkconfig --list iptables

Now to enable iptables for runlevels 3,4,5, if it is not already:
chkconfig --levels 345 iptables on

Start the iptables service, if not done so already:
service iptables start

Most firewalls, by default, allow all traffic to exit the firewall, instead of a default deny - which is considered much more secure. We will be altering the INPUT and OUTPUT chains for our filter table, so that by default all traffic is dropped. We will then proceed to allow only the services (protocol and port combination - or well know services like ssh which use tcp port 22 by default) which we require to do our jobs. This will leave us in a much more secure posture. Let's begin by setting the default behavior for our chains.

Set the default behavior of the INPUT and OUTPUT chain to drop traffic:
iptables -P INPUT DROP
iptables -P OUTPUT DROP

Next we will flush all the rules currently pre-defined for our chains. You may want to list, and/or save the contents first, and I provided the command which will allow you to do this as well.

List all current rules contained in the chains ('-L' lists the rules, '-n' provides the port numbers, instead of just the named service as contained in '/etc/services' and '--line-numbers' will display the actual number of the rules):
iptables -L -n --line-numbers

Save the current rules (I added a date here, and you can add this or something else in order to help you remember when you last backed it up):
iptables-save > old.rules.saved.03142009

The command below will flush '-F' all rules you currently have defined:
iptables -F

Now you can save your work:

For those who want to save the current ruleset, and make it persistent across a reboot, use the following:
service iptables save

We will we doing this throughout this paper, in order to ensure that our changes are saved, in case your machine is inadvertantely rebooted while we're working on our ruleset.

4. Creating custom chains for logging
Let's create 2 new custom chains in order to alleviate the headache of having to create 2 separate rules for logging and accepting/dropping traffic. What I am providing is a bare minimum, as there are many more options available for these custom chains. For those looking for more information on this, use the resources listed below!

Looking at the example provided below, the '-N' option is used to create a new user defined chain. The names I gave for these chains are 'LOGDROP' and 'LOGACCEPT'. After defining the new chain name, we use the append '-A' statement to add a rule to the LOGDROP and LOGACCEPT chains, set an action '-j' to LOG the traffic, and add a label to the log entry with '--log-prefix'. So when we receive traffic that matches our LOGDROP and LOGACCEPT rules, we will see the prefix of LOGDROP and LOGACCEPT in our logs.

Creating a new LOG and DROP Chain:

iptables -N LOGDROP
iptables -A LOGDROP -j LOG --log-prefix "LOGDROP: "
iptables -A LOGDROP -j DROP

iptables -N LOGACCEPT
iptables -A LOGACCEPT -j LOG --log-prefix "LOGACCEPT: "

You can elaborate on much of this, by creating custom chains in order to group similar rules to be processed by iptables, as well as to specify different tags to be given to log entries. I highly recommend doing this if you'll be in charge of managing a large ruleset, as it does make management of your firewall much easier, and log search times can be dramatically reduced.

5. Defining a restrictive 'filter' table chain for the INPUT and OUTPUT chains.
First we will have to determine what traffic we will want to allow/deny to and from our firewall. If your developing this for a corporate environment, you may want to create a procedure for this and put a policy in place that states something to the point that if someone in your corporate environment is using a Linux Desktop, they must have a restrictive local firewall policy configured. To go further with this, you could even send all of this log data to a centralized syslog server, which would help in log correlation - say in the event of a virus outbreak.

So for me, I'm going to define a restrictive ruleset (yes, I know, I can be much more restrictive in nature if I wanted to) for both incoming and outgoing traffic. If you know the IP addresses of your DNS and DHCP servers, add them to the rules. Since the machine I am configuring is used while I travel, many of these addresses change with each location, so I chose to be liberal in what I defined as source/destination addresses.

For Loopback interface traffic, we will allow everything, and this will be added to the INPUT and OUTPUT chains.
Incoming services we want to allow: DHCP (UDP68), SSH, icmp echo-requests
Outgoing services we want to allow: DHCP (UDP67), SSH, icmp echo-requests, http, https, dns

Rules for the INPUT Chain:

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state INVALID -j LOG --log-prefix "DROP INVALID: " --log-ip-options --log-tcp-options
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A INPUT -p udp --dport 68 -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 22 --syn -m state --state NEW -j LOGACCEPT
iptables -A INPUT -j LOGDROP

NOTE: So what did we just do here? Let me discuss some of this.
Rule 1: The first rule states that we want to append '-A' to our INPUT chain a rule which allows all traffic to our loopback interface.
Rule 2 & 3: The second rule specifies that if we receive a packet which is invalid, an example of this is receiving an initial packet with the FIN flag set (such as an nmap FIN scan '-sF') iptables will log it (as well as record the tcp and ip options) and drop the traffic - as specified in the 3rd rule.
Rule 4: The fourth rule is defined to allow already established connections and those related to another connection (an example of a related connection would be ftp which uses both ports 21 and 20).
Rule 5: This rule is defined to allow icmp requests to our machine
Rule 6: Rule 6 allows our client to receive a reply from the DHCP server. We will receive a DHCP Offer and Acknowledgement on UDP port 68.
Rule 7: Rule 7 allows incoming ssh, or port 22, connections and logs '-j LOGACCEPT' the connection for us as well.
Rule 8: Lastly we have a rule which jumps '-j' to our customly created chain 'LOGDROP', which effectively logs the connection and drops it.

Something to keep in mind on the last rule, and our custom chain in general, is that you may want to set connection limits/threshholds for it, or possibly not log at all on dropped packets. We have specified that all dropped packets be logged, which - depending on how much disk space you have available - can eat up a lot of disk space. If for instance, you have an attacker on your network and they know your logging all dropped packets, they could essentially target your machines, and try to perform a DoS by filling up your disk space. I wanted to state this so the reader is aware of potential drawbacks to logging all dropped traffic.

Rules for the OUTPUT Chain:

iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -m state --state INVALID -j LOG --log-prefix "DROP INVALID: " --log-ip-options --log-tcp-options
iptables -A OUTPUT -m state --state INVALID -j DROP
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p udp --dport 67 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 22 --syn -m state --state NEW -j LOGACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A OUTPUT -p tcp -m multiport --dports 80,443 --syn -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 --syn -m state --state NEW -j ACCEPT
iptables -A OUTPUT -j LOGDROP

NOTE: Here we have defined the OUPUT chain for our iptables firewall. This is to govern all traffic that leaves our local machine. Please refer to the NOTE above for an explanation on the 1st 4 rules.
Rule 5: Since DHCP servers listen on UDP 67 for client connections, rule 5 was defined to allow this connectivity. UDP 67 is used for DHCP DISCOVER and REQUEST operations.
Rule 6: In rule 6, we are allowing outgoing SSH connections from our client, since we frequently connect to other *nix devices from our workstation.
Rule 7: Allows outgoing ping's from our machine.
Rule 8: Here we allow connectivity to the web for http and https services.
Rule 9: This allows normal dns queries out from our machine in order to resolve names. By default DNS uses UDP.
Rule 10: This is defined to not only allow zone transfers (which uses TCP), but also if our DNS server receives a query over 512 bytes in size, the server will ask our machine to resend the request over TCP.
Rule 11: Lastly we have a rule which jumps '-j' to our customly created chain 'LOGDROP', which effectively logs the connection and drops it.

Now that we have a functional and more secure local firewall defined, save the configuration once more and we're done!

Save the Configuration:
service iptables save

6. Viewing and manipulating rules
Now that we're done creating our ruleset, I'd like to cover some other options that are available for viewing and manipulating the rules. At some time or another you will need to make changes to your current ruleset by adding, changing or deleting rules, and these commands should come in handy.

#'L'ist all iptables rules without resolving '-n' the service names, while printing #the line numbers '--line-numbers'. This can be helpful when trying to determine #what rules to replace, or where to insert new rules in the ruleset.
iptables -L -n --line-numbers

#'A'ppend a new rule to your ruleset. This will add a new rule to the bottom of your #ruleset.

#This will 'I'nsert a new rule into position '5' in the INPUT chain in our ruleset.

#This will 'R'eplace the 5th rule in the INPUT chain. You might do this if you want #to make a change to a rule, such as adding a log prefix.

#Add a 'N'ew chain, like we did earlier for the LOGDROP and LOGACCEPT chains.

#'Z'ero the packet and byte counters for a selected chain

#'F'lush, which deletes all the chains, or a specific chain if you specify it.

#Print all rules in the selected chain. If no chain is selected, all chains are #printed like iptables-save.

#Much more information is contained in the 'man' pages than what I've covered thus #far! For additional questions, consult it!
man iptables

7. Summary

There has been a lot covered in this 'brief' tutorial! My goal was to provide an entry level overview of iptables. I covered how to create a ruleset for a local firewall, with some details on how to manipulate the ruleset. The references I provided below contain much more information than what I wrote about, so for those looking for methods to use for more complex environments, I strongly suggest buying one of the books below, and taking a look at the online references - which are free! If there any questions in relation to this content, please let us know!

Mike Rash - No Starch Press - 2007 - "Linux Firewalls"
Michael and Scott Shinn - Addison Wesley - 2005 - "Troubleshooting Linux Firewalls"
Gregor Purdy - O'Reilly Media - August 2004 - "Linux iptables Pocket Reference"



iptables -F
iptables -N LOGDROP
iptables -A LOGDROP -j LOG --log-prefix "LOGDROP: "
iptables -A LOGDROP -j DROP
iptables -N LOGACCEPT
iptables -A LOGACCEPT -j LOG --log-prefix "LOGACCEPT: "
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state INVALID -j LOG --log-prefix "DROP INVALID" --log-ip-options --log-tcp-options
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A INPUT -p udp --dport 68 -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 22 --syn -m state --state NEW -j LOGACCEPT
iptables -A INPUT -j LOGDROP
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -m state --state INVALID -j LOG --log-prefix "DROP INVALID" --log-ip-options --log-tcp-options
iptables -A OUTPUT -m state --state INVALID -j DROP
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p udp --dport 67 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 22 --syn -m state --state NEW -j LOGACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A OUTPUT -p tcp -m multiport --dports 80,443 --syn -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 --syn -m state --state NEW -j ACCEPT
iptables -A OUTPUT -j LOGDROP
iptables service save



Tuesday, March 10, 2009

Secure Connectivity from Hostile/Untrusted Networks

Some of my friends and I were discussing how we 'securely' connect to the Internet, in particular our banking sites or email accounts, while at security events or in other venues where malicious users might reside. I use the word 'securely' loosely here since my viewpoint is that even though you might go through great effort to ensure your methods of connectivity are secure and impervious to eavesdroppers, I simply think this is pretty close to impossible unless you have a machine which is entirely disconnected from the world, and is pretty much of no use because of this. Some machines and networks fit this bill - as far as being pretty much 'disconnected' - think of some of the governments SCADA networks, but for the most part, this isn't the modus operandi for a typical user.

The following is a list of some of the methods that we use to connect. Some might be considered better then others.

Best Methods In My Opinion:

Wireless Broadband
Local Proxying of all traffic to a remote destination - via SSH tunnel
Using an IPSec and/or SSL VPN solution - to connect to the home office, or the business

Bad Method which many people use (again, this is in my opnion):

Using the Hotel's Network (you can add, or substitute free wi-fi network as well, which can be used at the airport or your local Starbucks) to connect directly to your banking sites

Now to be honest, I've pretty much used all these methods at some time or another - less wireless broadband (although I have been looking into this service for some time) - to phone home, or connect to my banking site while on the road. As time has progressed, I've evolved in respect to using more secure methods to make these connections. So your asking, what do I currently use, well right now I am using NoMachine (NX) <>. I'll go over some of the cool features that NX offers, as well as what I have setup in particular in my work environment to enable this secure connectivity.

NX allows a client to run a SSH tunneled X11 session to the NX server. NX uses SSH public-key encryption and 128 bit volatile random cookie generation for the secure connection (Reference: The NX architecture consists of 3 different components:

1. NX Server (This is the machine you will be connecting to in order to launch specific applications from, or to just browse the web securely from.)
2. NX Node (This package needs to be installed on the server)
3. NX Client (This is the client software that needs to be installed on the machine you will be connecting from.)

The free edition allows you to have 2 users concurrently connected to your server. This is sufficient for my needs, but may not suit yours. NX does offer 'for pay' services which can allow an organization to increase the number of users which are allowed to concurrently connect to a server, see the following for more information: For those looking for more information on the technology, I strongly encourage you to read the documentation they provide on the site. I'm not going to delve into all the specifics, but will give the reader a very general overview of how I use it when I am on the road.

My NX Server at home is running CentOS 5.2 ( The NX Client software was installed on a Windows XP and Linux (Fedora 10) based host - I brought a dual-boot system to the conference. On the server, I changed the port SSH was listening on (via the sshd.conf file) to 45220 (you can continue to use the default port, but I choose to use a port that in my experience I have not seen scanned by script kiddies as often as the popular well known ports [1024 and below]). Both local client firewalls were configured with rules to only allow dhcp traffic (UDP 67 and 68), limited web traffic (TCP 80/443), as well as dns (UDP/TCP 53), in order to connect to the hotels portal page, and lastly I had a rule which allowed connectivity to my remote firewall, which forwarded the TCP45220 traffic to my NX server. Since I have currently been fiddling with a Juniper SSG5 at home, I had this on the perimeter with a dedicated DMZ configured where the NX server sits. I've included a little visio document of how this layout looks:

Network Diagram:

Closing Notes:

There are a few different methods available that someone can use, if they want to 'securely' connect to resources that are considered sensitive in nature. I've been at conferences where many of the folks I've spoken with are using their regular corporate laptop in class for the labs. Of course, I am strongly against this (data loss comes to mind here), and would beseech each of you to talk to your own corporate resources in order to get a lab laptop for class, or better yet, buy your own cheap laptop online - easily can find a used one for under 400 bucks. Upon receiving the laptop, image it, launch your packet capture tool when you connect on the hostile network, save the captures to a portable thumb drive, and re-image it when you get home. I know there are other methods available, and I welcome feedback on this, so please send us any comments, and/or questions you may have regarding this.

Hope you enjoyed...

Topics for follow up: IPTables configuration on Linux Machines.


Monday, March 9, 2009

SANS Orlando 2009

I just got back from the SANS event in Orlando, and it was another great conference they put on. My brain still hurts from the firehose of information that I received, of which I will spend the next few weeks reading, and re-reading, in order to drive the concepts home. Where I am currently employed, we already have an established Project Management Office, and a Change Control/Request process in place. This being said, there are still many areas that can be improved, and my hope is to be able to take what I learned in class and use it to improve some of our current processes that we have in place.

Aside from the project management course, for which Jeff Frisk did a stellar job providing examples in class, and made the material enjoyable to read - which very easily could have been uber dry and tough to get through - the evening sessions were great! Two of the sessions, "The Enemy Within - Detecting Suspicious Network Traffic via Security Visualization Techniques" and, "Wireless Intrusion Detection Tactics - Hands-On Workshop" were a lot of fun. This was more up my alley of interest, since it was technical hands-on material, instead of sitting while listening to a lecture.

The Enemy Within - Detecting Suspicious Network Traffic via Security Visualization Techniques, evening session consisted of performing labs with DAVIX "". Andy Patrick was the presenter and he provided an overview of various tools (Afterglow, Graphviz, GnuPlot, Inetvis, Ntop, Parvis, RadialNet, Rumint, etc...) that are used for visualization, and then we dug into performing some labs. I found this session very interesting since these tools allow a security administrator to 'see' the port scans and malicious network entities, in a different light. Although this will not eliminate the need to analyze packet captures, it can greatly assist an admin in identifying what might need to be more closely looked at in your network.

Applied Security Visualization by Raffael Marty (
Security Data Visualization by Greg Conti (

Wireless Intrusion Detection Tactics - Hands-On Workshop, was pretty cool, and attendees left with a new Linksys WRT54GL AP flashed with OpenWRT, and ready for use at home/work as a Wireless Intrusion Detection Scanner (WIDS). In brief, we flashed a WRT54GL Wireless router with OpenWRT and configured it to act as a WIDS in class (running Kismet). The purpose of having a WIDS is to detect various wireless network attacks (NetStumbler or WEP Cracking taking place), as well as wireless client attacks (KARMA or Client Driver attacks). Paul mentioned how he would also use his at work to help identify client connectivity problems.
Much of what was covered in the class is also covered in the book. For anyone interested in this topic, check out the resources below...or drop a note on our blog, and we'll get back to you!

Linksys WRT54G Ultimate Hacking by Paul Asadoorian; Larry Pesce (Author)
Their Site:
OpenWRT Website:

Overall, this conference was a great time. Due to the way some of the presentations were arranged, I didn't get to attend many of the other talks that were taking place, since there was a lot of overlap in the evenings. I may volunteer for a conference later this year, but I will have to see what's going on in life, before I apply for something like that again.

As always, let us know if you have any comments or questions regarding the post.