WRTSL54GS Adventures

Kamikaze 8.09 is almost ready, just hit RC1. Time to prep my (2nd) backup WRTSL54GS. First step is to install the serial adapter, but Linksys has thrown a curve, instead of the standard screws previously used, these are 'tamper proof' Torx-10 screws, the tamper proof versions have a small stud in the exact center of the screw to keep a normal driver from being inserted.

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

Yesterday's article, Blocking brute force attacks, helped me put a great dent in attacks here, but also caused a bit of an inconvenience. Using IPTABLES to block such attacks has the inherent drawback of using the same restriction on both successful and failed connections, and the main system I check mail on here logs into quite a few separate mail accounts locally, all requiring a separate connection, so my default filter had to allow for a rather high number of incoming connections before any could be blocked. Enter the whitelist...

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

This one has had me baffled for a while. From time to time in my logs, I'd see repeated attempts by an unknown IP to connect to one of the services here, usually trying to log into the mail server via a POP account. Normally I'd simply update the /etc/firewall.user file to drop connections from that IP, and not worry about it, but I knew there had to be a way to stop such attacks in their tracks...

Continue reading "Blocking brute force attacks" »

Still waiting on the Release Candidate that should have been out early this month. Lots of fixes in the new release, still no new kernel for my WRT, though. Stupid Broadcom not releasing drivers for their chipset...

Due in August. Time to prep my backup router...

There is probably a better way to do this, but I've gotten tired of my son screwing around on the net and not doing his homework, so I've decided to block a few sites at the router. His system uses DHCP addressing, so he picks up the DNS server info from OpenWRT, which till now just passed along those requests to the configured ISP DNS servers. My other systems are on static, and have these DNS entries listed manually.

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

Continue reading "Restricting URLs" »

I'm going to take another crack at installing Kamikaze on my new spare WRTSL54GS that I picked up before the holidays. After I install a new serial jack on it, that is. :)

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.

A few weeks ago, I had purchased a spare WRTSL54GS to do testing on, and unfortunately shortly after installing a new serial port (installed almost immediately after opening the box) and then installing Kamikaze, discovered that the router had become unresponsive after just a few days.

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.

A bit of trickery to print to a printer on my home LAN via the internet. The example below assumes the printer is being connected to externally on port 12345, and actually accepts connections on port 9100 (HP Jet Direct).

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

For posterity, here is my working iptables config:

#!/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.