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. |

| Subject: | [ISSForum] Proventia G2000 RSTs |
|---|---|
| Date: | Thu, 31 Aug 2006 09:05:57 -0500 |
I've noted an issue in the way that Proventia generates it's RST packets and would like to know if ISS will fix it in the future. A simple test, generating traffic that hits a block rule and capturing the packets, shows that Proventia doesn't calculates the probable initial victim/attacker's TTL, and puts it's own static initial TTL (64) in it's RST packets. While we cannot make the choice of simply drop de "attack" packets (don't sending the RST) anymore, this is a potential problem, because this well known feature shows two important things to the attacker: 1) There's a IDS/IPS in the way! 2) The relative position of IDS/IPS to her victim. Of course we can set Proventia to send it's RSTs through the "RST Port", and connect this port in a "black hole" segment (like a switch that connects nowhere to anywhere), in a way that RSTs never hits their destination. But, I think that it's at least more secure to fake not just the attacker/victim's IPs, but also de TTL! Just for reference, Snort's flexresp2 actually do this job, calculating (guessing) the attacker/victim's TTL and using it to set the appropriate TTL on the RST packets. PS: My test was made using a Proventia G2000 Firmware 1.2 XPU 1.8. Pedro Quintanilha E-MAIL CONFIDENTIALITY NOTICE This e-mail, and any attachments hereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, any dissemination, distribution or copying of this e-mail, and any attachments hereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify me by e-mail or telephone and permanently delete all copies of this e-mail. _______________________________________________ ISSForum mailing list ISSForum@iss.net TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to https://atla-mm1.iss.net/mailman/listinfo/issforum To contact the ISSForum Moderator, send email to mod-issforum@iss.net The ISSForum mailing list is hosted and managed by Internet Security Systems, 6303 Barfield Road, Atlanta, Georgia, USA 30328.
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Next by Date: | [ISSForum] Security Fusion Module - 10061 error after upgrade to SP6, mustafa.yaman |
|---|---|
| Next by Thread: | [ISSForum] Security Fusion Module - 10061 error after upgrade to SP6, mustafa.yaman |
| Indexes: | [Date] [Thread] [Top] [All Lists] |