From bchandra at secpod.com Fri Feb 5 07:12:27 2010 From: bchandra at secpod.com (Chandrashekhar B) Date: Fri, 5 Feb 2010 11:42:27 +0530 Subject: [Openvas-devel] CR #41 and #42 Message-ID: Hello, I have added two new CR's towards standardizing representation of CVSS and Risk Factor in NVT's. #41 - Adoption of CVSS Standard http://www.openvas.org/openvas-cr-41.html #42 - Adoption of Risk Factor standard for NVT's http://www.openvas.org/openvas-cr-42.html Please review and let me know if there are any concerns, comments or suggestions. Thanks, Chandra. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20100205/3c605183/attachment.html From felix.wolfsteller at intevation.de Fri Feb 5 13:43:01 2010 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Fri, 5 Feb 2010 13:43:01 +0100 Subject: [Openvas-devel] CR #41 and #42 In-Reply-To: References: Message-ID: <201002051343.01731.felix.wolfsteller@intevation.de> As usual, an uncooked selection of automatic reactions from my side :) While the idea of both CRs is great and will result in a clean up of the NASL NVTs and make them more consistent, I want to express concern about using the script_tag approach. The neatness of the script-tag approach is that in theory only the NASL scripts themselves have to be updated and there is no compatibility issues at all. The clients will display the content of the tags (although currently it will not look nice, as all tags are cramped together in a single string iirc). Thats all great and I will probably thus vote +1 ;). However, in my eyes, the disadvantages are 1) Tags do not have a clear semantic (e.g. CVSS is a number, think about sorting). 2) Typos are hard to find (assume somebody accidentally typed cvSs), in contrast to a function call like 'meta_info_cvss (5.0);' where the interpreter (and thus Q&A scripts) would warn about un-naslness. 3) Many tags will make the nice and relatively new cache format unreadable again. 4) Many tags will probably make the clients view of NVTs look weird. 5) Start of a "ok, lets do everything with tags"- mentality, where we need proper solutions. Remember the meta-data discussions on the devcon. I think its an okay intermediate solution and if you guys can do the work of touching all these scripts thats a great effort in the right direction. Regarding CR 42: Some nasl- scripts currently do not directly relate to any security issue (e.g. "General Settings", "Toolcheck"). These should get an own SEVERITY, too. "None", or "n/a", "unrelated", "scan-related",...? Similarly for CR 41, should these get an empty string as cvss? A "0.0", a "-1"...? Also, it seems that redundant information is delivered in case both tags are given. The only additional information gained by "risk_factor" is whether the script is just "informational", otherwise the level can be deducted from the cvss score, on client side. If openvas-nasl-tags wouldnt be key-value-pairs I would opt for the first community-agreed-on-tag: "informational". And I am waiting for the meta-data CR :) -- felix On Friday 05 February 2010 07:12:27 Chandrashekhar B wrote: > Hello, > > I have added two new CR's towards standardizing representation of CVSS and > Risk Factor in NVT's. > > #41 - Adoption of CVSS Standard http://www.openvas.org/openvas-cr-41.html > > #42 - Adoption of Risk Factor standard for NVT's > http://www.openvas.org/openvas-cr-42.html > > Please review and let me know if there are any concerns, comments or > suggestions. > > Thanks, > Chandra. -- Felix Wolfsteller | ++49 541 335083-783 | http://www.intevation.de/ PGP Key: 39DE0100 Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From openvas-bugs at wald.intevation.org Thu Feb 4 23:37:08 2010 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Thu, 4 Feb 2010 23:37:08 +0100 (CET) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1272=5D_=5Bopenvas?= =?utf-8?q?-libraries=5D_openvas=5Flogging=2Ec=3A308=3A_error=3A_fo?= =?utf-8?q?rmat_not_a_string_literal_and_no_format_arguments?= Message-ID: <20100204223708.35748852FEA8@pyrosoma.intevation.org> Bugs item #1272, was opened at 2010-02-04 22:37 Status: Open Priority: 3 Submitted By: Stephan Kleine (bitshuffler) Assigned to: Nobody (None) Summary: [openvas-libraries] openvas_logging.c:308: error: format not a string literal and no format arguments Architecture: None Resolution: None Severity: None Version: None Component: openvas-libraries Operating System: Linux Product: OpenVAS Hardware: None URL: Initial Comment: Please review the attached patch and apply it to trunk. It fixes some "format not a string literal and no format arguments" errors which break Mandriva builds. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1272&group_id=29 From openvas-bugs at wald.intevation.org Fri Feb 5 14:40:23 2010 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Fri, 5 Feb 2010 14:40:23 +0100 (CET) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1273=5D_=5Bopenvas?= =?utf-8?q?-administrator=5D_formating_woes?= Message-ID: <20100205134023.F21F5865FAA9@pyrosoma.intevation.org> Bugs item #1273, was opened at 2010-02-05 13:40 Status: Open Priority: 3 Submitted By: Stephan Kleine (bitshuffler) Assigned to: Nobody (None) Summary: [openvas-administrator] formating woes Architecture: None Resolution: None Severity: None Version: None Component: openvas-administrator Operating System: Linux Product: None Hardware: None URL: Initial Comment: Compilation of 0.7.0 fails with: /usr/src/packages/BUILD/openvas-administrator-0.7.0/src/oap.c: In function \'send_to_client\': /usr/src/packages/BUILD/openvas-administrator-0.7.0/src/oap.c:636: error: format \'%i\' expects type \'int\', but argument 3 has type \'size_t\' make[2]: *** [src/CMakeFiles/oap.dir/oap.c.o] Error 1 /usr/src/packages/BUILD/openvas-administrator-0.7.0/src/oxpd.c: In function \'read_protocol\': /usr/src/packages/BUILD/openvas-administrator-0.7.0/src/oxpd.c:249: error: field precision should have type \'int\', but argument 2 has type \'ssize_t\' make[2]: *** [src/CMakeFiles/openvasad.dir/oxpd.c.o] Error 1 Attached patch fixes this. Please apply it to trunk. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1273&group_id=29 From bchandra at secpod.com Mon Feb 8 08:31:35 2010 From: bchandra at secpod.com (Chandrashekhar B) Date: Mon, 8 Feb 2010 13:01:35 +0530 Subject: [Openvas-devel] CR #41 and #42 In-Reply-To: <201002051343.01731.felix.wolfsteller@intevation.de> References: <201002051343.01731.felix.wolfsteller@intevation.de> Message-ID: <93CCC934A8E741978DB96F32EE4FE08D@bchandra> Hello, > -----Original Message----- > From: openvas-devel-bounces at wald.intevation.org > [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf > Of Felix Wolfsteller > Sent: Friday, February 05, 2010 6:13 PM > To: openvas-devel at wald.intevation.org > Subject: Re: [Openvas-devel] CR #41 and #42 > > As usual, an uncooked selection of automatic reactions from my side :) > > While the idea of both CRs is great and will result in a > clean up of the NASL NVTs and make them more consistent, I > want to express concern about using the script_tag approach. > > The neatness of the script-tag approach is that in theory > only the NASL scripts themselves have to be updated and there > is no compatibility issues at all. The clients will display > the content of the tags (although currently it will not look > nice, as all tags are cramped together in a single string iirc). > Thats all great and I will probably thus vote +1 ;). Ok, you have voted +1, so I don't need to respond to the below issues :) > > However, in my eyes, the disadvantages are > 1) Tags do not have a clear semantic (e.g. CVSS is a number, > think about sorting). > 2) Typos are hard to find (assume somebody accidentally typed > cvSs), in contrast to a function call like 'meta_info_cvss > (5.0);' where the interpreter (and thus Q&A scripts) would > warn about un-naslness. We already have some kind of QA check once the NVT's are committed to svn to check these documentation related errors. That can be enhanced. script_tag allows you to add any "key" and "value" types whereas in other case, you need to add new functions for each "key". > 3) Many tags will make the nice and relatively new cache > format unreadable again. Again, better than adding new functions for each key that we want to add. > 4) Many tags will probably make the clients view of NVTs look weird. This is the reporting issue. Client should handle. > 5) Start of a "ok, lets do everything with tags"- mentality, > where we need proper solutions. Remember the meta-data > discussions on the devcon. Yes, the goal is to separate the data portion from the script/code. Even in that case, data must be represented in some key/value format. > > > I think its an okay intermediate solution and if you guys can > do the work of touching all these scripts thats a great > effort in the right direction. > > Regarding CR 42: Some nasl- scripts currently do not directly > relate to any security issue (e.g. "General Settings", > "Toolcheck"). These should get an own SEVERITY, too. "None", > or "n/a", "unrelated", "scan-related",...? > Similarly for CR 41, should these get an empty string as > cvss? A "0.0", a "-1"...? I thought "Informational" would take care of such scripts. Adding CVSS is not mandatory, so we need not add 0.0 in such cases. > > Also, it seems that redundant information is delivered in > case both tags are given. The only additional information > gained by "risk_factor" is whether the script is just > "informational", otherwise the level can be deducted from the > cvss score, on client side. Yes, I agree that both Risk factor and CVSS serve the same purpose. I am not sure if there's any real value in adding both. We are just maintaining Risk factor since we have many NVT's that have risk factor. Anybody else thinks the usefulness of keeping both? > If openvas-nasl-tags wouldnt be key-value-pairs I would opt > for the first > community-agreed-on-tag: "informational". > > And I am waiting for the meta-data CR :) I'll hopefully complete this before the next DevCon :) Chandra. From openvas-bugs at wald.intevation.org Mon Feb 8 20:06:52 2010 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Mon, 8 Feb 2010 20:06:52 +0100 (CET) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1274=5D_=5Bgreenbo?= =?utf-8?q?ne-security-assistant=5D_does_not_compile_on_Debian_Lenn?= =?utf-8?q?y?= Message-ID: <20100208190652.60C2986607DE@pyrosoma.intevation.org> Bugs item #1274, was opened at 2010-02-08 20:06 Status: Open Priority: 3 Submitted By: Dierk Lucyga (dlucyga) Assigned to: Nobody (None) Summary: [greenbone-security-assistant] does not compile on Debian Lenny Architecture: 32 Bit Resolution: None Severity: blocker Version: v1.0 Component: gsa Operating System: Linux Product: OpenVAS Hardware: Other URL: Initial Comment: [ 60%] Building C object src/CMakeFiles/gsad_omp.dir/gsad_omp.c.o cd /home/dlu/src/greenbone-security-assistant-1.0.0-beta3/src && /usr/bin/gcc -Wall -g -Wall -I/usr/local/include -I/usr/include/libxml2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -Werror -DGSAD_VERSION=\"1.0.0-beta3.SVN\" -DOPENVAS_SERVER_CERTIFICATE=\"/usr/local/var/lib/openvas/CA/servercert.pem\" -DOPENVAS_SERVER_KEY=\"/usr/local/var/lib/openvas/private/CA/serverkey.pem\" -DOPENVAS_CA_CERTIFICATE=\"/usr/local/var/lib/openvas/CA/cacert.pem\" -DGSA_STATE_DIR=\"/usr/local/var/lib/openvas/gsa\" -DGSAD_PID_DIR=\"/usr/local/var/run\" -DGSA_CONFIG_DIR=\"/usr/local/etc/openvas/\" -DOPENVAS_OS_NAME=\"Linux-2.6.26-2-686\" -DPREFIX=\"/usr/local\" -I/usr/local/include -I/usr/local/include/openvas -o CMakeFiles/gsad_omp.dir/gsad_omp.c.o -c /home/dlu/src/greenbone-security-assistant-1.0.0-beta3/src/gsad_omp.c cc1: warnings being treated as errors /home/dlu/src/greenbone-security-assistant-1.0.0-beta3/src/gsad_omp.c: In function ?get_report_omp?: /home/dlu/src/greenbone-security-assistant-1.0.0-beta3/src/gsad_omp.c:3803: error: implicit declaration of function ?print_entity_to_string? make[2]: *** [src/CMakeFiles/gsad_omp.dir/gsad_omp.c.o] Fehler 1 make[2]: Leaving directory `/home/dlu/src/greenbone-security-assistant-1.0.0-beta3' make[1]: *** [src/CMakeFiles/gsad_omp.dir/all] Fehler 2 make[1]: Leaving directory `/home/dlu/src/greenbone-security-assistant-1.0.0-beta3' make: *** [all] Fehler 2 gsad_omp.c compiles without -Wall but you get an recoverable linker error later on. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1274&group_id=29 From matthew.mundell at intevation.de Fri Feb 12 19:23:06 2010 From: matthew.mundell at intevation.de (Matthew Mundell) Date: 12 Feb 2010 18:23:06 GMT Subject: [Openvas-devel] CR #41 and #42 In-Reply-To: Message of Fri, 5 Feb 2010 13:43:01 +0100. <201002051343.01731.felix.wolfsteller@intevation.de> Message-ID: <20100212182306.619B2DEBBF@mail.ukfsn.org> > 2) Typos are hard to find (assume somebody accidentally typed cvSs), in > contrast to a function call like 'meta_info_cvss (5.0);' where the > interpreter (and thus Q&A scripts) would warn about un-naslness. Could this be solved with a meta_info_cvss wrapper function that calls script_tag ("cvss_base", x.y)? -- Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From openvas-bugs at wald.intevation.org Fri Feb 12 11:28:53 2010 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Fri, 12 Feb 2010 11:28:53 +0100 (CET) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1278=5D_open=5Fsoc?= =?utf-8?q?k=5Ftcp=28=29_+_transport?= Message-ID: <20100212102853.83BD8865FACC@pyrosoma.intevation.org> Bugs item #1278, was opened at 2010-02-12 10:28 Status: Open Priority: 3 Submitted By: Michael Meyer (mime) Assigned to: Nobody (None) Summary: open_sock_tcp() + transport Architecture: None Resolution: None Severity: normal Version: None Component: openvas-libraries Operating System: Linux Product: OpenVAS Hardware: All URL: Initial Comment: open_sock_tcp() has problems connecting to some ssl-services. ,---[ test.nasl ] | port = 8000; | transport = make_list(ENCAPS_SSLv23,ENCAPS_SSLv3,ENCAPS_TLSv1,ENCAPS_SSLv2); | | foreach t (transport) { | display("TRANSPORT: ",t,"\n"); | soc = open_sock_tcp(port, transport: t); | | if(!soc) { | display("NO SOCKET\n\n"); | } else { | display("SOCKET OK\n\n"); | send(socket:soc, data: string("GET /\r\n")); | buf = recv(socket:soc, length: 512); | display("\n",buf,"\n\n"); | close(soc); | } | sleep(2); | } `---| ,---| | mime at kira:~ % sudo openssl s_server -accept 8000 \ | -key /home/mime/ca/serverkey.pem \ | -cert /home/mime/ca/servercert.pem \ | -msg -www `---| ,---| | openvas-nasl -X -t 192.168.2.4 /path/to/test.nasl (Also with Client) | | TRANSPORT: 2 | [31327] open_stream_connection: TCP:8000 transport:2 timeout:10 | [31327] connect : Operation now in progress | [31327] gnutls_handshake: The Diffie Hellman prime sent by the server is not acceptable (not long enough). | NO SOCKET | | TRANSPORT: 4 | [31327] open_stream_connection: TCP:8000 transport:4 timeout:10 | [31327] connect : Operation now in progress | [31327] gnutls_handshake: The Diffie Hellman prime sent by the server is not acceptable (not long enough). | NO SOCKET | | TRANSPORT: 5 | [31327] open_stream_connection: TCP:8000 transport:5 timeout:10 | [31327] connect : Operation now in progress | [31327] gnutls_handshake: The Diffie Hellman prime sent by the server is not acceptable (not long enough). | NO SOCKET | | TRANSPORT: 3 | [31327] open_stream_connection: TCP:8000 transport:3 timeout:10 | open_stream_connection(): unsupported transport layer 3 | NO SOCKET `--- ,---| | mime at openvas-qa:~> gnutls-cli -p 8000 192.168.2.4 | Resolving '192.168.2.4'... | Connecting to '192.168.2.4:8000'... | - Ephemeral Diffie-Hellman parameters | - Using prime: 520 bits | - Secret key: 503 bits | - Peer's public key: 512 bits | - Certificate type: X.509 | - Got a certificate list of 1 certificates. | | - Certificate[0] info: | # The hostname in the certificate matches '192.168.2.4'. | # valid since: Thu Feb 11 16:16:25 CET 2010 | # expires at: Fri Feb 11 16:16:25 CET 2011 | # fingerprint: 63:19:DF:BA:4C:1D:3C:3D:CF:C6:89:62:19:96:58:75 | # Subject's DN: C=DE,ST=Some-State,O=Internet Widgits Pty Ltd,CN=192.168.2.4 | # Issuer's DN: C=DE,ST=Some-State,O=Internet Widgits Pty Ltd,CN=192.168.2.4 | | - Peer's certificate issuer is unknown | - Peer's certificate is NOT trusted | - Version: TLS1.0 | - Key Exchange: DHE-RSA | - Cipher: AES-128-CBC | - MAC: SHA1 | - Compression: NULL | - Handshake was completed | | - Simple Client Mode: `--- ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1278&group_id=29 From bchandra at secpod.com Mon Feb 15 07:21:48 2010 From: bchandra at secpod.com (Chandrashekhar B) Date: Mon, 15 Feb 2010 11:51:48 +0530 Subject: [Openvas-devel] CR #41 and #42 In-Reply-To: <20100212182306.619B2DEBBF@mail.ukfsn.org> References: Message of Fri, 5 Feb 2010 13:43:01 +0100.<201002051343.01731.felix.wolfsteller@intevation.de> <20100212182306.619B2DEBBF@mail.ukfsn.org> Message-ID: Hello, > -----Original Message----- > From: openvas-devel-bounces at wald.intevation.org > [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf > Of Matthew Mundell > Sent: Friday, February 12, 2010 11:53 PM > To: Felix Wolfsteller > Cc: openvas-devel at wald.intevation.org > Subject: Re: [Openvas-devel] CR #41 and #42 > > > 2) Typos are hard to find (assume somebody accidentally > typed cvSs), > > in contrast to a function call like 'meta_info_cvss (5.0);' > where the > > interpreter (and thus Q&A scripts) would warn about un-naslness. > > Could this be solved with a meta_info_cvss wrapper function > that calls script_tag ("cvss_base", x.y)? The reason for adding script_tag was to avoid having to implement new functions for each such requirement. script_tag() lets you declare any key/value type. Chandra. From matthew.mundell at intevation.de Mon Feb 15 13:34:34 2010 From: matthew.mundell at intevation.de (Matthew Mundell) Date: 15 Feb 2010 12:34:34 GMT Subject: [Openvas-devel] [Openvas-commits] r6740 - in trunk/openvas-libraries: . base hg misc nasl omp In-Reply-To: Message of Mon, 15 Feb 2010 12:38:45 +0100 (CET). <20100215113845.A805186607BE@pyrosoma.intevation.org> Message-ID: <20100215123434.91D86DEBCB@mail.ukfsn.org> > Author: bitshuffler > Date: 2010-02-15 12:38:40 +0100 (Mon, 15 Feb 2010) > New Revision: 6740 > > Modified: > trunk/openvas-libraries/Makefile > trunk/openvas-libraries/base/CMakeLists.txt > trunk/openvas-libraries/hg/Makefile > trunk/openvas-libraries/misc/Makefile > trunk/openvas-libraries/nasl/CMakeLists.txt > trunk/openvas-libraries/omp/CMakeLists.txt > Log: > Fix building on Mandriva and some missing fPIC troubles (bug #1257). Stephan, you must include a Changelog with every commit. The only exception is the doc module. This helps us to synchronise our work and to keep track of what we have done. Please include the body of the Changelog entry as the commit message. Also, please take to care to format the code consistently. The patch introduced tabs and squashes a round bracket onto a function name. -- Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From Jan-Oliver.Wagner at greenbone.net Wed Feb 24 09:44:51 2010 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Wed, 24 Feb 2010 09:44:51 +0100 Subject: [Openvas-devel] CR #41 and #42 In-Reply-To: References: Message-ID: <201002240944.52834.Jan-Oliver.Wagner@greenbone.net> Hello Chandra, On Freitag, 5. Februar 2010, Chandrashekhar B wrote: > I have added two new CR's towards standardizing representation of CVSS and > Risk Factor in NVT's. > > #41 - Adoption of CVSS Standard http://www.openvas.org/openvas-cr-41.html > > #42 - Adoption of Risk Factor standard for NVT's > http://www.openvas.org/openvas-cr-42.html > > Please review and let me know if there are any concerns, comments or > suggestions. I just updated the two CRs to make some aspects more clear. In CR#42 I changed "Informational" to "None" because I felt this more suitable. Please read my changes carefully whether you are happy with it. All the best Jan -- 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 From Jan-Oliver.Wagner at greenbone.net Wed Feb 24 09:58:17 2010 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Wed, 24 Feb 2010 09:58:17 +0100 Subject: [Openvas-devel] Migrating openvas-libraries to cmake Message-ID: <201002240958.20514.Jan-Oliver.Wagner@greenbone.net> Hello, since it seemed to have not created much headache to users and packagers that we introduced cmake to some of the modules inside openvas-libraries, I propose that we do the final step and migrate openvas-libraries to cmake. Thus get rid of the old autotools framework. This step needs two groups: * the developers who do the actual change to cmake * the users/packagers who test on their systems whether it works as expected. Who would feel like being part of one of the groups? Some thougths on the technical side: Currently only "misc" and "hg" are not cmake-based. We could start with these even without changing the parent autotools process too much. The bigger challenge is the main cmake process. The autotools create several variables etc. of which some are important and some might be old unneeded stuff. I wonder wether it is possible to have a cmake process in parallet, so that for configuring the system you can either run cmake or run ./configure. Might be helpful for the transition phase. Best Jan -- 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 From felix.wolfsteller at intevation.de Wed Feb 24 10:28:10 2010 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Wed, 24 Feb 2010 10:28:10 +0100 Subject: [Openvas-devel] Migrating openvas-libraries to cmake In-Reply-To: <201002240958.20514.Jan-Oliver.Wagner@greenbone.net> References: <201002240958.20514.Jan-Oliver.Wagner@greenbone.net> Message-ID: <201002241028.10495.felix.wolfsteller@intevation.de> On Wednesday 24 February 2010 09:58:17 Jan-Oliver Wagner wrote: > since it seemed to have not created much headache to users > and packagers that we introduced cmake to some of the modules > inside openvas-libraries, I propose that we do the final > step and migrate openvas-libraries to cmake. > Thus get rid of the old autotools framework. > > This step needs two groups: > * the developers who do the actual change to cmake > * the users/packagers who test on their systems whether > it works as expected. Although imho not a fun project, the first part could be proposed as gsoc idea, in combination with my proposals below. Maybe there is a cmake- and build-system crazy student out there (plus we get accepted for gsoc). > The bigger challenge is the main cmake process. > The autotools create several variables etc. of which > some are important and some might be old unneeded > stuff. > I wonder wether it is possible to have a cmake process > in parallet, so that for configuring the system you > can either run cmake or run ./configure. > Might be helpful for the transition phase. CMake has a more or less direct counterpart of the configure step (e.g. with creating a config.h, setting macros etc). I expect the main work to be to find out which variables are actually still needed, correlating with which platforms we want to (or can) support. For this, the second mentioned group above (people doing functional tests on various systems/platforms/architectures) is crucial to have. To make the idea bigger, the process can be expanded to the code base, as code blocks that are #ifdef'd with "outdated" macros might be found. Otherwise we will keep carrying unused code around. I would also propose to keep working on a common cmake file (e.g. in direction of the patch and additional file i attached to http://wald.intevation.org/tracker/index.php?func=detail&aid=1245&group_id=29&atid=220). This would help to stop the diverging CMakeLists.txt in manager, administrator and libraries. And in the same time .pc pkg-info files and the respective FindOpenVAS-library.cmake module could be created/extended to allow easy integration of openvas-libraries into other cmake-based projects. E.g. currently with cmake 2.6 checking for the openvas-libraries version is a real pain. Afaiu, the openvas-libraries.pc created by kost is already pretty useable, just has to get installed and used. -- felix -- Felix Wolfsteller | ++49 541 335083-783 | http://www.intevation.de/ PGP Key: 39DE0100 Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From bchandra at secpod.com Wed Feb 24 12:19:13 2010 From: bchandra at secpod.com (Chandrashekhar B) Date: Wed, 24 Feb 2010 16:49:13 +0530 Subject: [Openvas-devel] CR #41 and #42 In-Reply-To: <201002240944.52834.Jan-Oliver.Wagner@greenbone.net> References: <201002240944.52834.Jan-Oliver.Wagner@greenbone.net> Message-ID: Hello Jan, > -----Original Message----- > From: Jan-Oliver Wagner [mailto:Jan-Oliver.Wagner at greenbone.net] > Sent: Wednesday, February 24, 2010 2:15 PM > To: openvas-devel at wald.intevation.org > Cc: Chandrashekhar B > Subject: Re: [Openvas-devel] CR #41 and #42 > > Hello Chandra, > > On Freitag, 5. Februar 2010, Chandrashekhar B wrote: > > I have added two new CR's towards standardizing > representation of CVSS > > and Risk Factor in NVT's. > > > > #41 - Adoption of CVSS Standard > > http://www.openvas.org/openvas-cr-41.html > > > > #42 - Adoption of Risk Factor standard for NVT's > > http://www.openvas.org/openvas-cr-42.html > > > > Please review and let me know if there are any concerns, > comments or > > suggestions. > > I just updated the two CRs to make some aspects more clear. > > In CR#42 I changed "Informational" to "None" because I felt > this more suitable. > > Please read my changes carefully whether you are happy with it. Changes look good, I made some minor changes. Thanks, Chandra. From Jan-Oliver.Wagner at greenbone.net Wed Feb 24 12:21:00 2010 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Wed, 24 Feb 2010 12:21:00 +0100 Subject: [Openvas-devel] Slightly updated OpenVAS Logo? In-Reply-To: <201001242141.10918.Jan-Oliver.Wagner@greenbone.net> References: <201001242141.10918.Jan-Oliver.Wagner@greenbone.net> Message-ID: <201002241221.02333.Jan-Oliver.Wagner@greenbone.net> On Sonntag, 24. Januar 2010, Jan-Oliver Wagner wrote: > as part of the website update a slightly updated logo has been created. > It is attached. > > OK to adopt this one for the website? only positive feedback occured. I know updated the website with this updated logo. You still like it? All the best Jan -- 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 From bchandra at secpod.com Wed Feb 24 12:23:38 2010 From: bchandra at secpod.com (Chandrashekhar B) Date: Wed, 24 Feb 2010 16:53:38 +0530 Subject: [Openvas-devel] Slightly updated OpenVAS Logo? In-Reply-To: <201002241221.02333.Jan-Oliver.Wagner@greenbone.net> References: <201001242141.10918.Jan-Oliver.Wagner@greenbone.net> <201002241221.02333.Jan-Oliver.Wagner@greenbone.net> Message-ID: <44AAE3E614A64B469886E04ABA33F264@corp.nai.org> > -----Original Message----- > From: openvas-devel-bounces at wald.intevation.org > [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf > Of Jan-Oliver Wagner > Sent: Wednesday, February 24, 2010 4:51 PM > To: openvas-devel at wald.intevation.org > Subject: Re: [Openvas-devel] Slightly updated OpenVAS Logo? > > On Sonntag, 24. Januar 2010, Jan-Oliver Wagner wrote: > > as part of the website update a slightly updated logo has > been created. > > It is attached. > > > > OK to adopt this one for the website? > > only positive feedback occured. > > I know updated the website with this updated logo. > > You still like it? Looks good. Chandra. From timb at openvas.org Wed Feb 24 12:59:14 2010 From: timb at openvas.org (Tim Brown) Date: Wed, 24 Feb 2010 11:59:14 +0000 Subject: [Openvas-devel] Slightly updated OpenVAS Logo? In-Reply-To: <44AAE3E614A64B469886E04ABA33F264@corp.nai.org> References: <201001242141.10918.Jan-Oliver.Wagner@greenbone.net> <201002241221.02333.Jan-Oliver.Wagner@greenbone.net> <44AAE3E614A64B469886E04ABA33F264@corp.nai.org> Message-ID: <201002241159.14351.timb@openvas.org> On Wednesday 24 February 2010 11:23:38 Chandrashekhar B wrote: > > -----Original Message----- > > From: openvas-devel-bounces at wald.intevation.org > > [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf > > Of Jan-Oliver Wagner > > Sent: Wednesday, February 24, 2010 4:51 PM > > To: openvas-devel at wald.intevation.org > > Subject: Re: [Openvas-devel] Slightly updated OpenVAS Logo? > > > > On Sonntag, 24. Januar 2010, Jan-Oliver Wagner wrote: > > > as part of the website update a slightly updated logo has > > > > been created. > > > > > It is attached. > > > > > > OK to adopt this one for the website? > > > > only positive feedback occured. > > > > I know updated the website with this updated logo. > > > > You still like it? > > Looks good. > > Chandra. Looks good. Just from a legal perspective we ought to get some kind of statement from the original designer. I know it's unlikely to be a problem, but I'd like to see copyright assigned to SPI to be on the safe side. At the moment we'd be hard pushed to enforce if any misuse occurred. I'll pick this one up with Robert and the SPI folk. Tim -- Tim Brown From Jan-Oliver.Wagner at greenbone.net Wed Feb 24 14:30:11 2010 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Wed, 24 Feb 2010 14:30:11 +0100 Subject: [Openvas-devel] Slightly updated OpenVAS Logo? In-Reply-To: <201002241159.14351.timb@openvas.org> References: <201001242141.10918.Jan-Oliver.Wagner@greenbone.net> <44AAE3E614A64B469886E04ABA33F264@corp.nai.org> <201002241159.14351.timb@openvas.org> Message-ID: <201002241430.21639.Jan-Oliver.Wagner@greenbone.net> On Mittwoch, 24. Februar 2010, Tim Brown wrote: > Looks good. Just from a legal perspective we ought to get some kind of > statement from the original designer. I know it's unlikely to be a problem, > but I'd like to see copyright assigned to SPI to be on the safe side. At the > moment we'd be hard pushed to enforce if any misuse occurred. I'll pick this > one up with Robert and the SPI folk. the logo was developed by a staff member over here. Of course, we are happy to assign copyright! Best Jan -- 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 From Jan-Oliver.Wagner at greenbone.net Wed Feb 24 14:31:09 2010 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Wed, 24 Feb 2010 14:31:09 +0100 Subject: [Openvas-devel] CR #41 and #42 In-Reply-To: References: <201002240944.52834.Jan-Oliver.Wagner@greenbone.net> Message-ID: <201002241431.13615.Jan-Oliver.Wagner@greenbone.net> On Mittwoch, 24. Februar 2010, Chandrashekhar B wrote: > > Please read my changes carefully whether you are happy with it. > > Changes look good, I made some minor changes. good. Go for a vote? Best Jan -- 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 From timb at openvas.org Wed Feb 24 15:20:54 2010 From: timb at openvas.org (Tim Brown) Date: Wed, 24 Feb 2010 14:20:54 +0000 Subject: [Openvas-devel] Slightly updated OpenVAS Logo? In-Reply-To: <201002241430.21639.Jan-Oliver.Wagner@greenbone.net> References: <201001242141.10918.Jan-Oliver.Wagner@greenbone.net> <201002241159.14351.timb@openvas.org> <201002241430.21639.Jan-Oliver.Wagner@greenbone.net> Message-ID: <201002241420.54266.timb@openvas.org> On Wednesday 24 February 2010 13:30:11 Jan-Oliver Wagner wrote: > On Mittwoch, 24. Februar 2010, Tim Brown wrote: > > Looks good. Just from a legal perspective we ought to get some kind of > > statement from the original designer. I know it's unlikely to be a > > problem, but I'd like to see copyright assigned to SPI to be on the safe > > side. At the moment we'd be hard pushed to enforce if any misuse > > occurred. I'll pick this one up with Robert and the SPI folk. > > the logo was developed by a staff member over here. The original one wasn't though. It was designed by a contact of Robert. > Of course, we are happy to assign copyright! Good to hear! Tim -- Tim Brown From robert.berkowitz at gmail.com Wed Feb 24 17:39:14 2010 From: robert.berkowitz at gmail.com (Robert Berkowitz) Date: Wed, 24 Feb 2010 11:39:14 -0500 Subject: [Openvas-devel] Slightly updated OpenVAS Logo? In-Reply-To: <201002241430.21639.Jan-Oliver.Wagner@greenbone.net> References: <201001242141.10918.Jan-Oliver.Wagner@greenbone.net> <44AAE3E614A64B469886E04ABA33F264@corp.nai.org> <201002241159.14351.timb@openvas.org> <201002241430.21639.Jan-Oliver.Wagner@greenbone.net> Message-ID: <8ce3eb501002240839u5e8236fdpd687e426b9bf4d9c@mail.gmail.com> This shouldn't be a problem. If we would like the copyright to lie with SPI then we should check with them to see if they have a standard Copyright Assignement Letter already drafted that we can have Jan fill out on behalf of his company. If not I can probably draft a quick one up for us. -Robert On Wed, Feb 24, 2010 at 8:30 AM, Jan-Oliver Wagner wrote: > On Mittwoch, 24. Februar 2010, Tim Brown wrote: >> Looks good. ?Just from a legal perspective we ought to get some kind of >> statement from the original designer. ?I know it's unlikely to be a problem, >> but I'd like to see copyright assigned to SPI to be on the safe side. ?At the >> moment we'd be hard pushed to enforce if any misuse occurred. ?I'll pick this >> one up with Robert and the SPI folk. > > the logo was developed by a staff member over here. > > Of course, we are happy to assign copyright! > > Best > > ? ? ? ?Jan > > -- > 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 > _______________________________________________ > Openvas-devel mailing list > Openvas-devel at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-devel > -- Robert Berkowitz 919.244.5704 robert.berkowitz at gmail.com From bchandra at secpod.com Thu Feb 25 11:08:55 2010 From: bchandra at secpod.com (Chandrashekhar B) Date: Thu, 25 Feb 2010 15:38:55 +0530 Subject: [Openvas-devel] Call for Vote - CR #41 and CR #42 Message-ID: <552A94B9BD5442DD8175CD8A57F97D22@corp.nai.org> Hello, I would like to call for vote on, CR #41 - Adoption of CVSS Standard (http://www.openvas.org/openvas-cr-41.html) CR #42 - Adoption of Risk Factor standard for NVT's (http://www.openvas.org/openvas-cr-42.html) Both the CR's are towards standardizing the representation of CVSS and Risk factor in NVT's. My vote being +1. Thanks, Chandra. From bchandra at secpod.com Thu Feb 25 11:13:00 2010 From: bchandra at secpod.com (Chandrashekhar B) Date: Thu, 25 Feb 2010 15:43:00 +0530 Subject: [Openvas-devel] CR #43 - NMAP based service detection Message-ID: <4BE598BA59754B9593EEC9CF7A2854A1@corp.nai.org> Hello All, I have added a new CR to integrate NMAP based service detection as a replacement for the current find_service method. #43 - NMAP based service detection http://www.openvas.org/openvas-cr-43.html Please review and let me know if there are any concerns, comments or suggestions. Thanks, Chandra. From bchandra at secpod.com Thu Feb 25 15:06:39 2010 From: bchandra at secpod.com (Chandrashekhar B) Date: Thu, 25 Feb 2010 19:36:39 +0530 Subject: [Openvas-devel] CR #44 - Integrating NMAP NSE's into OpenVAS Message-ID: <823F35232ACA4A9481841BD3B34FCA43@corp.nai.org> Hello, I have added a new CR to allow NSE scripts from NMAP to be launched through OpenVAS. #44 - Integrating NMAP NSE's into OpenVAS http://www.openvas.org/openvas-cr-44.html Please review and let me know if there are any concerns, comments or suggestions. Thanks, Chandra. From lists at securityspace.com Thu Feb 25 16:00:52 2010 From: lists at securityspace.com (Thomas Reinke) Date: Thu, 25 Feb 2010 10:00:52 -0500 Subject: [Openvas-devel] CR #43 - NMAP based service detection In-Reply-To: <4BE598BA59754B9593EEC9CF7A2854A1@corp.nai.org> References: <4BE598BA59754B9593EEC9CF7A2854A1@corp.nai.org> Message-ID: <4B8690A4.8000209@securityspace.com> Hi, I'm not sure I understand the actual rationale for removing the existing find_service.c plugin. a) It's a non-trivial excercise, so there needs to be actual gains seen out of doing it (which I don't see). b) We already get dynamic update of plugin capability if we want it if we include the nmap database in the feed (which I agree _should_ be done (but beware of ensuring that the config files we distribute in the feed match the version of nmap that is out there and might be installed on the scanning system). c) find_service.c almost _never_ gets updated anyways, so we don't need to change it, only complement it (the capability which already exists with item b) above c) Reliability of the tool chain (in a minor way) moves out of our control into the nmap arena for a critical component of any scan (break service detection, the whole scan is broken). I can see situations easily developing where distro X has a version of nmap incompatible with the nmap db we distribute. I am a firm believer of "if it ain't broke, don't fix it". Given that find_service.c essentially is not updated and we have the ability to complement it with nmap, I do not see an upside to removing find_service.c and changing it to an external dependency using code that may not be in sync with the version of OpenVAS installed. Am I missing something here? Thomas Chandrashekhar B wrote: > Hello All, > > I have added a new CR to integrate NMAP based service detection as a > replacement for the current find_service method. > > #43 - NMAP based service detection http://www.openvas.org/openvas-cr-43.html > > Please review and let me know if there are any concerns, comments or > suggestions. > > Thanks, > Chandra. > > > _______________________________________________ > Openvas-devel mailing list > Openvas-devel at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-devel > From bchandra at secpod.com Fri Feb 26 08:08:19 2010 From: bchandra at secpod.com (Chandrashekhar B) Date: Fri, 26 Feb 2010 12:38:19 +0530 Subject: [Openvas-devel] CR #43 - NMAP based service detection In-Reply-To: <4B8690A4.8000209@securityspace.com> References: <4BE598BA59754B9593EEC9CF7A2854A1@corp.nai.org> <4B8690A4.8000209@securityspace.com> Message-ID: Hello Thomas, > -----Original Message----- > From: openvas-devel-bounces at wald.intevation.org > [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf > Of Thomas Reinke > Sent: Thursday, February 25, 2010 8:31 PM > To: openvas-devel at wald.intevation.org > Subject: Re: [Openvas-devel] CR #43 - NMAP based service detection > > Hi, > > I'm not sure I understand the actual rationale for removing > the existing find_service.c plugin. The idea is to make use of tools or libraries that are designed for the purpose, as also discussed during DevCon. Similar exercises were planned for SSH and SMB libraries. > > a) It's a non-trivial excercise, so there needs to be actual > gains seen out of doing it (which I don't see). I agree, the exercise is non-trivial. As of now find_service.c is not being updated and it detects only about 90 services whereas NMAP service db is being maintained well and it has huge number of probes. Why have a module that is not going to be maintained? So, a careful review exercise has to be carried out to see if NMAP really is a full replacement, if not, wherever find_service.c does better, we either retain or see if the required changes can be incorporated to NMAP. > b) We already get dynamic update of plugin capability if we want > it if we include the nmap database in the feed (which I agree > _should_ be done (but beware of ensuring that the config files > we distribute in the feed match the version of nmap that is > out there and might be installed on the scanning system). I agree. > c) find_service.c almost _never_ gets updated anyways, so we > don't need to change it, only complement it (the capability > which already exists with item b) above Yes, that's the idea. But, the difference is to make NMAP the default service detection and use find_service wherever it does better than NMAP, if at all it does. > c) Reliability of the tool chain (in a minor way) moves out of > our control into the nmap arena for a critical component of > any scan (break service detection, the whole scan is broken). > I can see situations easily developing where distro X has > a version of nmap incompatible with the nmap db we distribute. > Thought the other way around :) we get better service detection. I believe, NMAP should ideally take over complete host/port scanning and service detection. I am not sure if the service probes are bound to a particular version of NMAP. I thought they are loosely-coupled. I'll evaluate this. > I am a firm believer of "if it ain't broke, don't fix it". > Given that find_service.c essentially is not updated and we > have the ability to complement it with nmap, I do not see an > upside to removing find_service.c and changing it to an > external dependency using code that may not be in sync with > the version of OpenVAS installed. > > Am I missing something here? > > Thomas Thanks, Chandra. From shehzadal at gmail.com Fri Feb 26 08:49:41 2010 From: shehzadal at gmail.com (Shehzad Lakdawala) Date: Fri, 26 Feb 2010 11:49:41 +0400 Subject: [Openvas-devel] OpenVas client Hangs Message-ID: I have recently installed Openvas3 on Ubuntu 9.0.4. when i launch OpenvasClient, it waits for few minutes and hangs. What is the recommended Linux OS ofr Openvas for good performance. -- Shehzad From Jan-Oliver.Wagner at greenbone.net Fri Feb 26 10:31:17 2010 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Fri, 26 Feb 2010 10:31:17 +0100 Subject: [Openvas-devel] Call for Vote - CR #41 and CR #42 In-Reply-To: <552A94B9BD5442DD8175CD8A57F97D22@corp.nai.org> References: <552A94B9BD5442DD8175CD8A57F97D22@corp.nai.org> Message-ID: <201002261031.18244.Jan-Oliver.Wagner@greenbone.net> On Donnerstag, 25. Februar 2010, Chandrashekhar B wrote: > I would like to call for vote on, > > CR #41 - Adoption of CVSS Standard > (http://www.openvas.org/openvas-cr-41.html) > CR #42 - Adoption of Risk Factor standard for NVT's > (http://www.openvas.org/openvas-cr-42.html) +1 for each. -- 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 From Jan-Oliver.Wagner at greenbone.net Fri Feb 26 10:34:36 2010 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Fri, 26 Feb 2010 10:34:36 +0100 Subject: [Openvas-devel] OpenVas client Hangs In-Reply-To: References: Message-ID: <201002261034.37805.Jan-Oliver.Wagner@greenbone.net> On Freitag, 26. Februar 2010, Shehzad Lakdawala wrote: > I have recently installed Openvas3 on Ubuntu 9.0.4. when i launch > OpenvasClient, it waits for few minutes and hangs. Look into the server log files to learn about what is going on. > What is the recommended Linux OS ofr Openvas for good performance. There is no explicit recommendation. Most developers use Debian Lenny. Most users seem to work with OpenSUSE, Ubuntu and CentOS - but thats just my personal impression from the various postings. Best jan -- 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 From Jan-Oliver.Wagner at greenbone.net Fri Feb 26 11:02:02 2010 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Fri, 26 Feb 2010 11:02:02 +0100 Subject: [Openvas-devel] CR #44 - Integrating NMAP NSE's into OpenVAS In-Reply-To: <823F35232ACA4A9481841BD3B34FCA43@corp.nai.org> References: <823F35232ACA4A9481841BD3B34FCA43@corp.nai.org> Message-ID: <201002261102.04417.Jan-Oliver.Wagner@greenbone.net> Hi, On Donnerstag, 25. Februar 2010, Chandrashekhar B wrote: > I have added a new CR to allow NSE scripts from NMAP to be launched through > OpenVAS. > > #44 - Integrating NMAP NSE's into OpenVAS > http://www.openvas.org/openvas-cr-44.html > > Please review and let me know if there are any concerns, comments or > suggestions. I've just updated the CR. I really like this feature! I've also send a message to the nmap-dev people to inform them about this idea. Maybe they like even to help regarding the NSE preferences management. All the best Jan -- 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 From felix.wolfsteller at intevation.de Fri Feb 26 11:15:14 2010 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Fri, 26 Feb 2010 11:15:14 +0100 Subject: [Openvas-devel] Call for Vote - CR #41 and CR #42 In-Reply-To: <552A94B9BD5442DD8175CD8A57F97D22@corp.nai.org> References: <552A94B9BD5442DD8175CD8A57F97D22@corp.nai.org> Message-ID: <201002261115.14681.felix.wolfsteller@intevation.de> +1 --felix On Thursday 25 February 2010 11:08:55 Chandrashekhar B wrote: > Hello, > > I would like to call for vote on, > > CR #41 - Adoption of CVSS Standard > (http://www.openvas.org/openvas-cr-41.html) > CR #42 - Adoption of Risk Factor standard for NVT's > (http://www.openvas.org/openvas-cr-42.html) > > Both the CR's are towards standardizing the representation of CVSS and Risk > factor in NVT's. > > My vote being +1. > > Thanks, > Chandra. > > _______________________________________________ > Openvas-devel mailing list > Openvas-devel at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-devel -- Felix Wolfsteller | ++49 541 335083-783 | http://www.intevation.de/ PGP Key: 39DE0100 Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From felix.wolfsteller at intevation.de Fri Feb 26 11:46:09 2010 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Fri, 26 Feb 2010 11:46:09 +0100 Subject: [Openvas-devel] CR #44 - Integrating NMAP NSE's into OpenVAS In-Reply-To: <823F35232ACA4A9481841BD3B34FCA43@corp.nai.org> References: <823F35232ACA4A9481841BD3B34FCA43@corp.nai.org> Message-ID: <201002261146.09930.felix.wolfsteller@intevation.de> I like the idea very much but I fear that we loose some of the optimizations done by OpenVAS (e.g. only check a banner from a port if that port is known to be open, shared sockets, share infos through KB). Afaiu, each NSE/Lua script does everything from start to end by itself. Is that correct? Would it be possible to write a small NSE/Lua library that circumenvent this problem, e.g. to rely on the KB for port states instead checking the port itself? -- felix On Thursday 25 February 2010 15:06:39 Chandrashekhar B wrote: > Hello, > > I have added a new CR to allow NSE scripts from NMAP to be launched through > OpenVAS. > > #44 - Integrating NMAP NSE's into OpenVAS > http://www.openvas.org/openvas-cr-44.html > > Please review and let me know if there are any concerns, comments or > suggestions. > > Thanks, > Chandra. > > _______________________________________________ > Openvas-devel mailing list > Openvas-devel at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-devel -- Felix Wolfsteller | ++49 541 335083-783 | http://www.intevation.de/ PGP Key: 39DE0100 Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From felix.wolfsteller at intevation.de Fri Feb 26 12:18:31 2010 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Fri, 26 Feb 2010 12:18:31 +0100 Subject: [Openvas-devel] CR #44 - Integrating NMAP NSE's into OpenVAS In-Reply-To: <823F35232ACA4A9481841BD3B34FCA43@corp.nai.org> References: <823F35232ACA4A9481841BD3B34FCA43@corp.nai.org> Message-ID: <201002261218.31987.felix.wolfsteller@intevation.de> Also, for the future there should be a mechanism to influence certain other "nse-nvt" parameters like category. As some nse seem to be intrusive, they should not be executed when "safe checks" is on, right? Also, which severity would the reported issues/nse output have? -- felix On Thursday 25 February 2010 15:06:39 Chandrashekhar B wrote: > Hello, > > I have added a new CR to allow NSE scripts from NMAP to be launched through > OpenVAS. > > #44 - Integrating NMAP NSE's into OpenVAS > http://www.openvas.org/openvas-cr-44.html > > Please review and let me know if there are any concerns, comments or > suggestions. > > Thanks, > Chandra. > > _______________________________________________ > Openvas-devel mailing list > Openvas-devel at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-devel -- Felix Wolfsteller | ++49 541 335083-783 | http://www.intevation.de/ PGP Key: 39DE0100 Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From bchandra at secpod.com Fri Feb 26 12:48:21 2010 From: bchandra at secpod.com (Chandrashekhar B) Date: Fri, 26 Feb 2010 17:18:21 +0530 Subject: [Openvas-devel] CR #44 - Integrating NMAP NSE's into OpenVAS In-Reply-To: <201002261146.09930.felix.wolfsteller@intevation.de> References: <823F35232ACA4A9481841BD3B34FCA43@corp.nai.org> <201002261146.09930.felix.wolfsteller@intevation.de> Message-ID: Hello Felix, > -----Original Message----- > From: openvas-devel-bounces at wald.intevation.org > [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf > Of Felix Wolfsteller > Sent: Friday, February 26, 2010 4:16 PM > To: openvas-devel at wald.intevation.org > Subject: Re: [Openvas-devel] CR #44 - Integrating NMAP NSE's > into OpenVAS > > I like the idea very much but I fear that we loose some of > the optimizations done by OpenVAS (e.g. only check a banner > from a port if that port is known to be open, shared sockets, > share infos through KB). Yes, it'll run as a separate process for each NSE. We can give the port etc as args though. But, this is a small number of set we are talking about. I don't expect NSE numbers to grow into too many, nor is a replacement for NVT's written in NASL's. > Afaiu, each NSE/Lua script does everything from start to end > by itself. Is that correct? Yes. > Would it be possible to write a > small NSE/Lua library that circumenvent this problem, e.g. to > rely on the KB for port states instead checking the port itself? That would mean changes to Nmap, may be something like libnmap (when we have it) would solve that? Chandra. From bchandra at secpod.com Fri Feb 26 12:59:09 2010 From: bchandra at secpod.com (Chandrashekhar B) Date: Fri, 26 Feb 2010 17:29:09 +0530 Subject: [Openvas-devel] CR #44 - Integrating NMAP NSE's into OpenVAS In-Reply-To: <201002261218.31987.felix.wolfsteller@intevation.de> References: <823F35232ACA4A9481841BD3B34FCA43@corp.nai.org> <201002261218.31987.felix.wolfsteller@intevation.de> Message-ID: Hello Felix, > -----Original Message----- > From: openvas-devel-bounces at wald.intevation.org > [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf > Of Felix Wolfsteller > Sent: Friday, February 26, 2010 4:49 PM > To: openvas-devel at wald.intevation.org > Subject: Re: [Openvas-devel] CR #44 - Integrating NMAP NSE's > into OpenVAS > > Also, for the future there should be a mechanism to influence > certain other "nse-nvt" parameters like category. > > As some nse seem to be intrusive, they should not be executed > when "safe checks" is on, right? Yes, I mention about preferences in CR. As of now there is one or very few that need such inputs as "--script-args". But they run with default value set to to "safe". As we go, may be we need to take care of it through NASL preferences. There's no standard way of listing these args inside NSE's. There may be an exercise required to be carried out before adding NSE into NVT feed. > > Also, which severity would the reported issues/nse output have? All going to be reported as security_note() as we can't distinguish the NMAP output clearly. > > -- felix > Thanks, Chandra. > On Thursday 25 February 2010 15:06:39 Chandrashekhar B wrote: > > Hello, > > > > I have added a new CR to allow NSE scripts from NMAP to be launched > > through OpenVAS. > > > > #44 - Integrating NMAP NSE's into OpenVAS > > http://www.openvas.org/openvas-cr-44.html > > > > Please review and let me know if there are any concerns, > comments or > > suggestions. > > > > Thanks, > > Chandra. > > > > _______________________________________________ > > Openvas-devel mailing list > > Openvas-devel at wald.intevation.org > > http://lists.wald.intevation.org/mailman/listinfo/openvas-devel > > > -- > Felix Wolfsteller | ++49 541 335083-783 | > http://www.intevation.de/ PGP Key: 39DE0100 Intevation GmbH, > Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 > Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. > Jan-Oliver Wagner _______________________________________________ > Openvas-devel mailing list > Openvas-devel at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-devel From lists at securityspace.com Fri Feb 26 22:10:04 2010 From: lists at securityspace.com (Thomas Reinke) Date: Fri, 26 Feb 2010 16:10:04 -0500 Subject: [Openvas-devel] CR #43 - NMAP based service detection In-Reply-To: References: <4BE598BA59754B9593EEC9CF7A2854A1@corp.nai.org> <4B8690A4.8000209@securityspace.com> Message-ID: <4B8838AC.1060200@securityspace.com> Chandrashekhar B wrote: > Hello Thomas, > >> -----Original Message----- >> From: openvas-devel-bounces at wald.intevation.org >> [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf >> Of Thomas Reinke >> Sent: Thursday, February 25, 2010 8:31 PM >> To: openvas-devel at wald.intevation.org >> Subject: Re: [Openvas-devel] CR #43 - NMAP based service detection >> >> Hi, >> >> I'm not sure I understand the actual rationale for removing >> the existing find_service.c plugin. > > The idea is to make use of tools or libraries that are designed for the > purpose, as also discussed during DevCon. Similar exercises were planned for > SSH and SMB libraries. With SSH, it's a clear win. The existing modules are buggy and have limited functionality. No argument on either of those. Rather than doing the work to implement these things ourselves, we leverage third party tools to do the heavy lifting for us. I myself argued for exactly that position at DevCon. > >> a) It's a non-trivial excercise, so there needs to be actual >> gains seen out of doing it (which I don't see). > > I agree, the exercise is non-trivial. As of now find_service.c is not being > updated and it detects only about 90 services whereas NMAP service db is > being maintained well and it has huge number of probes. Why have a module Nmap 5.00 has 58 probes. That being said, it identifies 511 services. But even that count is suspect. Check how many ways http based services are identified with labels that are NOT "http" (3dm-http,http-proxy, http-proxy-ctrl,kazaa-http,ncacn_http,ntop-http,vnc-http). > >> b) We already get dynamic update of plugin capability if we want >> it if we include the nmap database in the feed (which I agree >> _should_ be done (but beware of ensuring that the config files >> we distribute in the feed match the version of nmap that is >> out there and might be installed on the scanning system). > > I agree. > >> c) find_service.c almost _never_ gets updated anyways, so we >> don't need to change it, only complement it (the capability >> which already exists with item b) above > > Yes, that's the idea. But, the difference is to make NMAP the default > service detection and use find_service wherever it does better than NMAP, if > at all it does. Why make nmap the default? I'll ask again - what advantage are you getting that we do not already have? > >> c) Reliability of the tool chain (in a minor way) moves out of >> our control into the nmap arena for a critical component of >> any scan (break service detection, the whole scan is broken). >> I can see situations easily developing where distro X has >> a version of nmap incompatible with the nmap db we distribute. >> > > Thought the other way around :) we get better service detection. I believe, > NMAP should ideally take over complete host/port scanning and service > detection. How is it better? More services? No (we already have nmap included.) More reliable? No. Fewer mistakes? No. We've seen find_service.c in action for nearly a decade. It does things very well. When we did the previous CR to implement nmap probes, we _did_ do very careful thinking about the ramifications of removing it entirely in favour of nmap. We decided against it. Reasons: 1) A critical component moves out of the sphere of control of OpenVAS. A minor point given the collaborative nature OSS Will nmap avoid changing service names to avoid breaking scripts that depend on a service name? If they don't lock down the names, an updated nmap database will break things. E.g. Port #113 - what's the service name? Well, most people would say it's "auth". Run an nmap scan without service detection, and it will say "auth". Run it with service detection, it will say "ident". Port 993? "imaps" by most people's standards. "ssl/imap" when nmap does service detection. Any name change to any of these services will result in a broken dependency. 2) We get NO improvements by replacing find_service.c We don't get improved detection. We already have nmap's service detection. (Unless you are arguing that nmap does it better than find_service.c for the set of services they overlap on, in which case I will dispute and ask you to cite even one example where find_service.c gets it wrong). 3) We get uncertainty on the dependency chain. Not for a single script that might break if nmap ceases to do its job or isn't installed properly. The ENTIRE scanner will break. a) If users don't have nmap installed, the scanner is broken in many cases. b) If users have a mismatched nmap and probe db that we distribute, should the formats change, the scanner is now broken. In addition, individual scripts that rely on service names given by nmap will cease to function if nmap changes the name of the service at any point in time. 4) We replace a proven, solid, working bit of code that has been proven in a production environment for more than a decade, with something that we've never relied on before. In short, there were in our opinion 4 solid reasons to not do this work, and not a single reason to actually do it. I'm sorry, but no-one has provided a single reason yet why we should do this. If you want to say its "better", then please say how it is better. If we had to build from scratch, I'd support it. But as it stands right now, I see too many downsides with no upside to doing this work. Thomas From shehzadal at gmail.com Sun Feb 28 10:05:35 2010 From: shehzadal at gmail.com (Shehzad Lakdawala) Date: Sun, 28 Feb 2010 13:05:35 +0400 Subject: [Openvas-devel] .openvasrc with OpenVAS Client Message-ID: Hi, When i run OpenVAS-Client --batch-mode=127.0.0.1 9390 user password targetip xp2.html -c .openvasrc_windows I get an error as below : No such file or directory : No such file or directory : No such file or directory : No such file or directory : No such file or directory Segmentation fault What i have noticed is that the openvasrc_windows file gets overwritten with no data. I am using Openvas 3.0. The Global settings are left blank. Below is the contents of openvasrc_windows # This file was automatically created by OpenVAS-Client trusted_ca = cacert.pem hide_toolbar = no hide_msglog = no auto_enable_new_plugins = yes targets = 192.168.1.4 use_client_cert = no nessusd_port = 9390 nessusd_user = magnet paranoia_level = 1 nessusd_host = 127.0.0.1 begin(SCANNER_SET) 1.3.6.1.4.1.25623.1.0.10180 = yes 1.3.6.1.4.1.25623.1.0.10278 = no 1.3.6.1.4.1.25623.1.0.10331 = no 1.3.6.1.4.1.25623.1.0.10335 = yes 1.3.6.1.4.1.25623.1.0.10841 = no 1.3.6.1.4.1.25623.1.0.10336 = no 1.3.6.1.4.1.25623.1.0.10796 = no 1.3.6.1.4.1.25623.1.0.11219 = no 1.3.6.1.4.1.25623.1.0.14259 = no 1.3.6.1.4.1.25623.1.0.14272 = no 1.3.6.1.4.1.25623.1.0.14274 = no 1.3.6.1.4.1.25623.1.0.14663 = no 1.3.6.1.4.1.25623.1.0.100315 = no 1.3.6.1.4.1.25623.1.0.11840 = no 1.3.6.1.4.1.25623.1.0.80002 = no 1.3.6.1.4.1.25623.1.0.80009 = no 1.3.6.1.4.1.25623.1.0.80000 = no 1.3.6.1.4.1.25623.1.0.80001 = no end(SCANNER_SET) begin(SERVER_PREFS) max_hosts = 20 max_checks = 4 plugins_timeout = 320 cgi_path = /cgi-bin:/scripts port_range = default auto_enable_dependencies = yes silent_dependencies = no host_expansion = ip ping_hosts = no reverse_lookup = no optimize_test = no safe_checks = no use_mac_addr = no unscanned_closed = no save_knowledge_base = no only_test_hosts_whose_kb_we_dont_have = no only_test_hosts_whose_kb_we_have = no kb_restore = no kb_dont_replay_scanners = no kb_dont_replay_info_gathering = no kb_dont_replay_attacks = no kb_dont_replay_denials = no kb_max_age = 864000 cache_folder = /usr/local/var/cache/openvas include_folders = /usr/local/lib/openvas/plugins log_whole_attack = yes checks_read_timeout = 5 non_simult_ports = 139, 445 slice_network_addresses = no nasl_no_signature_check = yes end(SERVER_PREFS) begin(CLIENTSIDE_USERRULES) end(CLIENTSIDE_USERRULES) begin(PLUGINS_PREFS) w3af (NASL wrapper)[entry]:Profile = full_audit HTTP NIDS evasion[entry]:HTTP User-Agent = HTTP NIDS evasion[checkbox]:Use HTTP HEAD instead of GET = no HTTP NIDS evasion[radio]:URL encoding = none;Incorrect UTF-8; UTF-16 (MS %u);UTF-16 (double byte);Hex HTTP NIDS evasion[radio]:Absolute URI type = none;http;gopher;file HTTP NIDS evasion[radio]:Absolute URI host = none;random IP;random name;host IP;host name HTTP NIDS evasion[checkbox]:Double slashes = no HTTP NIDS evasion[radio]:Reverse traversal = none;Long URL;Basic HTTP NIDS evasion[checkbox]:Self-reference directories = no HTTP NIDS evasion[checkbox]:Premature request ending = no HTTP NIDS evasion[checkbox]:CGI.pm semicolon separator = no HTTP NIDS evasion[checkbox]:Parameter hiding = no HTTP NIDS evasion[checkbox]:Dos/Windows syntax = no HTTP NIDS evasion[checkbox]:Null method = no HTTP NIDS evasion[checkbox]:TAB separator = no HTTP NIDS evasion[checkbox]:HTTP/0.9 requests = no HTTP NIDS evasion[entry]:Force protocol string : = HTTP NIDS evasion[checkbox]:Random case sensitivity (Nikto only) = no LDAPsearch[entry]:Timeout value = 3 LDAPsearch[entry]:Buffersize = 500 HTTP login page[entry]:Login page : = / HTTP login page[entry]:Login form : = HTTP login page[entry]:Login form fields : = user=%USER%&pass=%PASS% Services[entry]:Number of connections done in parallel : = 6 Services[entry]:Network connection timeout : = 5 Services[entry]:Network read/write timeout : = 5 Services[entry]:Wrapped service read timeout : = 2 Services[file]:SSL certificate : = Services[file]:SSL private key : = Services[password]:PEM password : = Services[file]:CA file : = Services[radio]:Test SSL based services = Known SSL ports;None;All SMB Authorization[entry]:SMB login: = administrator SMB Authorization[password]:SMB password: = password SMB Authorization[entry]:SMB domain (optional): = CPE-based Policy Check[entry]:Single CPE = cpe:/ CPE-based Policy Check[file]:CPE List = CPE-based Policy Check[radio]:Severity = High;Low;Medium CPE-based Policy Check[radio]:Severity upon = present;missing Nikto (NASL wrapper)[checkbox]:Force scan even without 404s = no Options for Local Security Checks[checkbox]:Also use 'find' command to search for Applications = yes Options for Local Security Checks[checkbox]:Descend directories on other filesystem (don't add -xdev to find) = yes NIDS evasion[radio]:TCP evasion technique = none;short ttl;injection;split NIDS evasion[checkbox]:Send fake RST when establishing a TCP connection = no Availability of scanner helper tools[checkbox]:Perform tool check = yes Web mirroring[entry]:Number of pages to mirror : = 200 Web mirroring[entry]:Start page : = / Nmap (NASL wrapper)[radio]:TCP scanning technique : = connect();Null scan;Xmas Tree scan;FIN scan;SYN scan Nmap (NASL wrapper)[checkbox]:UDP port scan = no Nmap (NASL wrapper)[checkbox]:Service scan = no Nmap (NASL wrapper)[checkbox]:RPC port scan = no Nmap (NASL wrapper)[checkbox]:Identify the remote OS = no Nmap (NASL wrapper)[checkbox]:Use hidden option to identify the remote OS = no Nmap (NASL wrapper)[checkbox]:Fragment IP packets (bypasses firewalls) = no Nmap (NASL wrapper)[checkbox]:Get Identd info = no Nmap (NASL wrapper)[checkbox]:Do not randomize the order in which ports are scanned = no Nmap (NASL wrapper)[entry]:Source port : = Nmap (NASL wrapper)[radio]:Timing policy : = Auto (openvas specific!);Custom;Paranoid;Sneaky;Polite;Aggressive;Insane;Normal Nmap (NASL wrapper)[entry]:Host Timeout (ms) : = Nmap (NASL wrapper)[entry]:Min RTT Timeout (ms) : = Nmap (NASL wrapper)[entry]:Max RTT Timeout (ms) : = Nmap (NASL wrapper)[entry]:Initial RTT timeout (ms) : = Nmap (NASL wrapper)[entry]:Ports scanned in parallel (max) = Nmap (NASL wrapper)[entry]:Ports scanned in parallel (min) = Nmap (NASL wrapper)[entry]:Minimum wait between probes (ms) = Nmap (NASL wrapper)[file]:File containing grepable results : = Nmap (NASL wrapper)[checkbox]:Do not scan targets not in the file = no Nmap (NASL wrapper)[checkbox]:Run dangerous port scans even if safe checks are set = no Ping Host[checkbox]:Report about unrechable Hosts = no Ping Host[checkbox]:Mark unrechable Hosts as dead (not scanning) = no end(PLUGINS_PREFS) begin(PLUGIN_SET) 1.3.6.1.4.1.25623.1.0.66319 = yes 1.3.6.1.4.1.25623.1.0.902112 = yes 1.3.6.1.4.1.25623.1.0.902116 = yes 1.3.6.1.4.1.25623.1.0.902015 = yes 1.3.6.1.4.1.25623.1.0.900227 = yes 1.3.6.1.4.1.25623.1.0.901095 = yes 1.3.6.1.4.1.25623.1.0.902117 = yes 1.3.6.1.4.1.25623.1.0.900229 = yes 1.3.6.1.4.1.25623.1.0.900230 = yes 1.3.6.1.4.1.25623.1.0.901097 = yes 1.3.6.1.4.1.25623.1.0.900228 = yes 1.3.6.1.4.1.25623.1.0.900740 = yes 1.3.6.1.4.1.25623.1.0.902115 = yes end(PLUGIN_SET) begin(SERVER_INFO) server_info_openvassd_version = 3.0.0 server_info_libnasl_version = 3.0.3 server_info_libnessus_version = 3.0.3 server_info_thread_manager = fork server_info_os = Linux server_info_os_version = 2.6.31-14-generic-pae end(SERVER_INFO) Please Help Thanks Shehzad From shehzadal at gmail.com Sun Feb 28 18:07:19 2010 From: shehzadal at gmail.com (Shehzad Lakdawala) Date: Sun, 28 Feb 2010 21:07:19 +0400 Subject: [Openvas-devel] Scanning for Missing Microsoft Patches (Vulnerabilities) Message-ID: Dear Users, I have tried running OpenVAS Client GUI and Command line to run a scan against Microsoft Vulnerabilities. With every scan i dont get a list of missing patches agains MS vulnerabilities. Same scan run with Nessus 4 gives me correct results. Note: I have all the pligins updated and can also see all the MS-09xxx, MS-10xxx .nasl scripts in the plugins folder (Those released by secpod) Please Assist. -- Shehzad Lakdawala +971 50 5343387 Linkdin: http://ae.linkedin.com/in/shehzadl