ACE+WAF DG August 2008 Rev 1.

Design Guide: ACE appliance and ACE Web Application Firewall

Introduction

The Cisco ACE Web Application Firewall (datasheet:

http://www.cisco.com/en/US/prod/collateral/contnetw/ps5719/ps9586/data_sheet_c
78-458627.html) is a high-performance reverse-proxy style security solution for
your off-the-shelf and custom web applications. The ACE WAF does not provide
high-availability services in and out of itself, it relies on the network for that
purpose. This design guide shows you how to front-end Cisco ACE Web
Application Firewalls with an ACE 4710 appliance in order to provide a highly
available, scalable and secure framework for your web applications.

Recommended topology

cpaggen ADBU – Technical Marketing 1

ACE+WAF DG August 2008 Rev 1.0

Detailed topology walkthrough

Clients on the Internet who wish to connect to our main web application
(http://acedemo.cisco.com in our case) obtain the IP address of the front-end virtual
IP (VIP) through DNS resolution. In this topology, the specific IP address mapped
to acedemo.cisco.com is 172.25.89.165. That VIP is owned by a Cisco ACE 4710
appliance on the front-end side of the diagram. It is linked to a serverfarm which
contains two load-balanced servers which are the actual Cisco ACE Web
Application Firewalls (WAF). Because the ACE WAFs are stateless no particular
stickiness needs to be configured between the front-end VIP and the WAFs
themselves. Requests from clients are load-balanced in a round-robin fashion. A
given client session might see its packets load-balanced between WAF1 and WAF2.
That is perfectly acceptable because the WAFs treat each request as a finite
transaction which bears no relation with the previous or next request.

Once the traffic hits a WAF incoming data is filtered according to the security
profile configured on that WAF. If the traffic is allowed to proceed, the WAF
substitutes the original source IP address of the packet with its own IP address. This
is very important to remember. It isn’t something you can change, that’s how most
reverse proxies function and the WAF falls in that category.

The actual origin (or target) web servers are concealed behind a second back-end
VIP. This step is required because the WAFs themselves do not perform any sort of
server load balancing. The second VIP in our case is 10.30.30.12. The WAFs are
configured to answer requests for hostname acedemo.cisco.com mapping to
destination server 10.30.30.12:

However, a very important configuration step needs to be performed before sending

traffic from the WAFs to the back-end VIP. Our web servers run a shopping-cart
application which does maintain state on a per-session basis. State information
includes items contained in the shopping cart for instance. It is therefore imperative
to stick a given client to the same target web server for the duration of the session.
With the original client IP address lost, how is this accomplished? The WAF can
insert an HTTP header in requests made to the back-end VIP. That header contains
the source IP address of the client. Here is a snapshot of the profile on the WAFs:

cpaggen ADBU – Technical Marketing 2

ACE+WAF DG August 2008 Rev 1.0

You can either select the factory-provided option to insert the X-Forwarded-For
header (first line of the HTTP Header Processing section of the profile) or manually
add one. We chose to manually add the header in this case. There was no specific
reason to do so other than demonstrate the WAF’s ability to tailor requests and
responses based on user-specified variables.

The back-end VIP is configured to stick sessions to a given web server based on the
value found in the X-Forwarded-For header. Here is how this is configured on the
ACE 4710:

The sticky group is configured as follows:

cpaggen ADBU – Technical Marketing 3

ACE+WAF DG August 2008 Rev 1.0

That configuration instructs the ACE 4710 to look for the presence of the X-
Forwarded-For header in requests made to the back-end VIP and stick clients (the
WAFs in this case) to one specific web server based on the value of the header.

The traffic then hits the selected web server which returns content back to the
source IP address who requested it. That source IP address belongs to one of the
WAFs. The return traffic from the server back to client takes the reverse path by
virtue of the stateful nature of the ACE 4710. In other words thanks to the pre-
established connection record that incoming traffic set up, return traffic symmetry is
ensured. Make sure that the web servers have the proper static route to reach the IP
address of the WAFs.

Health Monitoring

To maintain a high level of availability we need to ensure that both the WAFs and
the target web servers are able to service requests at any give time. The WAFs
themselves do not implement health checks for target servers. Therefore health
checks for WAFs and web servers become the responsibility of the ACE 4710
through the use of probes. The ACE 4710 can probe the WAF directly or verify that
traffic from the web servers can be served through the WAF. This is how you can
configure the latter probe:

cpaggen ADBU – Technical Marketing 4

ACE+WAF DG August 2008 Rev 1.0

The CLI equivalent of the probe is:

probe http THROUGH_WAF1

ip address 10.30.30.2
interval 3
passdetect interval 60
request method get url /index.php?categoryID=66
expect status 200 200
header Host header-value "acedemo.cisco.com"
open 1
probe http THROUGH_WAF2
ip address 10.30.30.3
interval 3
passdetect interval 60
request method get url /index.php?categoryID=66
expect status 200 200
header Host header-value "acedemo.cisco.com"
open 1

The probes are applied to each WAF. Note: if you would like to insert a question
mark at the CLI for the URL, press CTRL-V before hitting the ‘?’ key.

cpaggen ADBU – Technical Marketing 5

ACE+WAF DG August 2008 Rev 1.0

You can use a similar probe at the back-end level to verify that the web servers are
up and running.

Complete ACE 4710 configuration

4710-SA/WAFLB# sh run
Generating configuration....

logging enable
logging timestamp
logging monitor 7
logging device-id context-name
no logging message 111009

access-list allin line 8 extended permit ip any any

probe http THROUGH_WAF1

ip address 10.30.30.2
interval 3
passdetect interval 60
request method get url /index.php?categoryID=66
expect status 200 200
header Host header-value "acedemo.cisco.com"
open 1
probe http THROUGH_WAF2
ip address 10.30.30.3
interval 3
passdetect interval 60
request method get url /index.php?categoryID=66
expect status 200 200
header Host header-value "acedemo.cisco.com"
open 1

parameter-map type http xff

case-insensitive
persistence-rebalance
set header-maxparse-length 8192
length-exceed continue

rserver host waf-one

ip address 10.30.30.2
probe THROUGH_WAF1
inservice
rserver host waf-two
ip address 10.30.30.3
probe THROUGH_WAF2
inservice
rserver host www-one
ip address 10.30.30.18
inservice
rserver host www-two
ip address 10.30.30.19
inservice

cpaggen ADBU – Technical Marketing 6

ACE+WAF DG August 2008 Rev 1.0

serverfarm host wafs

rserver waf-one
inservice
rserver waf-two
inservice
serverfarm host web
rserver www-one
inservice
rserver www-two
inservice

sticky http-header X-Forwarded-For XFF

timeout 10
serverfarm web

class-map match-all backend-vip

2 match virtual-address 10.30.30.12 tcp eq www
class-map match-all frontend-vip
2 match virtual-address 172.25.89.165 tcp eq www

class-map type management match-any remoteaccess

2 match protocol ssh any
3 match protocol icmp any
4 match protocol http any
5 match protocol https any
6 match protocol xml-https any

policy-map type management first-match remoteaccess

class remoteaccess
permit

policy-map type loadbalance first-match traffic-for-WAF

class class-default
serverfarm wafs
policy-map type loadbalance first-match traffic-from-waf
class class-default
sticky-serverfarm XFF

policy-map multi-match back-end

class backend-vip
loadbalance vip inservice
loadbalance policy traffic-from-waf
loadbalance vip icmp-reply
appl-parameter http advanced-options xff

policy-map multi-match front-end

class frontend-vip
loadbalance vip inservice
loadbalance policy traffic-for-WAF
optimize http policy php
loadbalance vip icmp-reply

service-policy input remoteaccess

access-group input allin

interface vlan 2
description Intranet

cpaggen ADBU – Technical Marketing 7

ACE+WAF DG August 2008 Rev 1.0

ip address 172.25.89.151 255.255.255.192

service-policy input front-end
no shutdown
interface vlan 300
description TO_WAFs
ip address 10.30.30.1 255.255.255.248
no shutdown
interface vlan 400
description FROM_WAFs
ip address 10.30.30.9 255.255.255.248
service-policy input back-end
no shutdown
interface vlan 500
description TO_SERVERS
ip address 10.30.30.17 255.255.255.248
no shutdown

ip route 0.0.0.0 0.0.0.0 172.25.89.129

username admin password 5 $1$xbAl8Lc9$M6Sfalx1lD0iKWldOqtuh/ role
Admin domain default-domain

cpaggen ADBU – Technical Marketing 8