Small delay, I'll just need to fetch my set of security drivers from work tomorrow... ;)

Additional reading online found a number of very similar articles, again all centered around SSH attacks to the router, not a separate system behind the router. After a few rounds of testing, I finally found the trick that would work here, the completed snipped of code is below, refer to yesterday's article for a more complete firewall.user file.

The greatest challenge was in determining exactly how to whitelist internal traffic. When such traffic is logged by my servers, the connection appears to be coming from outside, so my natural assumption was to whitelist the external IP. That just didn't work. Changing the code to whitelist my internal network did the trick, a streamlined version follows. This code may likely only be necessary for mail accounts, other types of connections are not as likely to have a high number of repeat connections for valid users, internally or externally.

# POP/IMAP
iptables -N pop-whitelist
iptables -A pop-whitelist -s $network -m recent --remove --name POP -j ACCEPT

iptables -A forwarding_rule -p tcp --dport 110 -m state --state NEW -m recent --set --name POP
iptables -A forwarding_rule -p tcp --dport 110 -m state --state NEW -j pop-whitelist
iptables -A forwarding_rule -p tcp --dport 110 -m state --state NEW -m recent --update --seconds 60 --hitcount 3 --rttl --name POP -j DROP

After more Googling, and closing in on exactly what I was searching for, I finally found an article that had much the same information as the others, but some comments there led me to the answer I needed.

The steps documented in many places for SSH will work great, but they are intended to block traffic destined for a service on the router itself. My situation was to block traffic destined for a server behind the firewall, but not on the router, a service that traffic was being forwarded to.

This is a key difference, and iptables handles these chains in different ways, and the rules I was putting in were only acting on the INPUT chain, not the forwarding_rule.

My firewall.user file was cobbled together from various places, including a number of threads on the OpenWrt forums, and so is likely a bit different from what others may have, so below is the relevant code from my file showing how my rules are defined, and more importantly, the working code that will block repeated attempts at connecting to the POP service here (port 110).

In my example, 10 connections within 60 seconds from the same IP will cause further attempts to simply drop, until the oldest connections age past 60 seconds and drop off. The second rule will drop connections with 20 attempts in 10 minutes (600 seconds), which should be enough to stifle most attacks. I plan to adapt this code to FTP and other services also.

It is important to understand how users connect to these services, and when multiple connections within a short timespan may be required, so that you can then identify what may actually constitute an attack to effectively block it.

#!/bin/sh
. /etc/functions.sh

iptables -t nat -A prerouting_rule -d $WANIP -p tcp --dport 110 -j DNAT --to $server:110
iptables -A forwarding_rule -d $server -p tcp --dport 110 -j ACCEPT
iptables -t nat -A postrouting_rule -o $LAN -p tcp -s $network -d $server -m multiport --dports 110 -j SNAT --to-source $WANIP

So, it seemed to be an easy process to insert a few entries into the /etc/hosts file on the router.

It would be easy enough to pick a 'safe' site to redirect requests to, a homework help site, the school's web site, etc. All you'd need is their IP address and then just list out the sites you want to point there. In my case, since I am already running a web server here, it seemed easy enough to just add a new VirtualHost under Apache.

Since obviously I wasn't going to purchase a new domain for this, the easiest thing to set up unique traffic seemed to be to add a second IP address on the Mac's ethernet port. In System Preferences, click Network, add a new service (the + symbol if you're running Leopard), select the Ethernet interface, and just call it Ethernet 2. Set a new static IP, save it, and you're done.

Next, in the Apache config files(/etc/apache2/extra/httpd-vhosts.conf for 10.5), set up a new virtual host using that IP address, and port 80. Then just set up where the documents for this web site are located, separate log files if you wish, then grant access for web visitors to actually reach this content. Example follows:

<VirtualHost 192.168.1.9:80>
DocumentRoot /www/homework/Documents
ErrorLog "/Users/wright/Documents/apache2/homework_error_log"
CustomLog "/Users/wright/Documents/apache2/homework_access_log" combined
</VirtualHost>

<Directory "/www/homework/Documents">
Options Indexes FollowSymLinks MultiViews
Order allow,deny
Allow from all
ErrorDocument 404 /index.html
</Directory>

The ErrorDocument statement above will take any page that isn't found (which almost all page requests will be) and redirects this to the main page served. All that I'm using for this is a simple HTML document that displays the text 'Site Unavailable, go do your homework." Obviously you can be as fancy as you want with that.

Over on the OpenWRT side, enter the domains you wish to route to this fake web page. My etc/hosts file looks like the following:

127.0.0.1 localhost OpenWrt
192.168.1.9 youtube.com www.youtube.com

Specifically adding the www.* domain is important, otherwise those requests will hit the actual site.

I've had this one just idling with power on and nothing else hooked up as a burn in test, since it's still chugging I think I'm past the issue I had with my last spare router now.

Consulting several experts led me to believe that he router was bricked. I shipped it off to a friend to verify, and all indications are that I had experienced an actual hardware failure, possibly as a result of a power fluctuation here (something I had ignored at the time, but now seems likely to have been the culprit). It is also possible I had bad hardware from the factory, but as I had quickly modified it, I had no way of knowing if it may have been bad originally. Bummer.

Tested and working, but may not be perfect. OS X wasn't able to identify the printer model automatically, but setting this manually let the jobs print normally.

# Printer
iptables -t nat -A prerouting_rule -d $WANIP -p tcp --dport 12345 -j DNAT --to 192.168.1.99:9100
iptables -A forwarding_rule -d 192.168.1.99 -p tcp --dport 9100 -j ACCEPT
iptables -t nat -A postrouting_rule -o $LAN -p tcp -s $network -d 192.168.1.99 -m multiport --dports 9100 -j SNAT --to-source $WANIP

#!/bin/sh
. /etc/functions.sh

iptables -t nat -A postrouting_rule -o $WAN -j SNAT --to-source $WANIP

There you have the basic setup. The variable WANIP will find the current IP address of the WAN interface, network is whever you have defined for your local LAN, and server is the server you're routing ports to. You could easily define server2, server3, etc, for as many systems as you want to map here.

# identd
iptables -t nat -A prerouting_rule -i $WAN -p tcp --dport 113 -j ACCEPT
iptables -A input_rule -i $WAN -p tcp --dport 113 -j ACCEPT

This is my config for identd (still not working for some reason?) to open the correct port, and set up the router itself to answer on this port (that part, at least, works).

# Lines below let WAN address work from LAN
# SMTP
iptables -t nat -A prerouting_rule -d $WANIP -p tcp --dport 25 -j DNAT --to $server:25
iptables -A forwarding_rule -d $server -p tcp --dport 25 -j ACCEPT
iptables -t nat -A postrouting_rule -o $LAN -p tcp -s $network -d $server -m multiport --dports 25 -j SNAT --to-source $WANIP

iptables -t nat -A prerouting_rule -d $WANIP -p tcp --dport 143 -j DNAT --to $server:143
iptables -A forwarding_rule -d $server -p tcp --dport 143 -j ACCEPT
iptables -t nat -A postrouting_rule -o $LAN -p tcp -s $network -d $server -m multiport --dports 143 -j SNAT --to-source $WANIP

Opening up various ports that will be handled by 'server', and tricking things so that requests via the LAN port for the WANIP will get routed correctly, so you can use your own external domain name internally (default router config doesn't allow this to work). This was the tricky bit solved in the forum thread mentioned in my last post.

# Access webif from WAN on port 65321
iptables -t nat -A prerouting_rule -i $WAN -p tcp --dport 65321 -j DNAT --to :80
iptables -A input_rule -i $WAN -p tcp --dport 80 -j ACCEPT

This took a small bit of research. This will redirect port 65321 from the WAN side to port 80 on the router itself, in case you want the router's web interface to be accessible externally. Use this same trick if you wanted to SSH into the router, or externally access any other router specific service by remapping the port.

The trickiest bit was figuring out the iptables command and setting things up so that I could access my web/mail server via the LAN using the WAN address (so I could refer to it by name instead of a local IP). This posting over on the OpenWRT forums was a great help in doing exactly what I needed.

I wish now that I'd had some heat shrink tubing on hand for the jack, but I'm not planning to go back to fix that unless I have to. A quick desoldering of my old cable from the underside of the board and soldering the new cable to the top of the board and I was in business.

Several versions of this cable are available for 5v and 3.3v sources, with several alternate ends, the AJ (Audio Jack) version to me seems the most flexible to adding a serial interface as it is easily removable from the unit when not needed.

I still need to dig in and figure out iptables, the code that controls the firewall and NAT settings, it's a lot trickier than what I'm used to, and there aren't a lot of great examples online that I've been able to find so far.

That looks to be my last technical hurdle on putting this into production here. All I need to do now are fine tune my firewall rules for port handling, and I should be good to go. Now all I need is some free time to get that worked out... ;)