Cisco 1841 filter http requests by string match

[admiralmedia]

I have an web server behind an Cisco 1841 router which receives many requests as follows(DDOS Slowloris), which causes bandwidth and server resources consumption:

"POST /wp-login.php HTTP1.1"

On the web server I've managed using Iptables to stop those requests but now I want to pass this task to the Cisco 1841 router so this kind of requests will stop at the gateway and not going all the way to the web server.

How can this be set up in Cisco firewall so that any request matching the string "POST /wp-login.php HTTP1.1"  to be dropped?

[Mark Malone · Accepted solution]

Hi

theres a couple of ways to do this that might work on an 1841 you can try them anyway

check his link

http://www.cisco.com/c/en/us/support/docs/routers/7500-series-routers/27842-nbar-acl-codered.html

HTH

[admiralmedia]

Thanks for the solution, I've implemented method A( ACL):

class-map match-any http-hacks
 match protocol http url "*wp-login.php*"
 match protocol http url "*/-/-/-/-/-/-/-/-/-/-*"
 match protocol http url "*/wp-login.php*"
 match protocol http url "*GET*/wp-login.php*HTTP*"
 match protocol http url "*POST*/wp-login.php*HTTP*"

policy-map mark-inbound-http-hacks
 class http-hacks
  set ip dscp 1

interface Dialer0
 description Connect to PPPOE
 ip address negotiated
 ip access-group 105 out

........

sh access-lists 105
Extended IP access list 105
    10 deny ip any any dscp 1 (5 matches)
    20 permit ip any any (55834 matches)

The issue is that there are only 5 matches in an interval of 1h, but on my web server on the rule in iptables there are a couple hundreds of dropped matches. So the solution works on cisco but is not catching all the matching packets.

Any idea?

[Mark Malone]

Yes honestly i was 50/50 whether it would work or not , 1841s are really routers with firewall features rather than the other way around , the routers just not catching everything your config looks good and as you said its catching some but not all

You could try 1 of the other methods see if its better at catching the correct packets or if your IOS supports you could try cbac (ip inspect) below which should do the trick only thought of that after yesterday

http://www.cisco.com/c/en/us/products/collateral/security/ios-firewall/product_implementation_design_guide09186a00800fd670.html

https://supportforums.cisco.com/document/81561/basic-url-filter-using-cbac

[admiralmedia]

So for now I have the following config which seems to be doing the job:

class-map match-any SLOWLORIS
 match protocol http url "*wp-login.php*"
 match protocol http url "*/-/-/-/-/-/-/-/-/-/-*"
!
!
policy-map DROP_SLOWLORIS
 class SLOWLORIS
   drop

interface Dialer0
 description Connect to PPPOE
.........
 service-policy input DROP_SLOWLORIS

And I monitor the drops using the bellow command, virtual-access 2 itnerface is bind to dialer 0

#sh policy-map interface virtual-access 2

 Virtual-Access2

  Service-policy input: DROP_SLOWLORIS

    Class-map: SLOWLORIS (match-any)
      9773 packets, 2901620 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol http url "*wp-login.php*"
        9773 packets, 2901620 bytes
        5 minute rate 0 bps
      Match: protocol http url "*/-/-/-/-/-/-/-/-/-/-*"
        0 packets, 0 bytes
        5 minute rate 0 bps
      drop

    Class-map: class-default (match-any)
      1544011 packets, 1970706533 bytes
      5 minute offered rate 11000 bps, drop rate 0 bps
      Match: any

So basically now the filtering is made by Cisco router and not by iptables on web server side. The only issue is that I receive into apache logs for the main server domains, what I think is that for every drop rule in iptables for my criteria an entry is logged as 408 - request time out:

XXX.XXX.XXX.XXX - - [24/Jul/2015:12:39:58 +0300] "-" 408 - "-" "-"

But now disabling the iptables rules into the web server so basically no more drops from server I still receive into the logs the 408 errors! Which is strange as the drop rule is in cisco and all the connections from those Ip's should not go all the way through the web server.

Any ideas about why is this happening?

[Mark Malone]

Not sure exactly on that you could set a span session on the server and see whats happening as the packets are being dropped it may give you an indication