A common attack found on TCP/IP networks is IP spoofing. This is usually used for Denial-of-Service, Identity hiding, or even to bypass firewalls or Access-Lists security rules. The spoofing attack works like that:

• A malicious attacker sends packets towards a target host.
• The attacker disguises itself by inserting a fake source IP into the packet. This fake source IP address in the packet either does not exist at all or it might be a legitimate IP address of some other host located on some other network.
• The reply traffic from the target will never reach the attacker because the attacker’s source address is bogus. Therefore the identity of the attacker remains unknown.
• This can cause resource-exhaustion on the target host because it will create several “incomplete” TCP connections in its memory.

A Cisco ASA Firewall can identify a spoofed packet by using Reverse Path Forwarding (RPF). RPF can be enabled on a per interface basis. As soon as RPF is enabled on a specific interface, the ASA firewall will examine the source IP address (in addition to the destination address) of each packet arriving at this interface. Normally, any Layer 3 network device examines only the destination address of packets in order to know how to route the packet. By examining also the source IP address of the packet, the firewall can verify if the packet is spoofed or not. The firewall will try to find the reverse route (the path back towards the source) in its routing table. If a reverse route is not found on the interface where the packet arrived, it means that the packet is spoofed and will be dropped immediately.

Lets see the diagram below to clarify the concept of Reverse Path Forwarding:

From the diagram above, an attacker tries to spoof the inside network 192.168.1.0 by using a fake source IP in the packet (fake source IP 192.168.1.1). It sends the packet towards its target host which is 192.168.1.10 (destination address in packet).

On the ASA we have configured RPF on the outside interface as following:

Ciscoasa(config)# ip verify reverse-path interface outside

The ASA will examine the source address of the spoofed inbound packet and will see that source IP 192.168.1.1 belongs to its internal network. A packet with such a source IP should never arrive from the outside interface. Therefore the packet will be dropped. The ASA performs the RPF check by using its routing table. The routing table shows that network 192.168.1.0/24 is towards the inside interface of ASA (assume that we have already configured a static route for this internal network).

For a low budget firewall functionality, a Cisco router with the proper IOS version can work as a network firewall providing stateful protocol inspection using the Context-Based Access Control (CBAC) feature. Many people use normal Access Control Lists on Cisco routers for traffic filtering and protection. However, a normal ACL is just a static packet filtering mechanism and nothing else. With a CBAC configuration, the router acts like a firewall. That is, it inspects protocols and sessions and keeps a state of the connection in memory. This means that an outbound packet (from inside the network to the outside) is inspected and a connection state of the session is kept in memory. The reply packet which belongs to the original outbound connection is allowed to pass through the router/firewall and reach the internal system which originated the connection. This stateful functionality is achieved by the IOS Firewall CBAC mechanism by opening temporary holes on an Access List in order to allow the reply packets.

A normal ACL checks traffic up to the transport layer. CBAC on the other hand inspects traffic up to the application layer to learn about the state of the session and to apply firewall filtering on the specific application. The protocols supported by CBAC for inspection are the following:

CUSeeMe Protocol, ftp, h323, http, rcmd, realaudio, rpc, smtp, sqlnet, streamworks, tcp, tftp, udp, vdolive. CBAC helps to protect also against DoS attacks such as SYN-floods or fragmentation attacks.

CBAC is applied either inbound or outbound on a specific router interface. CBAC applied “Inbound” on an interface inspects traffic entering the interface and CBAC applied “Outbound” on an interface inspects traffic exiting the interface. CBAC cooperates with an ACL applied on the same interface in order to provide the firewall stateful functionality that we described above. Lets see a simple example below.

In the figure above, assume that there is an inbound ACL applied on S0 on the router. The ACL is configured to block Telnet traffic initiated from the outside. Assume also that there is a CBAC rule applied “outbound” on S0. An internal user (User1) initiates a Telnet session from inside to outside. When the connection request for User1’s Telnet session passes through the firewall, CBAC inspects the Telnet traffic when exits interface S0 and creates a temporary opening in the inbound access list at S0 to permit returning Telnet traffic for User1’s Telnet session. (If the same access list is applied to both S0 and S1, the same opening would appear at both interfaces.)

Important Note: CBAC which inspects outbound traffic from an interface, will create temporary openings on the Access List which is applied Inbound on the interface. This is required to allow the return packets to pass through the ACL.

Let us see a configuration example below to get a better picture.

Configuration Example:

Refer to the diagram below for our configuration example:

We have a border Cisco router connecting the internal LAN 192.168.1.0/24 to the Internet. We have a static public IP address 50.50.50.1 on interface Serial0/0. Also, we have a DMZ segment (interface FE0/0) hosting a DMZ Web Server 10.1.1.1. We want to allow access from Internet towards the Web Server only. We use static NAT to hide the Web server private address behind our public address. Also, we use PAT on interface S0/0 for all outbound communication from the internal LAN towards the internet.

Lets see a snapshot of the configuration below:

! Create the outbound CBAC inspection rules
ip inspect name CBAC-IN-OUT tcp
ip inspect name CBAC-IN-OUT ftp
ip inspect name CBAC-IN-OUT h323
ip inspect name CBAC-IN-OUT rcmd
ip inspect name CBAC-IN-OUT http
ip inspect name CBAC-IN-OUT netshow
ip inspect name CBAC-IN-OUT realaudio
ip inspect name CBAC-IN-OUT rtsp
ip inspect name CBAC-IN-OUT sqlnet
ip inspect name CBAC-IN-OUT streamworks
ip inspect name CBAC-IN-OUT tftp
ip inspect name CBAC-IN-OUT udp
ip inspect name CBAC-IN-OUT vdolive

! Create the inbound CBAC to inspect inbound HTTP
ip inspect name CBAC-OUT-IN http

! DMZ interface
interface FastEthernet0/0
ip address 10.1.1.254 255.255.255.0
ip nat inside
full-duplex
no cdp enable
!
! Internal LAN interface
interface FastEthernet0/1
ip address 192.168.1.254 255.255.255.0
ip nat inside
full-duplex
no cdp enable
!

! External Internet Interface
! Notice that we apply an inbound ACL and CBAC rules for both in and out inspection
interface Serial0/0
description CONNECTED TO INTERNET
bandwidth 1024
ip address 50.50.50.1 255.255.255.252
ip access-group FIREWALL in
ip nat outside
ip inspect CBAC-OUT-IN in
ip inspect CBAC-IN-OUT out

ip nat inside source list 122 interface Serial0/0 overload
ip nat inside source static tcp 10.1.1.1 80 50.50.50.1 80 extendable no-alias
ip classless
ip route 0.0.0.0 0.0.0.0 50.50.50.2

! This ACL will be used by the CBAC out rule to open temporary holes for return traffic
ip access-list extended FIREWALL
permit icmp any any echo-reply
permit tcp any host 50.50.50.1 eq 80
deny   ip any any log

access-list 122 permit ip 192.168.1.0 0.0.0.255 any

This article gets back to the basics regarding Cisco ASA firewalls. I’m offering you here a basic configuration tutorial for the Cisco ASA 5510 security appliance. This device is the second model in the ASA series (ASA 5505, 5510, 5520 etc) and is fairly popular since is intended for small to medium enterprises. Like the smallest ASA 5505 model, the 5510 comes with two license options: The Base license and the Security Plus license. The second one (security plus) provides some performance and hardware enhancements over the base license, such as 130,000 Maximum firewall connections (instead of 50,000), 100 Maximum VLANs (instead of 50), Failover Redundancy, etc. Also, the security plus license enables two of the five firewall network ports to work as 10/100/1000 instead of only 10/100.

Next we will see a simple Internet Access scenario which will help us to understand the basic steps needed to setup an ASA 5510. Assume that we are assigned a static public IP address 100.100.100.1 from our ISP. Also, the internal LAN network belongs to subnet 192.168.10.0/24. Interface Ethernet0/0 will be connected to the outside (towards the ISP), and Ethernet0/1 will be connected to the Inside LAN switch. Refer to the diagram below for our example scenario.

The firewall will be configured to supply IP addresses dynamically (using DHCP) to the internal hosts. All outbound communication (from inside to outside) will be translated using Port Address Translation (PAT) on the outside public interface. Let’s see a snippet of the required configuration steps for this basic scenario:

Step1: Configure a privileged level password (enable password)

By default there is no password for accessing the ASA firewall, so the first step before doing anything else is to configure a privileged level password, which will be needed to allow subsequent access to the appliance. Configure this under Configuration Mode:

ASA5510(config)# enable password mysecretpassword

Step2: Configure the public outside interface

ASA5510(config)# interface Ethernet0/0
ASA5510(config-if)# nameif outside
ASA5510(config-if)# security-level 0
ASA5510(config-if)# ip address 100.100.100.1 255.255.255.252
ASA5510(config-if)# no shut

Step3: Configure the trusted internal interface

ASA5510(config)# interface Ethernet0/1
ASA5510(config-if)# nameif inside
ASA5510(config-if)# security-level 100
ASA5510(config-if)# ip address 192.168.10.1 255.255.255.0
ASA5510(config-if)# no shut

Step 4: Configure PAT on the outside interface

ASA5510(config)# global (outside) 1 interface
ASA5510(config)# nat (inside) 1 0.0.0.0 0.0.0.0

Step 5: Configure Default Route towards the ISP (assume default gateway is 100.100.100.2)

ASA5510(config)# route outside 0.0.0.0 0.0.0.0 100.100.100.2 1

Step 6: Configure the firewall to assign internal IP and DNS address to hosts using DHCP

ASA5510(config)# dhcpd dns 200.200.200.10
ASA5510(config)# dhcpd address 192.168.10.10-192.168.10.200 inside
ASA5510(config)# dhcpd enable inside

The above basic configuration is just the beginning for making the appliance operational. There are many more configuration features that you need to implement to increase the security of your network, such as Static and Dynamic NAT, Access Control Lists to control traffic flow, DMZ zones, VPN etc. I just tried to offer you a starting point for a basic configuration from where you can build your knowledge further.

NetFlow is a protocol initially developed by Cisco but it is also supported on many other network devices. NetFlow’s purpose is to collect IP traffic information and send the collected records to a NetFlow Collector server or NetFlow Analyzer. NetFlow is useful for administrators to have an inside-view to the traffic passing through the network and collect information about bandwidth usage, type of traffic, traffic volume etc.

Only Cisco IOS Routers were supporting NetFlow in the past. Regarding Cisco ASA, NetFlow was only supported on Cisco ASA 5580 with software version 8.1. With the introduction of Cisco ASA software version 8.2, NetFlow is now supported on ALL ASA Models. This new feature on ASA is called NetFlow Security Event Logging (NSEL) which is an adaptation of NetFlow version 9.

Configuring NetFlow on Cisco ASA:

 There are three event types that trigger the creation of a NetFlow record. These are flow-create, flow-denied, flow-teardown. You can use all as well to trigger a netflow record for all events. You need to define a netflow collector IP address to which the ASA appliance will send flow records. You can use the Modular Policy Framework to customize the details of NetFlow functionality.

Example: Log Flow Creation events between hosts 10.1.1.1 and 10.2.2.2

The Internal NetFlow Collector server is 192.168.100.1

 
ASA (config)#  flow-export destination inside 192.168.100.1 2055

ASA (config)# access-list flow_export_acl permit ip host 10.1.1.1 host 10.2.2.2

ASA (config)# class-map flow_export_class
ASA (config-cmap)# match access-list flow_export_acl

ASA (config)# policy-map flow_export_policy
ASA (config-pmap)# class flow_export_class
ASA (config-pmap-c)# flow-export event-type flow-creation destination 192.168.100.1

! You can use also event-type all to trigger records for all flow events

ASA (config)# service-policy flow_export_policy global 

! Disable Logging for flow export events for performance increase
ASA (config)# logging flow-export syslogs disable