Stealth The Viking Voyager Router..

The main 205 page was starting to get a bit long, and while there's loads of great info there, especially in the comments section, I felt it was about time to split things up a bit, help those looking for particular solutions.

This page deals with stealth and security, and applies to all the Viking based router; BT Voyager 205, of course, CastleNet AR502, Dynalink RTA100, RTA500-D51, GlobespanVirata, Netgear DM602, Solwise SAR100 & SAR130 and probably many others.

Console gamers; playstation, ps2, xbox, whatever; impatient lot that they are, might just want to head straight to the perfect stealth section, though reading the whole page is advised, especially before asking questions about stuff that is well covered right here..

Stealth   (so called)

There's no such thing as complete stealth, not on the internet. The idea that our computer is "invisible to the hacker" is a nonsense, firstly because the word "hacker" is so horribly misused, again, but mainly because the action of stealthing; that is, dropping completely, any inbound packets is, in itself, an indication that there must be something there; a system dropping the packets.

If there were really no machine at such-and-such an IP address, the router at the next hop would simply report that fact, sending an ICMP "host unreachable" message. So why stealth? There are at least three reasons.

Firstly, stealthing is an efficient way for a sysadmin (you), to simply configure your gateway security. With a decent firewall (that is, one with "stateful" inspection, like the Voyager 205's built-in firewall) we can achieve that ninja effect with only a couple firewall rules. Sure it breaks internet protocol, but that matters much less out at the ends of the internet, like we users are. With your gateway secure, you don't have to worry too much about security on the machines behind it, in effect creating a secure area where even Windows98 machines could happily work without fear of constant infection and malicious access.

In essence, we start with "no entry", and then allow particular traffic as required. simplicity, if it can be achieved, is always the best option.

Secondly, a stealthed system sends a message to any potential attacker, saying "this sysadmin is serious about security (or at least knows what it is)", and this is usually enough to move our script-kiddie onto the next, probably easier, target.

Thirdly, as I mentioned in the main page, A stealthed router refuses to needlessly leak information about your computing environment. An NMAP scan of your IP won't have a "fingerprint"..

OK! Let's Stealth!

Like I said, stealthing the 205 is very easy to achieve. We only need to create two rules; the first allowing all outbound traffic, and the second denying all incoming traffic. simple!

create ipf rule entry ruleid 5 dir out act accept storestate enable seclevel high medium low
create ipf rule entry ruleid 500000 ifname public dir in act deny log enable seclevel high medium low

In the web interface, it will look something like this..


image captured before I enabled logging

That's it! It may seem simple, but the first rule, in particular, does a lot. Thanks to the 205's "stateful inspection", this one simple firewall rule will allow us to perform all standard internet tasks, web, mail, FTP, IRC, etc, etc, securely, and without any further configuration whatsoever.

You'll likely see a lot more rules than that. That's because you haven't deleted the others yet. You can do that now, you don't need them. That's right! Delete them ALL! You only need the two rules, above.

If you want to allow some incoming connexion, say for a p2p application, you simply place a rule somewhere between the two stealth rules. Firewall rules are processed in order, counting up from zero, and although, technically, it makes no difference what numbers you use, wherever possible, I like to number my rules according to the ports they cover, or the first port, if the rule covers a range.

For instance, I often use traceroute functions, so I'll need to create a rule (rule id no. 11) for that..

create ipf rule entry ruleid 11 ifname public dir in transprot eq icmp icmptype eq num 11 act accept seclevel high medium low

Now traceroute packets will pass to the LAN unmolested. Trouble is, the in-built rules will obliterate rule 11 the instant you power-cycle the router, so instead I use rule ID 13 for traceroute. Sometimes, in networking, you have to work around things.

tip: as a rule of the thumb, don't put rules right next to each other, numerically, but leave a gap of at least 10. at a later date, you may need to insert another rule in between them.

Generally you will also have NAT rules in place to route the incoming connection to particular "private" machine..

For more details on NAT, as well as many ready-made port-forwarding solutions, check out the recipes page.

To delete a firewall rule, do this..

delete ipf rule entry ruleid 2769

If you ever reboot the router (or switch the power off), the first few in-built rules will sadly be re-inserted. We are still looking for a firmware flash which might successfully resolve this issue!

In the meantime, you might want to keep a small text file with a few handy delete commands, if you ever need to power-cycle the unit, it's easy enough to drag&drop these into a telnet session.

Better yet, if you run Linux, Unix, BSD, Solaris, OS X, or some similar operating system, you can use this handy shell script to do it automatically back with one simple command. There's now a windows version, too

Perfect Stealth (aka "console stealth")

Yes, I know I said there was no such thing as perfect stealth, but this next trick comes pretty damn close. It's also a real handy one for Gamers, particularly console owners, xbox, ps2, etc, anabling you to set-and-forget your router, and have all your games work for ever. Here's how it works..

Normally, if you don't exist on the network, the router at the next hop will send back a "host unreachable" message, but with a stealthed router the incoming packet is simply dropped at our front door. The laws of physics tell us that it has been converted, more-or-less, to heat energy. But it's nowhere on the network, and the "attacking" machine is instantly alerted to the fact that rather than "no host", there is some host eating the packets; aka. firewall.

Let's play hide-and-seek..

But what if, instead of simply dropping the packet, we forward it on to another machine, a machine that doesn't exist? Of course, discovering that there is nothing there, what does the router do? Simple, it responds with a host-unreachable message! To the untrained eye, this looks exactly like we really don't exist! Certainly it will fool most script-kiddies.

Let's play the console..

But what if, instead of pointing the packets at a non-existent machine, we point them at our games console? This is what happens. While the console is switched on, all incoming packets that don't match specific rules (like our eMule port forwarding rules for the peecee) will be forwarded on to the console, in effect creating one big port-forwarding rule for the gaming unit. And when the console is switched off, that empty space in our network becomes the "Perfect Stealth" black-hole.

To achieve this cute effect, you simply replace stealth rule two (from above) with a port forwarding rule routing all spare ports to the console device. If the playstation (or xbox, nintendo, whatever) is at 192.168.1.200, the complete rule set would look something like this (edit the IP to match that of your games console)..

create ipf rule entry ruleid 5 dir out act accept storestate enable seclevel high medium low
create ipf rule entry ruleid 500000 ifname public dir in act accept transprot eq tcp seclevel high medium low
create ipf rule entry ruleid 500002 ifname public dir in act accept transprot eq udp seclevel high medium low
create nat rule entry ruleid 500000 rdr lcladdrfrom 192.168.1.200 lcladdrto 192.168.1.200

The first line is identical to regular stealth, the next two allow tcp and udp traffic to enter the network, and the final rule routes that traffic to the console device/black-hole. The only downside to this technique (which I have tested for some weeks) is that your network has lots of broadcast messages flying around along the lines of "where is machine at 192.168.1.200?". Not enough to cause trouble, but would certainly be worth filtering out if you have any sort of network monitoring tool that logs these kinds of things. The router's investigations into the missing device are quite persistent!

Do I really need all this attack protection?

Ahh, you mean this..

modify fwl global blistprotect enable attackprotect enable dosprotect enable

Good question! And the answer is not so straightforward. The protection offered by the Viking chipset is rather good, but if you do a lot of p2p and online gaming, you may find it interefering with your. If you disable it, the worst that could happen is that an untuned router (one that has not been tweaked and stealthed) could become the victim of a denial-of-service or other attack.

If you leave the attack protections enabled you could face issues where "good" sites are being blacklisted becasue they happen to open a lot of connexions, which sounds very much like your average game server. You may instead prefer to fine tune its parameters - checking your attack logs as you go - allowing your games, whilst still protecting against most potential "bad" connexions.

For many more details, check out section 9.2 of the "SAR130extra2.1notes", available in the corz.org public archive. To find out what the current status is, jump into telnet and try this...

get fwl stats
get fwl ?
modify fwl global ?


a note about online firewall testing..

Before you run any BIG firewall tests, like those at grc.com, ensure you disable blacklist protection, or else the router will blacklist the probing site right at the very start of the test and although it may look like you are secure, you are not! all your ports could be wide open and it would look like stealth! not good. a false sense of security is worse than no security. you see, an attacker striking only once on an open port wouldn't trigger blacklist protection.

switch off blacklist protection..

modify fwl global blistprotect disable

now test!



then re-enable blacklist protection..

modify fwl global blistprotect enable

You can see the log of all the recent attacks on your firewall, . Probe yourself with blacklist protection ON, and watch it fill up. But it will do that anyway.

lastly..

Do check out the main Voyager 205 page if you haven't already, there's some juicy stuff on there. Also check out the recipes page, for some ready-made port-forwarding solutions for BitTorrent, FastTrack/KaZaA, eMule/eDonkey, LimeWire/Gnutella/Gnutella2, Napster/OpenNap, KAD, WinMX, aimster, audiogalaxy, imesh, freenet, etc etc, well, a few of them anyway, it's all the same really.

If things aren't working out for you, don't forget to walk, don't run, through the troubleshooter, especially the checklist at the foot of the page. It's probably something obvious, but perhaps not. If you're trying to something really unusual with your 205, you should definitely tell us about it..

If you want to leave any feedback or ask questions, whatever, you can do all that on the main Voyager 205 page.

If you want to save yourself a lot of trouble, why not use one of our tried-and-tested "ready made" router configuration files? Check them out here. Full instructions within the archives and on that page.


have fun!

;o) corz.org