Cisco Archives

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:

asa ddos http protection

ASA Configuration:

!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.

In this first Video Tutorial I will show you how to enable initial access to the ASA device in order to connect with ASDM graphical interface or with SSH. The network topology is shown below:

Cisco ASA ASDM Configuration

First we need to have console access (with a serial console cable) to the device in order to configure some initial settings to allow user access with ASDM or with SSH. We will configure Interface GigabitEthernet 5 as a management interface with IP address 10.10.10.1/24. Also, on the same subnet we have our management PC with IP address 10.10.10.10/24. The management PC is running also a TFTP server software (tftp32) which will be used to transfer the ASDM image to the ASA.

Below is the CLI configuration used in this initial setup (see video below also for more information):

ciscoasa# sh run
: Saved
:
ASA Version 8.4(2)
!
hostname ciscoasa
! Configure an “enable password” which is the administrator password of the device
enable password 2KFQnbNIdI.2KYOU encrypted

passwd 2KFQnbNIdI.2KYOU encrypted
names
!
interface GigabitEthernet0
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet1
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet2
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet3
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet4
shutdown
no nameif
no security-level
no ip address
!
! Configure IP address to Interface GigEth5 and put a high security level (90 is good).
! name also the interface as “management”
interface GigabitEthernet5
nameif management
security-level 90
ip address 10.10.10.1 255.255.255.0
!
ftp mode passive
pager lines 24
mtu management 1500
icmp unreachable rate-limit 1 burst-size 1

! Tell the appliance where the asdm image is located.
asdm image disk0:/asdm-647.bin
no asdm history enable
arp timeout 14400
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
timeout floating-conn 0:00:00
dynamic-access-policy-record DfltAccessPolicy
user-identity default-domain LOCAL

! SSH access will use the LOCAL username/password for authentication
aaa authentication ssh console LOCAL
! enable the HTTP service on the device so that you can connect to it for ASDM access
http server enable
! Tell the device which IP addresses are allowed to connect for HTTP (ASDM) access and from which interface
http 10.10.10.0 255.255.255.0 management
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart warmstart
telnet timeout 5
! Tell the device which IP addresses are allowed to connect for SSH access and from which interface.
ssh 10.10.10.0 255.255.255.0 management
ssh timeout 5
console timeout 0
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
webvpn
! Configure a LOCAL username/password to be used for authentication.
username cisco password 3USUcOPFUiMCO4Jk encrypted
!
!
prompt hostname context
no call-home reporting anonymous
call-home
profile CiscoTAC-1
no active
destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService
destination address email callhome@cisco.com
destination transport-method http
subscribe-to-alert-group diagnostic
subscribe-to-alert-group environment
subscribe-to-alert-group inventory periodic monthly
subscribe-to-alert-group configuration periodic monthly
subscribe-to-alert-group telemetry periodic daily
crashinfo save disable
Cryptochecksum:0760c72b39dd8d7a479d517a65758f33
: end
ciscoasa#

NOTE:

To enable SSH access, we need to generate also SSH keys as following:

ciscoasa(config)# crypto key generate rsa modulus 1024
Keypair generation process begin. Please wait…
ciscoasa(config)#

And here is the video:

I have found the following informative video which shows how to physically install a Content Security Services (CSC) Module in a Cisco ASA 5510 firewall appliance, and also how to create the initial setup configuration of this module using the graphical ASDM GUI of ASA firewall.

The CSC module provides protection against Viruses, Spam, Spyware and other unwanted traffic that can be found in data flowing in and out of your network, so I think its one of the useful security controls that you can put in place to protect your network and data.

New business requirements, the evolvement of social networking and web 2.0 and new generation technologies are driving new requirements for network and information security. Gartner has recently published their definition for next-generation firewalls, and they have noted that their famous “magic quadrant” reports for enterprise firewalls will now be taking into account the Next Generation Firewall capabilities of each tested device and vendor. The “Next Generation Firewall” concept, according to Gartner, will be a progression of current firewall and IPS devices which must include extra features and capabilities, mainly application and content inspection and protection. Next generation firewalls must be fully application aware (up to Layer7 protection) and not only up to Layer4.

Gartner’s recent Magic Quadrant report for enterprise firewalls, brought a new player into the first position, the Palo Alto Networks. Cisco has stayed behind this new generation security concept and they are now trying to catch up with the announcement of next generation capabilities in the new Cisco ASA CX product line. The new Cisco direction in network security was announced by Chris Young, senior vice president of Security, in RSA Conference 2012.

The new Cisco ASA CX products will be “context aware” and therefore they can provide protection against application threats and also offer inspection and traffic access control towards popular “micro-applications”, such as games in facebook or gambling apps in other popular websites. The new firewalls can also control access towards more than 1000 applications (facebook, twitter, google+, linkedin etc) and more than 75,000 micro applications for more granular context-aware control. So the main idea that we can take from this announcement is that the CX ASA product line will be centered around granular application, user and device control and better visibility in the network traffic. Just keep in mind also that in order to provide this comprehensive end-to-end security posture, the Cisco ASA CX must cooperate with other Cisco security products and solutions, such as Cisco SecureX Framework, Cisco AnyConnect Secure Mobility Client, and Cisco SIO (Security Intelligence Operations) for global threat intelligence data.

There are new Cisco ASA models available now, which will be under the CX framework. Specifically, the following new models were introduced:

  • ASA 5512-X
  • ASA 5515-X
  • ASA 5525-X
  • ASA 5545-X
  • ASA 5555-X

At the moment there is not much documentation and explanations about the new features introduced in those new models, so we can not describe them in more detail. We will come back again after more info is available.

Site to Site VPN between Cisco ASA and Router

In this post we will configure Site-to-Site IPSEC VPN between a Cisco IOS Router and ASA Firewall. ASA configuration is not much different from Cisco IOS with regards to IPSEC VPN since the fundamental concepts are the same. Let’s start our LAB example and we’ll see how it’s done.

Consider the following diagram. The first site (Remote1) is equipped with a Cisco ASA firewall (any model) and the second site (Remote2) is equipped with a Cisco Router. Remember that a Cisco ASA firewall is by default capable to support IPSEC VPN but a Cisco Router must have the proper IOS software type in order to support encrypted VPN tunnels.

Equipment Used in this LAB:

  • ASA 5510 – Cisco Adaptive Security Appliance Software Version 8.0(3)
  • Cisco Router 2801 – C2801-ADVIPSERVICESK9-M Version 12.4(9)T4

Scenario:

LAN of Remote1 must be connected to LAN of Remote2 via VPN Tunnel. The most usual scenario is that the WAN cloud is the Internet, so secure connectivity shall be provided between the two LAN networks over the Internet.

First of all we shall make sure that the outside interfaces of ASA and router must be reachable over the WAN. Now let’s start IPSEC VPN configuration.

Cisco ASA Configuration

First I started ASA configuration.

I’ve created an Access list, which will match the interesting traffic which is the traffic to be encrypted. If source is 192.168.3.0/24 and destination is 192.168.4.0/24, then traffic will be matched by the access list as “interesting traffic” and will be encrypted and pass through the tunnel.

ASA(config)# access-list vpn extended permit ip 192.168.3.0 255.255.255.0 192.168.4.0 255.255.255.0

!IKE PHASE #1
! I’ve created a phase1 policy. This policy provides secured process of exchanging Keys.

ASA(config)# crypto isakmp policy 1

! For authentication I used Pre-shared. This method is most frequently used today.
ASA(config)# authentication pre-share

!For encryption I used 3des.
ASA(config)# encryption 3des

! Hashing md5.
ASA(config)# hash md5

! I used second group of diffie-hellman. Group1 is used by default. The most secured is Group5.
ASA(config)# group 2

! configure crypto key. The keys must match to each other between peers. Otherwise Phase1 will not be completed.
ASA(config)# crypto isakmp secretsharedkey address 192.168.2.2

NOTE: Crypto key is hidden in ASA configuration. If we look at configuration, it will be shown in following way.
tunnel-group 192.168.2.2 ipsec-attributes
pre-shared-key *

! Activate policy on Outside interface.
ASA(config)# crypto isakmp enable outside

! IKE PHASE #2- VPN Tunnel is established during this phase and the traffic between VPN Peers is encrypted according to the security parameters of this phase.

! I created Transform-set, by which the traffic will be encrypted and hashed between VPN peers.
ASA(config)# crypto ipsec transform-set ts esp-3des esp-md5-hmac

! Apply the access list created earlier for matching the interesting traffic.
ASA(config)# crypto map vpn 10 match address vpn

! I indicated address of Remote2 peer public outside interface.
ASA(config)# crypto map vpn 10 set peer 192.168.2.2

! Apply also the transform-set.
ASA(config)# crypto map vpn 10 set transform-set ts

! Attach the already created Crypto-map and VPN to outside interface.
ASA(config)# crypto map vpn interface outside

ASA configuration is completed here (regarding the VPN config of course). Now let’s start Router Configuration below.

Cisco Router Configuration

ISAKMP Phase 1

! Enter crypto-isakmp policy configuration mode for configuring crypto isakmp policy.
Router(config)# crypto isakmp policy 10

! Turn on 3des as an encryption type.
Router(config)# encr 3des

! I indicated MD5 as a hashing type.
Router(config)# hash md5

! I indicated pre-share authentication.
Router(config)# authentication pre-share

! I used second group of diffie-hellman. group1 is used by default.
Router(config)# group 2

! I defined peer key same as ASA site.
Router(config)# crypto isakmp secretsharedkey address 192.168.1.2

It’s not necessary to match policy numbers. The most important is to match corresponding parameters of policy. Otherwise negotiation of Phase1 will not be successful.

! Access list for matching interesting traffic.
Router(config)# ip access-list extended vpn
Router(config)# permit ip 192.168.4.0 0.0.0.255 192.168.3.0 0.0.0.255

ISAKMP PHASE 2
!
! Create IPSEC transform-set, by which the mechanism of hashing and encryption is determined, by which the traffic will be hashed/encrypted in VPN tunnel later.
Router(config)# crypto ipsec transform-set ts esp-3des esp-md5-hmac

! Enter into crypto-map configuration mode.
Router(config)# crypto map vpn 10 ipsec-isakmp

! Indicate IP address of peer.
Router(config)# set peer 192.168.1.2

! Indicate IPsec transform-set created above.
Router(config)# set transform-set ts

! Apply access list created above.
Router(config)# match address vpn

! Apply crypto-map to interface.
Router(config)# interface FastEthernet0/0
Router(config)# crypto map vpn

With this, VPN configuration is completed so let’s start verification.

! In the output below it is shown that ISAKMP PHASE1 is active, which means that negotiation of PHASE1 is completed successfully.

ASA# show crypto isakmp sa

Active SA: 1
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1 IKE Peer: 192.168.2.2
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE

Router# show crypto isakmp sa
dst src state conn-id slot
192.168.1.2 192.168.2.2 MM_ACTIVE 1 0

! Checking ISAKMP PHASE2. Here we see that IPSec is working and the interesting traffic flows in VPN Tunnel.

ASA# show crypto ipsec sa
interface: outside
Crypto map tag: vpn, seq num: 10, local addr: 192.168.1.2

access-list vpn permit ip 192.168.3.0 255.255.255.0 192.168.4.0 255.255.255.0
local ident (addr/mask/prot/port): (192.168.3.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.4.0/255.255.255.0/0/0)
current_peer: 192.168.2.2

#pkts encaps: 344, #pkts encrypt: 344, #pkts digest: 344
#pkts decaps: 344, #pkts decrypt: 344, #pkts verify: 344

#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 344, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #framents created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#send errors: 0, #recv errors: 0

Router# show crypto ipsec sa

interface: FastEthernet0/0
Crypto map tag: vpn, local addr 192.168.2.2

protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.4.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.3.0/255.255.255.0/0/0)
current_peer 192.168.1.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 344, #pkts encrypt: 344, #pkts digest: 344
#pkts decaps: 344, #pkts decrypt: 344, #pkts verify: 344

#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

VPN Tunnel is established and works.

 Page 3 of 16 « 1  2  3  4  5 » ...  Last »