I am new in this, so I need some help if you dont mind...I need to configure an IDS in a network with many VLANS. I asked some pals about that and someone told me that the only way to do this is by configuring one port monitor in the switch for each VLAN. I dont know if this is correct 'cause I remember have read in some magazine about the "mirror port" in many switches but I dont know if is the same thing and if I can use it in Catalyst Switches (I guess in some models...).
I hope you can help me 'cause this is very importnat in my design.
BTW is also important to me to know if an IDS can help me to detect and kill Code Red/Nimda attacks?
There are two approaches to this problem. First, the "port mirror" is called a SPAN in Cisco parlance. A SPAN can source ports and vlans to a target output port. The destination (output) port of the span will output all the traffic from the source ports "as is"..i.e. you don't have any idea where the traffic came from (port/vlan). The other approach is to use a "trunk" line, where the source vlan information is encoded in the packets put on the trunk. This requires an IDS that knows how to parse the trunking information to get to the packet data. Currently, Cisco IDS' do not do anything with the trunking information (they will eventually), but can correctly parse it. The SPAN method is "old school" and is limited(going forward) by the aforementioned anonymizing(if thats a word) of the source and by the fact that SPAN sets are very limited on most switches(Cat5 has 1 tx/rx span, Cat6 has 2 tx/rx). The new technology can be seen in the Cat6 family of switches. The Cat6 running CatOS can also do a "copy/capture" based on a security acl (see the "set security acl" command(s)). The security acl's use destination ports that can be configured as trunks to allow combined traffic output. You can also use the trunk "traffic coloring" capability and different security acls to filter the traffic you send to your IDS. A similar capability is available in the recent CatIOS releases as well.
Yes, the Cisco IDS can help with CodeRed/Nimda. See older posts in this forum for more information. I can't speak for other IDS's, but most good ones should be able to help as well.
A little bit of clarification from experience using the Cat 6K.
The scenarios I note below have been tested with the Cat 6K, but may not be true for all Cisco switches or other competitor switches. You would need to verify with your specific switch if not using a Cat 6K.
There are 2 types of ports when it comes to vlans:
1) Access port - an access port belongs to only a single vlan, packets transmitted out this port are never encapsulated in trunking headers. Trunking headers are used to tell other devices on what vlan a particular packet should be placed on.
2) Trunk port - a trunk port can carry traffic from multiple vlan. The port is typically assigned to a primary vlan known as the Native vlan of the trunk port. When packets are transmitted out the trunk port, if the packet is on the Native vlan then the trunking header is not added, but if the packet is on other vlans then a trunking header is added to tell the device which vlan the packet is from.
The IDS-42xx appliances can have their sniffing port configured as either an Access port or a Trunk port when connected to the switch.
The IDSM (IDS Module for Cat 6K) will have it's sniffing port always configured as a trunk port.
The trunking protocol supported by both IDS-42xx and IDSM is referred to as dot1q; they do not support other trunking protocols such as ISL.
NOTE: Though ISL is not supported to the sensors, the sensors have no problem monitoring packets that are being transmitted between switches using ISL trunks.
There are then 2 different ways to send traffic to the sniffing port:
1) SPAN - Spanning is Cisco terminology for port mirroring. It is the monitor command when using Cat IOS.
If the IDS-42xx sniffing port is connected to an Access port and a span is setup to send packets to that port. Then all of the packets will be seen by the IDS-42xx without trunking headers regardless of whether a single vlan or multiple vlans are being spanned. The IDS-42xx will believe that all of the packets are on the same vlan and will treat them as such.
If the IDS-42xx or IDSM sniffing port is configured as a dot1q Trunk port and a span is setup to send packets to that port. Then all of the spanned packets from the Native vlan of the trunk will be seen without trunking headers. Spanned packets from any other vlan will be seen with dot1q headers.
2) Capture feature of the Vlan ACL.
The Catalyst 6000 has a feature in it's Vlan ACL which allows the switch to mark certain packets (depending on protocol, or ip address combinations) as captured packets. The packets are then copied to any ports in the switch that have been marked as capture ports.
The difference here is that the switch will not only look to see whether or not the port is an Access port or a Trunk port, but also which vlans are allowed on the port, unlike the Span feature which sends the packets regardless of what vlans were assigned to the port.
If the IDS-42xx sniffing port is connected to an Access port and is configured as a Capture port, then the switch will only send the sniffing port the packets marked as captured that are on the exact same vlan as the sniffing port.
If the IDS-42xx or IDSM sniffing port is configured as a dot1q Trunk port (this time we assign specific vlans to the trunk port) and is configured as a Capture port, then the switch will only send the sniffing port the packets marked as capture that are on the same vlans as those assigned to the trunk port. All of the captured packets from the Native vlan of the trunk will be seen without trunking headers. Captured packets from any other assigned vlan will be seen with dot1q headers. Captured packets from vlans not assigned to the trunk will not be seen by the sensor.
A) Span has a typical limit of only one or two Span sessions in the switch. The VACL Capture feature can be applied to every vlan, and have a seperate capture port for each vlan if desired. So VACL Capture does not have the typical 2 port limit of Span.
B) Current sensor versions do not use the dot1q header information for analysis or keeping traffic separate when tracking connections. Future sensor versions might. So for now the dot1q header is providing no additional information to the sensor.
C) When multiple vlans are being monitored, TCP Resets will only work for connections on the same vlan as the Access port, or the Native vlan of the trunk port.
D) If you will be using the IDS-42xx attached to a trunk port, then you will need to contact your local Cisco Representative. He/she will need to contact IDS project management for a Engineering driver for the sniffing interface. The dot1q headers will increase the mtu size of hte packets beyond what the normal sniffing interface will allow. So our engineering team created a special NIC driver for the sniffing interface to handle these larger packet sizes.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...