Re: Guidelines for Securing your Router

Author	All Replies
Sentinel Premium join:2001-02-07 Florida kudos:1	reply to andy_c Re: Guidelines for Securing your Router 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?
	to forum · permalink · 2001-03-17 15:29:28 ·
andy_c join:2001-01-31 Pflugerville, TX	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]
	to forum · permalink · 2001-03-17 17:18:32 ·
Sentinel Premium join:2001-02-07 Florida kudos:1	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.
	to forum · permalink · 2001-03-17 19:32:28 ·

DrTCP Yours truly Premium,ExMod 1999-04 join:1999-11-09 Round Rock, TX	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.
	to forum · permalink · 2001-03-17 20:35:42 ·
andy_c join:2001-01-31 Pflugerville, TX	reply 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?
	to forum · permalink · 2001-03-17 21:39:37 ·
Sentinel Premium join:2001-02-07 Florida kudos:1	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.
	to forum · permalink · 2001-03-18 00:06:00 ·
SYNACK Just Firewall It Premium,Mod join:2001-03-05 Venice, CA Host: Networking Virtual Private Ne.. Netgear ZyXEL	reply 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!
	to forum · permalink · 2001-03-18 11:18:26 ·
bbarrera Premium,MVM join:2000-10-23 Sacramento, CA kudos:1 Reviews: ·SureWest Internet	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]
	to forum · permalink · 2001-03-18 12:00:59 ·
Sentinel Premium join:2001-02-07 Florida kudos:1	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. -- ~AL~
	to forum · permalink · 2001-03-18 13:05:11 ·
andy_c join:2001-01-31 Pflugerville, TX	reply 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!
	to forum · permalink · 2001-03-18 13:36:25 ·
Awgeewhiz Gort, Klaatu Barada Nikto Premium join:2001-03-04 Delta, PA	andy_c: Um, any chance of cutting/pasting the details of your new rule set here?
	to forum · permalink · 2001-03-18 13:58:32 ·
SYNACK Just Firewall It Premium,Mod join:2001-03-05 Venice, CA Host: Networking Virtual Private Ne.. Netgear ZyXEL	reply 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.
	to forum · permalink · 2001-03-18 14:19:04 ·
Sentinel Premium join:2001-02-07 Florida kudos:1	reply 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?
	to forum · permalink · 2001-03-18 14:21:44 ·
Sentinel Premium join:2001-02-07 Florida kudos:1	reply 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?
	to forum · permalink · 2001-03-18 14:34:42 ·
SYNACK Just Firewall It Premium,Mod join:2001-03-05 Venice, CA Host: Networking Virtual Private Ne.. Netgear ZyXEL	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.
	to forum · permalink · 2001-03-18 14:42:53 ·
bbarrera Premium,MVM join:2000-10-23 Sacramento, CA kudos:1	reply 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...
	to forum · permalink · 2001-03-18 14:52:14 ·
andy_c join:2001-01-31 Pflugerville, TX	reply to Sentinel 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.
	to forum · permalink · 2001-03-18 15:15:49 ·
Sentinel Premium join:2001-02-07 Florida kudos:1	reply to SYNACK So this theoretical UDP filter might look like this: 1 Y IP Pr=17, SA=0.0.0.0, DA=0.0.0.0, DP=68 N F N 2 Y IP Pr=17, SA=0.0.0.0, DA=0.0.0.0, DP=1024 N F N 3 Y IP Pr=17, SA=0.0.0.0, DA=0.0.0.0, DP=1025 N F N 4 Y IP Pr=17, SA=0.0.0.0, DA=192.168.0.0, N F D R1, R2 & R3 forward those ports. R4 allows NAT session UDP and drops all else(providing you put 255.255.255.0 in the dest IP mask). Am I getting close here?
	to forum · permalink · 2001-03-18 16:19:36 ·
SYNACK Just Firewall It Premium,Mod join:2001-03-05 Venice, CA Host: Networking Virtual Private Ne.. Netgear ZyXEL	said by alotero: So this theoretical UDP filter might look like this: ... 4 Y IP Pr=17, SA=0.0.0.0, DA=192.168.0.0, N F D Am I getting close here? Just a note. I would NEVER drop on not matched! Imagine you have a TCP packet (e.g. from your web return traffic) passing this filter. Since it does not match (it is NOT UDP!) the filter will most likely drop it! (Unless this has changed with the newer firmware. This was the case when I was still using protocol filters) This is the reason for my rule #5!
	to forum · permalink · 2001-03-18 16:54:46 ·
Sentinel Premium join:2001-02-07 Florida kudos:1	Duh, of course. Sorry about that. Yes, that is obvious now. So it should look more like this: 1 Y IP Pr=17, SA=0.0.0.0, DA=0.0.0.0, DP=68 N F N 2 Y IP Pr=17, SA=0.0.0.0, DA=0.0.0.0, DP=1024 N F N 3 Y IP Pr=17, SA=0.0.0.0, DA=0.0.0.0, DP=1025 N F N 4 Y IP Pr=17, SA=0.0.0.0, DA=192.168.0.0, N F N 5 Y IP Pr=17, SA=0.0.0.0, DA=0.0.0.0, N D F Providing this is the last rule of a chain.
	to forum · permalink · 2001-03-18 17:38:35 ·

Equipment Support > Hardware By Brand > Netgear > Guidelines for Securing your Router