why do we need to use PIX and ASA firewall while ACLs can filter traffic?

thedrama

This may look stupid, however, we have already filtered packet traffic on
routers going through out and in. So, why are these firewalls used additionally?

peanutnoggin

If your router is processing hundreds of thousands packets or even millions of packets, having to inspect each one to conform to ACL rules is going to be processor intensive. You're setting yourself up for a Denial of Service attack that was not intentional. Plus, with ACLs, you can only get so granular before your router goes belly up!

If you're in a small environment, you can probably get away with having your router inspect each packet, but larger environments will require a dedicated "box" for packet inspection!

Also, no question is stupid... its all a part of learning. Someone else probably had that same question but may have been afraid to ask. Good luck.

-Peanut

thedrama

peanutnoggin wrote: »

If your router is processing hundreds of thousands packets or even millions of packets, having to inspect each one to conform to ACL rules is going to be processor intensive. You're setting yourself up for a Denial of Service attack that was not intentional. Plus, with ACLs, you can only get so granular before your router goes belly up!

If you're in a small environment, you can probably get away with having your router inspect each packet, but larger environments will require a dedicated "box" for packet inspection!

Also, no question is stupid... its all a part of learning. Someone else probably had that same question but may have been afraid to ask. Good luck.

-Peanut

Thank you. So, should we use both ACLs and firewalls?

docrice

The term "firewall" can be generic. Any packet filtering device could be considered a firewall, including a router equipped with basic stateless filtering capability.

IOS access-lists are generally stateless (at least the standard and extended access-lists are). You can always use reflexive ACLs for basic stateful capability, but those can bump up CPU usage a lot since it now has to create and reference state tables. However, those still don't compare to stateful inspection where the filtering device is protocol-aware above layer 4.

The PIX has stateful inspection capabilities with a lot of common protocols. FTP is a prime example. In active-mode FTP, the client initiates a connection to the server for the command channel, and the server initiates the connection to the client for the data channel. Unless the filtering device could actually look into the FTP stream and determine the dynamically-chosen incoming destination port from the server, a stateful ACL (not stateful inspection) will not match the command and data connections together to see they're part of the same stream. Therefore, in IOS you'd have to do:

access-list 101 permit tcp any eq 20 1.1.1.0 0.0.0.31

and apply this to your external interface to allow your internal clients to access public FTP servers via active mode. From a ACL perspective, this is a very generous permit rule (a huge hole in your defense). There's passive mode which alleviates this, but I'm just using this as an example.

http://www.kimiushida.com/bitsandpieces/articles/packet_analysis_ftp/

thedrama

docrice wrote: »

The term "firewall" can be generic. Any packet filtering device could be considered a firewall, including a router equipped with basic stateless filtering capability.

IOS access-lists are generally stateless (at least the standard and extended access-lists are). You can always use reflexive ACLs for basic stateful capability, but those can bump up CPU usage a lot since it now has to create and reference state tables. However, those still don't compare to stateful inspection where the filtering device is protocol-aware above layer 4.

The PIX has stateful inspection capabilities with a lot of common protocols. FTP is a prime example. In active-mode FTP, the client initiates a connection to the server for the command channel, and the server initiates the connection to the client for the data channel. Unless the filtering device could actually look into the FTP stream and determine the dynamically-chosen incoming destination port from the server, a stateful ACL (not stateful inspection) will not match the command and data connections together to see they're part of the same stream. Therefore, in IOS you'd have to do:

access-list 101 permit tcp any eq 20 1.1.1.0 0.0.0.31

and apply this to your external interface to allow your internal clients to access public FTP servers via active mode. From a ACL perspective, this is a very generous permit rule (a huge hole in your defense). There's passive mode which alleviates this, but I'm just using this as an example.

Bits&Pieces: Active vs. Passive FTP

I figured out the CPU banging part, however do your words mean that we must apply standard or extended access-list configuration over PIX or ASA without using router?

docrice

In general practice, you would apply some basic standard or extended ACLs on your front router (at least inbound from the Internet, but also perhaps outbound from your network). You don't want this list too long, otherwise you might end up with a relatively complex ACL which consumes a lot of router resources.

On the real firewall itself (such as the PIX or ASA), you would then apply the granular filtering rules to conform to your corporate security policy. These rulesets could be maybe a dozen to hundreds of lines each. It depends on the environment.

If you router / firewall is experiencing packet drops or other issues due to excessive processing overhead, then some ACL tuning may be required to ensure that the most commonly matched rules are towards the top of the list without breaking security policy requirements. If there's still too much CPU utilization and performance impact, you'll need to upgrade the hardware or change traffic expectations.