New Links!

I’ve changed the MattLinks page somewhat to reflect some new things I’ve found and additions I figured appropriate. I added a hilarious reference (see under Stupid/Random Links) for the Wooden Periodic Table — a project I really admire…and shudder to think about at the same time. There are also other additions and changes to the list. Check them out when you get a chance.

Long Live The Firewall!

I’ve managed to transcribe my firewall rules for iptables. Electronically. This means that major progress is being made. This setup has yet to be tested, and the only part which really changed was the FORWARD chain stuff (no more masquerading) and NAT table stuff (I now do SNAT (source NAT) instead of masquerade as I have a static home IP address). I also made some minor changes within the iptables rules, mostly based upon a good idea I saw in an example script. Since the -l flag is no longer available, you actually have to write rules where the target is -j LOG, then write an identical rule to drop said packet if that’s the desired reaction. I have several ‘services’ I monitor for abuse (I used to get a lot of FTP requests, now it’s mostly SMB ports)…just for the heck of it. So, I’d have to copy pretty much every rule of that chain. Instead I added a new chain with the log/deny rules both written in the generic case, and call it as the jump for these services. See diagram:

My service blocking under ipchains:

Incoming Packet –> INPUT CHAIN –> EXT-IN CHAIN –> SERVICES CHAIN –> Log, then DENY (in one step)

INPUT CHAIN is a default chain for ipchains. Ext-in and Services are my user-defined chains.

My service blocking under iptables:

Incoming Packet –> INPUT CHAIN –> EXT-IN CHAIN –> SERVICES CHAIN –> SLnD CHAIN –> LOG –> DROP

INPUT CHAIN and LOG are default targets in iptables. Ext-in, Services, and SLnD (Service Log & Deny) are my user-defined chains.

Perhaps this makes no sense to anyone else but me…but it works, and without ‘duplicating code’ and causing the packet filter to check more rules. So it’s more efficient.

With all that said, I hope to start working on the transition to new server box tomorrow after work. It will take a few hours, but should be quite straightforward. The only major potential problem will be with iptables, which should be quickly diagnosed and hopefully fixed if any problems arise. Wish me luck. We’ll see what happens…

In Other News…

…I’ve not really taken time to look at my local packet sniffing experiment the other night. I have yet to do some research on potential holes in that scenario. This will hopefully allow me to pick out potential (and already possibly exploited) security holes and patch that into the firewall as appropriate. At first glance, most of the traffic was SMB-related (e.g. Windows Connectivity (Network Neighborhood stuff)) and ARP requests…as well as the occasional mail-check, messenger service update, and so on.

Once I get the old server box back online (after redoing it), I hope to run this exact experiment for about 24 hours, of course filtering out valid requests.

This post was upgraded to the MZ Online Blog on 8/20/07