Jeff Liebermann wrote in news: snipped-for-privacy@4ax.com:
Why not?
This is the definition as to what I condider a FW. I don't like to type so I find what I need to find and I cut and paste.
A firewall protects networked computers from intentional hostile intrusion that could compromise confidentiality or result in data corruption or denial of service. It may be a hardware device or a software program running on a secure host computer. In either case, it must have at least two network interfaces, one for the network it is intended to protect, and one for the network it is exposed to. A firewall sits at the junction point or gateway between the two networks, usually a private network and a public network such as the Internet. The earliest firewalls were simply routers. The term firewall comes from the fact that by segmenting a network into different physical subnetworks, they limited the damage that could spread from one subnet to another just like firedoors or firewalls.
Both solutions can use a packet filter so in someway they do set similar types of rules and make similar types of decisions based on the rules implemented.
And I agree to disagree here about NAT. NAT is not FW software.
By comparing the way NAT functions between two networks, and the way packet screening methods function between two networks, you can see that NAT does not adhere to the firewall definition. NAT does not control access between the networks. Some may argue that NAT does control access because you cannot "see" the internal network. NAT does this not by using rules or filters, however, but through concealment. It hides the network from outside users.
This is where I think a packet filtering solution or packet filtering NAT router falls short. And again I don't like to type.
Packet filtering firewalls allow a direct connection to be made between the two endpoints. Although this type of packet screening is configured to allow or deny traffic between two networks, the client/server model is never broken.
Packet filtering firewalls are fast and typically have no impact on network performance, but it's usually an all-or-nothing approach. If ports are open, they are open to all traffic passing through that port, which in effect leaves a security hole in your network.
Defining rules and filters on a packet filtering firewall can be a complex task. The network administrator must have a good understanding of services and protocols to be able to translate the organization's security requirements and needs into an accurate list of allow and deny rules or filters. In some cases, the task of configuring rules or filters may become so complicated that implementation is impossible. Lengthy access rules or filters can have a negative impact on network performance and be prone to error. As the number of rules or filters increases, so does the amount of time it takes the firewall to make comparison decisions and the chance that an inaccurate rule or filter will be added.
The accuracy of rules or filters on packet filtering firewalls can be very difficult to test. Even if the rules and filters seem simple and straightforward, verifying the correctness of a rule through testing can be a time-consuming process. Sometimes testing results can be misleading and inaccurate.
Packet filtering firewalls are prone to certain types of attacks. Since packet inspection goes no deeper than the packet header information, this method of packet screening is easier to circumvent and cannot protect against attacks directed at the application level. There are three common exploits to which packet filtering firewalls are susceptible. These are IP spoofing, buffer overruns, and ICMP tunneling. IP spoofing is sending your data and faking a source address that the firewall will trust. Buffer overruns typically occur when data sizes inside a buffer exceed what was allotted. ICMP tunneling allows a hacker to insert data into a legitimate ICMP packet.
Packet filtering firewalls do not perform user authentication. Again, this method of packet screening looks at information contained in the packet header and bases decisions on that information alone.
And I consider the FW appliance to out class the packet filtering NAT router with SPI, because the FW appliance's architecture resembles the packet filtering router and dual-homed Gateway architectures and is able to look at a deeper level along with other things like actually breaking the client/server model between two end points, providing services etc.
However, I got nothing against NAT routers. They are a good first line of defense, until you start doing high risk things like port forwarding.
There is something to be said about book and practical knowledge I use them both and I have been doing so since 1971 when I first entered the computer industry.
BTW, Linux is not the greatest thing since *Air, Water and Fire*. ;-)
Duane :)