Basic Firewall Concepts

History
When networking was constrained to only connection between our own computers, no one
needed a firewall -- heck the necessity had not arrived and there were none. As soon as
the Internet started serving files, there was a rash of infections and rome started to burn --
hence the term Firewall. In large commercial buildings, the building is sectioned into areas
separated by walls certified to withstand a fire on one side of xxx degrees for yyy minutes.
This gives the occupants time to evacuate to safety.

A computer firewall attempts to keep the fire (ie: intruders) out of your system(s) forever.

Controlling Network Access
Our networks provide ingress and egress (inbound & outbound) activities. The firewall
will monitor and control both. TCP operates by

1. one system opening a socket
2. binding it to a port
3. making a connection to the remote system
4. which accepts or rejects it
5. if accepted, the traffic flows in both directions over the single connection

Historically, our systems needed ingress or inbound protection and the firewall only needed to control event [E].
Today with Identity Theft, Keyloggers and Botnets, our systems also need egress / outbound control of event [C].

Simple IP & Port Control
Ignoring the Identity Theft, Keyloggers and Botnet problems, a simple firewall
(like that of XP/SP2) can be effective by two simple default rules:

1) allow all outbound activity
2) deny all inbound activity

Rule (2) is found in all firewalls to simplify the number and complexity of managing the firewall.
If left like this, our system could connect to anyone but could not host any services
like Exchange, Print/File Sharing or IIS (or Linux daemons like SMTP, Samba or Apache2).
Hence, there's always a means to add rules to control the allow / deny events [a,e] above.

Consider the parameters of the connection and you can see the knobs used to make the rules:

1. direction of flow {in/out/both}
2. the protocol {TCP,UDP,ICMP,IP}
3. the ip-address of the source system
4. the port used on the source system
5. the ip-address of the remote system
6. the port on the remote
7. the permission to be set {allow, deny}
8. optional actions (log | alert)

There are variations to some of these such as a range of ports to be controlled, eg 135-139.

Usually we set separate rules for inbound and outbound access even if the traffic will flow
over the same connection. For example

• [sample]Allow Tcp in dst-ports=137-139,445
  Allow Tcp out dst-ports=137-139,445[/sample]

This creates what is known as a hole in the firewall for specifically this case, Print/File Sharing.
As shown, we have control but this is still unsafe! WHY?
Because we allow connections to or from any system on the internet to all our shares
To restrict the access to only our known lan systems, we need the ip-subnet of our LAN.
(a full subnet might be 192.168.1.1-192.168.1.255 or sometimes expressed as 192.168.1.1/24).

To make our LAN secure for Print/File sharing we add the source and destination ip-address ranges to the above rules, eg:

• [sample]Allow Tcp in src-ip-range=192.168.1.1/24 dst-ports=137-139,445
  Allow Tcp out dst-ip-range=192.168.1.1/24 dst-ports=137-139,445[/sample]

Additional Services
Better firewalls have an Application Monitor Service, which effectively adds the program name to our firewall rules.
Without this feature, as soon as we allow
[sample]Allow Tcp out dst-ip=any dst-port=25[/sample] we can send email by programs such as Outlook, Outlook Express, and Thunderbird. However, this also allows
%userprofile%\local settings\temp\somekeylogger to do the same

With the Application Monitor Service, each program attempting to open ANY outbound port
is monitored and you can allow/deny on a permanent or one-time basis.
It is quite easy to see the difference between your known and unknown programs and thus
stop Identity Theft, Keyloggers and Botnet problems in their tracks.

__________________
J. O. Beard; you + tech-101.com => synergism. Secure your system now