Mailing List Archive

TCP ping missing obvious port?
Just wondering if I'm missing something obvious, but is there
a reason why the tcp_ping() function within Nessus, used, for
example, in ping_host() to check if a host is up, will omit
port 80 as one of the default ports being checked using the
"built-in" TCP port list?

I note it's checking SSH, FTP, DNS, a secure web server,
but notably is missing any checks against port 80.

File reference: libnasl/nasl/nasl_packet_forgery.c
Function: nasl_tcp_ping

Also, since the same function is strategically setting
the source port for any queries, (e.g. setting port 53
when querying a DNS server) to increase the likelihood
of a packet getting through, would it not make sense to
have either
a) The script be able to set the source port, or
b) Have the nasl_tcp_ping function use the same
source port lookup technique for any user passed
ports?

At issue is, for example, a user enhancing the 'built-in'
port list with one of their own, by, say, adding port 80,
but then losing functionality as a result of losing the
sport settings currently in use in the function.

Thomas
Re: TCP ping missing obvious port? [ In reply to ]
On Mon, Jun 14, 2004 at 02:27:35PM -0400, Thomas Reinke wrote:
> Just wondering if I'm missing something obvious, but is there
> a reason why the tcp_ping() function within Nessus, used, for
> example, in ping_host() to check if a host is up, will omit
> port 80 as one of the default ports being checked using the
> "built-in" TCP port list?

It's there :

[renaud@myth nasl]$ grep 80 nasl_packet_forgery.c
int ports[] = { 139, 135, 445, 80, 22, 515, 23, 21, 6000, 1025, 25,
111, 1028, 9100, 1029, 79, 497, 548, 5000, 1917, 53, 161, 9001, 65535,
443, 113, 993, 8080, 0};

(cf item #4)


> Also, since the same function is strategically setting
> the source port for any queries, (e.g. setting port 53
> when querying a DNS server) to increase the likelihood
> of a packet getting through, would it not make sense to
> have either
> a) The script be able to set the source port, or
> b) Have the nasl_tcp_ping function use the same
> source port lookup technique for any user passed
> ports?

We could do that. However using another list than 'built-in' is not
really recommended because when you use built-in you send packets in
parallel (thus gaining time) whereas supplying your own list makes the
script very slow (waiting for a reply for every port). Also, adding an
option is good but increases the overall complexity of the options - I'm
already getting many "Nessus is too difficult to use" remarks because
the "Options" panel is quite large, so I'd assume that changing the
source port could be something you can modify in your own script ?



-- Renaud
Re: TCP ping missing obvious port? [ In reply to ]
Renaud Deraison wrote:
> On Mon, Jun 14, 2004 at 02:27:35PM -0400, Thomas Reinke wrote:
>
>
>
> It's there :
>
> [renaud@myth nasl]$ grep 80 nasl_packet_forgery.c
> int ports[] = { 139, 135, 445, 80, 22, 515, 23, 21, 6000, 1025, 25,
> 111, 1028, 9100, 1029, 79, 497, 548, 5000, 1917, 53, 161, 9001, 65535,
> 443, 113, 993, 8080, 0};

my bad. I should have checked the latest version to see
if it had been added.

> already getting many "Nessus is too difficult to use" remarks because
> the "Options" panel is quite large, so I'd assume that changing the

One of the possible solutions is to add more documentation, and
split the huge options panel into multiple tabbed forms.

> source port could be something you can modify in your own script ?

Sure, something absolutely that we could do. But I'd prefer advocating
suggestions and improvements to the core project than forking off
a separate project with improvements and fixes that then don't get
added back in.

Thomas
Re: TCP ping missing obvious port? [ In reply to ]
On Mon, Jun 14, 2004 at 03:26:27PM -0400, Thomas Reinke wrote:
> >[renaud@myth nasl]$ grep 80 nasl_packet_forgery.c
> > int ports[] = { 139, 135, 445, 80, 22, 515, 23, 21, 6000, 1025, 25,
> >111, 1028, 9100, 1029, 79, 497, 548, 5000, 1917, 53, 161, 9001, 65535,
> >443, 113, 993, 8080, 0};
>
> my bad. I should have checked the latest version to see
> if it had been added.

Err... this has been added in 2.0.8 - 11 months ago.

> >already getting many "Nessus is too difficult to use" remarks because
> >the "Options" panel is quite large, so I'd assume that changing the
>
> One of the possible solutions is to add more documentation, and
> split the huge options panel into multiple tabbed forms.

That does not reduce the sheer number of options which is what most
people complain about. Also, sometimes you need to draw the line : there
are over 2000 scripts now, and a lot of them could be made even more
effective / powerful with a user-supplied option. But you're talking
about serious interface bloat at this point.

There's no doubt that the preferences GUI could be improved and even
possibly be documented (of course, contributions would be welcome in
that area), but the bottom line is that if there are too many options,
nobody will ever use any of them.

-- Renaud