|
0:00:13
|
So in our next section here for the asa
|
|
0:00:16
|
we are going to talk about the Modular Policy Framework or the MPF
|
|
0:00:21
|
that uses the inspection engine for traffic as it is moving from the higher security
|
|
0:00:26
|
interfaces to the lower security interfaces
|
|
0:00:28
|
and its going to allow us to do our application level inspections
|
|
0:00:32
|
we will talk about specifically how the Modular Policy Framework does its classification
|
|
0:00:37
|
the different types of class maps
|
|
0:00:39
|
and policy maps, whether they be layer3 to layer4
|
|
0:00:43
|
or the layer7 application maps
|
|
0:00:46
|
How we can change some of the tcp and udp normalization settings with the ASA
|
|
0:00:52
|
which is going to control things like how many connections we can have
|
|
0:00:55
|
or any type of denial of service attack prevention
|
|
0:00:59
|
or any type of mal formed ip packet attack
|
|
0:01:02
|
and then also the application level inspections
|
|
0:01:05
|
thats going to allow us to look into the actual
|
|
0:01:07
|
payload of things like an http session or an ftp session or a mail session
|
|
0:01:15
|
Now as we talked about before
|
|
0:01:18
|
what the Modular Policy Framework is for, is to define, how traffic is going to be inspected
|
|
0:01:22
|
as well as some of the minor Quality of Service Parameters
|
|
0:01:26
|
for things like traffic shaping, traffic policing or traffic prioritization
|
|
0:01:31
|
Now the syntax is going to be similar in logic to how the regular cisco IOS Modular
|
|
0:01:36
|
Quality of Service or the MQC works
|
|
0:01:39
|
thats normally used for QoS parameters on the router
|
|
0:01:42
|
for things like banner reservations or prioritization
|
|
0:01:47
|
Now we will see there is a little bit difference in logic in how the classification works
|
|
0:01:51
|
with the MPF
|
|
0:01:53
|
we are going to use the same type of 3 step process
|
|
0:01:56
|
as we do on the routers QoS
|
|
0:01:58
|
as we will do here in the ASA with the MPF
|
|
0:02:02
|
Now additionally when we get to the IOS zone based firewall
|
|
0:02:05
|
we are going to see that the MPF is using the same type of logic
|
|
0:02:09
|
where we are using the class maps
|
|
0:02:11
|
for traffic selection or to do the classification of what we are trying to inspect
|
|
0:02:16
|
then we will use the policy maps to actually
|
|
0:02:19
|
apply the action of how the inspection is going to happen
|
|
0:02:22
|
and specifically
|
|
0:02:23
|
we can apply this two ways in asa, we can apply this globally
|
|
0:02:28
|
and we saw that there is a default global policy
|
|
0:02:31
|
then we can look at if we look at the
|
|
0:02:35
|
show run all policy map and show run all class map
|
|
0:02:39
|
and additionally we can apply the policy on to the interface
|
|
0:02:43
|
which is going to have an implicit direction or either inbound or outbound
|
|
0:02:48
|
depending on what type of action that we are trying to apply on to the traffic
|
|
0:02:53
|
so we will see its a little bit different than the IOS
|
|
0:02:56
|
where in the IOS, we apply the service
|
|
0:02:58
|
policy explicitly inbound or outbound to the interface
|
|
0:03:02
|
and in the case of the asa we apply it to the interface itself
|
|
0:03:06
|
then depending on what we are doing in the policy map
|
|
0:03:08
|
thats going to determine what the traffic direction is, whether its inbound or outbound
|
|
0:03:15
|
now once we define the policy map thats also where we can specify our
|
|
0:03:19
|
protocol specific actions
|
|
0:03:21
|
as I mentioned for things like the inspection of http headers
|
|
0:03:25
|
ftp commands, mail commands, dns commands etc
|
|
0:03:32
|
Now the first step of our configuration again is going to be to classify the traffic
|
|
0:03:37
|
and this is going to be accomplished by using the class maps
|
|
0:03:40
|
Now depending on what type of class that we are using whether its a normal layer3 layer4 class
|
|
0:03:47
|
or class map type inspect
|
|
0:03:49
|
that is used for the application level matching
|
|
0:03:52
|
there is a number of different attributes that we can match for attribute flow
|
|
0:03:56
|
first of which being simply an access list
|
|
0:03:59
|
so either a standard access list that specifying a source of traffic
|
|
0:04:03
|
or an extended access list that could match on source and destinations
|
|
0:04:07
|
source and destination port pairs, protocol number
|
|
0:04:09
|
and different attributes in the layer4 header
|
|
0:04:15
|
we could also match on
|
|
0:04:17
|
our layer3
|
|
0:04:20
|
marking for Quality of Service like differentiated services code points
|
|
0:04:24
|
the dhcp or the Ip precedence
|
|
0:04:27
|
which typically would be used when we are trying to classify traffic like voice over ip
|
|
0:04:32
|
and then with the Modular Policy Framework try to put this traffic into the priority queue
|
|
0:04:37
|
or may be we are trying to limit some type of traffic like icmp
|
|
0:04:40
|
so that its not saturating the link
|
|
0:04:45
|
we will also see when we get into more details with the IPSec VPNs and the SSL VPNs
|
|
0:04:51
|
that we can use the Modular Policy Framework to match the tunnel group
|
|
0:04:55
|
which is associated with an individual IPSec tunnel or an individual SSL VPN tunnel
|
|
0:05:02
|
So in this manner we could treat a
|
|
0:05:05
|
easy VPN client's traffic or an SSL VPN client's traffic different
|
|
0:05:09
|
from either an inspection point of view
|
|
0:05:12
|
or from a Quality of Service point of view
|
|
0:05:14
|
as the traffic is being routed in on the outside interface
|
|
0:05:19
|
and then back out either to the internal network
|
|
0:05:21
|
or back out to the public network outside
|
|
0:05:27
|
we will also see that the classes have a default inspection
|
|
0:05:31
|
traffic class
|
|
0:05:32
|
thats going to be used for some of the
|
|
0:05:34
|
the applications that are automatically inspected on asa
|
|
0:05:38
|
which is going to be things like SIP for IP phones
|
|
0:05:41
|
or web traffic, dns traffic
|
|
0:05:44
|
when we look at the show run all class map
|
|
0:05:47
|
we can see some of the parameters that are listed there for the default inspection
|
|
0:05:53
|
Now as I mentioned previously a lot of these syntax
|
|
0:05:56
|
you don't necessarily need to memorize
|
|
0:05:58
|
because you can use whats already on the command line
|
|
0:06:01
|
with show run all class map, show run all policy map
|
|
0:06:04
|
show run all regex
|
|
0:06:06
|
and show run all service policy to figure out what is the default
|
|
0:06:09
|
inspection policy to start
|
|
0:06:14
|
Now once we define
|
|
0:06:16
|
specifically what traffic that we are trying to match with the class map
|
|
0:06:20
|
then we are going to use the policy map to define how is the traffic actually going to be treated
|
|
0:06:26
|
So from the policy map we are going to call the specific class
|
|
0:06:29
|
whether this class is matching an access list, lets say look at port
|
|
0:06:33
|
80 for web traffic or may be look at
|
|
0:06:36
|
port 179 for bgp
|
|
0:06:39
|
and the main action typically we are going to take is to inspect the traffic
|
|
0:06:44
|
So this is going to put it through the individual application inspection engine
|
|
0:06:49
|
in the case of things like http, dns or ftp
|
|
0:06:54
|
or it could be just the generic inspection engine
|
|
0:06:57
|
thats going to be for any other standard
|
|
0:06:59
|
tcp applications or udp applications
|
|
0:07:05
|
for tcp and udp sessions we can also set the connection advance options
|
|
0:07:10
|
this is going to be where we change things
|
|
0:07:12
|
like the denial of service protection
|
|
0:07:14
|
or what particular ip options
|
|
0:07:17
|
are allowed in either the tcp or the udp header
|
|
0:07:21
|
so this would be things like
|
|
0:07:22
|
whether tcp time stamping is allowed
|
|
0:07:25
|
whether md5 authentication is allowed in the tcp header
|
|
0:07:30
|
so we can control more than just the layer3 information
|
|
0:07:34
|
which would be like our source and destination ip addresses
|
|
0:07:37
|
we can also do the inspection based on the layer4 information
|
|
0:07:40
|
in the tcp or the udp header
|
|
0:07:45
|
beyond these two pretty much the other actions are going to
|
|
0:07:47
|
be using or related to Quality of Service
|
|
0:07:50
|
these are the going to be the police, shape or priority actions
|
|
0:07:54
|
where policing is going to be used to limit the traffic
|
|
0:07:58
|
as it either is received in on the interface
|
|
0:08:01
|
or is sent out on the interface
|
|
0:08:04
|
So we will see the policing is bidirectional
|
|
0:08:07
|
where shaping and prioritization
|
|
0:08:10
|
are only outbound actions
|
|
0:08:14
|
so as I mentioned before, when we actually applied the policy map to the interface
|
|
0:08:18
|
there is not an explicit direction that we define
|
|
0:08:21
|
how the inspection or how the policy is going to be applied
|
|
0:08:25
|
depending on what particular action we choose here, whether we are inspecting or shaping or doing prioritization
|
|
0:08:31
|
thats ultimately going to control what the direction of traffic is
|
|
0:08:36
|
Now you don't necessarily need to memorize
|
|
0:08:39
|
which particular action correspond to which direction
|
|
0:08:42
|
because we will see in the documentation there is a need
|
|
0:08:45
|
less that specifically says if you take this action its going to be inbound or outbound, if you take this action
|
|
0:08:50
|
depending on whether the classes apply globally
|
|
0:08:53
|
or to the interface level
|
|
0:08:55
|
we can tell exactly what the direction of the
|
|
0:08:57
|
inspection is going to be or the direction of the QoS
|
|
0:09:02
|
and then again syntax wise
|
|
0:09:04
|
we can verify what are the default policies by looking at the
|
|
0:09:08
|
show run all policy map or show running config all policy map
|
|
0:09:15
|
Now for our tcp and udp connections settings
|
|
0:09:19
|
there is a number of different attributes that we can change thats going to control
|
|
0:09:23
|
how the behavior of an individual flow
|
|
0:09:25
|
is going to relate for possibly all destinations
|
|
0:09:29
|
or may be a sub set of destinations like I want a specific policy
|
|
0:09:33
|
that used to inspect traffic that is going to my web server
|
|
0:09:36
|
differently thats going to my mail server
|
|
0:09:39
|
or to my dns servers
|
|
0:09:42
|
So the first of these would be the total
|
|
0:09:44
|
maximum number of sessions that we can have
|
|
0:09:47
|
this would be the set connection, connection max option
|
|
0:09:51
|
that if we breach the total number of connections threshold
|
|
0:09:55
|
then new connections are going to be denied
|
|
0:09:57
|
until older connections leave the connection table
|
|
0:10:02
|
we could also control the maximum amount of sessions per host
|
|
0:10:06
|
which implicitly
|
|
0:10:08
|
is going to help prevent any type of syn attack
|
|
0:10:12
|
which is a denial service attack based on the tcp layer4 header
|
|
0:10:17
|
where we are not going to allow an individual client to open
|
|
0:10:20
|
all possible sessions on our web server or on our database server
|
|
0:10:25
|
and then starve the tcp stack
|
|
0:10:27
|
from being able to accept sessions from new legitimate clients
|
|
0:10:33
|
this would also be separately controlled by the maximum number of half open sessions
|
|
0:10:38
|
which are sometimes called the embryonic sessions
|
|
0:10:43
|
now what a half open session means
|
|
0:10:46
|
is that when the tcp client
|
|
0:10:50
|
sends the first initial
|
|
0:10:52
|
packet in the tcp three way handshake
|
|
0:10:56
|
from the client to the server, this is the syn packet
|
|
0:11:00
|
essentially the client is just saying to the server, I want to open a tcp session II here
|
|
0:11:05
|
Now if the server is configured to listen on this particular port
|
|
0:11:09
|
and to accept that session from the client
|
|
0:11:11
|
the server is going to reply back
|
|
0:11:13
|
with the syn
|
|
0:11:15
|
saying I also want to start a session
|
|
0:11:17
|
and the acknowledgement
|
|
0:11:19
|
saying that I received your initial packet to start
|
|
0:11:23
|
Now at this point
|
|
0:11:25
|
the connection is considered is half open or embryonic
|
|
0:11:29
|
because the client has not yet responded with the
|
|
0:11:32
|
third portion of the three way handshake
|
|
0:11:34
|
which is to acknowledge that the server is actually trying to
|
|
0:11:37
|
additionally open the session
|
|
0:11:41
|
so these two first steps here this is where the potential for the denial of service attack
|
|
0:11:46
|
the distributed denial of service attack in common with tcp
|
|
0:11:50
|
with the client could theoretically
|
|
0:11:52
|
just flood the server with tons of syn packets
|
|
0:11:56
|
but then never reply back with the third step
|
|
0:11:59
|
which is to completely open the session
|
|
0:12:04
|
so by default the asa is going to try to prevent against this type of attack
|
|
0:12:08
|
by limiting the number of maximum half open sessions as a total
|
|
0:12:14
|
and also the maximum of half open sessions on a per host basis
|
|
0:12:18
|
so we could set these options for client
|
|
0:12:20
|
for the embryonic connections maximum and
|
|
0:12:23
|
overall global
|
|
0:12:28
|
then lastly we could also control
|
|
0:12:30
|
whether the asa is going to do randomization of the initial
|
|
0:12:34
|
sequence numbers for tcp
|
|
0:12:37
|
which is on by default
|
|
0:12:41
|
Now the randomization of sequence numbers of tcp
|
|
0:12:44
|
is designed to prevent
|
|
0:12:46
|
a hijacking session
|
|
0:12:48
|
or basically a spoofing session of the tcp communication
|
|
0:12:52
|
where someone in the transit path between the client and the server
|
|
0:12:56
|
is able to guess what the
|
|
0:12:58
|
next sequence numbers or predict what the next sequence number is going to be
|
|
0:13:02
|
and then falsely insert
|
|
0:13:04
|
their own traffic into the tcp session
|
|
0:13:08
|
So what happens is that when we have the asa in the middle between the client and the server
|
|
0:13:13
|
when the client is sending this
|
|
0:13:15
|
first portion of the syn
|
|
0:13:18
|
its going to propose to the server
|
|
0:13:20
|
what the initial sequence number should be
|
|
0:13:24
|
where when the asa is doing its normalization in between them
|
|
0:13:28
|
the asa is actually going to intercept this
|
|
0:13:31
|
and change the sequence number
|
|
0:13:33
|
that the client is offering to the server
|
|
0:13:36
|
so we essentially end up with two
|
|
0:13:38
|
separate sessions, there is a session that goes from the
|
|
0:13:40
|
client to the asa
|
|
0:13:43
|
and a session that goes from the asa to the server
|
|
0:13:46
|
where essentially asa is running as a tcp
|
|
0:13:49
|
proxy
|
|
0:13:50
|
for the sequence numbers
|
|
0:13:53
|
so in this manner someone would be less likely to be able to do a sequence number prediction attack
|
|
0:13:59
|
because the
|
|
0:14:01
|
Now if they were to insert the sequence number
|
|
0:14:03
|
its going to be the wrong value as it goes from the
|
|
0:14:06
|
asa back to the client or from the asa to the server
|
|
0:14:12
|
now we will see that there are some particular applications
|
|
0:14:15
|
that have potential problems when we are using these advanced connection settings
|
|
0:14:21
|
one of them specifically will see
|
|
0:14:23
|
is that if we are trying to do md5 authentication
|
|
0:14:26
|
using the tcp header itself
|
|
0:14:30
|
which is used with the tcp option number 19 for the md5 signature
|
|
0:14:36
|
now there are certain control plane protocols in the network
|
|
0:14:40
|
like bgp
|
|
0:14:41
|
or the
|
|
0:14:43
|
Level Binding Protocol - LBP
|
|
0:14:45
|
Level Distribution Protocol for MPLS
|
|
0:14:48
|
that do not have their own built in authentication mechanisms
|
|
0:14:52
|
and since they are already riding on tcp as a transport
|
|
0:14:56
|
they are simply going to use the features that are built in to the tcp options
|
|
0:15:01
|
now what this means that these type of sessions are transcending through the asa
|
|
0:15:06
|
and going through this tcp normalization engine
|
|
0:15:09
|
their could be
|
|
0:15:11
|
essentially a
|
|
0:15:13
|
a miscalculation of what their sequence number is supposed to be
|
|
0:15:16
|
when the session gets from the client to the server
|
|
0:15:20
|
and part of the sequence number is used as a seed value or a salt value for the md5 hash
|
|
0:15:26
|
So we will see the final result of this
|
|
0:15:28
|
is that we have a host on the inside
|
|
0:15:31
|
throttling to a host on the outside
|
|
0:15:33
|
and they are trying to do tcp based md5 authentication
|
|
0:15:37
|
they are not going to agree on what the correct md5 hash value is
|
|
0:15:44
|
so in addition to this normalization setting that we can set
|
|
0:15:48
|
above the maximum number of sessions
|
|
0:15:50
|
or the prevention of the denial of service attack
|
|
0:15:53
|
there is also other advance settings
|
|
0:15:55
|
that are going to control the individual tcp specific session options
|
|
0:16:00
|
and this is going to be defined
|
|
0:16:02
|
by a tcp map
|
|
0:16:04
|
on the asa's command line
|
|
0:16:06
|
and specifically once we do our inspection
|
|
0:16:10
|
on to the policy map of the Modular Policy Framework
|
|
0:16:12
|
we are going to call the tcp map with the set connection advanced options command
|
|
0:16:18
|
So what this is typically allow us to do
|
|
0:16:22
|
is change how tcp is normally inspected
|
|
0:16:25
|
when we are dealing with any non standard
|
|
0:16:27
|
tcp options or ip options
|
|
0:16:30
|
So as I mentioned things like the level distribution protocol
|
|
0:16:32
|
or the Border Gateway Protocol authentication
|
|
0:16:37
|
since those are using tcp option number 19 for the md5 signature
|
|
0:16:42
|
that is not going to be allowed by default
|
|
0:16:45
|
Hey, additionally things like tcp sliding windows scaling
|
|
0:16:48
|
which is an optimization
|
|
0:16:51
|
of the slow start mechanism of tcp which is for
|
|
0:16:54
|
congestion management and congestion avoidance
|
|
0:16:58
|
and other miscellaneous options like the time stamping under the tcp header
|
|
0:17:03
|
So typically these type are options are not
|
|
0:17:06
|
allowed by default by the asa
|
|
0:17:09
|
because they are individual application specific attacks
|
|
0:17:12
|
that we could do with mal formed ip headers
|
|
0:17:15
|
or mal formed tcp headers
|
|
0:17:18
|
and a lot of times this is where you would see that your application server
|
|
0:17:22
|
like may be your microsoft IIS server or your patchy web server
|
|
0:17:26
|
would be vulnerable to things like buffer overflow attacks
|
|
0:17:30
|
when there is some sort of unpredictable
|
|
0:17:32
|
data in the tcp header
|
|
0:17:34
|
or some sort of mal formed header
|
|
0:17:36
|
that when the ip stack receives it
|
|
0:17:39
|
it takes some unpredictable action which typically is going to be the buffer overflow
|
|
0:17:44
|
so we will see that with the default options, the asa is trying to prevent against these types of attacks
|
|
0:17:50
|
by typically just removing
|
|
0:17:51
|
the ability to use these tcp options
|
|
0:17:55
|
when in the case that we are using it for a legitimate application
|
|
0:17:59
|
then we are going to need to change how the inspection engine for tcp is working
|
|
0:18:04
|
So this is going to under a tcp map
|
|
0:18:06
|
we are going to set specifically what are
|
|
0:18:08
|
the individual tcp options
|
|
0:18:13
|
Now just like in the IOS's Modular Quality of Service
|
|
0:18:17
|
the Modular Policy Framework is going to be
|
|
0:18:20
|
passes in a top down fashion
|
|
0:18:22
|
So similar to how an access list works or how a route map works
|
|
0:18:26
|
where we started the top of the list
|
|
0:18:28
|
and we work our way down to figure out what is the first class
|
|
0:18:32
|
that our particular traffic flow is going to match
|
|
0:18:36
|
So the end result that we will see
|
|
0:18:38
|
is that the order
|
|
0:18:40
|
that we actually reference the classes in
|
|
0:18:43
|
is going to be significant
|
|
0:18:44
|
if there are multiple possible matches between different classes
|
|
0:18:50
|
Now in the IOS's Modular Quality of Service
|
|
0:18:54
|
where in the case of a access list or a route map
|
|
0:18:56
|
once your first initial match occurs
|
|
0:19:00
|
the search breaks out of the route map or breaks out of the policy map
|
|
0:19:05
|
and say this is where the match occurs I am going to take the action based on whatever is defined there
|
|
0:19:11
|
but in the Modular Policy Framework of the asa it works a little bit differently
|
|
0:19:15
|
where we can find the flows can match multiple classes at the same time
|
|
0:19:21
|
Now an example of this would be that if we were trying to classify ftp traffic
|
|
0:19:25
|
and we have two separate classes in the policy
|
|
0:19:28
|
one that is doing a specific application of ftp
|
|
0:19:32
|
and one that is doing just a normal inspection of tcp
|
|
0:19:36
|
well technically ftp is going to be both
|
|
0:19:39
|
because it is using tcp as its layer4 transport
|
|
0:19:42
|
and then at the actual application layer its using ftp
|
|
0:19:46
|
for its file transfers
|
|
0:19:50
|
Now the reason this is significant to note
|
|
0:19:52
|
is that the different actions are going to be combined together
|
|
0:19:56
|
depending on whether they are applied at the interface level
|
|
0:20:00
|
or they are applied globally
|
|
0:20:03
|
and depending on which one actually matches first
|
|
0:20:07
|
Now what we will see is that if there are multiple matches
|
|
0:20:11
|
across different classes
|
|
0:20:13
|
the ones that overlap
|
|
0:20:15
|
we are going to choose whatever is the first match
|
|
0:20:19
|
however if they are not
|
|
0:20:20
|
overlapping matches, then we are going to combine the actions together
|
|
0:20:25
|
So for example if we had a class that was doing global inspection of tcp
|
|
0:20:30
|
and setting was the maximum number of
|
|
0:20:32
|
per.. connections per host
|
|
0:20:36
|
then we are doing a separate ftp inspection thats saying look at the actual ftp commands
|
|
0:20:40
|
like I don't want some one to be able to create a directory
|
|
0:20:43
|
or I don't want them to be able to delete files
|
|
0:20:46
|
in that case since the actions do not overlap
|
|
0:20:48
|
they would combine together
|
|
0:20:51
|
So ftp would be inspected based on whatever application level policy we are using
|
|
0:20:56
|
but then would also be using the
|
|
0:20:57
|
per client maximum number of connections
|
|
0:21:00
|
based on what the, the tcp inspection says
|
|
0:21:06
|
Now this can't get kind of complex when we look at order of operations
|
|
0:21:09
|
so we will see here in the documentation
|
|
0:21:12
|
there is a list that shows you exactly the order
|
|
0:21:15
|
that the inspections are going to be applied
|
|
0:21:19
|
So again this type of detail you don't necessarily need to memorize
|
|
0:21:23
|
you just need to know that if your classes do overlap
|
|
0:21:26
|
you could end up in an unpredictable inspection
|
|
0:21:29
|
if you didn't really know the order the classes were processed in
|
|
0:21:34
|
but in general
|
|
0:21:35
|
if there is an exact overlap of
|
|
0:21:37
|
actions between the classes
|
|
0:21:39
|
which ever one matches first
|
|
0:21:42
|
is going to be the one that takes precedence
|
|
0:21:45
|
so this is the reason that the order of matching is going make
|
|
0:21:47
|
a difference when you are actually creating the policy map
|
|
0:21:51
|
Now typically the way you are going to do this
|
|
0:21:54
|
is that your more specific matches
|
|
0:21:56
|
you would want to use towards the top of the policy map
|
|
0:22:01
|
So lets say for example that I am doing an inspection for
|
|
0:22:04
|
mail traffic
|
|
0:22:06
|
and ftp traffic
|
|
0:22:08
|
and DNS
|
|
0:22:10
|
So I have mail, may be the mail is going to be for
|
|
0:22:14
|
my smtp for my sendmail
|
|
0:22:17
|
but then there is also going be for pop3 and for imap for my get mail
|
|
0:22:23
|
then I have another class that is doing ftp inspection
|
|
0:22:26
|
and then a third one that is doing just tcp inspection
|
|
0:22:31
|
So if I were to specify that under the mail class
|
|
0:22:35
|
I wanted a number of maximum sessions
|
|
0:22:40
|
lets say I see the maximum number of sessions is 10
|
|
0:22:44
|
then onto the tcp class I also say that the max number of sessions
|
|
0:22:48
|
is 20
|
|
0:22:53
|
if I were then, to then call the classes in this particular order, if I say mail is first
|
|
0:22:57
|
ftp is next then tcp is last
|
|
0:23:01
|
it would mean for the send mail
|
|
0:23:03
|
I would get a maximum number of 10 connections
|
|
0:23:05
|
but for the get mail
|
|
0:23:07
|
the imap and the ftp
|
|
0:23:09
|
I would inherit the second match
|
|
0:23:17
|
so again typically the way you are going to solve this
|
|
0:23:19
|
is just like doing your most specific matches first
|
|
0:23:23
|
So this may mean that when you are editing the policy
|
|
0:23:26
|
you may need to remove some of the older inspections
|
|
0:23:28
|
in order to reorder
|
|
0:23:30
|
how the classes are being actually applied inside of the policy map
|
|
0:23:42
|
so here we have a specific example of this syntax wise
|
|
0:23:46
|
says we have an access list that is matching tcp
|
|
0:23:49
|
a class map that is calling that list
|
|
0:23:52
|
and a second class map that is calling tcp traffic that is matching port number 21 for ftp
|
|
0:23:59
|
then inside of our policy map
|
|
0:24:01
|
we are inspecting ftp
|
|
0:24:04
|
then specifically for that class
|
|
0:24:06
|
for ftp we are setting the maximum we are setting the maximum number of connections to 100
|
|
0:24:10
|
then the default tcp class is getting
|
|
0:24:13
|
connections of 200 and then an input policing rate
|
|
0:24:16
|
of a 150 kilo bits per second
|
|
0:24:20
|
So what the end result of this would be
|
|
0:24:23
|
is that the ftp class
|
|
0:24:25
|
would have a hundred maximum connections
|
|
0:24:28
|
but would also be policed inbound to 150k
|
|
0:24:33
|
if I did not want to police the ftp
|
|
0:24:37
|
I would need to put another police statement
|
|
0:24:40
|
that would essentially match whatever the line rate of the link is
|
|
0:24:43
|
so if its a fast ethernet I would need to police to 100 megs
|
|
0:24:46
|
If it was a gig ethernet, I would need to police it to 1000 megabits per second
|
|
0:24:53
|
but this can't be a little bit confusing because usually when you are working with the Modular Quality of Service on the Router
|
|
0:24:59
|
whatever the order that you enter in, is exactly the way its going to be processed
|
|
0:25:03
|
but in this case the policies are going to combine together
|
|
0:25:06
|
when ever they are not overlapping
|
|
0:25:12
|
Now also as I mentioned
|
|
0:25:14
|
we need to understand exactly what the direction of the policy is going to be
|
|
0:25:18
|
when we are applying it
|
|
0:25:20
|
and there is two different possible ways we can apply the policy
|
|
0:25:23
|
we can apply a global policy map
|
|
0:25:27
|
which will see is there by default, its going to be the global inspection policy
|
|
0:25:31
|
and this is going to apply to
|
|
0:25:33
|
inbound traffic or ingress traffic on the interfaces
|
|
0:25:38
|
Now since this global policy is already applying to all interfaces
|
|
0:25:43
|
it is inherently applying to all interfaces, all directions
|
|
0:25:49
|
so even though technically its doing any
|
|
0:25:50
|
ingress matching on the links
|
|
0:25:53
|
lets say that we have
|
|
0:25:56
|
the asa
|
|
0:25:57
|
that has an inside interface
|
|
0:26:00
|
an outside interface
|
|
0:26:02
|
and a DMZ
|
|
0:26:06
|
the global policy is going to be watching traffic as it comes
|
|
0:26:09
|
in on the inside
|
|
0:26:11
|
in on the outside
|
|
0:26:13
|
and in on the DMZ
|
|
0:26:17
|
Now if we look at the actual possible different flow directions
|
|
0:26:21
|
I know that I could have traffic that goes from the inside to out
|
|
0:26:24
|
the inside to the DMZ
|
|
0:26:27
|
outside to the DMZ
|
|
0:26:29
|
DMZ to outside and DMZ to inside
|
|
0:26:32
|
and outer in, there is six possible different directions of flows here
|
|
0:26:38
|
but the outside interface
|
|
0:26:41
|
inbound inspection
|
|
0:26:44
|
is automatically then going to match
|
|
0:26:47
|
out to in
|
|
0:26:48
|
and out to DMZ
|
|
0:26:51
|
where likewise the inbound in
|
|
0:26:54
|
is going to match into DMZ and in to out
|
|
0:26:59
|
so even though technically the global policy is applied as an
|
|
0:27:02
|
input policy
|
|
0:27:04
|
its automatically applied as
|
|
0:27:06
|
a egress filtering as well, egress inspection as well
|
|
0:27:09
|
because its essentially all interfaces in all directions
|
|
0:27:15
|
Now the other potential option we have is that we could apply the policy to the interface
|
|
0:27:20
|
and in this case its going to apply to both
|
|
0:27:22
|
inbound and outbound traffic
|
|
0:27:28
|
Now which action is actually going to be applied
|
|
0:27:30
|
is going to depend on
|
|
0:27:32
|
what particular inspection or what particular action that we are choosing
|
|
0:27:38
|
Now again since the classes can potentially overlap
|
|
0:27:42
|
an individual flow could match multiple policies
|
|
0:27:46
|
so if its overlapping between the global policy and the interface level policy
|
|
0:27:50
|
the interface level1 is going to precedence
|
|
0:27:54
|
for anything that is not matched in the interface policy
|
|
0:27:58
|
thats going to take whats in the global policy
|
|
0:28:00
|
or they could possibly be combined
|
|
0:28:05
|
So when you think of your overall inspection engine
|
|
0:28:08
|
you need to look at not only what are your interface level policies
|
|
0:28:12
|
or what is the global policy
|
|
0:28:14
|
what are the overlap between them
|
|
0:28:16
|
to figure out what is going to be the final
|
|
0:28:20
|
Now one thing that we will see when we actually look at this on the command line
|
|
0:28:24
|
is that there is a feature we can use, known as the packet tracer
|
|
0:28:28
|
and the packet tracer is going to tell us
|
|
0:28:31
|
if this were particular flow moving between interfaces
|
|
0:28:35
|
what exactly are the actions that are going to be applied
|
|
0:28:38
|
based on the inspection engine, based on our access list, based on Network Address Translation
|
|
0:28:44
|
its going to be a logical testing of the order of operation on the asa
|
|
0:28:48
|
what I could say
|
|
0:28:49
|
I want to do a test to figure out
|
|
0:28:51
|
whats going to happen when my host
|
|
0:28:53
|
A on the inside
|
|
0:28:55
|
sends a web browsing packet to host B thats on the outside
|
|
0:29:01
|
Now the asa is not actually going to generate the traffic
|
|
0:29:03
|
but its going to pretend to as if that this flow were going through
|
|
0:29:07
|
and this going to give you the step by step list of exactly
|
|
0:29:10
|
what the order
|
|
0:29:11
|
of the policies that are being applied
|
|
0:29:13
|
and then what is he final result
|
|
0:29:15
|
so is the result of the traffic is inspected
|
|
0:29:17
|
is the result of the traffic is dropped
|
|
0:29:19
|
is the result that it Network Address Translated
|
|
0:29:23
|
and thats going to depend on the particular features that we have implemented
|
|
0:29:28
|
so when you are trying to figure out whats the
|
|
0:29:30
|
final result of the policy
|
|
0:29:33
|
packet trace is going to be
|
|
0:29:34
|
a nice little tool that we can use on the command line to actually look at that final result
|
|
0:29:41
|
So next lets take a look at the documentation here
|
|
0:29:44
|
and I want to show the portion thats talking about
|
|
0:29:47
|
the order of operations
|
|
0:29:50
|
for the inspections and also the directions of inspections on the interfaces
|
|
0:29:57
|
So first lets go to the main
|
|
0:29:59
|
documentation page
|
|
0:30:03
|
and again to get to the asa documentation, this is going to be under products, security
|
|
0:30:09
|
firewall, appliance
|
|
0:30:12
|
asa 5500
|
|
0:30:15
|
then we want the configuration guides
|
|
0:30:19
|
and a particular release
|
|
0:30:22
|
in this case we are using release 8.0
|
|
0:30:27
|
So here under
|
|
0:30:29
|
getting started we have using the Modular Policy Framework
|
|
0:30:37
|
and we want the feature directionality
|
|
0:30:40
|
and the feature matching guideline within a policy map
|
|
0:30:44
|
Hey, we that we can see, also the order which the features are
|
|
0:30:47
|
match when when multiple actions are applied
|
|
0:30:49
|
So the feature directionality here
|
|
0:30:53
|
it says when you use a global policy, all features are unidirectional
|
|
0:30:57
|
features that are normally bidirectional
|
|
0:31:00
|
when applied to a single interface only applied to the ingress of each when applied globally
|
|
0:31:04
|
because the policies applied to all the interfaces, the policies applied in both directions
|
|
0:31:08
|
so bidirectional in this case is redundant
|
|
0:31:10
|
Hey this is basically what I was saying before
|
|
0:31:13
|
in this diagram that
|
|
0:31:16
|
here is really where the inspection is happening
|
|
0:31:20
|
but since the inspection is being
|
|
0:31:21
|
applied to all interfaces
|
|
0:31:23
|
its implicitly both ways
|
|
0:31:28
|
now for features that are unidirectional, say for example, Quality of Service
|
|
0:31:32
|
only traffic that exits the interface for which you have applied the policy is going to be affected
|
|
0:31:37
|
Hey, so when we look at the direction
|
|
0:31:40
|
of the flows
|
|
0:31:42
|
what are the key points
|
|
0:31:43
|
is going to be that the QoS features are applied differently
|
|
0:31:47
|
depending on which method that we are using
|
|
0:31:49
|
where policing
|
|
0:31:51
|
can be both on inbound
|
|
0:31:53
|
and on outbound action, so on ingress and egress
|
|
0:31:58
|
where the priority queuing or traffic shaping
|
|
0:32:02
|
those are only outbound
|
|
0:32:05
|
directions
|
|
0:32:06
|
So whether we are matching this in the global policy
|
|
0:32:09
|
or at the interface level policy
|
|
0:32:12
|
priority queueing and traffic shaping, those are always outbound
|
|
0:32:16
|
in the case of our application inspections
|
|
0:32:19
|
only type of modification on the tcp normalization
|
|
0:32:24
|
which again would be like the number of connections
|
|
0:32:27
|
what are the particular tcp options that we can use
|
|
0:32:29
|
the application inspection
|
|
0:32:32
|
and the normalization is going to be both directions
|
|
0:32:36
|
whether we are using the global
|
|
0:32:38
|
policy or we are using the interface level policy
|
|
0:32:43
|
where again even though technically it says, its only
|
|
0:32:45
|
ingress for the global policy
|
|
0:32:47
|
since its ingress on all links
|
|
0:32:50
|
its the same effect, has it been bidirectional
|
|
0:32:53
|
So what this then means
|
|
0:32:56
|
is that if I were to apply an inspection policy
|
|
0:33:03
|
on the DMZ interface
|
|
0:33:05
|
of asa2
|
|
0:33:08
|
this is going to effect
|
|
0:33:10
|
any one that is trying to hit the ACS server
|
|
0:33:14
|
or any traffic that the ACS server originates
|
|
0:33:18
|
so its going to be in both directions
|
|
0:33:21
|
Now if I wanted to apply in a inspection in one direction versus the other
|
|
0:33:25
|
thats where I can limit how the traffic is actually going to be classified
|
|
0:33:30
|
So lets say theoretically
|
|
0:33:32
|
I want a different parameter to be applied
|
|
0:33:35
|
as the ACS server sends traffic to the inside
|
|
0:33:41
|
versus its sending it to the outside
|
|
0:33:44
|
and then likewise from the inside to the ACS server and from outside of the ACS server
|
|
0:33:50
|
So the way we would have to do this
|
|
0:33:53
|
would be to classify not only on the particular traffic flow
|
|
0:33:56
|
but may be we want http port 80
|
|
0:34:00
|
but I could also call an access list
|
|
0:34:03
|
that is matching the source or destination pairs
|
|
0:34:06
|
so if I said access list
|
|
0:34:09
|
is DMZ
|
|
0:34:12
|
to out
|
|
0:34:14
|
this would be permitting
|
|
0:34:16
|
any ip traffic that came from 10.0.0.0/24
|
|
0:34:23
|
going to
|
|
0:34:26
|
basically anything
|
|
0:34:29
|
hey, anything, that would not be the other 10 network
|
|
0:34:33
|
where an access list
|
|
0:34:35
|
that will be matching the DMZ to in
|
|
0:34:38
|
I could say the source
|
|
0:34:40
|
is going to be 10.0.0.0/24
|
|
0:34:43
|
and then the destination
|
|
0:34:45
|
is going to be, may be anything else on the 10 network
|
|
0:34:48
|
So 10.0.0.0/8
|
|
0:34:52
|
so then this would mean
|
|
0:34:54
|
if I were to apply this policy
|
|
0:34:58
|
Hey, or specifically this class, to do the classification
|
|
0:35:01
|
if I were to match this one first in the policy
|
|
0:35:06
|
that would then apply to the DMZ in
|
|
0:35:10
|
then if I apply this second access list, which is saying
|
|
0:35:13
|
anything else thats coming from the 10 network
|
|
0:35:17
|
thats going to fall back on to any other traffic thats left over
|
|
0:35:22
|
so the logic can get kind of complicated because we are not applying the inspection
|
|
0:35:26
|
directly as a direction to the interface
|
|
0:35:29
|
we need to do this implicitly
|
|
0:35:32
|
based on either the particular action we are using
|
|
0:35:35
|
like QoS input policing
|
|
0:35:38
|
we would simply say police input or police output
|
|
0:35:42
|
but since things like application inspection are bidirectional
|
|
0:35:47
|
if we wanted to match an inbound flow versus an outbound flow
|
|
0:35:51
|
we are going to need to do that based on
|
|
0:35:53
|
the access list direction of the traffic flow
|
|
0:35:56
|
so whether the
|
|
0:35:58
|
hosts are in the center portion or whether they are in the destination portion
|
|
0:36:05
|
So additionally in this document, its going to talk about
|
|
0:36:07
|
what happens if multiple features are applied
|
|
0:36:11
|
so its the order in which different types of actions
|
|
0:36:15
|
are applied to perform independent of the order in which
|
|
0:36:18
|
they appear in the policy map
|
|
0:36:22
|
hey, so this is important here because it saying now it does matter
|
|
0:36:25
|
the order that you are applying in the policy map
|
|
0:36:30
|
but it depends on the individual features, so if we do input policing
|
|
0:36:34
|
this always going to happen before normalization
|
|
0:36:37
|
or randomization of the sequence numbers
|
|
0:36:40
|
says then after you do the policing after you do the normalization
|
|
0:36:44
|
then you are going to do the application inspection
|
|
0:36:47
|
then if for some reason
|
|
0:36:49
|
your application inspection actually overlap
|
|
0:36:53
|
there is a specific order that they are going to be processed in
|
|
0:36:58
|
Now most of this is really not going to matter because
|
|
0:37:01
|
we know from a protocol header point of view
|
|
0:37:04
|
there is obviously a difference between a ftp packet
|
|
0:37:07
|
and an http packet
|
|
0:37:09
|
what cannot be both at the same time
|
|
0:37:12
|
the same would be true of a SIP phone call or a skinny phone call
|
|
0:37:16
|
so if its voice over ip calls, there is not going to be a ftp transfer
|
|
0:37:20
|
but if you do run into the our case where the classes do overlap like this
|
|
0:37:25
|
and then you could use the documentation to figure out exactly what the order is
|
|
0:37:31
|
so again this would definitely be something that would not want to memorize
|
|
0:37:35
|
you just want to know where this is located in the documentation in case you need to reference it
|
|
0:37:42
|
Now the next thing we have after you apply
|
|
0:37:45
|
the matches under the traffic is thats based on the class map
|
|
0:37:49
|
which again will be used to classify traffic based on things like an access list
|
|
0:37:53
|
based on the tcp port
|
|
0:37:55
|
based on the layer3
|
|
0:37:57
|
dhcp or ip precedence markings
|
|
0:38:01
|
then we have specific application level class maps
|
|
0:38:04
|
which are called the class map type inspect
|
|
0:38:07
|
that is going to used for one individual application layer gateway or application inspection engine versus the others
|
|
0:38:15
|
So essentially this is going an extension of the class map syntax
|
|
0:38:19
|
where we say class map type inspect
|
|
0:38:22
|
and then specify what is the individual application that we are trying to use
|
|
0:38:27
|
so an inspection for DNS
|
|
0:38:29
|
is going to be different for an inspection for http
|
|
0:38:33
|
where dns may say look at the response
|
|
0:38:36
|
and I want to make sure you url link
|
|
0:38:39
|
is less than a certain value
|
|
0:38:42
|
or look at the http methods
|
|
0:38:44
|
and make sure that someone is not trying to do an http post that they are trying to upload files through a web interface
|
|
0:38:51
|
So this is where we are matching the application specific command structure
|
|
0:38:56
|
like http post
|
|
0:38:57
|
ftp passive, ftp active
|
|
0:39:02
|
to really understand this we would have to know the exact syntax
|
|
0:39:05
|
for that individual application
|
|
0:39:08
|
so generally here is when you are going to extensively rely on the documentation
|
|
0:39:13
|
because I don't know about you guys but personally I am not an expert in the
|
|
0:39:17
|
programming logic of ftp
|
|
0:39:19
|
or the instant messenger
|
|
0:39:21
|
syntax of AOL versus the yahoo's syntax
|
|
0:39:25
|
so generally if you try to make a change here
|
|
0:39:28
|
you would want to look at the defaults
|
|
0:39:30
|
like look at the show run all class map show run all policy map
|
|
0:39:33
|
look at what the default inspections are
|
|
0:39:35
|
and you should be able to kind of fumble your way to how to put the syntax together
|
|
0:39:40
|
so specifically in this case when we get to our command line examples
|
|
0:39:43
|
I will show a couple of cases where
|
|
0:39:46
|
we could look into
|
|
0:39:47
|
http like to figure out whats the domain name they are trying to reach
|
|
0:39:51
|
or whats the particular url they are trying to reach
|
|
0:39:54
|
and then based on that we can configure the MPF to take certain types of actions
|
|
0:39:59
|
so do we want to log the traffic, do we want to drop the session, do we want to reset it
|
|
0:40:03
|
depending on what particular application we are using
|
|
0:40:06
|
that going to control
|
|
0:40:07
|
what type of different actions that we can actually take
|
|
0:40:13
|
Now once we classify
|
|
0:40:15
|
what is the specific application level match
|
|
0:40:19
|
then we are going to use an extension of the
|
|
0:40:20
|
policy map syntax which is the policy map type inspect
|
|
0:40:26
|
Now the key here is the application inspection in policy map
|
|
0:40:31
|
has to be used with the application inspection inside the class map
|
|
0:40:36
|
so sometimes the syntax can get confusing
|
|
0:40:39
|
because if I try to call
|
|
0:40:40
|
a class map type inspect
|
|
0:40:43
|
from a regular policy map
|
|
0:40:46
|
or I try to call a
|
|
0:40:49
|
regular class map from a policy map type inspect then its going to tell us those are incompatible
|
|
0:40:55
|
so a regular class map is always called from a regular policy map
|
|
0:40:58
|
a class map type inspect is always called from a policy map type inspect
|
|
0:41:03
|
then we are going to use the policy map
|
|
0:41:05
|
inside the
|
|
0:41:07
|
normal, I should say we are going to use the policy map type inspect
|
|
0:41:11
|
inside the normal policy map
|
|
0:41:14
|
to specify how the classic traffic is actually inspected
|
|
0:41:19
|
so we will see the syntax logic, its kind of complex
|
|
0:41:23
|
and this is where again you heavily want to rely on the defaults that are in the command line
|
|
0:41:28
|
or in the documentation
|
|
0:41:32
|
now another one of the potential issues here
|
|
0:41:35
|
is that one were doing this application level matches
|
|
0:41:38
|
a lot of the times we need to match arbitrary strings of text
|
|
0:41:41
|
or application level signatures
|
|
0:41:44
|
that we may not know how do we match the different mime types of http or the different application types of http
|
|
0:41:52
|
so things like the url, the different file names
|
|
0:41:56
|
the way this is going to be matched is by a regular expression or a regex
|
|
0:42:02
|
Now the regex syntax is going to be the same that IOS uses
|
|
0:42:06
|
its the standard unix new
|
|
0:42:09
|
regular expression syntax
|
|
0:42:11
|
but unless you are really an expert at scripting and programming logic
|
|
0:42:14
|
a lot of this can be very complicated
|
|
0:42:17
|
so when we do the regular expression matching
|
|
0:42:20
|
again we generally going to really a lot on
|
|
0:42:23
|
the defaults that are already in the command line
|
|
0:42:25
|
or the examples that we are using on the documentation
|
|
0:42:31
|
so again the regex matching itself
|
|
0:42:34
|
is going to use the standard
|
|
0:42:36
|
unix based syntax for regular expression
|
|
0:42:38
|
so where we define this with a regex, give it a name
|
|
0:42:42
|
specify what are the actual characters that we are trying to match
|
|
0:42:48
|
to see the defaults that the command line already has, we are going to look at the show run all regex
|
|
0:42:53
|
So its similar to what I was showing before like the msn messenger
|
|
0:42:57
|
signatures or the AOL instant messenger signatures
|
|
0:43:01
|
whose are going to use the regular expressions
|
|
0:43:03
|
if you got whats the actual application level signature
|
|
0:43:08
|
Now once we create the regular expression
|
|
0:43:11
|
there is two ways that we can apply it
|
|
0:43:13
|
directly under a class map
|
|
0:43:16
|
directly under a policy map
|
|
0:43:18
|
or we can group them together
|
|
0:43:20
|
in a specific regular expression class
|
|
0:43:25
|
Now the reason that you would want to do the ladder with the regular expression class
|
|
0:43:29
|
is to make your changes
|
|
0:43:31
|
more Modular at the end
|
|
0:43:34
|
so we will look at some cases where we could use the regular expression directly under the class map or policy map
|
|
0:43:39
|
or when we want to group it under class map type regex
|
|
0:43:43
|
So its going to make it more extensive if we want it
|
|
0:43:45
|
add new signatures on to the inspection
|
|
0:43:51
|
Now as a reference for this, as I mentioned this does use the same syntax as IOS does
|
|
0:43:56
|
So if you are familiar with regexes like for BGP
|
|
0:43:59
|
AS path information
|
|
0:44:01
|
or possibly for like modem chat scripts
|
|
0:44:04
|
then its going to be the same syntax
|
|
0:44:07
|
Now there are examples in the ASA configuration guide
|
|
0:44:11
|
which is if you go to the configuration guide
|
|
0:44:13
|
under configuring the firewall
|
|
0:44:15
|
using the Modular Policy Framework and then creating a regular expression
|
|
0:44:20
|
so this is the same documentation we were looking at before
|
|
0:44:23
|
if we go
|
|
0:44:25
|
up to the top here using the Modular Policy Framework
|
|
0:44:29
|
then if we search for
|
|
0:44:32
|
regex
|
|
0:44:38
|
we could see a couple of different
|
|
0:44:40
|
examples here that are saying
|
|
0:44:42
|
regex url_example
|
|
0:44:45
|
is example/.com
|
|
0:44:50
|
where the / [slash] is our escape sequence
|
|
0:44:53
|
So it means its matching literal character . [dot ]
|
|
0:44:57
|
because normally a . [dot] is going to be any single character
|
|
0:45:01
|
but what we mostly want to look for here
|
|
0:45:03
|
is there is a table
|
|
0:45:06
|
under here creating a regular expression
|
|
0:45:08
|
this table shows us, what are the different characters used for
|
|
0:45:13
|
so where a dot
|
|
0:45:15
|
again is going to be any single character
|
|
0:45:19
|
so it says if you say d.g it matches dog dag dtg
|
|
0:45:24
|
so basically any character between the d and the g
|
|
0:45:28
|
if we use () [parenthesis]
|
|
0:45:32
|
this is going to be like a mathematical grouping
|
|
0:45:35
|
where they are saying d(o|a)
|
|
0:45:42
|
this would mean d
|
|
0:45:44
|
o or a g
|
|
0:45:48
|
so the | here, this is for a logical or
|
|
0:45:52
|
question mark is going to be
|
|
0:45:53
|
0 or 1 instances of the character
|
|
0:45:56
|
So may that character is there, may its not there
|
|
0:45:59
|
* [asterisk] is going to be 0 or more instances
|
|
0:46:03
|
so essentially question mark is true or false
|
|
0:46:06
|
asterisk is 0 or more
|
|
0:46:10
|
plus is going to be 1 or more
|
|
0:46:13
|
So the character must be there
|
|
0:46:15
|
but it could be there more that one time
|
|
0:46:19
|
and then the
|
|
0:46:22
|
the brackets here, this is going to be for a logical or as well
|
|
0:46:27
|
so normally when you use the pipe, if you say
|
|
0:46:29
|
a|b that will be a or b
|
|
0:46:32
|
but here they are saying [abc]
|
|
0:46:35
|
its saying a or b or c
|
|
0:46:38
|
then you could negate this with a character
|
|
0:46:43
|
so you should get to match in the syntax where this can get really really complicated
|
|
0:46:47
|
to the point when there is actually full books that are just on regular expressions
|
|
0:46:52
|
so if you look at the
|
|
0:46:55
|
safari online website
|
|
0:46:59
|
I want to see safari.
|
|
0:47:03
|
write it dot com, so safaribooksonline.com
|
|
0:47:11
|
if you really want to get into the detail for this
|
|
0:47:15
|
there is
|
|
0:47:17
|
a couple of different
|
|
0:47:18
|
books that are specifically on this
|
|
0:47:21
|
so regular expressions cookbook
|
|
0:47:23
|
and then this one is what, mastering regular expressions
|
|
0:47:27
|
so for some of these the
|
|
0:47:32
|
the syntax is little bit different, I think one of them uses like a pearl engine
|
|
0:47:36
|
which may be a little bit different than the unix engine
|
|
0:47:41
|
but if you just do some searching on google, you will be able to find a bunch of references for this
|
|
0:47:47
|
so for like within the scope of the CCIE security exam
|
|
0:47:50
|
you don't have to an expert in this type of stuff
|
|
0:47:52
|
hey, we are mainly going to rely on the documentation
|
|
0:47:55
|
or the examples that are already built into the command line
|
|
0:47:59
|
but if you are using this in production
|
|
0:48:01
|
and there is something very specific that you need to match in an application flow
|
|
0:48:05
|
then you really going to need to understand how can use the regular expressions to actually accomplish this
|
|
0:48:13
|
Now once we get to the point that we
|
|
0:48:15
|
have our application level class defined
|
|
0:48:19
|
which again is going to be the class map type inspect
|
|
0:48:21
|
this is where we need to apply
|
|
0:48:24
|
the, next step I should say, would be, where we actually apply the policy to that type of traffic
|
|
0:48:30
|
so this going to match sub set of traffic
|
|
0:48:33
|
depending on the individual parameters that we specify
|
|
0:48:37
|
so for example we could say
|
|
0:48:39
|
in an http header
|
|
0:48:41
|
match the get method
|
|
0:48:43
|
where get is going to be when you are download a webpage
|
|
0:48:47
|
then inside of this we could say
|
|
0:48:49
|
match that particular method
|
|
0:48:51
|
then I also wanted to
|
|
0:48:53
|
other additional matches, so may be its
|
|
0:48:55
|
combined with a layer3 map that says not only is it http get
|
|
0:49:01
|
but it has to be from this particular server
|
|
0:49:04
|
Now only an individual single application match is going to be supported
|
|
0:49:09
|
but the normal layer3 layer4 matches
|
|
0:49:12
|
can be multiples inside the policy
|
|
0:49:15
|
so we can get really really granular, not only is it this exact signature inside the http header
|
|
0:49:21
|
but it has to be from this host going to this destination
|
|
0:49:27
|
okay the other way we could apply this
|
|
0:49:29
|
is by calling a specific class map
|
|
0:49:33
|
so the class map we would have to predefine it
|
|
0:49:36
|
we would say match that particular class and then we can apply the action
|
|
0:49:40
|
this second one is going to make it a little bit modular
|
|
0:49:43
|
but really it depends on what we are trying to accomplish
|
|
0:49:46
|
so in the end there are lots of different ways that we could apply the application inspection
|
|
0:49:52
|
just depends on how granular and how modular you want to be with your syntax basically
|
|
0:49:59
|
Here we could also set the global parameters
|
|
0:50:02
|
for the inspection NAT, we will take a look at some examples of this
|
|
0:50:06
|
and then finally when you are going to apply it
|
|
0:50:08
|
under the normal policy map
|
|
0:50:10
|
where we say inspect the particular protocol
|
|
0:50:13
|
with the application level policy map
|
|
0:50:18
|
so again when you look at the documentation for this, it can be kind of confusing
|
|
0:50:22
|
until you look at a final syntax example
|
|
0:50:26
|
and then you will see exactly
|
|
0:50:28
|
how this is going to be tied together
|
|
0:50:37
|
So here we have an example of
|
|
0:50:39
|
a final advanced application inspection
|
|
0:50:43
|
where what this is saying
|
|
0:50:45
|
is that I have a regular expression that says look for
|
|
0:50:49
|
the string that is
|
|
0:50:54
|
has a / [slash] and a . [dot]
|
|
0:50:57
|
so the slash is the escape sequence again
|
|
0:51:00
|
so it means match the actual literal care to dot
|
|
0:51:03
|
its a lower case e or a upper case e
|
|
0:51:06
|
a lower case x or upper case x
|
|
0:51:08
|
lower case or upper case e
|
|
0:51:10
|
then we are calling this from
|
|
0:51:12
|
a class type inspect
|
|
0:51:16
|
that says look for
|
|
0:51:18
|
a web session thats doing the get method or its trying to download a file or download a webpage
|
|
0:51:25
|
but also it has to be matching this regular expression
|
|
0:51:30
|
so essentially its looking for someone
|
|
0:51:32
|
to be clicking on an exe file through the web browser
|
|
0:51:36
|
so if it matches the regular expression
|
|
0:51:39
|
and it is the get method
|
|
0:51:41
|
and it is port 80
|
|
0:51:44
|
then we are going to reset the session
|
|
0:51:48
|
so essentially example would stop someone from being able to download an exe web file from their web browser
|
|
0:51:55
|
but we could see how this is tied together
|
|
0:51:57
|
that the normal policy map outside in
|
|
0:52:01
|
is calling the normal class http traffic
|
|
0:52:06
|
in the normal class we are saying inspect http
|
|
0:52:10
|
but then use the inspection policy thats called the http
|
|
0:52:14
|
which in turn is calling the inspection class
|
|
0:52:17
|
which then classifying the application level match
|
|
0:52:20
|
So its actually like four layers deep that we need to do
|
|
0:52:23
|
in order to get this actual application inspection to apply
|
