If you have a LAN, it's often good form, IF you want unrestricted LAN access for local services without a lot of rules, to START the ruleset with an allow any rule for an IP range of the LAN addresses you use, and another rule allowing the subnet broadcast address. While it's up to you to decide, firewalls are much easier to configure, and much easier to do log analysis with, if you do not use DHCP, but a static block of private IP's, if you're behind a router... that rule, if desired, could be placed here.




DNS is fundamental:



... and can be followed with a neat deny and set this for alert:




If you use DHCP to retrieve a dynamically assigned IP address from your ISP or router, you can tighten up on the generic rule provided with a pair of rules, like this:




and protocol specific rules, for example:



Next, among the basics you'll want to have for getting started out, you can use the following as a guide to some sample ICMP rules; this can be a good place to put a generic loopback, if you want to use one:



/under construction! :)/

Yes. This intimidating looking list, below, is actually overkill for any beginner, and it's soon to be replaced. The series of denies, marked "ignore," are anti-spoofing rules. The rest are identified by their function. To understand these rules, you need to understand the machine they're on, and that the list is meant to contemplate almost every basic firewall situation we might encounter, without being overly complex for a beginning or an intermediate user.

The machine has two NIC's, only the 10 range is trusted. The LAN operates over the 10 range. The 172 range is a TCP only net. It carries internet traffic, as well as some local intranet traffic. It is behind a router ("NAP," network access point), and the DHCP rules are disabled in this configuration, because the router provides DHCP client services for the network.

The rules labelled "proxy access rules" are designed to "bunker" the browser and other apps required to pass through the proxy, and force them to use the local proxy server as their only means of accessing the internet (in this case, proxomitron on port 8080; these rules can be adapted to any filter or proxy server running on the local machine). They also bunker the proxy server, by denying access to any app not explicitly permitted to use the proxy to reach the internet. This is very important! If you use a proxy server, you have a natural firewall tunnel on your computer! The firewall cannot filter any request that passes to the proxy. It only sees the proxy asking for access. To prevent this, we make a rule denying access and alerting us if anything not permitted by rule tries to reach the proxy on localhost. This is an excellent example of ordering a series of rules to create a conditional with rule processing logic... examine the logic of how it works... IF the app is listed THEN allow it to access localhost 8080 ELSE IF app requesting access is IE AND access is requested to an address other than localhost THEN deny access ELSE IF any unlisted app THEN deny access to localhost port 8080 and prompt the user.

A very important thing to remember is that IE needs UDP access to 127.0.0.1 to maintain its caches. It will slow browsing to a crawl, if this is denied. You will note the first rule in the specialized proxy section allows IE full UDP access to localhost to accomodate this.

The "proxomitron" entry is the first normal internet application. As a rule, you will allow authorized applications "outbound TCP" or "outbound TCP/UDP" access only. Inbound is tantamount to allowing the application to act as a server, and should always be used with care.

The rest of the ruleset is a list of the internet apps on the machine.

It should be noted that you don't have to, and aren't even advised to, copy this ruleset verbatim... it's meant to show a subset of some of the various tricks this firewall is capable of. The most important rules for a beginner are identified as "DNS" "DHCP" and "ICMP". The rest are optional or special purpose rules.

Note too that the "block foreign DNS" is out of order. This is an error. It should e directly under the DNS entries. It lets the user know if something wants to access a foreign nameserver, which may be legitimate, so it alerts to a denied DNS request, in case the ISP changes the server, or an app uses a non-standard nameserver (and you'll usually know if you need that).




This ruleset is by no means comprehensive or suggested. They're provided as a guide and an example. Also, as the crude annotations no doubt imply, there will be a more permanent solution as soon as possible.