worrbase

So I haven’t really posted in the last month, mainly because I haven’t done anything interesting. I’ve been writing some Perl code using Catalyst and Mason. But that’s not terribly exciting.

I am however, taking a Mainframes course at RIT this quarter. It promises to be relatively exciting. In it, we get to learn the intricacies of z/OS, and how to manage one of those beasts. That’ll be fun. Surprisingly, there’s a programming project towards the end of it (it’s surprising because it’s a Networking and Sysadmin course, we don’t program much). And since I’m learning how to administer and use mainframes, I thought to myself, “Hell, let’s do this project in COBOL.” So here I sit, trying to find a decent COBOL tutorial on the internet.

If anyone finds one, please send it to me. It’d be nice.

So I started writing a netboot server for floor. I decided to start writing the web interface first, and learn myself some mason, web perl, and database-y things. Also found some things out about the process that were a little undocumented/misdocumented (now a word).

The biggest issue (so far) was file uploads. So here’s a quick tutorial on how to do file uploads with perl, with mason.

In index.html (or wherever your form HTML code lives):

<form method="post" action="upload.mas" enctype="multipart/form-data">
  <input type="file" name="file_name" /><br />
  <input type="submit" value="Submit" />
</form>

In upload.mas:

<%init>
use Apache2::Upload;
# $r is an Apache2::RequestRec, not an Apache2::Request like some places say it is
my $req = Apache2::Request->new($r);
# file_name refers to the form name you had in your HTML
my $upload = $req->upload('file_name');
my $fh = $upload->fh;
open OUTFILE, ">$where_ever_you_wanna_save_the)file";
binmode $fh;
binmode OUTFILE;
print OUTFILE $line foreach my $line (<$fh>);
close OUTFILE;
close $fh;
</%init>

In your httpd.conf:

APREQ2_READLIMIT 2G # Sets the max size of your user's uploads to 2GB

I intentionally skipped over error handling code and all of the httpd.conf config for the sake of brevity (I did say brief tutorial). Since I need to allow for larger file sizes than Apache does by default (64MB), I spent quite some time looking for that Apache directive.

Hopefully this saves someone some time.

This weekend, I decided it would be a good idea to turn my Linux router/firewall into an OpenBSD router/firewall. Clockfort recommended it, so I decided to grab backups of my iptables rules, install OpenBSD, and learn pf.

I learned iptables about a year ago, when I first built this router/firewall. It acts like those little home gateways that you get; it does NAT, DHCP, DNS, etc. I’ve also used iptables to firewall my desktop and laptop (though those rule sets were significantly simpler than the firewall).

Configuration

The first notable difference between pf and iptables: pf has a config file! It also has variables, lists and tables that you can manually populate which ease configuration. You can even include other config files in case you need to split your config for whatever reason. When you’re done modifying the config file, just call pfctl -f /etc/pf.conf and it’ll load that rule set and start filtering.

iptables doesn’t have any of that. iptables are primarily populated through the iptables command. You can use iptables-save and iptables-restore to save and load iptables rules from a file. The file is basically a bunch of iptables commands with the iptables bit omitted. Another alternative is to write a bash script that loads your iptables rules one by one. That option gives you the benefit of using variables so that it’s trivial to change IPs or similar.

I used iptables-save and restore to configure my iptables rules, and just wrote rules to that file in a similar syntax when I wanted to reconfigure parts of my firewall.

Rule Processing

The next most obvious way they differ is how they process rules. iptables has various tables, each with different chains that packets traverse, whereas pf just processes packets straight down the config file.

With pf, packets traverse the flat pf.conf file. Even if a packet matches a rule, it continues to process the packet all the way down the configuration file. Only if a rule contains the “quick” option does pf stop processing and take action before hitting the end of the rule set. If a packet makes it all the way to the end of the config file, the last action specified from a rule that matched that packet is taken.

With iptables, packets are processed by various chains in different order, depending on the source and destination in the packet. For example, normal outgoing packets are processed by the OUPUT chain on the filter table. Various rules within that chain may cause processing to hop over to a different set of rules on a user-defined chain, or might take action on a packet. When a packet matches a rule description, processing on that chain stops immediately, and the action is taken.

Dynamic Modification

pf really just owns iptables here. To dynamically update your rules with iptables, you just write new rules on the fly. If you want to do a bunch, you would write a bash script to delete some rules, and write new ones.

pf, you can change tables, variables, lists and anchors on the fly. Anchors are a really cool feature of pf. They are basically sub-rulesets that have names. So if you define an anchor somewhere in your ruleset, you can call pfctl and totally redefine the rules within that anchor. You can even write anchors to files, and load them from different files.

Packet Filtering

pf is pretty simple concerning what it can filter for. It can filter based on protocol, TCP flags, source IP, destination IP, interface, and port. There is also some slightly more advanced filtering, like antispoof, unicast reversing, and passive operating system finger printing. For the majority of situations, this kind of firewall control is fine.

iptables can do all of the same stuff. However with iptables, you can load all sorts of modules that do far more intensive filtering than pf. You can filter based on state (no, you can’t filter based on state in pf), where they are (geoip), time, statistics, ToS, and much more. There are so many target extensions for iptables, it is ridiculous. And if that isn’t enough, you can pass the packet into userspace and write a script to filter it further there.

Performance

pf is fast. I said before that you can’t filter packets in pf based on state. That doesn’t mean that pf isn’t a stateful firewall. It definitely recognizes state, as it passes packets that are part of an established connection without even processing them with pf. This means the majority of your packets skip your firewall rules entirely. This isn’t nearly as insecure as it sounds, since most iptables rulesets pass packets that are part of an established state anyway. It definitely has the distinct advantage of making it faster though.

With iptables, all of your packets pass through all of your rules. This can really slow things down, especially if you have complicated rulesets. If you use all sorts of crazy iptables modules, that will slow it down pretty heavily too. And if you pass the packet into userspace for further processing, it will slow it down even more.

Conclusion

pf and iptables are both great firewalling solutions, but cater to people of different needs. pf is ridiculously fast, but lacks some of the more avanced features of iptables. Since my router/firewall box doesn’t really need those advanced iptables features, and since it needs to be fast, I’m gonna stick with pf for now.

So lately I’ve been trying to get an IPX test network going between my NAS and my desktop. The idea was to make my NAS an emulated NetWare server, and then make my desktop a client using the Linux IPX tools.

IPX setup was trivial.  Getting a NetWare emulator set up is almost impossible now.

First off, the ipx.h that ships with Debian stable right now is broken. Flat out broken. I have tried incessantly to get various IPX programs to compile against it, but they always throw errors. Next quarter, when I have more time due to easy classes, I might try and figure out what’s wrong. Fact of the matter, I don’t have time now.

This problem was pretty limiting, as the only mars_nwe packages I could find were source, or (horribly broken) rpms. However, I managed to find a mars_nwe Debian package here. It installed cleanly, and started up after a bit of configuration. Right after it started up, it failed to open a critical library, libdb.so.2.

With a little apt-file magic, I found the library in the Debian repos: libdb1-compat. Great news: it was compiled against the wrong version of glibc. So no dice on Debian just yet. It refuses to compile Gentoo whatsoever because the mars_nwe Makefile chain horribly confused.

The provided mars_nwe Makefile reads a configuration file for all the options to mars_nwe (they have to be compiled in; it can’t be reconfigured later). After that, it runs the current Makefile through the C preprocessor, generates a new Makefile, and then begins the compilation process. The best part of the Makefile that it generates is that the syntax is wrong. Just wrong. Make just spits out errors everywhere. So I grabbed the Makefile.o it generated and started correcting the syntax errors and cut out the bit that generates that Makefile. Thing still won’t compile. Shelving that until after my CS project is all done.

I’ll be so happy when I’m done with that project. I’ll actually be able to work on all the projects I wanna get done this year.

Yesterday ended up being extraordinarily productive for me. I learned GTK+ in perl, and wrote the GUI for my Omegle app. It’s looking decent, although there is this annoying issue with the menu bar that’s bothering me a bit. It’s very simple, but I can’t really think of any other features to put in the GUI.

I also got a bunch of the abstraction for my CS project done today. But that wasn’t that much code. Oh well.

Also, in the middle of this post, got roped into helping fix our Xen management interface. And by help, I meant I installed Ubuntu server (ugh) on a machine and installed openssh. Woo.