|
0:00:13
|
In our next section we are going to talk about the zone based policy firewall performance tuning
|
|
0:00:18
|
that similar to CBAC is used to control
|
|
0:00:21
|
the individual parameters of the TCP, UDP and ICMP sessions
|
|
0:00:26
|
and control options
|
|
0:00:27
|
like the prevention of TCP denial of service attacks
|
|
0:00:32
|
Now just like CBAC zone based policy firewall support the tuning
|
|
0:00:36
|
of the individual TCP session options
|
|
0:00:38
|
things like what are the limits on the incomplete sessions
|
|
0:00:42
|
which again are also known as the half open sessions or what the ASA call the embrionic sessions
|
|
0:00:49
|
this would be used to prevent any type of TCP syn attack
|
|
0:00:52
|
what are the attackers send the first portion of TCP
|
|
0:00:55
|
three way handshake to the server, the server replies with the syn and the ack
|
|
0:01:00
|
and the attacker doesn't fully open the session
|
|
0:01:03
|
by replying back with the final acknowledgement
|
|
0:01:07
|
additionally we can control the syn parameters like how long is the firewall is going to wait
|
|
0:01:12
|
once I receive the initial portion of the three way handshake
|
|
0:01:16
|
for the server to actually reply
|
|
0:01:19
|
the FIN timers which would control how long do we manage a session after its complete
|
|
0:01:24
|
and different idle timers and miscellaneous parameters of the individual TCP sessions
|
|
0:01:30
|
Now for UDP and ICMP sessions, since these are not connection oriented
|
|
0:01:35
|
will see that there is many fewer options that we can control
|
|
0:01:39
|
mainly UDP and ICMP sessions are just going to be controlled by the idle timer
|
|
0:01:44
|
So once I hear an ICMP echo
|
|
0:01:47
|
how long am I going to wait for that ICMP echo reply to come back in
|
|
0:01:51
|
before the connection is removed from the state table
|
|
0:01:55
|
Now differently from the content based access control
|
|
0:01:58
|
where these parameters were directly defined with the IP inspect command
|
|
0:02:02
|
in the zone based policy firewall, these are going to be defined with a parameter map
|
|
0:02:09
|
Now the parameter map is going to define the TCP intercept settings
|
|
0:02:13
|
and other generic content based access control settings
|
|
0:02:16
|
because remember, even though the Zone Based Policy firewall is a different syntax interface
|
|
0:02:22
|
for the firewall feature set
|
|
0:02:24
|
its still using the same CBAC inspection behind the scenes
|
|
0:02:29
|
So in order to change these type of parameters
|
|
0:02:32
|
we are going to define a parameter map
|
|
0:02:35
|
that likely previous class maps and policy maps that we saw are going to be of type inspect
|
|
0:02:40
|
and this is where we would change options like what are the maximum tcp incomplete sessions
|
|
0:02:45
|
whats the SYN wait time, whats the tcp FIN wait time, etc
|
|
0:02:51
|
we also have an option here to turn on alerting
|
|
0:02:54
|
which is going to generate log messages, based on the parameters that we defined
|
|
0:02:58
|
and the auto trail
|
|
0:03:00
|
that is going to show us a verbose log
|
|
0:03:03
|
of the actual TCP connection that is occurring from the client to the server
|
|
0:03:09
|
now once we actually defined the parameter map
|
|
0:03:12
|
its going to be applied on the inspect action
|
|
0:03:15
|
inside the class, inside of the policy map
|
|
0:03:19
|
So recall the first thing that we are going to do with the Zone Based Policy Firewall
|
|
0:03:23
|
is to classify the traffic with the class map type inspect
|
|
0:03:27
|
this is where we would say, match protocol http, match protocol ICMP etc
|
|
0:03:33
|
Once we define the class
|
|
0:03:35
|
then we are going to define our policy map type inspect
|
|
0:03:39
|
inside the policy we are going to reference the class
|
|
0:03:43
|
then we are going to choose our action, so are we going to inspect the traffic, are we going to drop it, are we going to pass it
|
|
0:03:49
|
in this case for the parameter modifications
|
|
0:03:52
|
We are going to use the inspect command
|
|
0:03:54
|
followed by the particular parameter maps name
|
|
0:04:00
|
Now in the current topology that I am using
|
|
0:04:03
|
router3 is again is going to be running the zone based policy firewall
|
|
0:04:07
|
where the connection to the frame relay network is the outside
|
|
0:04:12
|
and the inside LAN interface connecting to router4
|
|
0:04:15
|
is going to be the inside
|
|
0:04:19
|
So we are going to look at modifying the parameters as traffic goes from the inside to the outside and then returns
|
|
0:04:26
|
and is traffic tries to move from the outside to the inside
|
|
0:04:32
|
Now for the next few examples the way that we are going to do this
|
|
0:04:35
|
is to configure router4 as a web server
|
|
0:04:39
|
and its also going to configured as a DNS server
|
|
0:04:44
|
So for devices on the outside of the network
|
|
0:04:46
|
router1 for example, the test PC
|
|
0:04:50
|
when there is sessions coming in
|
|
0:04:52
|
are coming in from the outside, going inside
|
|
0:04:54
|
we are going to allow the web traffic
|
|
0:04:57
|
we are going to allow the DNS traffic
|
|
0:04:59
|
and then for some basic verification, I have it configure to allow
|
|
0:05:02
|
ICMP traffic
|
|
0:05:06
|
So next lets look at the currently
|
|
0:05:07
|
the configured policy on router3
|
|
0:05:11
|
again for verification of the zone based policy firewall we will look at things like the show
|
|
0:05:17
|
zone security
|
|
0:05:19
|
says I have three zones, one of them is inside, one of them is outside
|
|
0:05:24
|
where again these are my user defined zones
|
|
0:05:26
|
then we have the self zone
|
|
0:05:28
|
that is going to control the traffic that is going to or coming from
|
|
0:05:32
|
the router itself
|
|
0:05:34
|
So things like OSPF hellos or EIGRP hellos
|
|
0:05:39
|
specifically these zones are applied inside is on the
|
|
0:05:43
|
fastethernet0/1
|
|
0:05:44
|
and outside is on the frame relay sub interface, the WAN interface
|
|
0:05:49
|
if we look at the show zone pair
|
|
0:05:53
|
security, I have two different pairings
|
|
0:05:56
|
one is for traffic as it goes from the inside to the outside
|
|
0:06:02
|
that is saying traffic is coming from the source zone, going to the destination zone outside
|
|
0:06:06
|
and I have the applied, the inside to outside policy
|
|
0:06:11
|
then likewise you have the way around, I have outside to inside pairing thats calling the outside to inside policy
|
|
0:06:18
|
so again as you are defining these parameters
|
|
0:06:21
|
the descriptive you can be in the class names
|
|
0:06:25
|
policy names, the zone pairings, the actual zones
|
|
0:06:29
|
the easier is going to be to read the final configuration
|
|
0:06:34
|
Now for the inside to outside pairing
|
|
0:06:37
|
if we look at the show zone pair security
|
|
0:06:41
|
or show zone pair
|
|
0:06:44
|
not zone pair, lets say show policy map
|
|
0:06:47
|
show policy map type inspect
|
|
0:06:50
|
and I want this for the zone pairing
|
|
0:06:53
|
that is the inside to outside pairing
|
|
0:06:58
|
so the inside to outside pairing is a pretty straight forward policy that says I have a class
|
|
0:07:03
|
that is the inside to outside class
|
|
0:07:05
|
that is matching TCP, UDP and ICMP
|
|
0:07:10
|
says for any of these types of flows
|
|
0:07:12
|
I am simply going to inspect the traffic
|
|
0:07:15
|
So we are essentially allowing everything
|
|
0:07:18
|
from the inside out that CBAC has an inspection for
|
|
0:07:23
|
now on the reverse direction, if we look at the
|
|
0:07:27
|
outside
|
|
0:07:30
|
to inside pairing
|
|
0:07:39
|
which is
|
|
0:07:42
|
actually its not called pairing, this is called outside to inside
|
|
0:07:47
|
Hey, so the outside to inside policy
|
|
0:07:50
|
is calling a couple of different classes
|
|
0:07:52
|
one of them is http servers class
|
|
0:07:56
|
that says I am matching two different things and I have to match all of them
|
|
0:08:00
|
in order for the policy to be true
|
|
0:08:04
|
which says not only is the traffic going to be http
|
|
0:08:07
|
So its that specific protocol
|
|
0:08:09
|
but its also calling this access list
|
|
0:08:12
|
So now we are limiting
|
|
0:08:14
|
the type of traffic that is allowed to be inspected
|
|
0:08:17
|
from the outside to inside
|
|
0:08:19
|
to the application
|
|
0:08:20
|
which is http
|
|
0:08:22
|
but also for the particular server
|
|
0:08:25
|
So this is how you would limit traffic that is going to your inside host
|
|
0:08:29
|
not only on a per address basis but also on a per protocol basis
|
|
0:08:34
|
then likewise we are doing the same thing here for the DNS servers
|
|
0:08:39
|
I am saying that I am allowing the protocol DNS
|
|
0:08:42
|
but only if its going to
|
|
0:08:44
|
servers that are matching that particular access list
|
|
0:08:47
|
then the last one I am permitting any ICMP
|
|
0:08:50
|
this going to be for basic testing of the policy
|
|
0:08:55
|
Now if we look at the result of this, if we were to go to the inside of the network
|
|
0:09:01
|
which in this case is router4
|
|
0:09:03
|
if I were to send an ICMP ping
|
|
0:09:05
|
or if I were to send a telnet
|
|
0:09:08
|
for testing our TCP traffic, we should see
|
|
0:09:12
|
that there is not going to be any problem for router4
|
|
0:09:15
|
pinging lets say 200.0.0.1
|
|
0:09:19
|
which is router1 or if we were to
|
|
0:09:22
|
to telnet to router1
|
|
0:09:26
|
and on router3, if we look at the show
|
|
0:09:29
|
policy map type inspect
|
|
0:09:32
|
zone pair sessions
|
|
0:09:34
|
So the active sessions in this state table
|
|
0:09:36
|
we do see that
|
|
0:09:38
|
there is a session that was initiated
|
|
0:09:40
|
from router4
|
|
0:09:42
|
going to 1
|
|
0:09:44
|
and its port 23, so this is our telnet traffic
|
|
0:09:49
|
So now we know the basic inside to outside policy is working
|
|
0:09:52
|
Now lets look at this in the reverse direction
|
|
0:09:55
|
if we look at the show
|
|
0:09:56
|
access list on router3
|
|
0:09:59
|
I have two different lists
|
|
0:10:01
|
one is specifying the DNS servers, one is specifying the HTTP servers
|
|
0:10:06
|
in this case we have the same address which is
|
|
0:10:09
|
an interface that is assigned to router4
|
|
0:10:13
|
So on router4, I am going to make two changes
|
|
0:10:16
|
one is to turn
|
|
0:10:18
|
the web servers on
|
|
0:10:20
|
So on global config, we will say ip http server
|
|
0:10:24
|
and the other is to turn the DNS servers on, say ip DNS server
|
|
0:10:30
|
now for the web service
|
|
0:10:32
|
any who now
|
|
0:10:33
|
starts a web browsing session to router4, should get to the GUI interface for management
|
|
0:10:39
|
for the DNS server
|
|
0:10:41
|
I am now going to put some static host entries in here
|
|
0:10:44
|
So that we can actually test, is the DNS resolution actually working
|
|
0:10:48
|
So I will say here
|
|
0:10:50
|
ip host
|
|
0:10:52
|
lets say www.abc.com
|
|
0:10:55
|
is
|
|
0:10:56
|
an interface that is on router4, lets say 172.16.34.4
|
|
0:11:02
|
and the same with
|
|
0:11:06
|
with xyz.com
|
|
0:11:10
|
now from router4, if I were to ping any of these addresses
|
|
0:11:14
|
ping abc.com
|
|
0:11:16
|
or ping www.xyz.com
|
|
0:11:22
|
we can see that the resolution is occurring
|
|
0:11:25
|
that it knows that this address resolve to that host name
|
|
0:11:31
|
next on the outside portion of the network
|
|
0:11:35
|
which were going to use the test PC for this
|
|
0:11:38
|
I have it configured
|
|
0:11:40
|
to use router4's address as the DNS server
|
|
0:11:44
|
So if we look at the windows command line
|
|
0:11:47
|
and the look at the ipconfig /all
|
|
0:11:52
|
we could see that the, of the DNS server here is configured as router4's address
|
|
0:11:58
|
Now assuming that the DNS process is configured correctly on router
|
|
0:12:03
|
which we did already verified
|
|
0:12:05
|
and that the outside to inside policy
|
|
0:12:08
|
is working on router3
|
|
0:12:11
|
I should be able to ping
|
|
0:12:12
|
abc.com
|
|
0:12:15
|
or xyz.com
|
|
0:12:18
|
and get those particular resolutions
|
|
0:12:20
|
which we see that we do
|
|
0:12:23
|
Now if I were to choose any other random address lets say efg
|
|
0:12:27
|
router4 is not configured with this host entry
|
|
0:12:30
|
So the DNS resolution is going to fail
|
|
0:12:34
|
but atleast upto this point it is telling us that our outside to inside policy is working
|
|
0:12:39
|
its allowing the DNS resolution
|
|
0:12:42
|
but its also allowing the ICMP pings
|
|
0:12:46
|
So next lets look at the web browsing sessions
|
|
0:12:50
|
lets connect to router4, we will say
|
|
0:12:52
|
172.16.34.4
|
|
0:12:59
|
and I will also open another connection
|
|
0:13:03
|
to 172.16.4.4
|
|
0:13:09
|
Now notice that the 4.4 session is working
|
|
0:13:13
|
but the 34.4 session is not
|
|
0:13:18
|
and the reason why
|
|
0:13:20
|
is that in the outside to inside policy
|
|
0:13:24
|
when I am matching the http server class
|
|
0:13:27
|
I am calling not only the protocol which is http
|
|
0:13:30
|
but I am also pulling an access list that says it has to be specifically to this address
|
|
0:13:35
|
not to any other address
|
|
0:13:39
|
So this is now telling that two additional things are working
|
|
0:13:42
|
not only is the outside to inside http inspection working
|
|
0:13:46
|
but it is also limiting the traffic based on the address
|
|
0:13:50
|
Now if I add an additional server that was added on the inside
|
|
0:13:53
|
the only thing I would need to do
|
|
0:13:55
|
would be to go to router3
|
|
0:13:58
|
and when we look at the access list
|
|
0:14:01
|
if I were to add an additional entry here
|
|
0:14:04
|
then that particular servers, traffic would be allowed inbound, as well
|
|
0:14:11
|
Now we can additionally see that router3 is logging traffic
|
|
0:14:14
|
it says that from the outside to the inside
|
|
0:14:19
|
we dropped a web session
|
|
0:14:21
|
that was coming from, this is the windows machine host's address
|
|
0:14:25
|
going to 34.4
|
|
0:14:28
|
because the drop action was found in the policy map
|
|
0:14:32
|
where the drop action here, this is in the
|
|
0:14:34
|
class default
|
|
0:14:40
|
so at this point, all of the inspection that router3 or 2 is doing
|
|
0:14:44
|
is based on all of the default parameters
|
|
0:14:47
|
Now we wanted to modify any of these
|
|
0:14:50
|
to say what are the number of connections that we can have to this particular web server
|
|
0:14:54
|
or what are the time outs, what are the maximum incomplete sessions
|
|
0:14:59
|
to prevent those TCP syn attacks
|
|
0:15:02
|
again this would be to find under a
|
|
0:15:04
|
parameter map
|
|
0:15:07
|
Now the parameter map, we are going to look at a couple of different examples of this
|
|
0:15:11
|
the first type we look at is an inspect parameter map p
|
|
0:15:15
|
that is going to used for these different
|
|
0:15:17
|
TCP, UDP or ICMP options
|
|
0:15:21
|
then when we get into our application inspections
|
|
0:15:23
|
or also look at the regular expressions
|
|
0:15:26
|
parameter maps, that are going to be used
|
|
0:15:29
|
for checking things like the http url strings
|
|
0:15:32
|
or any type of
|
|
0:15:33
|
string that is inside
|
|
0:15:35
|
the application header
|
|
0:15:37
|
that is not already predefined in a regular inspection
|
|
0:15:41
|
So next we will find the type of parameter map which is going to be an inspection map
|
|
0:15:47
|
we will give it a name, I will say that this is
|
|
0:15:49
|
for the http servers
|
|
0:15:52
|
and this is the http servers
|
|
0:15:55
|
parameters, where again
|
|
0:15:58
|
as descriptive as you can be for this type class, policy maps, parameter maps
|
|
0:16:03
|
its going to be a little bit easier to piece together
|
|
0:16:05
|
what the final result of the policy is
|
|
0:16:10
|
So inside the parameters
|
|
0:16:12
|
again this where we will change things like the individual TCP options
|
|
0:16:16
|
like the TCP
|
|
0:16:17
|
maximum incomplete sessions on a per host basis
|
|
0:16:21
|
this would be again for the syn attack prevention, this the tcp intercept
|
|
0:16:26
|
tcp syn wait time, this saying, you are trying to open the session
|
|
0:16:31
|
So you clear first portion of the three way handshake
|
|
0:16:34
|
but then the server doesn't
|
|
0:16:35
|
reply, how longer we are going to wait are going to wait
|
|
0:16:38
|
the idle time so
|
|
0:16:40
|
once the session is open but its sending traffic, how long do we manage it
|
|
0:16:44
|
the fin-wait time would be after the session is closed
|
|
0:16:47
|
how long do we maintain it in the session table
|
|
0:16:51
|
So, most of these, if you were to look at the command reference
|
|
0:16:54
|
should be fairly self explanatory exactly what the individual options do
|
|
0:17:00
|
Now for the UDP
|
|
0:17:01
|
and ICMP sessions again
|
|
0:17:04
|
since these are not connection oriented protocols
|
|
0:17:08
|
mainly the only thing we could change is how long is the session going to be managed in the state table
|
|
0:17:14
|
So since there is no specific message for UDP, that says, I am done with the connection
|
|
0:17:19
|
its just going to stay on the state table until it hits this idle timer
|
|
0:17:23
|
the same would be true of the ICMP session
|
|
0:17:29
|
A couple of other options we would have here would be to turn alerting on
|
|
0:17:34
|
this would be if we want to just generate a generic log message
|
|
0:17:39
|
if we were to turn the auto trail on
|
|
0:17:42
|
this is going to be a verbose log
|
|
0:17:45
|
which again is going to show is the individual connections
|
|
0:17:48
|
that are occurring from the clients to the servers
|
|
0:17:52
|
Now typically you would normally want, this one on
|
|
0:17:55
|
unless there is something that you are tyring to troubleshoot
|
|
0:17:58
|
some sort of attack, may be you are trying to track down
|
|
0:18:01
|
because it is going to be a very
|
|
0:18:04
|
not only processor intensive log, but its going to generate a lot of log messages
|
|
0:18:09
|
that would be just a lot of syslog information that you would have to parse through
|
|
0:18:14
|
but for this case I am going turn both of them, the learning on and the auto trail on
|
|
0:18:20
|
Hey, the other one that were typically be important is going to be the maximum incomplete sessions
|
|
0:18:26
|
the Highs and Low parameters
|
|
0:18:28
|
or the Highs and Lows on a one minute basis
|
|
0:18:33
|
So if I were to say that for within one minute
|
|
0:18:38
|
if the maximum incomplete sessions gets to, lets say, four
|
|
0:18:44
|
then we are going to start to drop the additional sessions
|
|
0:18:48
|
So again whats preventing the TCP SYN attacks
|
|
0:18:53
|
against the web servers
|
|
0:18:56
|
Now when we set the high threshold, it also says the
|
|
0:18:58
|
the low threshold is being set to four
|
|
0:19:01
|
the one minute low
|
|
0:19:03
|
this would control, how many sessions do we have to drop below
|
|
0:19:07
|
until we stop
|
|
0:19:08
|
managing the sessions
|
|
0:19:11
|
So if I were to say the one minute low is 2
|
|
0:19:14
|
means that when I first reach the threshold of 4
|
|
0:19:17
|
half open sessions, I am going to start to
|
|
0:19:19
|
to run in aggressive mode which is going to drop the new sessions
|
|
0:19:23
|
then once I go back below 2 sessions
|
|
0:19:26
|
then we are going to stop doing the management
|
|
0:19:31
|
Hey, so if we look at the result to this, lets say show run
|
|
0:19:34
|
section
|
|
0:19:36
|
parameter- [dash]
|
|
0:19:39
|
parameter-map
|
|
0:19:44
|
so we have the auto trail map, the one minute
|
|
0:19:46
|
lows and highs for the tcp sessions
|
|
0:19:48
|
also notice that the alert
|
|
0:19:50
|
options doesn't show up here
|
|
0:19:52
|
thats because the default is on
|
|
0:19:55
|
So if we did not want to log
|
|
0:19:57
|
sessions, we could turn the alert off
|
|
0:19:59
|
but alert is normally on by default
|
|
0:20:04
|
okay, so now we have the parameter map, next step would be to
|
|
0:20:06
|
apply it to the actual inspection that we were doing
|
|
0:20:10
|
So now lets look at the show run section
|
|
0:20:13
|
parameter map
|
|
0:20:17
|
or
|
|
0:20:18
|
class map or policy map or access list
|
|
0:20:24
|
So this is going to show us the vast majority of the
|
|
0:20:27
|
the policy we have configured
|
|
0:20:30
|
Now the place that I am going to apply this is on the outside going to the inside
|
|
0:20:35
|
because with these type of options typically what you would be using it for
|
|
0:20:38
|
will be to protect your inside web server
|
|
0:20:41
|
or may for the DNS servers, I want to control, whats the DNS timeout
|
|
0:20:48
|
but here for the web servers, since they are TCP based
|
|
0:20:51
|
I am applying the TCP normalization on to them
|
|
0:20:54
|
So this now means under the policy map type inspect
|
|
0:20:58
|
which is calling the class map type inspect, http server class
|
|
0:21:03
|
where http server class says that it has to be not only the protocol http
|
|
0:21:08
|
but this access list, http server's ACL
|
|
0:21:12
|
which again is calling router4's address
|
|
0:21:15
|
after the inspect option here
|
|
0:21:19
|
this is where
|
|
0:21:21
|
the parameter map is going to be called from
|
|
0:21:24
|
where in this case the parameter map name is http server
|
|
0:21:28
|
parameters
|
|
0:21:35
|
So now if we look at the
|
|
0:21:37
|
the show run section policy map
|
|
0:21:40
|
what we should see that has changed
|
|
0:21:43
|
is now there is a inspection for
|
|
0:21:45
|
these individual parameters
|
|
0:21:48
|
So next lets actually try this out and see when we
|
|
0:21:51
|
do the web browsing
|
|
0:21:53
|
from the outside to the inside
|
|
0:21:55
|
does the audit actually occur and does it give us the verbose log about the session
|
|
0:22:00
|
So from the outside client
|
|
0:22:03
|
which again is this window's host
|
|
0:22:06
|
lets open up a new session
|
|
0:22:09
|
to the server which in this case is router4
|
|
0:22:17
|
and lets generate some traffic, lets say
|
|
0:22:19
|
to show tech support
|
|
0:22:23
|
Now if we look at the result of this
|
|
0:22:25
|
on router3 we can see the audit trail
|
|
0:22:30
|
says that
|
|
0:22:31
|
on the outside to the inside
|
|
0:22:34
|
specifically in the http server class
|
|
0:22:37
|
this was the initiater
|
|
0:22:40
|
this was the responder, so its router4 on the inside
|
|
0:22:43
|
also tells us things like how many bytes have been sent over the session
|
|
0:22:48
|
So if some is trying to do some sort of
|
|
0:22:50
|
attack on your internal servers
|
|
0:22:53
|
you could potentially use the auto log
|
|
0:22:55
|
to figure out is there one outside host
|
|
0:22:58
|
thats generating tonnes and tonnes of session
|
|
0:23:02
|
but again the potential problem with this is that if you have
|
|
0:23:05
|
thousands or tens of thousands of sessions going on
|
|
0:23:08
|
then you probably wouldn't want the router to normally log all of this
|
|
0:23:12
|
So could be useful to track down a very specific problem
|
|
0:23:15
|
but you probably would not want on by default
|
|
0:23:19
|
but atleast what this is showing us
|
|
0:23:22
|
is that those individual parameters are properly working
|
|
0:23:28
|
So next lets test out
|
|
0:23:30
|
we know that the auto log is working
|
|
0:23:33
|
lets see can we get
|
|
0:23:35
|
the TCP sessions to breach
|
|
0:23:38
|
these minute high thresholds for the half open sessions
|
|
0:23:43
|
and see if the zone based policy firewall actually goes into the aggressive mode for the TCP intercept
|
|
0:23:51
|
Now again the way that the TCP intercept works
|
|
0:23:55
|
is that when the originating client
|
|
0:23:57
|
sends the syn
|
|
0:24:01
|
which again is the first portion of the three way handshake
|
|
0:24:05
|
the firewall is going to create the half open session
|
|
0:24:09
|
So now it knows, in the state table, someone is trying to connect to router4
|
|
0:24:13
|
the firewall is then expecting the return
|
|
0:24:17
|
which is the acknowledgement
|
|
0:24:19
|
and the syn, the ack syn or the syn ack
|
|
0:24:23
|
which is the second portion of the three way handshake
|
|
0:24:26
|
and then its looking for the client
|
|
0:24:29
|
to completely open the session with the final acknowledgement
|
|
0:24:32
|
which is the third portion
|
|
0:24:37
|
Now once the first portion of the handshake is received
|
|
0:24:42
|
the firewall is then going to start counting the
|
|
0:24:45
|
the syn time out
|
|
0:24:48
|
so if router4 does not respond
|
|
0:24:51
|
with the second portion of the handshake and the syn timer expires
|
|
0:24:54
|
then the session is going to remove from the table
|
|
0:24:57
|
Now if
|
|
0:24:58
|
the first portion happens, the second portion happens but the
|
|
0:25:01
|
third portion does not happen
|
|
0:25:03
|
thats what considered the half open session
|
|
0:25:06
|
So the syn attack is when
|
|
0:25:08
|
the client or more specifically the attacker
|
|
0:25:12
|
is constantly pinging the server with the syn messages
|
|
0:25:16
|
but its never listening to the acknowledgements that are coming back in
|
|
0:25:21
|
Now one way that we can
|
|
0:25:25
|
try to simulate this here
|
|
0:25:27
|
is that when we actually
|
|
0:25:28
|
receive the second
|
|
0:25:30
|
portion of the handshake back in
|
|
0:25:33
|
which is going to be the ack and syn
|
|
0:25:36
|
I am going to tell router1 to filter this flow
|
|
0:25:40
|
as it is going out that interface
|
|
0:25:43
|
and the way I can do this is by looking at either the ack or the syn
|
|
0:25:49
|
I will say that for any syn packets that are going out fastethernet0/0
|
|
0:25:53
|
we are simply going to drop those
|
|
0:26:00
|
So I am router1 and I am going to configure an access list
|
|
0:26:05
|
lets say ip access list
|
|
0:26:09
|
extended, this is going to drop
|
|
0:26:11
|
drop the syn packets
|
|
0:26:14
|
and this says deny TCP
|
|
0:26:18
|
any any syn
|
|
0:26:22
|
then we are going to permit anything else
|
|
0:26:25
|
this is then going to be applied
|
|
0:26:30
|
ip access group
|
|
0:26:33
|
drop syn out
|
|
0:26:37
|
so this is going to dropping the replies from the server
|
|
0:26:42
|
Now from the firewalls perspective router3
|
|
0:26:45
|
what it is going to see
|
|
0:26:47
|
is the first portion of the handshake
|
|
0:26:50
|
which is the initial syn
|
|
0:26:52
|
its going to see the syn ack come back from router4
|
|
0:26:55
|
but its never going to hear the third portion
|
|
0:26:58
|
because the originating host
|
|
0:27:00
|
thinks that the session was dropped in the transit path
|
|
0:27:05
|
Now what we can do is simply do back to the windows machine
|
|
0:27:08
|
and open a bunch of these sessions
|
|
0:27:17
|
so if we open our connection to the server 172.16.4.4
|
|
0:27:22
|
and simply
|
|
0:27:23
|
refresh the session over and over and over
|
|
0:27:38
|
so we will open a bunch of different sessions
|
|
0:27:40
|
and if we look at router3
|
|
0:27:43
|
what we should now see
|
|
0:27:46
|
is that the
|
|
0:27:50
|
and we can see its a kind of hard to see because we have the auto trail on
|
|
0:27:58
|
an lets keep going a little bit further
|
|
0:28:38
|
then additionally lets look at the show
|
|
0:28:41
|
policy map type inspect
|
|
0:28:45
|
zone pair
|
|
0:28:47
|
and I want to see the outside to inside pairing
|
|
0:28:51
|
and it should show me how many half open sessions there are
|
|
0:29:02
|
and this should be for the
|
|
0:29:05
|
the web sessions
|
|
0:29:07
|
So it says that the
|
|
0:29:09
|
the maximum ever here was four
|
|
0:29:12
|
half open sessions
|
|
0:29:18
|
and lets look at these individual sessions we will say policy map type inspect
|
|
0:29:22
|
zone pair
|
|
0:29:26
|
zone pair outside to inside
|
|
0:29:30
|
sessions
|
|
0:29:36
|
then lets try this again
|
|
0:29:37
|
Now one thing I am going to do just to make this a little bit clear in the logs
|
|
0:29:41
|
is to turn the auto trail off
|
|
0:29:45
|
so you can see the just for the few sessions that I have going on
|
|
0:29:52
|
its pretty confusing to try to read through the log, so lets say
|
|
0:29:56
|
auto trail is off
|
|
0:30:05
|
so lets try this again, from the
|
|
0:30:08
|
the web client, if we simply refresh these sessions
|
|
0:30:23
|
we could see now the alert happens
|
|
0:30:25
|
says for the outside to inside
|
|
0:30:27
|
http server class we are aggressive because the current one minute rate is
|
|
0:30:31
|
five half open session
|
|
0:30:34
|
so now we breach the threshold of what we configured
|
|
0:30:37
|
as the
|
|
0:30:38
|
the four half open sessions
|
|
0:30:41
|
and we can see them specifically here in the output of the
|
|
0:30:44
|
show policy map type inspect
|
|
0:30:47
|
zone pair outside the inside sessions
|
|
0:30:50
|
where these four half open sessions are coming from these
|
|
0:30:53
|
sources
|
|
0:30:55
|
and they are going to that particular server
|
|
0:31:00
|
Now generally you wouldn't have
|
|
0:31:02
|
four as the value here, it will be some number that is larger that this
|
|
0:31:06
|
but this could be quick way to figure out
|
|
0:31:08
|
is someone actually trying to
|
|
0:31:10
|
initiate a syn attack on to the server
|
|
0:31:12
|
because if you see that all of the half open sessions are coming from the same device
|
|
0:31:17
|
we would then know
|
|
0:31:19
|
that this 118.100 address is
|
|
0:31:22
|
probably trying to do some sort of denial of service attack
|
|
0:31:26
|
then to fix that we could simply
|
|
0:31:28
|
create an access list that is going to deny those individual flows
|
|
0:31:33
|
Now we could see since we waited for an additional minute
|
|
0:31:37
|
it says now the
|
|
0:31:41
|
the inspection is coming down because the current count went down to zero
|
