Re: [Openvas-discuss] how to minimize harm when introducing vuln scanning to a network

[Thomas Reinke]

LOL - you might be saying thank you as you pick up your pink slip/are
escorted out the door for impacting a production system with that
sentiment.

The ultimate answer is dependent upon sensitivities around your assets.
The more sensitive you are, the more you work to manage those sensitivities.

If nessus didn't present any issues, that's a good sign that your
system is likely robust enough, and I'd frame any plans in that
context (i.e. this is doing exactly what and how the external
contractor did it).

If additional concerns have been raised since then, you simply need
to address those - and they are specific to you (usually not a
technology problem).

In general, concerns are always around the unknowns and 'what if'.
To deal with that:

1) Know when your peak resource load times are (be it CPU, memory,
   bandwidth, whatever).   Avoid them, unless you of course are
   attempting to perform a peak test (but then, that's no longer
   a security issue).
2) Know when your peak sensitivity times are (Christmas shopping
   season? Hmmm...  Time for JD Powers to assess your reliability?
   Again...maybe avoid that.
3) Know what controls are in place to keep your assets secure even
   if you don't run an audit (regular patching?  Keeping abreast
   of advisories?).
4) If you are just starting with in-house scanning, roll out your
   scanning procedures from least important assets first to the
   most important ones last.  That will build confidence in the
   processes.  Include milestones/checks along the way that you can
   report back progress to everyone to keep them happy and confident
   that the scans will provide information without being disruptive.

There is no one-size fits all.  Tailor it to the people that have
a vested interest in what you do and why you do it, and you'll be
in good shape.

Thomas


On 03/14/2018 04:43 PM, Reindl Harald wrote:



Am 14.03.2018 um 21:06 schrieb Eero Volotinen:
I usually prefer lower scan speed as too intensive can crash firewall 
devices..


if a security scan from a single node crashs your firewall device you 
should say "thank you" for konwing that this crap needs to be replaced ASAP


real attackers don't care as you do

14.3.2018 22.01 "TJ" > 
kirjoitti:


    I would exclude networked printers as the scans can cause them to
    produce volumes of printed gibberish (found out the hard way)

    Yes, definitely scan during maintenance windows/non-business hours
    until you see how well it plays in your environment.  Not to mention
    with less network traffic and systems activity, the scans should
    finish a lot sooner


    On 3/14/2018 3:53 PM, Peter Collins wrote:

    (Sorry if this is a repost. I had a technical issue with my first
    attempt)

    I would like to use OSSIM's OpenVAS component to run asset and
    vulnerability scans on both prod and non-prod. Like every place,
    we want to make sure the IT infrastructure is not harmed or
    jeopardized.

    So what is due care when introducing scanning? Should I do the
    asset scans only during maintenance windows to start off, to make
    sure nothing gets broken? Or are the non destructive, non
    authenticated scans considered safe enough to run during
    production hours, on production assets?

    I should add that Nessus has been used by an outside contractor
    without issue, on our network.

    Thanks so much in advance

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss


___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Restrict cpu util.

[Thomas Reinke]

Unix/Linux does not allow that kind of CPU utilization control, unless
you're talking about some big iron.

The best you can do is limit the amount of thrashing your processor
may do be controlling the number of scans, and the number of hosts per
scan, and number of tests per host, that you are running in parallel.

Thomas

On 15/08/14 12:11 PM, lucianofain wrote:

Hi all is any way to restrict cpu utilization of openvas scanner
service?  I put be nice=yes but as I run to many task in paralell I need
to restrict all openvas scanner services running in parallel for example
using 80% max of all CPUs
Regards


Enviado desde Samsung Mobile.


___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss



___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Bug in openvas 6.0 - possible breakage of default port scan

[Thomas Reinke]

On 23/07/14 04:27 AM, Jan-Oliver Wagner wrote:

On Dienstag, 22. Juli 2014, Thomas Reinke wrote:

The latest version of openvas has changed the logic used to
validate the port_range passed in.  One of the values
advertised that can be used is the string default, and if
you look at older daemons, they specifically support that
via the getpts call.


with latest you mean OpenVAS-6 here?
Note that OpenVAS-7 removed even more of that port_range
handling.


My bad...I missed openvas7, so yes, we were talking about
openvas6.



The rationale was that a term default is entirely intransparent
for the user. The touched ports should not be a matter
to decide by some tools at the end of the chain. It needs always
control from top level.


Well, yes and no...unless the top level decision is (as was in
this case) to trust the nmap services configuration file as a
key, optimal way of scanning for open ports.  Not all well
known services reside in a specific port range.




Re impact:

FYI - I am seeing downstream impact, as amap.nasl and nmap.nasl
have explicit checks for the value default to control certain
behaviours.  That might be a non-trivial impact in terms of
expected behaviour/performance of nmap itself...


hm, this is somewhat in conflict with the intransparency of what
is going on. A Nmap expert of course might know well what will
happen using default.


That's, in my opinion, THE common way to run nmap (no port options).
It's the biggest bang for the buck from nmap. It's not really
an 'expert' thing - if you use nmap at ALL and know what it does,
you are using that mode.





The specific use case for us is that we use the 'default' value
of nmap to control nmap's scan to scan any port below 1024 and
all known service ports that nmap has, and to then feed that
back into openvas.  It looks to me based on observations (haven't
run the actual tests yet), that this capability would now be
broken, as there would be no way of telling nmap to leverage this
default behaviour set.


right, you need now to express the ports explicitly.


Got it...not my preferred approach (I've always been a fan of all
the work that nmap did in identifying all the common services). To
have to grab all that out seems...redundant. Not a huge issue though,
and admittedly I like the idea of passing port list better than
the idea of patching back two versions of openvassd.





I am guessing based on a cursory reading of the code that backwards
compatibility could be re-instated by modifying the check for
a string of -1 failure to be a check for failure of both
-1 and default...

I.e. change in attack.c

if (strcmp (port_range, -1) != 0)

to

   if (strcmp(port_range, -1)!=0)  strcmp(port_range, default)!=0)


Anyone see any issues with what's been suggested?


I don't see one for OpenVAS-6 branch (OpenVAS Scanner 3.4).
If the patch works for you without flaws, you can commit or let us
know to do so.

It won't apply for OpenVAS-7 though as the conceptual change would not
allow to transfer a setting that is understood by some port scanner in some
way.



Probably would be good to understand and handle the logic in the nasl
scripts that still rely on the default values...

Thomas

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Bug in openvas 6.0 - possible breakage of default port scan

[Thomas Reinke]

Probably would be good to understand and handle the logic in the nasl
scripts that still rely on the default values...


hm, which ones are these?




nmap.nasl, amap.nasl, portbunny.nasl, portscan-strobe.nasl, pnscan.nasl

In short, after you dig through code, it seems with a setting of
default, invoking scanner_get_ports eventually finds it's way to
the getpts function call, to get_tcp_svcs, which reads the
openvas file /usr/local/var/lib/openvas/services.tcp, specifically
to be able to get a list of ports.

So there's still a whole bunch of infrastructure, afaik, that is
designed to support the concept of a 'default' scan, which would
appear to be controlled by what is defined in these files.

nmap.nasl:
 port_range = get_preference(port_range);
 if (port_range) # Null for command line tests only
 {
  argv[i++] = -p;
  if (port_range == default )
  ^^^
  {
   n = 0;
   str = ;


amap.nasl:
 pr = get_preference(port_range);

 if (! pr) pr = 1-65535;

  if (pr == default )
 ^^
  {
   n = 0;
   pr = ;

portbunny.nasl:
argv[i++] = ip;
 pr = get_preference(port_range);
 if (! pr) pr = 1-65535;
 if (pr == default )
 {
 n = 0;
 str = ;


portscan-strobe.nasl:
prange = get_preference(port_range);
if (! prange) prange = 1-65535;
if (prange == default )
{
n = 0;
str = ;
while ( port = scanner_get_port(n) )
{
if ( n  0 ) str += , + string(port);
else str = string(port);
n ++;
}
prange=str;

pnscan.nasl:
prange = get_preference(port_range);
if (! prange) prange = 1-65535;
if (prange == default )
{
n = 0;
str = ;
while ( port = scanner_get_port(n) )


___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

[Openvas-discuss] Bug in openvas 6.0 - possible breakage of default port scan

[Thomas Reinke]

The latest version of openvas has changed the logic used to
validate the port_range passed in.  One of the values
advertised that can be used is the string default, and if
you look at older daemons, they specifically support that
via the getpts call.

Now, however, while default is still advertised as the
default value of port_range (see preferences.c:83), if
you actually try to use that default string, the daemon bails
with error

SERVER | ERROR | E001 - Invalid port range | SERVER

The offending code change appears to be in attack.c.

The new code looks like this:

  /* Init and check Port Range. */
  port_range = arg_get_value (preferences, port_range);
  if (port_range == NULL || port_range[0] == '\0')
port_range = 1-15000;

  if (strcmp (port_range, -1) != 0)
{
  port_range = arg_get_value (preferences, port_range);
  if (validate_port_range (port_range))
{
  auth_printf (globals,
   SERVER | ERROR | E001 - Invalid port range 
| SERVER\n);

  return 0;
}
}


The old code was:

   /* Init and check Port Range. */
  port_range = arg_get_value (preferences, port_range);
  if (port_range == NULL || port_range[0] == '\0')
port_range = 1-15000;

  if (strcmp (port_range, -1) != 0)
{
  unsigned short *ports;
  ports = (unsigned short *) getpts (port_range, NULL);
  ^^^
  # Support for default imbedded within getpts above
  if (ports == NULL)
{
  auth_printf (globals,
   SERVER | ERROR | E001 - Invalid port range 
| SERVE

R\n);
  return -1;
}
}

Re impact:

FYI - I am seeing downstream impact, as amap.nasl and nmap.nasl
have explicit checks for the value default to control certain
behaviours.  That might be a non-trivial impact in terms of
expected behaviour/performance of nmap itself...

The specific use case for us is that we use the 'default' value
of nmap to control nmap's scan to scan any port below 1024 and
all known service ports that nmap has, and to then feed that
back into openvas.  It looks to me based on observations (haven't
run the actual tests yet), that this capability would now be
broken, as there would be no way of telling nmap to leverage this
default behaviour set.

I am guessing based on a cursory reading of the code that backwards
compatibility could be re-instated by modifying the check for
a string of -1 failure to be a check for failure of both
-1 and default...

I.e. change in attack.c

  if (strcmp (port_range, -1) != 0)

to

 if (strcmp(port_range, -1)!=0)  strcmp(port_range, default)!=0)


Anyone see any issues with what's been suggested?

Thomas

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

[Openvas-discuss] Subdirectory of scripts - some issues?

[Thomas Reinke]

Hi folks,

Some observations about the breakup of scripts into sub directories...

1) I notice on the CR ( http://openvas.org/openvas-cr-60.html ) that
   it indicates (paraphrased) that scripts are to be committed into
   subdirs (beginning with 2013) with exceptions being scripts that
   are to be a dependency of others.

   That would lead to the observation that perhaps it is not guaranteed
   to be able to use script dependenciese on files that reside in
   subdirectories?

   If so, then I have specific questions around the following:

  2014/gb_dell_sonicwall_email_security_detect.nasl

   As a detection script, it
   will possibly have others depending on it (in the future..could not
   find any today). Shouldn't detection scripts reside then in the base
   directory?

   The file 2009/conficker.nasl has a dependency on
   nmap_nse/gb_nmap_p2p_conficker.nasl, which raises the same question.

   So is the CR guidance correct and the scripts need to be adjusted?
   Or are the scripts fine, and the CR is overly restrictive?

2) Are script base filenames intended to be unique?  I am noting
   a number of instances where they are not.

   Nearly identical (same vuln tested), but with different script IDs:
  2012/gb_suse_2012_1637_1.nasl
  2013/gb_suse_2012_1637_1.nasl
   (This looks like a simple duplication issue, one should be removed?)

   Completely different scripts, CVE, etc, but with same name:
  2012/gb_hp_smh_csrf_vuln.nasl
  2014/gb_hp_smh_csrf_vuln.nasl

  2009/gb_php_display_errors_xss_vuln.nasl
  2014/gb_php_display_errors_xss_vuln.nasl

  2010/gb_getsimple_cms_mult_vuln.nasl
  2014/gb_getsimple_cms_mult_vuln.nasl

   Finally, a whole series of scripts have non-unique names in the GSHB
   series (e.g. GSHB_M5_147.nasl has 3 different version):

 ~/openvas-nvts/scripts$ find . -name GSHB_M5_147.nasl -print
 ./GSHB/EL11/GSHB_M5_147.nasl
 ./GSHB/EL10/GSHB_M5_147.nasl
 ./GSHB/EL12/GSHB_M5_147.nasl

Thomas


___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Subdirectory of scripts - some issues?

[Thomas Reinke]

On 16/07/14 01:59 PM, Michael Meyer wrote:


The file 2009/conficker.nasl has a dependency on
nmap_nse/gb_nmap_p2p_conficker.nasl, which raises the same question.


The directory structure is different between svn and feed. Any NVT from 
2008-2012
goes into the base diretory when copied to the feed.


I think you missed the issue on this one - conficker.nasl has an
explicit dependency of nmap_nse/gb_nmap_p2p_conficker.nasl.  That
implies that either
  a) The daemon does in fact support subdirectory based dependencies, or
  b) The script's dependency has been broken for a long time.

if a), then the CR's guidance is just that, guidance (best practice,
whatever), instead of a requirement.  If b, then something needs to be
fixed.

Thomas
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Server System Requirements

[Thomas Reinke]

Something to consider:

The number of nasl processes running (if we remove basic control
tasks from the picture)  is the number of hosts being scanned at
a time multipled by the number of scripts being executed by the
host.

How you configure the two numbers above will result in drastically
different memory footprint requirements:

E.g.  Let's say that we can support 100 simultaneous NASl scripts
  on the hardware in question (CPU mainly).

If we say we can run 2 hosts, 50 scripts simultaneously each,

   a) Memory usage on the scanner is low;
   b) Dependencies on scripts may limit effective parallel
  processing;
   c) You're throwing a lot of traffic at a given IP, and may
  not get ideal response if the scanned server gets too
  loaded;


If, we go the opposite route, and scan 50 hosts, 2 nasl scripts
at a time max, again,at most 100 simultaneous scripts, then

   a) Memory usage on the scanner sky rockets
   b) Very high effective use of parallel processing
   c) Long scan times per IP, because despite effective parallel
  processing, it takes long to get through all scripts for
  a given IP.
   d) Low bandwidth being thrown at a given target at any time.

So, how you configure your scanning environment is highly dependent
on what you need to accomplish.

I would suggest playing around with the settings mentioned, taking
it to a couple of extremes to see where you can take things. For
reference, we've still got some scanners working with only 1 Gig
of RAM (NOT something I would recommend doing if you are setting up
a new install!).

Hope that helps,

Thomas


On 07/07/14 08:24 AM, Geoff Galitz wrote:



A lot of this really depends on which and how many plugins you use as well
as the size of your target object.  You'll potentially see a lot of forked
processes.

FWIW, I have a 4CPU 16GB RAM VM to scan /23 size networks (approx 500
hosts) with virtually all plugins enabled and configured.

-G




As far as i am testing OpenVAS i didn’t need more then 2GB. But a few day
ago linux killed openvas because it eats to much memory...
I think i will take a quadcore with 4gb ram.


Am 07.07.2014 um 13:31 schrieb Reindl Harald h.rei...@thelounge.net:




Am 07.07.2014 13:26, schrieb Eero Volotinen:

Well, we are currently running two physical scanner servers and one
very large amazon instance for our PCI scanners ..

Usually servers are running quad core processor and 32GB to 128GB of
physical memory.
So, it's based on my experiences on real production environments.


no it's not

experience would be we tried it with less RAM but we had to
upgrade to 32 GB because it otherwise did not work and not
you need that much RAM because i have

the most RAM is needed for the feed-sync and with 3 GB you are normally
fine




Yes you are right, most of the time it will be a default scan config. It´s
okay if its not parallel, but it should not run just one scan a night.



Do you need to run a lot of scans in parallel, or can a scan run lazily
all night?
Do you want to brute force / enumerate logins, or do you just run
discovery scans.
Etc etc…


Thanks for your fast responses,
Rene
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss





--
Geoff Galitz
http://www.galitz.org

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss



___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] [], Author a OpenVAS 5.0 Vulnerability scanning and Management book for Packt.

[Thomas Reinke]

Well, maybe they're working the same angle as the Nigerians scams -
make an extraordinarily silly offer, so ridiculous, that if anyone
bites, you KNOW you have a sucker on the line.

I mean seriously - 100 pages of work to be done, in exchange, you
get...NOTHING. Really?

Here's a counter:  I offer a job in doing security consultancy work.
You will work 7.5 hours a day for 13 weeks over the next quarter. At
the end of it, I will give you a $150 loan.  If the product you
work on is brought to market at some indeterminate time in the
next 5 years, I will extend up to a $600 loan to you.  You will be
entitled to 16% commissions on all sales, with the any initial
commissions going to pay back any loan you may have taken from us.

Ok, I should be ashamed for having spent even this amount of time
to feed the troll...

Thomas

On 15/11/12 07:51 AM, Tim Brown wrote:
 On Tuesday 06 Nov 2012 10:14:39 Sumeet Sawant wrote:
 
 Could you please let me know if any one of you find it interesting to
 author this book?
 
 Please don't.  These guys have been spamming various @openvas.org mailing 
 lists over the last week.  I had hoped they would simply go away, but they're 
 simply becoming more agressive.
 
 Tim
 
 
 
 ___
 Openvas-discuss mailing list
 Openvas-discuss@wald.intevation.org
 https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Survey: Who uses OTP?

[Thomas Reinke]

On 30/10/12 11:29 AM, Jan-Oliver Wagner wrote:
 Hello OpenVAS users,
 
 I'd be very interested to find out how many users of the OpenVAS Transfer 
 Protocol
 (OTP) we still have.
 
 This is the protocol offered by the OpenVAS Scanner and in modern OpenVAS 
 releases
 the OpenVAS Manager is the only relevant client.
 
 Please reply on-list (preferred as it might interest the community in general)
 or off-list (if you prefer this) to the following questions in case you are 
 using
 OTP:
 
  * Have you implemented OTP with your own pograming lanuage and tools or
have you used API elements of openvas-libraries/openvas-scanner for this?

Implemented OTP client with own tools.

 
  * Which of the OTP commands did you implement?

On the sending side,

CLIENT | COMPLETE_LIST | CLIENT
CLIENT | GO ON | CLIENT
CLIENT | PREFERENCES |
CLIENT | PLUGINS_ORDER | -- | CLIENT
CLIENT | ATTACHED_FILE
CLIENT | LONG_ATTACK |

 
  * Which OTP commands do you really need in the future and which
could you drop?

The above list is the minimal list need to collect all scanner
information and to have the ability to launch a scan with any
arbitrary configuration.

 
  * Is OTP critical for your activities/processes?

Yes.

 
  * Is OMP an alternative for your OTP use case?
 

Arguably yes, but preferably no.  While technically we could use OMP,
there would be zero added benefit to doing so - we would literally
add overhead/infrastructure to replace a lean client/scheduling system
with one that is at best going to do what we already have in place,
at worst will add overhead and possibly not do what we already have.

If the protocol was changed, we would likely prefer to leverage the
replacement protocol instead of using OMP.

 
 Your answers will help developers to judge about the future of OTP.
 So far it is fully maintained across all stable OpenVAS releases.
 But OTP has several drawbacks and design issues and it is desirable
 to have a leaner OTP version as well as a new, more advanced, protocol.
 
 All the best
 
 Jan
 


Cheers, Thomas
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Local security checks privileges

[Thomas Reinke]

Depends on the distribution/OS being checked.

For Linux distributions, you typically need to be able to run

uname -a
rpm, dpkg, or have read access to certain directories.

I'm probably missing some, but afaik, most of the LSCs can
run with any login credential, as the above commands are
not priviledged when used in read-only as is being done
by the scanner.

You can check gather-package-list.nasl and view the logic
yourself there.

Thomas

On 16/08/12 08:17 PM, Juan José Pavlik Salles wrote:
 Hi, how much privileges does the local sec check user need to run?
 
 
 
 ___
 Openvas-discuss mailing list
 Openvas-discuss@wald.intevation.org
 http://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Not scanning machines which don't respond to pings

[Thomas Reinke]

On 11/08/12 05:51 AM, Michael Meyer wrote:

 Not allowing ping makes _no_ security gain. Denying ICMP is mainly
 only useful in the Security By Obscurity model. Security By
 Obscurity, however, is completely useless.

This is simply not true.

It is well understood that to RELY on security by obscurity is
dangerous, and that it will not be sufficient to determine a determined,
resourceful, skilled attacker.

By the same token, it adds a layer of protection, however minimal,
that can reduce the overall risk profile.  This can have the effect
of anything from reducing the likelihood of certain types of
attacks succeeding (script kiddie scans of certain service types),
to buying anything from hours to days (or more) to patch vulnerable
systems that might be susceptible to zero day exploits.

If you look at only a black and white absolute (vulnerable or not), then
yes, security through obscurity does nothing to the binary evaluation of
the vulnerability status of a system.  But here's the catch - EVERY
system is by definition vulnerable to a network based attack, unless you
airgap it (unless you want to assert that a given system has achieved
perfection - I'll take a bet with you any day that we've not achieved
that anywhere yet).

At the end of the day, we are not worried about whether or not a system
is vulnerable - no airgap, no guarantee of security, so we can really
only look at reducing, as low as possible, for as reasonable a $ amount
as possible, the risk of experiencing a compromise, and to limit the
exposure should a compromise take place.  And for that, security by
obscurity approaches add a cheap, non-zero valued additional benefit.

Thomas

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] openvas4 scanning vhosts

[Thomas Reinke]

This is a long standing issue, I know this was discussed several years 
back in one of the DEVCONs (3 years ago I believe).  I thought at one

point there was a CR written on this, but I can't seem to find it?

Perhaps someone else that was involved at the time can refresh our
collective memories?

I know that the work involved to make this happen was non-trivial, and
there was a certain level of discussion on how to handle common
scenarios where there are many (sometimes 2,3, sometimes hundreds if
not more) virtual hosts on a single IP.  The issue there was that scans
are IP based, so support for virtual hosts needed to decide how to
handle the many (vhost) to one (IP) mapping, and what kinds of limits
to put around it.

As far as I know, no one ever had significant time/bandwidth to resolve
this issue.

Thomas


On 28/05/12 04:54 PM, Reindl Harald wrote:

what do you mean with host records are correct?
if you mean matching PTR -  no, no and again: no
it is a bgu in openvas that if you configure
a hostname as target the default vhost is accessed
due missing host headers from the scanner

Am 28.05.2012 22:31, schrieb Scott Damron:

You need take sure the open as server can resolve DNS.  If using internal DNS 
servers, make sure your host records
are correct.

On May 28, 2012 2:28 PM, Juan José Pavlik 
Sallesjjpav...@gmail.commailto:jjpav...@gmail.com  wrote:

 Hi, is it possible to make openvas scan a server with its hostname instead 
of its IP address? I've created a
 target with its hostname but it doesn't work.




___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss


___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Fwd: CVE-2011-0539 - Medium?

[Thomas Reinke]

We need to distinguish between *potential* customer impacts
and *real* customer impacts on a given network.

Vulnerability scanners can *NEVER* fully understand the network
they are auditing and what the true impact of an issue is.
That's the job of an auditor, not a free tool.

If a vulnerability has the potential for being a critical
vulnerability (e.g. root exploit against IIS), but is a
non-event on your network because of how you've filtered
things using an Apache reverse proxy, does that mean it should be
reported as Low as opposed to Critical?

The scanner will (and in my opinion SHOULD) always report
what the potential is for a vulnerability.  It is up to the
auditor to then examine this in the context of the network
setup to decide if the issue needs remediation or not, and
if so, what sense of urgency is associated with it.

The problem here is not the scanner - it is using the scanner
in an appropriate way. If an auditor is (and I say this
in the context of providing auditing services to thousands
of customers) is claiming that because their scanner is
finding a vulnerability that the issue must be repaired
or the service stopped, without providing even basic due
diligence on the impact of that vulnerability, then either
fire the auditor (or if you are the auditor, rethink your
business plan).

Thomas

Reindl Harald wrote:
 On 22.12.2011 03:00, Christian Kuersteiner wrote:
 The scanner doesn't know if /admin or /myprivatedocs is something worth 
 to report or not but you know as you know your setup.
 
 exactly - the scanner does not know
 
 and if he can not classify what he finds it should be low
 or even informational and not middle
 
 I think the way to  go is in general to make a override of the thread if 
 it doesn't match  with your risk assessment.
 
 you do not understand the problem:
 
 a big client makes security audtis via a third party
 they start automated scans, provide the result and say
 Middle has to be fixed or the site has to go down
 
 so, the robots.txt is a part of fully autmativally
 deployed system for  100 customers and i have no
 understanding change things because some foreigner
 outside is able to start a scan-software and decides
 global changes :-(
 
 On the other side I agree that robots.txt is not a medium risk but would 
 rather mark it Low than None for the reason stated above
 
 please yes!
 
 currently it makes robots.txt unuseable for companies which
 which have a secaudit once each week
 
 
 P.S.:
 i fixed CVE-2011-0539 by rebuild the Fedora1 6 openssh on our F15
 buildservr and deploy the new openssh. But not all users out there
 have the knowledge and infrastructure to do so
 
 they are forced to a distribution upgrade with classification Middle
 where the is no real reason
 
 
 
 
 
 
 
 ___
 Openvas-discuss mailing list
 Openvas-discuss@wald.intevation.org
 http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] false positives and version detection

[Thomas Reinke]

Right now, local security checks (LSC) and the banner security checks
are independent of each other.  The local security checks are accurate,
while the banner security checks suffer from fp hits on certain linux
distros due to how backports are done to older versions of software to
fix problems.

Historically, banner checks cannot know if you are vulnerable by
checking only the version banner.  If version 5.2.6 is vulnerable
and 5.2.7 is not, we have a problem - debian will not report
5.2.6.lenny13 or some such, only 5.2.6, even if it is patched.

Moving on to local security checks, these report accurately.

So with that as a base, how to remove false positives on the banner
checks in a scan that also has information on local security checks?
Two ways:

1) We disable the banner checks if a local security check was run.

   Minor issue of scheduling, to ensure that the LSCs are run
   before banner checks.  Each banner check would need to be
   modified to have a dependency on an LSC (probably something
   like gather-package-list.nasl), and then to be disabled
   if a recognized, supported linux distro is detected.

2) Use a more granular approach - up report the version of
   a package on a system that matches the backported version
   found in a distro.  With the example given above, record the
   fact that version 5.2.7 is on the system when we detect that
   version 5.2.6.lenny13 is available.

   This is a very large administrative headache. It's been tried
   once before, and failed.  It requires that each and every
   LSC be examined, and a mapping be created from the detected
   version to the actual upstream version.  It is also not fool-proof,
   as distros tend to cherry pick their backports.  You have no
   guarantee now that up reporting (using the above example) from
   5.2.6 to 5.2.7 actually means you are running a full 5.2.7.
   In fact, it is almost a guarantee that you are NOT.
   That introduces certain risks.

3) A even more granular approach of flagging that an LSC detecting
   a version of 5.2.6 is NOT vulnerable to certain reported issues,
   such as CVE--.

   This may in fact be the easiest approach, as all LSCs have the
   relevant CVEs that they address in their script.  It does
   mean, however, that a banner check needs to ensure it has the
   relevant CVE information in it's logic, and their is an
   infrastructure development effort that needs to happen within
   the daemon to cope with communicating the critical CVE
   dependency information from LSC to banner check in a way that
   is useful and usable.

#3 above may be the cleanest approach, as it is (IMHO),

  1) The simplest from a maintenance perspective.  Once infrastructure
 is in place to support it, banner check writers simply need to
 ensure that they reference the appropriate CVE, and if a system
 is detected with software that has that CVE entry addressed, simply
 refuse to report a vulnerability, thereby removing the FP.

  2) It limits the shotgun approach of #1 (which sort of throws out
 the baby with the bathwater), and avoids the maintenance headache
 of maintaining backport correlation information in #2)

but #3 DOES come up with a big scheduling and possible performance and
memory headache associated with having all tested CVE information be
known and on-file, and available for use, and ensuring that banner
checks are always run after LSCs. (almost sounds like a candidate for
putting LSCs into a specific scheduling level that guarantees they
are run before banner based checks).

Just some idle thoughts on the subject.

Thomas


Stefan Schwarz wrote:
 Am 05.10.2011 18:32, schrieb Thomas Reinke:

 So that's not a local security check.  Local security checks are those
 that are done by having had the ability to ssh directly into the box
 in question, and grab the actual deployed RPMs/packages.

 Are there false positives that are truly generated from local security
 checks?

 Thomas
 []
 The problem is not in using local security checks. You'll always get
 these false positives. An example:
 
 Results from an actual scan on Debian 5 with up to date packages show
 about 11 FPs marked High about PHP.
 PHP is declared to be 5.2.6, which is derived from PHPs signature
 5.2.6.dfsg.1-1+lenny13. Looking at
 http://packages.debian.org/changelogs/pool/main/p/php5/php5_5.2.6.dfsg.1-1+lenny13/changelog
 you can verify that this is the most actual package and all the issues
 found by OpenVAS/GSM are fixed.
 
 This is also true when doing local security checks.
 
 Stefan
 
 
 
 
 ___
 Openvas-discuss mailing list
 Openvas-discuss@wald.intevation.org
 http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/mailman

Re: [Openvas-discuss] false positives and version detection

[Thomas Reinke]

Which tests are tripping false positives?  The local security checks
should not be tripping false positives, certainly not those that are
based on direct examination of rpms, dpkgs, etc.

Thomas

ArkanoiD wrote:
 I was really disappointed to see that even local checks on RHEL family do
 not remove false positives -- though requesting package patchlevel is trivial.
 
 Is there any effort to fix that ongoing?
 
 ___
 Openvas-discuss mailing list
 Openvas-discuss@wald.intevation.org
 http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss
 

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] false positives and version detection

[Thomas Reinke]

So that's not a local security check.  Local security checks are those
that are done by having had the ability to ssh directly into the box
in question, and grab the actual deployed RPMs/packages.

Are there false positives that are truly generated from local security
checks?

Thomas

Thibaut PIRONNEAU wrote:
 For example on an up to date CentOS 5.7, I have a lot of apache, php, 
 mysql alerts... But it's not a local scan. My scanner is on an other 
 machine, but in the same network.
 
 Le 05/10/2011 15:54, Thomas Reinke a écrit :
 Which tests are tripping false positives?  The local security checks
 should not be tripping false positives, certainly not those that are
 based on direct examination of rpms, dpkgs, etc.

 Thomas

 ArkanoiD wrote:
 I was really disappointed to see that even local checks on RHEL family do
 not remove false positives -- though requesting package patchlevel is 
 trivial.

 Is there any effort to fix that ongoing?

 ___
 Openvas-discuss mailing list
 Openvas-discuss@wald.intevation.org
 http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

 ___
 Openvas-discuss mailing list
 Openvas-discuss@wald.intevation.org
 http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

 
 

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Scanning a whole net?

[Thomas Reinke]

As an FYI, you should be able to, without excessive extra load on the
server, up the number of max_checks run concurrently per IP without
significant increase in memory on the server running the check.

Increasing concurrent hosts, for each IP, adds a non-trivial overhead
in memory to the system - that's the big hit. If you want to increase
one of these on a memory constrained system, go for an increase in
max_checks before increase in max_hosts.

If you DO increase the max_checks, be careful, because at somepoint,
the scanner may start loading the scanned server to the point where
reliability may suffer.

Thomas

Roy Sigurd Karlsbakk wrote:
 - Any idea how I can get rid of this?
 Try restart the Manager.
 
 Tried that, no luck, but I resorted to removing the entry from the database 
 (/var/lib/openvas/mgr/tasks.db). Hope that doesn't break anything...
 
 - Is there a way to limit parallel checks to a certain amount of
 hosts,
 or should I split up the network for checks from this rather antique
 box?
 My netbook with 1GB struggles to run the full set of OpenVAS
 components
 reliably.

 The Scanner preferences max_hosts and max_checks control the number of
 concurrent hosts and NVTs.
 
 I found out, after some trial and error. Had to create openvassd.conf - it 
 wasn't there and the values in openvasd.conf didn't change anything. Running 
 now with rather low values for those, and it seems the server can handle it.
 
 Thanks a bunch
 
 roy
 --
 Roy Sigurd Karlsbakk
 (+47) 97542685
 r...@karlsbakk.net
 http://blogg.karlsbakk.net/
 --
 I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det 
 er et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av 
 idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og 
 relevante synonymer på norsk.
 ___
 Openvas-discuss mailing list
 Openvas-discuss@wald.intevation.org
 http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Debian Local Security Checks out of date ?

[Thomas Reinke]

Laurent Rossier wrote:
 Hi Thomas,
 
 03/08/2011 14:14, Laurent Rossier wrote :
 03/08/2011 04:26, Thomas Reinke wrote :
 Updates are coming.  There were a few delays after it was pointed out
 that a couple previous nasl scripts were incorrect.  This forced a
 re-evaluation of the generation process and a rework.
 
 Thanks for having fixed this.
 
 Is it possible to also include the reported date in the
 script_description (for example, 28 Jul 2011 for DSA 2288, available
 here http://www.debian.org/security/2011/dsa-2288) ?
 
 About that, I can give you a patch for the current nvts which adds this
 date in the description.
 But I don't have access to the generation process so I cannot modify it
 for the future ones.
 

I don't see a particular problem with this, but I guess the bigger issue
in my mind is if this is something that should be done consistently
across ALL local security checks.  When we built the generators, we
tried to provide a level of consistency in how they were built across
all distributions.

What we've done, in general, is to keep the amount of information within
the test to a reasonable minimum (that is of course a subjective
judgement call), but to then reference other resources. That includes
always including within the script a reference to the actual advisory.

So I guess, at end of day, I would lean towards not putting that
information into the nasl (but that's a soft leaning - am willing
to be convinced otherwise).

Thomas
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Debian Local Security Checks out of date ?

[Thomas Reinke]

Laurent Rossier wrote:
 Hi,
 
 It seems that the nvts are out of date : the last one is about DSA 2230 
 but the last official DSA is 2288.
 Is this a known issue ?
 
 Regards,
 

Updates are coming.  There were a few delays after it was pointed out
that a couple previous nasl scripts were incorrect.  This forced a
re-evaluation of the generation process and a rework.

New scripts are coming within the next couple minutes.

Thomas

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Associating NVT's with CVE's

[Thomas Reinke]

If you have the NVT's and the specific CVE's, if you post it to the list
I'm quite sure it will be taken care of by someone relatively quickly...

Thomas

Alicia Smith wrote:
 Who would I e-mail to provide a list of NVT’s that do not have
 associated CVE’s listed?
 
  
 
 Alicia Smith
 Security Operations Supervisor
 
 Tel. 214-292-8152 Fax 214-720-1836
 
   
 
 NeoSpire Managed Hosting
 
 
 
 website http://www.neospire.com/ | map
 http://www.neospire.com/contact.information/location.phone.numbers.php
 | email mailto:sbru...@neospire.net
 
   
 
 WE SECURE TRUST
 
  
 
  
 
 
 
 
 ___
 Openvas-discuss mailing list
 Openvas-discuss@wald.intevation.org
 http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Is Openvas multi-processor aware?

[Thomas Reinke]

Yup - the # of CPUs you can take advantage of depend on the number of
concurrent IPs you are testing, and the number of concurrent tests for
each IP.

Each IP tested is a separate governing process, and each test for that
IP spawns a separate process again, so it will happily gobble up as many
cores as you can throw at it.  Based on experience, once you get to 4
cores (with lots of memory!) you'll easily run into network bandwidth
issues before you run into processor issues.

Thomas

Alicia Smith wrote:
 Is openvas multi-processor aware?
 
 I am currently running openvas on some xen  guests, but wondered if they
 could benefit from multiple cpu’s?
 
  
 
 Thanks,
 
  
 
 Alicia
 
 
 
 
 ___
 Openvas-discuss mailing list
 Openvas-discuss@wald.intevation.org
 http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Openvas-client as a nessus client

[Thomas Reinke]

The protocols are not compatible with each other, so no, you cannot
use openvas-client on nessusd or nessus client against openvassd.

Thomas


Stefano Gargiulo wrote:
 Hi, in debian packages openvas-client replaced nessus client.
 
 Now i'm asking, can i use openvas-client as a nessus client (against a
 nessus 4 server?)
 
 How to specify the protocolo version to nessus and not openvas? i can't
 find this in the man.
 
 
 
 
 ___
 Openvas-discuss mailing list
 Openvas-discuss@wald.intevation.org
 http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Openvas-client as a nessus client

[Thomas Reinke]

Thomas *smacks* self and reminds self to read the _entire_ thread before
replying!

 But if I was writing or adapting an NTP based java client surely I could
 code it in such a way that it could switch between NTP and OTP...
would this
 be enough for the client to work with Nessus and OpenVAS???

 Derek.

The changes to the protocol are minor.  If you are familiar with one
protocol, the changes to implement the other is trivial. (Hint - we
have a stripped down custom client, for both OTP/NTP, and the code
changes between the two different clients amount to 5 lines of code.)

The responses between the two will probably start to diverge more
and more over time, so you may want to put some thought into what
you will do as the OTP protocol changes and migrates further away
from NTP.

Thomas

Thomas Reinke wrote:
 The protocols are not compatible with each other, so no, you cannot
 use openvas-client on nessusd or nessus client against openvassd.
 
 Thomas
 
 
 Stefano Gargiulo wrote:
 Hi, in debian packages openvas-client replaced nessus client.

 Now i'm asking, can i use openvas-client as a nessus client (against a
 nessus 4 server?)

 How to specify the protocolo version to nessus and not openvas? i can't
 find this in the man.


 

 ___
 Openvas-discuss mailing list
 Openvas-discuss@wald.intevation.org
 http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss
 
 ___
 Openvas-discuss mailing list
 Openvas-discuss@wald.intevation.org
 http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss
 

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Many findings when scanning Debian lenny?

[Thomas Reinke]

Hartmut Goebel wrote:
 Am 28.04.2010 18:38, schrieb Vlatko Kosturjak:

 Few of them:

 - Use local security checks if possible.

 Unfortunately not practicable in our case :-(. (Esp. since the
 requirements for local checks are not well documented.)

Requirements are that the scanner has permissions to a shell
account on the platform being audited, and that this account
has access to the commands

   uname
   cat
   dpkg


 - Turn off Safe checks. Did not check the particular NASL(s) you
 mention. but if there's correct implementation, safe check would check
 for vulnerability harder. With safe checks, usually it checks
 banners/versions.

 Uff, this will become hard, since I assume these are not grouped into a
 family.

I believe this is a single configuration setting that in most cases
will apply to all tests that have a choice of making a banner check,
vs a more thorough vulnerability check. It would apply to all scripts
across all families that operate in this dual mode.

Thomas
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Informing that identified services have stopped being available during a scan

[Thomas Reinke]

Welll my first instinct would be to ask if there is any way to
uniquely identify these particular embedded servers via a banner,
and to then specifically generate a warning on exactly this issue.

If the above is not possible, I'd probably go for the approach of
ensuring that one particular plugin (a new one?) replicates the
problem (albeit probably not in safe mode), and then if a server
is found that trips on this, report the issue in a possibly
generic fashion, enumerating the problem with having the server
be temporarily unavailable during the audit.

Hmm... would it make any sense to have one of several different
type of connectivity meters running during an audit, and report
on unexpected outages?  I'm thinking something like the host up
measure using TCP/ICMP connectivity checks at the start of an
audit.  Instead, however, how about running these, if they are
able, at a low level through an audit, Then, at the end of an
audit, report on any anomalous readings.  You could probably do
this through a plugin that continuously updated the kb with
detected outages as they are in progress, and have one of the
last scripts run have the means to terminate the plugin and
report on the results.

My thoughts above are related to the fact that we see this problem
regularly, and it's not always due to the equipment being audited.
Sometimes network hiccups cause outages for minutes or more at a
time.  Sometimes IPS' kick in.  There's all sorts of reasons why
an audit may be incomplete, which can affect any plugin. A generic
solution might be in order.

Thomas

Jonas Andradas wrote:
 Hello,
 
 together with Michael Meyer, we found out that running several plugins
 against some embedded web servers, on APC UPS or Enterasys switches,
 froze those services for a while (about 3 minutes on APC UPS and 30-40
 seconds on Enterasys switches). Along with the HTTP service, Telnet, FTP
 or SSH services also stopped responding, but how to handle this is
 another issue.
 
 The problem with causing a temporary failure on the service is that,
 while the service is down, other plugins are still run against the host.
 Some even for the same service or port. When this happens, these plugins
 don't report or get any results, as they cannot perform the checks they
 need to. 
 
 I was wondering if it would make sense to provide these plugins or the
 OpenVAS server/scanner with same awareness on this issue, which would
 get reported at the end of the scan. For example, if on the KB the
 presence of a web server on port 80 is noted, and after running plugins
 that use this port, they exit because of a timeout or the server not
 responding, this could be seen as if something might have caused the
 service to stop working.  If on the report a note is included, saying
 something like A Web Server was found running on this port, but some
 plugins could not perform their checks because at times during the scan,
 the service was found unavailable, one could re-run the test with some
 other options.
 
 Probably it includes lots of work, but if instead of a simple note as
 the one I said before, a more complete/complex one is provided,
 specifying a list of plugins run against the service/port correctly and
 a list of failed plugins, a re-scan could be performed without the
 successful plugins which, if enabled, could cause again the temporary
 DoS and prevent the failed plugins to report correctly.
 
 I tried to specify the problem and the idea the best I could but,
 please, if something I am talking about is not clear, tell me and I'll
 try to explain myself better.  I don't know if this issue happens very
 often, but I guess that, running with safe-checks disabled could cause
 more than one DoS to be successful, but any tests done after it the
 first one, or if the service recovers by itself, between the first time
 and when the service is available again, would not provide an accurate
 result, maybe resulting in false negatives.
 
 Best Regards,
 
 Jonás
 
 
 
 
 ___
 Openvas-discuss mailing list
 Openvas-discuss@wald.intevation.org
 http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] OpenVAS - SSL Error

[Thomas Reinke]

Not 100% sure, but I thought that the ability to do client
server connections in plaintext had been removed in favour
of forcing all protocol communications over SSL.  If I'm
right, it would mean the ssl_version=none config item
shouldn't be allowed anymore, and it would explain why you are
getting the SSL connect errors.

Thomas

SECInfy Team wrote:
 Hi,
 
 I am using OpenVas 2.0.1 and I have installed openssl-0.9.8k
 
 I have configured no SSL in SSL server configuration y setting following 
 options
 
 # vi /etc/openvas/openvasd.conf
 ssl_version=none
 
 When I try to connect to server with following command from command line 
 openvas client, I get error
 
 OpenVAS-Client --batch-mode=10.184.155.159 9390 openvas openvas 
 /root/inputdir/tst1_1011091505226389759381372567510.txt 
 /root/reportdir/tst1_101109150522.xml --output-type=xml -x -V
 
 I get following error
 [11989] SSL_connect: error::lib(0):func(0):reason(0)
 OpenVAS-Client : SSL error
 
 Can someone please help me in troubleshooting this issue.
 
 Please let me know if you need any further information.
 
 Regards
 Hemil
 ___
 Openvas-discuss mailing list
 Openvas-discuss@wald.intevation.org
 http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss
 

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Vulnerabilities detected in !packages not installed!

[Thomas Reinke]

Hi David,

Could you give me some more details.  Which tests have tripped
positive for starters. And if possible if it doesn't violate
your security policies, the resulting file after running the
command on the target system:

COLUMNS=200 dpkg -l /tmp/pkg.list

Thomas

David Corcuera wrote:
 Hi list,
 
 As 'Subject' says, a scan have found some vulnerabilities in packages 
 not installed as openoffice.org, cups, avahi, xterm, ffmpeg-debian, 
 iceweasel, ... and moe.
 Plugins chosen are Debian Local Security Checks.
 Can you give me a tip to investigate?
 
 Thanks
 dav
 
 ___
 Openvas-discuss mailing list
 Openvas-discuss@wald.intevation.org
 http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss
 

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Possible false positives with CUPS and MySQL?

[Thomas Reinke]

Michael Meyer wrote:
 *** Michael Wiegand michael.wieg...@intevation.de wrote:
 * Chandrashekhar B [ 8. May 2009]:
 Instead we could add a statement with the description, This may be a
 False Positive
 Yes, I think this would be a good idea. We could define a standard
 disclaimer text which plugins could use whenever they try remote version
 identification.
 
 Ok, somebody must define this disclaimer. Any volunteers? :-)
 I saw that the newest plugins from secpod contains the following:
 
 *
 NOTE: Please, ignore the warning if Patch is already applied.
 *
 
 Is that enough?
 
 Micha


Something a bit more explanatory might be appropriate.  Perhaps

NOTE: This test relied on version number information retrieved
from a banner, and as such may be a false positive. Please ensure
you have the latest updates applied.

or

NOTE: This test relied on version number information retrieved
from a banner.  If the OS vendor's banner number identification
scheme isn't in line with the software's version number scheme,
this test might be a false positive.  Please ensure you have
the latest updates applied.

Thomas



___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Definitive list of client preferences

[Thomas Reinke]

The definitive list is subject to change from time to time.  While
not encouraged due to UI bloat, any NASL script can define a
preference that the UI is then supposed to display and allow input
on.

To see them all, simply go to the plugins directory and enter

$find -exec grep -H script_add_pref \{\} \;

Thomas

Shawn Duffy wrote:
 As I've mentioned before, I'm in the process of developing a web
 frontend to OpenVAS.  I'm currently working on building custom scan
 templates and profiles.  In order to do so, I need to be able to store
 client preferences in the database.  But I can't seem to find a
 definitive list of the available client preferences.  There is a list
 in the OTP docs but it doesn't appear to be complete:
 
 http://www.openvas.org/compendium/otp-preferences.html
 
 Is there a definitive list somewhere of all the possible preferences a
 client could send to the server?
 
 Thanks!
 Shawn
 ___
 Openvas-discuss mailing list
 Openvas-discuss@wald.intevation.org
 http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss
 

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Ubuntu package inc

[Thomas Reinke]

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-us2.4.1-1ubuntu2.1

 when you run dpkg -l, it returns,

 openoffice.org-help-en-us1: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@wald.intevation.org
 http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss
 

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] OTP help

[Thomas Reinke]

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

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Duplicate plugin IDs

[Thomas Reinke]

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

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Duplicate plugin IDs

[Thomas Reinke]

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-boun...@wald.intevation.org
 [mailto:openvas-discuss-boun...@wald.intevation.org] On Behalf Of Shawn
 Duffy
 Sent: Thursday, March 05, 2009 4:57 PM
 To: openvas-discuss@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@wald.intevation.org
 http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss


 ___
 Openvas-discuss mailing list
 Openvas-discuss@wald.intevation.org
 http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss
 

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Duplicate plugin IDs

[Thomas Reinke]

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@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Draft announcement for OpenVAS DevCon2

[Thomas Reinke]

Looks fine from here.

Thomas

Jan-Oliver Wagner wrote:
 Hello,
 
 I'd like to announce the DevCon2 to the openvas-announce mailing list.
 Here is a draft, what do you think?
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Nasty variable scoping booby-trap

[Thomas Reinke]

Michel Arboi wrote:
 On Sun, May 18, 2008 at 11:14 PM, Jan-Oliver Wagner
 [EMAIL PROTECTED] wrote:
 Are you saying that Thomas is wrong?
 
 Or at least, not very precise.
 
 Maybe I already had it.
 Are you saying you even implemented this already?
 
 IIRC, since the beginning of NASL2.
 
 Why are you in doubt?
 
 I am not in doubt.

NASL2 demonstrates this problem very clearly.  The
examples I previously cited highlighted it.
But for those who might question that I completely screwed
it up, let me be more explicit by way of example:

Script:

$cat testme.nasl
#!/usr/local/bin/nasl

if(description)
{
script_d(1);
}

function testme(port)
{
 x = 5;
}

x = 1;
display(string(x, \n));
testme(port:22);
display(string(x, \n));



Now, results from running this against both 2.1.0 as well
as 2.2.5 (on which OpenVAS is based):

$ which nasl
/usr/local/bin/nasl
$ nasl -v
nasl 2.1.0

Copyright (C) 1999 - 2003 Renaud Deraison [EMAIL PROTECTED]
Copyright (C) 2002 - 2003 Michel Arboi [EMAIL PROTECTED]

See the license for details


$ ./test.nasl
** WARNING : packet forgery will not work
** as NASL is not running as root
1
5

snip complete removal and reinstall of nessus 2.2.5

$ nasl -v
nasl 2.2.5

Copyright (C) 2002 - 2004 Tenable Network Security

See the license for details

$ ./test.nasl
** WARNING : packet forgery will not work
** as NASL is not running as root
1
5

Both of these results demonstrate quite clearly how the author of
a function testme can use a variable x that has no explicit
declarations, intend the variable to be local, yet have consequences
that the caller's scope is used.  All of the previous examples
I cited were examples of this problem.  In many cases, it was
obvious that authors _attempted_ to avoid the problem by using
local_var constructs.  But since they in many cases forgot
to do so, or missed one or more variables, the problem persists.

Perhaps Tenable has gone ahead and corrected the scripts themselves
to avoid this situation.  It does not, address the root problem,
which through inheritance, OpenVAS has in the daemon.

If I'm wrong, _constructive_ criticism is more than welcome.
But, unless I misunderstand when NASL2 was released, I don't
think I've made a mistake here.

Thomas

___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] [Openvas-devel] Voting on Change Requests #1 - #4

[Thomas Reinke]

#1 Adding script_oid(): In favour.
#2 Insufficient knowledge of use scenarios to form a vote opinion, but
comments as follows:

NSR is, AFAIK, not broken w.r.t semi-colons.  The actual NTP
protocol has the same issue of being line oriented - the server
replaces all semi-colons with newlines. NSR just carries this
issue through to its code. Thus removing NSR does not solve
the semi-colon issue, that can only be done by adding
support to both client and server to support escaped semi-colons.

As such, using the semi-colon problem as a justification to remove
NSR doesn't make sense.

#3 Removal of plugin factory: In favour.
#4 Plugin upload: In sufficient knowledge of use scenarios
to form a vote opinion.

Thomas

Jan-Oliver Wagner wrote:
 Hi,
 
 I'd like to call for voting on the change requests #1 - #4,
 listed here:
   http://www.openvas.org/openvas-crs.html
 
 Naturally, I am in favour of all 4 of them :-)
 However, please read and judge whether it is a good
 or bad idea or wether it needs further refinement.
 
 I am not totally sure about the proper voting scheme.
 Tim, Robert: Does SPI require something special or
 do we just decide upon a simple voting?
 
 Best
 
   Jan
 ___
 Openvas-devel mailing list
 [EMAIL PROTECTED]
 http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
 ___
 Openvas-discuss mailing list
 Openvas-discuss@wald.intevation.org
 http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss
 

___
Openvas-devel mailing list
[EMAIL PROTECTED]
http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

Re: [Openvas-discuss] Some last Plugins license issues (urgent)

[Thomas Reinke]

Renaud Deraison wrote:
 On Jul 26, 2007, at 11:17 PM, Jan-Oliver Wagner wrote:
 
 
 Anyone has pointers for any email, archived web page, or otherwise,
 that made it clear that scripts released, for example, in the 2.1.0
 timeframe, or scripts that were updated via the GPL-feed update  
 mechanism,
 were not under the GPL?
 
 You and I already discussed this over the phone several months ago  
 and you were very aware of the situation since that's why you could  
 not distribute the Tenable plugins in the BOSS CD you made.
 
 It's not like anything is new here :
 
 http://mail.nessus.org/pipermail/nessus/2004-December/010655.html

Any announcement earlier than this?

By the time this announcement went out, wasn't the cat supposedly
out of the bag already?  I.e. in 2004-July timeframe (Nessus 2.1.0)
hundreds of plugins were already released by Tenable, with Tenable
copyright, in a fully GPLed distribution.  And these scripts
continued to be updated via nessus-update-plugins, taking the total
to well over 1700 scripts, released with a Tenable copyright, under
the GPL, before this announcement ever came out.

Unless of course I missed an earlier announcement changing the policy
of components of Nessus (i.e the plugins) moving from GPL to a non-
GPL license?

Thomas
___
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss