Mailing List Archive

When you say "Windows port (besides the client)" do you mean that you'd
like to run Nessus as a service (i.e., daemon) on a Windows box, and
connect to it with the existing clients, or are you more interested in
an actual application, ala ISS, only using Nessus as its core.

ahp

On Monday, January 6, 2003, at 01:08 AM, Noah White wrote:

>
> I know this has been asked in the past, but it has been a while since
> then and I was wondering if anyone out there is working on a Windows
> port (besides the client)? Secondly, is anyone interested in doing one
> if none is currently under way?
>
> -Noah
> <mime-attachment>

This is a *brand-new* project, started, I think, near the end of last
year. Currently there doesn't seem to have been any work done on it,
and I think the project has actually posted a SF "help wanted ad" for
people.

ahp

On Monday, January 6, 2003, at 01:38 AM, Alex Zimin wrote:

> This project has just started at Sourceforge.
> http://sourceforge.net/projects/win-nessus/
>
> I'm not sure what is the status of the project, and if there are any
> files
> released.
>
> Alex.
>
>>
>> I know this has been asked in the past, but it has been a while since
>> then and I was wondering if anyone out there is working on a Windows
>> port (besides the client)? Secondly, is anyone interested in doing one
>> if none is currently under way?
>>
>> -Noah

This project has just started at Sourceforge.
http://sourceforge.net/projects/win-nessus/

I'm not sure what is the status of the project, and if there are any files
released.

Alex.

>
> I know this has been asked in the past, but it has been a while since
> then and I was wondering if anyone out there is working on a Windows
> port (besides the client)? Secondly, is anyone interested in doing one
> if none is currently under way?
>
> -Noah

Interesting, yes it does look pretty new. This is along the lines of
what I had in mind. I know there's been some work done to try to get
stuff working under cygwin but it was my understanding that this hit
some major sticking points and is pretty much dead. I suppose I should
check these folks out and see what kind of a project they've got going.
Thanks,

-Noah

Alex Zimin wrote:

>This project has just started at Sourceforge.
>http://sourceforge.net/projects/win-nessus/
>
>I'm not sure what is the status of the project, and if there are any files
>released.
>
>Alex.
>
>
>
>>I know this has been asked in the past, but it has been a while since
>>then and I was wondering if anyone out there is working on a Windows
>>port (besides the client)? Secondly, is anyone interested in doing one
>>if none is currently under way?
>>
>>-Noah
>>
>>
>
>
>
>

> Adam H.Pendleton wrote:
>
>> When you say "Windows port (besides the client)" do you mean that
>> you'd like to run Nessus as a service (i.e., daemon) on a Windows
>> box, and connect to it with the existing clients, or are you more
>> interested in an actual application, ala ISS, only using Nessus as
>> its core.
>>
>> ahp
>

I guess I am not catching the full distinction you are drawing here.
If you were to hold the port close to the current architecture you would
have something like a GUI client, windows service, NASL interpreter,
plug-ins, windows installer perhaps, etc. I'd still call this suite and
"actual application".

-Noah

On Monday, January 6, 2003, at 02:05 AM, Noah White wrote:

> I guess I am not catching the full distinction you are drawing
> here.
> If you were to hold the port close to the current architecture you
> would
> have something like a GUI client, windows service, NASL interpreter,
> plug-ins, windows installer perhaps, etc. I'd still call this suite and
> "actual application".

I'd be the first to admit it was indeed a fine distinction; you've
clarified it quite nicely, however. I suppose the reason for my
question has more to do with my thinking of a traditional Windows
application, where the application is contained, more or less, within
one Windows "form". It that way of thinking, and attempting a straight
port of the application, you would end up with more than one
application (in the traditional sense): the GUI, the service, etc.

A more important question is why would you endeavor to port the
underlying pieces of Nessus to a Windows platform, when you can use a
GUI from Windows to connect to the Nessus "server". Porting the
application the way you propose would not change this behavior in the
slightest, it would only change the platform on which the "server"
resides; your GUI interface to the "server" would be identical in both
cases. Given that the task of porting Nessus to Windows is likely to
be an onerous one, what is the advantage of running the core components
on a Windows box? I can think of several disadvantages off the top of
my head, the least of which is the somewhat dubious nature of Windows
as a true network development platform. It is only recently (i.e. XP)
that Windows has even embraced a fully-featured TCP/IP stack, and even
then there is no guarantee that all the network pieces required to make
Nessus work will function well enough on WIndows to make the port
tenable.

ahp

IIRC one of the major porting problems was the way Nessus spawns threads
during a scan. Most sane unices do whats called copy-on-write when a
process forks, which means that pages which have not been written to by
the parent process since the time of the fork will be shared with the
child process, so the OS doesn't have to consume memory identical to the
size of the parent process after each fork(). Windows however, actually
allocates enough memory to hold an entire copy of the parent process for
each child, so a Nessus scan of 10 hosts with 10 checks per host would
end up eating up 100 * the size of the main nessusd process. Other major
problems porting to windows are:

* The IPC methods used by Nessus are rather flaky under windows
* Many of the C plugins (nmap/queso/etc) would never compile
* Nessus uses a few third-party libaries which would need to be ported

If youre just looking for "free" ISS-clone, your best approach would be to
take nessus-libraries/libnasl and write your own interface which uses
them. The code is not that hard, I have written a stand-alone NASL-based
scanner before (pluginload.c + attack.c + main()) and it didn't take too
long to get all the defines/includes cut down to something managable.

I still have no idea why the you want to run an assessment tool under
Windows in the first place. You would probably get better performance
running Nessus inside VMWare then you would with a full-blown port
(assuming you didnt rewrite all of libnasl, libnessus, and tack on your
own interface...).

-HD

On Monday 06 January 2003 01:18, Adam H.Pendleton wrote:
> as a true network development platform. It is only recently (i.e. XP)
> that Windows has even embraced a fully-featured TCP/IP stack, and even
> then there is no guarantee that all the network pieces required to make
> Nessus work will function well enough on WIndows to make the port
> tenable.

On Monday, January 6, 2003, at 02:58 AM, H D Moore wrote:

> IIRC one of the major porting problems was the way Nessus spawns
> threads
> during a scan. Most sane unices do whats called copy-on-write when a
> process forks, which means that pages which have not been written to by
> the parent process since the time of the fork will be shared with the
> child process, so the OS doesn't have to consume memory identical to
> the
> size of the parent process after each fork(). Windows however, actually
> allocates enough memory to hold an entire copy of the parent process
> for
> each child, so a Nessus scan of 10 hosts with 10 checks per host would
> end up eating up 100 * the size of the main nessusd process. Other
> major
> problems porting to windows are:

A lot of the c-o-w and similar problems with Windows memory management
have been worked out to a large extent, if my memory serves me
correctly.

> I still have no idea why the you want to run an assessment tool under
> Windows in the first place. You would probably get better performance
> running Nessus inside VMWare then you would with a full-blown port
> (assuming you didnt rewrite all of libnasl, libnessus, and tack on your
> own interface...).

I'm quite surprised, actually, that more people don't take notice of
Windows platforms when creating vulnerability scanning products. I've
worked in several environments where the bulk of the hardware were
unix-based systems, but all the system administrators ran Windows on
their desktops. In this environment, the administrators turned
exclusively to Windows-based vulnerability scanners. Fortunately I was
able to pull out SARA and save the taxpayers the enormous cost of an
ISS license, but even then, they only wanted to use the browser-based
functionality of the scanner; they had no desire to run scans from the
command-line.

Not to mention that a non-technical customer or manager is not going to
endorse a product which does not produce pretty graphs and pictures.
This is the reason I put the browser code into SARA in the first place;
it's also the reason that SARAWriter exists. An SSH session is not
sufficient to present vulnerability data, no matter how comprehensive
it is. This is why ISS is so successful with such a low-quality
product. The cost of purchasing the proper licenses for ISS, training
personnel, and running the slooowwww ISS scans is actually worth the
cost, offset by the fact that ISS can export its vulnerability scans
into Word documents. And there's no impetus for ISS to improve their
product because people keep buying it the way it is. Frankly I am
surprised at the lack of serious competition in the Windows market. I
realize that vulnerability scanning has become somewhat passe in this
day and age, but you would think that at least a decent open-source
alternative to ISS would have come along. Alas, it is not so. Perhaps
one day soon, someone will rectify this situation. (wink, wink).

ahp

Adam H.Pendleton wrote:

> A more important question is why would you endeavor to port the
> underlying pieces of Nessus to a Windows platform, when you can use a
> GUI from Windows to connect to the Nessus "server". Porting the
> application the way you propose would not change this behavior in the
> slightest, it would only change the platform on which the "server"
> resides; your GUI interface to the "server" would be identical in both
> cases. Given that the task of porting Nessus to Windows is likely to be
> an onerous one, what is the advantage of running the core components on
> a Windows box?

Well I do like a challenge. Aside though from a sheer desire to inflict
countless hours of frustration I can think of a few reasons. Well we all
know, like it or not, that Windows has the largest OS install base.
Naturally, that means that "nessus" is/will be/has been used as a tool
to enforce a security policy in an environment which contains such
systems and statistically windows os systems would make up a significant
% of systems being scanned.

If the server were running from a Windows platform you would be able to
scan broader and deeper against Windows systems then you can today from
a *nix server by writing plugins which could take advantage of native
windows functionality. For example it would be easy to excersie a
vulnerability in WMI. You'd very hard pressed to do that from a *nix
server. You'd also be able to easily do things like remotely query a
systems registry to check for installed hotfixes etc (provided a
privaledged workgroup or domain account).

-Noah

Noah White <noah@baysystems.com> writes:

> I know this has been asked in the past, but it has been a while since
> then and I was wondering if anyone out there is working on a Windows
> port (besides the client)?

Recently, I needed a quick & dirty Windows port.
So I loaded Cygwin, compiled everything but the GTK GUI (I had to fix
a couple of little errors) and it nearly worked:
- only the .nasl plugins work, not the .nes
- it is very slow
- I used plain text communication (SSL may work, I just did not try)
That was enough for me, but this is definitely not something that can
be released & supported.

So, in a way, there is a Windows port. It is just not public :-]
Please do not ask for the binaries, I will *not* release them.

--
mailto:arboi@bigfoot.com
GPG Public keys: http://michel.arboi.free.fr/pubkey.txt
http://michel.arboi.free.fr/ http://arboi.da.ru/
FAQNOPI de fr.comp.securite : http://faqnopi.da.ru/

hmmm...it seems I saw a "win nessus" out on sourceforge a while back...

John Lampe

-----Original Message-----
From: Michel Arboi [mailto:arboi@noos.fr]
Sent: Monday, January 06, 2003 6:12 AM
To: nessus-devel@list.nessus.org
Subject: Re: Windows port


Noah White <noah@baysystems.com> writes:

> I know this has been asked in the past, but it has been a while since
> then and I was wondering if anyone out there is working on a Windows
> port (besides the client)?

Recently, I needed a quick & dirty Windows port.
So I loaded Cygwin, compiled everything but the GTK GUI (I had to fix
a couple of little errors) and it nearly worked:
- only the .nasl plugins work, not the .nes
- it is very slow
- I used plain text communication (SSL may work, I just did not try)
That was enough for me, but this is definitely not something that can
be released & supported.

So, in a way, there is a Windows port. It is just not public :-]
Please do not ask for the binaries, I will *not* release them.

--
mailto:arboi@bigfoot.com
GPG Public keys: http://michel.arboi.free.fr/pubkey.txt
http://michel.arboi.free.fr/ http://arboi.da.ru/
FAQNOPI de fr.comp.securite : http://faqnopi.da.ru/

"Adam H.Pendleton" <fmonkey@fmonkey.net> writes:

> I'm quite surprised, actually, that more people don't take notice of
> Windows platforms when creating vulnerability scanning products.

Oh, but ISS did. Eeyes too.

> I've worked in several environments where the bulk of the hardware were
> unix-based systems, but all the system administrators ran Windows on
> their desktops. In this environment, the administrators turned
> exclusively to Windows-based vulnerability scanners.

In such an environment, just install a nessusd on a Unix machine and
use the excellent NessusWX client.

> offset by the fact that ISS can export its vulnerability scans into
> Word documents.

Nessus can export to HTML, and Word can read HTML. So Nessus can
export to Word.

On Mon, Jan 06, 2003 at 03:23:56AM -0500, Adam H. Pendleton wrote:
>
> >each child, so a Nessus scan of 10 hosts with 10 checks per host would
> >end up eating up 100 * the size of the main nessusd process. Other
> >major
> >problems porting to windows are:
>
> A lot of the c-o-w and similar problems with Windows memory management
> have been worked out to a large extent, if my memory serves me
> correctly.

There are still some of them, but you could do a quick and dirty port by
using a Microsoft keyword (I don't recall which one) which allows you to
have one different global variable for each thread. This simplifies
most of the portability problems.

However, I don't really plan to do it, as I do not use Windows nor word,
and I don't like the devel tools under Windows. Feel free to help
though, I can even provide guidance.



-- Renaud