Mailing List Archive: Suggestions of evolution

Suggestions of evolution

Aug 24, 2001, 1:08 PM

Post #1 of 7 (1447 views)

Hi all,

#1
I don't know how to use Nessus with multihomed host.
I think there is no way to send the address and the hostname.
If I give the hostname, I don't know the host scanned.
If I give the address, I can't use virtualhost for the HTTP server

Is it possible to send both (like 'www.sample.com@14.66.44.33')?
At least I can modify the /etc/host any other ideas

#2
I suggest a new function recv_http_header(socket:soc, length:4096)
Many http plugins just need to parse the http header
to diagnostic the flaw.
I saw in the RFC 2616 that the header stop with CRLFCRLF.

With this new function,to get the body, the plugin will just have to make
recv_http_header(socket:soc, length:4096);
recv(socket:soc, length:4096);

This evolution will preserve the bandwidth. No need to read to much.

#3
almost all the time a server has a specific function:
SMTP server
Web server
...
It will be nice to configure this main port.
So we can use it in some case:
-in the denial detection (in the start_denial)
-in the tcp_ping function
-in nmap_wrapper.nes (parameter -PTport)
-in ping_host.nasl
-At the end of the process we can verify that the server is OK
...

#4
actualy the function get_port_state return TRUE/FALSE
I think this function could be more precise
not open value 0
open value 1
don't know value 2

In some plugin (checkpoint.nasl for example), you just need
to know that a port is realy open. so if you have already
scanned this port, there is no need to open a socket.

#5
I think that the function is_cgi_installed should be
very complicated when the server doesn't reply with 404.

So not to have all the alerts for this server, I suggest
to maintain a counter (in a key like www/cgicnt/port) increased
at each cgi discovered.
After 5 cgi detected (certainly false alerts) the function
is_cgi_installed will ever return 0 and send to the client
a message like for the timeout of the plugin.

What are you thinking of tose suggestions?
I think that #2 and #4 are very simple, I can do it.

Regards,
Georges

Re: Suggestions of evolution [ In reply to ]

georges.dagousset at alert4web

Aug 25, 2001, 7:58 AM

Post #2 of 7 (1424 views)

Permalink

Hello,

The HEAD method exist but sometime you use an other method (GET or POST),
and the only information you need is in the header.

Georges

----- Original Message -----
From: "Alexis de Bernis" <alexis@bernis.org>
To: "Georges Dagousset" <georges.dagousset@alert4web.com>
Cc: <nessus-devel@list.nessus.org>
Sent: Saturday, August 25, 2001 2:30 PM
Subject: Re: Suggestions of evolution

> On Fri, Aug 24, 2001 at 10:08:30PM +0200, Georges Dagousset wrote:
> >
> > Hi all,
> >
>
> Hi,
>
>
> [...]
> >
> >
> > #2
> > I suggest a new function recv_http_header(socket:soc, length:4096)
> > Many http plugins just need to parse the http header
> > to diagnostic the flaw.
> > I saw in the RFC 2616 that the header stop with CRLFCRLF.
> >
>
> Isn't there a HEAD request defined in HTTP ?
>
> Just a suggestion...
>
>
> -- Alexis

Re: Suggestions of evolution [ In reply to ]

deraison at cvs

Aug 25, 2001, 8:23 AM

Post #3 of 7 (1420 views)

Permalink

On Sat, Aug 25, 2001 at 04:58:40PM +0200, Georges Dagousset wrote:
> Hello,
>
> The HEAD method exist but sometime you use an other method (GET or POST),
> and the only information you need is in the header.

HEAD is not implemented by every HTTP server. Try it against swat for
instance.
(this is why in Nessus 1.x, most of the HEAD requests have been
replaced by GET)

-- Renaud

Re: Suggestions of evolution [ In reply to ]

reinke at e-softinc

Aug 25, 2001, 8:29 AM

Post #4 of 7 (1430 views)

Permalink

For the initiated, this is a perfect example of where the kb is
useful. Create a plugin that is informational only, and it does
nothing but retrieve the header, or web page, of, say, "/". Store the
complete
results in the kb.

From that point on, any test that does "something" based on
a web server response of the home page should be able to do its test
without reliance on network activity, providing it needs something in
the header.

There are countless examples in the scripts: multiple retrievals
of SSH version identifiers, web server identifiers, and so on.
I suspect there would be tangible noticed improvement if a set
of "data collector" plugins were created that were known to be
relied on by other plugins, such that these other plugins could
subsequently do their work more quickly than they can today

How high on the priority list? Probably not: functionality vs
performance,
usually functionality wins out unless performance gets to be very
painfully slow.

Thomas

Georges Dagousset wrote:
>
> Hello,
>
> The HEAD method exist but sometime you use an other method (GET or POST),
> and the only information you need is in the header.
>
> Georges
>
> ----- Original Message -----
> From: "Alexis de Bernis" <alexis@bernis.org>
> To: "Georges Dagousset" <georges.dagousset@alert4web.com>
> Cc: <nessus-devel@list.nessus.org>
> Sent: Saturday, August 25, 2001 2:30 PM
> Subject: Re: Suggestions of evolution
>
> > On Fri, Aug 24, 2001 at 10:08:30PM +0200, Georges Dagousset wrote:
> > >
> > > Hi all,
> > >
> >
> > Hi,
> >
> >
> > [...]
> > >
> > >
> > > #2
> > > I suggest a new function recv_http_header(socket:soc, length:4096)
> > > Many http plugins just need to parse the http header
> > > to diagnostic the flaw.
> > > I saw in the RFC 2616 that the header stop with CRLFCRLF.
> > >
> >
> > Isn't there a HEAD request defined in HTTP ?
> >
> > Just a suggestion...
> >
> >
> > -- Alexis

--
------------------------------------------------------------
Thomas Reinke Tel: (905) 331-2260
Director of Technology Fax: (905) 331-2504
E-Soft Inc. http://www.e-softinc.com
Publishers of SecuritySpace http://www.securityspace.com

Re: Suggestions of evolution [ In reply to ]

deraison at cvs

Aug 27, 2001, 9:19 AM

Post #5 of 7 (1414 views)

Permalink

On Fri, Aug 24, 2001 at 10:08:30PM +0200, Georges Dagousset wrote:

Hi,

> #1
> I don't know how to use Nessus with multihomed host.
> I think there is no way to send the address and the hostname.
> If I give the hostname, I don't know the host scanned.
> If I give the address, I can't use virtualhost for the HTTP server
>
> Is it possible to send both (like 'www.sample.com@14.66.44.33')?
> At least I can modify the /etc/host any other ideas

Actually, Matt Moore sent me a patch in early June that I failed to
apply :/ (sorry Matt!)

The syntax would be : www.nessus.org[127.0.0.1]

> #2
> I suggest a new function recv_http_header(socket:soc, length:4096)
> Many http plugins just need to parse the http header
> to diagnostic the flaw.
> I saw in the RFC 2616 that the header stop with CRLFCRLF.
>
> With this new function,to get the body, the plugin will just have to make
> recv_http_header(socket:soc, length:4096);
> recv(socket:soc, length:4096);
>
> This evolution will preserve the bandwidth. No need to read to much.

The recv_http_header() function is neat. I'm not sure it will really
save more bandwidth than now, but I like it. It'll probably go into
1.2

> #3
> almost all the time a server has a specific function:
> SMTP server
> Web server
> ...
> It will be nice to configure this main port.
> So we can use it in some case:
> -in the denial detection (in the start_denial)
> -in the tcp_ping function
> -in nmap_wrapper.nes (parameter -PTport)
> -in ping_host.nasl
> -At the end of the process we can verify that the server is OK

This makes sense when assessing only one host. If you start to assess a
network, such parameters are a pain to handle. Besides, this can easily
be done manually.

> actualy the function get_port_state return TRUE/FALSE
> I think this function could be more precise
> not open value 0
> open value 1
> don't know value 2

Good point. Or even better, I should change it so that if it's unknown,
it opens a socket. So it always return 1 or 0, and it's always right.

> #5
> I think that the function is_cgi_installed should be
> very complicated when the server doesn't reply with 404.

This is handled. Try Nessus 1.1.x and see if that works better for you.

-- Renaud

Re: Suggestions of evolution [ In reply to ]

deraison at cvs

Aug 27, 2001, 9:28 AM

Post #6 of 7 (1421 views)

Permalink

On Sat, Aug 25, 2001 at 11:29:19AM -0400, Thomas Reinke wrote:
> From that point on, any test that does "something" based on
> a web server response of the home page should be able to do its test
> without reliance on network activity, providing it needs something in
> the header.
>
> There are countless examples in the scripts: multiple retrievals
> of SSH version identifiers, web server identifiers, and so on.
> I suspect there would be tangible noticed improvement if a set
> of "data collector" plugins were created that were known to be
> relied on by other plugins, such that these other plugins could
> subsequently do their work more quickly than they can today
>
> How high on the priority list? Probably not: functionality vs
> performance,
> usually functionality wins out unless performance gets to be very
> painfully slow.

Follow the cvs commits in the plugins, and you'll realize that it's
where we're going. The problem I've been faced until today is that the
plugins dependencies are not shown on the client side, so it's easy for
a user to shoot himself in the foot, and that's why a lot of plugins
are re-opening the connection to SSH to grab the same banner again and
again, just in case the user has disabled THE plugin which does the
banner grabbing.

Once I've found a clean way to have the client enable all the plugins a
given script depends on, then I'll remove these useless connections.

And if you look at all the safe checks that were added, the logic is :

banner = get_kb_item(...);
if(!banner)connect_and_grab_banner();

-- Renaud

Re: Suggestions of evolution [ In reply to ]

georges.dagousset at alert4web

Aug 28, 2001, 7:46 AM

Post #7 of 7 (1422 views)

Permalink

Hi,
>
> > #2
> > I suggest a new function recv_http_header(socket:soc, length:4096)
> > Many http plugins just need to parse the http header
> > to diagnostic the flaw.
> > I saw in the RFC 2616 that the header stop with CRLFCRLF.
> >
> > With this new function,to get the body, the plugin will just have to
make
> > recv_http_header(socket:soc, length:4096);
> > recv(socket:soc, length:4096);
> >
> > This evolution will preserve the bandwidth. No need to read to much.
>
> The recv_http_header() function is neat. I'm not sure it will really
> save more bandwidth than now, but I like it. It'll probably go into
> 1.2
It will save bandwidth when a plugin just need to parse the header.
It will also reduce false positives, because actually plugins are searching
for string
in both (header and html).
Just have a look in php_log.nasl. If the page is speeking about PHP we could
have a false positive.

I wondering, if this new function could/should fill an array with all the
header data:
header["Content-length"],header["Server"] and so on...

Thinking about bandwidth, I looked the code source for is_cgi_installed
implementation.
In lot of case (55/121), a plugin use is_cgi_installed to see if the cgi
exist, and make
another request to parse the result. So we have 2 HTTP requests.
It will be clever to make it once and that is_cgi_installed could return the
result.
or
There is perhaps no need to read 4096 bytes (www_funcs.c) to find the code
status 404.

>
> > #3
> > almost all the time a server has a specific function:
> > SMTP server
> > Web server
> > ...
> > It will be nice to configure this main port.
> > So we can use it in some case:
> > -in the denial detection (in the start_denial)
> > -in the tcp_ping function
> > -in nmap_wrapper.nes (parameter -PTport)
> > -in ping_host.nasl
> > -At the end of the process we can verify that the server is OK
>
> This makes sense when assessing only one host. If you start to assess a
> network, such parameters are a pain to handle. Besides, this can easily
> be done manually.
>
We have already to fill 'TCP ping destination port :' for ping_host.nasl
(for host that deny icmp echoes
and don't have a web sever). And this new configuration could be saved in a
KB.
Talking about plugin ping_host.nasl:
-what do you think about merging ping_host.nasl and tcp_ping.nasl ?
-I think that the default 'TCP ping source port :' should be 21 rather than
80.

> > actualy the function get_port_state return TRUE/FALSE
> > I think this function could be more precise
> > not open value 0
> > open value 1
> > don't know value 2
>
> Good point. Or even better, I should change it so that if it's unknown,
> it opens a socket. So it always return 1 or 0, and it's always right.
>
> > #5
> > I think that the function is_cgi_installed should be
> > very complicated when the server doesn't reply with 404.
>
> This is handled. Try Nessus 1.1.x and see if that works better for you.
I have downloaded the last no404.nasl (from CVE), it works fine.
>
>
Georges