Norton Firewall Trusted Zone with Router

Discussion in 'other firewalls' started by SpongeBob, Aug 11, 2004.

Thread Status:
Not open for further replies.
  1. SpongeBob

    SpongeBob Registered Member

    Joined:
    Mar 28, 2004
    Posts:
    24
    I run WinXP Pro SP1. I have a wireless router with built-in hardware SPI firewall and I use Norton Internet Security 2004 Pro (NIS2004). I also use TDS3, ProcessGuard, SpyBlocker, SpywareStopper and SpywareBlaster.

    My question regarding NIS firewall is concerning the trusted zone, which is accessed via the Networking tab.

    In the trusted zone I have placed the IP addresses of my ISP's two DNS servers.

    I have also placed the address of my router into which my cable modem is plugged... IP: 192.168.0.0 - Mask: 255.255.255.0

    I assumed this is necessary in order for the router to work properly, but someone mentioned recently that by doing this I am automatically allowing an internet connection to anything on my machine that requests it because my router (and therefore the internet) is classed as trusted. Surely this can't be correct?

    Please can someone advise me if this is a security risk or not, and how I should set this up if I don't trust the local network/router?

    SB.
     
  2. CrazyM

    CrazyM Firewall Expert

    Joined:
    Feb 9, 2002
    Posts:
    2,428
    Location:
    BC, Canada
    Hi SB

    Having the LAN subnet in the trusted zone will permit all network traffic between those systems only. Access to and from the Internet (WAN) is still restricted by the firewall rules.

    Regards,

    CrazyM
     
  3. Paranoid2000

    Paranoid2000 Registered Member

    Joined:
    May 2, 2004
    Posts:
    2,839
    Location:
    North West, United Kingdom
    It is not advisable to list any Internet addresses here - this would allow all traffic to those servers when you only need to allow DNS traffic. You should instead create a rule to allow DNS (UDP protocol, remote port 53) to those addresses instead.
    This will allow access to addresses in the range 192.168.0.1 to 192.168.0.254 - you could tighten this to cover your router only by specifying its address with a 255.255.255.255 mask (e.g. 192.168.0.1/255.255.255.255).
    You could dispense with the trusted zone completely if you are prepared to define all the necessary rules for your router individually. This however can take time and some experimentation - you would most likely need rules for DHCP (used by your PC to get an IP address lease from your router) and HTTP (to access your router via your browser to change its configuration). You may also need rules for DNS (if your router has the option of acting as a DNS server) and HTTPS (encrypted webpage access for router configuration).
     
  4. CrazyM

    CrazyM Firewall Expert

    Joined:
    Feb 9, 2002
    Posts:
    2,428
    Location:
    BC, Canada
    Just to expand on the Trusted Zone in NIS.

    You do not need to add the router's IP or LAN subnet in order for the router to work. It should work fine without this. If your router has logging capabilities and you log to a server on a LAN, this would require a rule.

    What entering the LAN subnet in the Trusted Zone does do, is simplify allowing LAN traffic/file-printer sharing. Restricting the entry in the Trusted Zone to just the router's IP will likely effect sharing between systems on the LAN, so you are better off allowing the subnet if you are going to use it.

    The caveat with the Trusted Zone is this traffic bypasses the firewall allowing all traffic between defined systems/IP's and there is no way to monitor/log it.

    The alternative is to create specific rules to allow the LAN traffic you need. This is done in the General Rules section of the rule set.

    As Paranoid2000 suggested, there is no real need to add your ISP's DNS servers to the trusted zone. NIS already has default DNS and DHCP rules which you could modify/restrict to your ISP's servers.

    Regards,

    CrazyM
     
    Last edited: Aug 12, 2004
Loading...
Thread Status:
Not open for further replies.