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

reply to bbarrera

Re: Guidelines for Securing your Router

I am way above my head here but: I think that is the whole reason that he made a generic filter for this purpose. The generic filter drops anything coming in that has a destination IP of the LAN. Then his TCP estab protocol filter allows anything that has a destination IP of the LAN and drops everything else. If I understand what he is doing here correctly. Correct me if I'm wrong.
--
~AL~

You are correct. However, what I'm trying to find out is if that particular filter is necessary for all users since my tests seem to indicate that if you're not using PPPoE, the router will drop these packets even without any filters. Well, at least on my RT314 anyway.

reply to bamboox
I haven't tested without PPPoE. Logically the problem shouldn't exist because Ethernet encapsulation on WAN defaults to enif1. The whole problem is that PPPoE switches the WAN from enif1 to wanif0 interface, and enif1 is a like a zombie -- half alive and not truly dead. Anyways, since I only have a PPPoE connection with DSL modem I haven't tried with Ethernet encapsulation.

My WAN input spoof filter checks source IP address, if claiming to be LAN address then drop. You're right about NAT, that's why I check source and not destination. I also tried a "bounceback" LAN output filter, it drops packets with destination IP address set for LAN address. It also did not work in this particular situation.

So far all is well with DrTCP stealth filters in place, so I haven't tried a generic filter. For extra security I can set "ip tcp mss 0" in menu 24.8. I could try to create a "PPPoE only" filter by skipping over (offset) the first 12 bytes (src and dest MAC addresses) received, and then examine the Ethernet frametype (2 bytes) and decide whether it was a PPPoE, Ethernet, ARP or RARP frame. That may or may not work depending on how wanif0 and enif1 co-exist.

I thought DrTCP's filters checked for destination IP addresses, not source. With regard to spoofed source IP addresses, I think there is no doubt that this is necessary (especially if one allows source routing). However, for non-PPPoE users like myself, I don't see any benefit of applying a filter that checks for a spoofed destination IP (other than being able to log such attempts).

So let me see if I understand the problem correctly--you're saying that packets going through to the enif1 interface aren't routed through the protocol filters? Sounds like a major bug to me.

Yes, in PPPoE mode ONLY, Ethernet packets entering the WAN enif1 interface aren't passed through any filters. The "bug" is that by default the WAN enif1 should be completely disabled for PPPoE -- only PPPoE packets should pass thru WAN port of router. The WAN filters in menu 11.5 only apply to PPPoE packets on the wanif0 interface (which is correct).

Regarding major bug status... there is one application where WAN enif1 makes sense - accessing browser-based management interface of DSL modem. My modem's TCP/IP stack only speaks Ethernet, so if router WAN only allows PPPoE frames than no way to access modem mgmt interface. BUT, router should provide another set of filters on menu 11.5 to control access to enif1. So ideally for PPPoE the router should disable Ethernet packets on WAN port, but allow sophisticated user to enable and filter Ethernet packets if desired.

reply to DrTCP

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.

---

reply to SYNACK
Just checked my message!
I should have mentioned my RT314 is using PPPoE
so if anyone knows where I can find the generic
TCP_WAN_OUT filter which will allow iMRC to function
properly...
that is allow access to port 113, I would be much happy
Thanks

(I don't use mIRC, but I think the following is correct). You could always sniff the traffic to be sure what's going on
I think your mIRC client includes an AUTH server that listens and replies on port 113. This means you cannot just send a RST back, but the client must reply with vital information related to your mIRC session. The stealth filter only blocks outgoing RST, but does not block a valid reply.
If you point 113 to your PC in menu 15 you should be OK.

reply to EricLeViking

Re: Newbee: ZyXel or Netgear

reply to SYNACK

Re: Guidelines for Securing your Router

The default configuration is secure. If you upgrade to 3.25 it is equally secure, but it is less likely to make mistakes that reduce security:

»Router question

With a default server, the security of your LAN rests on the security of your server. A compromised server (happens!) would expose anything on the LAN via the server. Depending on the OS, check out

»www.cert.org/nav/index_red.html

and look for the most serious holes. Then add some filters to block these ports form everywhere!

The defaults are fine and almost anything initiated from the LAN side should work without modification. You router is smart enough to know what to do! Only applications that are not NAT friendly AND are not directly supported with special handling (maybe because it is mathematically impossible) need help with server mappings. Otherwise, they are only needed for ... you could have guessed ... servers.