Booches.nl

Cisco ASA: DNS reply filtering

Today I was asked to block access to multiple websites and the only device capable of doing this was the firewall. This customer is using a Cisco ASA firewall, which supports basic URL filtering. This customers wanted to block HTTP and HTTPS websites. HTTPS websites use a SSL tunnel from the end device to the end server, so the firewall isn’t capable of inspecting the SSL traffic. Instead of using URL inspection, I configured DNS inspection.

The ASA inspects the DNS request from the internal DNS server or end device to the external DNS server. I use regular expressions to match the FQDN of a website. Below is an example configuration of blocking access to the website (and applications using a DNS entry to this website) LogMeIn.com

regex domain_logmein.com “\.logmein\.com”
!
class-map type regex match-any DomainBlockList
description Blocked Domains
match regex domain_logmein.com
!
policy-map type inspect dns PM-DNS-inspect
parameters
message-length maximum 512
match domain-name regex class DomainBlockList
drop-connection log
!
policy-map global_policy
class inspection_default
inspect dns PM-DNS-inspect
!
service-policy global_policy global

A problem with this approach could be the DNS cache on the internal DNS server. This is domain name is queried before configuring the inspection, the domain will be available until the DNS cache from the DNS server expires. In urgent situation you can maybe clear the DNS cache yourself.

If a DNS reply is matched the ASA generates a syslog message, like shown below.

08-28-2009 15:33:31 Local4.Warning 10.10.1.254 %ASA-4-410003: DNS Classification: Dropped DNS request (id 22251) from inside:DNS-SERVER/59256 to outside:UPSTREAM-DNS/53; matched Class 23: match domain-name regex class DomainBlockList

Failed to establish VPN through PIX

We migrated our Internet connection lately and reconfigured our PIX firewall. We added some memory to install the latest firmware version (8.0(4)). After putting the PIX firewall in production some of the employees were complaining they couldn’t establish any PPTP VPN Tunnels anymore to customers.

Every time when some one called me, I tried it myself and I was always able to connect using a PPTP VPN Tunnel, but every time I was working remote and not at the office. So I always thought that something was wrong with there laptops, but today I encountered the problem myself.

Looking at the logging of the PIX firewall, I saw the following error message:

%ASA-3-305006: regular translation creation failed for protocol 47 src inside:<IP address> dst outside:<IP address>

The error message indicates that there is no NAT mapping for the specified traffic, which could direct you in the wrong direction. I checked the NAT mappings to be sure, but as I already thought, this couldn’t be the cause of the problem.

PPTP uses a TCP connection that uses port 1723 and an extension of generic routing encapsulation (GRE) [protocol 47] to carry the actual data (PPP frame). The TCP connection is initiated by the client, followed by the GRE connection that is initiated by the server. Because the PPTP connection is initiated as TCP on one port and the response is GRE protocol, the PIX Adaptive Security Algorithm (ASA) does not know that the traffic flows are related.

The PPTP fixup feature in version 6.3 allows the PPTP traffic to traverse the PIX when configured for PAT. Stateful PPTP packet inspection is also performed in the process. The fixup protocol pptp command inspects PPTP packets and dynamically creates the GRE connections and translations necessary to permit PPTP traffic. Specifically, the firewall inspects the PPTP version announcements and the outgoing call request/response sequence. Only PPTP Version 1, as defined in RFC 2637, is inspected. Further inspection on the TCP control channel is disabled if the version announced by either side is not Version 1. In addition, the outgoing call request and reply sequence is tracked. Connections and/or translations are dynamically allocated as necessary to permit subsequent secondary GRE data traffic. The PPTP fixup feature must be enabled for PPTP traffic to be translated by PAT.

So I had to configure the fixup protocol pptp feature with the following command:

fw01(config)# fixup protocol pptp 1723

As stated before, we are using fireware version 8.0(4). This version doesn’t support the fixup protocol pptp command and the converts the command an inspect pptp command as shown below.

fw01(config)# fixup protocol pptp 1723
INFO: converting ‘fixup protocol pptp 1723′ to MPF commands

!

!

policy-map global_policy
class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect pptp

Secure Copy Server Cisco ASA

Lately there are a lot of changes in the firmware and the ASDM for the Cisco ASA firewalls. This means a lot of copying from files to the flash memory of the specific appliances. Normally when upgrading the software from an appliance I use a computer on the customer network. This could be my own laptop or I take over a computer remotely.

Using my own laptop is never a problem, but when I would like to upgrade a firewall remotely I first have to build a VPN tunnel. Take over a computer, download the specific software for the appliance. Install some kind of FTP or TFTP service and start the upload procedure.

A couple of weeks ago a friend of mine brought up the Secure Copy Server feature for Cisco ASA appliance. This features gives to the ability to securely upload files remotely to the flash memory of the appliance. Secure copy is a often used feature in the open source community and the usage is simple. It is a very powerful tool, but it never crossed my mind to use it in conjunction with the ASA appliances.

The Secure Copy Server is enabled with the following command:

ssh scopy enable

After enabling the Secure Copy Server you have the ability to securely copy files to the flash memory of the ASA appliance. Linux or Mac OS X users normally use some kind of terminal to establish a secure copy connection. Windows users could use PuttySCP for uploading files to the flash memory. The syntax for using PuttySCP is in general the same as using a Linux shell. The syntax looks like:

pscp.exe <source> <user>@<destination host>:<flash file name>

An example would be:

pscp.exe asa804-k8.bin rene@asa.booches.nl:asa804-k8.bin

I guess I will use this feature more often from now on.

Cisco Firewall Design and Deployment

The session about firewall design and deployment didn’t reveal a lot of new things about the Cisco ASA appliance or FWSM module. The only new thing for me was the possibility to configure a redundant interface for a Cisco ASA appliance. The screen shot below shows the cabling scheme for an implementation with and without interface redundancy.

This interface redundancy makes it possible to connect a ASA to two different physical switches. When the active switch would crash, the second switch would become the active switch.

Important here is to notice that this configuration doesn’t provide load-balancing across two links. The configuration is only for link redundancy.

To configure interface redundancy you can use the configuration snippet shown below.

interface Redundant1
  member-interface GigabitEthernet0/2
  member-interface GigabitEthernet0/1
  no nameif
  no security-level

  no ip address
!
interface Redundant1.4
  vlan 4
  nameif inside
  security-level 100
  ip address 172.16.10.1 255.255.255.0
!
interface Redundant1.10

  vlan 10
  nameif outside
  security-level 0
  ip address 172.16.50.10 255.255.255.0

The configuration of interface redundancy has some caveats as listed below:

• Firewalls have to be configured in Active/Standby mode. No load-balancing or link aggregation is supported;
• Interface redundancy is available on Cisco ASA 5510 and above. The ASA 5505 already has a build in switch and FWSM doesn’t have any physical interfaces;
• Subinterfaces (IEEE 802.1Q) need to be configured on top of the logic redundant interface;

During the session the different modes for the firewalls have been discussed. Normally we only use the Routed Mode, but there are more modes like described below:

• Routed mode: traditional mode of the firewall. Two or more interfaces that separate two or more layer 3 domains;
• Transparent mode: the firewall acts as a bridge and functions mostly at layer 2 of the OSI model (this functions is often used for filtering traffic between two routers who, for example, exchange routing information through a dynamic routing protocol);
• Multi-context: one physical firewall is divided in more virtual firewalls;
• Mixed mode: using routed and transparent firewalls in a virtual environment (NOTE: mixed mode is only supported in FWSM today);

Firewall virtualization using multiple context has some caveats. We, Ictivity consultants, already noticed these caveats during firewall implementations. Firewall virtualization has the following caveats:

• No support for VPN services;
• No support for dynamic routing protocols;
• No way to configure the sharing of CPU usage between contexts;
• No support for multicast routing (multicast bridging is supported);

Especially not supporting VPN services (site-to-site VPN, remote access VPN and SSL VPN) is mostly the most used reason for not using multiple context implementation for the firewall.

PIX / ASA – Threat Detection

From software release 8.0 and later the Cisco PIX and Cisco ASA firewalls support the feature called Threat Detection. In the default configuration Basic Threat Detection is enabled on the security appliance.

Using Threat Detection the appliance monitors the rate of dropped packets and security events due to these reasons (Source):

• Denial by access lists;
• Bad packet format (such as invalid-ip-header or invalid tcp-hdr-length);
• Connection limits exceeded (both system-wide resource limits, and limits set in the configuration);
• DoS attack detected (such as an invalid SPI, Stateful Firewall check failure);
• Basic firewall checks failed (This option is a combined rate that includes all firewall-related packet drops in this bulleted list. It does not include non-firewall-related drops such as interface overload, packets failed at application inspection, and scanning attack detected.);
• Suspicious ICMP packets detected;
• Packets failed application inspection;
• Interface overload;
• Scanning attack detected;
• Incomplete session detection such as TCP SYN attack detected or no data UDP session attack detected;

When the security appliance detects a threat a syslog message is send. These syslog messages have the following format:

%ASA-4-733100: Object drop rate rate_ID exceeded. Current burst rate is rate_val per second, max configured rate is rate_val; Current average rate is rate_val per second, max configured rate is rate_val; Cumulative total count is total_cnt

Basic Threat Detection affects the performance of the security appliance only when there are drops or potentials threats. I have monitored the CPU with Basic Threat Detection enabled and disabled in an environment with many deny hits on the outside interface, resulting from port scans and (D)DoS attacks. The performance impact on the security appliance is insignificant.

The security appliance has also the option to actively scan all traffic and shun connections if threats rates are exceeded. The security appliance tracks two types of rates:

1. the average event rate over an interval;
2. the burst event rate over a shorter burst interval;

More information about configuring Threat Detection can be found in the Cisco Security Appliance Command Line Configuration Guide, 8.0 and more specific the chapter Preventing Network Attacks.

In my own experience with Cisco PIX and Cisco ASA firewalls running software release 8.0 and later, I normally disable Basic Threat Detection. Often I receive questions from customers about the syslog messages generated by Basic Threat Detection. Customers always think that something is terribly wrong with the security appliance. For some customers I enabled Basic Threat Detection in conjunction with the Scanning Threat Statistics. Enabling the statistics give you more detailed information about the discovered threat rates. The statistics can be viewed via the Firewall Dashboard when using ASDM or with various show commands using the CLI. Below the output of the command show threat-detection rate.

Average(eps)    Current(eps) Trigger    Total events
10-min ACL  drop:                  1               0       0            119
21-hour ACL  drop:                  2               1       0          7556
10-min SYN attck:                  0               0       0            436
1-hour SYN attck:                  0               0       0           2863
10-min  Scanning:                 12               9   31963            721
31-hour  Scanning:                 20              11   21622         74264
10-min Bad  pkts:                  0               0       0            107
1-hour Bad  pkts:                  0               0       0            682
10-min  Firewall:                  2               1       0           1299
1-hour  Firewall:                  2               1       0           8238
10-min Interface:                 10               0       0           6314
1-hour Interface:                 10              10       0          37220

Enabling the use of statistics could have a bad influence on the performance from the PIX / ASA. Especially the memory usage can increase enormously. With Basic Thread Detection, there is also an option for actively scanning all traffic and shun the traffic when certain threshold are reached. Shunning the traffic is accomplished by adding a policy rule to the configuration. This rule is added to the configuration automatically and stays even after a reboot.

I talked with a Cisco engineer about this feature and he advized me not to use Basic Thread Detection with the scanning feature. The feature is rather new and needs a lot of tweaking, because this functionality can basically be compared with Intrusion Detection and Intrusion Prevention System. The engineer also stated that the gathering of statistics can have an influence on the memory usage of the box. Therefore he also advized to only use the statistics feature in certain environments and circumstances.