Internet Network Filtering Part 3

After configuring filtering on the border router, it is time to perform filtering on the firewall. I believe in one rule for inbound Internet traffic to the firewall, only allow what is REQUIRED for the organizations business to function. For the purpose of this article the following services are required for the organization to function:

Widgets Website - 5.2.3.80 [tcp/80]
Widgets Extarnet Site - 5.2.3.143 [tcp/80 & tcp/443]
Widgets Online Database - 5.2.3.44[tcp/80 & tcp/443]
Widgets Email Server - 5.1.2.25 [tcp/25]
Widgets DNS - 5.1.2.53 [udp/53]
Widgets DNS - 5.1.2.54 [udp/53]
Widgets VPN - 5.1.2.123 [udp/500 & udp/4500]
Widgets SSL VPN - 5.1.2.43 [tcp/80 & tcp/443]
Widgets 3rd party Online Database Support - 5.2.3.250 [tcp/12345, tcp/23456 & tcp/34567]

Widgets perimeter network is protected with a Cisco ASA firewall. The firewall has an outside interface(outside), customer DMZ interface (DMZ1), service DMZ interface (DMZ2), and an inside interface(inside).

Because ASA's uses the concept of security levels each interface must be assigned one. For more information understanding the ASA security level concept please visit the Cisco website.

The IP address of servers in the DMZ use the RFC 1918 192.168.1.0/24 and 192.168.2.0/24 addresses. The use of these address require address translation to be performed. For more information on understanding and configuration a Cisco ASA for address translation please visit the Cisco website.

To configure access list for the required service we must use this command syntax:

access-list NAME action protocol source destination service

For detailed information for ASA access-list configuration please visit the Cisco website.

When configuring an ACL unless there is a legitimate business case I always take a default deny stance. When ordering an ACL I prefer to place entries that will hit more often at the top of the ACL.

Using the requirements listed above we will create an ACL named outside_access_in.

access-list outside_access_in permit udp any 5.1.2.53 eq 53
access-list outside_access_in permit udp any 5.1.2.54 eq 53
access-list outside_access_in permit tcp any 5.2.3.80 eq 80
access-list outside_access_in permit tcp any 5.2.3.44 eq 443
access-list outside_access_in permit tcp any 5.2.3.44 eq 80
access-list outside_access_in permit tcp any 5.2.3.143 eq 443
access-list outside_access_in permit tcp any 5.2.3.143 eq 80
access-list outside_access_in permit tcp any 5.1.2.25 eq 25
access-list outside_access_in permit udp any 5.1.2.123 eq 500
access-list outside_access_in permit udp any 5.1.2.123 eq 4500
access-list outside_access_in permit tcp any 5.1.2.43 eq 80
access-list outside_access_in permit tcp any 5.1.2.43 eq 443
access-list outside_access_in permit tcp any 5.2.3.250 eq 12345
access-list outside_access_in permit tcp any 5.2.3.250 eq 23456
access-list outside_access_in permit tcp any 5.2.3.250 eq 34567
access-list oustide_access_in deny ip any any

If a syslog server with sufficient disk space is available I prefer to log every Access Control Entry (ACE). After logging all my ACE's if there additional space on the syslog server I will add this last entry:

access-list outside_access_in deny ip any any log

When logging every hit on the ACL you will have a great understanding of your network. However this type of logging can be very storage expensive. If storage space becomes an issue, I always keep logging on my permits.

With the ACL built it must be applied to the outside interface of the ASA firewall. Unlike Cisco IOS it is not applied in the interface configuration. To bind the ACL to the outside interface we must enter in the following commands:

asa(config)#access-group outside_access_in in interface outside

With the ACL's and NAT setup (check out the Cisco website for more information) you must next permit traffic to the physical servers in the DMZ. The next article in this series will describe creating the ACL in the DMZ.