Mailing List Archive

Michel Arboi wrote:
>
> As nmap is running really slowwwwwwwwly against one of my boxes, I
> though that the quickest (and safest) "port scanner" is... the netstat
> command.
> What about this: you run netstat on the box, transfer the output to a
> file which will be sent to nessusd by the client and parsed as the
> nmap output file.
>
> What will be the problems?
> 1. You cannot "scan" more than one target with this
> 2. Misc output format on one OS or another
> 3. Anything more vicious?

Me being the usual paranoid sob, I think "hacker knows client
uses Nessus. Hacker installes modified version of netstat to
report what IT wants to be reported.".

Nothing beats simply connecting to a port to see if is open or not.

Cheers, Thomas
------------------------------------------------------------
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

Thomas Reinke <reinke@e-softinc.com> writes:

> Me being the usual paranoid sob, I think "hacker knows client
> uses Nessus. Hacker installes modified version of netstat to
> report what IT wants to be reported.".

Well, let's say we could use this feature on trusted hosts only.
I wouldn't use Nessus to check if a machine is compromised...

> Nothing beats simply connecting to a port to see if is open or not.

What if the hacker has configured the IP filter so that the backdoor
she installed can only be seen from her machine? Your portscan will
see the port as "filtered".


BTW, maybe I could simply write some little Perl program to transform the
output of netstat into the nmap format, and then feed nessusd with the
usual plugin...

--
mailto:arboi@bigfoot.com http://www.bigfoot.com/~arboi/
GPG Public keys: http://www.bigfoot.com/~arboi/pubkey.txt
FAQNOPI de fr.comp.securite : http://www.bigfoot.com/~arboi/secu/FAQNOPI/

H D Moore <hdm@secureaustin.com> writes:

> There are some definate ways to speed up nmap scanning and then feed the
> results to nessus via the nmap output file.

Playing with the timing options?

> Let me know if you want details, its gets fairly complicated.

Why not? Such trick can be useful.

> Well for one, the ports that the host says are open may be firewalled, so
> nessus will have to timeout on all plugins trying to connect to those
> services.

No, only find_services will have to wait. After it fails, the port
will be marked as "unknown".
(well, I just submitted a plugin that tries to flood "unknown" ports,
just for fun. This one will have to wait too, or will be killed by the
server)

On Friday 24 August 2001 12:56 pm, Michel Arboi wrote:
> As nmap is running really slowwwwwwwwly against one of my boxes, I
> though that the quickest (and safest) "port scanner" is... the netstat
> command.

There are some definate ways to speed up nmap scanning and then feed the
results to nessus via the nmap output file. This is the technique I have
been using for over a year now ;) Let me know if you want details, its gets
fairly complicated.


> What will be the problems?
> 1. You cannot "scan" more than one target with this
> 2. Misc output format on one OS or another
> 3. Anything more vicious?


Well for one, the ports that the host says are open may be firewalled, so
nessus will have to timeout on all plugins trying to connect to those
services. I think its a cool idea, just may not be that effective IRL.

--
H D Moore
http://www.digitaldefense.net - work
http://www.digitaloffense.net - play

On Fri, Aug 24, 2001 at 07:56:34PM +0200, Michel Arboi wrote:
> As nmap is running really slowwwwwwwwly against one of my boxes, I
> though that the quickest (and safest) "port scanner" is... the netstat
> command.
> What about this: you run netstat on the box, transfer the output to a
> file which will be sent to nessusd by the client and parsed as the
> nmap output file.
>
> What will be the problems?
> 1. You cannot "scan" more than one target with this
> 2. Misc output format on one OS or another
> 3. Anything more vicious?

I see a few problems with this:
1. If netstat has been replaced with a trojan, then this will fail. There are
cases where it would be nice to know that a new FTPD has started listening on some
high numbered port in the last week.

2. This would either require installing a nessus scan client on every machine or
as you said only scanning one machine at a time. Neigther is a particularly
useful or viable option for any site with more than one or two computers.

3. This is very OS dependent. Which means that the client will have to cope with
each OS that it runs on. Furthermore there is no garentee that it will work on a
particular platform, whereas now a nessus scan can be run against any platform.

4. It seems like useless client bloat, and it would add complexity to a piece of
software which realy doesn't need any more.

--
Devin Kowatch
devink@sdsc.edu

On Fri, Aug 24, 2001 at 04:09:48PM -0700, Devin Kowatch wrote:
> On Fri, Aug 24, 2001 at 07:56:34PM +0200, Michel Arboi wrote:
> > As nmap is running really slowwwwwwwwly against one of my boxes, I
> > though that the quickest (and safest) "port scanner" is... the netstat
> > command.
> > What about this: you run netstat on the box, transfer the output to a
> > file which will be sent to nessusd by the client and parsed as the
> > nmap output file.
> >
> > What will be the problems?
> > 1. You cannot "scan" more than one target with this
> > 2. Misc output format on one OS or another
> > 3. Anything more vicious?
>
> I see a few problems with this:
> 1. If netstat has been replaced with a trojan, then this will fail. There are
> cases where it would be nice to know that a new FTPD has started listening on some
> high numbered port in the last week.


That's why Michel is not suggesting to remove the other scanner
plugins ;) Actually, I was considering writing such a plugin to parse
the output from port 15/tcp, but as it was pointed out earlier, knowing
that the port is open does not imply it can be reached (nasty packet
filters).

> 4. It seems like useless client bloat, and it would add complexity to a piece of
> software which realy doesn't need any more.

Actually this would not bloat the software at all, it's just the
addition of a plugin. All the infrastructure for the file upload is
already built-in.

And regarding complexity, we're working on simplifying everything :)
(Michel's replacement of libpeks by openssl is a step in that direction)


-- Renaud

Devin Kowatch <devink@SDSC.EDU> writes:

> 1. If netstat has been replaced with a trojan, then this will fail.

Definitely, but using this is not compulsary.
BTW, I believe that everyone uses Nessus in a very personal way.
e.g. most of the time, I launch it against "trusted test
machines". i.e. I can run any command I want on them as root or
Administrator, I can destroy them (although my customer would
appreciate if I did not :) etc.
Others use Nessus as a basis for black box test or pen test

So I guess that we should leave every door open.

> 2. This would either require installing a nessus scan client on
> every machine or as you said only scanning one machine at a time.

*And* write a new plug-in.
So I solved all problems in one shot!

You run "netstat -a -n" or "netstat -a -n --inet" or whatever is
necessary (OK, I did *not* solve this part) and save the results to
files that have the same name as the host.
I wrote a script that "converts" the netstat output to a fake nmap
report. You feed the the nmap plugin with it.
i.e.:
rlogin somehost
netstat -a -n --inet > somehost

> 3. This is very OS dependent.

Definitely. What I wrote is supposed to work on Doz/NT, Linux and
[Open]BSD, and probably a couple of other Unix, *if* you do not forget
the -n option

> 4. It seems like useless client bloat, and it would add complexity
> to a piece of software which realy doesn't need any more.

As it is just a "contrib" that feeds the nmap plugin, Nessus core
remains simple.

I'd highly appreciate comments, criticism (yes, even that), bugs
reports & bug fix, etc.
Do *not* forget the -n option (I should fix this, I suppose)

I am afraid that the current script will only work with French or English
versions of NT. I should fix this, definitely.