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
message-length maximum 512
match domain-name regex class DomainBlockList
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
When configuring a Remote Access VPN or a Site to Site VPN connection you have the ability to filter traffic entering and leaving the VPN connection. You have the ability to enable inbound IPsec sessions to bypass interface access lists. Group policy and per-user authorization access lists still apply to the traffic.
The sysopt connection permit-ipsec command allows all the traffic that enters the security appliance through a VPN tunnel to bypass interface access lists. Group policy and per-user authorization access lists still apply to the traffic. In PIX 7.1 and later, the sysopt connection permit-ipsec command is changed to sysopt connection permit-vpn.
Mostly I use this option and configure some extra ACL’s to filter trafifc. Some customers don’t want to use this option and want to specify all traffic with ACL’s. This is more secure, but is a bigger burden on the management of the firewall.
From IOS 7.1 and later you have the ability to configure VPN filtering through Group Policies. In short you configure an extended ACL, link this ACL to a Group Policy and link the Group Policy to the specific Tunnel Group. The syntax (source and destination) needs to be correct for the ACL to work.
For Site to Site VPN’s the remote network is the source and the local network is the destination. For Remote Access VPN’s the VPN IP pool is the source and the local network the destination, as specified below.
An ACL that is used for a vpn-filter must not also be used for an interface access-group. When a vpn-filter is applied to a group-policy/user name mode that governs Remote Access VPN Client connections, the ACL must be configured with the client assigned IP addresses in the src_ip position of the ACL and the local network in the dest_ip position of the ACL. When a vpn-filter is applied to a group-policy that governs an L2L VPN connection, the ACL must be configured with the remote network in the src_ip position of the ACL and the local network in the dest_ip position of the ACL.
Exercise caution when you construct the ACLs for use with the vpn-filter feature. The ACLs are constructed with the post-decrypted traffic (inbound VPN traffic) in mind. However, they are also applied to the traffic originated in the opposite direction.
More about this matter and examples configurations can be found here.