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 thats 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 (OReilly): 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.htmWhat 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 its 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 DefaultsLets 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! Ill 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 dont 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 dont know the details).Summary for the default configurationWith 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 serversFirst 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 NoiseMake 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 filtersNow 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 filteringBlock 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 youre 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 StealthNormally, 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, dont reply at all, and remain stealth or blocked. Stealth can be achieved by various means. If you dont 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 youre 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 StealthThe 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.SpoofingDOS 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 optionsDrTCPs filters check the IP header size and reject anything oversized, thus containing any IP options.
This is a great idea and we dont 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 firewallInformation 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, youre 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 considerThere 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 thats a different issue.Testing and LoggingAfter 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 whats 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 dont provide ANY useful information in the log.