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: | Re: TCP sequence number |
|---|---|
| Date: | Tue, 18 Oct 2005 10:05:56 -0700 (PDT) |
--- David Frechette <frechette_mail@yahoo.com> wrote:
Hello, Recently I'm receiving the following 2 notifications in the report of a single host: 12213: "The remote host might be vulnerable to a sequence number approximation bug, which may allow an attacker to send spoofed RST packets to the remote host and close established connections." 4259: "The TCP initial sequence number of the remote host are incremented by random positive values. Good!" IMHO, these notifications are contradictory. I've rescanned the system multiple times, but these 2 notification keep showing up. Is there an explanation for this?
Yes. Read the cross-reference the first one mentions. The latter purely relates to how the ISN is calculated and if it could be guessed. If it could, then one could perform a blind spoof attack to take advantage of IP-level access controls (e.g. a service relying upon host.allow entries). The prior refers to the ability to send an RST packet to an established TCP connection because of how implementations deal with window sizes and allowed ranges of RST values. This mainly affects long-lived services, such as BGP, that maintain a long TCP connection and suffer from having it drop. Is the nmap plugin (14259 btw) statement good? If you don't know what ISN calculations are and the difference between that and the 12213 plugin, then no; it requires a priori information. Once you understand ISNs and what the output is stating, then IMHO, it's a good statement. 12213 reference: http://www.securityfocus.com/bid/10183/solution ISN reference: http://www.faqs.org/rfcs/rfc1948.html
Thanks in advance,
Hope this helped and that I wasn't being condescending,
Jon
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
_______________________________________________
Nessus mailing list
Nessus@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Problem compiliing Nessus-core on Fedora core 4, Javier Fernandez-Sanguino |
|---|---|
| Next by Date: | Re: Unable to update plug-ins, George A. Theall |
| Previous by Thread: | TCP sequence number, David Frechette |
| Next by Thread: | Nmap.nasl not in direct feed?, Hubert Seiwert |
| Indexes: | [Date] [Thread] [Top] [All Lists] |