Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security FullDisclosure
[Top] [All Lists]

Re: [Full-Disclosure] IDS WIth TCP Reset and SPAN

Subject: Re: [Full-Disclosure] IDS WIth TCP Reset and SPAN
Date: Thu, 27 May 2004 13:24:20 -0400

dila wrote:

As far as I know, Snort has no drop capabilities, hence Intrusion _Detection_ System.

I found this using google: http://www.mcabee.org/lists/snort-users/Mar-03/msg00379.html

I did not read the question as one about Snort however while Snort proper does not have drop capability snort-inline which is a patch to snort to use it inline adds drop, silent drop, and replace functionality. It is available through the honeynet project and from the snort-inline sourceforge repository

http://www.honeynet.org/tools/index.html

http://snort-inline.sourceforge.net/

Hints about the Cisco problem below.


-dila


Hello Group,

Hopefully, this topic is ok to discuss here. I am fairly new to IDS
systems and am having trouble getting my cisco IDS to send TCP
resets. The lab network is as follows:


First mistake if you ask me is using Crisco IDS but that is a different topic.



R4 R1----IDS----| R2------R3

R4 and R2 are on the same ethernet segment. R1 is on Command and
Control side of the sensor. The attack is coming from R3 ( telnet
to R4 and issue "testattack" string ). The alarm shows up in event
viewer...but no tcp reset...I mean...my telnet session stays
active.

If Cisco works the same as the rest of the world then the reset should originate from the management interface ( R1 ) unless you have created specific routes to use a non stealth interface for resets. You will have to have route capability from R1 to R4 and possibly R3 in order for the resets to do anything. Did you configure resets using the device manager? I am assuming that you are following the directions linked below. I do not have one to play with so I am only guessing.



I know this probably has something to do with how I am setting up SPAN on the switch....but I am not sure. The IDS Sensing interface, R4 and R2 are on the same switch and in VLAN 20. R3 is in VLAN 30.

If it does inject the resets out the monitor interface then you will have to set up your span as an RX/TX port and then IIRC it depends on what model of switch and IOS/CatOS you are running on whether the port will allow packets to be injected there.


The following links may provide more info for you.

GIAC paper that set it up using RealSecure.
http://www.giac.org/practical/GSEC/Sylvain_Proulx_GSEC.pdf

Cisco doc on configuring span ( RSPAN will not work )
http://www.cisco.com/en/US/products/hw/switches/ps628/products_configuration_guide_chapter09186a00801a6ba9.html

Cisco doc on configuring resets with the IDS
http://www.cisco.com/en/US/products/sw/secursw/ps5052/products_configuration_example09186a00801c0e11.shtml#launch


I have tried it without span ( just R4, R2 and IDS sensing interfaces in same vlan ) and with span configured as follows. Niether has worked.

monitor session 1 source vlan 20 rx monitor session 1 destination
int f0/17 ingress vlan 20

Any ideas??

Thanks,

Dain


_______________________________________________ Full-Disclosure - We
believe in it. Charter:
http://lists.netsys.com/full-disclosure-charter.html



<Prev in Thread] Current Thread [Next in Thread>