Hi there,
I am newbie to Nessus, currently using version 2.29.
Sometimes during scanning I found this error:-
Communication closed by server nessus: nessusd abruptly shut the
communication down - the test may be incomplete
If I'm not mistaken, this is due to server timeout.
Is there any other reason that caused this error?
And is there any way to return error status if this happens?
Regards,
Suzanna Sarip
Software Developer
SCAN Associates Bhd.(525669-P),
Level 7, Menara Naluri,
161-B, Jalan Ampang,
50450 Kuala Lumpur
Tel No. : 03-21660020 ext 1778
Fax No. : 03-21661020
E-Mail : [EMAIL PROTECTED]
SCAN CONFIDENTIALITY NOTICE & DISCLAIMER
The contents of this e-mail and its attachment, if any ("message") are
intended for the named addressee only and may
contain confidential information. If you are not the named addressee, you
must not copy this message or disclose it to
any other person. If you received this message by error, you should delete
this message immediately and notify the
sender by return e-mail.
SCAN Associates Berhad, its subsidiaries and/or group companies ("SCAN")
disclaim all liability for any error, loss or
damage arising from this message being infected by computer virus or other
malicious software. The views and other
information in this message that do not relate to the official business of
SCAN shall not be deemed provided nor
endorsed by SCAN.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of [EMAIL PROTECTED]
Sent: Thursday, December 21, 2006 1:00 AM
To: [email protected]
Subject: Nessus Digest, Vol 38, Issue 17
Send Nessus mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.nessus.org/mailman/listinfo/nessus
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Nessus digest..."
Today's Topics:
1. Bind_query (Scott Pate)
2. RE: SSH Credentials problem (Thomas Nguyen Van)
3. Re: SSH Credentials problem (Renaud Deraison)
4. Strange Nessus Behavior (Steven Adair)
5. Re: Strange Nessus Behavior (Renaud Deraison)
6. Re: Strange Nessus Behavior (Doug Nordwall)
----------------------------------------------------------------------
Message: 1
Date: Tue, 19 Dec 2006 15:58:36 -0600
From: "Scott Pate" <[EMAIL PROTECTED]>
Subject: Bind_query
To: <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
Plugin 10539 reported a DNS server as allowing recursive queries. I
tried to verify this with:
========================================================
[EMAIL PROTECTED] dig @dns.server.com www.nessus.org
; <<>> DiG 9.3.1 <<>> -t A @dns.server.com www.nessus.org ; (1 server
found) ;; global options: printcmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9908 ;; flags: qr
rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.nessus.org. IN A
=======================================================
The status is 'SERVFAIL' but the 'ra' (recursion available) bit is set
as well
>From reading the plugin:
.....
send(socket:soc, data:req);
r = recv(socket:soc, length:4096);
close(soc);
if ( ! r ) exit(0);
pk = dns_split(r);
if ( (pk["flags"] & 0x8085) == 0x8080 )
security_warning(port:53, proto:"udp");
......
It looks like nessus is relying on the 'ra' bit to determine if
recursion is available...correct?
If this is the case, why does it report this since the response (from
below) is 0x8082?
Also, when the script builds the query, it apparently sets the DNS flags
to "dns["flags"] = 0x0100;", but from the packet capture you see that
the query is actually 0x0000. Is this correct?
15:14:05.688382 IP src.host.com.46385 > dns.server.domain: 139 A?
www.nessus.org. (32)
0x0000: 0030 9458 4730 0004 758e 8ebe 0800 4500
.0.XG0..u.....E.
0x0010: 003c 99e4 4000 4011 73b4 xxxx xxxx xxxx
.<[EMAIL PROTECTED]@.s.......
0x0020: xxxx b531 0035 0028 45aa 008b 0000 0001
...1.5.(E.......
0x0030: 0000 0000 0000 0e77 7777 2e6e 6573 7375
.......www.nessu
0x0040: 732e 6f72 6700 0001 0001 s.org.....
15:14:05.745973 IP dns.server.domain > src.host.com.46385: 139 ServFail
0/0/0 (32)
0x0000: 0004 758e 8ebe 0030 9458 4730 0800 4500
..u....0.XG0..E.
0x0010: 003c 0000 4000 3211 1b99 xxxx xxxx xxxx
.<[EMAIL PROTECTED]
0x0020: xxxx 0035 b531 0028 c527 008b 8082 0001
...5.1.(.'......
0x0030: 0000 0000 0000 0e77 7777 2e6e 6573 7375
.......www.nessu
0x0040: 732e 6f72 6700 0001 0001 s.org.....
Scott Pate
Security Consultant
------------------------------
Message: 2
Date: Tue, 19 Dec 2006 16:26:25 -0000
From: Thomas Nguyen Van <[EMAIL PROTECTED]>
Subject: RE: SSH Credentials problem
To: "'[email protected]'" <[email protected]>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
Good afternoon,
In addition to my previous mail of today, I would like to add those
information:
We did the following tests:
Test 1 - Manual SSH connection to IP_Nessus_Target with password: Ok
Test 2 - Manual SSH connection to IP_Nessus_Target with public/private keys:
Ok
Test 3 - Nessus SSH connection to IP_Nessus_Target with password: Ok
Test 4 - Nessus SSH connection to IP_Nessus_Target with public/private keys:
Failed
The analyse of the /var/adm/messages file on IP_Nessus_Target showed that:
Dec 19 16:05:55 IP_Nessus_Target sshd[13422]: [ID 800047 auth.info] Did not
receive ident string from IP_Nessus_Scanner.
Dec 19 16:05:56 IP_Nessus_Target sshd[13423]: [ID 800047 auth.info] Could
not reverse map address IP_Nessus_Scanner.
Dec 19 16:05:56 IP_Nessus_Target sshd[13423]: [ID 800047 auth.info]
Connection closed by IP_Nessus_Scanner
Dec 19 16:06:01 IP_Nessus_Target sshd[13424]: [ID 800047 auth.info] Could
not reverse map address IP_Nessus_Scanner.
Dec 19 16:06:01 IP_Nessus_Target sshd[13424]: [ID 800047 auth.info]
Connection closed by IP_Nessus_Scanner
Dec 19 16:06:01 IP_Nessus_Target sshd[13425]: [ID 800047 auth.info] Did not
receive ident string from IP_Nessus_Scanner.
Do you know why I read the message "Did not receive ident string from
IP_Nessus_Scanner." on the Nessus_Target?
Many thanks in advance
Regards,
Thomas
-----Original Message-----
From: Thomas Nguyen Van
Sent: 19 December 2006 13:04
To: '[email protected]'
Subject: SSH Credentials problem
Good afternoon,
I checked your Nessus' FAQ before calling you
(http://mail.nessus.org/pipermail/nessus/2006-September/msg00186.html) and I
have quiet the same problem as JeanPaul.
Actually, I activated the plugins "Local Checks Failed" (21745) and scanned
a solaris server. On the /var/log/message file, I can see that nessus
account was able to connect on the target server:
Dec 19 13:01:09 Server_Target sshd[7724]: [ID 800047 auth.info]
Accepted publickey for nessus_account from nessus_server port 56364 ssh2
However, when I checked the .nbe file, I got the error message associated to
the plugin 21745 and I can't get any information like security holes or
general information with the plugin 12634.
I would really appreciate a clue to understand what happened.
Thanks a million
Thomas
BT Communications Ireland Limited
is a wholly owned subsidiary of BT Group plc
Registered in Ireland, Registration No. 141524
Grand Canal Plaza, Upper Grand Canal Street, Dublin, Ireland
This electronic message contains information (and may contain files) from BT
Communications Ireland Limited which may be privileged or confidential. The
information is intended to be for the sole use of the individual(s) or
entity named above. If you are not the intended recipient be aware that any
disclosure, copying, distribution or use of the contents of this information
and or files is prohibited. If you have received this electronic message in
error, please notify us by telephone or email (to the numbers or address
above) immediately. http://www.btireland.ie
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mail.nessus.org/pipermail/nessus/attachments/20061219/c228b277/attach
ment.html
------------------------------
Message: 3
Date: Wed, 20 Dec 2006 14:05:16 +0100
From: Renaud Deraison <[EMAIL PROTECTED]>
Subject: Re: SSH Credentials problem
To: Thomas Nguyen Van <[EMAIL PROTECTED]>, Nessus List
<[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
On Dec 19, 2006, at 5:26 PM, Thomas Nguyen Van wrote:
>
> Good afternoon,
>
> In addition to my previous mail of today, I would like to add those
> information:
Once again : Are your plugins up-to-date ??
-- Renaud
------------------------------
Message: 4
Date: Wed, 20 Dec 2006 09:53:32 -0500 (EST)
From: "Steven Adair" <[EMAIL PROTECTED]>
Subject: Strange Nessus Behavior
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain;charset=iso-8859-1
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
------------------------------
Message: 5
Date: Wed, 20 Dec 2006 16:00:29 +0100
From: Renaud Deraison <[EMAIL PROTECTED]>
Subject: Re: Strange Nessus Behavior
To: Nessus List <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Hi,
On Dec 20, 2006, at 3:53 PM, Steven Adair wrote:
>
> 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?
Probably because ping.nasl is enabled anyways due to the dependencies.
To disable ping, you should disable ICMP and TCP pings from Prefs-
>Advanced->Ping Options
>
> 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?
This is happening because nessusd only knows about the status of port
8888 -- maybe port 445 is wide open, maybe it's not. We can't tell
because you chose not to scan it.
So what nessusd does is that it attempts to connect to that port, and
when the attempt eventually times out, it marks it as being a port
not to connect to in the future. Since there are plenty of plugins,
it still takes some time.
To avoid this, enable the option 'Consider unscanned ports as closed'
and try again. Some UDP checks will still take place, though.
-- Renaud
------------------------------
Message: 6
Date: Wed, 20 Dec 2006 07:01:11 -0800
From: "Doug Nordwall" <[EMAIL PROTECTED]>
Subject: Re: Strange Nessus Behavior
To: [EMAIL PROTECTED]
Cc: [email protected]
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"
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.
On 12/20/06, Steven Adair <[EMAIL PROTECTED]> wrote:
>
> 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
> [email protected]
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mail.nessus.org/pipermail/nessus/attachments/20061220/53425f92/attach
ment.htm
------------------------------
_______________________________________________
Nessus mailing list
[email protected]
http://mail.nessus.org/mailman/listinfo/nessus
End of Nessus Digest, Vol 38, Issue 17
**************************************
_______________________________________________
Nessus mailing list
[email protected]
http://mail.nessus.org/mailman/listinfo/nessus
