cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1674
Views
10
Helpful
15
Replies

using alternate tcp reset interface

sebastan_bach
Level 4
Level 4

hi i am new to cisco ips. can someone pls tell me the function of use alternate interface for tcp reset.

say i have 2 interfaces for the ips. one command and control interface and other is a interface running in promiscious mode.

without this command can the ids send tcp resets. or does it uses a another interface for tcp resets.

can someone pls tell me.

regards

sebastan

1 Accepted Solution

Accepted Solutions

marcabal
Cisco Employee
Cisco Employee

Under most installations the alternate tcp reset interface is not needed.

By default the TCP resets will go back out the same interface where the attack was detected.

So if your promiscuous interface is connected to a 100Mbps hub for monitoring then the tcp resets will be sent back out that same promiscuous interface into the hub.

Or if your promiscuous interface is connected to the span port of a switch, then the tcp resets will be sent back out the same promiscuous interface into that span port.

The issue becomes no whether the sensor can send the tcp resets, but if the switch will accept them. Many switches Will accept tcp resets coming in from the span port. Some switches just require an extra parameter on the span configuration to tell the switch to allow incoming packets from the span port.

BUT there are some switches that do NOT allow incoming packets from their span ports.

These ituations are the reason for the alternate tcp reset interface configuration.

It requires having 2 sensing interfaces (one for promiscuous monitoring, and the the other used as just the alternate tcp reset interface). The command and control port can NOT be used as the alternate tcp reset interface.

You connect the promiscuous interface up to the span port of the switch. You configure the second interface as the alternate tcp reset interface of the first promiscuous interface. Then plug the second interface into the saem switch (but do Not make the 2nd one a span port).

Now when the sensor detects an attack on the 1st interface it will NOT send the tcp resets out the 1st interface, but instead will send out the tcp resets on the 2nd interface.

Since the switch won't accept the tcp resets from the span port you need the second interface to get the tcp resets into the switch.

This can also be done with taps where the taps (because taps have no means of accepting incoming packets).

The alternate tcp reset interface configuration is ignored when configured for inline monitoring. It is only used with promiscuous monitoring.

View solution in original post

15 Replies 15

marcabal
Cisco Employee
Cisco Employee

Under most installations the alternate tcp reset interface is not needed.

By default the TCP resets will go back out the same interface where the attack was detected.

So if your promiscuous interface is connected to a 100Mbps hub for monitoring then the tcp resets will be sent back out that same promiscuous interface into the hub.

Or if your promiscuous interface is connected to the span port of a switch, then the tcp resets will be sent back out the same promiscuous interface into that span port.

The issue becomes no whether the sensor can send the tcp resets, but if the switch will accept them. Many switches Will accept tcp resets coming in from the span port. Some switches just require an extra parameter on the span configuration to tell the switch to allow incoming packets from the span port.

BUT there are some switches that do NOT allow incoming packets from their span ports.

These ituations are the reason for the alternate tcp reset interface configuration.

It requires having 2 sensing interfaces (one for promiscuous monitoring, and the the other used as just the alternate tcp reset interface). The command and control port can NOT be used as the alternate tcp reset interface.

You connect the promiscuous interface up to the span port of the switch. You configure the second interface as the alternate tcp reset interface of the first promiscuous interface. Then plug the second interface into the saem switch (but do Not make the 2nd one a span port).

Now when the sensor detects an attack on the 1st interface it will NOT send the tcp resets out the 1st interface, but instead will send out the tcp resets on the 2nd interface.

Since the switch won't accept the tcp resets from the span port you need the second interface to get the tcp resets into the switch.

This can also be done with taps where the taps (because taps have no means of accepting incoming packets).

The alternate tcp reset interface configuration is ignored when configured for inline monitoring. It is only used with promiscuous monitoring.

hi buddy thanks a lot once again. u have written down the concept so nicely even a dumb guy can understand it easily.

i have lots of doubts regarding ips. will surely look forward for ur answers.

regards

sebastan

hi buddy,

I study a lot of from you. However, I have many questions to ask you:

This is the configuration:

Catalyst 6513 + IDSM-2

IDSM-2 has 2 sensing interface: interface 7 and interface 8

This is the configuration on Catalyst 6513

intrusion-detection module 3 management-port access-vlan 3

intrusion-detection module 3 data-port 1 capture

intrusion-detection module 3 data-port 1 capture allowed-vlan 2-4,8,10

intrusion-detection module 3 data-port 1 capture allowed-vlan 1002-1005

1) how can I know what interface is in promiscuous?

2) how can I connect promiscuous interface to span port of switch?

3) when I configure tcp reset for interface 8, how can I test the function of tcp reset to know it acts or not?

Thank you very much. I manage IDSM but I don't have knowledge about it. Please answer me early.

When dealing with an Appliance it is fairly obvious that you have a sensor interface with a wire plugged into a corresponding switch port. You have to use commands in the IPS CLI to configure the sensor interface, and use commands in the Switch CLI to configure the corresponding switch port.

When dealing with the IDSM-2 you need to understand that you have a similar situation. You have the sensor interface that is hard wired to a switch port.

In the case of the IDSM-2 the GigabitEthernet0/7 sensor interface is hardwired to the "intrusion-detection module data-port 1" switch port.

And the GigabitEthernet0/8 sensor interface is hardwired to the "intrusion-detection module data-port 2" switch port.

When you want to do promiscuous monitoring you must configure both the sensor interface and the corresponding switch port.

To configure the sensor interface for promiscuous monitoring you need to login to the IDSM-2 CLI and run "setup" and add the GigabitEthernet0/7 AND/OR the GigabitEthernet0/8 interfaces to the virtual sensor "vs0" as promiscuous interfaces.

Then you need to configure the corresponding switch ports within the switch CLI.

In your example commands you have set "data-port 1" as a "capture" port.

This is ONE method of correctly setting the switch port as a promiscuous port.

(NOTE: When using "capture" be sure you have also created the Vlan ACL that marks the packets for capture.)

So with your current set of commands the switch is correctly configured for "data-port 1" as a promiscuous port, and you just need to ensure in the IDSM-2 CLI that GigabitEthernet0/7 has been added to virtual sensor "vs0".

As for your question about span, lets assume you want to use the other sensor port for span.

The other sensor port is "data-port 2" in the switch configuration and "GigabitEthernet0/8" in the IDMS-2 configuration.

On the switch create a "monitor" session with the source ports or vlans that you want monitored.

Then set "data-port 2" as the destination port for that "monitor" session.

Example:

"monitor session 1 destion intrusion-detection-module 3 data-port 2"

Now in the IDSM-2 CLI run setup and add GigabitEthernet0/8 to virtual sensor vs0 as a promiscuous interface.

(NOTE: Alternatively you could have put "data-port 1" as the span destination and added GigabitEthernet0/7 to virtual sensor vs0)

(NOTE: Both VACL Capture ports and Span destination ports can be used for Promiscuous monitoring. You can decide which of the 2 methods to use.)

As for TCP Resets.

Understand that the IDSM-2 has an internal interface used for TCP Resets.

From earlier posts in this series you will see that on the Appliances the TCP Resets will always go back out of the same interface where the packets were monitored Unless the Alternate TCP Reset Interface awas configured.

The IDSM-2, on the other hand, is internally hard coded (not viewable or modifiable in the config) to always use an alternate port for TCP Resets when configured for promiscuous mode.

On the IDSM-2 the internal interface "sy0_1" is used fro sending TCP Reset packets from the IDSM-2 back into the switch when interfaces are being used in promiscuous mode.

So how do you test TCP Resets?

The easiest way is to use the IDM Signature Wizard to create a Custom Signature looking for the regular expression "testSig" inside of a Telnet connection.

Then execute a telnet on one of the networks being monitored by the IDSM-2 and type "testSig". The Custom Signature should trigger an alert (if it does not, then you will need to troubleshoot why the sensor is not alarming).

Now add the TCP Reset action to the Custom Signature. Execute a new telnet and type "testSig" and the connection should be Reset.

hi marcabal sebastan here buddy . buddy i have a silly doubt abt the cables i have to use between 2 routers conected by a inline ips.

R1---ipsf1/0---ipsf1/1-----R2.

f1/0 and f1/1 are sniffing interfaces of the ips. these interfaces are basically layer 2 ports and the routers;s ethernet interfaces are layer 3 interfaces. so when connecting interfaces of different types we need to use straight cables like connecting between a switchport and a router.

but here the interfaces only comeup using cross cables. is it correct.

can u pls help me out.

waiting for ur help.

regards

sebastan

The difference between layer 2 and layer 3 is what is causing your confusion.

Though the sensor acts like a layer 2 device you need to remember it is built using PC style equipment.

The type of wire used is based not on the type of application being run, but instead on how the hardware was built.

Since the sensor is built using PC style hardware, then when wiring you need to think of it as you would an ordinary PC.

When a PC is connected to a switch you use a straight through cable. So when connecting a sensor to a switch you also use a staight through cable.

When a PC is connected to a router, however, you have to use a crossover cable. So when connecting a sensor to a router you also use a crossover cable.

In your deployment you would want to use a crossover cable to connect the IPS Sensor ports to the Routers.

(NOTE: Many of the newer 10/100/1000 NICs are intelligent enough to automtically detect and if needed do the crossover themselves. Sometimes this does require auto detection rather than hardcoding of the speed and duplex. So with 10/100/1000 NICS on both the sensor and router you may be able to use a straight through cable if the auto detection is working correctly.)

hi marcabal thanks a lot.i have connected the topology the same way as u mentioned above.

using cross cables with the ips. now the r1 ip is 1.1.1.1/24 and r2 ip is 1.1.1.2. the ips is in between. i am not able to ping each other.

what could be the problem. even the arp resolution is not getting completed. in the ips events i don;t see the packets getting dropped by ant signatures.

can u pls help me.

regards

sebastan

hi marcabal hey buddy i solved the problem. thanks a lot buddy.

regards

sebastan

Thank you for your answer. Now I have one more question:

how can I create custom signature to test IDS tcp reset?

Please answer me early. Thank you very much.

Here is the link to the IDM documentation that talks about using the Custom Signature Wizard:

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/csids/csids12/idmguide/dmsigwiz.htm#wp1055605

Read through this section to understand how to create the custom signature.

In step 7 you will want "To Service" with a port of 23.

In step 8 use the regex "testSig" or some other string you want to use.

(When in doubt just use the defaults for the other fields)

Once the signature is created then test it to make sure you can fire it (Do a telent and type "testSig" inside the telnet).

Once you have ensured it is firing then add the reset TCP connection event action to the signature.

hi marcabal here;s my setup and i am facing some weird problem in it.,

i have a single switch with 4 routers and ids.

F0/1 IDS SENSING INTERFACE IN PROMISICOUS MODE.

F0/2 R1 ON VLAN 10

F0/3 R2 ON VLAN 10

F0/4 R3 ON VLAN 20

F0/5 R4 ON VLAN 20

R1 and R2 are on same subnet and R3 and R4 are on same subnet.

i have enabled local span .

monitor session 1 source vlan 10 , 20 rx

monitor session 1 destination interface F0/1 encapsulation dot1q ingress vlan 40.

vlan 10

vlan 20

vlan 40

vlan 40 is a unused vlan on the switch,

on the ids in the signature engines i have set tcp reset for syn packets on port 23 for telnet.

now the problem is when i try to get telnet from R1 to R2 the connection is closed properly and i can see the tcp reset send in the ips events.

but when i try to telnet from R2 to R1 it doesn;t work. i mean i can see the signature firing in the events but the tcp reset is not send and the telnet is allowed.

same problem is with with R3 and R4.

did anyone out here faced the same problem. i guess the problem is with the dump ids cause the signature is getting fired but the action is not taken whereas in the events it says the action for tcp reset is true.

any help on this would be really helpful.

regards

sebastan

Just because the telnet is not torn down do not automatically assume that TCP Resets were not sent by the sensor.

The TCP Resets are a best attempt to shutdown the connection but are not guaranteed to work.

This is especially true when the 2 machines are within the same subnet on a fast network.

This is because the server's response may happen before the TCP Resets from the sensor.

In this case the TCP Resets do get sent, but the client sees them after already seeing the server response and so ignores the TCP Resets.

When connections happen over the internet they have a better (but still not guaranteed) chance of shutting down the connection.

So how to debug?

First check the signature actions as see if shows that a TCP Reset action was at least attempted.

IF so then you can fairly safely assume the TCP Resets are at least going out.

If you want more assurance then run a second sniffer in front of the client router and see if there are any TCP Resets being sent to it from the sensor.

The next thing to check is if the TCP Resets have the correct vlan header.

First check the alert to see if a vlan was listed in the alert.

If no vlan is listed in the alert (vlan 0), then the TCP Resets will NOT be sent out with 802.1q headers. This will most likely mean that the TCP Resets are never making it onto the correct vlan and are just being dropped by the switch.

hi marcabal thanks a million for ur detailed explaination man.

ur explainations are better than cisco documentation to be frank.

yeah on the ids events i can see the events being generated for the correct signature.

and also in the events i can see the tcpreset send action as true.

and i can also see the vlan id of the attacker i mean the vlan in which the traffic originated.

as u said if i can see the vlan tags in the events and the tcp reset send as true it means the resets are send right.

in my configuration i have not set the span dest port connecting to the ids as trunk, i have left it to default but still i can see the vlan tags in the events.

so do i need to configure the span dest port as trunk

can u pls reply to my query .

thanks a lot.

regards

sebastan

With the vlan being seen in the alert, and the reset action showing in the alert, then I would have a 99%+ confidence that the resets are being generated and sent out by the sensor (always the small 1% chance you may be hitting a bug we don't know about)

As for how to configure your switch.

This is where the answer differs based on your specific switch.

I have had experience with Cat 6K switches, but very little experience with other switches. In the Cat 6K yes you would need to configure the span destination port as a 802.1q trunk port, as well as use the "ingress" keyword on the monitor command.

You will need to read through the documentation for your specific switch to determine what if any commands would be needed on your switch.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: