dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
43230

SYNACK
Just Firewall It
Mod
join:2001-03-05
Venice, CA

SYNACK

Mod

Guidelines for Securing your Router

Here are some guidelines on router security. It is in no way complete, but should give some hints and will hopefully start some discussions to refine the points. There are probably many errors that people will point out to me. At this time I will NOT give any specific filters, but once a consensus is reached we can easily make a list of examples.

Most discussions will apply equally to all models based on ZyNOS. Even the P312/ZyWALL contains all the generic and protocol filtering; the stateful firewall code is added on top of it.

All security policies on the basic routers (P310, RT311, RT314, P314) are based on NAT(SUA) and packetfiltering.

(Compared to most of the competition, they are not "basic" at all, and allow quite granular filtering. Many cheap routers have security based solely on NAT, but that’s another story).

The Situation is a little different for the P312/ZyWALL where most policies are handled by the stateful inspection engine. Nevertheless, all packet filters are also available, but are typically only used to do some simple pre-filtering if needed. Special consideration for ZyWALL will be mentioned as appropriate. Some people are wondering about the difference between the P312 and ZyWALL. Both have similar hardware specs and can run the SAME firmware. The P312 is the older model in a classic stackable P310 case while the ZyWALL has the compact case of the P314, but colored in silver.

The first priority should be basic security from unwanted outside sources. Later the settings can be refined to lower the visibility crossection, blocking unwanted outgoing packets, lower vulnerability, etc.

Some recommended reading:
"Building internet firewalls" by Chapman and Zwicky (O’Reilly): A little old, but a good introduction to packet filtering and port requirements of various applications.
"Secrets and Lies" by Bruce Schneier (Wiley): Entertaining to read discussions of general internet security issues.
The ZyWALL manual has a pretty nice section on firewall issues. Download it from here:
»www.zyxel.com/support/do ··· wall.htm

What are some of the threats?
Most unsolicited probes are random subnet sweeps looking for exploitable machines. Many times they target port 111, 53 or 21 and thus will not find anything on a stock Windows9x/ME machine and can be ignored. If these ports respond, you are most likely running a poorly secured Unix machine and further exploits will be tried in many cases. These probes typically never come directly from the home IP of the "evil prober", but from some intermediate host that has been compromised by a root-kit. If you run an exposed server, it is important to keep up with the newest exploits and patches to lower the vulnerability of exposed services.
Other sweeps, e.g. direct probes to port 139 are specific to Windows machines and were a signature of certain Trojans (e.g. Qaz) looking to spread to neighboring machines via open shares. These sightings have quieted down a bit, but were high in Q3-Q4 of 2000. In most cases these probes are not intentional, but simply point to a machine that, unaware of it’s owner, is already infected. Probes for sub7 trojans are also quite popular.
Direct denial-of service (DOS) attacks against your IP. Any regular e-mail and newsgroup post will have your real IP in the header, and it might also be exposed to participants of chat programs or online games. Somebody might not like your ramblings and might thus launch a classic DOS (SYN flood, teardrop, etc) attack against your IP (stealth or not!). An attacker with unlimited time/skill might try other exotic stuff like packets with illegal header combinations or weird ICMP types.
If the router is used in a commercial setting, there could be other targeted attacks, e.g. to obtain company secrets.

What are NOT threats?
There is always a significant amount of network noise, unintentionally generated by other users or part of the regular maintenance traffic. All low-level packets (arp, stp, etc) are non-routeable and are typically not a security concern (?).
On the IP level, there will always be a certain number of broadcast and multicast packets. These packets have a destIP that is NOT your IP, but your interface cannot ignore them. (If the interface in addition also looks at ALL other IP packets, it is called promiscuous mode as used by packet sniffers)
Broadcasts have a destIP of 255.255.255.255, (0.0.0.0, rarely, but possible), or the actual subnet broadcast address. Some attacks, e.g. smurf, send echo requests to the broadcast address, creating a flood of responses from unpatched machines thus overloading the network.
Multicasts have destIP in the range of 224.0.0.0 to 239.255.255.255, in other words they match for IP=224.0.0.0, Mask:240.0.0.0. They can be dropped with a single filter if desired.
Broadcasts and multicasts are not targeted specifically and thus are rarely (never?) directed attacks. Typically these are UDP (pr=17), but sometimes IGMP (pr=2). They can never be connection based like TCP (pr=6), because a connection requires exactly two endpoints.



Factory Defaults

Let’s first look at the factory default:
- Default password
- NO SUA mappings (menu 15)
- Default filters. (menu 21)
ZyWALL/P312 only: Default policy=permit all LAN-WAN sessions, drop all incoming sessions.
The ZyWALL has tons of additional built-in security, e.g. All spoofed packets are dropped, All SMTP commands are inspected (try a manual SMTP session via telnet and type e.g. DEBUG and the connection will be immediately shutdown by the firewall. Certain ICMP packets (e.g. redirect) will trigger an alert and get dropped. For a good discussion, it is instructive to read sections 13+ of the ZyWALL manual.


Out of the box, the biggest security hole is the default password! It is essential to change this to something strong, especially if you plan to "play" with filters later. Accidental mistakes happen. There was also an exploit that allowed under certain conditions access to the router password prompt by overflowing the NAT table with SYN packets. A strong password will keep everybody out of the router, even if the filters would fail.

All readers that still have the default password should change it right now! I’ll wait here

Do NOT underestimate the security implications of a router compromise. Control of the router gives ultimate control to the entire LAN via access to filters and NAT settings. This needs to be prevented at all cost. A compromised router can even be a launching point for further intrusion attempts, apparently coming from YOUR IP, just try "ip telnet victimsite.com" (or also "ip telnet yourLAN.telnet.server" that you thought was protected by an WAN filter.)

TCP (with factory default rules)
The default configuration has no NAT server mappings. The only things that need to be protected are the embedded services running on the router (port 21,23,80/TCP). The default filter #3 already achieves this. Do NOT remove it! Everything else is protected by the inherent firewall properties of NAT.

The ZyWALL does not allow any incoming TCP connections, period. Not even to default servers or 1-1 mapped hosts.

UDP(with factory default rules)
UDP is not filtered from the outside. As with TCP, in the absence of server mappings we only need to be concerned about services running on the router. This needs some attention, because it seems that certain services, e.g. SNMP might reveal information.
There are quite a few services running on the router, lets have a look: The command "ip udp st" reveals the following UDP ports active: (161, 1024, 53, 67, 68, 1025, 69, 263, 520, unfortunately, we cannot tell on which interfaces: LAN, WAN or BOTH).
Port 53 is DNS, used for the DNS proxy for LAN clients.
Ports 67, 68 are used for DHCP client (WAN) and server (LAN).
Port 69 TFTP can be used for firmware upload. While regular TFTP has absolutely no security or authentication, the ZyNOS flavor of TFTP is very secure. It will only accept connections from hosts that have an already established telnet connection to the router. It indirectly uses the telnet password authentication for security. TFTP was used for upgrades via the obsolete PNC configuration tool.
Port 161 SNMP: Configured in menu 22 if available.
Port 263 is HDAP: PNC (First gear) software used this to find all available routers on the subnet. It is probably only active on the LAN side.
Port 520 is RIP. Defaults are off for WAN (menu 11.1) and enabled for LAN (menu 3.2). Most people can turn it off for LAN, too, unless they use a more complex LAN topology with multiple routers.
1024, 1025: These are probably dynamic ports for return traffic, e.g. ongoing DNS lookups.

All these services should be evaluated to determine if they are vital or should be blocked from the outside. It was discussed here recently that SNMP could reveal loads of information. Incoming 161/UDP should be blocked or SNMP should be configured more securely in menu 22 (custom community name, etc.).

The stateful inspection of the ZyWALL/P312 maintains a connection state even for stateless protocols such as UDP and ICMP. Thus it knows if a packet is allowed return traffic or a sneaky probe, no matter what protocol or port is targeted. The ZyWALL rejects anything from the outside.

ICMP (with factory default rules)
All incoming ICMP is allowed and pings are answered. It is not clear if any special ICMP types pose a security risk, because I don’t know how the router will react to them under NAT. Maybe somebody with the right tools can do some tests to verify.

(Historical side note: An earlier firmware had a bug where an incoming ICMP source quench (type 4) shut down the connection. These packets are very rare and only the main gateway router of newsguy was apparently configured to send those out when congested. It took some detective work to figure out why people got randomly disconnected downloading newsfeeds from that site, while everything else was perfect. A quick generic filter for ICMP type 4 was the instant cure until the next firmware release)

(ZyWALL: Dangerous ICMP types are blocked and create alerts. These are: redirect, timestamp, and address mask related types). Other types are handled according to the connection state as appropriate (I don’t know the details).

Summary for the default configuration
With menu 15 empty, All LAN computers are safe and protected by NAT. Everything incoming will end up at the router and it is sufficient to adequately protect the active services hosted on the router.


Securing the router is the most important issue to secure your network! Once the router is secure we only need to look at menu 15 and modify according to the specific needs of LAN servers listed there. Remember, the ONLY leaks to the LAN are in the NAT(SUA) mappings!


What if there is a server mapping in menu 15?
Based on the above, this is now easy. The server computer will have to deal only with the mapped port (e.g. port 80 for web server) and filter #3 should be modified to pass that service. The router still takes the onslaught on ALL other ports.

What if there is a default server?
A default server mapping is insecure because it will have absolutely no NAT protection. Depending on the OS of the default server, filters should be placed to block certain unwanted traffic (e.g. port 111 for Unix, or port 139 for windows). It is also recommended to secure the default server further with a personal firewall (zonealarm, tiny, etc.) or other means (ip-chains, TCP-wrappers, etc.).

What if I use Multi-NAT?
A custom firmware is apparently available that supports multi-NAT from ZyXEL France. Due to memory constraints, Web configuration is not implemented. MultiNAT supports multiple WAN IPs that can be mapped in many ways to LAN computers. Popular is a 1-1 mapping that maps one of the WAN IPs directly to a LAN computer. Security wise, this is similar to a default server. With multiple 1-1 mappings the required filtering can get quite complex.

The ZyWALL has double the RAM and ROM and always supports multi-NAT. Securing the various servers is very easy with a few firewall rules. A single firewall rule can consist of several source and destination IPs, IP ranges and IP subnets, and can contain many services, custom ports and port ranges. It would be very difficult to duplicate this with packet filters alone.

Summary for NAT servers
First priority is to keep the router safe!
Second, look in menu 15 to see where the holes are. Only mapped ports need further consideration.



Lowering Noise

Make sure that your router does not leak to the WAN. Turn off RIP, etc. The default filters 1 and 2 prevent Netbios related packets from leaking out.

Lowering the Visibility and fine-tuning of filters
Now that the router, your LAN network and your servers are protected, we can tweak the filters to lower visibility and also get a better rating on certain online scanners. If you run any public servers you probably want to be visible. Many ISPs prohibit public servers and many home users just need to have a private server to be accessible from the work PC or a branch office. In this case, we can just define a rule to allow packets with certain source IPs, but remain invisible to the rest of the world.

We probably can expand this section later.



Some popular tricks:

ICMP filtering
Block incoming ping request: This is not a bad idea and will prevent certain port scans.
Things to consider:
Make sure to inactivate this filter before calling ISP tech support; they might want to ping you to look at packet loss or latency.
There is anecdotal evidence that certain ISPs drop your connection if you’re not pingeable.
Certain online scans give a clean bill if ping is disabled, leading to a false sense of security. If the result looks to good to be true, enable ping and rerun the test.
Basic network research uses random pings, e.g. I have been probed by skitter recently: »www.caida.org/tools/meas ··· skitter/
Why not let them do their research?

Other ICMP: ICMP packets are control messages, and certain types are required for the health of the connection, see e.g.: »www.robertgraham.com/pub ··· html#8.1 for some guidelines on what to allow.

ZyWALL: ping is blocked by default. Other ICMP types have reasonable defaults.

TCP Stealth
Normally, unwelcome TCP SYN packets to a port without associated service is answered by a RST packet, indicating that the port is closed. Some firewalls break this protocol convention, don’t reply at all, and remain stealth or blocked. Stealth can be achieved by various means. If you don’t have servers and can live with passive ftp, all SYN packets from the outside can be dropped by a rule that specifies only TCP-estab=yes and drop if matched. This prevents any TCP connection from the outside, but allows any return traffic to pass freely.
Another possibility is to block outgoing RST as suggested by DrTCP. This provides stealth appearance for all ports that are closed, but allows anything to active server ports. This is NOT safe for a default server, unless you are fully aware of all running services that can be reached. Watch out for trojans!
Many SMTP servers probe port 113 and expect at least a RST before allowing the SMTP session to complete. Thus port 113 cannot be stealth and an exception must be made with yet another rule.

ZyWALL: By default all ports except 113 are stealth while port 113 is closed. This is configurable via CI commands, e.g.:
zywall> sys firewall tcprst disp
TcpRstSend to port 113 = ON
TcpRstSend = OFF

Stealth has also disadvantages. If you’re NOT stealth, most online testers will scream at you that all ports are ONLY closed, but stealth is MUCH better and can be achieved e.g. with their product. Some of this is hype and marketing, and for all practical purpose a closed port is safe. If you can live with these accusations and warnings because you know better, NON-stealth has certain advantages. For example, online scanners can scan many more ports in much shorter time so there is a lower threshold to actually test all ports, a process that would be prohibitively slow under stealth.
Another common trick to achieve stealth is to enter an unused IP as default server. This uses resources because connection attempts will consume NAT entries and cause fruitless ARPs on the LAN. While on other router brands this might be the only solution, it is highly recommended to use filters instead (because we can!).

UDP Stealth
The equivalent of a TCP RST is an ICMP(3,3) for UDP. Should we block this outgoing too?
I believe the ZyWALL can decide if it belongs to an allowed ongoing or just killed UDP connection or a random external probe and can thus act accordingly.

Spoofing
DOS attacks are often carried out with spoofed source IPs. However, any legal IP can be spoofed equally well so we cannot filter based on this. I would recommend rejecting incoming packets with a source IP corresponding to your LAN.

IP options
DrTCP’s filters check the IP header size and reject anything oversized, thus containing any IP options. This is a great idea and we don’t have to deal with source route in the protocol filters (source route is one possible IP option). Today, there are no legitimate uses for any IP options. If you really need to use IP options yourself to troubleshoot a complicated networking issue, you can disable this filter easily. Even the Chapman book states that many packet-filtering firewalls drop ALL packets with any options set without any problems. Be aware that most generic filters will have unexpected results if the IP header is oversized. It is very difficult (impossible?) to write a generic filter set that works also with IP option packets.

Things we cannot protect with a firewall
Information leakage to external packet sniffers.
Sophisticated attacks based on packet sniffing, e.g. hijacking of an existing connection.
Many of these require wire access and considerable skills, but if your “enemy” works at the cable company, you’re out of luck.
If your LAN has unencrypted wireless components, LAN access can be achieved without even involving the firewall by tapping directly into the wireless branch from hundreds of yards away. If some LAN computers have modems that can dial the Internet, we have another potential firewall bypass.
Other potential problems are attacks by insiders, social engineering, unethical online merchants, etc.

Other things to consider
There are many other topics such as privacy issues (cookies, etc), bugs/exploits in the OS and in browser components (Java, ActiveX, etc) that travel with a regular user-initiated connection. It is important to keep everything patched and upgraded and use common sense. Web browsers allow adjusting the balance between security and functionality.

ZyWALL: Content filtering allows selective blocking of cookies, activeX, etc. and blocking based on strings in the web address, as well as many other criteria.

A good anti-virus scanner with current signatures and safe computing practices are still required, but that’s a different issue.

Testing and Logging
After any modification of the filters, it is absolutely necessary to test if they perform as designed. Key rules should have "log=matched" so we know that the probe actually tested our box. Generally, it is useless to add a rule that cannot be tested, except maybe the test for IP header size. Constant logging of potentially interesting events is always fun and you will get a feeling what’s out there. If somebody seems really interested in your box, you can take preventive measures, e.g. completely block that IP or even notify the source ISP if it gets too annoying after a while. Unfortunately, generic filters don’t provide ANY useful information in the log.

Awgeewhiz
Gort, Klaatu Barada Nikto
Premium Member
join:2001-03-04
Delta, PA

Awgeewhiz

Premium Member

Really nice article Synack.
The kind of thing Ignoramuses like me can really use.
Thanks
Sentinel
Premium Member
join:2001-02-07
Florida

Sentinel to SYNACK

Premium Member

to SYNACK
Great job Synack! Thank you. Now we are beginning to get somewhere in understanding all this stuff. I hope this is just the first in a series of posts that will enlighten us all.
System

to SYNACK

Anon

to SYNACK
Wow, what a lot of info! I'll be rereading it after I pick up my RT314 from my friend (he's buying a cisco or something). Finally getting aDSL in my area March 27!!!!!

Just wanted to mention that "Building Internet Firewalls" is out with edition 2, as of June 2000.

chris

bbarrera
MVM
join:2000-10-23
Sacramento, CA

bbarrera to SYNACK

MVM

to SYNACK
Excellent guidelines! One suggestion - a section at the end on "Designing Filters" using info from one of your previous posts:

Some rules of Thumb
- Generic filters are cheapest because they occur before NAT.
- If possible use more=yes, it is more efficient because it keeps the same packet in the buffer for further tests.
- protocol filters incur the cost of NAT translation + filtering.
- always drop at the earliest convenience. (e.g. Don't drop an incoming packet at the LAN output if you can already drop it at the WAN input).
- If your rule logic permits, put the filters in order of dropping probability. Put the filters that throw away many packets before filters that almost never drop anything.
- Logging is relatively expensive (don't set log=both on all rules, right? )
- Limit logging to SYN packets (TCP estab=Yes), so you get one entry per connection instead of one entry per packet. Big difference!
- Unlike the ZyWALL/P312, the basic routers have no stateful inspection. Remember however that NAT is stateful. You can harness that fact to design some primitive statefulness into your rules. If a UDP packet has a destIP on your LAN, it is part of an ongoing NAT connection, while a destIP of the WanIP would indicate otherwise. Make sure you don't kill the DNS proxy mechanism, DHCP, and possibly other router hosted UDP services.

head_spaz
Byte-Me
join:2001-01-29
Searcy, AR

head_spaz to SYNACK

Member

to SYNACK
.
[text was edited by author 2001-04-08 18:05:40]

SYNACK
Just Firewall It
Mod
join:2001-03-05
Venice, CA

SYNACK to Anon

Mod

to Anon
said by deneshac:
Just wanted to mention that "Building Internet Firewalls" is out with edition 2, as of June 2000.
... and went from 500 to 850 page!
Thanks.
There must be quite a bit of new info. One of these day, I have to upgrade.
SYNACK

SYNACK to head_spaz

Mod

to head_spaz
said by deewm:
Very good job SYNACK. Are you a ZyXel employee?
...
Question:
There are a lot of sites suggesting that TCP/IP should NOT be bound (WAN or LAN) for file and print sharing and that NetBEUI should be used on the LAN instead since it is reported to be a non-routable protocol
Thanks ... Nah. I have I fun day job and it's NOT in networking

There is nothing wrong with NetBIOS over TCP/IP (NBT) behind a NAT router. My networks at home and at work are exclusively TCP/IP. I even have pinholes in the firewall and map port 139/TCP so I can access my shares remotely.
(I DO use rules with a very restricted range of allowed source ports, logging of all connections in the firewall, and still strong passwords on all shares. I have never logged anything suspicious, ever).

If you just share within your private LAN, its perfectly safe. You need TCP/IP anyway, why not use it for everything?

A computer should be as "clean&mean" as possible. No unnecessary protocols, not tons of stuff that I never use in the systray. It increases stability to keep everything simple. The computer will start faster, run faster and crash less.

(I agree that running NetBIOS over TCP/IP on a fully exposed computer without router/firewall is risky, just because the entire implementation has security holes, see e.g.:
»www.insecure.org/stf/cifs.txt.
There is no logging whatsoever, and once a connection is established one could try passwords day and night at a high rate until success. There is no delay after a failed attempt and no disconnect after a certain number of unsuccessful tries. WRITE access to the base (C) or windows directory would allow the planting of all kinds of nasty programs that would automatically run next time you reboot.)

MediaONE/RR/AT&T block all NetBIOS ports in the cablemodem, so even people buying multiple IPs and hooking everything to a hub are safe with NBT. (My ISP filters are out so I can share, see above)
[text was edited by author 2001-03-18 18:22:53]

DrTCP
Yours truly

join:1999-11-09
Round Rock, TX

DrTCP to SYNACK

to SYNACK
said by SYNACK:
Another possibility is to block outgoing RST as suggested by DrTCP. This provides stealth appearance for all ports that are closed, but allows anything to active server ports. This is NOT safe for a default server, unless you are fully aware of all running services that can be reached. Watch out for trojans!
True, my filters do not enhance security over what NAT provides. They primarily provide hiding with minimal intervention in router's operation. So, the risks involved by opening ports especially specifiying a default host is the same as without my filters.

For port forwarding/default host, I strongly suggest a firewall software on local PC.

Also, The exposure to the default host can be reduced by using protocol filter that blocks all SYN (TCP estab) packets for the destination IP of default host (keeping other hosts free from restrictions). Of course, one should create proper "allow" filters before this filter or otherwise there will be no point of specifying a deafult host. Please not estab filtering is only for TCP. You should properly filter other protocols enabling only allowed ports and dropping the rest.
quote:
Many SMTP servers probe port 113 and expect at least a RST before allowing the SMTP session to complete. Thus port 113 cannot be stealth and an exception must be made with yet another rule.
I had created a version of my TCP_WAN_OUT filter to deal with this situation. It is in a recent thread but I can dig it out.
quote:
IP options
DrTCP’s filters check the IP header size and reject anything oversized, thus containing any IP options. This is a great idea and we don’t have to deal with source route in the protocol filters (source route is one possible IP option). Today, there are no legitimate uses for any IP options. If you really need to use IP options yourself to troubleshoot a complicated networking issue, you can disable this filter easily. Even the Chapman book states that many packet-filtering firewalls drop ALL packets with any options set without any problems. Be aware that most generic filters will have unexpected results if the IP header is oversized. It is very difficult (impossible?) to write a generic filter set that works also with IP option packets.
Today, I found that Netmeeting 3.0 running on Windows 2000 tries to use RSVP protocol (RFC-2205) and this protocol (in raw mode) uses an IP option (IP Alert Option - RFC-2113) increasing the IP header to 24 bytes. Hence, my filters were dropping these (relatively infrequent) packets but it did not seem to affect performance. RSVP RFC talks about encapsulating RSVP in UDP instead of RSVP but I am not sure if it is used by Windows 2000 or Netmeeting. It is highly likely transit routers are ignoring this so blocking them is not a big deal. I tried Netmeeting on Windows 98 and it did not use RSVP. I think it is because RSVP/QoS is provided by Windows 2000 stack.

BTW, RFC-2113 talks about IGMPv2 (Multicast) also using "IP Alert Option"
[text was edited by author 2001-03-17 05:34:15]
andy_c
join:2001-01-31
Pflugerville, TX

andy_c to SYNACK

Member

to SYNACK
Excellent post SYNACK! I changed a few items in my filter as a result of reading it.
I'd like to mention some additional info about the port 53 vulnerability found by a scan using vulnerabilities.org. The report said this:

"Warning found on port domain (53/tcp)
The remote name server allows recursive queries to be performed by the host running nessusd.
If this is your internal nameserver, then forget this warning.
If you are probing a remote nameserver, then it allows anyone to use it to resolve third parties names (such as www.nessus.org). This allows hackers to do cache poisoning attacks against this nameserver.
Solution : Restrict recursive queries to the hosts that should use this nameserver (such as those of the LAN connected to it). If you are using bind 8, you can do this by using the instruction 'allow-recursion' in the 'options' section of your named.conf
If you are using another name server, consult its documentation.
Risk factor : Serious


I've found that the 53/tcp indication is in error. This occurred when I had all unsolicited TCP traffic blocked via "TCP Established = yes", and these filters were logging dropped TCP traffic on port 53 during the scan. After I first ran the scan, I changed several things at once, reran the scan, and the problem went away. I wanted to try a more scientific approach to see if I could get the problem to go away and come back by only changing one thing.

I've been able to repeatedly make the problem disappear and come back by enabling and disabling respectively a filter which blocks incoming WAN UDP traffic on port 53. This process was done with the filter that drops unsolicited incoming TCP traffic *disabled*, so I know it's not a TCP problem.

Because of this, I've made the filter that drops incoming port 53 UDP WAN traffic a permanent part of my filter set.
Sentinel
Premium Member
join:2001-02-07
Florida

Sentinel

Premium Member

Synack:
Oddly enough, after reading this part of your great post:

What are some of the threats?
Most unsolicited probes are random subnet sweeps looking for exploitable machines. Many times they target port 111, 53 or 21 and thus will not find anything on a stock Windows9x/ME machine and can be ignored.

I checked my logs and I have numerous entries from an IP in Korea on port 111.

Andy_c?
So are you saying that you have the TCP estab filter and you like it because it blocks port 53? Or that you had it and didn't like it so now you have a special filter for port 53?
andy_c
join:2001-01-31
Pflugerville, TX

andy_c

Member

said by alotero:
Andy_c?
So are you saying that you have the TCP estab filter and you like it because it blocks port 53? Or that you had it and didn't like it so now you have a special filter for port 53?
At the time I did the original scan, I had the "TCP established" filter in place. The scan showed a port 53/TCP vulnerability, yet my logs showed that port 53 TCP traffic was being dropped by the "TCP established" filter. This is a contradiction, so I assumed that the reported error (53/TCP) was incorrect. I tried blocking port 53 UDP traffic, and that fixed the problem. In fact, the problem is still gone even if the "TCP established" filter is removed, as long as the port 53 UDP filter is still in place. So the report is in error. It's a port 53 UDP problem, not a port 53 TCP problem.

I have subsequently modified the "TCP established" filter so that the "action on match" and "action on not matched" is just "check next rule", and the only thing it does is log on match. This is due to problems I was having with FTP as SYNACK mentioned in his post. The FTP application protocol sequence involves the FTP server initiating a TCP connection which is unsolicited in the TCP sense (but definitely solicited in the FTP application protocol sense). This causes the directory listing step to fail in WS_FTP. I can fix it by enabling PASV mode, but WS_FTP wants this setting changed for each connection individually - it can't be set globally as far as I can tell. Also, I can't find a way to enable FTP PASV mode in Internet Explorer.

So now I'm back to the standard filters, but with additional UDP filters for port 161 (SNMP) and port 53. I am no longer "full stealth" in scans that report this, but I'm becoming swayed by the view that stealth is way, way overrated. In my case, it came at the price of a big inconvenience with the FTP issue. My current non-stealth configuration shows no vulnerabilities at all with the vulnerabilities.org tester. Also, I finally realized the level of security that was being provided by NAT. A simple thought experiment based on my previous experience getting Napster uploads to work proved this. With Napster running, I essentially have a server running, listening on port 6699. Yet nobody could upload files from me! Of course, I had to direct port 6699 traffic to the desired machine in menu 15. I don't know why it took me so long to realize this, but it finally dawned on me that I could have an open server on any machine behind the router, but if traffic isn't explicitly directed to it, "it ain't gonna get there" . So I realized that all my attempts to achieve stealth amounted to the router being stealth. That seems like a complete waste. But I'm no expert, so it could be that I'm oversimplifying things.
[text was edited by author 2001-03-17 18:14:37]

[text was edited by author 2001-03-17 21:16:19]
Sentinel
Premium Member
join:2001-02-07
Florida

Sentinel

Premium Member

So the TCP established filter did effectively close port 53 for TCP but did nothing for UDP. So you added a filter for port 53 UDP. I understand now.

I left my TCP Established filter in since I have no problems with FTP. I found a setting in IE under Advanced for passive FTP. Also, I use WS_FTP with no problems with that filter in place. Odd that I have no problems with it.

DrTCP
Yours truly

join:1999-11-09
Round Rock, TX

DrTCP

UDP is connectionless protocol. There is no connection establishment packets (SYN) like in TCP to filter! Hence, Estab filtering do nothing for any protocol except TCP.
andy_c
join:2001-01-31
Pflugerville, TX

andy_c to Sentinel

Member

to Sentinel
said by alotero:
I left my TCP Established filter in since I have no problems with FTP.
Hmm, interesting. Here's a log entry I get when making an FTP connection. This is from my "log only" TCP established filter.

RAS: IP[Src=206.103.63.121 Dst=192.168.1.33 TCP spo=00020 dpo=01306]}S04>R01mN

What's strange about this is the destination IP address reported is my LAN IP address, rather than the WAN IP address that's reported in all other filter log entries. I'm guessing the router "knows" about FTP and treats it specially, and the difference in the logs shows this. If I block these packets, FTP only works in PASV mode. I'm not sure what's different between your setup and mine that's causing the different behavior.
said by alotero:
I found a setting in IE under Advanced for passive FTP. Also, I use WS_FTP with no problems with that filter in place. Odd that I have no problems with it.
I'm using IE 5.01 and couldn't find any option for PASV FTP. I'm going to guess that you're using 5.5?
Sentinel
Premium Member
join:2001-02-07
Florida

Sentinel

Premium Member

Yes, I am using IE 5.5 and I use WS_FTP in passive mode too. Perhaps that is the difference. I only FTP in passive mode. Maybe that is why I haven't had a problem yet(operative word is yet). If I do have to FTP to or from someplace that is active FTP only I guess I can just deactivate that rule for a few seconds for the download.

DrTCP
Yours truly

join:1999-11-09
Round Rock, TX

DrTCP to SYNACK

to SYNACK
I've obtained this link from Linksys forum. They are currently trying to figure out what "Stateful Packet Inspection" (SPI) feature in beta firmware is supposed to do. I think it is releavant here since SYNACK mentioned SPI features of P312/ZyWALL

»www.avolio.com/apgw+spf.html

SYNACK
Just Firewall It
Mod
join:2001-03-05
Venice, CA

SYNACK to andy_c

Mod

to andy_c
said by andy_c:
RAS: IP[Src=206.103.63.121 Dst=192.168.1.33 TCP spo=00020 dpo=01306]}S04>R01mN

What's strange about this is the destination IP address reported is my LAN IP address, rather than the WAN IP address that's reported in all other filter log entries. I'm guessing the router "knows" about FTP and treats it specially, and the difference in the logs shows this. If I block these packets, FTP only works in PASV mode
See, now we are getting somewhere! Remember that I mentioned earlier that NAT has some kind of "statefulness" and that we could tap into this?

Well NOW we can! So far, I tried to discuss "why" and "what", now this thread can drift into the "how"!

Imagine a filter:
(1) TCP-estab=Yes, destIP="yourLAN-Subnet", forward if matched
followed by
(2) TCP-estab=Yes, destIP=0.0.0.0, drop if matched

This would forward any SYN packet that have a NAT translation, meaning they are expected by NAT via some special treatment and are thus part of an ongoing connection. (Or are already mapped in menu 15, see below).

For good measure, we should drop with a generic filter anything that has a destIP=C0A8, e.g. the dest IP starts with 192.168, just to make sure. (On the same WAN subnet, it is possible to fabricate a packet with destIP=192.168.x.x, but containing your WAN MAC in the ethernet header. I am not sure what the router would do with it.)

If you are on a static IP, you could do it with ONE rule:

(3) TCP-estab=yes, destIP=WAN IP, drop if matched.

Drops anything without NAT translation.

Unfortunately, we cannot do this on DHCP, because there is no placeholder for "current WAN IP". We also cannot invert the IP/mask logic, otherwise we could define
(4) "... destIP != LAN-IPsubnet , drop".


So, if you put rules (1) and (2) in place, you have the worlds first primitive SPI filter set in ZyNOS.


!!!Be aware that anything defined in menu 15 ALSO has a destIP=on the LAN. Make sure all holes are plugged!!
It will not drop anything if you define a default server!
EricLeViking
join:2001-03-18
.

EricLeViking to SYNACK

Member

to SYNACK

Newbee: ZyXel or Netgear

Hello,
i live in Europe. The official price for the ZyXEL 314 is
400 US $ :-(
The Netgear is cheaper 200 US $.

If i buy a Netgear, can i flash it to support ZyXel add (snmp,ntp,...)
If not, can i buy a ZyXEL prestige 314 from buy.com ?

Eric

»www.surf.be

bbarrera
MVM
join:2000-10-23
Sacramento, CA

bbarrera to SYNACK

MVM

to SYNACK

Re: Guidelines for Securing your Router

quote:
(On the same WAN subnet, it is possible to fabricate a packet with destIP=192.168.x.x, but containing your WAN MAC in the ethernet header. I am not sure what the router would do with it.)

With default filters in place, the RT314 will allow destIP=192.168.x.x with WAN MAC in the Ethernet header. I've verified this using telnet from my 3Com ADSL modem. Without anti-spoof filter on RT314, I can telnet into the router (even with TEL_FTP_WEB_WAN filter in place)! For example, if the router LAN IP is 192.168.1.1 you can telnet into router from WAN side by running command "telnet 192.168.1.1" on the ADSL modem.

(Edited) Forgot to add that this only works if 3Com modem's management interface is on the same subnet as router LAN. So in this case the router's WAN interface sees packets with LAN src & dest IPs, and router passes the packets through to LAN side. The performance of telnet is terrible, but it does work. This seems like a bug, because somehow the router sends telnet replys with LAN destIP back out the WAN interface (but very slowly). However, I cannot telnet into router from modem IF the router and modem are on different subnets.

I just bought a hub to run some additional experiments from the WAN side of the router (using another computer and packet sniffer software). Don't have a lot of time these days, but I'll publish results when I finish.
[text was edited by author 2001-03-18 12:17:17]

[text was edited by author 2001-03-18 12:37:05]
Sentinel
Premium Member
join:2001-02-07
Florida

Sentinel

Premium Member

Two questions in one post.........

bbarrera,
You said that without a spoof filter in place you could get in but you neglected to say whether or not you could get in WITH the common spoof filter that many of us use in place. The filter I speak of is the one like this:
Y IP Pr=0, SA=192.168.0.0 (with a subnet of 255.255.255.0) N D N
So could you?

Synack,
In your post you spoke of some possible open UDP ports. By doing your ip udp st command I saw that I had the 8 ports you mentioned open as I assume most of us do (I didn't have 161 since I am running the Netgear firmware). Related to that part of your post I have 2 questions.

1. Where in menu 11.1 can we turn off RIP? I have turned it off on lan in menu 3.2 a long time ago but I can't find it for WAN on menu 11.1?

2. If we make a filter like the following:
1 Y IP Pr=17, SA=0.0.0.0, DA=0.0.0.0, DP(less than)67 N D N
2 Y IP Pr=17, SA=0.0.0.0, DA=0.0.0.0, DP(greater than)68 Y N N
3 Y IP Pr=17, SA=0.0.0.0, DA=0.0.0.0, DP(less than)1024 N D N
4 Y IP Pr=17, SA=0.0.0.0, DA=0.0.0.0, DP(greater than)1025 N D F

That would close all UDP except what is necessary for DNS from our ISP's. ComptrGuy tried something like this but it didn't work for me since he only allowed 67 & 68. From the command you showed us, I see that perhaps 1025 & 1025 are necessary as well. Maybe that is where he went wrong. Would the above filter be good then? I am trying it out now but I have only come to this web site so far so I dont know how it will do.
andy_c
join:2001-01-31
Pflugerville, TX

andy_c to SYNACK

Member

to SYNACK
said by SYNACK:
So, if you put rules (1) and (2) in place, you have the worlds first primitive SPI filter set in ZyNOS.

This is very cool! I now have the following filters for WAN incoming:

1.) Stock Tel_FTP_Web_WAN
2.) A new filter set, consisting of:
a.) Block TCP packets whose source IP is the same as the LAN
b.) Block UDP packets on port 161 (SNMP vulnerability)
c.) Block UDP packets on port 53 (DNS vulnerability)
d.) SYNACK's rule (1)
e.) SYNACK's rule (2)

The filters are working great! I don't need passive FTP anymore. Moreover, I don't need to explicitly forward port 6699 TCP traffic for Napster - it's implicitly taken care of by SYNACK's rule (1) and the NAT forwarding in menu 15.

Thanks very much SYNACK!

Awgeewhiz
Gort, Klaatu Barada Nikto
Premium Member
join:2001-03-04
Delta, PA

Awgeewhiz

Premium Member

andy_c:

Um, any chance of cutting/pasting the details of your
new rule set here?

SYNACK
Just Firewall It
Mod
join:2001-03-05
Venice, CA

SYNACK to Sentinel

Mod

to Sentinel
said by alotero:
1. Where in menu 11.1 can we turn off RIP? I have turned it off on lan in menu 3.2 a long time ago but I can't find it for WAN on menu 11.1?
...
That would close all UDP except what is necessary for DNS from our ISP's. ComptrGuy tried something like this but it didn't work for me since he only allowed 67 & 68. From the command you showed us, I see that perhaps 1025 & 1025 are necessary as well. Maybe that is where he went wrong. Would the above filter be good then? I am trying it out now but I have only come to this web site so far so I dont know how it will do.
I will catch up on some of the other recent posts in this thread later, but here's just a quick reply to your specific questions. Remember that I run a ZyWALL so I don't need these UDP filters. The ZyWall has a default firewall rule that only allows 68/UDP (DHCP client) from the outside so DHCP can work. You do not need to open 67/UDP (DHCP server) from the outside. Your router listens on the LAN for DHCP requests broadcast to 67/UDP from computers that need configuration, but you hopefully don't hand out configurations on the WAN. (Since a computer without configuration has no idea about local IPs, masks, etc. the DHCP request are sent to 255.255.255.255.)
Do some tests with logging and renew your lease to see what's needed from the WAN.

Since these are not really "ranges" you could open each port individually, it is just easier on the brain (at least mine):
1) pr=17, port=68, forward, else next
2) pr=17, port=1024, forward, else next
3) pr=17, port 1025, forward, else next
4) pr=17, dest=LAN subnet, forward, else next
5) pr=17, any port, drop, else next
...
I really haven't studies the traffic patterns in detail, so I don't know if the the router uses any other dynamic UDP return ports if need arises. (In the absence of NAT mappings (menu 15), rule 4 allows UDP that is part of a NAT session, and thus most likely wanted, and rule 5 drops any other UDP).

RIP on the WAN is off by default, so you should be safe. (try "ip rip st" to verify.) To turn it off, you go to menu 11.1 (menu 11...edit IP=yes) and set RIP Direction=none.
Sentinel
Premium Member
join:2001-02-07
Florida

Sentinel to andy_c

Premium Member

to andy_c
Something I don't understand here andy. First of all you don't have DrTCP's ICMP filter in there. This even Synack says is good because of the IP header size check in there.

Secondly, it appears to me that your filter #2 rule A drops all incoming packets with source address of the LAN but then your rule D allows packets with a source address of the LAN that have a TCP Estab. How will D work if A already blocked all packets with that address? Am I missing something here?
Sentinel

Sentinel to SYNACK

Premium Member

to SYNACK
I never saw that menu 11.3 before! Holy cow. Thanks Synack.

I don't get the R4 line there. Dest=LAN subnet? Would that mean the following?

Filter Type= TCP/IP Filter Rule
Active= Yes
IP Protocol= 17 IP Source Route= No
Destination: IP Addr=
IP Mask= 255.255.255.0
Port #=
Port # Comp= None
Source: IP Addr=
IP Mask=
Port #=
Port # Comp= None
TCP Estab= N/A
More= No Log= None
Action Matched= Forward
Action Not Matched= Check Next Rule

Or would we have to put in the ip address of 192.168.0.0 too?

SYNACK
Just Firewall It
Mod
join:2001-03-05
Venice, CA

SYNACK

Mod

said by alotero:
Or would we have to put in the ip address of 192.168.0.0 too?
Sorry about being too cryptic.

A subnet is a combination of a Subnet address (192.168.0.0) and a Subnet Mask (255.255.255.0). So, Yes, you need both!

Just a note: All this is theoretical for me and I haven't tested it. Make sure you test so there are no loose ends.

bbarrera
MVM
join:2000-10-23
Sacramento, CA

bbarrera to Sentinel

MVM

to Sentinel
I'll put spoof filter in router, then try to telnet from modem into router tonight. Yardwork and kids are calling me to another duty now...

SYNACK
Just Firewall It
Mod
join:2001-03-05
Venice, CA

SYNACK to EricLeViking

Mod

to EricLeViking

Re: Newbee: ZyXel or Netgear

said by ericvane:
Hello, i live in Europe...If not, can i buy a ZyXEL prestige 314 from buy.com ?
True, the netgear is a little cheaper, but you probably could not use the current $30 mail-in rebate anyway. Be aware that the power supply is not universal. A USA 110V supply will not work in europe).

Differences: Unlike the RT314, the P314 has a crossover switch.
Does anyone know the differences between packed items as currently shipped:
e.g. Cat5 cable, crossover cable, serial cable, printed manual?
[text was edited by author 2001-03-19 00:29:17]
andy_c
join:2001-01-31
Pflugerville, TX

andy_c to Sentinel

Member

to Sentinel

Re: Guidelines for Securing your Router

said by alotero:
Something I don't understand here andy. First of all you don't have DrTCP's ICMP filter in there. This even Synack says is good because of the IP header size check in there.
Well, I'm not a networking expert by any means. I have written some very simple winsock applications that use only TCP, so I feel comfortable with TCP. I'm hesitant to use filters that I don't understand, though. I'm totally unfamiliar with ICMP, as well as the low-level details of packet contents and so forth. So I use only filters that I feel I can successfully reason about, understand and fix any errors that come up. DrTCP's excellent work with filters is unfortunately beyond my understanding at this point. Also, my intent of posting the filters I'm using is to say "This is what I'm using and these are the results I'm getting", rather than "These are the filters *you* should be using". They are examples only.
said by alotero:
Secondly, it appears to me that your filter #2 rule A drops all incoming packets with source address of the LAN...
Yes. This is the "IP spoofing" scenario of mimicking a trusted host (a la Kevin Mitnick) as I understand it. These packets are by definition not wanted.
said by alotero:
...but then your rule D allows packets with a source address of the LAN that have a TCP Estab. How will D work if A already blocked all packets with that address? Am I missing something here?
Ah, but rule D allows packets with *any* source address. It's packets with the LAN *destination* address that rule D is letting through. As mentioned by SYNACK, when the destination address is the LAN address, rather than the WAN address as normally occurs, this means that NAT is treating these packets specially because it "knows" something about them. This is the case with FTP (in non-passive mode) for example. It's also true of forwarded traffic from menu 15, as I've verified by logging Napster uploads.