|
0:00:13
|
in our next section for the ips senor we are going to look at using the remote span or rspan feature
|
|
0:00:19
|
in order to redirect traffic to the sensing interface when we are running in promiscuous mode
|
|
0:00:25
|
now the previous example that we saw when we were running the
|
|
0:00:29
|
span or the switch board analyser
|
|
0:00:32
|
was when the ips 's sensing interface
|
|
0:00:36
|
which again was attached to switch 2
|
|
0:00:39
|
port fast ethernet 0/10
|
|
0:00:43
|
and this was redirecting traffic
|
|
0:00:45
|
from router 5
|
|
0:00:47
|
who has its interface fast ethernet 0/1
|
|
0:00:51
|
which is on fast ethernet 0/5 of switch 2
|
|
0:00:55
|
so here this is a local span session since we are receiving traffic in one port
|
|
0:01:00
|
and simply redirecting it out
|
|
0:01:02
|
the port that is on , another port that is on the same physical box
|
|
0:01:07
|
now for the remote span feature
|
|
0:01:09
|
this would be when the source of the traffic that they were trying to monitor
|
|
0:01:13
|
and the destination that we are reflecting it to or making the copy to
|
|
0:01:17
|
is on a different physical switch
|
|
0:01:19
|
now if we look back at the topology
|
|
0:01:22
|
the session that we are monitoring or the segment that we are monitoring
|
|
0:01:26
|
is this vlan 125 that is between the asa and router 5
|
|
0:01:32
|
now the way that i configured it before we direct this span session
|
|
0:01:36
|
we were looking at this particular port and looking at both the inbound and out bound traffic
|
|
0:01:41
|
we could have also configured it to look
|
|
0:01:43
|
for all traffic in vlan 125
|
|
0:01:45
|
and then do the redirection
|
|
0:01:48
|
but now in this case lets tell it to look at just at the traffic
|
|
0:01:51
|
that asa is 2 is sending out that direction
|
|
0:01:56
|
so any traffic flows may be that would come from the test pc
|
|
0:02:00
|
and go in that direction or anything that is coming from router 4
|
|
0:02:03
|
going in this direction
|
|
0:02:05
|
so this is going to be outbound
|
|
0:02:07
|
from the asa's perspective
|
|
0:02:09
|
which means that from the switch that is actually attached to the asa that is going to be
|
|
0:02:13
|
inbound from their perspective
|
|
0:02:16
|
and specifically this is interface ethernet 0/1
|
|
0:02:21
|
now if we look at the change of what this means in the physical topology
|
|
0:02:25
|
we still have the ips sensor that is
|
|
0:02:27
|
connected on port fast ethernet 10
|
|
0:02:30
|
of switch 2
|
|
0:02:31
|
but then we have asa
|
|
0:02:34
|
2
|
|
0:02:36
|
whose interface
|
|
0:02:38
|
ethernet 0/1
|
|
0:02:42
|
is connected to switch 1
|
|
0:02:45
|
on port fast ethernet 0/13
|
|
0:02:50
|
then we have some sort of trunking between switch 1 and switch 2
|
|
0:02:54
|
now if the goal here is that we want to get the traffic that is going in this direction
|
|
0:02:59
|
so leaving the asa and entering switch 1
|
|
0:03:02
|
i want to make a copy of this on to
|
|
0:03:05
|
the ips's sensing interface
|
|
0:03:07
|
it means that from switch 1's perspective
|
|
0:03:11
|
the source
|
|
0:03:13
|
of the monitoring is going to be a local port
|
|
0:03:16
|
and the destination of the monitoring is going to be the rspan vlan
|
|
0:03:23
|
now the goal of the rspan vlan is to get the traffic to forward
|
|
0:03:26
|
over the trunking between the layer 2 switches
|
|
0:03:30
|
then from switch 2 we are going to say that the source
|
|
0:03:34
|
is the rspan vlan
|
|
0:03:36
|
and the destination is the local port
|
|
0:03:39
|
which the local port is going to be fast ethernet 0/10
|
|
0:03:42
|
which is connected to the sensor
|
|
0:03:46
|
now configuration wise inorder to actually implement this
|
|
0:03:50
|
the first thing that we need to do in the layer 2 switching domain
|
|
0:03:53
|
is define a specific vlan that is going to be used
|
|
0:03:57
|
for the rspan process or the rspan vlan
|
|
0:04:01
|
so just like a normal vlan definition we are going to give it a number
|
|
0:04:05
|
but then we are going to specify this specific attribute which is remote-span
|
|
0:04:09
|
under the vlan mode
|
|
0:04:13
|
now the key with this vlan is that for every
|
|
0:04:16
|
physical switch that is in the transit path from the source
|
|
0:04:19
|
to the destination
|
|
0:04:20
|
we need to make sure that they agree that this is an rspan vlan
|
|
0:04:24
|
because the cam table or the mac address table
|
|
0:04:27
|
is treated differently for an rspan vlan
|
|
0:04:30
|
then it is for a normal vlan
|
|
0:04:33
|
because we are not forwarding traffic really based on the layer 2 destination
|
|
0:04:37
|
we are trying to take all traffic
|
|
0:04:39
|
regard this what the source is or regard this what the destination is
|
|
0:04:42
|
and redirect this to the sensor
|
|
0:04:45
|
so we don't do normal mac address learning like we do on a regular vlan
|
|
0:04:49
|
now we could go to all other the switches on the transit path and manually define this
|
|
0:04:55
|
but we could also advertise this through vtp
|
|
0:04:59
|
but therefore not running vtp that would mean that we need to make sure everyone agrees on this
|
|
0:05:03
|
so either on the vtp server we create the vlan and then specify remote span
|
|
0:05:08
|
or on every switch on a half by half basis we create the vlan and specify
|
|
0:05:12
|
the rspan attribute
|
|
0:05:15
|
now we also need to make sure that
|
|
0:05:17
|
that this vlan is actually forwarding
|
|
0:05:19
|
over the trunking
|
|
0:05:22
|
so if there are more than 2 devices
|
|
0:05:24
|
in the path from the source to the destination
|
|
0:05:26
|
we need to make sure that whatever the rspan vlan number is
|
|
0:05:30
|
is actually forwarding over the link
|
|
0:05:34
|
so lets say for example in this case that we are going to use vlan 919
|
|
0:05:39
|
as the rspan vlan
|
|
0:05:42
|
this means that when switch 1 receives the packets in
|
|
0:05:45
|
i am going to say that the source
|
|
0:05:47
|
on switch 1
|
|
0:05:49
|
is fast ethernet 0/13
|
|
0:05:52
|
and the received traffic
|
|
0:05:56
|
because from the switches perspective
|
|
0:05:58
|
that is the inbound traffic
|
|
0:06:01
|
where from asa 2 is outbound traffic
|
|
0:06:04
|
so atleast the asa is going to be received by the switch
|
|
0:06:08
|
then we are going to say that the destination
|
|
0:06:10
|
is the rspan
|
|
0:06:13
|
vlan 919
|
|
0:06:18
|
so we make a new copy of the pack and on the rspan vlan we then need to make sure that this is forwarded over the trunk
|
|
0:06:25
|
so if we look at the show interface trunk
|
|
0:06:27
|
we need to make sure that this vlan is actually forwarding over that link
|
|
0:06:33
|
now configuration wise beyond this
|
|
0:06:36
|
there is not that much that we need to do
|
|
0:06:38
|
as compared to the regular span sessions versus the
|
|
0:06:41
|
rspan sessions
|
|
0:06:43
|
its more of a design issue that we need to make sure that the layer 2 transit path
|
|
0:06:46
|
is correct to begin with
|
|
0:06:49
|
but in addition to this on the switch that is attached to the source segment
|
|
0:06:54
|
which in our particular case this is going to be switch 1
|
|
0:06:57
|
switch 1 is going to say that the source
|
|
0:07:00
|
is the physical port so monitor session source
|
|
0:07:03
|
this case we are going to say interface
|
|
0:07:06
|
fast ethernet 0/13 and we are going to look for the received traffic
|
|
0:07:11
|
we then specify the destination this is going to be the rspan vlan
|
|
0:07:16
|
we say monitor session destination whats the remote vlan
|
|
0:07:19
|
the number
|
|
0:07:20
|
then certain platforms will require the argument reflective port
|
|
0:07:25
|
which is used to actually encapsulate the packet
|
|
0:07:29
|
or essentially as a physical loop back inside of the switch
|
|
0:07:34
|
now with the reflective port you need to make sure that this is an interface that is not used for another purpose
|
|
0:07:40
|
so if you have a cable plugged into this port
|
|
0:07:42
|
the port is going to be disabled from receiving traffic
|
|
0:07:46
|
now is platform depended whether you actually need this or not
|
|
0:07:49
|
some switches have additional dedicated acs for the rspan process
|
|
0:07:54
|
but if you look at the context sensor help and you see that its asking for the reflective port
|
|
0:07:57
|
then that is going to be required
|
|
0:08:00
|
now this would also imply that from a hardware
|
|
0:08:04
|
limitation point of view
|
|
0:08:05
|
if you wanted to run rspan on the switch
|
|
0:08:08
|
you need to make sure that its not fully populated with all of its ports
|
|
0:08:14
|
so lets say for example you have a 48 port switch with 2 uplinks
|
|
0:08:18
|
if you have all 48 ports
|
|
0:08:20
|
plus the 2 uplinks being used
|
|
0:08:21
|
that you cannot run rspan
|
|
0:08:24
|
assuming that platform needs the reflective port
|
|
0:08:27
|
pretty much any of the newer platforms are not going to need this
|
|
0:08:31
|
now on the switch that is attached to the sensor
|
|
0:08:34
|
or where we were trying to redirect the traffic to
|
|
0:08:37
|
we are then going to specify the source as the vlan
|
|
0:08:42
|
which in our case we will say monitor session 1 source remote vlan is 911 whatever we are defining
|
|
0:08:48
|
then the destination
|
|
0:08:50
|
is going to be defined as the physical port
|
|
0:08:57
|
so lets take a look at this on the command line
|
|
0:08:59
|
first we will go to switch 2
|
|
0:09:02
|
where we had our previous span sessions that was
|
|
0:09:05
|
receiving traffic
|
|
0:09:08
|
that was either coming in or going out fast ethernet 0/5
|
|
0:09:11
|
and then we were making a copy on fast ethernet 0/10
|
|
0:09:16
|
we then also said that the packets come in that interface
|
|
0:09:19
|
they are going to be treated as if they are in vlan 125
|
|
0:09:23
|
and we will look at surely why we would need to do that
|
|
0:09:26
|
when we configure the reset action
|
|
0:09:29
|
or the tcp reset action
|
|
0:09:33
|
from a signature
|
|
0:09:34
|
we need to make sure that the ips sensor can actually generate its own traffic
|
|
0:09:38
|
to go back to the attacker and to go back to the vector
|
|
0:09:43
|
so lets look at our configuration out here lets say show run
|
|
0:09:46
|
include monitor
|
|
0:09:51
|
right here at the monitor session source and the monitor session destination
|
|
0:09:55
|
now identically they don't need to change the destination
|
|
0:09:59
|
its going to be the same as what the previous configuration is
|
|
0:10:02
|
about what is changing on switch 2 is going to be what is the source
|
|
0:10:07
|
the source is no longer going to be an interface
|
|
0:10:11
|
but the source is going to be the remote span vlan
|
|
0:10:16
|
and this is then going to be whatever vlan number that i define
|
|
0:10:20
|
now again remember we do need to define this vlan we need to create it
|
|
0:10:24
|
and issue the remote span keyword
|
|
0:10:28
|
the same is going to be true on switch 1
|
|
0:10:31
|
so i say vlan 999
|
|
0:10:33
|
this is a remote span vlan
|
|
0:10:36
|
if we look at the show vtp status
|
|
0:10:39
|
right now these switches are running in transparent mode
|
|
0:10:43
|
so i do need to define that option on both of them
|
|
0:10:46
|
if one of them was running in server mode i could simply define the vlan there
|
|
0:10:50
|
and then all of the other servers or all of the other vtp clients would learn
|
|
0:10:53
|
that vlan 999 is a remote span vlan
|
|
0:10:58
|
we can see this specific option if we look at the show vlan output
|
|
0:11:02
|
then down under 999
|
|
0:11:05
|
should give us a specific feel that this the remote span vlan
|
|
0:11:12
|
so again now on switch 1 if we look at the show interface status
|
|
0:11:17
|
i have the port that is connected to asas
|
|
0:11:19
|
ethernet 0/1
|
|
0:11:21
|
which is port 13
|
|
0:11:24
|
and then i have
|
|
0:11:26
|
3 different interfaces that are trunks that are going over to switch 2
|
|
0:11:30
|
there are fast ethernet 21 22 and 23
|
|
0:11:34
|
so as along as when i look at the show
|
|
0:11:36
|
spanning tree for vlan 999
|
|
0:11:40
|
as long as that is forwarding over
|
|
0:11:43
|
atleast one of these trunks links
|
|
0:11:45
|
thats really what i care about
|
|
0:11:48
|
that i can't forward the traffic from the source segment of the switch
|
|
0:11:52
|
to the destination segment of the switch
|
|
0:11:57
|
so now i will say monitor session
|
|
0:12:00
|
give it a number this is only locally significant
|
|
0:12:02
|
the source
|
|
0:12:05
|
is going to be on interface so the interface is fast ethernet 13
|
|
0:12:09
|
and i want to say the traffic that is coming in on that port
|
|
0:12:13
|
the monitor session destination
|
|
0:12:17
|
is then going to be the
|
|
0:12:19
|
the remote vlan
|
|
0:12:22
|
remote vlan 999
|
|
0:12:25
|
now you could see this particular platform this is of 3550
|
|
0:12:29
|
it is
|
|
0:12:30
|
now saying thats not the complete syntax if we look at the question mark
|
|
0:12:34
|
this particular platform is asking for reflective port
|
|
0:12:38
|
so i could choose anything here as long as its not something that is already in use
|
|
0:12:43
|
now i know
|
|
0:12:45
|
g 0/1 for example thats not in use
|
|
0:12:50
|
so thats fine if we look at the show
|
|
0:12:53
|
show interface status now
|
|
0:12:57
|
we will see under gig 0/1
|
|
0:13:00
|
it says that the state of this port is monitoring
|
|
0:13:05
|
so if there was a cable actually plugged in here its not going to be of any use
|
|
0:13:09
|
so the switch can no longer receive traffic in that link or send traffic up that line
|
|
0:13:13
|
because its dedicated now to the rspan process
|
|
0:13:20
|
so now lets see if this is actually going to work if we take a look at the topology
|
|
0:13:24
|
ideally what should happen
|
|
0:13:26
|
is that for any packets
|
|
0:13:28
|
that get to the asa and then go out
|
|
0:13:30
|
this interface
|
|
0:13:32
|
once it gets to switch 1
|
|
0:13:35
|
switch 1 is going to make a copy to switch 2
|
|
0:13:39
|
switch 2 is then going to reflect this
|
|
0:13:41
|
to the ips's sensing interface
|
|
0:13:47
|
just like we did in the previous example by using the span feature
|
|
0:13:51
|
if we were to enable any of the signatures and enable login on the ips
|
|
0:13:56
|
i want to see
|
|
0:13:57
|
if an alert is generated
|
|
0:13:59
|
when one of these signatures are triggered
|
|
0:14:03
|
where some of the basic ones again that we can enable
|
|
0:14:06
|
signature number 2000
|
|
0:14:08
|
and 2004
|
|
0:14:11
|
these are for our icmp pings
|
|
0:14:15
|
and we could see that from the ibm
|
|
0:14:17
|
so if we go back to the interface
|
|
0:14:21
|
of the sensor if we go configuration
|
|
0:14:25
|
then under signature definitions i have signature
|
|
0:14:29
|
engine 0 or 60
|
|
0:14:32
|
then if i scroll down in the 2000 range
|
|
0:14:37
|
signature 2000 is echo reply
|
|
0:14:39
|
signature 2004 is echo request
|
|
0:14:43
|
signature 2000
|
|
0:14:44
|
is 2004 i should say is enabled
|
|
0:14:48
|
which is the echo request thats enabled
|
|
0:14:51
|
it says that if this is triggered
|
|
0:14:54
|
the action is that i am going to produce an alert
|
|
0:14:58
|
so i am not dropping any of the packets i am just generating a log message
|
|
0:15:02
|
it also says that the type here is tuned
|
|
0:15:05
|
which means that i have changed something that was previously the default
|
|
0:15:09
|
and basically what i changed is this that i just turned the signature on
|
|
0:15:14
|
that previously it was disabled and now i have enabled it
|
|
0:15:17
|
if this sensors actually receiving the packet
|
|
0:15:20
|
we can see this from the groe ??? interface if we go to monitoring
|
|
0:15:25
|
then i can view the events
|
|
0:15:28
|
but the problem is here lot of the time you are going to get
|
|
0:15:31
|
all sorts of events that you don't need
|
|
0:15:34
|
so we can limit this based on the type
|
|
0:15:37
|
like i could say whats the
|
|
0:15:39
|
the specific alert type may be i want only medium and high alerts
|
|
0:15:45
|
i could also say based on the time
|
|
0:15:48
|
if i say show all of them this is going to be unless there is everything thats in the sensor
|
|
0:15:54
|
so what i am going to do next is go to the command line
|
|
0:15:57
|
of the sensor
|
|
0:16:00
|
and issue the clear advance
|
|
0:16:03
|
and this is going to remove everything from the event line
|
|
0:16:08
|
so now from the command line if we look at show events
|
|
0:16:12
|
or if i were to go to
|
|
0:16:15
|
now back to the groe ??? interface and say show all events
|
|
0:16:21
|
we see the ones that it is
|
|
0:16:24
|
the ones that it is generating is saying
|
|
0:16:26
|
the tls connection exception the handshake is incomplete for a web session
|
|
0:16:31
|
this is
|
|
0:16:33
|
related to my management session here from the groe ?? interface
|
|
0:16:37
|
where this
|
|
0:16:39
|
this message is an error
|
|
0:16:41
|
so what i am going to do here is remove
|
|
0:16:45
|
the error messages
|
|
0:16:49
|
and view the events
|
|
0:16:51
|
so now this is going to show me basically just the signatures that are being triggered
|
|
0:16:57
|
from the command line i could get that same effect if i were to say
|
|
0:17:00
|
show events
|
|
0:17:03
|
but then just show me the alerts
|
|
0:17:06
|
so i don't want the error messages i just want the alerts
|
|
0:17:10
|
then if i were to go to someone else on the topology then lets say we go to router 1
|
|
0:17:14
|
and send a ping
|
|
0:17:16
|
down this way lets say i ping router 6's address
|
|
0:17:20
|
i should see then that the sensor
|
|
0:17:22
|
things that router 1 is the attacker
|
|
0:17:26
|
and that router 6 is the victim
|
|
0:17:29
|
and we should see the log message appeared
|
|
0:17:31
|
so if i ping 10.0.6.6
|
|
0:17:36
|
look at the sensor
|
|
0:17:38
|
its not getting any alerts
|
|
0:17:42
|
if i were to go to the
|
|
0:17:45
|
web interface and refresh this
|
|
0:17:49
|
its not receiving anything
|
|
0:17:52
|
so either this means that there is something wrong with my sensor config
|
|
0:17:56
|
or may be it doesn't
|
|
0:17:58
|
have the correct interface applied or may be the virtual sensor is applied on the physical interface
|
|
0:18:03
|
or it could be something that is related to
|
|
0:18:06
|
the rspan sessions
|
|
0:18:10
|
so lets take a look back at the switch here
|
|
0:18:13
|
and go to some other basic troubleshooting steps to figure out
|
|
0:18:16
|
is the span session working to begin with
|
|
0:18:21
|
so on switch 1 lets look at the show monitor session
|
|
0:18:25
|
is monitor session 1
|
|
0:18:28
|
it says that the traffic coming in is going to be on fast ethernet 0/13
|
|
0:18:34
|
its going to be
|
|
0:18:36
|
sent to the rspan vlan which is 999
|
|
0:18:40
|
and its going to use gi0/1
|
|
0:18:42
|
to encapsulate this
|
|
0:18:45
|
so basically the switch is using that gig interface just as a loop back
|
|
0:18:49
|
where the packet goes
|
|
0:18:51
|
to the gig interface
|
|
0:18:53
|
then gets encapsulated on to
|
|
0:18:55
|
the rspan vlan
|
|
0:18:58
|
now assuming that fast ethernet 0/13 is the correct interface
|
|
0:19:03
|
where here the description says it is
|
|
0:19:06
|
asa 1's
|
|
0:19:07
|
e0/1
|
|
0:19:09
|
this is actually the
|
|
0:19:11
|
the issue here
|
|
0:19:13
|
that it should be asa 2
|
|
0:19:17
|
so this section should be fast ethernet 0/15 not 13
|
|
0:19:21
|
so lets update that
|
|
0:19:25
|
here that should say 15
|
|
0:19:31
|
so now we need to change the
|
|
0:19:34
|
the monitoring
|
|
0:19:35
|
lets show do show run include
|
|
0:19:38
|
monitor
|
|
0:19:43
|
where is the source is not 13
|
|
0:19:47
|
source should be 15
|
|
0:19:52
|
ok so now lets look at the
|
|
0:19:55
|
the sensor again i want to see is it going to get these alerts
|
|
0:19:58
|
on router 1 we will generate the packets again
|
|
0:20:01
|
now the sensor is receiving them
|
|
0:20:05
|
specifically it says
|
|
0:20:08
|
that there was an icmp echo request
|
|
0:20:10
|
that came from router 1
|
|
0:20:13
|
and went to router 6
|
|
0:20:16
|
so 6 is considered the target or the victim here router 1 is the attacker
|
|
0:20:21
|
now again when i am actually doing anything other than generating an alert to a log message
|
|
0:20:27
|
once this signature is triggered
|
|
0:20:30
|
because when we look at the idn
|
|
0:20:33
|
the web interface and go back to the configuration
|
|
0:20:36
|
then the signature engine
|
|
0:20:40
|
go down to signature 2000
|
|
0:20:44
|
or 2004 specifically
|
|
0:20:47
|
and if we double click on this
|
|
0:20:49
|
and go to lets say edit
|
|
0:20:53
|
we will see all the specifics about this signature
|
|
0:20:56
|
but when we look at the event actions
|
|
0:21:00
|
right now the event action is just to produce an alert
|
|
0:21:04
|
not to do anything else
|
|
0:21:10
|
now these specific event actions
|
|
0:21:13
|
are going to be controlled
|
|
0:21:15
|
based on whether we are running in promiscuous mode
|
|
0:21:18
|
or we are running in inline mode
|
|
0:21:22
|
now the ones thats say inline
|
|
0:21:24
|
obviously you can only use those if you are running in inline mode
|
|
0:21:27
|
but the other ones like producing an alert
|
|
0:21:29
|
producing a reverse alert
|
|
0:21:32
|
which has more information than the regular one
|
|
0:21:34
|
are request to block the connection or request to block the host
|
|
0:21:37
|
the snyp trap or the tcp reset
|
|
0:21:40
|
these are the ones that we can do
|
|
0:21:43
|
when we are running in promiscuous mode
|
|
0:21:48
|
then when we are running in inline mode
|
|
0:21:52
|
these are the ones that we can do where we can deny the attacker
|
|
0:21:55
|
the service or the victim pairs these would be like the port numbers and the protocol numbers
|
|
0:22:00
|
the
|
|
0:22:02
|
login that is either going to be for syslog
|
|
0:22:05
|
or for the alert messages that the idm
|
|
0:22:09
|
is receiving
|
|
0:22:14
|
so we look back to these on a little bit looking at the more specifics of the signatures
|
|
0:22:18
|
but the key now is that if we go to the monitoring
|
|
0:22:21
|
then look at the advance
|
|
0:22:23
|
we do see that those echo requests were received
|
|
0:22:30
|
so now we know we can get either variation working in the local span
|
|
0:22:34
|
which is the
|
|
0:22:36
|
monitor session and the destination on the same physical switch
|
|
0:22:40
|
or the remote span
|
|
0:22:42
|
or the source segment they were trying to monitor
|
|
0:22:45
|
and the destination segment are on 2 different switches
|
|
0:22:50
|
now the other feature that we could configure here in addition
|
|
0:22:53
|
to the remote span
|
|
0:22:55
|
if we were to go to the switch that is the source segment
|
|
0:22:59
|
which is switch 1 if we look at the
|
|
0:23:02
|
the show run include
|
|
0:23:04
|
include monitor
|
|
0:23:10
|
it says that the
|
|
0:23:12
|
source interface is fast ethernet 0/15
|
|
0:23:16
|
although the traffic it is being received there
|
|
0:23:19
|
and the destination is the remote span vlan
|
|
0:23:24
|
so again when we look at the physical
|
|
0:23:26
|
topology
|
|
0:23:28
|
it means that the traffic is coming in from asa 2
|
|
0:23:31
|
its going to switch 1
|
|
0:23:33
|
then switch 1 is redirecting and it is going in this direction
|
|
0:23:38
|
however if we corelate this with the logical diagram
|
|
0:23:43
|
notice that the interface and the asa that we are monitoring
|
|
0:23:47
|
if actually a sub interface
|
|
0:23:50
|
where ethernet 0/1 is not only used for the inside
|
|
0:23:55
|
but it is also being used for the dmz
|
|
0:24:00
|
so technically what this means is that the asa's traffic that is going this direction
|
|
0:24:05
|
in addition to traffic going that direction
|
|
0:24:08
|
both of these are going to be redirected to the sensor
|
|
0:24:13
|
now the way that we can tell this if we were to go to
|
|
0:24:16
|
one of the devices on the outside lets say router 2
|
|
0:24:19
|
and lets ping the acs server
|
|
0:24:22
|
and see if the signatures are being triggered
|
|
0:24:25
|
on the sensor
|
|
0:24:29
|
so right now the sensor is not getting any
|
|
0:24:31
|
alerts
|
|
0:24:33
|
if we go to router 2 and ping
|
|
0:24:35
|
10.0.0.100
|
|
0:24:39
|
we see that the sensor is receiving those as well
|
|
0:24:45
|
whether this is an issue really depends on the design
|
|
0:24:49
|
so do i want to monitor just
|
|
0:24:51
|
the vlan 125
|
|
0:24:53
|
or do i also want to monitor the
|
|
0:24:55
|
monitor this vlan 10 segment
|
|
0:24:58
|
if i want to monitor both of the them its not going to be any additional configuration
|
|
0:25:03
|
but lets say now i want to constrain
|
|
0:25:05
|
the remote span
|
|
0:25:07
|
so that i am only catching the traffic that is going this way
|
|
0:25:10
|
not the traffic that is going upto vlan 10
|
|
0:25:15
|
and the way that we can do this is by applying a filter
|
|
0:25:19
|
on switch 1 to the source traffic that we are receiving
|
|
0:25:26
|
so if we look at the monitor session command
|
|
0:25:29
|
monitor session 1
|
|
0:25:31
|
i want to apply a filter
|
|
0:25:35
|
that says the span source vlan is just going to be vlan 125
|
|
0:25:40
|
and i could also specify a range
|
|
0:25:42
|
or discontinuous vlans
|
|
0:25:45
|
but now when we look at show run
|
|
0:25:47
|
include monitor
|
|
0:25:51
|
since the interface that is coming in is a trunk
|
|
0:25:55
|
there is multiple vlans being received in them
|
|
0:25:58
|
i am saying filter it so that only the vlan 125 encapsulated packets are received
|
|
0:26:03
|
what we should now see is that when we send the traffic
|
|
0:26:06
|
from router 2
|
|
0:26:08
|
to the acs server
|
|
0:26:10
|
and then from router 2
|
|
0:26:12
|
to 6
|
|
0:26:14
|
only the packet that was
|
|
0:26:16
|
going to router 6 is going to be logged
|
|
0:26:22
|
so lets go to the idm lets refresh these logs
|
|
0:26:29
|
now if we look at the details of any of these
|
|
0:26:33
|
the last one it says it came from to
|
|
0:26:36
|
and it was going to 100
|
|
0:26:42
|
so now lets go to router 2
|
|
0:26:45
|
and lets ping router 6
|
|
0:26:48
|
ping 10.0.6.6
|
|
0:26:52
|
if we refresh the log we see there is a new one in there
|
|
0:26:55
|
says this one was coming from 2
|
|
0:26:58
|
going to 6
|
|
0:27:02
|
if we ping
|
|
0:27:04
|
the acs server 10.0.0.100
|
|
0:27:08
|
and then refresh these logs again
|
|
0:27:12
|
notice that we do not receive a sixth log
|
|
0:27:17
|
and if we look at this on the command line on the ips and look at the alerts
|
|
0:27:20
|
we got the one to router 6
|
|
0:27:24
|
but we did not get the one thats going to
|
|
0:27:26
|
the acs server
|
|
0:27:32
|
so the key with this configuration or the filtering
|
|
0:27:35
|
you would really only need to do this if the interface that you are monitoring
|
|
0:27:39
|
is a trunk link to begin with
|
|
0:27:42
|
if it is just an access port then there is only one vlan that is going to be on whatever the access vlan is
|
|
0:27:49
|
now documentation wise this is going to be under
|
|
0:27:53
|
the careless ??? ios documentation
|
|
0:27:58
|
so if we go the main documentation page
|
|
0:28:02
|
this is going to be under products
|
|
0:28:04
|
switches
|
|
0:28:07
|
lans switches for access
|
|
0:28:09
|
in the case of the ccie security lab exams right now they are using 3560s
|
|
0:28:15
|
then under configuration guides
|
|
0:28:18
|
the particular software version
|
|
0:28:22
|
then under span and remote span
|
