String.TCP doesn't work for 3550-routed traffic !?

[ovt]

Hi!

We have 3550 switch that also routes traffic between 2 VLANs ("outside" and "inside"). I've configured VSPAN for the "outside" VLAN to send ingress traffic to the IDS 4210 sensor (with the latest 4.1 software). To test the configuration I've created custom Atomic.TCP signature that fires when the string "ABC" is seen by the sensor. This works well for traffic going within the "outside" VLAN as well as for routed traffic.

The problem is with the String.TCP test signature that should fire for the same "ABC" string. This signature doesn't fire for routed traffic. I checked it multiple times with the netcat and observed the following:

- 2 alrams (String.TCP and Atomic.TCP) for switched traffic;

- only 1 alarm for routed traffic.

Also, protocol analyzer on the SPAN port shows that packets are copied to the SPAN port. No summarization is in effect. String.TCP signature parameters are as follows:

- AlarmThrotle = FireAll

- Direction = ToService

- ServicePorts = 23

- RegexString = ABC

- ResetAfterIdle = 15 (doesn't matter?)

- StorageKey = STREAM

- Protocol = TCP

- SummaryKey = AaBb (doesn't matter?)

- ThrottleInterval = 15 (doesn't matter?)

Am I missed something here? Did anybody faced with the same strange problem?

Oleg Tipisov,

REDCENTER,

Moscow

[ovt]

The problem solved: for STREAM signatures sensor should see all the returning traffic, so VSPAN should be enabled for the "inside" VLAN as well.

[scothrel]

disregard my other response, I didn't see this message until after I sent it.

SC

[marcabal]

A brief explanation of what is happening:

There is some funky interaction between routing and the VSPAN feature.

The VSPAN feature can be treated as a short hand for doing a span on all physical ports in the vlan.

The key here is that it is the physical ports, and not the logical router interface on the vlan that is being spanned.

So lets say you do a VSPAN for RX traffic on vlan 100.

Machine A is connected to port 1/1 on vlan 100 and the switch will route between vlan 100 and vlan 200 where machine B is connected to port 2/1 on vlan 200.

The packet from A->B enters the switch on 1/1 vlan 100. The packets is a RX span and is spanned to the sensor.

The packet is routed to vlan 200 and sent out port 2/1 to B.

The packet from B->A enters the switch on 2/1 vlan 200. The packet is a RX packet on vlan 200 so is not spanned. The packet is routed from vlan 200 to vlan 100 (but because it is routed the packet is not seen as an RX packet on vlan 100 and is not spanned).

The packet is sent out port 1/1 to A.

So in the end the sensor only sees packets from A->B and won't see packets from B->A.

(Note: There are dew exceptions where occasional B->A packets may be seen but these should not be relied on).

Why does only seeing A->B traffic prevent the STREAM signatures from firing?

This is because the STREAM signatures rely on the TCP Stream Reassembly feature in the sensor.

The TSP Stream Reassembly feature by default will NOT analyze packets for a TCP connection unless it has seen the 3 way handshake.

Since the sensor is not seeing the SYN|ACK packets from B->A the sensor has not seen the 3 way handshake and will not analyze the remainder of the packets in the connection.

So how do you get the B->A packets to be sent to the sensor?

1) Option 1 you have already figured out. That is to do the corresponding RX VSPAN on the other vlan. (OR if using TX you could do a TX VSPAN on both vlans)

2) Option 2 is to use port based span rather than a vlan based span. You could do a BOTH (TX+RX) on one or more ports instead of on the vlan. If your switch is connected to a Firewall, then the best solution is to do a BOTH Span on the Firewall port.

[scothrel]

Oleg,

could you also post your SPAN configuration. This sounds like possibly a direction or selection of the traffic issue.

SC