[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