The Author – Bart Busschots
Creative Commons
Unless otherwise stated, the content on this site is licensed under Creative Commons Attribution, Noncommercial, No Derivative Works 3.0 License
Mar
19
The Changing Face of Computer Security – Part 1
Filed Under Computers & Tech, Security on March 19, 2007 | Leave a Comment
Like just about everything in IT the computer security landscape is constantly changing. As the computer industry strengthens our defenses, and as old avenues of attack are closed off, the attackers change their strategies, targets and techniques. It’s a never-ending game of cat-and-mouse and the rules are always changing. However, there is one element that remains constant, uneducated and innocent users are always the prime target. Hence, the best defense is education, if you don’t understand the attacks you haven’t a hope of defending yourself. This is the first part of a two-part series to try to give people an introduction to this complex and dynamic field. Reading these articles won’t bring you even close to being an expert but they should give you a basic overview of the computer security landscape. In this first part we’ll have a look at what the bad guys are trying to do to your computer and why, as well as some of the simple things you can do to protect yourself. In the second part we’ll look in more detail at how your computer may be attacked and how I see the attacks evolving over the next few years.
Feb
19
JavaScript Home Router Attacks Happening for Real
Filed Under Computers & Tech, Security on February 19, 2007 | 4 Comments
In my rather long post on JavaScript security on the 15th I described a possible future scenario where JS could be used to attack home broadband routers. I was off sick last week so this morning I was catching up on some RSS feeds I subscribe to and was shocked to see the follow advisory issued on the 16th by US CERT:
In an announcement made yesterday, security researchers at
Symantec and Indiana University School of Informatics revealed
that they had uncovered a serious new security threat targeting
home broadband routers. The attack, dubbed Drive-By Pharming,
allows an attacker to change the configuration of a home router
when a user unknowingly visits a malicious website. The website
employs malicious JavaScript code that allows an attacker to log
into many types of home routers if the default password has not
been changed. Once logged in, the attacker is able to change the
configuration of the home router, including the Domain Name
Server (DNS) server settings.This type of attack is particularly concerning for a few reasons:
- Simply viewing the malicious webpage is all that is required
for a user to fall victim to this attack.- Many home users fail to change the default password on their
broadband routers. The Symantec report indicates that 50% of
all users could fall into this category.- Changing the Domain Name Server (DNS) server settings allow
an attacker to redirect the home user to a DNS server of
their choice. This includes a malicious server set up by the
attacker to direct users to other malicious websites, where
information such as financial account numbers, passwords,
and other sensitive data can be stolen.Symantec notes that the best defense against this type of attack
is for home users to change their default password. The
following links provide support resources for three of the more
common home router vendors:US-CERT cautions users to avoid clicking on links sent in
unsolicited emails. Users should also remain cautious when
browsing the web and avoid visiting untrusted sites. More
information can be found in Securing Your Web Browser document.To learn more, or to view a flash-animation of the attack, visit
Security Response Weblog.
This is pretty much exactly the scenario I warned about and it’s happening for real in the wild, NOW! If you have a broadband router make sure you change it’s password and give serious consideration to only enabling JS on sites that need it and not just surfing with JS on all the time. The threat is no longer hypothetical!
Feb
16
The Month of Apple Bugs Digested
Filed Under Computers & Tech, Security on February 16, 2007 | Leave a Comment
I’m actually surprised by how little discussion I’ve seen about January’s month of Apple Bugs. For those of you not familiar with the Month of Apple Bugs (MoAB) project, the idea was to post one Apple related bug each day in January 2007. Perhaps one reason for the lack of discussion is that the bug for the 31st of January has not been released yet. A very ominous title (“Unspecified Kernel Remote Fun”) has been posted but nothing more. People may be waiting to see just how bad these supposed remote exploits are before commenting. However, I’ve been digesting the thirty bugs we do have for a few weeks now and I think I’m ready to share some of my thoughts, even if may have to alter my views a bit when (and if) last bug is finally released.
[tags]Apple, Security, MoAB[/tags]
Feb
15
Are the Days of JS and AJAX numbered?
Filed Under Computers & Tech, Software Development, Security on February 15, 2007 | 2 Comments
A couple of months back I wrote two articles singing JavaScript’s praises from a programmer’s point of view (JavaScript – Much more than Java’s Mini-Me & Hidden JavaScript). In the last one I hinted that there would be a follow-on article showing a darker side to JS. This is that article, just a few months later than I’d planned. Unlike the previous two articles this one is not really aimed at programmers, it’s aimed at anyone who surfs the web.
JavaScript (JS) can be used to really enhance usability on the web. We all like having drag and drop capability on the web, we like the way AJAX lets pages only refresh the bits that need to change instead of whole pages, and we even like those cool JS transitions and graphic effects. A lot of people refer to these things as Web2.0, but I’m not going to. I prefer to think of Web2.0 as being about community involvement rather than any particular technology. It’s a frame of mind not a software version! You can have Web2.0 without JS or AJAX. The key point is that we are all getting used to the enhancements JS can bring to the web environment. But there is a cloud on the horizon and it is growing.
The sometimes controversial security expert Steve Gibson has been warning us about the dangers of browsing with JS turned on for years now. In the beginning people ridiculed him, but his views are gaining more and more acceptance as the dangers start to become real rather than theoretical. I think the recent MySpace JS worm and the release of proof-of-concept code for a JS port-scanner by SPI Labs have really started to focus people’s minds on the dangers of JavaScript.
[tags]JavaScript, JS, XSS, Security[/tags]
Jan
1
Running NMAP on Intel Macs
Filed Under System Administration, Computers & Tech, Security on January 1, 2007 | 4 Comments
Before I switched to an Intel based Mac I had always used NMapFE as my nmap front end. Since I only need to run nmap on my G4 MacMini at home and my G5 PowerMac at work I didn’t notice until today that NMapFE doesn’t work in Intel Macs. I had recommended NMapFE to Allison of the NosillaCast and she replied to tell me it didn’t work for her. I tried it on my own MacBookPro and sure enough, it doesn’t work. So, I went hunting for a good nmap GUI for Intel Macs and eventually came up with a good solution. The bad news is that this solution involves installing three things separately. But, don’t worry, all three are small and painlessly simple to install.
[tags]nmap, security, Mac, OS X[/tags]
Dec
22
Rogue DHCP Detection Plugin for Nagios on RedHat
Filed Under Security, My Projects, Software Development, Computers & Tech on December 22, 2006 | 9 Comments
I’m pretty sure this is useless on most versions of Linux because the default DHCP plugin that comes with the Nagios Plugins distribution has this functionality and seems to work just fine everywhere except on RedHat-based distros like RHEL, Centos and Fedora Core. On these systems the default plugin does not seem to work and fails to detect any DHCP servers. This plugin is different to the one I gave instructions for before which tests whether a particular DHCP server is answering requests, this plugin finds rogue servers, it will not alert you if any of your actual DHCP servers are down. Hence, you should probably install both. This plugin is not very polished, it is rough and ready but I know it works on RHEL4. If you’re running a different system you may have to do some minor tweaks but this should serve as an excellent starting point none-the-less.
[tags]Nagios, DHCP, RedHat, RHEL, CentOS, Fedora, Linux[/tags]
Mar
13
OS X Security – Untangling Some of the Hype
Filed Under Computers & Tech, Security on March 13, 2006 | Leave a Comment
There has been a lot of media hype in the last two weeks or so about OS X security and it seems to be sexy now to have a go at the mac. The amount of half-thought-out and poorly researched hype about OS X vulnerabilities of late is just astounding. To read some articles you’d swear that there was millions of destroyed macs littered all over the Internet. But there aren’t, there are two minor ‘viruses’, a vulnerability in a web browser, and a dubious hacking claim.
Two ‘Viruses’
So, what were these ‘viruses’, well, the first one, the wonderfully named "oompah loompah" virus (or Leap.A to be more formal) was a Trojan that spread it self via iChat. People had to open a file that they received via iChat to get infected. The second one allowed people with bluetooth devices to get too much access to your machine. Not good but the patch to fix this problem was released months before the virus so any sensible person was safe.
What can we learn from these two ‘viruses’:
- Don’t open files you get from an un-trusted source
- Keep your OS up to date
As for the first point, if you get a strange file from a strange person over ANY medium and you are stupid enough to open/run it you DESERVE to get your machine destroyed! Any file you run runs as YOU and has all the permissions YOU have so it can delete all YOUR files. That’s not a security problem that’s a fact of life on any OS. Programs you run can do what you can do and you can delete your own stuff!
The second point is another no-brainer. Linux and Unix are more secure than windows but ONLY if you keep them updated! Same goes for OS X, or any OS for that matter. Apple are very good at brining out security updates and patches, if your machine is going to be online INSTALL THEM!
You’ll notice that the two rules of thumb above are not OS X specific, they go for all OSes. Windows users have been aware of these realities for a long time, perhaps Mac users have not, well, they should have been!
One Vulnerability
The Safari vulnerability however was more worrying. In this case Apple did something stupid and they should have known better. Safari was susceptible because it opened files automatically on download. That is dangerous and the horrible experiences MicroSoft had with things like this SHOULD have served as an example to Apple for what NOT to do. It didn’t. I hope they’ve learned their lesson now!
And a Misreported Hack Success
Finally, the hack reported on ZDNet. Firstly, I’m disgusted with ZDNet for their shoddy reporting on this one. I read the ZDNet article and the implication was that the machine had been hacked remotely in 30 minutes. That would have been worrying. Thing is that is not what happened. The guy GAVE login accounts to the people who were doing the hacking! The exploit was NOT remote, it was local, and that makes the world of difference. I was disgusted when I found out from another source that that was how it had been done, ZDNet really let themselves down by leaving that vital piece of information out of their story, I for one will take everything they write from now on with a grain of salt.
What difference does it make if the exploit was remote or local? Well, on ANY OS you should only give accounts to people you trust. If you have to give accounts to un-trusted parties you need to take extra precautions to protect yourself. I very much doubt there is a single OS out there (be it a Linux, Unix or Windows variant) that does not have a local exploit, why should OS X be any different? What is important is that if you put a Mac on the internet that you are safe, that means that you should be protected from remote attacks, so far OS X seems to stand up very well to those, no doubt due to it’s excellent firewall which it inherited from it’s FreeBSD roots. In fact, another Mac was set up as a hack challenge, but without giving the attackers a login account and it lasted 38 hours before the test was cut short by University Administrators who didn’t like a machine in their network being advertised as a hacking target!
You Mean OS X is not Perfect?
So, OS X is not perfect, OS X users need to use common sense too, are you surprised? If you are then you were living in fantasy land! Linux is also not perfect, neither is Unix. There is no perfect OS! So, does that mean OS X is no better than Windows for security? Nope. Not at all. OS X has a better security model than Windows (as does Linux). The way attackers carry out remote exploits is by using a known or un-known flaw in some world-facing service on the target machine (e.g. the dreaded blaster used the RPC service to gain access to machines without the users having to do anything). The more services you have listening the more potential avenues for attack there are. You need to minimise the services you expose and you need to keep the software for those services as up-to-date as possible. On Windows there are loads of services open by default. Regardless of whether you ASKED your windows machine to run these services or not, ‘out of the box’ it will be running them, and each one is a potential entry point for nasty people into your computer. To make things worse it is actually quite tricky to turn off services on Windows, you need to be more than just an average user to have the skills to do it.
OS X and Linux by contrast have ZERO world-facing services by default! You, as a user need to turn on what you want. On OS X this is trivial to do, there is a nice simple GUI in the System Preference App to do it. The other nice thing is that the OS X firewall is tied in to the services and it’s default behavior is to block off all ports that are not needed by the services you have selected to activate. This means that, in general an attacker has FAR FAR fewer avenues of attack on an OS X or Linux machine than on a Windows machine. In fact, in general you don’t need any services open so you can keep everything closed and know that you are well protected, much better than you are on Windows unless you get technical or install third-party addons.
Finally … Some Conclusions
In Summary, here are the simple steps all Mac users should take to protect themselves:
- Turn on your firewall, Apple provided you with it for a reason!
- Don’t activate any services you don’t need!
- Keep your OS up to date
- Don’t open up any files (including apps) you get from un-trusted source
Finally, these are the reason I believe OS X is more secure than Windows
- OS X only opens the services you ask it to
- OS X has a better built-in firewall (the defauls are perfect for home users and power users have the power to do MUCH more, see The RIGHT way to set up a Custom Firewall on OS X and IPFW Firewall Script (Suitable for OS X))
- The core of OS X is opensource and based on the very solid FreeBSD.
- Apple seem to be quicker at getting out security fixes
- OS X has a better user-model, the Unix one
- OS X has a better file permissions model, again, the Unix one.
Feb
27
NmapFE – Nice OS X Frontend for NMAP
Filed Under Computers & Tech, Security on February 27, 2006 | 1 Comment
If you manage a server or a network nmap is one of those tools that you’d just be lost without. However, remembering the syntax for all the cool stuff it can do is a right PITA. Hence this nice simple OS X GUI to nmap is a real time and energy saver.
I can’t stress enough that NMAP is a tool that must be used responsibly. If you go around randomly scanning random people it is only a matter of time till you get into trouble, remember, it is a crime to scan machines that are not yours!
You can download NmapFE OS X from here: http://faktory.org/m/software/nmap/
It’s not particularly fancy and doesn’t have many bells and whistles but it does it’s job excellently. It gives you all your options neatly laid out in the main dialoge and then a separate window for the results of each scan (you can run many at the same time). The app even has a sense of humor, click the "script kiddie" checkbox and watch the output go all 1337!
The screenshots below show the main window and a sample output window (with the sensitive data blacked out) showing the results of a scan on one of my servers.
Dec
7
IPFW Firewall Script (Suitable for OS X)
Filed Under Computers & Tech, Security, System Administration on December 7, 2005 | Leave a Comment
I posted an article the other day about how to configure OS X to use a custom firewall script but explicitly didn’t discuss the actual rules, in this article I’m going to focus only on the firewall rules and assume that you are using an IPFW configuration that is working correctly on some OS that uses IPFW. Please note that I have tested these rules on OS X only but I can’t see why they wouldn’t work on any other IPFW enabled system.
So, without further ado, here is my /etc/rc.firewall (with all specific IP addresses blanked out of course!):
#!/bin/sh
#
# Declare variables
#
IPFW='/sbin/ipfw'
LOOPBACK_INTERFACE=lo0
PRI_DNS=XXX.XXX.XXX.XXX
SEC_DNS=XXX.XXX.XXX.XXX
#
# Flush the rules so we start with an empty pallet
#
$IPFW -f -q flush
#
# Do some house keeping
#
# allow through all genuinely local packets
$IPFW add 00001 allow ip from any to any via $LOOPBACK_INTERFACE
# deny all spoofed local packets
$IPFW add 00010 deny ip from 127.0.0.0/8 to any in
$IPFW add 00011 deny ip from any to 127.0.0.0/8 in
$IPFW add 00012 deny ip from 224.0.0.0/3 to any in
$IPFW add 00013 deny tcp from any to 224.0.0.0/3 in
# allow through established connections
$IPFW add 00020 allow ip from any to any established
# filter ICMP packets to only allow through some types
$IPFW add 00030 allow icmp from any to any icmptypes 0,3,4,8,11,12
$IPFW add 00031 deny icmp from any to any
# allow through DNS
$IPFW add 00040 allow udp from me to $PRI_DNS 53 keep-state
$IPFW add 00041 allow udp from me to $SEC_DNS 53 keep-state
# allow myself to make outgoing connections
$IPFW add 00050 allow tcp from me to any keep-state
$IPFW add 00051 allow udp from me to any keep-state
# allow through all DHCP packets
$IPFW add 00060 allow udp from any to any 67
$IPFW add 00061 allow udp from any to any 68
# deny UDP
$IPFW add 00070 deny udp from any to any
#
# Allow services
#
# ssh just from within my departments range
$IPFW add 00100 allow tcp from XXX.XXX.XXX.0:255.255.255.0 to me 22
#
# Allow in exceptions for me
#
# allows the FTP server to connect back to me for active FTP
$IPFW add 00200 allow tcp from XXX.XXX.XXX.XXX 20 to me
#
# end with deny all
#
$IPFW add 65534 deny ip from any to any
OK, so now I’m going to go through this bit by bit to explain why I’m doing things the way I am. There is logic behind each line and I’ve spent a lot of time and effort this week getting this right. I’ll also mention some pitfalls to look out for along the way.
I should also point out what I was trying to achieve with these rules. The first thing is that these rules allow me to go out on any port to anywhere I want, they are not designed to stop me doing stuff. Secondly, these rules are designed to expose as few as possible services on this machine and any services that are exposed should be exposed to as few hosts as possible. Finally, these rules are also designed to filter out a lot of the UDP rubbish floating round on the network I work on because of all the Windows boxes on it.
So, into the rules, the way I have it set up is that the only parts that you should need to edit are the top bit that defines the variables and the bottom bit that defines the services you want to open up, the bits in between that should not need to be edited as there are no specific IP addresses anywhere in them.
The first line is obviously a shebang line, if you don’t know what that is please stop reading now because you are not ready to set up a custom firewall script! So, the next bit is the definition of some variables:
IPFW='/sbin/ipfw'
LOOPBACK_INTERFACE=lo0
PRI_DNS=XXX.XXX.XXX.XXX
SEC_DNS=XXX.XXX.XXX.XXX
The first one is obviously defining the location of the IPFW binary and the second line is the definition of the loop-back interface. Be careful here, some scripts you see use lo* here and that is very dangerous, using it made my machine un-usable till I changed it back to lo0. The next two lines define the IP addresses for the DNS servers that the firewall should allow the machine to use.
The next thing you have to do is to flush all the rules that may be in the firewall already out so you know exactly what will be in there when your script ends, to do this we use the flush command but we must also use the -f flag to force it to do the flush without asking us if we are sure.
$IPFW -f -q flush
The next stage is to ensure that all loopback traffic can flow but that no one can spoof the localhost address on another interface, anyone doing so is definitely up to no good!
# allow through all genuinely local packets
$IPFW add 00001 allow ip from any to any via $LOOPBACK_INTERFACE
# deny all spoofed local packets
$IPFW add 00010 deny ip from 127.0.0.0/8 to any in
$IPFW add 00011 deny ip from any to 127.0.0.0/8 in
The next two lines are standard in all firewalls OS X’s firewall interface generates so I have added them to my rules too. They block certain types of multi-cast traffic.
$IPFW add 00012 deny ip from 224.0.0.0/3 to any in
$IPFW add 00013 deny tcp from any to 224.0.0.0/3 in
The next thing to do is to allow packets belonging to contections that have already been established to pass through the firewall without needing to be checked off all the rules again. This a great optimisation but is only any good if you have it close to the start of your rules.
$IPFW add 00020 allow ip from any to any established
At this point the next thing we are going to deal with is ICMP packets. Many people block all of these packets but I am not a fan of that. ICMP is there for a good reason and blocking it will probably make your system administrator grumpy! The way I filter ICMP I can ping people, people can ping me, I can traceroute to people and people can traceroute to me. I am however still blocking loads of other potential ICMP traffic that is just not needed (note that to get traceroute working you also need UDP to be allowed out).
$IPFW add 00030 allow icmp from any to any icmptypes 0,3,4,8,11,12
$IPFW add 00031 deny icmp from any to any
Next I allow through DNS to my specific DNS servers. These rules are technically not needed if you decide to allow yourself to send out traffic on all UDP ports using a state-full rule (see rule 00051) but I like to put these in explicitly because I sometimes like to just kill all UDP connections later in the rules.
$IPFW add 00040 allow udp from me to $PRI_DNS 53 keep-state
$IPFW add 00041 allow udp from me to $SEC_DNS 53 keep-state
The next thing I do is allow myself to make outgoing connections to any host on any TCP port and to send UDP to any port on any host. If you want to be able to use traceroute you have to allow UDP traffic out. Again, if you allow all UDP out using a state-full rule like the one below you don’t need to explicitly allow DNS so you can leave out the two lines above if you wish.
$IPFW add 00050 allow tcp from me to any keep-state
$IPFW add 00051 allow udp from me to any keep-state
One more thing to bear in mind is that if you do not include rule 00051 above to allow out and back all UDP ports then you would need to explicitly allow NTP if you wanted to use it.
The next thing to do is to make sure that you let all DHCP packets through. If you don’t use DHCP you can leave these two lines out.
$IPFW add 00060 allow udp from any to any 67
$IPFW add 00061 allow udp from any to any 68
At this point I like to deny all UDP traffic because there is just so much of it on our network but you can leave this line out if you wish, the last line will catch these packets too. The reason I put this rule here is for efficiency.
$IPFW add 00070 deny udp from any to any
Then we get to the second last part of the script where we define the services on our machine that we will allow be visible (to part of) the outside world. I like to tie things down very tightly so that I expose as few services as possible to as as few people as possible, hence, I only have two entries in this part of the script (and one is not technically a service). The first thing I do is allow SSH access to my machine but ONLY from within the subnet used by people within my department, not to anyone else on campus or beyond.
$IPFW add 00100 allow tcp from 149.157.4.0:255.255.255.0 to me 22
The second entry I have in here is needed to allow me to use active FTP to communicate with a web server I have to publish stuff to.
$IPFW add 00200 allow tcp from ccintranet.nuim.ie 20 to me
Finally, AND MOST IMPORTANLY, you must end with a rule to deny all packets not yet accepted. If you don’t your rule set will be utterly pointless and your machine will be pretty much completely open.
$IPFW add 65534 deny ip from any to any
And there you have it, my full set of Firewall rules for OS X. Now, please note that although I’ve been working with IPFW rules for many years both on OS X and FreeBSD I would still not consider myself an expert, hence, these rules come with absolutely no guarantees. I’m confident they are an excellent set of rules that combine the best bits of the other scripts I found on the web for OS X but you will need to make your own judgement call before using them.
My final bit of advice is to NEVER put a line onto your rules that you do not understand 100%, if you’re not sure what a rule does it should not be in your script! When you are done with your rules you should then check them by getting someone to nmap your machine or by using a free online service like ShieldsUp! from Gibson Research Corporation. Happy firewalling!
Dec
5
The RIGHT way to set up a Custom Firewall on OS X
Filed Under Security, System Administration, Computers & Tech on December 5, 2005 | Leave a Comment
For the vast majority of home users the GUI in the OS X System Preferences application for managing your Firewall is all you’ll ever need, however, once you start wanting to have different rules for different hosts you have no choice but to either fork-out cash for something like Brickhouse or to get your hands dirty and write your own firewall rules with IPFW, the firewall that is part of OS X.
In this article I’m going to walk you through the right way to set up your mac to use custom IPFW rules, I am NOT going to give a tutorial on IPFW, I will be assuming that you are familiar with it and basic firewalling concepts. If you don’t know what you are doing with IPFW then DO NOT SET UP YOUR OWN CUSTOM RULES, you are playing with fire here people, if you mess them up you can actually stop your computer from working or leave it open to attack, neither are good!
The first step in setting up a custom firewall is to create a Startup item to manage it as a service. There are many different scripts out there to do this but most do this in a very poor way that does not use the standard files and is not controllable in the standard BSD way. The script I give here DOES do things the Right-Way(tm).
As root you will need to make a folder /Library/StartupItems/Firewall, in this folder you will have to create two files. The first is the script to control your firewall, the second is the list of parameters the OS needs about your firewall service.
Firstly, the script to control your firewall, this file MUST be named identically to the startup item so in this case Firewall. The script should contain the following:
#!/bin/sh
##
# Firewall
##
. /etc/rc.common
StartService ()
{
if [ "${FIREWALL:=-NO-}" = "-YES-" ]
then
ConsoleMessage "Starting Firewall"
sh /etc/rc.firewall > /dev/null
fi
}
StopService ()
{
ConsoleMessage "Stopping Firewall"
/sbin/ipfw -f -q flush
}
RestartService ()
{
StopService
StartService
}
RunService "$1"
This script has the advantage that it allows your firewall to be started, stopped and restarted like any OS service and it also allows the firewall to be enabled and disabled from /etc/hostconfig (without this you would have to delete the startup item to disable it). As you can see this file does not actually contain our firewall rules, those should be defined in /etc/rc.firewall.
The second file MUST be called StartupParameters.plist and should contain:
{
Description = "Firewall";
Provides = ("Firewall");
Requires = ("NetworkExtensions","Resolver");
OrderPreference = "Late";
Messages =
{
start = "Starting firewall";
stop = "Stopping firewall";
};
}
The next step is to create your custom firewall rules and store them in /etc/rc.firewall. As I said I am not going to go into a discussion on creating firewall rules in this article, I am assuming that you know what you are doing when it comes to creating firewalls with IPFW! Hence I am going to skip straight on to enabling the service in /etc/hostconfig. This is exceptionally simple, all you have to do is add the line:
FIREWALL=-YES-
to the end of the file.
That’s it, you now have a custom IPFW firewall running correctly on OS X. If at any stage you want to temporarily stop using your custom firewall all you have to do is stop the service with /Library/StartupItems/Firewall/Firewall stop and then set the entry for your firewall in /etc/hostconfig to FIREWALL=-NO- to disable it.
I may well do a follow-up article to this one discussing firewall rules for OS X and/or logging but I’ll make no promises!