|
0:00:13
|
In our next section we are going to talk about the IPS's blocking devices
|
|
0:00:18
|
that are used to either shun host or configure access list
|
|
0:00:22
|
based on when its being triggered
|
|
0:00:25
|
Now with the current configuration of our topology
|
|
0:00:28
|
we have the IPS sensor listening for traffic
|
|
0:00:32
|
that is being sent out on to VLAN 125
|
|
0:00:36
|
by ASA2
|
|
0:00:38
|
So its packets are sent out, under this link, they are being redirected via the RSPAN
|
|
0:00:42
|
to the monitoring interface
|
|
0:00:46
|
Now once the IPS
|
|
0:00:47
|
receives a signature that has been triggered
|
|
0:00:50
|
lets say for example, there is some sort of application attack against our web server
|
|
0:00:55
|
since the traffic is not physically transiting through the IPS
|
|
0:00:58
|
in inline mode
|
|
0:01:01
|
there is a limited number of actions that it can actually take
|
|
0:01:04
|
once these signatures are triggered
|
|
0:01:06
|
Now we know that we can generate a tcp reset
|
|
0:01:10
|
by sending the reset back out the sensing device
|
|
0:01:13
|
but if we wanted to actually block
|
|
0:01:15
|
the packets with an access list or with a shun
|
|
0:01:18
|
the IPS sensor is then going to have to either telnet or SSH
|
|
0:01:22
|
into
|
|
0:01:24
|
the ASA or could telnet or SSH, lets say into router5
|
|
0:01:28
|
in order to actually configure the shuns or the access list on the interfaces
|
|
0:01:33
|
and this is where the blocking devices are going to come in
|
|
0:01:37
|
Now typically when we do this
|
|
0:01:39
|
one of the first things that we would want to define as the blocking properties
|
|
0:01:44
|
are what are the devices that we will never block
|
|
0:01:47
|
or the exceptions for the block
|
|
0:01:50
|
from the command line this is going to under the configuration and then blocking
|
|
0:01:55
|
and the blocking properties
|
|
0:01:57
|
typically
|
|
0:01:59
|
you would want to do something like this verse on the
|
|
0:02:01
|
the IDM configuration with the GUI interface
|
|
0:02:04
|
but you again technically can do all of this from the command line
|
|
0:02:09
|
but the idea behind this
|
|
0:02:10
|
is that you would want to put an exception
|
|
0:02:13
|
for your management device
|
|
0:02:16
|
so lets say for example that
|
|
0:02:19
|
we have the
|
|
0:02:21
|
the management device down here
|
|
0:02:24
|
where this is where the web session is coming from that is going to the IPS sensors command and control interface
|
|
0:02:31
|
if someone were to spoof this host, lets say the host has an address of 10.0
|
|
0:02:36
|
.6.100
|
|
0:02:38
|
so someone sensing attack
|
|
0:02:40
|
under the segment
|
|
0:02:42
|
and they are spoofing the source
|
|
0:02:44
|
of
|
|
0:02:45
|
10.0.6.100
|
|
0:02:50
|
Now once this attack occurs
|
|
0:02:52
|
if the IPS sensor then tells the ASA
|
|
0:02:55
|
to configure a shun
|
|
0:02:57
|
which again is essentially like a no route
|
|
0:03:00
|
to shun 10.0.6.100
|
|
0:03:04
|
then the problem is going to be
|
|
0:03:06
|
this management station no longer has access to the IPS
|
|
0:03:11
|
so you can end up in this kind of weird situations
|
|
0:03:14
|
where someone can do a reverse denial of service attack against your network
|
|
0:03:19
|
where the IPS turns dropping traffic towards your own servers or towards your own management sessions
|
|
0:03:25
|
so this is typically why we would want to put these exceptions
|
|
0:03:28
|
or I would want to say, may be that
|
|
0:03:31
|
the ACS server here
|
|
0:03:33
|
which is 10.0.0.100
|
|
0:03:37
|
I am going to say that this address
|
|
0:03:39
|
has a never block, or an exception for blocking on the sensor
|
|
0:03:44
|
so that this traffic is always allowed to go in the DMZ
|
|
0:03:47
|
or its always allowed to go in that direction
|
|
0:03:50
|
and then no one can
|
|
0:03:52
|
potentially take this device out of service
|
|
0:03:56
|
Now if we were to look at this from the command line
|
|
0:03:59
|
again if we look at the more
|
|
0:04:01
|
current config, this is the equivalent of show run
|
|
0:04:14
|
and since I previously had issued the terminal link 0 command
|
|
0:04:17
|
notice that it is not
|
|
0:04:18
|
pause for the output when I am doing the show command, so lets say terminal
|
|
0:04:23
|
length
|
|
0:04:26
|
lets say 25 lines
|
|
0:04:33
|
so lets assume now that we want to configure the blocking
|
|
0:04:37
|
parameters on the command line interface, but we don't necessarily know
|
|
0:04:41
|
which particular mode
|
|
0:04:42
|
this is configured on
|
|
0:04:44
|
configured under
|
|
0:04:46
|
you can currently guess which one its probably not located under
|
|
0:04:50
|
like service interface, which is going to be the physical interface parameters
|
|
0:04:54
|
the service event action rules
|
|
0:04:58
|
this would be what are the responses that you want to take
|
|
0:05:02
|
once the signature is actually triggered
|
|
0:05:04
|
but if we were to go under
|
|
0:05:06
|
any of these modes, lets say, we were to go to service
|
|
0:05:12
|
service event actually rules, rule 0
|
|
0:05:15
|
then we look at the show savings
|
|
0:05:21
|
its going to show the default configuration here
|
|
0:05:24
|
So most of this if you were
|
|
0:05:27
|
as kind of a last resort, if you are stuck using the command lines for these configurations
|
|
0:05:31
|
you can kind of fumble your way through this just by going to the different sub configurations mode and then looking at the show settings
|
|
0:05:38
|
but ideally the official way to do this is going to be through the web interface
|
|
0:05:43
|
So lets go to the IDM and lets look at how we would configure it there
|
|
0:05:48
|
if we go under configuration
|
|
0:05:56
|
configuration then under blocking
|
|
0:06:00
|
and the blocking properties
|
|
0:06:03
|
the never block addresses
|
|
0:06:05
|
which we see here
|
|
0:06:07
|
this is typically, where you would want to put your management stations or your servers
|
|
0:06:11
|
to make sure that someone is not doing again that reverse type denial of service attack
|
|
0:06:16
|
So here I am going to add an entry
|
|
0:06:18
|
for my own
|
|
0:06:20
|
manager ?? 10.0.0.100
|
|
0:06:28
|
so now if someone were to spoof the address 10.0.0.100 coming from the outside
|
|
0:06:33
|
then the sensor is not going to
|
|
0:06:35
|
configure and access list or configure shun in order to drop these packets
|
|
0:06:40
|
Now the second portion of this
|
|
0:06:42
|
is going to be to define
|
|
0:06:45
|
what are the actual login profiles
|
|
0:06:47
|
for the devices
|
|
0:06:49
|
so if we were talking to the router, or talking to the ASA
|
|
0:06:52
|
the sensor needs to know whats the authentication
|
|
0:06:55
|
and the authorization credentials
|
|
0:06:58
|
So the username and password and then the enable password
|
|
0:07:01
|
in order to actually get into global config to make these changes
|
|
0:07:05
|
So under that configuration and blocking we saw by the IDM
|
|
0:07:08
|
this is what the device login profiles are
|
|
0:07:13
|
Now in our case
|
|
0:07:14
|
we are going to be configuring this on
|
|
0:07:16
|
two different devices
|
|
0:07:17
|
we will configure it on the ASA
|
|
0:07:19
|
and we will configure it on router5
|
|
0:07:23
|
So I need to know when I telnet or when I SSH into
|
|
0:07:26
|
router5 and ASA2
|
|
0:07:29
|
whats the credentials that I am using for the login
|
|
0:07:32
|
Now on router5
|
|
0:07:35
|
we will use username
|
|
0:07:38
|
lets say username router5
|
|
0:07:42
|
IPS password cisco
|
|
0:07:45
|
and username
|
|
0:07:48
|
router5 ips
|
|
0:07:50
|
has a privilege
|
|
0:07:53
|
of level 15
|
|
0:07:54
|
So this means when this user logs in
|
|
0:07:58
|
I would have said username is router5
|
|
0:08:01
|
router5 ips
|
|
0:08:04
|
password cisco
|
|
0:08:06
|
they are automatically being authorised to privilege level 15
|
|
0:08:09
|
so wouldn't necessarily need to issue the enable password
|
|
0:08:15
|
but the IPS is going to need to know when it logs in, is it already at privilege mode
|
|
0:08:19
|
or is it at user mode
|
|
0:08:21
|
which means that it will have to say enable and then issue the enable password
|
|
0:08:25
|
so just like us from the normal command line, if we were to make any changes to the router
|
|
0:08:30
|
Now additionally I am going to have the
|
|
0:08:32
|
the blocking configuration using SSH
|
|
0:08:36
|
So I need to make sure that the SSH server
|
|
0:08:39
|
is enabled on the router5 and on the ASA
|
|
0:08:42
|
so in order to do this
|
|
0:08:44
|
first thing we need to do is conigure a domain name
|
|
0:08:47
|
I will say ine.com
|
|
0:08:49
|
and then generate an RSA key
|
|
0:08:51
|
So crypto key
|
|
0:08:52
|
generate RSA
|
|
0:08:57
|
and I will use 1024 for the size which is going to be for SSH version 2
|
|
0:09:06
|
I can now test this from the router, if I say, ssh-l
|
|
0:09:10
|
the login
|
|
0:09:12
|
which the login name here is router5 IPS
|
|
0:09:16
|
and I will telnet to my, SSH to myself, so 10.0.125.5
|
|
0:09:24
|
I end up in privilege level 15, which is what I want
|
|
0:09:29
|
so lets now look at the same thing, from the ASA
|
|
0:09:33
|
again we would need to configure a domain name
|
|
0:09:37
|
so domain name ine.com
|
|
0:09:39
|
I need to generate an RSA key
|
|
0:09:42
|
So same syntax crypto
|
|
0:09:44
|
crypto key generate rsa
|
|
0:09:51
|
then I need to say, where am I going to enable SSH in from ?
|
|
0:09:56
|
if we look at the diagram here from ASA's perspective
|
|
0:09:59
|
the SSH is going to coming in on the DMZ interface
|
|
0:10:04
|
the specific address that is coming from is
|
|
0:10:07
|
10.0.0.13
|
|
0:10:10
|
with a mask of all to 255, so I am saying this exact host
|
|
0:10:14
|
is coming in to the DMZ
|
|
0:10:18
|
then additionally to test this, I am going to say, allow SSH in from router5
|
|
0:10:25
|
from the inside
|
|
0:10:28
|
if I wanted to allow in from everywhere, I could just say SSH
|
|
0:10:31
|
0 0 inside or SSH 0 0 DMZ
|
|
0:10:35
|
but here I am limiting it to specific users
|
|
0:10:39
|
then for the authentication, I needed to check the local database
|
|
0:10:43
|
I will say username
|
|
0:10:46
|
ASA2 IPS
|
|
0:10:49
|
password cisco
|
|
0:10:51
|
and I already have my enable password set to cisco
|
|
0:10:56
|
so now for login authentication we will now say AAA
|
|
0:10:59
|
authentication
|
|
0:11:01
|
for SSH
|
|
0:11:05
|
I am going to check the local database
|
|
0:11:09
|
so now lets test this out from router5, lets say
|
|
0:11:13
|
SSH
|
|
0:11:14
|
-L for my login is ASA2 IPS
|
|
0:11:18
|
destination is 10.0.125.12
|
|
0:11:22
|
which is the ASA
|
|
0:11:26
|
from here we get to usermode, if we then enable
|
|
0:11:29
|
password is cisco thats going to get us to privilege mode
|
|
0:11:34
|
so we will try this from a different interface, lets go to global config, we will say ip ssh
|
|
0:11:38
|
source interface
|
|
0:11:40
|
and lets say I am sending this from fastethernet0/0
|
|
0:11:44
|
Now when I do the same connection
|
|
0:11:47
|
instead of ASA, I see that this is denied
|
|
0:11:51
|
because in that access list
|
|
0:11:53
|
which essentially is for the local traffic on the ASA
|
|
0:11:56
|
I only specified the
|
|
0:11:58
|
10.0.125.5 address
|
|
0:12:02
|
I didn't specified what is on
|
|
0:12:05
|
router5's
|
|
0:12:06
|
fastethernet0/0
|
|
0:12:10
|
So this is now telling me that the ASA is looking for ssh and its listening
|
|
0:12:13
|
from the proper hosts
|
|
0:12:18
|
so next for the IPS sensor
|
|
0:12:21
|
we need to configure the device login profiles
|
|
0:12:26
|
I am going to have one that is for the ASA
|
|
0:12:29
|
which the username was ips
|
|
0:12:33
|
password in cisco
|
|
0:12:35
|
and then the enable password result is cisco
|
|
0:12:39
|
I then have a separate one , that is for router5
|
|
0:12:42
|
username was router5 ips password was cisco
|
|
0:12:46
|
here I don't necessarily need to issue the enable password
|
|
0:12:49
|
because they were already authorised o level 15
|
|
0:12:55
|
the next thing I need to do
|
|
0:12:57
|
is configure, how are they actually going to communication
|
|
0:13:00
|
with the devices
|
|
0:13:03
|
So under the device locking profile
|
|
0:13:06
|
this is where I would define
|
|
0:13:08
|
is this
|
|
0:13:09
|
an IOS router ro is this an ASA or I am talking to
|
|
0:13:12
|
and for the IOS
|
|
0:13:14
|
also define
|
|
0:13:15
|
what is the interface
|
|
0:13:17
|
that we are going to use for plucking
|
|
0:13:19
|
and the what is the particular direction
|
|
0:13:22
|
Now the reason that we need to use that
|
|
0:13:24
|
is that for the
|
|
0:13:27
|
the router's configuration, it could be very specific
|
|
0:13:29
|
where may be I am doing blocking
|
|
0:13:31
|
on router1
|
|
0:13:33
|
and specifically want to do it on serial0/0/12
|
|
0:13:38
|
whereas with the ASA
|
|
0:13:41
|
the shuns are going to be configured globally
|
|
0:13:44
|
like shun on the outside or shun on the inside
|
|
0:13:46
|
so its much more straight forward for the IPS to know what the syntax is supposed to be
|
|
0:13:51
|
but the router is going to be more specific
|
|
0:13:56
|
so first lets look at using the IPS
|
|
0:13:58
|
excuse me, look at using the ASA
|
|
0:14:01
|
then we will look at the routers
|
|
0:14:02
|
because there is more specific
|
|
0:14:04
|
definitions that we can do on the routers for the blocking
|
|
0:14:09
|
so next under blocking devices
|
|
0:14:13
|
I am going to add
|
|
0:14:15
|
the address of the ASA, which is
|
|
0:14:17
|
10.0.0.12
|
|
0:14:23
|
device logging profile, this is what we define, either ASA2 or router5
|
|
0:14:28
|
and this device type is PIX or ASA
|
|
0:14:33
|
communication are we using ssh version 2, version 1
|
|
0:14:36
|
or clear text telnet
|
|
0:14:38
|
this case my
|
|
0:14:39
|
my rsa key is large enough for ssh version 2
|
|
0:14:44
|
now beyond this for the ASA, this is
|
|
0:14:46
|
pretty much the only thing we need to do
|
|
0:14:49
|
in order to get
|
|
0:14:50
|
the blocking profiles configured
|
|
0:14:54
|
Now notice 1
|
|
0:14:56
|
more additional thing actually one thing I forgot here, it says
|
|
0:14:58
|
for the
|
|
0:15:01
|
SSH DES or for 3DES
|
|
0:15:04
|
we need to get the public keys
|
|
0:15:06
|
which is going to be for the
|
|
0:15:07
|
the encryption of the SSH session
|
|
0:15:10
|
normally when you do an SSH from
|
|
0:15:13
|
the command line, or lets say like from your
|
|
0:15:15
|
your terminal emulation software
|
|
0:15:17
|
one of the things that it asks you is that do you accept the key
|
|
0:15:21
|
which is the rsa key that we are using for the encryption
|
|
0:15:25
|
but in the case of the IPS you have to
|
|
0:15:27
|
to manually get this
|
|
0:15:29
|
or to automatically request this
|
|
0:15:32
|
and this is under
|
|
0:15:33
|
the SSH
|
|
0:15:35
|
section here, under the sensor setup
|
|
0:15:37
|
and we need what are the known
|
|
0:15:40
|
host keys
|
|
0:15:42
|
now there is two ways that you can do this, when you go to add the key
|
|
0:15:46
|
you could simply paste in the public key
|
|
0:15:50
|
or if you put the address here
|
|
0:15:53
|
so if I tell 10.0.0.12
|
|
0:15:56
|
and retrieve the key
|
|
0:15:59
|
if I am able to get this successfully
|
|
0:16:01
|
it means that SSH is
|
|
0:16:04
|
enabled to that device
|
|
0:16:10
|
Now if we were to have any type of filtering in the transit path
|
|
0:16:14
|
lets say for example that the IPS is trying to get
|
|
0:16:16
|
the SSH key of router
|
|
0:16:18
|
5 or the rsa key of router 5
|
|
0:16:22
|
if the ASA is not allowing
|
|
0:16:24
|
tcp port 22
|
|
0:16:26
|
for ssh from the dmz to the inside
|
|
0:16:29
|
then that is going to be dropped
|
|
0:16:33
|
we would be able to see that from the logs ASA if we turn logging to the console on at level 7
|
|
0:16:37
|
but we will also see that when you
|
|
0:16:40
|
go to get the key here
|
|
0:16:43
|
if I would have said 10.0.125.5
|
|
0:16:49
|
retrieve the key
|
|
0:16:50
|
if it says that you are not able to do this
|
|
0:16:52
|
it means that SSH is being filtered out
|
|
0:16:59
|
so now the sensors ready to use the ASA as a blocking device
|
|
0:17:04
|
Now to test this
|
|
0:17:05
|
we need to be able to trigger, some sort of signature
|
|
0:17:09
|
that has an action performed
|
|
0:17:12
|
that is going to
|
|
0:17:14
|
do a
|
|
0:17:16
|
requesting of the block of a connection or requesting of a shun
|
|
0:17:19
|
thats when the sensor is actually going to
|
|
0:17:21
|
telnet or SSH into these devices in order to perform these actions
|
|
0:17:26
|
Now the vast majority
|
|
0:17:27
|
of these that are automatically enabled on the sensor
|
|
0:17:31
|
are once that we can't really generate from
|
|
0:17:34
|
the router's themselves
|
|
0:17:36
|
to test if it works
|
|
0:17:38
|
we need some sort of application thats actually initiating the attack
|
|
0:17:42
|
so what I am going to do here
|
|
0:17:45
|
is modify some of the signatures
|
|
0:17:47
|
so that based on
|
|
0:17:49
|
a particular criteria that we are issuing
|
|
0:17:53
|
that we can generate from the routers themselves
|
|
0:17:55
|
that we can use the signature
|
|
0:17:57
|
request the blocking
|
|
0:18:00
|
Now talked little bit about this before
|
|
0:18:02
|
that when we go under the signature definition and the signature configuration
|
|
0:18:07
|
you can edit
|
|
0:18:09
|
or enable or disable some of the
|
|
0:18:11
|
the signatures that are already there
|
|
0:18:13
|
for example for
|
|
0:18:15
|
signature 2004 that was for our echo request
|
|
0:18:19
|
but we also have the option to define
|
|
0:18:22
|
custom signatures
|
|
0:18:25
|
Now we will take a look at more details later
|
|
0:18:28
|
some of the more advanced examples that we can do with signature customization
|
|
0:18:32
|
but under the signature configuration
|
|
0:18:35
|
we can take
|
|
0:18:36
|
user defined
|
|
0:18:39
|
actions
|
|
0:18:40
|
for particular user defined events
|
|
0:18:43
|
where
|
|
0:18:44
|
what we will look at here is to say
|
|
0:18:46
|
I want to block a telnet connection
|
|
0:18:48
|
and generate an alert message
|
|
0:18:50
|
if someone issued the keyword delete flash
|
|
0:18:55
|
So by looking into the actual tcp payload
|
|
0:18:58
|
similar to how the ASA or the zone based policy
|
|
0:19:01
|
firewall was able to do that based on the application inspection
|
|
0:19:05
|
we are going to look into the payload of the packet
|
|
0:19:07
|
and then based on this we are going to take an action
|
|
0:19:10
|
and what I want to happen
|
|
0:19:12
|
is that when someone from the outside
|
|
0:19:14
|
lets say we go to the test pc
|
|
0:19:17
|
and we telnet to router6
|
|
0:19:21
|
and once I have telnet it into router6, I tried to delete its flash
|
|
0:19:24
|
what I want the sensor to do
|
|
0:19:26
|
is to SSH
|
|
0:19:29
|
into the ASA
|
|
0:19:30
|
and then configure a shun
|
|
0:19:32
|
so that the test pc is no longer able
|
|
0:19:36
|
to send traffic to that direction
|
|
0:19:41
|
we will then also look at the same type of action configured on the router
|
|
0:19:45
|
so that the IPS sensor is then going to SSH into router5
|
|
0:19:49
|
and we could configure it
|
|
0:19:50
|
to apply access list
|
|
0:19:52
|
or to apply policing actions
|
|
0:19:55
|
based on the particular
|
|
0:19:56
|
signatures that we are defining
|
|
0:20:00
|
So configuration wise this is going to be under signatures definitions and then the custom signature wizard
|
|
0:20:08
|
so now lets go to the IDM, lets go under
|
|
0:20:11
|
the signature definitions 60
|
|
0:20:17
|
and run the custom signature wizard
|
|
0:20:25
|
Now we have the option of these different engines
|
|
0:20:27
|
that are going to be looking at different types of payloads
|
|
0:20:31
|
this is similar to the different types of
|
|
0:20:33
|
application level policy maps
|
|
0:20:35
|
that we have in the ASA and we have in the routers
|
|
0:20:39
|
where something like service http
|
|
0:20:42
|
this would be looking at the specific http methods
|
|
0:20:46
|
like I could say if someone tries to delete a file
|
|
0:20:49
|
through the web interface
|
|
0:20:51
|
I am going to reset the session
|
|
0:20:53
|
or if they try to use an http
|
|
0:20:55
|
post upload a file
|
|
0:20:57
|
then I am going to block that connection
|
|
0:21:00
|
in my case since I am going to look at telnet
|
|
0:21:02
|
this is going to be a string
|
|
0:21:04
|
just any arbitrary string that is inside the tcp payload
|
|
0:21:08
|
so the engine is string tcp
|
|
0:21:11
|
I could then give it a number
|
|
0:21:13
|
a sub signature name
|
|
0:21:15
|
a sub signature id and then a name, lets
|
|
0:21:18
|
say this one is to
|
|
0:21:20
|
request
|
|
0:21:24
|
shun
|
|
0:21:25
|
or actually no, I will say delete
|
|
0:21:28
|
flash
|
|
0:21:30
|
and the alert notes are to
|
|
0:21:35
|
shun on keyword
|
|
0:21:37
|
delete flash, so this is whatever
|
|
0:21:40
|
arbitrary description that you want to put in there
|
|
0:21:43
|
what really is going to matter is, what are the specific
|
|
0:21:46
|
parameters of this signature
|
|
0:21:49
|
the event actions so this is what do we want to do once this is triggered
|
|
0:21:54
|
I want to do two things, I want to produce an alert
|
|
0:21:57
|
and I want to request
|
|
0:21:59
|
a logging of the host
|
|
0:22:05
|
then the regular expression string
|
|
0:22:08
|
this is similar to what we saw in the IOS and the ASA
|
|
0:22:12
|
when we are doing the application level policy maps
|
|
0:22:15
|
is that we need to look at the arbitrary
|
|
0:22:17
|
key words inside the tcp payload
|
|
0:22:21
|
to figure out is the signature triggered or is the signature not triggered
|
|
0:22:25
|
so here I am simply just going to say
|
|
0:22:28
|
the string delete flash
|
|
0:22:32
|
if this regular expression is triggered
|
|
0:22:35
|
and its going to trigger on port 23
|
|
0:22:38
|
so the service port for telnet
|
|
0:22:42
|
the direction is going
|
|
0:22:44
|
to destination
|
|
0:22:45
|
23
|
|
0:22:48
|
so to the service
|
|
0:22:50
|
and swap attacker victim pair, this would be
|
|
0:22:54
|
do I want the attacker
|
|
0:22:57
|
to be the one who is initiating the connection or the one who is receiving
|
|
0:23:02
|
or in this case if someone is trying to delete the flash
|
|
0:23:05
|
if the test pc is telnetting into router6
|
|
0:23:08
|
from the IPS's perspective
|
|
0:23:11
|
this source
|
|
0:23:12
|
is the test pc
|
|
0:23:16
|
and the destination
|
|
0:23:17
|
is router6
|
|
0:23:20
|
the source port
|
|
0:23:23
|
is random
|
|
0:23:26
|
the destination port
|
|
0:23:29
|
is port 23 for telnet
|
|
0:23:32
|
so this means that my service port is going to be 23
|
|
0:23:35
|
the direction is to
|
|
0:23:37
|
the server, so its destination 23
|
|
0:23:40
|
then the
|
|
0:23:41
|
attacker is the source
|
|
0:23:43
|
the victim is the destination
|
|
0:23:50
|
then I could configure the
|
|
0:23:53
|
the risk rating, basically the number that is assigned to this
|
|
0:23:56
|
and then whats the severity of the alert
|
|
0:23:58
|
lets say this is going to be a high
|
|
0:23:59
|
severity alert
|
|
0:24:04
|
Now its going to apply the
|
|
0:24:07
|
apply the signature
|
|
0:24:10
|
now to test this
|
|
0:24:11
|
there is a couple of different things that we are going to look at
|
|
0:24:14
|
from the IPS sensors command line
|
|
0:24:17
|
when we go to
|
|
0:24:20
|
the sensor and look at the show
|
|
0:24:22
|
advance alerts
|
|
0:24:27
|
I should see the alert show up here, once the signature is triggered
|
|
0:24:32
|
additionally on the ASA
|
|
0:24:34
|
I should see under the show shun
|
|
0:24:38
|
that the attacker is then denied, from sending traffic into the network
|
|
0:24:43
|
additionally I am going to turn logging on, lets say logging console 7
|
|
0:24:52
|
then we are going to test this out from the
|
|
0:24:55
|
from the test pc
|
|
0:24:59
|
so next on the test pc, lets go to the command prompt
|
|
0:25:03
|
and we are going to telnet to router6, we will telnet to 10.0.6.6
|
|
0:25:08
|
and once we login
|
|
0:25:09
|
we will issue the delete flash command
|
|
0:25:13
|
and what happens once I issue that
|
|
0:25:15
|
the connection is now dropped from here
|
|
0:25:19
|
so any other characters that I type here
|
|
0:25:20
|
are not going to be sent to the telnet line
|
|
0:25:23
|
if we go to the
|
|
0:25:26
|
ips
|
|
0:25:27
|
and we look at the
|
|
0:25:29
|
the alert logs
|
|
0:25:31
|
it says that
|
|
0:25:33
|
signature id 60000 with sub id 0 has been triggered
|
|
0:25:38
|
the description is delete flash
|
|
0:25:40
|
has these particular details that we specified
|
|
0:25:43
|
this is the attacker
|
|
0:25:45
|
which was the test pc
|
|
0:25:47
|
and the target of the attack was router6
|
|
0:25:49
|
at port 23
|
|
0:25:52
|
then once the alert was generated
|
|
0:25:55
|
it says that the action is that block requested is true
|
|
0:25:59
|
and the context or the reason why
|
|
0:26:01
|
that this was heard
|
|
0:26:04
|
is that
|
|
0:26:05
|
we had the
|
|
0:26:07
|
delete flash being received
|
|
0:26:10
|
now notice that it separates these into two different fields, one that it heard from the
|
|
0:26:13
|
target and one that it heard from the attacker
|
|
0:26:17
|
because with the telnet connection
|
|
0:26:18
|
from the attacker we are sending
|
|
0:26:20
|
this information, so this is the username and password, were cisco and cisco
|
|
0:26:25
|
the
|
|
0:26:26
|
actual telnet server which is router6
|
|
0:26:29
|
was asking for the user name, that was asking for the password
|
|
0:26:32
|
its sending the prompt back
|
|
0:26:35
|
and then it was the attacker that was trying to delete the flash
|
|
0:26:39
|
Now once this occurs
|
|
0:26:42
|
its going to try to
|
|
0:26:44
|
request the block, which is of the ASA
|
|
0:26:46
|
if we go to the ASA, we should see here it its log
|
|
0:26:50
|
that a packet was then shunned
|
|
0:26:53
|
which essentially means that the packet was dropped, its coming from
|
|
0:26:57
|
the
|
|
0:27:00
|
host address 192.168.118.100
|
|
0:27:04
|
going to router6, 10.0.6.6
|
|
0:27:08
|
if we look at the show shun
|
|
0:27:11
|
this is what was requested from the IPS
|
|
0:27:15
|
thats essentially saying this exact host is going to be dropped
|
|
0:27:18
|
and I don't care where the traffic is going to, I don't care of the particular
|
|
0:27:22
|
protocol or port number
|
|
0:27:24
|
we are just filtering
|
|
0:27:26
|
the host based on its address
|
|
0:27:29
|
Now if we were to go back to
|
|
0:27:31
|
the IDS
|
|
0:27:34
|
or the IDM
|
|
0:27:35
|
and go under monitoring
|
|
0:27:38
|
we will see this field here the active hosts blocks
|
|
0:27:41
|
this is the devices that are currently getting shunned or that are currently getting
|
|
0:27:45
|
filtered based on an access list
|
|
0:27:48
|
where eventually
|
|
0:27:50
|
the session is going to timeout or the shunning is going to timeout
|
|
0:27:53
|
we see we have a default timer of 30 minutes
|
|
0:27:56
|
says that this was destination port 23 and protocol number 6
|
|
0:28:00
|
which is tcp port 23 for telnet
|
|
0:28:04
|
the connection block enabled is false
|
|
0:28:07
|
which means that it didn't ask for the specific
|
|
0:28:10
|
connection details like the port
|
|
0:28:12
|
its just talking about the source address here, the source ip
|
|
0:28:19
|
So for the ASA, using this as the blocking device, its pretty straight forward
|
|
0:28:24
|
again the only thing that we need to do is under the configuration
|
|
0:28:27
|
when we go to the
|
|
0:28:29
|
blocking login
|
|
0:28:30
|
profile, we need to give the username and password
|
|
0:28:34
|
then under blocking devices we will specifying its address as an ASA
|
|
0:28:38
|
then under the SSH known host keys we need to make sure we get its ssh key
|
|
0:28:44
|
Now offcourse if were doing telnet, we would need the ssh key
|
|
0:28:47
|
but generally
|
|
0:28:49
|
you are going to be doing this management through ssh, not through telnet
|
|
0:28:54
|
so next lets look at the same configuration, but we are going to use router5
|
|
0:28:59
|
so onto the blocking devices I am going to
|
|
0:29:01
|
actually first thing I am going to do is monitoring
|
|
0:29:04
|
under the active host blocks, I am going to delete this
|
|
0:29:08
|
and what we should see this does if we go back to the ASA's command line
|
|
0:29:12
|
is that the user
|
|
0:29:14
|
issued the no shun command
|
|
0:29:17
|
so either once the session times out
|
|
0:29:20
|
or we manually clear the session
|
|
0:29:22
|
the IPS is logging into the ASA and then removing the shun
|
|
0:29:28
|
but now we are going to make the changes so that it is happening on
|
|
0:29:31
|
router5, as opposed to the ASA
|
|
0:29:34
|
Now before I actually configure this on the sensor
|
|
0:29:38
|
on the IPS
|
|
0:29:39
|
what I am going do on router5 is turn on
|
|
0:29:41
|
local command accounting
|
|
0:29:44
|
through the archive feature
|
|
0:29:46
|
so that we can see the individual commands the IPS is issuing
|
|
0:29:51
|
so on router5 in global config
|
|
0:29:54
|
I am going to say archive
|
|
0:29:57
|
config, or actually just archive
|
|
0:29:59
|
then log config
|
|
0:30:03
|
and I want logging to be enabled
|
|
0:30:07
|
I will say the size of the log
|
|
0:30:10
|
is the maximum ?? a 1000 entries
|
|
0:30:16
|
from now on everytime we
|
|
0:30:18
|
look at, it must be telnetted in there
|
|
0:30:22
|
everytime we look at the show
|
|
0:30:25
|
archive
|
|
0:30:29
|
config, or show archive
|
|
0:30:37
|
show archive log config off
|
|
0:30:40
|
this is going to show all of the changes that we were making
|
|
0:30:44
|
so lets see, if we can clear this out, lets say clear archive
|
|
0:30:49
|
log config
|
|
0:30:56
|
then again show archive log config all
|
|
0:30:58
|
So this is going to show the particular commands that the user is entering
|
|
0:31:02
|
and what particular session that it was belonging to
|
|
0:31:06
|
So for example if I were to go to global config and create a new loopback interface
|
|
0:31:10
|
I will say loopback 1234
|
|
0:31:12
|
with address 1.2.3.4
|
|
0:31:16
|
then exit
|
|
0:31:17
|
when I now look at the show
|
|
0:31:20
|
archive log config all
|
|
0:31:21
|
it should say the user console
|
|
0:31:24
|
on the console line
|
|
0:31:25
|
went to global config, added an interface and added an ip address
|
|
0:31:30
|
but now since we had the specific username that is for the ips sensor
|
|
0:31:34
|
which is router5 ips
|
|
0:31:36
|
we could see the individual commands
|
|
0:31:38
|
and the changes that it has made
|
|
0:31:40
|
making when it actually logs in
|
|
0:31:43
|
so now lets go back to the sensor
|
|
0:31:46
|
and under configuration
|
|
0:31:49
|
on the blocking devices I am going to add
|
|
0:31:52
|
router5
|
|
0:31:54
|
and delete the ASA, so lets delete the ASA
|
|
0:31:58
|
at router5 its address is 10.0.125.5
|
|
0:32:02
|
the logging profile is r5
|
|
0:32:05
|
its a router and I want to be able to run blocking and rate limiting
|
|
0:32:10
|
which is of this we can choose is depended on the IOS version
|
|
0:32:13
|
pretty much any thing greater than 12T or 12.3T
|
|
0:32:17
|
is going to support both of them
|
|
0:32:19
|
then the communication again here, this is
|
|
0:32:21
|
3DES SSH for ssh version 2
|
|
0:32:28
|
then under the router blocking device interfaces
|
|
0:32:32
|
I need to tell the sensor
|
|
0:32:33
|
on router5
|
|
0:32:35
|
what is the specific interface
|
|
0:32:38
|
where again if we look back at our topology
|
|
0:32:41
|
on router5 this is going to be fastethernet0/1
|
|
0:32:45
|
So I want the IPS sensor to SSH into router5
|
|
0:32:48
|
and then make changes on this interface
|
|
0:32:50
|
in order to protect devices on the inside
|
|
0:32:54
|
network, which in this case is router6
|
|
0:32:58
|
So I do need to specify this exactly, I will say fast ethernet
|
|
0:33:02
|
0/0
|
|
0:33:03
|
the direction of the filtering is going to be inbound
|
|
0:33:08
|
Now if I want exceptions to this access list
|
|
0:33:11
|
that the IPS is going to configure
|
|
0:33:14
|
I would specify here then
|
|
0:33:15
|
here as the
|
|
0:33:16
|
three block and the
|
|
0:33:18
|
post block acl
|
|
0:33:21
|
what this essentially means is that
|
|
0:33:23
|
when the sensor is making its changes
|
|
0:33:26
|
lets say that on router5
|
|
0:33:28
|
I configure two ACLs, so I have acl 100
|
|
0:33:32
|
and I have acl
|
|
0:33:33
|
101
|
|
0:33:35
|
where 100 is going to be my
|
|
0:33:37
|
preblock
|
|
0:33:39
|
acl
|
|
0:33:40
|
and 101 is going to be the post block acl
|
|
0:33:45
|
when the sensor comes in and makes its changes
|
|
0:33:48
|
its going to create a new access list
|
|
0:33:50
|
that starts with the entries from 100
|
|
0:33:55
|
then its going to have its own changes, so thats what the IPS is adding
|
|
0:33:59
|
then its going to be followed by 101, which is the post block acl
|
|
0:34:05
|
So if there is something very
|
|
0:34:06
|
specific, we want to do at the beginning of the acl
|
|
0:34:08
|
always
|
|
0:34:09
|
then at the end of the acl as well
|
|
0:34:12
|
we would need to
|
|
0:34:14
|
to specify that on the router
|
|
0:34:16
|
so lets say for example that we want to
|
|
0:34:18
|
deny a specific service
|
|
0:34:20
|
from being used all the time
|
|
0:34:23
|
on the router lets say that we want to
|
|
0:34:27
|
have an access list, we will say access
|
|
0:34:29
|
our ip access list
|
|
0:34:31
|
extended, I will call this my pre block
|
|
0:34:34
|
acl
|
|
0:34:36
|
that denies tcp any any =
|
|
0:34:42
|
lets say ftp
|
|
0:34:44
|
ftp and ftp data
|
|
0:34:46
|
so we don't want anyone ftping in on that interface
|
|
0:34:51
|
so now on the sensor if we specify that the
|
|
0:34:54
|
pre block acl is named
|
|
0:34:56
|
pre block
|
|
0:34:57
|
which I defined on router5
|
|
0:35:00
|
once I apply this
|
|
0:35:02
|
we should see we get a log
|
|
0:35:05
|
from
|
|
0:35:07
|
router5, it says someone logged in on vty0
|
|
0:35:09
|
which is the ssh or telnet lines
|
|
0:35:13
|
it was router5 IPS and it is making changes
|
|
0:35:16
|
we now look at the show
|
|
0:35:18
|
archive
|
|
0:35:20
|
show archive config
|
|
0:35:22
|
or show archive log config
|
|
0:35:28
|
we see that the user router5 IPS came in on vty0
|
|
0:35:33
|
it added an access list named ids_fastethernet0/0_in_0
|
|
0:35:41
|
it then
|
|
0:35:44
|
allowed the IPS
|
|
0:35:48
|
so its own address there 10.0.0.13
|
|
0:35:51
|
it tool my pre block acl
|
|
0:35:55
|
put those entries here
|
|
0:35:56
|
and then it is allowing everything else
|
|
0:35:59
|
Now if we look at the running config
|
|
0:36:02
|
we show run interface fastethernet0/0
|
|
0:36:05
|
these are the changes that the sensor is making
|
|
0:36:08
|
you will see its doing some kind of
|
|
0:36:10
|
non sense config here basically, where
|
|
0:36:13
|
it was
|
|
0:36:15
|
removing the access list and then adding the access list
|
|
0:36:18
|
from being applied, removing it globally and then re adding it globally
|
|
0:36:23
|
configuring a policy map, applying it
|
|
0:36:25
|
then removing it and then deleting the policy map
|
|
0:36:28
|
basically what its doing here
|
|
0:36:29
|
is just checking the capability of what the router supports
|
|
0:36:33
|
So it wants to know, Is this the correct
|
|
0:36:35
|
interface name
|
|
0:36:37
|
that is doing the config on
|
|
0:36:38
|
and does this router actually
|
|
0:36:40
|
support
|
|
0:36:42
|
having the service policy configured in on the interface
|
|
0:36:46
|
so if it were to run these commands and then get an error message back
|
|
0:36:49
|
its going to tell us that in the log over the IDM
|
|
0:36:52
|
saying that there is something wrong with the blocking device, like may be we configure the
|
|
0:36:56
|
the interfaces address incorrectly
|
|
0:37:00
|
but since we have the acl on there
|
|
0:37:02
|
we know that this is the correct action
|
|
0:37:08
|
So now lets look at the same
|
|
0:37:10
|
signature setting that we had before
|
|
0:37:15
|
where we were
|
|
0:37:17
|
configuring it to
|
|
0:37:19
|
shun the connection or basically
|
|
0:37:22
|
filter out the source
|
|
0:37:26
|
when that signature is triggered which is our custom signature 60000
|
|
0:37:30
|
says that if someone says
|
|
0:37:32
|
delete flash
|
|
0:37:34
|
the action is that we are going to produce an alert and we are going to
|
|
0:37:37
|
request to have the host blocked
|
|
0:37:41
|
Now lets be a little bit more specific here, instead of saying just
|
|
0:37:44
|
blocking the host, lets try blocking the connection
|
|
0:37:55
|
where if we go back to the command line to the sensor
|
|
0:37:58
|
we are still looking at the show
|
|
0:38:01
|
advanced, specifically show advanced alerts
|
|
0:38:04
|
then if I were to go to
|
|
0:38:07
|
the test PC
|
|
0:38:11
|
and lets try this out again, lets
|
|
0:38:14
|
telnet to 10.0.6.6
|
|
0:38:23
|
then I say delete flash
|
|
0:38:39
|
lets see if the alarm was tiggered
|
|
0:41:25
|
so now lets try this again from the windows machine
|
|
0:41:27
|
if we open up another telnet session
|
|
0:41:30
|
we will telnet to router6
|
|
0:41:34
|
and we issue the delete flash command
|
|
0:41:38
|
we should be able to go to the sensor
|
|
0:41:41
|
and see that the
|
|
0:41:43
|
action was triggered
|
|
0:41:45
|
says that the attacker was
|
|
0:41:47
|
the test pc
|
|
0:41:49
|
victim is router6 on port 23
|
|
0:41:52
|
the action now is that we are requesting to block the connection
|
|
0:41:56
|
where the
|
|
0:42:00
|
attackers is issuing this the target is issuing that
|
|
0:42:04
|
if we now go to router5, we should see
|
|
0:42:06
|
that the ips logged in
|
|
0:42:09
|
if we look at the show
|
|
0:42:16
|
show archive
|
|
0:42:17
|
log config
|
|
0:42:19
|
we can say this specific
|
|
0:42:21
|
the user
|
|
0:42:22
|
If I were to say router5 IPS
|
|
0:42:24
|
and then also the specific
|
|
0:42:26
|
session number
|
|
0:42:28
|
so if I want to say the
|
|
0:42:30
|
first record to display, lets say is record
|
|
0:42:34
|
10
|
|
0:42:36
|
or if we actually look at the final one, which was session
|
|
0:42:41
|
session 14
|
|
0:42:43
|
session 14, that was the last time they were logged in
|
|
0:42:46
|
but it came in and it said, I am going deny the host
|
|
0:42:50
|
192.168.118.100
|
|
0:42:54
|
from going to 10.0.6.6 at port 23
|
|
0:42:59
|
then this is being applied in
|
|
0:43:02
|
on
|
|
0:43:03
|
fastethernet 0/0
|
|
0:43:05
|
so if we look at the show access list
|
|
0:43:11
|
to neither host 192.168.118.100
|
|
0:43:21
|
So it is actually editing the access list
|
|
0:43:22
|
as per what it looks like is that its on the wrong interface
|
|
0:43:26
|
if we look at the
|
|
0:43:28
|
show ip interface brief
|
|
0:43:30
|
the interface that this on is fastethernet0/1
|
|
0:43:33
|
which means when I configure the blocking device I listed the wrong interface
|
|
0:43:38
|
should be fastethernet0/1, as opposed to 0/0
|
|
0:43:41
|
so lets do this, lets go back to the IDM
|
|
0:43:46
|
then if we look at the active host blocks
|
|
0:43:50
|
and click on the refresh here, it should show that its trying to filter out the test pc
|
|
0:43:54
|
So lets delete this
|
|
0:43:57
|
which is, should cause the its log back into router5 and make more changes
|
|
0:44:01
|
so now if we look at the show access list
|
|
0:44:04
|
we see it deleted the block from that list
|
|
0:44:08
|
but now what I need to do is go back
|
|
0:44:10
|
to under configuration
|
|
0:44:12
|
and the
|
|
0:44:15
|
router blocking device interfaces
|
|
0:44:17
|
I need to edit this, so this is fastethernet0/1
|
|
0:44:20
|
not fastethernet0/0
|
|
0:44:24
|
Now on router5 lets see if it
|
|
0:44:26
|
it changed again which it did
|
|
0:44:29
|
and if we look at the
|
|
0:44:33
|
the show access list
|
|
0:44:36
|
Now we have fastethernet0/1
|
|
0:44:39
|
in_1
|
|
0:44:41
|
and if we look at, lets look at the result of these on the interfaces
|
|
0:44:45
|
I need to manually remove
|
|
0:44:47
|
the other
|
|
0:44:51
|
the other access list, so its not a 100% full proof, what the IPS is doing
|
|
0:44:56
|
it can make mistakes when its making changes at the routers
|
|
0:44:59
|
so if you are doing this in production, you do need to be very careful as to
|
|
0:45:03
|
what your settings are
|
|
0:45:05
|
you could potentially lock your self out in the network
|
|
0:45:07
|
by having the IPS go and
|
|
0:45:09
|
do the automation of making the changes
|
|
0:45:12
|
so lets remove that access
|
|
0:45:13
|
group and then I am going to delete the access list as well
|
|
0:45:17
|
lets say do show run include access list
|
|
0:45:23
|
so I will remove the previous one
|
|
0:45:30
|
so now lets try this again, if we go back to the sensors command line
|
|
0:45:33
|
I want to see if a new log is generated
|
|
0:45:36
|
when the test pc
|
|
0:45:38
|
lets try this again, telnet to 6
|
|
0:45:41
|
then says delete
|
|
0:45:44
|
flash
|
|
0:45:45
|
delete flash
|
|
0:45:49
|
Now from here I am now locked out of the telnet session
|
|
0:45:54
|
if I go to ping router6
|
|
0:45:58
|
this still going to be allowed
|
|
0:46:00
|
but new subsequent
|
|
0:46:01
|
telnets should be denied
|
|
0:46:05
|
So this is telling me that on the IPS
|
|
0:46:07
|
the signature did actually trigger
|
|
0:46:10
|
it says the
|
|
0:46:12
|
the attacker was the test pc
|
|
0:46:14
|
the victim was router6
|
|
0:46:16
|
then the action is going to be that its requesting the blocking
|
|
0:46:19
|
we look at 5, we can see the IPS sensor logged in again
|
|
0:46:23
|
if we look at now the show
|
|
0:46:25
|
access list
|
|
0:46:28
|
its now filtering out the test pc
|
|
0:46:30
|
from sending the telnet
|
|
0:46:35
|
So again these actions when we look at the signatures
|
|
0:46:40
|
under configurations
|
|
0:46:42
|
signature definitions, signature 0
|
|
0:46:46
|
then we go to signature 60000 which was our custom 1
|
|
0:46:50
|
the event actions
|
|
0:46:52
|
these request block connections
|
|
0:46:54
|
block host
|
|
0:46:55
|
SNMP trap or reset tcp connection
|
|
0:46:58
|
these ones are going to be specific
|
|
0:47:00
|
for the promiscuous mode
|
|
0:47:03
|
Now if I were to change this from produce
|
|
0:47:06
|
the alert and
|
|
0:47:07
|
request block connection, which it was before like this
|
|
0:47:10
|
if I changed it instead to say reset tcp session
|
|
0:47:14
|
what we should see
|
|
0:47:16
|
is that on the
|
|
0:47:19
|
monitoring interface
|
|
0:47:21
|
which is
|
|
0:47:24
|
coming here, so the traffic is being redirected this way under the sensor
|
|
0:47:28
|
if I change the signature to say now, reset tcp connection
|
|
0:47:33
|
when some one is telnetting in, lets say router1 telnets to 6
|
|
0:47:37
|
triggers the signature by saying delete flash
|
|
0:47:39
|
the sensor is then going to spoof
|
|
0:47:42
|
a reset
|
|
0:47:43
|
from the server
|
|
0:47:45
|
which goes
|
|
0:47:46
|
to router6
|
|
0:47:47
|
to drop its connection
|
|
0:47:49
|
but then it also goes back to router1
|
|
0:47:52
|
to tell it to drop its connection
|
|
0:47:55
|
and the result to this, we would see
|
|
0:47:57
|
is that if we were to
|
|
0:48:00
|
say we go to router1 and test this
|
|
0:48:03
|
we telnet into router6
|
|
0:48:07
|
and type delete flash
|
|
0:48:09
|
we see that it closes the connection
|
|
0:48:13
|
Now the difference between this is that
|
|
0:48:14
|
its not going to stop me from doing
|
|
0:48:17
|
more telnets later, so there is no access list thats being configured
|
|
0:48:21
|
what its doing instead
|
|
0:48:24
|
is closing the session
|
|
0:48:27
|
Now as I mentioned before the regular
|
|
0:48:29
|
expression for this has to be very very specific
|
|
0:48:32
|
because notice what the sensor did not catch
|
|
0:48:36
|
is that if were to say
|
|
0:48:38
|
delete flash
|
|
0:48:40
|
it caught that and it logged me out
|
|
0:48:43
|
but if I were to telnet it again
|
|
0:48:46
|
and say
|
|
0:48:48
|
delete
|
|
0:48:51
|
flash
|
|
0:48:52
|
but I put a backspace in there first
|
|
0:48:56
|
since the linear characters that I am sending in the tcp string
|
|
0:49:00
|
were not actually delete flash
|
|
0:49:02
|
it was like delete flas
|
|
0:49:04
|
then whatever the character code is for backspace
|
|
0:49:08
|
then a space and then a h
|
|
0:49:11
|
so it will also be the same, if I were to use capitals
|
|
0:49:14
|
I would have said capital D
|
|
0:49:16
|
delete flash, its not going to catch this one
|
|
0:49:19
|
because I am only looking at the ascii code
|
|
0:49:21
|
for the lower case d not the upper case D
|
|
0:49:26
|
so similar to like we have on the ASA, when we look at the
|
|
0:49:29
|
the show run all regex
|
|
0:49:34
|
this can give you an idea of what the syntax should look like
|
|
0:49:37
|
when you are dealing with the IPS sensor as well
|
|
0:49:41
|
so if I wanted my match to be case insensitive
|
|
0:49:44
|
I would have to say look for
|
|
0:49:47
|
inside of brackets [ ] look for
|
|
0:49:50
|
uppercase A and lowercase a, look for uppercase P and lowercase p
|
