Drop/permit packets based on their source or destination addresses or port#s
No context is kept (memory less)---decision solely based on current packet contents
Filtering ma be done at the incoming interface, the outgoing interface, or both.
Ingress filtering: refers to traffic coming into your organization
Egress filtering: Outbound packet security is called egress filtering.
Rules are applied from top to bottom. So the last rule should be to block all those that don’t fit in the above rules.
* OUR-GW Allow * * * * Block 25 OUR-GW * * Allow block action * src * SPIGOT * Port dest port
Limited connections are permitted through thr router between GW and the outside world
Very limited, but possibly different, conections are permitted between GW and anything on NET 2 or NET 3
Any thing can pass between Net 2 and NET 3
Outgoing calls are allowed between NET 2 or NET 2 and the external link
Rule set for external interface at the router (that is filtering packets coming in from the outside world)
Rule set on the router’s interface to NET 1
Total degradation due to filtering depends on the number of rules applied at any point.
It is better to hav eone rule specifying a network rather than to have several rules enumerating different hosts on that network.
Also, speed up things by ordering the rules so that the most common types of traffic are processed first.
Deal with the details of the particular service they are checking
Special purpose code needed for each application
Easy to log and control all incoming and outgoing traffic---e.g., checking mail message for specific words.
Web queries can be checked for conformation with organizational policies
E-mail is generally passed through an application-level filter
Work at TCP level---TCP connections are relayed through a computer that essentially acts as a wire
A client wishing to connect to a server, connects to the relay host supplying the needed info. The name and IP are not available to the server.
IP packets now flow from server to host, filtered and then to the client (like NAT)
Circuit relays are generally used to create specific connections between isolated networks
SOCKS – Circuit-level gateway Protocol
SOCKS is an Internet protocol that allows client-server applications to transparently use the services of a network firewall . SOCKS is an abbreviation for "SOCKetS"  .
Clients behind a firewall, needing to access exterior servers, may connect to a SOCKS proxy server instead. Such proxy server controls the eligibility of the client to access the external server and passes the request on to the server. SOCKS can also be used in the opposite way, allowing the clients outside the firewall ("exterior clients") to connect to servers inside the firewall (internal servers).
Rather than have a separate box on the edge of the network reject all inbound packets to port 80, this rule is enforced by every host.
What Firewalls cannot do
They are not a panacea
Useless against attacks from insiders (legitimate user with a bad intention)
Firewalls act at a specific layer and are not concerned about other layers
Transitivity is a problem: If A trusts B, and B trusts C, then A trusts C whether or not it wants.
Errors in rules or firewall is a serious threat.
More complex than packet filters---look at the details of the particular service they are checking
Special code for each desired application
Easy to control and log all incoming and outgoing traffic
Look for inappropriate or confidential words
Check if web queries are in conformance with company policies
Strip dangerous attachments
E-mail is usually passed through an application-level gateway
Work at the TCP level
Firewall Problems (i) Inadvertent problems
Example: Suppose a company has a policy to drop all e-mail coming through the gateway, to avoid exposure to mail-borne viruses. If port 80 is left open, Web mail services (e.g., gmail, hotmail) introduce a new avenue for malicious cod eto get in, via-e-mail-over-Web tunnels.
Example: Admin errors are the most common cause of trivial firewall problems. A large set of complex rules is a cause of such problems.
IP fragmentation problems---if the destination port# part is in a different fragment than the ACK or SYN, then the firewall will not be able to decide whether or not to allow ACK or SYN packets since it does not know if it is part of a current conversation.
If initial fragments are at least 16 bytes long, the problem can be avoided. Alternately, the firewall can do the reassembly. This is expensive.
Technique of using ICMP echo and ICMP responses and DNS queries to get information about systems beyond a firewall.
Firewalk is an active reconnaissance network security tool that attempts to determine what layer 4 protocols a given IP forwarding device will pass. Firewalk works by sending out TCP or UDP packets with a TTL one greater than the targeted gateway. If the gateway allows the traffic, it will forward the packets to the next hop where they will expire and elicit an ICMP_TIME_EXCEEDED message. If the gateway hostdoes not allow the traffic, it will likely drop the packets on the floor and we will see no response.
To get the correct IP TTL that will result in expired packets one beyond the gateway we need to ramp up hop-counts. We do this in the same manner that traceroute works. Once we have the gateway hopcount (at that point the scan is said to be `bound`) we can begin our scan.
It is significant to note the fact that the ultimate destination host does not have to be reached. It just needs to be somewhere downstream, on the other side of the gateway, from the scanning host.