I have only one IDS and want to know if its possible to monitor all VLANs.

[sguerrero]

With the only one IDS I have I want to know if it is possible to monitor all my VLANs in the network. I am using IDS version 4 and VMS MC 1.1.

If I have to define my internal addresses and those I define as internal are considered trusted, in the case I configure a port in my central switch to monitor all VLANs in my network and connect the IDS to the destination monitor port to sniff all VLANS, which VLANS would I consider as internal?

Also, I have switches catalyst 6006 and 6509 with version 5.1(3) and 12.1 in each case, can I apply shunning to take acctions when an attack is detected?

Is it possible this configuration?

Thanks for any help-

[marcabal]

The sensor has no problem handling multiple vlans (or even all of the 4096 vlans possible) as long as the aggregate traffic from all of these vlans is less than the performance rating for that sensor.

Each sensor model is rated for a particular bandwidth. You will need to find out the bandwidth of the traffic going through your switch. If this bandwidth is less than the sensor's rated performance then you will likely be fine and can span all of the traffic to the one sensor. If this bandwidth is more than the sensor's rated performance then you should not attempted to monitor all of that traffic with that sensor. You will either need to upgrade to a higher performing sensor, determine a way to split monitoring between 2 sensors, or configure the switch so only certain traffic (less than sensor's rated performance) is sent to the sensor.

Caveat to be aware of:

If you are using 2 switches, then you may need to use RSPAN if you want the sensor to see the traffic from both switches.

As for Internal Network configuration, this is entirely up to you. Designating Internal networks does not affect the way the sensor analyzes the packets, and you coudl even run fine without designating any internal networks.

The only things the sensor does with your internal network is settings is mark addresses with either the word IN (to designate an address in the internal network), or the word OUT (to designate an address outside of your internal network). This is not for the sensor's analysis, but instead simply an aid in helping users to determine if they are being attacked from the internet, or if one of their own machines is doing the attacking.

If your switches carry internal traffic as well as traffic from the internet (like from users browsing the web) then you may want to go ahead and list ALL of your internal network ip addresses. In many cases this may be as easy as simply listing the entire 10.0.0.0 network if all of your internal networks are 10.0.0.0 subnets.

If your switches ONLY carry internal traffic, and not traffic from the internet, then you may choose to declare the ipaddress of your main servers as the Internal Network. Then you can tell if users are attacking each other's machines, or if they are attacking your main servers.

As for shunning, yes you can apply shunning. You can choose to apply shunning using Vlan ACLs (VACLs) directly on the supervisor configuration, or you can choose to do shunning on the Vlan interfaces of the MSFC using traditional Router ACLs (RACLs).

If you choose to shun with VACLs then you will need to determine which vlan for the IDS to create VACLs on. You may choose to configure the IDS to create VACLs on the Vlan connecting to the internet firewall, the vlan for your main servers, or you could even configure it for ALL of the vlans.

If you choose to shun with the traditional RACLs on the MSFC then you will need to decide on which vlan interface to configure the shunnning, as well as which direction. You could configure it in the IN direction on the vlan interface to your fireall, or the IN direction to the vlan interface to your main servers, or any combination of IN/OUT and vlan interfaces.

You need to be aware that just because the sensor can monitor multiple vlans, does not mean it does shuns based on which vlan the attack was seen. If your configure the sensor to shun with a VACL on vlan 100, and attack from 10.1.1.1 is seen on vlan 200, the VACL denying 10.1.1.1 will be put on vlan 100. So you need to make some intelligent decisions when deciding where shunning will take place.

You may even choose to do both VACL shunning on the supervisor for some vlans, and RACL shunning on the MSFC for the same or other vlans.

NOTE: The sensor can be configure to shun on both switches and/or both supervisors.

[sguerrero]

Thanks for your answer, it is very clear, in addition, I would like to ask this:

If the customer does not want to apply a rule for downloading for instance active X codes, and one of the stations gets a software from which he could permit access from a no trusted network to his equipment, with the monitoring I would enable for all VLANs, Could it be possible to detect this kind of attack? If it is not possible, what other mecanism could I implement?

I do really appreciate your help.

[sguerrero]

My last question: I am using catalyst 6509 in one location with IOS version 12.1(8a)3 and in other location catalyst 6009 with CATOS version 5.3. In order to take actions while detecting an attack (I mean, reset port, inject blocking -with VACLs, etc), Do my actual versions permit this accions to be sent from my IDS (running ver 4.0, VMS 1.1) to my actual switches with these versions?

Also, I would like to mention that any of the switches have PFC or MSFC.

If I don´t have these, any way, can I configure a reaction from my IDS to control the attack?

Thanks so much for any comment ..

[marcabal · Accepted solution]

I am not sure if the IDS will detect the specific activity you mentioned. You would need to look through our list of signatures to see if it is possible. You may even want to submit a fresh posting and ask that specific question again.

As for actions.

Cat OS 5.3 should allow you to be able to inject TCP Reset packets in through a span port (requires the inpackets enable parameter).

As for blocking with Cat OS 5.3, I don't think that version supports VACLs. You may need to upgrade the Cat OS version if you want to block with VACLs, and you would also need either a PFC or an MSFC on the supervisor.

NOTE: If you have an MSFC doing routing you could also block with traditional Router ACLs on the MSFC.

On the 6509 running native IOS (where IOS instead of the traditional CatOS is run on the supervisor) there may be a problem with TCP Resets. I am not sure if the monitor port (native IOS equivelant of span port) will allow the incoming TCP Resets. You would have to look through the documentation.

Some versions of native IOS (I believe newer versions than what you have) will also allow you to monitor through the capture feature of Vlan ACLS. If the sensor is monitoring through a VACL Capture port instead of a monitor port then I believe the TCP Resets will work OK, but I haven't tested it.

With native IOS the sensor supports blocking with traditional Router ACLs, it does not support blocking with Vlan ACLs in native IOS.

NOTE: The difference between Router ACLs and Vlan ACLs is that the Vlan ACL is applied to the vlan and applies to all packets comining and out of the Vlan. While the Router ACL is actually applied to the INTERFACE of the Vlan where an IP has been assigned and only applies to packets Routed in or out of the Vlan.

NOTE: Native IOS requires that the supervisor have an MSFC to even load the image.