Discussion:
next steps for development in OpenVAS
Pham, Tam T
2014-07-21 18:12:44 UTC
Permalink
Everyone:

I have done some digging into Openvas including install from RPM in RHEL, DEB install into Ubuntu, and source install into Ubuntu. I have previous exposure to NASL from working on Nessus when it was still open source.

I am instrumenting Openvas to do automated scans in my production environment and am also interested in contributing to the development effort.

At this point I would like some suggestions on how to get more deeply involved in two areas of interest:
1) Developing plugins in OVAL to extend the tool set.
2) Contributing to the development of Openvas security scanner. I am interested in just digging in now and getting general understanding of the data flow. Also getting a handle on the development and debugging environment.

Regards,
Tam
Brandon Perry
2014-07-21 19:31:21 UTC
Permalink
I would grok the following:

http://www.openvas.org/protocol-doc.html

The OMP protocol will be what you use for the most part, I think, for
instrumentation and automation.


On Mon, Jul 21, 2014 at 1:12 PM, Pham, Tam T <***@hp.com> wrote:

> Everyone:
>
> I have done some digging into Openvas including install from RPM in RHEL,
> DEB install into Ubuntu, and source install into Ubuntu. I have previous
> exposure to NASL from working on Nessus when it was still open source.
>
> I am instrumenting Openvas to do automated scans in my production
> environment and am also interested in contributing to the development
> effort.
>
> At this point I would like some suggestions on how to get more deeply
> involved in two areas of interest:
> 1) Developing plugins in OVAL to extend the tool set.
> 2) Contributing to the development of Openvas security scanner. I am
> interested in just digging in now and getting general understanding of the
> data flow. Also getting a handle on the development and debugging
> environment.
>
> Regards,
> Tam
> _______________________________________________
> Openvas-discuss mailing list
> Openvas-***@wald.intevation.org
> https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss
>



--
http://volatile-minds.blogspot.com -- blog
http://www.volatileminds.net -- website
Jan-Oliver Wagner
2014-07-21 21:11:21 UTC
Permalink
Am Montag, 21. Juli 2014, 20:12:44 schrieb Pham, Tam T:
> I have done some digging into Openvas including install from RPM in RHEL,
> DEB install into Ubuntu, and source install into Ubuntu. I have previous
> exposure to NASL from working on Nessus when it was still open source.
>
> I am instrumenting Openvas to do automated scans in my production
> environment and am also interested in contributing to the development
> effort.

Any contribution is welcome!


> At this point I would like some suggestions on how to get more deeply
> involved in two areas of interest: 1) Developing plugins in OVAL to extend
> the tool set.

Running OVAL definitions files is something currently being worked on as part
of the OSP integration, prototyping with ovaldi.
If your are not afraid of SVN trunk, you can soon try it out...


> 2) Contributing to the development of Openvas security scanner. I am
> interested in just digging in now and getting general understanding of the
> data flow. Also getting a handle on the development and debugging
> environment.

Building from trunk is a good start. Fixing bugs, trying to trace them
is something training a lot about the internals ;-)




--
Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/
Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B
202460
Geschäftsführer: Lukas Grunwald, Dr. Jan-Oliver Wagner
Pham, Tam T
2014-07-22 01:40:25 UTC
Permalink
Jan:

Thank you for your kind words of encouragement.

My current line of work is automating security scans for printers. I am familiar with NASL but was going to skip writing plugins in that if OVAL was the future. I am assuming this forum will announce when we are able to proceed with the prototype code. I am comfortable with SVN branch and trunk development so I will keep an eye out for it.

I have a development background in C, C++, and Python. For me installing the development environment and stepping through the debug code is the best way to start understanding application behaviour. Any suggestions would be appreciated.

Regards,
Tam


________________________________________
From: Jan-Oliver Wagner [Jan-***@greenbone.net]
Sent: Monday, July 21, 2014 2:11 PM
To: openvas-***@wald.intevation.org
Cc: Pham, Tam T
Subject: Re: [Openvas-discuss] next steps for development in OpenVAS

Am Montag, 21. Juli 2014, 20:12:44 schrieb Pham, Tam T:
> I have done some digging into Openvas including install from RPM in RHEL,
> DEB install into Ubuntu, and source install into Ubuntu. I have previous
> exposure to NASL from working on Nessus when it was still open source.
>
> I am instrumenting Openvas to do automated scans in my production
> environment and am also interested in contributing to the development
> effort.

Any contribution is welcome!


> At this point I would like some suggestions on how to get more deeply
> involved in two areas of interest: 1) Developing plugins in OVAL to extend
> the tool set.

Running OVAL definitions files is something currently being worked on as part
of the OSP integration, prototyping with ovaldi.
If your are not afraid of SVN trunk, you can soon try it out...


> 2) Contributing to the development of Openvas security scanner. I am
> interested in just digging in now and getting general understanding of the
> data flow. Also getting a handle on the development and debugging
> environment.

Building from trunk is a good start. Fixing bugs, trying to trace them
is something training a lot about the internals ;-)




--
Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/
Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B
202460
Geschäftsführer: Lukas Grunwald, Dr. Jan-Oliver Wagner
Jan-Oliver Wagner
2014-07-22 06:21:26 UTC
Permalink
On Dienstag, 22. Juli 2014, Pham, Tam T wrote:
> My current line of work is automating security scans for printers. I am familiar with NASL but was going to skip writing plugins in that if OVAL was the future. I am assuming this forum will announce when we are able to proceed with the prototype code. I am comfortable with SVN branch and trunk development so I will keep an eye out for it.

What I learned about OVAL so far is that doing more complex vulnerability tests
is getting hard if not impossible.
Most OVAL content I see is about patch level testing and policies.


> I have a development background in C, C++, and Python. For me installing the development environment and stepping through the debug code is the best way to start understanding application behaviour. Any suggestions would be appreciated.

Just solving some challenges is the best way to dive in. C and Python are the preferences
of most of the active OpenVAS developers. So this matches well.


--
Dr. Jan-Oliver Wagner | +49-541-335084-0 | http://www.greenbone.net/
Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 202460
Geschäftsführer: Lukas Grunwald, Dr. Jan-Oliver Wagner
Chandrashekhar B
2014-07-22 06:43:42 UTC
Permalink
>> My current line of work is automating security scans for printers. I am
familiar with NASL but was going to skip writing plugins in that if OVAL was
the future. I am assuming this forum will announce when we are able to
proceed with the prototype code. I am comfortable with SVN branch and trunk
development so I will keep an eye out for it.

>What I learned about OVAL so far is that doing more complex vulnerability
tests is getting hard if not impossible.
>Most OVAL content I see is about patch level testing and policies.

We are using OVAL extensively for endpoint vulnerability/configuration
assessments and confidently I can say we develop all sorts of vulnerability
tests. But, OVAL is meant to be a language to do endpoint security
assessments by being on the endpoint or using authenticated scans to remote
endpoints. It is not for the purpose of remotely assessing a vulnerability
by crafting and sending some type of packets. I would assume, for printers,
you'll be doing the latter. So, NASL is the best bet for that purpose.

Thanks,
Chandra.
Loading...