http://www.enterastream.com/whitepapers/cisco/pix/pix-practical-guide.html
1. A packet is entering an interface and PIX evaluates the security level for the source and destination interfaces. A low-to-high is allowed only if there is an access-list/conduit that allows the connection and a high-to-low is allowed by default unless a specific access-list/outbound denies it.
2. The packet enters is checked against the statefull session table. If it is part of an already established flow is passed forward in order to be routed out and eventually translated if specified. If the packet is identified as part of a new session it is checked against the access-list applied to the inbound interface (or against the conduits for versions earlier than 6.3)
3. As the packet passed the inbound security check is passed to ASA that performs the inbound network translation (destination NAT).
4. ASA creates an entry in the statefull session table and the timers are started for that session. The packet gets routed out to the interface designated by the routing table.
5. At the exit interface eventual source translation is performed - if specified by using global statements and nat groups
6. The packet is delivered out to the next hop router or to the final destination if it is present in the local firewall’s subnets.
PIX-OS later than 5.3
Access lists are the newly recommended security enforcement mechanism.An access list is applied to an interface and checks all traffic with no difference between the direction of traffic as outbound (high-to-low security) and inbound (low-to-high security).
Access lists are statefull and are part of the ASA engine.
The access list is applied only when a packet enters the firewall through an interface.
No checking is performed when it exits the firewall using the destination interface.
The flow is defined only once in the access-list that applies for the interface where the flow enters the firewall.
We can make a comparison with Checkpoint FW1/NG which has the option to check a flow when it enters and also when it exits the firewall. This increases the security but downgrades the processing speed.
Some of the features of ACLs in the new PIX-OS ver 6.3 and later:
1. Accept comments (remarks) so that each statement that is part of an ACL can be commented for a more readable security policy (essential feature for a firewall administrator that was missing in the previous PIX versions)
2. Statements are numbered permitting insertion of new statements at any desired position.
3. Accepts TCP/UDP port ranges.
4. Introduces the use of groups of objects for an easier management.
The ACL statements are checked in a sequential order exactly as they have been defined.
All hits that qualify for a specific statement are logged. In order to log all dropped traffic visibly specify the implied #deny ip any any statement at the end of the ACL.
An ACL becomes active and assigned to an interface when it is associated with it using access groups.
The matching policy is the first pattern match is chosen to drop or allow the data flow. For improved performance define the most used statements first.
Important: for security reasons PIX does not use the native VLAN. When define the VLAN interfaces do not use the native VLAN.
PIX treats the trunk link a little bit differently than a regular router that performs trunking. It just does the tagging/de-tagging operation.
Configuration summary:
On the physical interface define the VLAN as logical interfaces.
At least one VLAN has to be defined as physical in order to instruct PIX to perform tagging on the physical interface. The other VLANs are defines as logical interfaces
1. As observed in the above example, PIX architecture requires individual static statements for each pair of interfaces in order allow access to that translated IP. The static statement is essential in “publishing” the local host to that specific interface and making it accessible through that interface.
2. It is mandatory to define a “transparent” static translation when you access any host from a lower security interface to higher security interface. The static translation could be called transparent because there is no real address translation; it is only an IP address publishing in order to allow the access.
Example:
In order to access the server 10.0.0.100 situated behind the inside interface from the dmz02 interface you have to define a “transparent” static translation as follows:
#static(inside,dmz02) 10.0.0.100 10.0.0.100 netmask 255.255.255.255
You can observe that the global and local IPs is one and the same and no real translation is done. This is mandatory and is part of PIX’s specific architecture. It brings an additional level of security by the fact that even you might have the access lists/conduits to allow the access, it will not work unless you specifically designate which host(s) are published for access.
This transparent static is required only for inbound transactions from a lower security to a higher security interface. No specific statics are required when you access from a higher security to a lower security interface, unless you want to do explicit source address translation.
