ASA Features and Services
Summing up the exact features of an ASA could take quite a while because most of the features discussed in the previous chapter related to firewalls and different implementations are included in ASA. ASA provides the following features:
Packet filtering: Simple packet filtering normally represents an access list. It is also true with regard to this feature that the ASA provides. The ASA supports both standard and extended access lists. The most significant difference between an access list on an ASA versus an access list on a router is that the ASA never ever uses a wildcard mask. Instead, if it needs to represent a mask related to a permit or deny statement in an access list, it just uses the real mask in the access control list (ACL).
Stateful filtering: By default, the ASA enters stateful tracking information about packets that have been initially allowed through the firewall. Therefore, if you have an ACL applied inbound on the outside interface of the firewall that says deny everything, but a user from the inside makes a request to a server on the outside, the return traffic is allowed back in through the firewall (in spite of the ACLs that stops initial traffic from the outside) because of the stateful inspection that is done by default on the initial traffic from the client out to the server, which is now dynamically allowing the return traffic to come back in. This is probably the most significant and most used feature on the ASA. One way of thinking about stateful filtering is to imagine that the ASA is going to build a dynamic permit entry in a virtual ACL that will permit the return traffic. Suppose that you are sending a packet to a web server. Your source address is 10.4.4.4, and your source TCP port is 4444. The destination IP address of the server is 10.5.5.5, and the destination port is TCP 80 (web/HTTP). The ASA will (virtually, as this is just a way to consider it) remember this outbound session and expect to see a return packet from 10.5.5.5 destined to 10.4.4.4 (the client), and the source port is TCP:80 (for the return packet), and the destination port is TCP:4444 (again going back to the client). The “virtual” ACL, or state table, that is dynamically created by the ASA would say, “Please permit this packet (the return one) from the outside network to the inside network where the client is waiting for this reply.”
Application inspection/awareness: The ASA can listen in on conversations between devices on one side and devices on the other side of the firewall. The benefit of listening in is so that the firewall can pay attention to application layer information. An example of this is a client on the inside of our network going to an FTP server on the outside. The client may open a connection from a source port of 6783 to the well-known FTP port of TCP:21. During the conversation between the client and the server, stateful inspection is inspecting traffic (and allowing reply traffic inbound from the outside networks) as long as the source IP address is the server and the source port is 21 (coming from the server back to the client) and the destination port is 6783. That is how stateful inspection works. Unfortunately, some applications, such as FTP, dynamically use additional ports. In the case of standard FTP, the client and the server negotiate the data connection, which is sourced from ports 20 at the server and destined for whatever port number was agreed to by the client. The challenge with this is that the initial packets for this data connection are initiated from the server on the outside. As a result, normal stateful filtering denies it (either by default rules or an ACL that is denying initial traffic from the outside). With application layer inspection, the ASA learns about the dynamic ports that were agreed to and dynamically allows the data connection to be initiated from the server that is on the outside going to the client on the inside.
Network Address Translation (NAT): You learned about the benefits of NAT and Port Address Translation (PAT) earlier in this book, and it comes as no surprise that the ASA supports both of these. It supports inside and outside NAT, and both static and dynamic NAT and PAT, including Policy NAT, which is only triggered based on specific matches of IP addresses or ports. There is also the ability to perform NAT exemption (for example, specifying that certain traffic should not be translated). This comes in handy if you have NAT rules that say everybody who is going from the inside networks out to the Internet should be translated, but at the same time you have a virtual private network (VPN) tunnel to either a remote user or a remote network. Any traffic from the inside network going over the VPN tunnel in most cases should not be translated, so you set up an exemption rule that says traffic from the inside networks to the destinations that are reachable via the VPN tunnels should not be translated. The policy that indicates that traffic should not be translated is often referred to as NAT zero.
DHCP: The ASA can act as a Dynamic Host Configuration Protocol (DHCP) server or client or both. This is a handy feature when implementing a firewall at a smaller office that might require getting a globally routable address from our service provider through DHCP and at the same time the ability to hand out addresses to the internal DHCP clients at that location.
Routing: The ASA supports most of the interior gateway routing protocols, including Routing Information Protocol (RIP), Enhanced Interior Gateway Routing Protocol (EIGRP), and Open Shortest Path First (OSPF). It also supports static routing.
Layer 3 or Layer 2 implementation: The ASA can be implemented as a traditional Layer 3 firewall, which has IP addresses assigned to each of its routable interfaces. The other option is to implement a firewall as a transparent firewall, in which the actual physical interfaces receive individual IP addresses, but a pair of interfaces operate like a bridge. Traffic that is going across this two-port bridge is still subject to the rules and inspection that can be implemented by the ASA. The ASA can still perform application layer inspection and stateful filtering.
VPN support: The ASA can operate as either the head-end or remote-end device for VPN tunnels. When using IPsec, the ASA can support remote-access VPN users and site-to-site VPN tunnels. When supporting Secure Sockets Layer (SSL), it can support the clientless SSL VPN and the full AnyConnect SSL VPN tunnels (which hand out IP addresses to remote VPN users, similar to the IPsec remote VPN users). SSL is a very upcoming and popular option for VPNs and is only used for remote access, not for site-to-site VPNs.
Object groups: An object group is a configuration item on the ASA that refers to one or more items. In the case of a network object group, it refers to one or more IP addresses or network address ranges. The benefit of an object group is that a single entry in an ACL could refer to an object group as the source IP or destination IP address in an individual access control entry (a single line of an ACL), and the ASA logically applies that entry against all the IP addresses that are currently in the object group. If an object group has four IP addresses in it, and we use that object group in a single entry of an ACL that permits TCP traffic to the object group, in effect we are allowing TCP traffic to each of those four IP addresses that are in the group. If we change the contents of the group, the dynamics of what that ACL permits or denies also change.
Botnet traffic filtering: A botnet is a collection of computers that have been compromised and are willing to follow the instructions of someone who is attempting to centrally control them (for example, 10,000 machines all willing [or so commanded] to send a flood of ping requests to the IP address dictated by the person controlling these devices). Often, users of these computers have no idea that their computers are participating in this coordinated attack. The ASA works with an external system at Cisco that provides information about the Botnet Traffic Filter Database and so can protect against this.
Advanced malware protection (AMP): The Cisco ASA provides next-generation firewall (NGFW) capabilities that combine traditional firewall features with thread and advanced malware protection in a single device. AMP allows an administrator to protect the network from known and advanced threats, including advanced persistent threats (APT) and targeted attacks.
High availability: By using two firewalls in a high-availability failover combination, you can implement protection against a single system failure.
AAA support: The use of authentication, authorization, and accounting (AAA) services, either locally or from an external server such as Access Control Server (ACS), is supported.