ASA CHAPTER 8 (MPF HTTP)
13.HTTP Traffic Inspection
• The ASA should spoof the HTTP server headers to pretend that it is
“Apache/2.2.0 (Unix)”.
• Additionally, the firewall should reset the TCP connection upon any HTTP
protocol violations for extra security.
• For the HTTP connections from the inside, restrict the number of half-open
connections to 100 and the total number of connections to the HTTP
server to 200.
• Since DoS attacks are more expected from the outside, ensure the firewall
allows no more than 50 embryonic connections from the outside and limit
the total number of outside connections to 100.
-->
The purpose of Modular Policy Framework is to allow creating flexible traffic
inspection rules. Traffic inspection is the core of the stateful firewall, as it
accomplishes the following main purposes:
1) Inspects protocol commands and dynamically modify firewall rules to permit
secondary information channels, like with H.323 and FTP
2) Perform deep traffic inspection to detect protocol violations, anomalies and
attacks.
3) Dynamically modify packet contents to remove potential threats or hide some
sensitive information.
MPF replaced the legacy fixuptraffic inspection command with totally new
configuration concepts. MPF (Modular Policy Framework) configuration is similar
to MQC (Modular QoS CLI) configuration on IOS router. Starting with recent IOS
releases you may find many similarities between the IOS zone based firewall and
the ASA MPF configuration.
In order to inspect traffic in the ASA firewall you should perform the following
basic steps:
1) Define Layer 3/Layer 4 classification criteria. For example, if you want to
inspect HTTP traffic to a particular server, you may define an access-list to match
this traffic e.g. access-list HTTP_TRAFFIC_ACL permit tcp any host
10.0.0.100 eq 80and then create new L3/L4 class-map that matches the
traffic flow:
class-map HTTP_TRAFFIC_CMAP
match access-list HTTP_TRAFFIC_ACL
This is very similar to MQC configuration in IOS routers – class-maps are used
for traffic classification based on L3/L4 criteria. As usual, you may create matchany or match-allclass-maps, with the first type matching any of the
statements in the class-map, while the second requiring all statements to be
matched. In addition to using ACLs, you can match traffic based on
DSCP/Precedence, port numbers as well, though using the ACLs is more
flexible. In addition, the ASA firewall allows using some unique classification
criteria, such as matching VPN traffic flows.
2) Define a policy-map that associates certain actions with L3/L4 class-maps. For
example, here is a policy that inspects HTTP traffic:
policy-map INSPECT_HTTP_PMAP
class HTTP_TRAFFIC_CMAP
inspect http
his will apply HTTP inspection engine to the traffic matching the L3/L4 class
map. In addition to inspection, another most common setting is the command
set connectionwhich allows changing various TCP session parameters.
Most notably, you can change the maximum number of connections and the
maximum number of half-open (embryonic) connections for the particular traffic
class. This is much more flexible that using the staticcommand.
3) Apply the policy map to an interface or globally. When you apply the service
policy to an interface using the command service-policy <POLICY>
interface <iface>all ingress or egress traffic on the interface <iface>is
inspected according to the policy settings. When you apply the policy-map
globally using the command service-policy <POLICY>global it applies to
all inboundtraffic flows on all interfaces.
Note that there is alwaysa global policy defined, either user-specified or the
default. If you have both the global and interface policies applied, the interface
policy takes precedence for the same feature. For example, if the interface-level
policy inspects HTTP and the global policy inspects FTP than the effect is
combined. However, if both the interface and global policy inspects the same
protocol (with potentially different settings) than the interface-level policy-map
takes precedence.
The default inspection policy uses special match statement match defaultinspection-traffic, which allows matching a bunch of default protocols at
the same time. The respective class has a group of inspect statements
associated in the default global policy-map. This is needed to replicate the
default behavior of the old fixupcommands.
The next question is – what if we would like to tune the inspection engine
parameters, instead of simply relaying on the default values? For example, we
would like to tune HTTP and FTP inspection. To accomplish this, the firewall
supports the concepts of inspection class-maps and policy-maps. Defined using
the syntax class-map type inspect <protocol>and policy-map type
inspect <protocol>they are designed to be used together. If we want to
create a customer HTTP inspection rule, we would use the following syntax:
policy-map type inspect http HTTP_INSPECT
parameters
protocol-violation action reset
Later, this customer inspection policy map is bound to the inspect statement
under the L3/L4 class in the regular policy-map:
policy-map INSPECT_HTTP_PMAP
class HTTP_TRAFFIC_CMAP
inspect http HTTP_INSPECT
allowing for fine-tuning of HTTP inspection engine. Every type of inspect policy
map (HTTP, ESMTP, FTP, DNS and so on) has its own set of unique parameters
and options, which are fully described in the firewall documentation. Some
advanced inspection settings might require protocol-specific classifications. For
example, you might want to set various HTTP inspection options only for sites
matching certain URLs. To accomplish this, we create a special HTTP inspect
class-map that matches the URIs against certain regex and then we use this
class in the HTTP inspect policy-map and associate and action.
regex CISCO "www\.cisco\.com/.*"
class-map type inspect http URI_CISCO
match request uri regex CISCO
policy-map type inspect http HTTP_POLICY
class URI_CISCO
log
You cannot use regular L3/L4 class-maps with the inspect type policy-map.
Remember that inspection policy-maps have no effect until they are associated
with the inspectcommand in a normal policy-map.
As for our scenario, it is relatively straight-forward. We classify traffic going to the
WWW server from the inside and outside directions, by using two L3/L4 classmaps. Both class-maps match access-lists, but one of them uses the translated
IP address of the WWW server (for the outside policy).
Then we create a special HTTP inspection policy-map that is used to tweak the
HTTP inspection settings. After this, the final step is creating two normal policymaps, for the inside and outside interfaces. The inside-interface policy-map
matches the class for “inside to the server” traffic and the outside interface policymap matches the traffic from the “outside to the server”. Both policy-maps apply
the HTTP inspection policy to the matched traffic. In addition to that, the
connection options are set to accomplish the goal of limiting the number of halfopen and open sessions.
-->
Solution:
! Define & Apply Access-Lists
!
access-list OUTSIDE_IN permit tcp any host 10.0.0.100 eq www
access-group OUTSIDE_IN in interface outside
!
! Clasify traffic from inside to the WWW server
!
access-list HTTP_FROM_INSIDE permit tcp 136.1.121.0 255.255.255.0 host
10.0.0.100 eq www
!
! Classify traffic from outside to the WWW server
!
access-list HTTP_FROM_OUTSIDE permit tcp 136.1.122.0 255.255.255.0 host
10.0.0.100 eq www
!
! Define L3/L4 class-maps
!
class-map HTTP_FROM_INSIDE
match access-list HTTP_FROM_INSIDE
class-map HTTP_FROM_OUTSIDE
match access-list HTTP_FROM_OUTSIDE
!
! Define HTTP inspection policy
!
policy-map type inspect http HTTP_INSPECT
parameters
spoof-server "Apache/2.2.0 (Unix)"
!
protocol-violation action reset
!
! Create policy maps
!
policy-map OUTSIDE
class HTTP_FROM_OUTSIDE
inspect http HTTP_INSPECT
set connection conn-max 100 embryonic-conn-max 50
policy-map INSIDE
class HTTP_FROM_INSIDE
inspect http HTTP_INSPECT
set connection conn-max 200 embryonic-conn-max 100
!
! Apply the policies
!
service-policy OUTSIDE interface outside
service-policy INSIDE interface inside
!
output: at R1 & R3:
!
R1#telnet 10.0.0.100 80
Trying 10.0.0.100, 80 ... Open
sdfasdf
HTTP/1.1 400 Bad Request
Date: Fri, 01 Mar 2002 00:16:33 GMT
Server:Apache/2.2.0(UNIX)
Accept-Ranges: none
400 Bad Request
[Connection to 10.0.0.100 closed by foreign host]
!
R3#telnet 10.0.0.100 80
Trying 10.0.0.100, 80 ... Open
[Connection to 10.0.0.100 closed by foreign host]
R3#telnet 10.0.0.100 80
Trying 10.0.0.100, 80 ... Open
asdf
HTTP/1.1 400 Bad Request
Date: Fri, 01 Mar 2002 00:16:10 GMT
Server:Apache/2.2.0(UNIX)
Accept-Ranges: none
400 Bad Request
[Connection to 10.0.0.100 closed by foreign host]
!
13.HTTP Traffic Inspection
• The ASA should spoof the HTTP server headers to pretend that it is
“Apache/2.2.0 (Unix)”.
• Additionally, the firewall should reset the TCP connection upon any HTTP
protocol violations for extra security.
• For the HTTP connections from the inside, restrict the number of half-open
connections to 100 and the total number of connections to the HTTP
server to 200.
• Since DoS attacks are more expected from the outside, ensure the firewall
allows no more than 50 embryonic connections from the outside and limit
the total number of outside connections to 100.
-->
The purpose of Modular Policy Framework is to allow creating flexible traffic
inspection rules. Traffic inspection is the core of the stateful firewall, as it
accomplishes the following main purposes:
1) Inspects protocol commands and dynamically modify firewall rules to permit
secondary information channels, like with H.323 and FTP
2) Perform deep traffic inspection to detect protocol violations, anomalies and
attacks.
3) Dynamically modify packet contents to remove potential threats or hide some
sensitive information.
MPF replaced the legacy fixuptraffic inspection command with totally new
configuration concepts. MPF (Modular Policy Framework) configuration is similar
to MQC (Modular QoS CLI) configuration on IOS router. Starting with recent IOS
releases you may find many similarities between the IOS zone based firewall and
the ASA MPF configuration.
In order to inspect traffic in the ASA firewall you should perform the following
basic steps:
1) Define Layer 3/Layer 4 classification criteria. For example, if you want to
inspect HTTP traffic to a particular server, you may define an access-list to match
this traffic e.g. access-list HTTP_TRAFFIC_ACL permit tcp any host
10.0.0.100 eq 80and then create new L3/L4 class-map that matches the
traffic flow:
class-map HTTP_TRAFFIC_CMAP
match access-list HTTP_TRAFFIC_ACL
This is very similar to MQC configuration in IOS routers – class-maps are used
for traffic classification based on L3/L4 criteria. As usual, you may create matchany or match-allclass-maps, with the first type matching any of the
statements in the class-map, while the second requiring all statements to be
matched. In addition to using ACLs, you can match traffic based on
DSCP/Precedence, port numbers as well, though using the ACLs is more
flexible. In addition, the ASA firewall allows using some unique classification
criteria, such as matching VPN traffic flows.
2) Define a policy-map that associates certain actions with L3/L4 class-maps. For
example, here is a policy that inspects HTTP traffic:
policy-map INSPECT_HTTP_PMAP
class HTTP_TRAFFIC_CMAP
inspect http
his will apply HTTP inspection engine to the traffic matching the L3/L4 class
map. In addition to inspection, another most common setting is the command
set connectionwhich allows changing various TCP session parameters.
Most notably, you can change the maximum number of connections and the
maximum number of half-open (embryonic) connections for the particular traffic
class. This is much more flexible that using the staticcommand.
3) Apply the policy map to an interface or globally. When you apply the service
policy to an interface using the command service-policy <POLICY>
interface <iface>all ingress or egress traffic on the interface <iface>is
inspected according to the policy settings. When you apply the policy-map
globally using the command service-policy <POLICY>global it applies to
all inboundtraffic flows on all interfaces.
Note that there is alwaysa global policy defined, either user-specified or the
default. If you have both the global and interface policies applied, the interface
policy takes precedence for the same feature. For example, if the interface-level
policy inspects HTTP and the global policy inspects FTP than the effect is
combined. However, if both the interface and global policy inspects the same
protocol (with potentially different settings) than the interface-level policy-map
takes precedence.
The default inspection policy uses special match statement match defaultinspection-traffic, which allows matching a bunch of default protocols at
the same time. The respective class has a group of inspect statements
associated in the default global policy-map. This is needed to replicate the
default behavior of the old fixupcommands.
The next question is – what if we would like to tune the inspection engine
parameters, instead of simply relaying on the default values? For example, we
would like to tune HTTP and FTP inspection. To accomplish this, the firewall
supports the concepts of inspection class-maps and policy-maps. Defined using
the syntax class-map type inspect <protocol>and policy-map type
inspect <protocol>they are designed to be used together. If we want to
create a customer HTTP inspection rule, we would use the following syntax:
policy-map type inspect http HTTP_INSPECT
parameters
protocol-violation action reset
Later, this customer inspection policy map is bound to the inspect statement
under the L3/L4 class in the regular policy-map:
policy-map INSPECT_HTTP_PMAP
class HTTP_TRAFFIC_CMAP
inspect http HTTP_INSPECT
allowing for fine-tuning of HTTP inspection engine. Every type of inspect policy
map (HTTP, ESMTP, FTP, DNS and so on) has its own set of unique parameters
and options, which are fully described in the firewall documentation. Some
advanced inspection settings might require protocol-specific classifications. For
example, you might want to set various HTTP inspection options only for sites
matching certain URLs. To accomplish this, we create a special HTTP inspect
class-map that matches the URIs against certain regex and then we use this
class in the HTTP inspect policy-map and associate and action.
regex CISCO "www\.cisco\.com/.*"
class-map type inspect http URI_CISCO
match request uri regex CISCO
policy-map type inspect http HTTP_POLICY
class URI_CISCO
log
You cannot use regular L3/L4 class-maps with the inspect type policy-map.
Remember that inspection policy-maps have no effect until they are associated
with the inspectcommand in a normal policy-map.
As for our scenario, it is relatively straight-forward. We classify traffic going to the
WWW server from the inside and outside directions, by using two L3/L4 classmaps. Both class-maps match access-lists, but one of them uses the translated
IP address of the WWW server (for the outside policy).
Then we create a special HTTP inspection policy-map that is used to tweak the
HTTP inspection settings. After this, the final step is creating two normal policymaps, for the inside and outside interfaces. The inside-interface policy-map
matches the class for “inside to the server” traffic and the outside interface policymap matches the traffic from the “outside to the server”. Both policy-maps apply
the HTTP inspection policy to the matched traffic. In addition to that, the
connection options are set to accomplish the goal of limiting the number of halfopen and open sessions.
-->
Solution:
! Define & Apply Access-Lists
!
access-list OUTSIDE_IN permit tcp any host 10.0.0.100 eq www
access-group OUTSIDE_IN in interface outside
!
! Clasify traffic from inside to the WWW server
!
access-list HTTP_FROM_INSIDE permit tcp 136.1.121.0 255.255.255.0 host
10.0.0.100 eq www
!
! Classify traffic from outside to the WWW server
!
access-list HTTP_FROM_OUTSIDE permit tcp 136.1.122.0 255.255.255.0 host
10.0.0.100 eq www
!
! Define L3/L4 class-maps
!
class-map HTTP_FROM_INSIDE
match access-list HTTP_FROM_INSIDE
class-map HTTP_FROM_OUTSIDE
match access-list HTTP_FROM_OUTSIDE
!
! Define HTTP inspection policy
!
policy-map type inspect http HTTP_INSPECT
parameters
spoof-server "Apache/2.2.0 (Unix)"
!
protocol-violation action reset
!
! Create policy maps
!
policy-map OUTSIDE
class HTTP_FROM_OUTSIDE
inspect http HTTP_INSPECT
set connection conn-max 100 embryonic-conn-max 50
policy-map INSIDE
class HTTP_FROM_INSIDE
inspect http HTTP_INSPECT
set connection conn-max 200 embryonic-conn-max 100
!
! Apply the policies
!
service-policy OUTSIDE interface outside
service-policy INSIDE interface inside
!
output: at R1 & R3:
!
R1#telnet 10.0.0.100 80
Trying 10.0.0.100, 80 ... Open
sdfasdf
HTTP/1.1 400 Bad Request
Date: Fri, 01 Mar 2002 00:16:33 GMT
Server:Apache/2.2.0(UNIX)
Accept-Ranges: none
400 Bad Request
[Connection to 10.0.0.100 closed by foreign host]
!
R3#telnet 10.0.0.100 80
Trying 10.0.0.100, 80 ... Open
[Connection to 10.0.0.100 closed by foreign host]
R3#telnet 10.0.0.100 80
Trying 10.0.0.100, 80 ... Open
asdf
HTTP/1.1 400 Bad Request
Date: Fri, 01 Mar 2002 00:16:10 GMT
Server:Apache/2.2.0(UNIX)
Accept-Ranges: none
400 Bad Request
[Connection to 10.0.0.100 closed by foreign host]
!
No comments:
Post a Comment