DevinCarraway writes:

One of the potential handy uses of a tuxscreen is as a firewall. It has several advantages:

• No moving parts: firewalls almost never need to start or stop applications. They don't need to do anything but sit in kernelspace, route and filter packets. The tuxscreen has no hard drive and no fans, making it potentially lots more reliable than a PC firewall can be. Firewall logs can and should be sent over the network to a loghost in any case.
• Flash filesystem: disks fail. Floppies fail. Flash fails less, and has the advantage over either for a firewall machine you're going to boot once, then leave up for months.
• Non-x86 architecture: your typical attack script assumes an x86 (or, rarely, a sparc) architecture. Using a more esoteric architecture is a cheap and dirty way to fend off such attacks. It's not automatic security, but it helps.
• Very Readonly Filesystems: if your filesystem is in cramfs (see UsingCramfs) on flash, an attacker who wants to trojan the binaries will need either a rw-cramfs driver (which maybe they'd be so kind as to contribute back to the kernel maintainers) or a reflash driver (likewise).
• Cost: A tuxscreen is very cheap compared to anything comparable you can buy, and it's very hard to find StrongARM units that can supply two ethernet hookups. The LART project has schematics, but as of this writing you can't purchase all the hardware you'd need pre-built.
• You can order pizza on the firewall.

I'm gradually working on getting a tuxscreen turned into a firewall.

Jun 20 2002 : Returned to the effort after some time spent off on other distractions. In the meantime the buildroot had changed substantially, so it took me a couple evenings to get an operable build again.

I knocked up the files needed to add iptables to a buildroot build; they can be had from http://www.devin.com/cruft/tuxscreen/ . The patch alters the iptables makefile slightly so IPv6 support (which is enabled if the host side has the relevant libc header) can be disabled on the make commandline. This version uses the standard loadable-module configuration (since the buildroot's uclibc now has dlopen()).

Jul 3 2002 : I've now got iptables working pretty nicely; made a few updates to the buildroot makefiles to smooth things out. I'm now proceeding on to FreeSWAN.

Hardware : I used a pair of Trendware TE100-PC16 cards; these worked out of the box(es) without any hassles at all. The PCMCIA page has plenty of discussion of this issue. Heat doesn't appear to be an issue even with two such cards running -- after (checking uptime) 25 hours of continuous 10mbit streams on both cards, the card region of the tuxscreen is barely warmer than anywhere else.

Since any PCMCIA cards of which two can fit in the tuxscreen will have dongles, you'll want to secure the dongles in some way that doesn't stress the connector and can support the weight of hanging ether cables. Zip ties and a couple of adhesive anchors would do.

Kernel : the ARM kernel tree has a working netfilter implementation. The 2.4.16-rmk2-tux1 tree (current as of this writing) works fine for it. Make minor changes to the stock kernel configuration and away you go:

CONFIG_NETFILTER=y
[...]
#
#   IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_FTP=y
CONFIG_IP_NF_IRC=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=y
CONFIG_IP_NF_MATCH_MAC=y
CONFIG_IP_NF_MATCH_MARK=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_LENGTH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_TCPMSS=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_MATCH_UNCLEAN=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_MIRROR=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_NAT_SNMP_BASIC=y
CONFIG_IP_NF_NAT_IRC=y
CONFIG_IP_NF_NAT_FTP=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_MARK=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_TCPMSS=y

(select what you really need and omit the rest.)

iptables : you need the iptables utilities, not currently part of the tuxscreen buildroot. I've put my iptables.mk and a small patch at http://www.devin.com/cruft/tuxscreen/ ; save iptables.mk to buildroot-tux/make/, and iptables-1.2.6a-no_ipv6.patch to buildroot-tux/sources/.

syslogd : For this job a remote loghost is required; there's not enough space in either the /var ramfs or flash to store the firewall logs, to say nothing of the DoS potential. The busybox syslogd has a BB_FEATURE_REMOTE_LOG which provides the basic UDP remote logging -- worth looking into. Logging rejected packets to a ULOG target and thence to ulogd is more tempting, but as of 0.97 ulogd doesn't have a means to make the last hop over the network to the loghost.

Performance :

I haven't measured performance (read: carrying capacity) in detail yet. Without overclocking the CPU, my tuxscreen handles two simultaneous 10mbit TCP streams (nc remotehost1 port < /dev/zero to nc -l port > /dev/null, once for each interface) with a loadavg of 0.82. Note that this involves copying the network stream out to userspace and back, plus a lot of context switching, so the real thing should be a good deal faster.

Obviously, 16-bit PCMCIA isn't a terribly efficient way to do this sort of thing, but it should be plenty for any DSL-level connection.