Route NNTP traffic via specific ISP with iptables

Jeroen — Sat, 12 Feb 2011 17:37:24 +0000

I use a newsgroup provider for exchanging content with the Usenet newsgroup. My newsgroup provider restricts connections to be originating from the same IP for a specific account. I have a machine in my network that is always on and therefore perfectly suited to be serving as a download machine. The problem however is that this machine is providing other services (shell, webserver, mail) via the slower, but more stable ISP connection with a static IP. My preference is to keep it connected this way for obvious reasons.

I can use ISP1′ connection for downloading via the newsgroup, bu the newsgroup provider does not allow traffic to its servers from more then one IP. If violated this results in the following message:

1	Failed login for server [482 You are already connected from a different host]

Besides I also use the ISP with the fast connection to download from the newsgroups, and when using both ISPs at the same time it causes the above ‘failed login’ message.

My situation summed up:

Server running Ubuntu 10.04 LTS running my favorite newsgroup download tool SABNZBD
Two ISP’s on my local network.
ISP1: slow but stable connection with static IP
ISP2: fast, but less reliable connection with dynamic IP
Server connected to the Internet via ISP1 (default gateway)
Both gateways are on the same local network (192.168.2.0/24)

The solution
I want traffic that is using 119 as destination port to be routed via ISP2, while other traffic should be routed via ISP1, which is the default gateway for the server. To accomplish this, I created a script that allows you to redirect specific traffic to a specific port to be redirected via a different gateway then the default gateway:

1
2
3
4
5
6
7
8
9
10
11

#!/bin/sh
ISP2_GATEWAY=192.168.2.253
PORT_TO_REDIRECT=119

#Create a table
ip route del table webtraffic
ip route add default table webtraffic via $ISP2_GATEWAY
ip rule add fwmark 1 table webtraffic

#Redirect all traffic outgoing to the specified port to be routed via the above specified gateway
iptables -t mangle -A OUTPUT -p tcp -m tcp --dport $PORT_TO_REDIRECT -j MARK --set-mark 1

Just adapt this script to your needs and execute it on the server machine.

This solution can be used for other ports and other kinds of traffic as well that is going outward from your local unix machine, for example secure nntp traffic via port 563.

References
These sources have inspired me to find this solution:

Hope this helps anyone.

Get a root shell on a Lacie Network Space device without physically opening the device

Jeroen — Wed, 29 Jul 2009 20:36:12 +0000

About the NAS

I own a 1 TB Lacie Network Space device. This device, also called Network Attached Storage (NAS), enables you to hook it onto your (local) network and access files via file -and print sharing, ftp and other protocols. Very handy, if it works as you expect it to.
The NAS has an ARM926EJ-S processor, a 1TB hard disk, 16MB of memory, an USB port and no fan (which makes it pretty quiet).

Problem

My problem with the NAS is that the kernel running on the device starts killing processes when I copy very large (2 GB+) files to the NAS via file -and print-sharing (using the samba server). This broke my device in such a way that it would become unusable (no admin panel, though still pingable). Therefore I sent the device for RMA to Lacie’s service desk where it was repaired.
At least I thought it was, because after copying those large files again, the device broke again, but this time I was luckily still able to reboot and keep the device up a little while before it required a new reboot.
The system log showed a kernel that was randomly killing processes. I expect this might be caused by the autoscan feature that indexes the media on the device, or maybe the device just doesn’t have enough memory to cope with the continuous transfer of big files. Not funny for a € 160,- device.

Getting root

I decided I didn’t want to submit the device for RMA again and wanted to get root access to the device and repair it (read: make it more stable) myself. However I didn’t want to physically open the device and void the warrant. Luckily you don’t have to, at least not when your device is running firmware 1.1.8, as I found out thanks to a post from user ‘hardel09′ (read here). You should only proceed when you understand what you are doing. If you do anything wrong, it can break your device.

Take the following steps:

Save the content below to a HTML page, as it allows you to send commands that allow you to abuse cron for executing the tasks you want:

1
2
3
4
5
6
7
8
9
10
11
12
13

Change the YOURDEVICE in the HTML-file to use the right IP-address or hostname of the NAS
Copy utelnetd to \\YOURDEVICE\openshare\utelnetd
Open the HTML file with your favorite browser and fill the current hour in the hour input field and fill the minute input field with the value below. Change the “HOUR” string to the current hour and change the “MINUTE” string to the next minute plus 2 minutes or so (leaving existing spaces intact), assuming the time on your NAS is correctly set (if not, make it correct by using the admin panel). Now click the SET CRONTAB button and after a few seconds you should end up at the administrator media page with the autoscan checkbox selected.
1
MINUTE HOUR * * * chmod 755 /home/openshare/utelnetd; /home/openshare/utelnetd &
Now wait a few minutes, start you favorite network scanner tool and check if port 23 on the NAS has yet appeared as open. If this is not the case, try again from step 4.
If so, you can almost log in, if you set a (empty) password for the root user. Get to the HTML page again, change the “MINUTE” and “HOUR” strings again (leaving existing spaces intact) and add a command that makes root’s password empty:
1
MINUTE HOUR * * * passwd -d root
Login with user root via telnet to get your root shell:
If you got a shell, congratulations, you did it! Now continue to make it permanent. Disable the cleanConf daemon, so your changes won’t be reversed when the NAS is rebooted:
1
2
3
cd /etc/rc.d/rc3.d
mkdir disabled
mv S12cleanConf disabled
Fix the hacked crontab by executing the command below and clear the first line in the editor (which will disable autoscan)
1
crontab -e
Copy /home/openshare/utelnetd to /usr/bin and make it executable:
1
2
cp /home/openshare/utelnetd /usr/bin
chmod 755 /usr/bin/utelnetd

Add a script in /etc/init.d/telnetd for starting utelnetd automatically. Mine looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

#!/bin/sh
# Begin $rc_base/init.d/telnetd

. /etc/sysconfig/rc
. $rc_functions

case "$1" in
start)
echo "Starting telnetd server..."
/usr/bin/utelnetd &
;;

stop)
echo "Stopping telnetd server..."

killall utelnetd
;;
restart)
$0 stop
sleep 1
$0 start
;;

status)
statusproc utelnetd
;;

*)
echo "Usage: $0 {start|stop|restart|status}"
exit 1
;;
esac

# End $rc_base/init.d/telnetd

Enable the script by making a symbolic link that points to the telnetd script:
1
2
3
4
cd /etc/rc.d/rc3.d
ln -s ../../init.d/telnetd S18telnetd
cd /etc/rc.d/rc6.d
ln -s ../../init.d/telnetd K12telnetd
Make the script executable:
1
chmod +x /etc/init.d/telnetd

That’s it. You can now reboot the device and utelnetd is automatically started after the reboot.

Now we have root

So what can you do with the device now you have root access to it?

Secure it. Anyone in your network who can access the device via IP can currently connect to it without a password, so you might consider using openssh instead of telnet as described here. You might want to secure the /www/cgi-bin/admin/media script as well, as it can be easily used to hack into the device.
Fix other problems with the software on the NAS that bother you.
Mount (multiple) partitions from an external mass-storage device and make it available on the network.
Use it as bittorrent client.
Run other (light-weighted / self-compiled) applications on it.

I hope this has helped anyone in any way

Jeroen's weblog » Linux

Route NNTP traffic via specific ISP with iptables

Get a root shell on a Lacie Network Space device without physically opening the device