Block Access to Websites with a Cisco ASA Firewall

In this article I will show you how to deny access to specific websites (domain names) with a normal Cisco ASA firewall. This works on either the older 5500 models or the new 5500-X series devices. The only pre-requisite for the firewall is to run software version 8.4.2 and later. Also, you don’t need to have any next generation firewall features or special licenses installed.

Although the ASA can provide a simple solution for restricting web access to specific websites, you should know that it is NOT a replacement for a full-featured URL filtering solution.

There are a few methods to block access to websites. These methods include regular expressions (regex) together with Modular Policy Framework (MPF), finding the IP address of the website and blocking with ACL, and using FQDN in an ACL.

The first method (regex with MPF) works well with HTTP websites but it will not work at all if the website uses HTTPs. The second method (blocking the IP with ACL) will work only for simple websites which have a static IP but it will be difficult to work for dynamic websites (such as Facebook, Twitter etc) which have many different IP addresses which change all the time. The third method (using FQDN in an ACL) is the one which we will describe here.

From ASA version 8.4(2) and later, Access Control Lists (ACL) can contain an object which represents a Fully Qualified Domain Name (FQDN). So, inside an ACL you can allow or deny access to hosts using their FQDN name instead of their IP address. You can therefore deny access to website www.facebook.com by denying access to FQDN object “www.facebook.com” inside the ACL.

The ASA will need to resolve all possible IP addresses of the FQDN and will dynamically insert several “deny IP” entries for these IP addresses in the ACL. Therefore you must specify what DNS server the ASA can use in order to resolve IP addresses for the FQDNs.

The method above does not slow down the firewall since the device will do the DNS lookup for the website you want to block beforehand and store all resolved IP addresses of the website in memory. Depending on the TTL of the DNS lookup, the firewall will keep doing DNS requests for the specific domain name (every few hours for example) and update the resolved IPs in memory.

n our example network below, we want to restrict access to www.website.com which resolves to IP address 2.2.2.2. The ASA will use the internal DNS server (or any other DNS) to resolve the IP and put a “deny IP” entry in the inbound ACL applied on the “inside” interface.

Let’s now see the required configuration on the ASA to achieve the above scenario:

domain-name mycompany.com

interface GigabitEthernet0
 nameif outside
 security-level 0
 ip address 20.20.20.2 255.255.255.0

interface GigabitEthernet1
 nameif inside
 security-level 100
 ip address 192.168.1.1

![other interface commands omitted]

!Specify which DNS server to use for resolving FQDN domains.
dns domain-lookup inside
dns server-group DefaultDNS
 name-server 192.168.1.20
 domain-name mycompany.com

!Create FQDN objects for website we want to block. Block both the www and non-www domains
object network obj-www.website.com
 fqdn www.website.com

object network obj-website.com
fqdn website.com

!Add the FQDN objects above to an ACL applied inbound to the inside interface
access-list INSIDE-IN extended deny ip any object obj-www.website.com
access-list INSIDE-IN extended deny ip any object obj-website.com
access-list INSIDE-IN extended permit ip any any

!Apply the ACL above to the inside interface
access-group INSIDE-IN in interface inside

![other commands omitted]

How to block HTTP DDoS Attack with Cisco ASA Firewall

Denial of Service attacks (DoS) are very common these days. Especially Distributed DoS attacks (called also DDoS) can be executed quite easily by attackers who own large networks of BotNets. Thousands of malware-infected computers (which comprise the so called “BotNets”) are controlled by attackers and can be instructed to start attacks at any target.

Usually WebSites are targeted more frequently. Bringing down a website can have a negative effect to the image (in addition to any financial loss) of the company owing the site. A DDoS attack can be purely “volumetric”, which means that the attacker just sends high volume of packets as quickly as possible to flood the bandwidth of the “pipe” connecting the website to the Internet. Also, DDoS attacks can be “Application Resource Exhaustion” which means that the attacking computers create thousands of application requests (e.g HTTP Requests) to a server, thus consuming the application resources.

A Cisco ASA Firewall can not help much in a “volumetric” DDoS attack. In such an attack, a dedicated DDoS device is needed or your ISP must do some kind of rate limiting to mitigate the attack. However, for “Application Exhaustion” attacks a Cisco ASA can help to some extend with HTTP inspection using the Modular Policy Framework mechanism of ASA. This is what we are going to describe in this article.

Usually, HTTP Application DDoS attacks have a pattern or string which helps you distinguish the attacking HTTP requests from other legitimate requests. For example, HTTP attacking packets might have a common parameter or string, which can be for example the same “User-Agent” used by the attacking script, a common POST or GET URI request, some other HTTP header parameters etc. With the ASA HTTP inspection feature you can match on this common pattern in the HTTP packet thus filter-out the attacking packets and drop them.

Recently I was engaged to help mitigate a DDoS attack on a webserver. I observed from the Apache logs that the attacking HTTP requests were all targeting the website on the same URL string, such as http://www.website.com/xyz123.  The string “xyz123” was the common pattern for all malicious HTTP requests. Thus with a policy on ASA you can match on the unique string above and drop the packets that have this string in the HTTP URI.

Lets see a diagram and configuration below:

!First create a regular expression with the unique attack string
regex attackstring xyz123

!Create an ACL to match the HTTP traffic towards the target server
access-list HTTPTRAFFIC extended permit tcp any host 1.1.1.1 eq www

!Create a regular L3/L4 class to match the traffic above
class-map attackingtraffic
 match access-list HTTPTRAFFIC

!Now create an HTTP inspection policy to match on the unique attacking string
policy-map type inspect http HTTPDOS
 parameters
 match request uri regex attackstring
  drop-connection
 match request args regex attackstring
  drop-connection

!The following policy-map will include the L3/L4 class which will include the HTTP inspection policy
policy-map BLOCKDOS
 class attackingtraffic
  inspect http HTTPDOS

!Now attach the policy-map to the ASA outside interface to inspect Inbound traffic.
service-policy BLOCKDOS interface outside

If you enable logging on the drop-connection command (use “drop-connection log“), then you will start seeing logs that the ASA is dropping packets with the matched attacking HTTP string.

NETWORKEXPLOSION: Understanding of BGP regular expressions

NETWORKEXPLOSION: Understanding of BGP regular expressions: Regular expressions are strings of special characters that can be used to search and find character patterns. Within the scope of BGP in Ci...

Understanding of BGP regular expressions

Regular expressions are strings of special characters that can be used to search and find character patterns. Within the scope of BGP in Cisco IOS regular expressions can be used in show commands and AS-Path accesslists to match BGP prefixes based on the information contained in their AS-Path.

In order to understand how to build regular expressions we first need to know what the character definitions are for the regex function of IOS. The below table illustrates the regex characters and their usage. This information is contained in the Cisco IOS documentation under the Appendix of Cisco IOS Terminal Services Configuration Guide, Release 12.2.

CHAR	USAGE
^	Start of string
$	End of string
[]	Range of characters
-	Used to specify range ( i.e. [0-9] )
()	Logical grouping
.	Any single character
*	Zero or more instances
+	One or more instance
?	Zero or one instance
_	Comma, open or close brace, open or close
	parentheses, start or end of string, or space

Some commonly used regular expressions include:

Expression	Meaning
.*	Anything
^$	Locally originated routes
^100_	Learned from AS 100
_100$	Originated in AS 100
_100_	Any instance of AS 100
^[0-9]+$	Directly connected ASes

Let’s break some of the above expressions down step-by-step. The first one “.*” says to match any single character (“.”), and then find zero or more instances of that single character (“*”). This means zero or more instances or any character, which effectively means anything.

The next string “^$” says to match the beginning of the string (“^”), and then immediately match the end of the string (“$”). This means that the string is null. Within the scope of BGP the only time that the AS-Path is null is when you are looking at a route within your own AS that you or one of your iBGP peers has originated. Hence this matches locally originated routes.

The next string “^100_” says to match the beginning of the string (“^”), the literal characters 100, and then a comma, an open or close brace, an open or close, a parentheses, the start or end of the string, or a space (“_”). This means that the string must start with the number 100 followed by any non-alphanumeric character. In the scope of BGP this means that routes which are learned from the AS 100 will be matched, as 100 will be the first AS in the path when AS 100 is sending us routes.

The next string “_100$” is the exact opposite of the previous one. This string says to start with any nonalphanumeric character (“_”), followed by the literal characters 100, followed by the end of the string (“$”). This means that AS 100 is the last AS in the path, or in other words that the prefix in question was originated by AS 100.

The next string “_100_” is the combination of the two previous strings with some extra matches. This string means that the literal characters 100 are set between any two non-alphanumeric characters. The first of these could be the start of the string, which would match routes learned from AS 100, while the second of these could be the end of the string, which would match routes originated in AS 100. Another case could be that the underscores represent spaces, in which the string would match any other AS path information as long as “ 100 ” is included somewhere. This would match any routes which transit AS 100, and therefore “_ASN_” is generally meant to match routes that transit a particular AS as defined by the number “ASN”.

The final string “^[0-9]+$” is a little more complicated match. Immediately we can see that the string starts (“^”), and we can see later that it ends (“$”). In the middle we see a range of numbers 0-9 in brackets, followed by the plus sign. The numbers in brackets mean that any number from zero to nine can be matched, or in other words, any number. Next we have the plus sign which means one or more instances. This string “[0-9]+” therefore means one or more instance of any number, or in other words any number including numbers with multiple characters (i.e. 1, 12, 123, 1234, 12345678, etc.). When we combine these all together this string means routes originated in any directly connected single AS, or in other words, the routes directly originated by the peers of your AS.

traffic toeing techniques

Prefix-Lists  

Prefix-lists are used to match routes as opposed to traffic. Two things are matched: • The prefix (the network itself) • The prefix-length (the length of the subnet mask)
Consider the following prefix-list:
Router(config)#  ip prefix-list MYLIST 10.1.1.0/24
The above prefix-list matches the 10.1.1.0/24 network exactly. It will not match 10.1.0.0/16, or 10.1.1.4/30.
A range of prefix-lengths can be specified:
Router(config)#  ip prefix-list MYLIST 10.1.1.0/24 le 30 Router(config)#  ip prefix-list MYLIST 10.1.1.0/24 ge 26 le 30
The first command dictates that the first 24 bits of the prefix must match (meaning, the prefix must begin 10.1.1), and the subnet mask must be less than or equal to 30 bits.
The second command dictates again that the first 24 bits of the prefix must match, and the subnet mask must be between 26 to 30 bits (or equal to).
To match all prefixes:
Router(config)#  ip prefix-list MYLIST 0.0.0.0/0 le 32
To view information about all prefix lists:
Router#  show ip prefix-list detail 

Distribute-Lists  

Distribute-lists are used to filter routing updates, either inbound or outbound. Routes must first be matched using an access-list or prefix-list, and then applied using a distribute-list under the routing process: 
To use an access-list to identify routes:
Router(config)#  access-list 10 permit ip 172.16.0.0 0.0.255.255
Router(config)#  router rip Router(config-router)#  distribute-list 10 in serial0/0
The above distribute-list will control routes sent inbound on serial0/0. Specifically, the referenced access-list will only permit routes matching 172.16 in the first two octets.
To use a prefix-list to identify routes:
Router(config)#  ip prefix-list MYLIST 10.1.0.0/16
Router(config)#  router rip Router(config-router)#  distribute-list prefix MYLIST out fastethernet0/0
The above distribute-list will control routes sent outbound on fastethernet0/0. Specifically, the referenced prefix-list will only match the exact 10.1.0.0/16 route.

Route-Maps  

Route-maps are advanced access-lists that serve several functions on IOS devices, including (but not limited to): • Controlling redistribution between routing protocols. • Adjusting the attributes of routes (especially for BGP). • Implementing Policy Based Routing (PBR).
As with access-lists, route-maps are organized as a sequential set of rules or statements, each with a permit or deny condition. However, access-lists can merely permit or deny traffic, while a route-map can additionally modify or perform a specific action on traffic.
Route-maps follow a very simple logic:  • Traffic must be first matched, based on specified criteria.  • A particular attribute or action is set on the matched traffic.
Each statement in a route-map is assigned a sequence number, and contains a series of match and set statements. The route-map is parsed from the lowest sequence number to the highest, and will stop once a match is found.
The following demonstrates the syntax of a route-map:
Router(config)#  access-list 1 permit 10.1.1.0 0.0.0.255
Router(config)#  route-map MYMAP permit 10 Router(config-route-map)#  match ip address 1 Router(config-route-map)#  set ip next-hop 192.168.1.1
First, an access-list was created that matched traffic from 10.1.1.0/24.
Then, a route-map called MYMAP was created, and assigned a sequence number of 10 with a permit condition. If a route-map contains multiple statements, the sequence number dictates the order of those statements.
The route-map will then match any traffic listed in access-list 1. Notice that the syntax to call an access-list match ip address.
Finally, the desired attributed is set to this traffic. In this instance, the ip next hop attribute has been modified to 192.168.1.1.     

Route-Maps (continued)  

A single route-map statement can contain multiple match commands:  

Router(config)#  route-map MYMAP permit 10 Router(config-route-map)#  match ip address 1 2 3  

The above line would match traffic in access-list 1, or access-list 2, or access-list 3. Thus, when match criteria is contained within a single line, a logical OR is applied.   

However, if match criteria is specified on separate lines:  

Router(config-route-map)#  match ip address 1 Router(config-route-map)#  match ip address 2  

Then the traffic must match access-list 1 and access-list 2 (a logical AND). Remember this distinction!   

If no match criteria is specified, all traffic is matched!  

Additionally, a single route-map statement can contain multiple set commands:  

Router(config)#  route-map MYMAP permit 10 Router(config-route-map)#  match ip address 1 Router(config-route-map)#  set weight 50 Router(config-route-map)#  set local-preference 200  

Any traffic matching access-list 1 will have both set attributes applied.  

There is an implicit deny any statement at the bottom of every route-map. The impact of this deny any statement is dependent on the function of the access-list: • If using a route-map for policy-based routing or adjusting attributes, any routes/traffic not specifically matched will remain unchanged. • If using a route-map for redistribution, any routes not specifically matched (and permitted) will not be redistributed.   

What is a Rough point in a network security.

Rough point - it is a device where the user can connect to access the network.

for example if a host connected to a switch then switch is rough point. if a host connected to a wireless access point then wireless access point is rough point.

where the user connected to devices to access the network that all device call as rouge point device.
it might be any devices it might be either switch or wireless access points.

About infrastructure security is very important for every organization or we can say that infrastructure security is the key success of any organization.

We all know that the importance of security in any field whether it is in banking transaction, or book a airplane ticket or to book a pizza whatever it may be it is very very important.
So coming back in our communication field it is also very important to protect your network whether it is a small organization or a big organization every one want or need security.
Now lots of small organization is facing the issue and they need to find out exact way so that we can exactly deal with the security issue. we want exact solution or mitigation techniques to overcome the security issue. now sometimes what happened peoples are think about security breach is always happened from outside but it is not truth, in your internal organization because some small mistake done by any user attack is also originated. So every time attack is not coming from outsides, attack is originated from inside your organization also . for example of internal originated attack. suppose a network guy go into the market and he perches a small size wireless access point from market. what happens when he came back to the office and for testing purpose he is interested to test the wireless access point that he brought from market. so what he did ? he sit on the desk of their cubical and from their patch panel he connect the access point which means he directly connect the access point into the switch because from cubical patch panel is connect directly to switch. and we know that if we connect any device on switch it will directly provide the network access to that host. there is no authentication on switch because switch is a Ethernet device and by default there is no authentication on Ethernet technologies. if you want authentication on switch there is one protocol called as DOT1X. you need to enable the dot1x security if you want authentication on switch. so it is all about on switch but what happens on wireless access point if anyone try to connect to access point first it will ask username and password . after providing the correct username and password then only it will provide the network access to that particular hoat only. so initially when it guys brought the wireless access point from market there is no username and password set on the access point. as soon as when he connected the wireless access point to the switch it will start transmitting the wireless access to outside users. at that time if any outside user connect to that access point he will get the access of your entire network and he will do bad thing in your network.

so the moral of the story because of your one mistakes of your employee there is a huge chances of attack in your network. so keep protecting your infrastructure in a smart manner.