 DrTCPYours trulyPremium,ExMod 1999-04
join:1999-11-09
Round Rock, TX
| reply to SYNACK
Re: Guidelines for Securing your Router 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] |
