[Openvas-commits] r1093 - in trunk: doc/openvas-compendium openvas-compendium

scm-commit@wald.intevation.org scm-commit at wald.intevation.org
Fri Aug 1 20:08:05 CEST 2008

Author: jan
Date: 2008-08-01 20:08:03 +0200 (Fri, 01 Aug 2008)
New Revision: 1093

Added:
trunk/openvas-compendium/openvas-compendium.tex
Removed:
trunk/doc/openvas-compendium/openvas-compendium.tex
Modified:
trunk/openvas-compendium/ChangeLog
Log:
Moving openvas-compendium.tex to the openvas-compendium module.

Deleted: trunk/doc/openvas-compendium/openvas-compendium.tex
===================================================================
--- trunk/doc/openvas-compendium/openvas-compendium.tex	2008-08-01 17:58:36 UTC (rev 1092)
+++ trunk/doc/openvas-compendium/openvas-compendium.tex	2008-08-01 18:08:03 UTC (rev 1093)
@@ -1,2417 +0,0 @@
-% OpenVAS
-% $Id$
-% Description: The OpenVAS Compendium
-% Note, that this a HyperLaTeX source and not plain LaTeX!
-%
-% Authors:
-% Jan-Oliver Wagner <jan-oliver.wagner at intevation.de>
-% Michael Wiegand <michael.wiegand at intevation.de>
-% Tim Brown <timb at nth-dimension.org.uk>
-%
-% Copyright:
-% Copyright (C) 2008 Intevation GmbH
-% Copyright (C) 2008 Tim Brown
-%
-% This program is free software; you can redistribute it and/or modify
-% it under the terms of the GNU General Public License version 2,
-% as published by the Free Software Foundation
-%
-% This program is distributed in the hope that it will be useful,
-% but WITHOUT ANY WARRANTY; without even the implied warranty of
-% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-% GNU General Public License for more details.
-%
-% You should have received a copy of the GNU General Public License
-% along with this program; if not, write to the Free Software
-% Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
-
-\documentclass[a4paper,11pt,twoside,titlepage,dvips]{scrbook}
-\usepackage{hyperlatex}
-\usepackage{a4wide}
-\usepackage{times}
-\usepackage[latin1]{inputenc}
-\usepackage[T1]{fontenc}
-\usepackage{ifpdf}
-\T\ifpdf\usepackage[pdftex]{graphicx}\else\usepackage{graphicx}\fi
-\W\usepackage{graphicx}
-\usepackage{alltt}
-\usepackage{moreverb}
-\usepackage{fancyhdr}
-%\W\usepackage{rhxpanel}
-\W\usepackage{sequential}
-\W\htmldirectory{./html}
-
-
-
-\newcommand{\IncludeImage}[2][]{\texorhtml{%
-\begin{center}%
-\ifpdf
-  \DeclareGraphicsExtensions{.png}
-  \includegraphics[#1]{#2.png}%
-\else
-  \DeclareGraphicsExtensions{.eps}
-  \includegraphics[#1]{#2}%
-\fi
-\end{center}%
-}{%
-\htmlimg{../#2.png}%
-}}
-
-% Hyperref should be among the last packages loaded
-\usepackage{hyperref}
-
-
-\newcommand{\compendiumversion}{0.1.0-svn}
-\newcommand{\compendiumdate}{20080708}
-\newcommand{\compendiumauthor}[1]{\begin{small}(by {#1})\end{small}}
-\newcommand{\hyperurl}[1]{\htmlonly{\xml{p}\small
-\xlink{{#1}}{{#1}}\xml{br}}\texonly{\small{#1}}}
-
-% for a consistent appearance of key names
-\newcommand{\openvasd}{openvasd}
-\newcommand{\openvasnvtsync}{openvas-nvt-sync}
-
-\T\fancyhead{} % clear all fields
-\T\fancyhead[LO,RE]{OpenVAS Compendium \compendiumversion\ \compendiumdate}
-\T\fancyhead[RO,LE]{\thepage}
-\T\fancyfoot[C]{\includegraphics[width=1cm]{images/openvas-logo}}
-
-
-% Title stuff
-\htmltitle{OpenVAS Compendium}
-\title{
-\IncludeImage[width=10cm]{images/openvas-logo}
-\ \\
-OpenVAS Compendium}
-
-\author{\htmlonly{\xml{p}\small
-\xlink{List of PDF Download Versions}{http://wald.intevation.org/frs/?group_id=29}\xml{br}
-%To \xlink{OpenVAS online Compendium}{openvas-compendium.html}\xml{br}
-To \xlink{OpenVAS Homepage}{http://www.openvas.org/}\xml{p}
-}%
-A Publication of the OpenVAS Project\\
-  \small Jan-Oliver Wagner, Michael Wiegand, Tim Brown, Carsten Koch Mauthe}
-\date{Version \compendiumversion\ as of \compendiumdate\ }
-
-
-\begin{document}
-\thispagestyle{empty}
-\pagestyle{fancy}
-\T\parindent0cm
-\T\parskip\medskipamount
-
-
-\maketitle
-
-
-\chapter*{Imprint}
-
-\noindent
-Copyright \copyright{} 2008 Intevation GmbH\\
-
-\IncludeImage[width=5cm]{images/cc-by-sa-logo}
-
-This work is licensed under the
-
-Creative Commons License Attribution-ShareAlike 3.0 Unported
-
-\hyperurl{http://creativecommons.org/licenses/by-sa/3.0/deed.en}
-
-%Special Thanks to:\\
-%XXX YYY for ZZZ (2008).\\
-
-\clearpage
-\tableofcontents
-\clearpage
-
-\chapter{Introduction}
-\section{About this Compendium}
-
-\compendiumauthor{Jan-Oliver Wagner}
-
-This compendium was compiled by people involved in the
-OpenVAS project. The intention is to provide a comprehensive documentation
-for all aspects of network vulnerability scanning with OpenVAS.
-
-This ranges from instructions on how to use the OpenVAS-Client graphical user
-interface, run specific test methods and write NASL vulnerability tests to
-details on the internal architecture of the actual scan server software.
-
-The present version of the compendium is far from complete. However, the section
-about OpenVAS-Client is already complete.
-
-\section{About the OpenVAS Project}
-
-\compendiumauthor{Michael Wiegand}
-
-OpenVAS stands for Open Vulnerability Assessment System and is a network
-security scanner with associated tools like a graphical user front-end. The core
-is a server component with a set of network vulnerability tests (NVTs) to detect
-security problems in remote systems and applications.
-
-OpenVAS products are Free Software under GNU GPL and a fork of the Nessus
-security scanner.
-
-\section{About the OpenVAS Software}
-
-\compendiumauthor{Michael Wiegand}
-
-\IncludeImage[width=10cm]{images/OpenVAS-Structure}
-
-The OpenVAS software consists of five distinct parts which are provided and
-maintained by the OpenVAS projects. The individual parts are:
-\begin{description}
- \item[OpenVAS-Server:] This is the core component of OpenVAS. It contains the
-functionality used for scanning a large number of target servers at a high
-speed. Scans will always originate from the host where OpenVAS-Server is
-running; therefore, this machine has to be able reach the intended targets.
- \item[OpenVAS-Client:] OpenVAS-Client controls the OpenVAS server,
-processes the scan results and displays them to the user. OpenVAS-Client can run
-on any machine able to connect to the OpenVAS-Server and can control multiple
-servers.
- \item[OpenVAS-Libraries:] This module contains functionality used by
-OpenVAS-Server.
- \item[OpenVAS-LibNASL:] The NVTs are written in the Nessus Attack Scripting
-Language'' (NASL). This module contains the functionality needed by
-OpenVAS-Server to interface with NASL.
- \item[OpenVAS-Plugins:] This module contains a base set of NVTs. Please be
-aware that the update cycle of this module is not intended to ensure the
-availability of the most recent NVTs. If you need up-to-date NVTs you should
-consider subscribing to a NVT feed as described in section \ref{sec:NVT feed}.
-\end{description}
-
-\clearpage
-
-\chapter{Planning OpenVAS-based Network Auditing}
-\compendiumauthor{Jan-Oliver Wagner}
-
-Note: This section is not complete yet.
-
-\section{Consider Coverage of Available Vulnerability Tests}
-\label{sec:NVT feed}
-
-As one of the first tasks of planning security audits based
-on OpenVAS, you should compare your targets with the coverage
-of the currently available OpenVAS vulnerability tests.
-
-Please be aware that the OpenVAS server (actually its module
-openvas-plugins'') delivers only a base set of tests.
-The update cycle of this base set is quite long compared to
-the occurrence of new vulnerabilities and respective tests.
-New or changed tests are delivered via so-called feed services''.
-
-If you want to test your network against the latest threats, a successful
-outcome will depend on the quality of the feed service(s) you subscribed to.
-Although the set of
-tests provided by openvas-plugins'' will detect a large range of older,
-well-known vulnerabilities, it will most probably be outdated by the time you
-use it and will not be able to detect the most recent vulnerabilities. In order
-to stay up-to-date with the latest security threats, you will need a feed
-service that provides you with the most recent tests for these threats.
-
-The OpenVAS project maintains a feed of its own:
-
-  http://www.openvas.org/openvas-nvt-feed.html
-
-To evaluate your need for an up-to-date feed service, you should think about
-the following questions:
-
-\begin{itemize}
-\item To what extent do the available feeds and their maintained
-      families cover my audit target?
-\item In case you are planning a permanent auditing solution and not just a
-      single shot: How sustainable is the feed service organized?
-\end{itemize}
-
-\section{Choose Location of Scan-Server}
-
-If you are planning to use the OpenVAS security scanner in your network, the
-best location for the machine running the server module depends on the targets
-you want to evaluate:
-
-\begin{itemize}
-\item Target is a public server:
-
-      Several tests do follow the very same path
-      as various attacks do: from a remote network.
-      If you are only interested in these tests,
-      you may use a arbitrary location of your OpenVAS
-      server outside of the targeted network.
-
-      However, you are advised to contact the
-      administration of the target systems beforehand and inform them that you
-      are planning on running OpenVAS against their machines.
-      Because OpenVAS will actively look for vulnerabilities on the target
-      system, a scan will under certain circumstances look like a real attack on
-      the target system and might be acted upon legally and/or technically by
-      the administration of the system in question.
-
-\item Targets are intranet desktops:
-
-\item Targets are intranet servers:
-
-\item Targets are intranet active network components:
-
-\end{itemize}
-
-\section{Choose Type of Scan-Server}
-
-
-\clearpage
-
-\chapter{Installing and Configuring OpenVAS-Server}
-\label{chap:Install-And-Configure-Server}
-
-\compendiumauthor{Tim Brown, Jan-Oliver Wagner and Michael Wiegand}
-\section{Installing Binary Packages}
-
-Easily installable binary packages for OpenVAS-Client are available for
-download on the OpenVAS website. The availability of these packages may change
-over time and thus the following descriptions might be slightly outdated;
-please refer to the OpenVAS website for up-to-date information.
-
-\subsection{Debian "Sid" (unstable) and "Lenny" (testing)}
-
-OpenVAS server is currently being integrated into Debian. The following modules
-are already available for Sid'' and Lenny'':
-\begin{itemize}
- \item libopenvas1
- \item libopenvas1-dev
-\end{itemize}
-
- You can install these modules with the following commands:
-
-\begin{verbatim}
- # apt-get install libopenvas1
- # apt-get install libopenvas1-dev
-\end{verbatim}
-
-ATTENTION: For the remaining modules you need to get the latest
-source tar-balls and compile them on your own.
-
-\subsection{Debian 4.0 Etch''(stable)}
-
-The OpenVAS-Server modules are not official packages for the Debian 4.0 release
-("Etch"). To help you to run OpenVAS-Server on Debian Etch, the OpenVAS project
-provides backports for some modules for Etch. You can install these modules on
-Debian Etch by following these steps:
-
-Select the following resource and add the line to the file
-\verb!/etc/apt/sources.list! on your system:
-
-\begin{verbatim}
-deb http://apt.intevation.de/ etch openvas
-\end{verbatim}
-
-Then, update your package list and install the available modules: (Please note
-that some modules are not yet available as backports. You have to compile the
-remaining modules on your own.)
-\begin{verbatim}
-# apt-get update
-# apt-get install libopenvas1
-# apt-get install libopenvas1-dev
-\end{verbatim}
-
-Note: If you know of further sources of backports, let the
-OpenVAS team know and they will be added to this list.
-
-\subsection{Gentoo}
-\label{sec:gentoo-server}
-
-The ebuilds are in the Gentoo portage. To get the most recent packages simply
-run:
-
-\begin{verbatim}
- #emerge --sync
-\end{verbatim}
-
-Because all OpenVAS packages are masked, you need to unmask the packages by
-keyword using one of the following ways:
-\begin{enumerate}
- \item  Edit \verb!/etc/portage/package.keywords! and add the packages:
-\begin{verbatim}
- net-analyzer/openvas ~x86
- net-analyzer/openvas-client ~x86
- net-analyzer/openvas-libnasl ~x86
- net-analyzer/openvas-libraries ~x86
- net-analyzer/openvas-plugins ~x86
- net-analyzer/openvas-server ~x86
-\end{verbatim}
- After that you can run:
-\begin{verbatim}
- #emerge net-analyzer/openvas
- #emerge net-analyzer/openvas-server
- #emerge net-analyzer/openvas-client
-\end{verbatim}
-\item To emerge all masked OpenVAS packages together you can use
-the following command:
-\begin{verbatim}
- # ACCEPT_KEYWORDS="~x86" emerge openvas
-\end{verbatim}
-\end{enumerate}
-
- For the server package there are the following "USE-Flags": gtk tcpd debug
-prelude
-
- Set them in the \verb!/etc/make.conf! to enable the support e.g. for prelude:
-\begin{verbatim}
- USE="prelude"
-\end{verbatim}
-
-or run it via the command line:
-
-\begin{verbatim}
- # ACCEPT_KEYWORDS="~x86" USE="prelude -debug" emerge openvas
-\end{verbatim}
-
-\subsection{OpenSUSE 10.2}
-
-In the download area you will find the files
-
-\begin{itemize}
-\item openvas-libraries-N.N.N-M.suse102.openvas.i586.rpm
-\item openvas-libnasl-N.N.N-M.suse102.openvas.i586.rpm
-\item openvas-server-N.N.N-M.suse102.openvas.i586.rpm
-\item openvas-plugins-N.N.N-M.suse102.openvas.i586.rpm
-\end{itemize}
-
-where N.N.N stands for the version of OpenVAS-Client and M for the package
-release number.
-
-For installation follow these steps as user "root" (insert the most
-current version numbers):
-\begin{verbatim}
-# rpm -i openvas-libraries-N.N.N-M.suse102.openvas.i586.rpm
-# rpm -i openvas-libnasl-N.N.N-M.suse102.openvas.i586.rpm
-# rpm -i openvas-server-N.N.N-M.suse102.openvas.i586.rpm
-# rpm -i openvas-plugins-N.N.N-M.suse102.openvas.i586.rpm
-# openvas-mkcert
-# openvas-adduser
-# openvas-nvt-sync
-# openvasd -D
-\end{verbatim}
-
-Note that you need to restart openvasd after each reboot and
-after each NVT synchronization.
-
-The corresponding source RPM files are
-named openvas-MODULE-N.N.N-M.suse102.openvas.src.rpm (where MODULE is
-"libraries", "libnasl", "server" and "plugins"). You will need these files only
-if you plan to rebuild the actual installation package.
-
-Finally, you will find the
-files openvas-MODULE-devel-N.N.N-M.suse102.openvas.i586.rpm (except for module
-"plugins"). These packages will install some files that are needed to compile
-some of the packages or rebuild packages from the source RPM packages. For
-simply running the OpenVAS server, it is not necessary to install the -devel-
-packages.
-
-\subsection{Fedora 8}
-
-In the download area you will find the files
-\begin{itemize}
-\item openvas-libraries-N.N.N-M.fc8.openvas.i586.rpm
-\item openvas-libnasl-N.N.N-M.fc8.openvas.i586.rpm
-\item openvas-server-N.N.N-M.fc8.openvas.i586.rpm
-\item openvas-plugins-N.N.N-M.fc8.openvas.i586.rpm
-\end{itemize}
-
- where N.N.N stands for the version of OpenVAS-Client and M for the package
-release number.
-
- For installation follow these steps as user "root" (insert the most current
-version numbers):
-\begin{verbatim}
-# rpm -i openvas-libraries-N.N.N-M.fc8.openvas.i586.rpm
-# rpm -i openvas-libnasl-N.N.N-M.fc8.openvas.i586.rpm
-# rpm -i openvas-server-N.N.N-M.fc8.openvas.i586.rpm
-# rpm -i openvas-plugins-N.N.N-M.fc8.openvas.i586.rpm
-# openvas-mkcert
-# openvas-adduser
-# openvas-nvt-sync
-# openvasd -D
-\end{verbatim}
-
-Note that you need to restart openvasd after each reboot and
-after each NVT synchronization.
-
-Also note that you may need to open the OpenVAS port to allow OpenVAS-Client to
-connect from other machines. This could be done by switching off the firewall
-(not recommended) or by adding a line like this to the file
-\verb|/etc/sysconfig/iptables| at the appropriate position:
-
-\begin{verbatim}
- -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 1241 -j
-ACCEPT
-\end{verbatim}
-
-You need to run the following command after this change:
-\begin{verbatim}
-/etc/init.d/iptables restart
-\end{verbatim}
-
-The corresponding source RPM files are named
-openvas-MODULE-N.N.N-M.fc8.openvas.src.rpm (where MODULE is "libraries",
-"libnasl", "server" and "plugins"). You will need these files only if you plan
-to rebuild the actual installation package.
-
-Finally, you will find the
-files openvas-MODULE-devel-N.N.N-M.fc8.openvas.i586.rpm (except for module
-"plugins"). These packages will install some files that are needed to compile
-some of the packages or rebuild packages from the source RPM packages. For
-simply running the OpenVAS server, it is not necessary to install the -devel-
-packages.
-
-\section{Compiling OpenVAS-Server from Source Packages}
-
-\subsection{Latest source code release}
-
-The download link for the latest source code release can be found in the
-"Download" section on the OpenVAS website.
-
-Download the four ".tar.gz" source code archives and unpack with "tar -xzf
-openvas-MODULE-N.N.N.tar.gz". Compiling from source is currently geared towards
-GNU/Linux systems, but may work as well in other environments.
-
-You have to compile and install the packages in the the following sequence:
-\begin{enumerate}
-\item openvas-libraries
-\item openvas-libnasl
-\item openvas-server
-\item openvas-plugins
-\end{enumerate}
-
-Now read the file \verb|INSTALL_README| inside the directory "openvas-libraries"
-for the next steps.
-
-Repeat for each module and read the corresponding INSTALL or README files.
-
-\subsection{Most current state of development (directly from the source code
-management
-system)}
-
-You need subversion to retrieve the code:
-\begin{verbatim}
-$svn checkout -https://svn.wald.intevation.org/svn/openvas/trunk/openvas-libraries -$ svn checkout
-https://svn.wald.intevation.org/svn/openvas/trunk/openvas-libnasl
-$svn checkout https://svn.wald.intevation.org/svn/openvas/trunk/openvas-server -$ svn checkout
-https://svn.wald.intevation.org/svn/openvas/trunk/openvas-plugins
-\end{verbatim}
-
-Now read the file \verb|INSTALL_README| inside the directory "openvas-libraries"
-for the next steps.
-
-Repeat for each module and read the corresponding INSTALL or README files.
-
-Although the OpenVAS team is committed to maintaining a high code quality,
-please be aware that you are using a development state that may be incomplete
-and unstable and should not be used in production environments.
-
-\section{Configuring OpenVAS-Server}
-\label{sec:Configuring OpenVAS-Server}
-\compendiumauthor{Michael Wiegand}
-
-\subsection{Generating a Server Certificate}
-
-For security reasons, communication between server and client is only possible
-through SSL encrypted connections. In order to establish an SSL encrypted
-connection, the server needs to have an SSL certificate. If the machine
-OpenVAS-Server is running on does not have a certificate, you will to generate
-one yourself. The easiest way to do this is through the \verb|openvas-mkcert|
-script provided by the OpenVAS-Server package. This will generate two
-certificates: one certificate for a local certificate authority (CA) and a
-second certificate for the OpenVAS server which is signed by the CA and is
-presented to connecting clients.
-
-\subsection{Adding New Users}
-
-In order to use an OpenVAS server, a client needs to have a user account on the
-server. The OpenVAS-Server package provides the \verb|openvas-adduser| script
-to simplify creating user account. Using \verb|openvas-adduser|, you can specify
-whether the user should use a password or a certificate to authenticate himself
-and optionally restrict the access rights of the user.
-
-Restricted access rights can be useful to prevent users from scanning arbitrary
-hosts or networks. You can specify rules that restrict an user to certain hosts
-or subnets or even prevent him from scanning any host but his own.
-
-The correct syntax for user rules is:
-
-\verb#accept|deny ip/mask#
-
-and
-
-\verb#default accept|deny#
-
-Where \verb#mask# is the CIDR netmask of the rule.
-
-The \verb#default# statement must be the last rule and defines the policy for
-the user.
-
-The following rule set will allow the user to test 192.168.1.0/24,
-192.168.3.0/24 and 172.22.0.0/16, but nothing else:
-
-\begin{verbatim}
-accept 192.168.1.0/24
-accept 192.168.3.0/24
-accept 172.22.0.0/16
-default deny
-\end{verbatim}
-
-The following rule set will allow the user to test whatever he wants,
-except the network 192.168.1.0/24:
-
-\begin{verbatim}
-deny 192.168.1.0/24
-default accept
-\end{verbatim}
-
-The keyword \verb#client_ip# is replaced at runtime by the IP address
-of the user. If you want to restrict the user to be able to scan only the system
-he is connecting from, you can use the following ruleset:
-
-\begin{verbatim}
-accept client_ip
-default deny
-\end{verbatim}
-
-\subsection{Advanced Configuration}
-
-If you need to make changes to the default OpenVAS-Server configuration, you can
-do so in the configuration file located at \verb#/etc/openvas/openvasd.conf#.
-
-The following settings can be configured through the openvasd.conf configuration
-file (note: the default values for your distribution may differ from the default
-values described here):
-
-\begin{description}
- \item[plugins\_folder] This setting configures the path where the NVT scripts
-can be found. \textit{(default value: /lib/openvas/plugins)}
- \item[max\_hosts] The maximum number of hosts that will be tested
-simultaneously. \textit{(default value: 30)}
- \item[max\_checks] The maximum number of checks that will run simultaneously
-against a given host. \textit{(default value: 10)}
- \item[be\_nice] Niceness. If set to 'yes', openvasd will renice itself to 10.
-\textit{(default value: no)}
- \item[logfile] The file used to log activity. If this value is set to 'syslog',
-OpenVAS-Server will use syslogd for logging.
-\textit{(default value: /var/log/openvas/openvasd.messages)}
- \item[log\_whole\_attack] This setting controls how detailed should be logged. If
-this option is set to 'no', only the start and end time of the scan is logged.
-If set to 'yes', OpenVAS-Server will log more information, including the time
-each plugin took to execute. Be aware that this may cause OpenVAS-Server to use
-more hard disk space and to access the hard disk more often during the scan.
-\textit{(default value: no)}
- \item[log\_plugins\_name\_at\_load] This setting controls whether the names of the
-plugins that are loaded by the server should be logged.
-\textit{(default value: no)}
-
- \item[dumpfile] This option configures the name of the file that should be used
-for debugging output. If this option is set to '-', debugging output will be
-written to stdout. \textit{(default value: /var/log/openvas/openvasd.dump)}
-
- \item[rules] The filename for the server rules file.
-\textit{(default value: /etc/openvas/openvasd.rules)}
-
- \item[users] The filename for the user database.
-\textit{(default value: /etc/openvas/openvasd.users)}
-
- \item[cgi\_path] The default CGI paths to check, separated by colons(':').
-\textit{(default value: /cgi-bin:/scripts)}
-
- \item[port\_range] The range of ports that will be scanned by the port scanners.
-If this setting is set to 'default', OpenVAS-Server will scan the ports
-specified in the file found at \verb#/var/lib/openvas/openvas-services#.
-\textit{(default value: default)}
-
- \item[optimize\_test] Security tests may request to be launched if and only if
-certain information gathered by other tests exists in the knowledge base, or if
-and only if a given port is open. If this option is set to 'yes', it will speed
-up the test, but may cause the OpenVAS server to miss some vulnerabilities.
-\textit{(default value: yes)}
-
- \item[language] The language to use in plugin description. Currently the values
-'english' and 'french' are supported. \textit{(default value: english)}
-
- \item[checks\_read\_timeout] The read timeout (in seconds) for the sockets used
-while scanning. \textit{(default value: 5)}
-
- \item[non\_simult\_ports] This option can be used to specify a list of ports or
-services against which plugins should not be run simultaneously.
-\textit{(default value: 139, 445)}
-
- \item[plugins\_timeout] The maximum lifetime of a plugin (in seconds).
-\textit{(default value: 320)}
-
- \item[safe\_checks] Some security checks may harm the target server, by
-disabling the remote service temporarily or until a reboot. If this option, is
-set to 'yes', the OpenVAS server will rely on banners instead of actually
-performing a security check. This will result in a less reliable report, but you
-is less likely to disrupt functionality on the target system during a test.
-\textit{(default value: yes)}
-
- \item[auto\_enable\_dependencies] If this option is set to 'yes', OpenVAS-Server
-will automatically enable plugins which are need by the plugins selected by the
-user. \textit{(default value: yes)}
-
- \item[silent\_dependencies] If this option is set to 'yes', output from plugins
-which were enabled automatically will not be send to the client.
-\textit{(default value: yes)}
-
- \item[use\_mac\_addr] Designate hosts by MAC address, not IP address; this can
-be useful in DHCP networks. \textit{(default value: no)}
-
- \item[save\_knowledge\_base] This option controls whether the knowledge base
-created during the scan should be saved to disk. \textit{(default value: no)}
-
- \item[kb\_restore] This setting controls whether the knowledge base should be
-restored for each test. \textit{(default value: no)}
-
- \item[only\_test\_hosts\_whose\_kb\_we\_dont\_have] If this option is set to
-'yes', OpenVAS-Server will only test the hosts that are not yet in the knowledge
-base. This can be used to scan new hosts once if they appear in a subnet for the
-first time, for example. \textit{(default value: no)}
-
- \item[only\_test\_hosts\_whose\_kb\_we\_have] If this option is set to 'yes',
-OpenVAS-Server will only test the hosts that are already in the knowledge
-base. This is useful for scanning only a set of host that are already known to
-the server. \textit{(default value: no)}
-
- \item[kb\_dont\_replay\_scanners] If this option is set to 'yes' and the option
-kb\_restore has been enabled, scanner plugins will not be launched if they have
-already been launched in the past. \textit{(default value: no)}
-
- \item[kb\_dont\_replay\_info\_gathering] If this option is set to 'yes' and the
-option kb\_restore has been enabled, information gathering plugins will not be
-launched if they have already been launched in the past.
-\textit{(default value: no)}
-
- \item[kb\_dont\_replay\_attacks] If this option is set to 'yes' and the option
-kb\_restore has been enabled, attack plugins will not be launched if they have
-already been launched in the past. \textit{(default value: no)}
-
- \item[kb\_dont\_replay\_denials] If this option is set to 'yes' and the option
-kb\_restore has been enable, denial of service plugins will not be launched if
-they have already been launched in the past. \textit{(default value: no)}
-
- \item[kb\_max\_age] This option sets the maximum age of the knowledge base (in
-seconds). \textit{(default value: 864000)}
-
- \item[slice\_network\_addresses] If this option is set to 'yes', OpenVAS will
-not scan a network sequentially, (10.0.0.1, 10.0.0.2, 10.0.0.3) but will attempt
-to slice the workload throughout the whole network (i.e.: 10.0.0.1, 10.0.0.127,
-10.0.0.2, 10.0.0.128). \textit{(default value: no)}
-
- \item[nasl\_no\_signature\_check] If this option is set to 'yes',
-OpenVAS-Server will not check the signatures of the NASL scripts and will run
-scripts even if they have no or no valid signature. Be aware that setting this
-option to 'yes' does pose a security risk. However, at the current stage of
-OpenVAS development, signatures are only available for a limited subset of
-tests. If this option is set to 'no', you will only be able to use a very
-limited number of plugins. For this reason, this option will default to 'yes'
-until an infrastructure for signature checking has been established.
-\textit{(default value: yes)}
-\end{description}
-
-\section{Managing NVT signatures}
-\compendiumauthor{Jan-Oliver Wagner}
-
-This section explains what you need to do to allow your OpenVAS-Server to
-execute only signed NVTs with a trust level you decide.
-
-Currently, some signed NVTs are available by using the command
-\verb#openvas-nvt-sync# which is included in openvas-plugins since release
-0.9.1. The signatures correspond to the certificate "OpenVAS Transfer Integrity"
-available on the OpenVAS website.
-
-\subsection{What is a Signature?}
-
-A clever method is applied to compute a unique checksum for a file. If only a
-single character in the file changes, the checksum will change as well. This
-checksum is digitally signed in a way that you can test with a public
-certificate whether a certain key was used to create the signature. Such a key
-and certificate do always form a pair that is related to each other. If the
-signed file has been modified by a third party, the signature will be broken. In
-this case you should not trust the file.
-
-If the signature is not broken, the question remains if you trust the owner of
-the key. If you decided to do so (and there any many ways and supporting
-technologies to manage this), you can accept the file as trustworthy.
-
-\subsection{The Signature Format}
-
-The signatures for OpenVAS NVTs and associated files (.nasl, .inc and .nes) are
-standard so-called "ASCII-armored detached OpenPGP signatures" created with
-GnuPG. This format features:
-
-\begin{itemize}
- \item Multiple signer keys possible
- \item Site administrators can decide which keys to trust
- \item Signatures can be created and verified with widely available tools like
-GnuPG
- \item detached signatures do not require changes to the signed file (like
-inline signatures would)
-\end{itemize}
-
-The name of the signature file is the name of the signed file with the added
-extension ".asc". That is, the name of the signature file for a file
-"myscript.nasl" is "myscript.nasl.asc".
-
-Please note the difference to Nessus: Nessus signatures were inline x509-based
-signatures. This concept does not consider multiple signatures. Please be aware
-that OpenVAS no longer supports Nessus signatures and will consider plugins
-unsigned even if the have a valid Nessus signature.
-
-\subsection{The Signature Verification Process}
-
-The signature verification of the OpenVAS server is activated by setting
-"nasl\_no\_signature\_check = no" in /etc/openvas/openvasd.conf.
-
-At start-up the openvas daemon (openvasd) checks all signatures for validity.
-Only fully trusted files are considered by the server and thus loaded and made
-available to OpenVAS client.
-
-The trust check uses a special list of certificates managed for the
-OpenVAS server. It is a standard GnuPG keyring located by default in
-/etc/openvas/gnupg.
-
-When OpenVAS verifies a signature it checks all signatures contained in the
-signature file and all signatures must be fully valid. This means that all of
-the following criteria must be fulfilled for all signatures:
-
-\begin{itemize}
- \item The certificate must be present in the keyring.
- \item The key must be fully valid.
- \item The signature must be valid.
-\end{itemize}
-
-If any of the signatures does not meet all of these criteria, that file is
-considered untrustworthy and will not be executed at all. If all signatures meet
-the criteria, the script is trusted fully and may execute all functions. If no
-signature file exists, the script is not executed at all.
-
-Again, pleas note the difference to Nessus: For Nessus signatures, three levels
-were distinguished: no signature, a bad signature and a good signature. Plugins
-with no signature were still executed, but in a "restricted" mode where no
-functions that were regarded critical could be executed. OpenVAS explicitly only
-distinguishes between fully trusted and untrusted files.
-
-\subsection{How to Add a Certificate}
-
-To add a certificate to the OpenVAS Server keyring, use this command:
-
-\begin{verbatim}
-# gpg --homedir=/etc/openvas/gnupg --import certificate-file.asc
-\end{verbatim}
-
-See the OpenVAS website for available certificate files.
-
-\subsection{How to Set Trust}
-
-To express trust into keys that signed NVTs (see "How to set trust" below) you
-need a signing key for your OpenVAS installation. You can use an existing key,
-or you can generate a new one:
-
-\begin{verbatim}
-# gpg --homedir=/etc/openvas/gnupg --gen-key
-\end{verbatim}
-
-This needs to be done only once for an OpenVAS-Server installation.
-
-For OpenVAS to trust a signature, the key used to create the signature has to be
-valid. A certificate corresponding to this key that was just imported has an
-unknown validity and thus is considered not valid.
-
-In order to trust a certificate for your purpose, you have to sign it. The
-recommended way is to use local signatures that remain only in the keyring of
-your OpenVAS Server installation.
-
-To sign a certificate you need to know its KEY\_ID. You can get it either
-from the OpenVAS website or via a "list-keys" command. Then you can locally
-sign:
-
-\begin{verbatim}
-# gpg --homedir=/etc/openvas/gnupg --list-keys
-
-# gpg --homedir=/etc/openvas/gnupg --lsign-key KEY_ID
-\end{verbatim}
-
-Before signing you should be absolutely sure that you are signing correct
-certificate. You may use its fingerprint and other methods to convince yourself.
-
-\subsection{How to Remove a Certificate}
-
-\begin{verbatim}
-# gpg --homedir=/etc/openvas/gnupg --delete-keys KEY_ID
-\end{verbatim}
-
-\subsection{Manual Signature Verification}
-
-In case you want to manually verify the validity of a .nasl file, you  can
-either run GnuPG:
-
-\begin{verbatim}
-$gpg --homedir=/etc/openvas/gnupg gpg --verify script.nasl.asc script.nasl -\end{verbatim} - -Or you can use the standalone nasl interpreter: -\begin{verbatim} -$ openvas-nasl -p script.nasl
-\end{verbatim}
-
-The -p Option means that the script is only parsed and not executed.
-
-To debug the signature verification done by the nasl interpreter, use the -T
-option to enable the trace mode. The signature verification will leave more
-detailed information about the verification and the signatures found in the
-trace file.
-\clearpage
-
-\chapter{Installing and Configuring OpenVAS-Client}
-\compendiumauthor{Tim Brown, Jan-Oliver Wagner and Michael Wiegand}
-
-\section{Installing Binary Packages}
-
-Easily installable binary packages for OpenVAS-Client are available for
-download on the OpenVAS website. The availability of these packages may change
-over time; please refer to the OpenVAS website for up-to-date information.
-
-\subsection{Debian "Sid" (unstable) and "Lenny" (testing)}
-
-OpenVAS-Client is an official Debian package for the distribution "unstable"
-("Sid) and "testing" ("Lenny"). You can find more information about the Debian
-packages on the OpenVAS-Client package pages
-for Sid\footnote{http://packages.debian.org/sid/openvas-client} and
-Lenny\footnote{http://packages.debian.org/lenny/openvas-client}.
-
-This means you can simply install OpenVAS-Client on Debian Sid or Debian
-Lenny with the following command:
-\begin{verbatim}
-# apt-get install openvas-client
-\end{verbatim}
-
-\subsection{Debian "Etch" 4.0 (stable)}
-
-OpenVAS-Client is not an official package for the Debian 4.0 release ("Etch").
-To enable you to easily run OpenVAS-Client on Debian Etch, the OpenVAS
-project provides backports for Etch. You can install OpenVAS-Client on
-Debian Etch by following these steps:
-
-Select the following resource and add the line
-to the file /etc/apt/sources.list on your system:
-\begin{verbatim}
- deb http://apt.intevation.de/ etch openvas
-\end{verbatim}
-
-Then, update your package list and install OpenVAS-Client:
-
-\begin{verbatim}
- # apt-get update
- # apt-get install openvas-client
-\end{verbatim}
-
-\subsection{Ubuntu 8.10 "Intrepid Ibex"}
-
-OpenVAS-Client has been added to the upcoming Ubuntu 8.10 release
-("Intrepid Ibex") which is scheduled for release in October 2008. You can find
-more information about the Ubuntu
-package on the OpenVAS Client package page for Intrepid Ibex (at
-\hyperurl{http://packages.ubuntu.com/intrepid/openvas-client}).
-
-This means you can simply install OpenVAS-Client on Ubuntu 8.10 with the
-following command:
-
-\begin{verbatim}
-# apt-get install openvas-client
-\end{verbatim}
-
-Backported packages are also available for the Ubuntu 8.04 LTS release ("Hardy
-Heron"). To install OpenVAS-Client on Ubuntu 8.04 LTS, simply follow the
-instructions for Debian 4.0 "Etch" as described above.
-
-\subsection{Gentoo}
-
-Please see the installation description for OpenVAS-Server on Gentoo in
-section \ref{sec:gentoo-server}.
-
-\subsection{OpenSUSE 10.2}
-
-In the download area you will find the file
-openvas-client-N.N.N-M.suse102.openvas.i586.rpm where N.N.N stands for the
-version of OpenVAS-Client and M for the package release number.
-
-The corresponding source RPM files are named
-openvas-client-N.N.N-M.suse102.openvas.src.rpm.
-You will need these files only if you plan to rebuild the actual installation
-package.
-
-
-\subsection{Fedora 8}
-
-In the download area you will find the file
-openvas-client-N.N.N-M.fc8.openvas.i586.rpm
-where N.N.N stands for the version of OpenVAS-Client and
-M for the package release number.
-
-The corresponding source RPM files are named
-openvas-client-N.N.N-M.fc8.openvas.src.rpm.
-You will need these files only if you plan to rebuild
-the actual installation package.
-
-\subsection{Windows XP SP2}
-
-In the download area you will find the file OpenVAS-Client-N.N.N-M-LL-setup.exe
-where N.N.N stands for the version of OpenVAS-Client, M for the package release
-number and LL for the language (e.g. en=English, de=German, sv=Swedish).
-
-\section{Compiling OpenVAS-Client from Source Packages}
-
-\subsection{Latest source code release}
-
-Download the ".tar.gz" source code archive from the download section of the
-OpenVAS website and unpack with "tar -xzf openvas-client-N.N.N.tar.gz".
-Compiling from source is currently geared towards GNU/Linux systems, but may
-work as well in other environments.
-
-Now read the README file inside the new directory for further instructions.
-
-\subsection{Most current state of development (directly from the source code
-management system)}
-
-You need subversion to retrieve the code:
-
-\begin{verbatim}
- $svn checkout -https://svn.wald.intevation.org/svn/openvas/trunk/openvas-client -\end{verbatim} - -Change to the new directory and follow the instructions of the README file. - -Although the OpenVAS team is committed to maintaining a high code quality, -please -be aware that you are using a development state that may be incomplete and -unstable and should not be used in production environments. - -\clearpage - -\chapter{Using OpenVAS-Client} -\compendiumauthor{Jan-Oliver Wagner} - -This section describes the basic components of OpenVAS-Client -and how to use them for day-to-day use as well as more specific -features that might be of interest for advanced users. - -This documentation assumes OpenVAS-Client in version 1.0.4. Newer version -might offer additional or changed functionality. In case, please refer to the website -for information or support. - -\section{The Main Window} -\label{sec:MainWindow} - -The main window of OpenVAS-Client is split into two major sections: -On the left-hand side is the treelist with an overview of the locally -stored tasks, scopes and reports. On the right-hand side there is -a notebook with pages for comments, options and reports. This is the -place where a security scan can be configured, commented upon and -its result reviewed. - -\IncludeImage[width=10cm]{images/mainwindow-en} - -When you first start of OpenVAS-Client, you will see only one entry -in the list: Global Settings. These settings you see on the first start-up are -the default settings shipped with OpenVAS-Client. They do not cover a -specific selection of plugins since a connection to an OpenVAS server is -required to make a plugin selection. You can establish a connection with a -server and then specify a global default plugin selection for later use. - - -\subsection{Tasks} - -Tasks are intended to cover all activities of a major topic. A task could be - {}Test the machines of our headquarter'' or {}Customer -XYZ Inc.''. - -A task can contain a comment that explains the task in more detail. -Also any type of additional info or reminder can be entered in the -comment area, e.g. when to run the next series of scans or based on -which contract the scans are performed. - -A task has neither options nor a report. Apart from the comment, -it just contains a number of scopes. - -Possible operations for tasks are: - - -\paragraph{New} - -Adds a new task with the title {}unnamed''. - - -\paragraph{Rename} - -Allows to edit the title in the treelist either by clicking -on the title or by selecting the corresponding menu item. - - -\paragraph{Remove} - -This means the removal of all scopes associated with this task and thus the -removal action prompts for a confirmation. - - -\subsection{Scopes} - -A scope can be seen as a sub-task. It defines a certain security scan. -The title should indicate the scope of this scan, e.g. {}Careful -scan of web server production system'', {}Aggressive scan of web -server alpha test system'' or {}All Sun workstations''. - -Comments can also be specified for each scope and may explain the -scope in more detail as well as contain any other helpful hints regarding -the respective scope. - -The scope is associated with a full set of options for the security -scan. When creating a new scope, the general settings are copied. The -scan options are explained in detail in a later section. - -It should be noted that a connection to an OpenVAS server is established within -the context of a specific scope. If a scope is connected to the server, a scan -based on the settings for this scope can be executed. An icon to the right of -the scope title indicates the connection status of this scope. This means a task -can contain a selection of scopes that connect to different OpenVAS servers -with different plugins. - -Next, a scope may contain a number of reports. Whenever a scope is -successfully executed, the resulting report is added to its list of -reports. Also, importing a report from a file or from an OpenVAS server -will add the report to the currently selected scope. - -Please note that changes to a scope are always and only stored when -executing a scan. If you make changes to a scope like a new plugin -selection and leave OpenVAS-Client without running a scan, these changes -will be discarded. - -Possible operations for scopes are: - - -\paragraph{Execute} - -The scope configuration is stored to disk and a security scan is executed -with the currently specified options using the currently connected -OpenVAS server. - - -\paragraph{New} - -Adds a new scope entitled {}unnamed'' as part of the currently -selected task. As a default the global settings are copied. Note, -that only explicitly saved global settings are taken as defaults. -If you changed them inside OpenVAS-Client without saving them, they -will have no effect. - - -\paragraph{Rename} - -Allows to edit the title in the treelist either by clicking -on the title or by selecting the corresponding menu item. - - -\paragraph{Remove} - -This means the removal of all associated reports and thus the removal -action prompts for a confirmation. - - -\paragraph{Move to task} - -It is possible to move a scope with all of its reports from one task -to another. This menu item has subitems which represent the other -tasks. Select one of them and the scope will be moved. - - -\paragraph{Open} - -You can load a scope file and add it to the current task with this -menu command. Note that here only the parameter sets are covered but -not the reports which are represented by files of their own. So, opening -and saving (see below) scopes is a method to transfer you settings -to someone else or to create a copy of the current scope for yourself. - - -\paragraph{Save As} - -Saves the current scope to a file (which is of nessusrc type). Note -that only the parameter sets are stored but not the reports. See above -the description of {}Open'' for more hints. - - -\subsection{Reports} -\label{sec:Reports} - -A report is the result of a security scan. It contains the results -of the executed plugins associated with the corresponding subnet, -host, port and severity. - -Managed within OpenVAS-Client, additionally a comment and, if available, -the scan options leading to the report, can be stored. This additional -information is not contained in the plain OpenVAS report files and -thus gets lost when being exported. This also means that imported reports -have no comments or scan options associated. - -Possible operations for reports are: - - -\paragraph{Remove} - -Deletes the report and its comments and options. The -user is prompted to confirm the removal. - - -\paragraph{Import} - -Allows to import a report from a file. The standard exchange format -is NBE (files suffixed {}.nbe''). The file selection dialog allows -to select the desired report file. A error hint will be displayed -if the file format was not NBE. Else, the report is added to the currently -selected scope. Neither comments nor options will be there for a report -imported from a NBE file. - - -\paragraph{Export} - -Allows to export the currently selected report either in a re-importable -format (NBE) or in a format for further processing or presentation -(XML, HTML, HTML with Pies and Graphs, \LaTeX{}, ASCII Text and PDF). -It is recommended to use NBE if re-importing is planned and to use -PDF for creating simple report documents that need no further editing. -Use one of the other if you want to further process the report or -integrate it into your own document style. - - -\paragraph{Print} - -Selecting the Print command will create a PDF version of the current report -and tries to run a PDF viewer installed on your system. OpenVAS-Client will try -a number of well-known PDF viewers; if there is a PDF viewer installed on your -system and this menu item does not work, please check if the executable file for -your PDF viewer is available in your system path. - - -\section{Authentication} - -OpenVAS-Client needs to connect to an OpenVAS server in order to retrieve -the available plugins and to actually execute a security scan. - -OpenVAS-Client can handle multiple connections to different servers. -Each scope has a connection of its own. Additionally, the Global Settings -can be connected to an OpenVAS server to define default plugin selections -and plugin parameters. Note that only explicitly saved Global Settings -are used as defaults for new scopes. - -\IncludeImage[width=5cm]{images/authentication-dlg-en} - -The connection status is indicated with a icon in the tasks/scopes/reports -treelist next to the title of the global settings or a scope. Only -scopes are connected with the OpenVAS server. - -More information on the connection status is shown in the statusbar -at the bottom of the main window. There, the connection information -is displayed, i.e.. {}Connection: username at host.test.example''. -At bottom right there is an icon indicating the connection status. - -The connection dialog allows to specify the following settings for establishing -a connection to an OpenVAS server: - - -\paragraph{Host} - -The hostname or IP address of the server where an OpenVAS server is running. - - -\paragraph{Port} - -The port where the OpenVAS Server waits for connections. Older Nessus -Servers used 3001, but the official port now is 1241. With the default -button you can reset this option to the default port. - - -\paragraph{Login} - -Your username on the selected OpenVAS server. To use an OpenVAS server you have -to have an account on the OpenVAS server. Please contact the administrator of -the server if you need an account. - - -\paragraph{Password} - -The password for your account on the OpenVAS server. - - -\paragraph{Authentication by Certificate:} - -If you use this method you have to have a key/certificate pair created -for you. This is usually done by the administrator of OpenVAS server -using the available scripts. The administrator will give you the -two files you need to specify (User Certificate File and User Key -File). The administrator may create a key without a password or with -a password. If you have a password for the User Key File you must -enter the password in the corresponding text field. - - -\subparagraph{Trusted CA:} - -This certificate defines a certificate authority (CA) you trust. With -this certificate you will be able to check that you are connecting to a trusted -OpenVAS server. This is checked if you have the Paranoia Level'' set -to 2 or 3 and is is not checked with a Paranoia Level'' of 1. Note that -you can set the Paranoia Level by hand in the nessusrc files or when -first connecting to an OpenVAS server where you are asked explicitly. - -The default path for the Trusted CA is the filename used by the OpenVAS server -itself. Thus, if you are running OpenVAS-Client on the same -machine or have the same volume mounted, you can just use the default. - -If you are running OpenVAS-Client from a remote machine, you need to have a copy -of the CA certificate and set the location of the certificate file -manually. - - -\section{Scan Options} - -This section explains the most important configuration options for -a security scan. - -\subsection{General} - -This page covers all the general scan options. See the screenshot -for the main window in section \ref{sec:MainWindow}. - - -\paragraph{Port range} - -Ports that will be scanned by the OpenVAS server. You can enter single -ports, such as {}1-8000'' or more complex sets, such as -{}21,23,25,1024-2048,6000''. -Put {}-1'' for no portscan, or put {}default'' to scan the -default ports in the OpenVAS services file. - - -\paragraph{Consider unscanned ports as closed} - -To save scanning time, you may ask the OpenVAS server to declare TCP ports -it did not scan as closed. This will result in an incomplete audit -but it will reduce scanning time and prevent the OpenVAS server from sending -packets to ports you did not specify. If this option is disabled, -the OpenVAS server will consider ports whose state it does not know -as open. - - -\paragraph{Number of hosts to test at the same time} - -Maximal number of hosts that the OpenVAS server will test at the same -time. Be aware that the OpenVAS server will spawn max\_hosts max\_checks -processes! - - -\paragraph{Number of checks to perform at the same time} - -Maximal number of security checks that will be launched at the same -time against each host. Be aware that the OpenVAS server will spawn -max\_hosts x max\_checks processes! - - -\paragraph{Path to CGIs} - -It is possible to check for the presence of CGIs in multiple paths -like {}/cgi-bin'', {}/cgis'', {}/home-cgis'' and so on. -In that case, put all your paths here separated by colons. For instance: -{}/cgi-bin:/cgi-aws:/cgi''. - - -\paragraph{Do a reverse lookup of the IP before testing it} - -If this option is set, the OpenVAS server will do a reverse lookup on the -IP addresses before it tests them. This may slow down the whole test. - - -\paragraph{Optimize the test} - -Security tests may ask the OpenVAS server to be launched if and only -if some information gathered by other tests exists in the knowledge -base, or if and only if a given port is open. This option speeds up -the test, but may cause the OpenVAS server to miss some vulnerabilities. If you -are paranoid, disable this option. - - -\paragraph{Safe checks} - -Some security checks may harm the target server, by disabling the -remote service temporarily or until a reboot. If you enable this option, -the OpenVAS server will rely on banners instead of actually performing -a security check. You will obtain a less reliable report, but you -are less likely to disrupt functionality on the target system by doing a test. -From a security point of view, we recommend you disable this option; from -a system administrator point of view, we recommend you enable it. - - -\paragraph{Designate hosts by their MAC address} - -If you enable this option, the hosts on the local network will be -designated by their ethernet MAC address instead of their IP address. -This is especially useful if you are using the OpenVAS server in a DHCP network. -If unsure, disable this option. - - -\paragraph{Port Scanner} - -This is the list of available port scanners. Port scanners are a special -category of plugins and therefore presented separately from the other -plugins. The list is only available if a connection to an OpenVAS server -has been established. You can activate one or more of the scanners. -Clicking on an entry shows the details for the respective scanner -plugin. - - -\subsection{Plugins} - -The plugins are stored on the OpenVAS server. Thus, to make a selection -of the plugins to apply you need to connect to a server. Otherwise -this page will remain empty. - -\IncludeImage[width=12cm]{images/mainwindow-plugins-en} - -The Plugins are separated into a number of families which can be activated or -deactivated as a whole by checking the box to the right of family -name. Also, a family can be expanded to show all of its member plugins -where you can refine the selection by activating or deactivating single -plugins using the checkbox to the right of the plugin name. - -The column {}Warning'' contains a warning sign for some plugins. -The warning sign means that this plugin may harm the target host by -disabling the attacked service or by crashing the host. You should -be careful when you enable it since it may disrupt functionality on the -target server. - -Below the plugin list the total number of plugins loaded from the -server is shown, together with the total number of currently selected -plugin as well as the number of plugins shown due to an applied filter. - -The following actions are possible: - - -\subparagraph{Enable all} - -Enables all plugins. - - -\subparagraph{Disable all} - -Disables all plugins. - - -\subparagraph{Expand all} - -Expands the plugin tree-list to maximum so that the list contains -all plugins. - - -\subparagraph{Collapse all} - -Only show the plugin families. - - -\subparagraph{Enable dependencies at runtime} - -If you enable this option, the OpenVAS server will automatically enable the -plugins needed by the set of plugins you selected. - - -\subparagraph{Silent dependencies} - -If you enable this option, the OpenVAS server will not report data -coming from the plugins that you did not specifically enable. - - -\subparagraph{Filter} - -The filter dialog lets you select plugins with the characteristics -you want. \textbf{Note} that you will erase your previous selection -by applying a filter. - - -\paragraph{Plugin information dialog} - -Double-clicking on a specific plugin title will raise a information -dialog for the respective plugin. - -The information shown are the ones specified within the corresponding -plugin. - -The following actions are possible in this dialog: - - -\subparagraph{Set plugin timeout} - -Allows you to specify a timeout for the plugin. - - -\subparagraph{Show dependencies} - -This lists the dependencies for the selected plugin. It also provides -information on whether the dependencies are currently -enabled or disabled. - - -\subsection{Credentials} - -Some of the plugins allow to enter credentials to test certain applications, -for example Samba or websites (HTTP). These plugins work the same way as the -plugins listed in the {}Plugin Preferences'' list. -For better handling they are collected under {}Credentials''. - -\IncludeImage[width=10cm]{images/mainwindow-credentials-en} - - -\subsection{Plugin Preferences} - -Some of the plugins allow to refine with specific parameters. All -of the configurable plugins' parameters are collected on this page -where the user may modify the default values. - -\IncludeImage[width=10cm]{images/mainwindow-pluginprefs-en} - -Only a comparably small number of plugins offer a configuration. - - -\subsection{Target Selection} - -\IncludeImage[width=12cm]{images/mainwindow-targetselection-en} - - - -\paragraph{Target(s)} - -The first host(s) that will be attacked by the OpenVAS server. The options -below allow you to extend the test to a larger set of targets. You -may define several targets by separating them with a comma -(,). i.e. : {}host1,host2''. - -A special syntax is {}file:/some/where/targetlist.txt'' which -means that the actual target names are loaded from that list. - - -\paragraph{Read from file} - -A textfile can be specified that contains the list of targets. This -textfile may contain comma-separated lists of host and also may contain -many of such lines. - - -\paragraph{Perform a DNS Zone transfer} - -The OpenVAS server will perform an AXFR request (that is, a zone transfer) -to the target name server and will attempt to obtain the list of the -hosts in the target domain. Then, it will test each host. - - -\section{Reports} - - -\subsection{Report Page of OpenVAS-Client} - -The report page consists of three elements. On the left hand a tree list -allows you to browser via hosts, ports and severity to single reports. -On top of this treelist is a selection for re-ordering the tree structure. -On the right hand the text area contains the actual report text. The -whole design is focused on supporting an explorative understanding -of the scan results. - -\IncludeImage[width=13cm]{images/mainwindow-report-en} - -\subsection{Report Formats} - -The scan results can be exported into a number of formats. Basically -it can be distinguished between three types of formats: interchange formats, -editable documents and read-only documents. The last type is currently -represented by the PDF Report file. With a capable viewer it allows you to -browse back and forth through the document using the various inserted -hyperlinks. - -For further information see the section \ref{sec:Reports} about the menu command -{}Report->Export''. - -\section{OpenVAS-Client Preferences} - -OpenVAS-Client allows you to specify some individual preferences that -determine some ways how the client GUI works. - -\IncludeImage[width=10cm]{images/preferences-dlg-en} - - -The following selection are available: - - -\subsection{User Interface} - - -\paragraph{Auto expand tree elements} - -In the left-hand treeview clicking on a task or a scope automatically -expands the corresponding tree if checked. - -If not checked, the user has to manually click on the expand icon -each time. - -\paragraph{Order by} - -This setting controls how the scan results are sorted in the report window. The -default is to sort the results by host first, then by port and severity. -Depending on your context, it might make more sense to choose the second option -and sort the results by port first; for example, you might be more interested in -a quick overview over which hosts are running a service on a certain port than -in which ports are open on a certain host. - -\subsection{Connection to the OpenVAS server} - - -\paragraph{Automatically connect} - -If this setting is enabled, OpenVAS-Client will try to connect to -the server when a scope is executed. For user certificates without -a password, this will work immediately. For password protected user -certificates or simple password based authentication, the password -will be stored in memory after a successful login until OpenVAS-Client -is closed. - -\paragraph{Protocol version} - -This setting controls which protocol the client will ask the server to use for -communication between client and server. Right now, it is possible to choose -between NTP 1.2 (the legacy protocol used by Nessus) and OTP 1.0 (the upcoming -OpenVAS Transport Protocol). Please be aware that the server will close the -connection if the client asks for an unsupported protocol. - -\subsection{Plugin Cache} - - -\paragraph{Cache plugin information when connecting} - -If this setting is enabled, OpenVAS-Client will create a cache for -the respective scope containing all plugin information. This has essentially -three effects: - -First, reconnecting the same scope might be much faster because MD5 -checksums are used to discover changed and new plugins. Only -the changes will be downloaded. Of course, connecting to a different -OpenVAS server will usually force a new download of all plugins. - -Second, all plugin information is available even when the client -has no connection to the server. Thus you can review which plugins are selected -and what the current plugin preferences are. Note that the selection -might change after connecting for a actual scan because new plugins -might become available and others might disappear. -Loading the cache may take a couple of seconds. If you don't want -this, switch off the option {}Load plugin cache for scopes immediately''. - -Third, the downside of caching: The cache will consume several megabytes -for each scope. If you do not have sufficient storage space available, you -should disable this feature. If you want to remove the caches, search for the -files {}nessus\_plugin\_cache'' in your OpenVAS directory -(the directory .openvas'' in your home directory). Simply deleting them is -sufficient. - - -\paragraph{Use plugin cache with reports} - -Enabling this setting will make OpenVAS-Client attach all Plugin Information -to newly created scan reports. This allows to review the plugin selection -and the plugin preferences for a report in the OpenVAS-Client GUI. -So, this cache is for increasing transparency not performance. - -Again, the downside is that several megabytes of cache per report will -be generated. Disable this option if you do not have sufficient storage space -available. If you want to remove the caches, search for the files -{}nessus\_plugin\_cache'' in your Nessus directory -(the directory .openvas'' in your home directory). Simply deleting them is -sufficient. - - -\paragraph{Load plugin cache for scopes immediately} - -Disabling this option will cause OpenVAS-Client to not automatically -load a scope's cache when made active. You won't see the plugin selection -nor the plugin preferences. So, in fact this option could remove the -second effect of the above described option {}Cache plugin information -when connecting'' for the benefit of avoiding to load possibly huge -caches once clicking on a scope entry. - - -\subsection{Report} - - -\paragraph{Include plugin details in PDF} - -Enabling this setting will make OpenVAS-Client add an appendix to -each PDF Report containing the details of those plugins that produced -relevant results for the report. They are linked within the PDF so -that the information can easily be browsed. - -Be aware, however, that this could significantly increase the size -of your PDF file. On average, you can expect two plugin descriptions -to consume one page. - -\paragraph{Show script origin in report window} - -Enabling this option will cause OpenVAS-Client to show additional information -in the report window regarding the origin of the reported security issue. If -this option is enabled, these reports will contain the name and the OID of the -NVT that reported the issue. - -\subsection{External Links in HTML/PDF} - -These settings determine the URLs for linking more information on -OpenVAS NVTs, CVE/CAN and BugTraq IDs in HTML or PDF reports. The defaults as -shown in the screenshots are recommended since these are the definitive -sources for up-to-date information. The defaults are -restored when the fields are left empty. - -In case you want to package an OpenVAS report with e.g. CVE/CAN details -for offline-reading, you may enter an appropriate definition like -mitre/\%s/\%s/\%s.html'' -in case you have a directory structure relative to the report file -with mitre/CVE/yyyy/nnnn.html and mitre/CAN/yyyy/nnnn.html where yyyy -is the year and nnnn is the number of the record. Then you could package -all files together. - -Note, that the strings defined here are inserted into the html link -parameter href'' as they are. The tool htmldoc'' is used to produce -a PDF out of this html report. Depending on the version and features -the created links in the PDF file may be created differently. - -\clearpage - -\chapter{Knowledge Base} -\compendiumauthor{} - -\clearpage - -\chapter{Performing Local Security Checks} -\compendiumauthor{Jan-Oliver Wagner} -\section{Debian Local Security Checks} - -This section explains how to run local security checks with OpenVAS. So far, -this procedure has been tested only with Debian local security checks. - -\subsection{Prerequisites} - -To perform local security checks, you need a working OpenVAS-Server -installation. Information on setting up and configuring OpenVAS-Server is -available in chapter \ref{chap:Install-And-Configure-Server}. - -\subsection{Create users for local security checks} - -First, you need a key with certificate: - -\begin{verbatim} -$ ssh-keygen -t rsa -f ~/.ssh/id_rsa_sshovas -C
-"OpenVAS-Local-Security-Checks-Key"
-$openssl pkcs8 -topk8 -v2 des3 -in ~/.ssh/id_rsa_sshovas -out sshovas_rsa.p8 -\end{verbatim} - -Note: The comment (here: "OpenVAS-Local-Security-Checks-Key") must not -contain spaces. -Currently, you need a rsa pkcs8 key for OpenVAS local security checks. - -Now, for each target system: -\begin{verbatim} -# adduser --disabled-password sshovas -Name: OpenVAS Local Security Checks -# su - sshovas -$ mkdir .ssh
-$cp /some/path/id_rsa_sshovas.pub .ssh/authorized_keys -$ chmod 500 .ssh
-$chmod 400 .ssh/authorized_keys -\end{verbatim} - -\subsection{Configure the local security checks in OpenVAS-Client} - -In Preferences, configure SSH Authorization: -\begin{verbatim} -SSH login name: sshovas -SSH private key: ~/.ssh/sshovas_rsa.p8 -SSH key passphrase: ******** -SSH public key: ssh/id_rsa_sshovas.pub -\end{verbatim} - -Note: It is actually not necessary to submit the public key, but currently this -is necessary due to a bug inherited from Nessus. - -Next, make sure you select at least these plugins: -\begin{itemize} -\item Debian Local Security Checks/* -\item Misc/Determine List of installed packages via SSH login -\item Service Detection/Services -\item Settings/Global variable settings -\item Settings/SSH Authorization -\end {itemize} -or ensure dependencies are resolved at runtime (see checkboxes) if you select -only some local security checks. - -\section{Windows Local Security Checks} - -In order to provide - analogous to the Linux Local Security Check - a framework -for checking and testing for Microsoft Windows vulnerabilities, a new -Application Programming Interface (API) was introduced by the OpenVAS team. - -This API (for the Nessus Attack Scripting Language, NASL) allows to check and -examine binary files (e.g. DLLs) as well Microsoft Windows meta-data on -Microsoft Windows machines by accessing the complete file system using default -Windows administrative shares. - -The functionality is similar to the Nessus Windows Local Security checks. -However, the OpenVAS solution is using samba (smbclient) and does not -re-implement the binary SMB protocol in NASL. - -The advantage of this smbclient integration is to act more flexible on protocol -changes on the SAMBA/CEFIS protocol side. - -\subsection{Preparing the OpenVAS Server} - -To install the WLSC, a few steps are required to be taken on the server that -hosts and runs the actual scan daemon "openvasd". - -It depends on the operating system where you run the OpenVAS server, how the -steps are carried out technically. - -\begin{enumerate} - -\item Install SAMBA (http://www.samba.org) - -Installation packages should be readily available for your operating system. - -\item Make sure that the binary "smbclient" in is the installation/execution -path. - -\item Check the permissions of openvasd and smbclient: smbclient must be -executable with the permissions of openvasd. - -\end{enumerate} - -\subsection{Preparing the Microsoft Windows target} - -The WLSC implementation has been tested on the following Microsoft Windows -Operating Systems: -\begin{itemize} -\item Windows NT 4.0 -\item Windows 2000 -\item Windows XP SP2 -\item Windows XP SP3 -\item Windows Vista -\end{itemize} -Probably the WLSC is also compatible with other Microsoft Operating Systems. -Once the SMB Port of a Windows target is accessible, the Operating System (OS) -and SAMBA Version could be detected immediately and will be reported. For deeper -tests the following steps are required: - -You need the Windows credentials for an administrative user. Usually this is the -user name (Default is "Administrator") and the correct password for this user. -There is no default password, this has been defined before during the Windows -installation process. - -These credentials are entered in the OpenVAS-Client GUI as SMB Credentials and -are used on every host in the target list. - -If you plan to scan a whole Windows Domain, you can enter the -Domain-Administrative user and password instead of the target host credentials. - -Make sure the Windows-(personal) Firewall is disabled for the OpenVAS Server -host, or a correct rule for the Test-Network is entered. - -\paragraph{Additional Note for Windows XP} - -For Windows XP it is important that "Easy Filesharing" is switched off. -To disable this, the Windows Click-Path is: Windows Explorer/Tools/Folder -Options/View (see screenshot below). - -Without this setting, "smbclient" is not able to retrieve files from the Windows -System shares (\verb!C$,D$...!). - -\subsection{Executing the checks via OpenVAS-Client} - -Using the OpenVAS-Client you specify the credentials and the target host -information will be reported as illustrated by the following two screenshots: - -\clearpage - -\chapter{Using Integrated Tools} - -\section{Security Local Auditing Daemon (SLAD)} -\compendiumauthor{Jan-Oliver Wagner} -\subsection{How to use Security Local Auditing Daemon (SLAD) with OpenVAS} - -Homepage: \hyperurl{http://www.dn-systems.org/slad.shtml} - -This description is a quick guide how you get first results with SLAD via -OpenVAS. For real production mode you should make yourself familiar with the -details of SLAD and its integrated tools. There is also the SLAD developer's and -administrator's guide as PDF file. - -\begin{enumerate} - -\item Download SLADinstaller from -\hyperurl{http://www.dn-systems.org/boss/slad2/sladinstaller-1.1.tar.gz} - -\item You may want to apply this patch: -\begin{verbatim} -diff -r -u sladinstaller-1.1-orig/gtk.cpp sladinstaller-1.1-openvas/gtk.cpp ---- sladinstaller-1.1-orig/gtk.cpp 2006-04-23 15:57:01.000000000 +0200 -+++ sladinstaller-1.1-openvas/gtk.cpp 2008-04-30 15:59:07.452562817 +0200 -@@ -299,8 +299,8 @@ - else - dir="~"; -} -- // and nessus directory -- dir+="/.nessus"; -+ // and OpenVAS directory -+ dir+="/.openvas"; - mkdir(dir.c_str(), 0700); - - std::string ip_; -\end{verbatim} - -\item Compile sladinstaller by just typing "make", which works at least on a -Debian GNU/Linux "Etch" 4.0. There is a file "INSTALL" which might provide some -helpful hints. - -\item Prepare SSH Authorization: It is required to use a SSH key created -following the example for ssh-keygen and openssl on the page about local -security checks. Especially take care you create a RSA .p8 key file. Reason: -sladinstaller would else create a key that is not usable with OpenVAS due to the -migration from OpenSSL to GNU/TLS. - -\item Make sure SLAD is not installed yet on your target system. Is so, remove -it this way: -\begin{verbatim} -# /opt/slad/bin/slad-uninstall.sh -\end{verbatim} - -\item Run sladinstaller and fill out the entries. Take care you apply the SSH -key you've just created on your own and don't let sladinstaller create one for -you. Hostname defines the target system. - -\item It might be necessary you have to adjust the sshd configuration of the -target system allow sladinstaller to log in. Just follow the hints given by -sladinstaller. - -\item Finally, you need to install the file "slad.inc" (which is specific to -your SLAD version) for your OpenVAS Server. Assume, SLAD is installed on the -same system as the OpenVAS Server. Then it would execute this: -\begin{verbatim} -# cd /opt/slad/share/nessus_plugins/ -# /opt/slad/bin/sladd -s plugins | awk -f sladbuild.awk > -/usr/local/openvas-production/lib/openvas/plugins/slad.inc -\end{verbatim} - -\item Finally, run OpenVAS-Client and configure your task to scan the target -where you installed SLAD and fill out the "SLAD init" preferences and, if -wished, -adjust the "SLAD run" preferences. A first scan will schedule the tasks, the -next scan will retrieve the results that were collected so far (lsof is fast, -John-the-ripper could take very long). -\end{enumerate} - -\section{Nikto} -\compendiumauthor{Michael Wiegand} - -Nikto is an Open Source (GPL) web server scanner which performs comprehensive -tests against web servers for multiple items, including over 3500 potentially -dangerous files/CGIs, versions on over 900 servers, and version specific -problems on over 250 servers. Scan items and plugins are frequently updated and -can be automatically updated (if desired). - -OpenVAS is able to recognize an installed version of Nikto and can integrate -the results of a Nikto scan in the scan results. - -\subsection{Prerequisites} - -In order to be able to perform a Nikto scan from within OpenVAS, the following -requirements must be met: -\begin{itemize} - \item There has to be a version of Nikto that can be found in the system path. -The OpenVAS integration of Nikto is optimized for Nikto versions >= 2.0, but -will probably work with older versions as well. - \item The OpenVAS plugin for Nikto integration (\textit{nikto.nasl}) needs to -be present and enabled. You can find the plugin in the section \textit{CGI -abuses} in the plugin section of your client. -\end{itemize} - -\subsection{Starting a Nikto scan} - -If the Nikto plugin is present and enabled, it will be executed with your next -scan. The results returned by Nikto will be available together with the rest of -the scan results. - -\subsection{Understanding Nikto results} - -Some web servers are (intentionally or unintentionally) configured to respond -to requests for non-existent with an HTTP status code other than 404. This can -be used to direct these requests from human users to a page with helpful -information (like a sitemap), but tends to confuse security assessment tools -like Nikto checking whether possibly sensitive or dangerous content can be -accessed on the target server. - -The Nikto plugin is able to recognize this condition in most web servers and -will (in the default setting) refuse to launch Nikto under these circumstances. -You can however force the Nikto plugin to launch Nikto by enabling the option -\textit{Force scan even without 404s} in the plugin preferences. - -If you enable this option, please be aware that the results of the Nikto scan -are likely to contain false positives; because of the web server configuration -described above Nikto may be convinced that certain files exist on the web -server, even though the server simply redirected these requests to a generic -page. - -This is especially true for older versions of Nikto (< 2.0); but even with -newer versions you may need to manually evaluate whether the threats reported -by Nikto are real threats or simply the result of the web server configuration. - -\clearpage - -\chapter{Developers Guide for NASL scripts} - -\section{Basic Structure of a NASL NASL Scripts} - -\compendiumauthor{Tim Brown} - -\subsection{API Documentation} - -\subsubsection{script\_oid()} - -This function is intended to replace \verb!script_id!, the current method of uniquely -identifying NASL scripts. The logic behind this is that \verb!script_id! has only a single -global namespace. With plans by several organisations to develop and contribute -plugin feeds it was deemed necessary to introduce a new namespace that could be -shared between each organisation. - -The current proposed implementation of this function is as follows. Any plugin that -contains a \verb!script_id! call will automatically be given an OID from the namespace -allocated for legacy plugins. Moreover \verb!script_oid! can only be used on plugins -that do not have a \verb!script_id! set. The OID namespace for legacy plugins has the -prefix "1.3.6.1.4.1.25623.1.0". The OpenVAS OID namespace is currently administered -by Tim Brown. - -Both the client and server as well as the libraries on which they depend are being -updated to support this functionality. You can detect if it is supported by checking -OPENVAS\_NASL\_LEVEL is greater than 2206. - -\verb!script_oid! should be called like so: - -\begin{verbatim} - ... - if(description) - { - if (OPENVAS_NASL_LEVEL >= 2206) - { - script_oid("1.3.6.1.4.1.25623.1.0.90010"); - } - else - { - script_id(90010); - } - ... -\end{verbatim} - -\section{Writing WLSC NASL Scripts} - -\compendiumauthor{Carsten Koch Mauthe} - -The SMB-Client API is made available as \verb!smbcl_func.inc!. This file has to -be included in any WLSC Script. - -\subsubsection{smbclientavail()} - -This function returns TRUE if smbclient can be used from within openvasd. -It also sets the knowledge base item "SMB/smbclient". It should be called first -in any WLSC Script. -Example: - -\begin{verbatim} - include("smbcl_func.inc"); - if(!get_kb_item("SMB/smbclient")) - { - smbclientavail(); - } - if(get_kb_item("SMB/smbclient")) - { - do something; - } - else - { - report = string("SMBClient not found on this host !"); - security_note(port:0, proto:"SMBClient", data:report); - exit(0); - } -\end{verbatim} - -\subsubsection{smbversion()} - -This function returns TRUE if successful and writes the DOMAIN, OS Version and -SMB Server version to the knowledge base as items "SMB/DOMAIN", "SMB/OS" and -"SMB/SERVER". - - -\subsubsection{smbgetfile(share, filename, tmp\_filename)} - -Use this function to get a file from the target host and save this file locally -using tmp\_filename. Returns TRUE if successful. -Example: -\begin{verbatim} - tmp_filename = get_tmp_dir() + "tmpfile" + rand(); - orig_filename = "C:\Windows\systems32\ntdll.dll"; - smbgetfile(share: "C$", filename: orig_filename, tmp_filename: tmp_filename)
-\end{verbatim}
-
-\subsubsection{smbgetdir(share, dir, typ)}
-
-Use this function to get directory entries from the SMB source.
-\begin{description}
- \item[typ = 0:] All entries
- \item[typ = 1:] Only file entries
- \item[typ = 2:] Only directory entries
-\end{description}
-
-With this it is possible to check for one or more files or directories.
-Returns NULL or array of Strings containing found entries.
-Example:
-
-\begin{verbatim}
-  r = smbgetdir(share: "C$", dir: "C:\Windows\systems32\*.dll", typ: 1); -\end{verbatim} - -\subsubsection{GetPEFileVersion (tmp\_filename, orig\_filename)} - -This function returns the Version of Windows PE/32 executables like .exe or -.dll. Together with smbgetfile, this can be used to check for Windows -vulnerabilities. - -Example: -\begin{verbatim} - tmp_filename = get_tmp_dir() + "tmpfile" + rand(); - orig_filename = "C:\Windows\systems32\ntdll.dll"; - if(smbgetfile(share: "C$", filename: orig_filename,
-                tmp_filename: tmp_filename))
-  {
-    v = GetPEFileVersion(tmp_filename:tmp_filename,
-                        orig_filename:orig_filename);
-    if(v = "1.2.3.4")
-    {
-      ...
-\end{verbatim}
-
-\subsubsection{get\_windir()}
-
-This function returns the standard Windows folder WINNT or WINDOWS, depending on
-the OS found by "smbversion".
-
-\subsection{Example}
-
-This is a complete NASL test for a Windows Local Security Check. It can be found
-in the OpenVAS plugins as win\_CVE-2007-0043.nasl.
-
-\begin{verbatim}
-#
-# This script was written by
-# Carsten Koch-Mauthe
-# <c.koch-mauthe at dn-systems.de>
-#
-# This script is released under the GNU GPLv2
-#
-# $Revision: 01$
-
-if(description)
-{
-  if (OPENVAS_NASL_LEVEL >= 2206)
-  {
-    script_oid("1.3.6.1.4.1.25623.1.0.90010");
-  }
-  else
-  {
-    script_id(90010);
-  }
-  script_version ("$Revision: 01$");
-  script_cve_id("CVE-2007-0043");
-  name["english"] = ".NET JIT Compiler Vulnerability";
-  script_name(english:name["english"]);
-
-  desc["english"] =
-"The remote host is affected by the vulnerabilities described in CVE-2007-0043
-
-Checking if System.web.dll version is less than 2.0.50727.832
-
-Impact
-    The Just In Time (JIT) Compiler service in Microsoft
-    .NET Framework 1.0, 1.1, and 2.0 for Windows 2000, XP,
-    Server 2003, and Vista allows user-assisted remote
-    attackers to execute arbitrary code via unspecified
-    vectors involving an unchecked buffer, probably a
-    buffer overflow, aka .NET JIT Compiler Vulnerability.
-    Checking if System.web.dll version is less than 2.0.50727.832
-
-References:
-    http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0043
-
-Solution:
-    All users should upgrade to the latest version.
-
-
-Risk factor : High";
-
-  script_description(english:desc["english"]);
-  summary["english"] = "Test for .NET JIT Compiler Vulnerability";
-  script_summary(english:summary["english"]);
-  script_category(ACT_GATHER_INFO);
-  script_copyright(english:"This script is under GPLv2");
-  family["english"] = "Windows.NET";
-  script_family(english:family["english"]);
-  exit(0);
-}
-
-#
-# The code starts here
-#
-
-include("version_func.inc");
-include("smbcl_func.inc");
-
-if(!get_kb_item("SMB/smbclient"))
-{
-  smbclientavail();
-}
-test_version = "2.0.50727.832";
-
-if(get_kb_item("SMB/smbclient"))
-{
-  if(smbversion() == 0)
-  {
-    report = string("Error getting SMB-Data -> " +
-                    get_kb_item("SMB/ERROR"));
-    security_note(port:0, proto:"SMBClient", data:report);
-    exit(0);
-  }
-}
-else
-{
-  report = string("SMBClient not found on this host !");
-  security_note(port:0, proto:"SMBClient", data:report);
-  exit(0);
-}
-
-win_dir = get_windir();
-if(!isnull(win_dir))
-{
-  path = win_dir+"Microsoft.NET\Framework\";
-  filespec = "v2*";
-  r = smbgetdir(share: "C$", dir: path+filespec, typ: 2); - if(!isnull(r)) - { - filespec = r[0] + "\" + "system.web.dll"; - r = smbgetdir(share: "C$", dir: path+filespec, typ: 1);
-    if(!isnull(r))
-    {
-      tmp_filename = get_tmp_dir() + "tmpfile" + rand();
-      orig_filename = path + filespec;
-      if(smbgetfile(share: "C$", filename: orig_filename, - tmp_filename: tmp_filename)) - { - v = GetPEFileVersion(tmp_filename:tmp_filename, - orig_filename:orig_filename); - unlink(tmp_filename); - if(version_is_less(version: v, test_version: test_version)) - { - security_hole(port:0, proto:"SMB"); - report = report + "Fileversion : C$ " +
-                    orig_filename + " "+ v + string("\n");
-          security_hole(port:0, proto:"SMB", data:report);
-        }
-      }
-      else
-      {
-        report = string("Error getting SMB-File -> " +
-                        get_kb_item("SMB/ERROR")) + string("\n");
-        security_note(port:0, proto:"SMB", data:report);
-      }
-    }
-  }
-  else
-  {
-    report = string(".NET V2xx not found/no access -> " +
-                    get_kb_item("SMB/ERROR")) + string("\n");
-    security_note(port:0, proto:"SMB", data:report);
-  }
-}
-
-exit(0);
-\end{verbatim}
-
-
-\clearpage
-
-\chapter{Developers Guide for OpenVAS Server and Client}
-\compendiumauthor{Jan-Oliver Wagner}
-\section{The OpenVAS Source Code Map}
-
-\section{Management of OpenVAS Change Requests}
-
-OpenVAS change requests describe proposed changes to one of the OpenVAS
-components. Though this is a formalized approach, this does not replace open
-discussion among interested developers on the mailing lists. In fact, these open
-discussions are the main source of change requests. This approach is intended
-to make the OpenVAS development process as transparent as possible to the
-OpenVAS developers as well as to the OpenVAS user community and other interested
-parties.
-
-You can find the most current change requests at:
-
-\hyperurl{http://www.openvas.org/openvas-crs.html}.
-
-A complete change request consists of the following sections:
-
-\begin{description}
- \item[Status:] A general description of the current status of this request.
-This could be something like in discussion'', agreed (voted +3) for release
-1.4'' or Step 1 and 2 implemented''.
- \item[Purpose:] A concise summary of the reasons for this change request.
- \item[References:] Links to corresponding issue tracker entries or mailing list
-discussions.
- \item[Rationale:] A more verbose explanation as to why this change request
-should be implemented.
- \item[Effects:] The effects should this change request be implemented,
-describing changes to API, compatibility, user experience and so on.
- \item[Design and Implementation:] Technical details regarding the
-implementation of this change request.
- \item[History:] Date, name and description of changes to this change request in
-ChangeLog format.
-\end{description}
-
-Change requests can be created by anybody; although most change requests are
-created by OpenVAS developers, this is not in any way meant to exclude
-anyone from creating their own change request and submitting it to the
-openvas-discuss mailing list. Authors of change requests are encouraged to
-discuss their ideas for change requests on this mailing or in the OpenVAS IRC
-channel (\#openvas on irc.oftc.net) before compiling the actual request.
-
-The OpenVAS developer community regularly votes on new change requests. Every
-OpenVAS developer can vote for or against a certain changed request by voting
-+1'' (for), +/-0'' (somewhat for/against) or -1'' (against). After a
-number of days has passed, the votes are counted; a positive result means that
-the change request has been accepted and will be implemented in future versions
-of OpenVAS.
-
-The voting process itself is not yet fully formalized and subject to change;
-ideas and suggestions are welcome.
-
-\section{Submitting Patches}
-
-\section{Write-Access to Source Code Repository}
-
-Write access to the source code repository is granted by the project
-coordinators. If you want to able to commit changes to the source code
-repository, just drop a message on the openvas-devel mailing list.
-Usually you are asked to send your first changes as patches to the
-mailing list to demonstrate you know what you are doing. If these
-are accepted, it is also usual that you are immediately approved for
-write access to the source code repository.
-
-Note that that changes to the code repository are watched by several
-developers. Low quality changes or uncoordinated high-impact-changes
-might get reverted immediately.
-
-\section{Maintaining ChangeLog}
-
-Any main module of OpenVAS maintains a ChangeLog'' file in its
-root directory. It is a GNU-style ChangeLog and syntax highlighting
-for your favorite editor should work out of the box.
-
-Some rules for the ChangeLog file:
-
-\begin{itemize}
-\item Keep the GNU-style syntax for your new entries. Your syntax-highlighting
-      editor will support you.
-\item Make atomic commits: Always include the updated ChangeLog file together with
-      the changed files.
-\item List any changed file explicitly in the ChangeLog, even if there were many.
-      See the ChangeLog file for examples how to write the change information.
-\end{itemize}
-
-Note: The ChangeLog is intentionally not created automatically. Before committing,
-developers are forced to reflect on the changes they did. This regularly leads
-to detection of suboptimal changes or identification of intermediate (try-out/debugging)
-changes that of course should not go to the main repository.
-
-The developer's ChangeLog is the base for writing the user's CHANGES when a new
-release is prepared.
-
-\section{Source Code Style Guide}
-
-Currently there is no complete definition of a style guide
-for the source code of OpenVAS.
-
-In fact, several styles have been mixed into OpenVAS over
-the last years, most inherited from the old Nessus times.
-
-However, some rules should always be followed when adding
-new code or when changing some source code lines anyway.
-For the rest, it makes sense to be close to the GNU coding style
-which you will find more or less applied already.
-
-\begin{itemize}
-
-\item Indention: Do not use tabulators at all, only regular spaces.
-
-\item Indention: Indent with a step of 2 space characters.
-
-\item Function definitions: Do not use old K\&R style.
-
-\end{itemize}
-
-\clearpage
-
-\chapter{Document License: CC by SA}
-
-\begin{latexonly}
-\urlstyle{normal}
-
-\begin{center}
-\IncludeImage[width=5cm]{images/cc-by-sa-logo}
-\textbf{Creative Commons Attribution-ShareAlike 3.0 Unported}
-\end{center}
-
-
-You are free to copy, distribute and transmit the work under the following
-conditions:
-
-\textit{Attribution.} You must give the original author credit.
-
-\textit{Share Alike.} If you alter, transform, or build upon this work,
-you may distribute the resulting work only under a license identical to this one.
-
-\begin{itemize}
-  \item  For any reuse or distribution, you must make clear to others the license terms of this work.
-  \item  Any of the above conditions can be waived if you get permission from the copyright holder.
-\end{itemize}
-
-
-Nothing in this license impairs or restricts the author's moral rights.\\
-To view the full licensing agreement, visit
-\begin{center}
-    \normalsize\hyperurl{http://creativecommons.org/licenses/by-sa/3.0/}
-\end{center}
-or mail to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.
-\end{latexonly}
-
-\W \hyperurl{http://creativecommons.org/licenses/by-sa/3.0/}
-
-\end{document}

Modified: trunk/openvas-compendium/ChangeLog
===================================================================
--- trunk/openvas-compendium/ChangeLog	2008-08-01 17:58:36 UTC (rev 1092)
+++ trunk/openvas-compendium/ChangeLog	2008-08-01 18:08:03 UTC (rev 1093)
@@ -1,3 +1,7 @@
+2008-08-01  Jan-Oliver Wagner <jan-oliver.wagner at intevation.de>
+
+	* openvas-compendium.tex: New. Moved here from doc module.
+
2008-06-01  Michael Wiegand <michael.wiegand at intevation.de>

Removing support of old XML report format according to

Copied: trunk/openvas-compendium/openvas-compendium.tex (from rev 1090, trunk/doc/openvas-compendium/openvas-compendium.tex)



More information about the Openvas-commits mailing list