|
0:00:13
|
In our next section for security, we're going to look at the TCP
|
|
0:00:16
|
intercept feature as well content based access control
|
|
0:00:20
|
that can be used to prevent the TCP SYN flood attacks
|
|
0:00:25
|
both as a stand-alone feature and with CBAC where CBAC is going to
|
|
0:00:29
|
integrate the TCP intercept along with its application inspection
|
|
0:00:32
|
for doing a stateful firewall.
|
|
0:00:37
|
Now the TCP SYN attack itself is a problem with the
|
|
0:00:40
|
three-way handshake that is happening between the TCP
|
|
0:00:43
|
client and the TCP server
|
|
0:00:46
|
where normally the client is going send the TCP SYN
|
|
0:00:48
|
to which the server replies with an acknowledgment and a syn
|
|
0:00:53
|
and the client replies with the third step which is the acknowledgment.
|
|
0:00:59
|
So in the SYN flood attack, the client sends the syn
|
|
0:01:03
|
without ever sending the acknowledgment back
|
|
0:01:07
|
to fully open the third portion of the three-way handshake
|
|
0:01:10
|
which essentially means that the server's TCP stack gets overloaded
|
|
0:01:14
|
with these connections that are known as either half open
|
|
0:01:17
|
or embryonic
|
|
0:01:20
|
so TCP intercept is designed to prevent this type of attack
|
|
0:01:24
|
by either proxying for any TCP sessions that are going to the
|
|
0:01:27
|
server or passively monitoring the sessions and then resetting
|
|
0:01:32
|
half-open sessions that do not get completely open
|
|
0:01:36
|
within a specified time.
|
|
0:01:40
|
Now with the intercept mode, this is the less common way to implement
|
|
0:01:44
|
the feature because essentially, you're taking your denial of service attack
|
|
0:01:48
|
that was happening against the server and then you're moving
|
|
0:01:51
|
that down to the router.
|
|
0:01:53
|
So if the router has to proxy for every TCP SYN that it gets
|
|
0:01:57
|
then potentially you're going to overload the CPU on the
|
|
0:01:59
|
router because of this attack.
|
|
0:02:01
|
So typically, the feature is configured just in watch mode
|
|
0:02:05
|
where the router is passively listening for all of the TCP traffic
|
|
0:02:08
|
that is going through it, then if the connection
|
|
0:02:12
|
does not fully open within a certain period of time
|
|
0:02:15
|
it's going to send a reset that is from the spoofed
|
|
0:02:19
|
source going to the server.
|
|
0:02:22
|
Now configuration wise the feature is pretty straightforward
|
|
0:02:25
|
where we simply define what particular host that
|
|
0:02:27
|
we want to protect, then whether we are running in
|
|
0:02:31
|
intercept mode or in watch mode.
|
|
0:02:34
|
In watch mode, we could change the timers
|
|
0:02:37
|
in which we are resetting the session
|
|
0:02:39
|
but again, for this type of configuration, if you simply
|
|
0:02:43
|
look at the command reference for the IP TCP intercept command
|
|
0:02:47
|
you should be able to see what are all the default values
|
|
0:02:49
|
and then what are any of the minor options that you can change.
|
|
0:02:52
|
So things like the thresholds what is the minimum amount of sessions
|
|
0:02:56
|
that need to be half open before I start closing them
|
|
0:03:00
|
or before I start resetting them
|
|
0:03:02
|
which is going to be the maximum incomplete high and low
|
|
0:03:05
|
thresholds, so the high threshold controls once I
|
|
0:03:08
|
breach this value so once I go above it, then I start
|
|
0:03:11
|
to go into aggressive mode which essentially in watch mode
|
|
0:03:15
|
means that we're doing resets or in intercept mode
|
|
0:03:19
|
that we start to drop the connections
|
|
0:03:21
|
then once we go to the low value, then we stop
|
|
0:03:26
|
resetting the connections or we stop dropping the connections.
|
|
0:03:30
|
We can also do this on a one-minute basis
|
|
0:03:33
|
as opposed to an overall aggregate basis which
|
|
0:03:36
|
would be the maximum incomplete high and low
|
|
0:03:40
|
and again, this is going to be for particular hosts that we
|
|
0:03:44
|
are defining in an access list.
|
|
0:03:46
|
So I'm not going to go through a lot of the configuration for
|
|
0:03:49
|
this. Again, if you look at the configuration guide
|
|
0:03:53
|
this would be under securing the data plane.
|
|
0:03:59
|
Then under
|
|
0:04:04
|
configuring TCP intercept and preventing denial of service attacks.
|
|
0:04:09
|
You'll see that the document is not really long because there's
|
|
0:04:11
|
not that many features that you can change with this.
|
|
0:04:14
|
If you look at their particular configuration example
|
|
0:04:17
|
it says that I'm protecting any host
|
|
0:04:21
|
that is in the subnet 192.168.1.0/24
|
|
0:04:27
|
so this is where our web servers would be for example
|
|
0:04:31
|
where the TCP SYN attack is going against
|
|
0:04:34
|
these particular addresses
|
|
0:04:36
|
and this is what the router is preventing against.
|
|
0:04:40
|
Again, the key issue with this is generally you would not
|
|
0:04:42
|
want to run in intercept mode because then the denial of service
|
|
0:04:46
|
attack is essentially happening against the router as opposed
|
|
0:04:50
|
to the server and generally, the server's CPU is going to be
|
|
0:04:53
|
much more powerful than the router's is
|
|
0:04:55
|
so you don't want the DOS attack to go onto the router.
|
|
0:04:59
|
So with the watch mode, again we're simply passively
|
|
0:05:04
|
listening for the sessions, then once the watch timeout
|
|
0:05:09
|
expires, we're going to send a reset to the server.
|
|
0:05:16
|
If we're doing intercept mode, it says changes the time between the
|
|
0:05:20
|
receipt of a reset or FIN-exchange between dropping the connection.
|
|
0:05:23
|
Basically this is how long the router's going to manage it
|
|
0:05:26
|
after it's closed.
|
|
0:05:28
|
Then the connection timeout changes the time the software
|
|
0:05:31
|
will manage a connection after no activity, so this
|
|
0:05:34
|
in basically idle time or for the session.
|
|
0:05:40
|
We could also change if we're doing intercept mode
|
|
0:05:43
|
how are we dropping the sessions. Is it a random session or is it
|
|
0:05:46
|
based on the oldest one?
|
|
0:05:50
|
But again, typically we would say the intercept mode is going to be
|
|
0:05:53
|
watch, not intercept.
|
|
0:05:58
|
Now this feature also will be integrated with the
|
|
0:06:00
|
content based access control or CBAC
|
|
0:06:03
|
which means that we can reference it either from the
|
|
0:06:06
|
IP inspect command which is for CBAC or through the
|
|
0:06:10
|
zone based policy firewall
|
|
0:06:13
|
so if you look under the CBAC documentation, there should be a
|
|
0:06:17
|
section here that is related to the TCP timers
|
|
0:06:23
|
and maybe just the first one here configuring CBAC
|
|
0:06:30
|
that is for half-open sessions.
|
|
0:06:37
|
So it says an unusually high number of half-open sessions
|
|
0:06:40
|
either absolute or measured at the arrival time, could indicate
|
|
0:06:43
|
a denial of service attack is occurring. For TCP, half open means
|
|
0:06:46
|
the session has not reached the established state.
|
|
0:06:49
|
CBAC measures both the total number of existing half-open
|
|
0:06:52
|
sessions and the rate of session establishment.
|
|
0:06:54
|
We can change the max incomplete high
|
|
0:06:57
|
the max incomplete low, the one-minute high and the one-minute low
|
|
0:07:00
|
basically, it's the same thing as TCP intercept.
|
|
0:07:03
|
So they took the same feature, now it's automatically
|
|
0:07:07
|
integrated into CBAC for any host that is being inspected.
|
|
0:07:12
|
So you don't need to explicitly enable this
|
|
0:07:15
|
as soon as you're inspecting TCP, it means that CBAC
|
|
0:07:18
|
is going to enable this.
|
|
0:07:21
|
Now for the verification for TCP intercept on its own
|
|
0:07:28
|
if we look back at this document for preventing the DOS attacks
|
|
0:07:37
|
we could say show ip tcp intercept connections or
|
|
0:07:40
|
show ip -- show tcp intercept statistics
|
|
0:07:43
|
Basically CBAC is going have the same type of show command
|
|
0:07:46
|
here, but it's not specifically for TCP intercept.
|
|
0:07:50
|
So again, the TCP intercept feature on its own is used
|
|
0:07:53
|
just to prevent the SYN flood attacks
|
|
0:07:56
|
where CBAC is going to have multiple functionalities.
|
|
0:08:00
|
So intercept is just one of the included features
|
|
0:08:02
|
of CBAC where this is designed mainly to provide a stateful
|
|
0:08:07
|
inspection of the traffic.
|
|
0:08:09
|
Now the main difference between CBAC and the reflexive
|
|
0:08:12
|
access lists as we saw the reflexive ACLs have problems with
|
|
0:08:16
|
non-standard TCP or UDP applications.
|
|
0:08:20
|
So again, that means anything where the outbound flow
|
|
0:08:24
|
is not an exact mirror image of the inbound flow.
|
|
0:08:28
|
Where in the case of CBAC and then the reference from the
|
|
0:08:32
|
zone based policy firewall, since we have application specific
|
|
0:08:36
|
inspections, so there's a separate engine for
|
|
0:08:40
|
FTP versus web traffic versus DNS versus send mail
|
|
0:08:44
|
it means the router knows what is the actual application
|
|
0:08:48
|
conversation is supposed to look like.
|
|
0:08:50
|
Now the configuration of CBAC whether we're going to use
|
|
0:08:53
|
it on its own or we're going to use it with the zone based policy firewall
|
|
0:08:56
|
it really depends on how specific the inspection rules
|
|
0:09:00
|
need to be and whether we have two or more interfaces.
|
|
0:09:06
|
In the case of the example I showed before
|
|
0:09:08
|
where Router 5 was tracking traffic as it left out of the
|
|
0:09:13
|
frame relay interface.
|
|
0:09:16
|
We could apply the same type of logic using CBAC
|
|
0:09:19
|
where this is the connection to switch 2 is going to be
|
|
0:09:23
|
the inside interface.
|
|
0:09:27
|
The frame relay is going to be the outside interface
|
|
0:09:31
|
But if we had another link that was the DMZ
|
|
0:09:35
|
or maybe a second outside interface, then the CBAC policy is
|
|
0:09:39
|
going to get fairly difficult in order to maintain.
|
|
0:09:44
|
So we'll see the issue is that when we apply the
|
|
0:09:45
|
inspection between different interfaces, since we're using
|
|
0:09:48
|
access list syntax to determine what is permitted or denied
|
|
0:09:53
|
once we go beyond two interfaces, the CBAC syntax
|
|
0:09:56
|
quickly gets out of control.
|
|
0:09:58
|
So the zone based policy firewall is still using the
|
|
0:10:01
|
CBAC inspection engine, it's just a different
|
|
0:10:05
|
logic for the syntax to make it a little bit easier for us to
|
|
0:10:08
|
figure out exactly how the inspection rules are working.
|
|
0:10:15
|
So first we'll look at using CBAC for the inspection
|
|
0:10:18
|
then we'll look at using the zone based policy firewall.
|
|
0:10:22
|
So to start on Router 5, we're going to have just two interfaces.
|
|
0:10:25
|
Again, this point to point link to Router 4 is going to be disabled.
|
|
0:10:31
|
What I want to do here is allow traffic to go from the
|
|
0:10:33
|
inside interface out and then return
|
|
0:10:37
|
but I do not want unsolicited traffic to come from the outside
|
|
0:10:42
|
and go in.
|
|
0:10:47
|
Configuration wise, there's going to be a syntax difference
|
|
0:10:51
|
between the CBAC and the reflexive access list
|
|
0:10:53
|
where the IP inspect rule is going to watch the traffic
|
|
0:10:58
|
as it leaves the network
|
|
0:11:00
|
then it will automatically poke a hole in the access list applied
|
|
0:11:04
|
in the opposite direction, so there's nothing we need to do
|
|
0:11:09
|
to manually tie the inspection rule to the access list.
|
|
0:11:12
|
The router's already going to know which ACL
|
|
0:11:15
|
it needs to do an exception for based on where the
|
|
0:11:17
|
traffic is leaving the network and the direction of the inspection rule.
|
|
0:11:23
|
Now again, where this gets complicated is when we have three
|
|
0:11:27
|
or more interfaces, then the direction of the inspection
|
|
0:11:30
|
is going to be significant.
|
|
0:11:34
|
So here in our current case, we have Router 5
|
|
0:11:36
|
that has the LAN interface and the WAN interface.
|
|
0:11:40
|
The frame relay interface is the outside, the LAN interface
|
|
0:11:43
|
is the inside.
|
|
0:11:47
|
This essentially means that we have only two possible
|
|
0:11:50
|
options to do the inspection.
|
|
0:11:52
|
We can inspect the traffic as it leaves the outside
|
|
0:11:56
|
interface which would be and outside outbound
|
|
0:12:02
|
inspection
|
|
0:12:04
|
or we can inspect the traffic as it comes in the inside
|
|
0:12:09
|
which would be an inside inbound inspection.
|
|
0:12:15
|
But when we look at the result of the traffic flow
|
|
0:12:18
|
it's essentially going to be the same
|
|
0:12:20
|
because traffic that is going out the outside interface
|
|
0:12:23
|
already came in the inside interface
|
|
0:12:26
|
and generally, if it's coming in the inside interface
|
|
0:12:29
|
we know that it's going to be leaving on the outside interface.
|
|
0:12:33
|
What becomes more complex is that if we have three or more
|
|
0:12:37
|
interfaces, so Router 5 has the link that goes to
|
|
0:12:40
|
the outside network.
|
|
0:12:42
|
It has the LAN interface that goes to inside
|
|
0:12:47
|
but then maybe it has another interface that goes to the DMZ
|
|
0:12:50
|
where we have our web servers, we have our
|
|
0:12:53
|
mail servers, whatever other public services that we have
|
|
0:12:58
|
so this now essentially means that we would need a
|
|
0:13:01
|
rule that goes from the inside to out that goes from the inside
|
|
0:13:06
|
to the DMZ and goes from the outside to the DMZ.
|
|
0:13:13
|
From the inside out generally we would want to allow
|
|
0:13:16
|
everything that allow the returning flows.
|
|
0:13:19
|
From the inside to the DMZ we would only want to allow
|
|
0:13:23
|
what specific applications
|
|
0:13:26
|
that are configured there, so maybe port 80 for our
|
|
0:13:29
|
web traffic, port 25 for send mail
|
|
0:13:34
|
then maybe we're running pop mail
|
|
0:13:40
|
maybe we're running IMAP so there might be multiple
|
|
0:13:42
|
ports that are related to the mail protocols, but the key
|
|
0:13:45
|
is that now we have three separate inspection rules
|
|
0:13:48
|
and it gets kind of complicated to maintain this based on the
|
|
0:13:51
|
access lists applied on the interfaces.
|
|
0:13:54
|
So you technically can do this with CBAC, we'll see that the
|
|
0:13:58
|
logic is going to be much more straightforward when we do it with
|
|
0:14:00
|
the zone based policy firewall even though the syntax itself is
|
|
0:14:05
|
more complex, so there's more steps that we need to go through
|
|
0:14:09
|
with the zone based firewall but the end result is going to
|
|
0:14:12
|
make more logical sense and it's easier to read in the config
|
|
0:14:15
|
than the CBAC is going to be.
|
|
0:14:18
|
So first let's look at Router 5 and look at what the current
|
|
0:14:21
|
reflexive configuration is. If we show run interface
|
|
0:14:25
|
serial 0/0/0
|
|
0:14:28
|
we have two different access lists.
|
|
0:14:31
|
One that is watching the traffic as it goes out
|
|
0:14:33
|
the outside interface, one that is tracking traffic
|
|
0:14:37
|
as it comes in the outside interface.
|
|
0:14:43
|
The access list that is outside out
|
|
0:14:46
|
it's saying look for TCP, UDP or ICMP flows
|
|
0:14:54
|
if any of these protocols are sent out
|
|
0:14:58
|
I'm going to keep track of them in the state table.
|
|
0:15:04
|
When they return in on the outside interface
|
|
0:15:09
|
I'm going to check to see if they're in the state table
|
|
0:15:12
|
but if it was ICMP time exceeded or ICMP port unreachable
|
|
0:15:17
|
I'm automatically going to allow those in
|
|
0:15:19
|
I'm also going to permit EIGRP because I know that's my
|
|
0:15:22
|
control plane, then everything else I'm going to deny.
|
|
0:15:29
|
So if we were to take this same logic and apply it to
|
|
0:15:32
|
CBAC, the traffic that is going out this is going to
|
|
0:15:37
|
be now the inspect rule.
|
|
0:15:42
|
So I want to inspect the traffic as it's going out
|
|
0:15:45
|
then for outside inbound, this is still going to be a normal
|
|
0:15:48
|
access list that is applied on the interface.
|
|
0:15:52
|
The difference is that the ACL doesn't directly
|
|
0:15:54
|
reference the CBAC, CBAC internally is going to know
|
|
0:15:58
|
which access list to apply the exception on
|
|
0:16:00
|
based on the traffic flow between the interfaces.
|
|
0:16:06
|
So our first step is to write a new inspection rule.
|
|
0:16:08
|
In global config we'll say ip inspect
|
|
0:16:12
|
and we give it a name.
|
|
0:16:14
|
We'll say CBAC 1
|
|
0:16:18
|
Now we specify what is the particular application
|
|
0:16:21
|
that we want to inspect.
|
|
0:16:24
|
So similar to NBAR
|
|
0:16:26
|
we're matching on more than just the Layer 3 protocol
|
|
0:16:29
|
and the Layer 4 transport
|
|
0:16:33
|
where things like web traffic is going to based more on just
|
|
0:16:37
|
than port 80 for TCP.
|
|
0:16:42
|
Now we can do basic inspections by saying things like TCP
|
|
0:16:46
|
UDP and ICMP
|
|
0:16:50
|
So this would be including all applications of TCP
|
|
0:16:55
|
The problem is now it's not including any non-standard protocols
|
|
0:17:00
|
so things like FTP
|
|
0:17:04
|
the issue is that with active FTP the inbound flow is different
|
|
0:17:09
|
than the outbound flow
|
|
0:17:11
|
the same with protocols with TFTP
|
|
0:17:16
|
TFTP is UDP based, but this is a non-standard UDP protocol
|
|
0:17:22
|
where the request is originally going to come from
|
|
0:17:24
|
UDP port 69, but that's not the response that is going to come back in.
|
|
0:17:29
|
So we would need a specific application level inspection for this.
|
|
0:17:35
|
Now one thing you could do in a real network design
|
|
0:17:38
|
if you were using the router for this, normally you would have
|
|
0:17:40
|
a dedicated security device that's doing the inspection
|
|
0:17:44
|
but we could go to the link level and say ip nbar protocol discovery
|
|
0:17:50
|
to figure out what are the different application flows to
|
|
0:17:52
|
begin with, then that would give us a good idea as to what
|
|
0:17:56
|
we would want to inspect.
|
|
0:17:59
|
But when we compare this like to the ASA
|
|
0:18:02
|
versus the zone based policy firewall, ASA is essentially going to
|
|
0:18:05
|
inspect everything
|
|
0:18:07
|
with the default modular policy framework, so
|
|
0:18:10
|
you don't even really need to modify that and it's already
|
|
0:18:13
|
going to allow TFTP or FTP traffic to go through.
|
|
0:18:20
|
So now we have in our inspect rule if we show
|
|
0:18:23
|
ip inspect
|
|
0:18:28
|
name CBAC 1
|
|
0:18:33
|
we see its configuration it says that we're inspecting TCP
|
|
0:18:36
|
UDP, ICMP, FTP and TFTP
|
|
0:18:39
|
The alerts are on, but the audit trail is off.
|
|
0:18:44
|
Now essentially what this means is that the protocol
|
|
0:18:50
|
violations are going to be logged to the console.
|
|
0:18:54
|
So some basically unexpected event that the router receives
|
|
0:18:57
|
like a TCP SYN attack that information would be
|
|
0:19:00
|
logged to the console, that's considered an alert
|
|
0:19:03
|
where an audit trail would be a detailed log of what the
|
|
0:19:08
|
individual user is doing.
|
|
0:19:12
|
So if I wanted to see what particular web sites the users
|
|
0:19:16
|
are browsing, I could inspect http and then turn on the audit
|
|
0:19:20
|
trail and it's going to give me the specific application
|
|
0:19:23
|
level information about that particular inspection.
|
|
0:19:27
|
In either case, both of these are generated as syslog messages
|
|
0:19:30
|
where you can either send them to the console, to the buffer
|
|
0:19:33
|
or to syslog.
|
|
0:19:39
|
Now the applications themselves are going to be defined by
|
|
0:19:43
|
the port numbers that come from the ip port map command
|
|
0:19:47
|
this is similar to the ip nbar port map
|
|
0:19:51
|
that we saw in QoS
|
|
0:19:54
|
that was to define what is http talking about
|
|
0:19:58
|
that normally this is TCP port 80
|
|
0:20:00
|
so if I were protecting a web server with CBAC
|
|
0:20:05
|
but it was running on a non-standard port
|
|
0:20:08
|
I would say ip port map
|
|
0:20:10
|
whatever the particular application is like http
|
|
0:20:14
|
then the port number is TCP 80, but maybe also
|
|
0:20:20
|
TCP 8080
|
|
0:20:22
|
We could also specify a specific access list
|
|
0:20:26
|
so maybe I have one server that listens at 8080
|
|
0:20:30
|
but all the rest are listening at the normal port of 80
|
|
0:20:33
|
I could do one exception just for that versus the other ones.
|
|
0:20:37
|
Another change versus the reflexive access list is that some of the
|
|
0:20:41
|
routers' locally generated traffic can be inspected
|
|
0:20:45
|
so if we look at the ip inspect name CBAC 1 tcp
|
|
0:20:54
|
this can include the router's locally generated traffic.
|
|
0:20:57
|
So this would include the telnets from the router
|
|
0:21:02
|
if I said icmp router traffic that would be its local pings
|
|
0:21:08
|
then UDP I'm not sure. It does support this I'm not really
|
|
0:21:11
|
100 percent sure what UDP traffic the router would be generating.
|
|
0:21:15
|
It could maybe be like network time where NTP uses UDP port
|
|
0:21:20
|
123 that unless we are
|
|
0:21:24
|
manually allowing that out, then the router would not be
|
|
0:21:28
|
able to be an NTP server or would not be able continue to
|
|
0:21:30
|
forward that traffic on.
|
|
0:21:36
|
RIP could be another example as well because RIP is using
|
|
0:21:38
|
520 -- UDP 524 transport.
|
|
0:21:41
|
So now let's say show run include inspect
|
|
0:21:47
|
we have the TCP, UDP, ICMP and then some of the other
|
|
0:21:49
|
application-level inspections.
|
|
0:21:53
|
So now I need a new access list that is going to be applied
|
|
0:21:56
|
on the outside interface inbound.
|
|
0:21:59
|
I'll say ip access list extended
|
|
0:22:02
|
CBAC outside inbound
|
|
0:22:12
|
where this is essentially just going to deny anything
|
|
0:22:16
|
so I'll deny ip any any log
|
|
0:22:19
|
but also need to take into account my control find protocols.
|
|
0:22:23
|
So this means really before I deny, I need to permit
|
|
0:22:28
|
EIGRP
|
|
0:22:32
|
then any other non-standard applications that CBAC does not
|
|
0:22:36
|
know how to inspect, so let's say our trace routes if we were to say
|
|
0:22:40
|
permit icmp any any port unreachable
|
|
0:22:44
|
or icmp any any time exceeded
|
|
0:22:53
|
It means now this traffic is manually going to be allowed
|
|
0:22:56
|
inbound before we check the state table.
|
|
0:23:02
|
If we show access list
|
|
0:23:06
|
note that in access list CBAC outside inbound
|
|
0:23:10
|
there's nowhere that I'm referencing this specific
|
|
0:23:12
|
inspection rule.
|
|
0:23:15
|
The router is going to assume what inspection rule
|
|
0:23:18
|
to use based on the fact that I'm going to apply it
|
|
0:23:21
|
outbound to this specific interface.
|
|
0:23:25
|
So I'm removing the previous access lists that were used for the
|
|
0:23:28
|
reflexive ACL
|
|
0:23:30
|
I'll now say ip access group that is CBAC outside inbound in
|
|
0:23:40
|
and ip inspect CBAC 1 is inspecting out.
|
|
0:23:49
|
If we look at the show access list
|
|
0:23:53
|
depending on the individual version that you're looking at
|
|
0:23:56
|
some of them will show the CBAC sessions inside of the access list.
|
|
0:24:02
|
Some of the versions will show it in the show ip inspect
|
|
0:24:05
|
sessions
|
|
0:24:09
|
Right now, this means that Router 5 is not currently
|
|
0:24:11
|
tracking any traffic.
|
|
0:24:17
|
So now let's go behind Router 5
|
|
0:24:20
|
let's say on Switch 4 and we're going to send traffic
|
|
0:24:24
|
through the policy so we'll telnet out to Switch 1
|
|
0:24:39
|
We see that the session does open
|
|
0:24:42
|
if we look at Router 5 and look at the show access lists
|
|
0:24:48
|
there are no hits on the deny entry for the outside
|
|
0:24:52
|
interface inbound
|
|
0:24:56
|
which is what we would expect because it is being inspected
|
|
0:24:59
|
outbound. The TCP traffic which is the telnet is being inspected
|
|
0:25:03
|
so it means it should be dynamically allowed
|
|
0:25:05
|
back inbound.
|
|
0:25:07
|
If we look at the show ip inspect sessions
|
|
0:25:11
|
It says there's currently a TCP session from Switch 4 on
|
|
0:25:17
|
the inside who's using source port 47390
|
|
0:25:22
|
going to Switch 1 on the outside at port 23
|
|
0:25:26
|
and it knows that the session is currently open.
|
|
0:25:32
|
Now a key difference here between the CBAC inspection
|
|
0:25:35
|
engine and the reflexive lists is that reflexive
|
|
0:25:39
|
lists are using just an idle timer to figure out when the
|
|
0:25:42
|
session should be closed.
|
|
0:25:44
|
And the disadvantage of that is that if someone can figure out
|
|
0:25:48
|
what the session is basically spoofing the destination back to the source
|
|
0:25:53
|
you would be able to ride the connection back inbound from the
|
|
0:25:56
|
outside, but in the case of CBAC if I were to go to
|
|
0:26:01
|
Switch 4 and exit out of the telnet session
|
|
0:26:06
|
this means that I'm sending the TCP FIN bit
|
|
0:26:10
|
which means that the session is finished and I should close it.
|
|
0:26:13
|
So now on Router 5, it means it automatically stops managing this session.
|
|
0:26:19
|
So it's not an idle timer, it's actively checking the TCP
|
|
0:26:23
|
communication to look at the syn versus the syn ack
|
|
0:26:27
|
versus the ack versus the ack push versus the reset
|
|
0:26:30
|
versus the Fin
|
|
0:26:33
|
so it knows the individual flags
|
|
0:26:35
|
and what that specifically means about the TCP session
|
|
0:26:38
|
and how to manage it.
|
|
0:26:41
|
Now with other protocols that are connectionless like ICMP
|
|
0:26:45
|
or UDP, we still have that traditional firewall problem
|
|
0:26:50
|
where since there's no management of the connection
|
|
0:26:54
|
we're basically going to have to guess what to allow
|
|
0:26:57
|
out or we know what's going out, we basically have to guess
|
|
0:27:01
|
what's going to come back inbound.
|
|
0:27:03
|
So in the case of UDP flows like a phone call
|
|
0:27:07
|
there's not an active management for the CBAC session to figure out when
|
|
0:27:12
|
it starts and when it ends.
|
|
0:27:16
|
So eventually this is going to time out based on the
|
|
0:27:18
|
the inspection timers. If we say ip inspect
|
|
0:27:26
|
likewise we could change the max incomplete low, high
|
|
0:27:32
|
the one-minute values
|
|
0:27:36
|
there's time outs for DNS because DNS is going to be
|
|
0:27:39
|
UDP based.
|
|
0:27:42
|
If we were to turn the audit trail on
|
|
0:27:45
|
Let's say ip inspect audit trail
|
|
0:27:49
|
and we do this telnet session again, so from Switch 4
|
|
0:27:53
|
let's telnet to Switch 1
|
|
0:27:54
|
If we look at Router 5, we see now that there's a
|
|
0:27:58
|
specific log message
|
|
0:28:00
|
that says a TCP session started.
|
|
0:28:04
|
It tells us the source and destination and what's the particular
|
|
0:28:07
|
port values
|
|
0:28:08
|
then once we leave the session,
|
|
0:28:15
|
then Router 5 ultimately is going to know about that.
|
|
0:28:20
|
So now the session has stopped.
|
|
0:28:24
|
So whether you really want to log all this information
|
|
0:28:26
|
the individual TCP sessions for real flows that are going
|
|
0:28:31
|
over the router, it's going to be a lot of information that it needs
|
|
0:28:33
|
to log.
|
|
0:28:35
|
So typically you would only turn this on if there's something
|
|
0:28:38
|
very specific that you need to troubleshoot, some sort of flow
|
|
0:28:41
|
that maybe is going out, but then is being denied back inbound
|
|
0:28:44
|
you can use the audit trail to figure out is the CBAC engine
|
|
0:28:48
|
even caching this to begin with.
|
|
0:28:51
|
So with our example here, we're basically using this to protect the
|
|
0:28:54
|
users that are behind Router 5
|
|
0:28:58
|
where we are allowing specific types of traffic flows out
|
|
0:29:01
|
in my case, I said basically everything TCP, UDP, ICMP
|
|
0:29:05
|
and then some individual application-level inspections.
|
|
0:29:09
|
But we could say for example, we only want web browsing and
|
|
0:29:13
|
DNS to go out.
|
|
0:29:15
|
The unsolicited incoming traffic from the outside, that's going to be
|
|
0:29:19
|
blocked while the returning sessions are going to be allowed.
|
|
0:29:26
|
Now the other usage for this is going to be to protect
|
|
0:29:29
|
our TCP servers like a web server or a mail server
|
|
0:29:34
|
against a denial of service attack.
|
|
0:29:36
|
So we're going to inspect the traffic as it goes to the server
|
|
0:29:43
|
where we're only allowing maybe web packets to go to
|
|
0:29:46
|
them or we're only allowing DNS or mail packets to go to them
|
|
0:29:50
|
where in that particular case, we would apply the inspection
|
|
0:29:54
|
rule out with also an outbound ACL and an inbound ACL.
|
|
0:30:03
|
So if I were to have a case on Router 5
|
|
0:30:06
|
where I have the DMZ that goes to my web server
|
|
0:30:14
|
on the interface here
|
|
0:30:17
|
outbound I'm going to have the inspect rule
|
|
0:30:22
|
where the inspect is matching Http
|
|
0:30:27
|
but additionally, I'm going to have an access list out
|
|
0:30:30
|
that would say permit TCP 80
|
|
0:30:36
|
and then deny everything else.
|
|
0:30:41
|
So this is stopping anyone from sending traffic to that -- out that
|
|
0:30:44
|
interface if it is not port 80
|
|
0:30:49
|
On the return for the ACL in
|
|
0:30:54
|
I would essentially just deny everything
|
|
0:30:59
|
then the only thing that's going to be allowed back in on that
|
|
0:31:02
|
interface is the return traffic from the inspection.
|
|
0:31:08
|
Now the advantage of doing this is to make sure that people are not
|
|
0:31:11
|
accessing the server from other ports that we don't
|
|
0:31:14
|
want the application running on
|
|
0:31:17
|
but additionally to do the TCP intercept.
|
|
0:31:22
|
So the TCP intercept doesn't need to be manually enabled.
|
|
0:31:26
|
As soon as we turn CBAC on, it's automatically going to be there
|
|
0:31:30
|
and it's going to be running in watch mode.
|
|
0:31:33
|
So this means that if we breach the maximum incomplete high
|
|
0:31:37
|
threshold, the router's going to send a reset message to the
|
|
0:31:41
|
server that is spoofing the source of the session.
|
|
0:31:47
|
Then if this occurs on a one-minute basis,
|
|
0:31:50
|
if we go over the high value
|
|
0:31:56
|
then we should be able to see this log message.
|
|
0:31:59
|
Now one way that you could actually test this on the routers
|
|
0:32:02
|
would be to allow your syn packets to go out
|
|
0:32:08
|
but not your acknowledgements to come back
|
|
0:32:13
|
so let's say for example that Router 5 is trying to protect
|
|
0:32:18
|
against a web server that's here.
|
|
0:32:22
|
So we're inspecting the traffic as it goes in this direction.
|
|
0:32:27
|
To test this, I could go to Router 6 and telnet to the
|
|
0:32:31
|
server which would be my syn.
|
|
0:32:36
|
Then I'm going to have the reply from the server which is the
|
|
0:32:39
|
syn ack
|
|
0:32:42
|
then the third step is Router 6 sending the acknowledgement
|
|
0:32:50
|
so if I were to filter out from Router 6 to the destination
|
|
0:32:54
|
this third step, then the server would be stuck with the
|
|
0:32:59
|
half-open session.
|
|
0:33:02
|
So on Router 6 I could telnet over and over and over
|
|
0:33:05
|
and then eventually I would see the logs that Router 5 says
|
|
0:33:08
|
we're breaching the maximum incompletes
|
|
0:33:11
|
either for the total counter or for the one-minute basis.
|
