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: Strange Nessus Behavior |
|---|---|
| Date: | Wed, 20 Dec 2006 07:01:11 -0800 |
Try clicking on the "consider unscanned ports as closed" and see if that doesn't clear some of this up. It should stop #2 for certain. If I understand #1 right, it should stop that as well.
I think I have noticed this issue for some time and I was wondering if anyone else experiences this and knows how to resolve these issues. The first issue is with how Nessus does its scans. Right now I am using Nessus 2.2.9 and have added nmap.nasl back into my plugins. However, I seem to have the same set of problems regardless as to whether or not I use nmap or Nessus TCP scanner for my port scanner.
First I can configure my Nessus scan to only scan a single port. For example, I can tell Nessus to solely scan port 8888 on the remote host. This is the *only* plugin I will enable (either Nessus TCP Scanner or Nmap (NASL wrapper)). No ping, no SNMP scanner, NO vulnerability or DoS checks. Simply a single plugin enabled - the prot scanner. Now my port scan is set for a specific range.. one single port (8888).
Now if I put in a host to scan and execute/start the scan it starts to exhibit weird behavior. If I am using the Nessus TCP Scanner it will first try Port 8888 on my remote host. Then it randomly moves on to send SYN packets to 8 other ports. Why? This makes no sense to me and I do not know why it does it. Now if I use Nmap (NASL wrapper) with all of the same settings it's a little more exciting. It will decide to scan the same 8 other ports or so and then randomly throw my port 8888 into the scan. It's not first and it's not last. It's usually towards the beginning or in the middle of the other random ports it has chosen to scan.
The next issue I have with Nessus is that it seems to keep the Vulnerability/DoS checks as a separate action. Regardless of what scanner I am using, whether or not a port is open, or if the host is even alive -- all of the checks will launch. So in our above example.. I could be scanning an IP with no host on it. I will tell the scanner to just scan port 8888 and I will have enabled Windows and Web Server checks. Well.. what does Nessus do? It takes our dead host that didn't respond to any ports and tries all of the Windows and Web Server checks on it. Is there a way to disable this from happening? It's a huge waste of time and makes absolutely not sense to me.
To recap from above:
Issue 1: Using just a scanner plugin and 1 port.. Nessus seems to scan multiple other ports for no reason. Why is this?
Issue 2: Even if the host is dead and/or no ports are open Nessus still runs the same vulnerability checks on it. Why is this and can we disable this?
-------
Here is a snippet from me scanning just port 8888 on a dead host with just the Nessus TCP scanner enabled.. notice it seems to try all these other ports
09:40:26.311085 IP 192.168.52.19.41711 > 192.168.74.92.9999: S 445855332:445855332(0) win 5840 <mss 1460,sackOK,timestamp 4139948604 0,nop,wscale 2> 09:40:28.476607 IP 192.168.52.19.41712 > 192.168.74.92.9999: S 455637585:455637585(0) win 5840 <mss 1460,sackOK,timestamp 4139950770 0,nop,wscale 2> 09:40:30.616844 IP 192.168.52.19.41713 > 192.168.74.92.9999: S 446064415:446064415(0) win 5840 <mss 1460,sackOK,timestamp 4139952911 0,nop,wscale 2> 09:40:32.896623 IP 192.168.52.19.60073 > 192.168.74.92.81: S 452683807:452683807(0) win 5840 <mss 1460,sackOK,timestamp 4139955192 0,nop,wscale 2> 09:40:32.899906 IP 192.168.52.19.47825 > 192.168.74.92.9101: UDP, length 2 09:40:33.899151 IP 192.168.52.19.47825 > 192.168.74.92.9101: UDP, length 2 09:40:34.898749 IP 192.168.52.19.47825 > 192.168.74.92.9101: UDP, length 2 09:40:35.895358 IP 192.168.52.19.60073 > 192.168.74.92.81: S 452683807:452683807(0) win 5840 <mss 1460,sackOK,timestamp 4139958192 0,nop,wscale 2> 09:40:35.898379 IP 192.168.52.19.47825 > 192.168.74.92.9101: UDP, length 2 09:40:36.898967 IP 192.168.52.19.47825 > 192.168.74.92.9101: UDP, length 2 09:40:37.898549 IP 192.168.52.19.47825 > 192.168.74.92.9101: UDP, length 2 09:40:37.898921 IP 192.168.52.19.58628 > 192.168.74.92.ftp: S 462790473:462790473(0) win 5840 <mss 1460,sackOK,timestamp 4139960196 0,nop,wscale 2> 09:40:40.898326 IP 192.168.52.19.58628 > 192.168.74.92.ftp: S 462790473:462790473(0) win 5840 <mss 1460,sackOK,timestamp 4139963196 0,nop,wscale 2> 09:40:41.893933 IP 192.168.52.19.60073 > 192.168.74.92.81: S 452683807:452683807(0) win 5840 <mss 1460,sackOK,timestamp 4139964192 0,nop,wscale 2> 09:40:42.893833 IP 192.168.52.19.57904 > 192.168.74.92.8009: S 463349648:463349648(0) win 5840 <mss 1460,sackOK,timestamp 4139965192 0,nop,wscale 2> 09:40:45.892304 IP 192.168.52.19.57904 > 192.168.74.92.8009: S 463349648:463349648(0) win 5840 <mss 1460,sackOK,timestamp 4139968192 0,nop,wscale 2> 09:40:46.895882 IP 192.168.52.19.58628 > 192.168.74.92.ftp: S 462790473:462790473(0) win 5840 <mss 1460,sackOK,timestamp 4139969196 0,nop,wscale 2> 09:40:47.895901 IP 192.168.52.19.54750 > 192.168.74.92.telnet: S 465290182:465290182(0) win 5840 <mss 1460,sackOK,timestamp 4139970196 0,nop,wscale 2> 09:40:50.894315 IP 192.168.52.19.54750 > 192.168.74.92.telnet: S 465290182:465290182(0) win 5840 <mss 1460,sackOK,timestamp 4139973196 0,nop,wscale 2> 09:40:51.889928 IP 192.168.52.19.57904 > 192.168.74.92.8009: S 463349648:463349648(0) win 5840 <mss 1460,sackOK,timestamp 4139974192 0,nop,wscale 2> 09:40:52.889809 IP 192.168.52.19.56161 > 192.168.74.92.http: S 474610391:474610391(0) win 5840 <mss 1460,sackOK,timestamp 4139975192 0,nop,wscale 2> 09:40:55.888407 IP 192.168.52.19.56161 > 192.168.74.92.http: S 474610391:474610391(0) win 5840 <mss 1460,sackOK,timestamp 4139978192 0,nop,wscale 2> 09:40:56.893012 IP 192.168.52.19.54750 > 192.168.74.92.telnet: S 465290182:465290182(0) win 5840 <mss 1460,sackOK,timestamp 4139979196 0,nop,wscale 2> 09:40:57.892830 IP 192.168.52.19.49079 > 192.168.74.92.2002: S 483205135:483205135(0) win 5840 <mss 1460,sackOK,timestamp 4139980197 0,nop,wscale 2> 09:41:00.892275 IP 192.168.52.19.49079 > 192.168.74.92.2002: S 483205135:483205135(0) win 5840 <mss 1460,sackOK,timestamp 4139983197 0,nop,wscale 2> 09:41:01.886799 IP 192.168.52.19.56161 > 192.168.74.92.http: S 474610391:474610391(0) win 5840 <mss 1460,sackOK,timestamp 4139984192 0,nop,wscale 2>
Any help would be appreciated!
Thanks
Steven
_______________________________________________ Nessus mailing list Nessus@list.nessus.org http://mail.nessus.org/mailman/listinfo/nessus
-- Doug Nordwall Unix, Network, and Security Administrator Noise proves nothing. Often a hen who has merely laid an egg cackles as if she laid an asteroid. -- Mark Twain
_______________________________________________ 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: Strange Nessus Behavior, Renaud Deraison |
|---|---|
| Next by Date: | Re: Strange Nessus Behavior, Steven Adair |
| Previous by Thread: | Re: Strange Nessus Behavior, George A. Theall |
| Next by Thread: | RE: Nessus Timeout Error, Suzanna Sarip |
| Indexes: | [Date] [Thread] [Top] [All Lists] |