Author: jan
Date: 2007-10-20 20:45:47 +0200 (Sat, 20 Oct 2007)
New Revision: 452

Added:
   trunk/doc/website/trusted-nvts.htm4
Modified:
   trunk/doc/website/template_header.m4
Log:
Adding page about trust and signatures for NVTs.


Modified: trunk/doc/website/template_header.m4
===================================================================
--- trunk/doc/website/template_header.m4        2007-10-18 14:32:14 UTC (rev 
451)
+++ trunk/doc/website/template_header.m4        2007-10-20 18:45:47 UTC (rev 
452)
@@ -68,6 +68,7 @@
      <p>
      <a href="sources-for-security-issues-information.html">Security info 
sources</a><br>
      <a href="creation-process-nvt.html">NVT creation process</a><br>
+     <a href="trusted-nvts.html">Trusted NVTs</a><br>
      </p>
     </div>
 

Added: trunk/doc/website/trusted-nvts.htm4
===================================================================
--- trunk/doc/website/trusted-nvts.htm4 2007-10-18 14:32:14 UTC (rev 451)
+++ trunk/doc/website/trusted-nvts.htm4 2007-10-20 18:45:47 UTC (rev 452)
@@ -0,0 +1,284 @@
+m4_dnl -*-html-*-
+m4_include(`template.m4')
+
+m4_dnl OpenVAS
+m4_dnl $Id$
+m4_dnl Description: Description of the NVT signature concept
+m4_dnl
+m4_dnl Authors:
+m4_dnl Jan-Oliver Wagner <[EMAIL PROTECTED]>
+m4_dnl
+m4_dnl Copyright:
+m4_dnl Copyright (C) 2007 Intevation GmbH
+m4_dnl
+m4_dnl This program is free software; you can redistribute it and/or modify
+m4_dnl it under the terms of the GNU General Public License version 2,
+m4_dnl as published by the Free Software Foundation.
+m4_dnl
+m4_dnl This program is distributed in the hope that it will be useful,
+m4_dnl but WITHOUT ANY WARRANTY; without even the implied warranty of
+m4_dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+m4_dnl GNU General Public License for more details.
+m4_dnl
+m4_dnl You should have received a copy of the GNU General Public License
+m4_dnl along with this program; if not, write to the Free Software
+m4_dnl Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 
USA.
+
+PAGE_START
+
+<h2>Trusted NVTs (how to manage NVT signatures)</h2>
+
+<h3>What is a signature (in simple words)?</h3>
+
+<p>
+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.
+</p>
+
+<p>
+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.
+</p>
+
+<p>
+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.
+</p>
+
+<p>
+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.
+</p>
+
+<h3>The signature format</h3>
+
+<p>
+The signatures for OpenVAS NVTs and associated files
+(.nasl, .inc and .nes) are standard so-called "ASCII-armored
+detached OpenPGP signatures" created with
+<a href="http://www.gnupg.org";>GnuPG</a>.
+This format features:
+</p>
+
+<ul>
+<li> multiple signer keys possible
+
+<li> site administrators can decide which keys to trust
+
+<li> signatures can be created and verified with widely available tools like 
GnuPG
+
+<li> detached signatures do not require changes to the signed file (like inline
+     signatures would)
+</ul>
+
+<p>
+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".
+</p>
+
+<p>
+Note difference to Nessus: Nessus signatures were inline x509-based signatues.
+The concept does not consider multiple signatures. A standard problem of
+inline signatures is that you can place bad code around a valid block. Whether
+such injection of untrusted code works for Nessus has not been tested by
+the OpenVAS team, though.
+</p>
+
+<h3>The signature verification process</h3>
+
+<p>
+The signature vertification of the OpenVAS server is applied
+due to the default setting "nasl_signature_check = no" in
+/etc/openvas/openvasd.conf". It is highly recommended to not change this
+option.
+</p>
+
+<p>
+At start-up time of the openvas daemon (openvasd), all signatures
+are checked for validity. Only fully trusted files are considered by
+the server and thus loaded and made available to OpenVAS client.
+</p>
+
+<p>
+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.
+</p>
+
+<p>
+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:
+</p>
+
+<ol>
+<li> The certificate must be present in the keyring.
+<li> The key must be fully valid.
+<li> The signature must be valid.
+</ol>
+
+<p>
+If any of the signatures does not meet all of these criteria, the file
+is considered untrustworthy and will not be exectuded at all.  If all
+signatures meet the criteria, the script is trusted fully and may
+execute any functions. If no signature file exists,
+the script is not executed at all.
+</p>
+
+<p>
+Note difference to Nessus: For Nessus signatures, three levels
+were distinguished: no signature, bad signature and good signature.
+Plugins with no signature were still executed, but in some
+"restricted" mode where no functions can be executed that
+are regarded critical like "fwrite".
+OpenVAS explicitely only distinguished between
+fully trusted and not fully trusted files.
+</p>
+
+
+<h3>How to add a certificate</h3>
+
+<p>
+To add a certifcate to the OpenVAS Server keyring issue this command:
+</p>
+
+<pre>
+# gpg --homedir=/etc/openvas/gnupg --import certificate-file.asc
+</pre>
+
+<p>
+See at the bottom for available certificate files.
+</p>
+
+<h3>Initial preparation to set trust: create key</h3>
+
+<p>
+To express trust to 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 you already have, or you can generate a new one:
+</p>
+
+<pre>
+# gpg --homedir=/etc/openvas/gnupg --gen-key
+</pre>
+
+<p>
+This needs to be done only once for a OpenVAS Server installation.
+</p>
+
+<h3>How to set trust</h3>
+
+<p>
+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 unknown validity and thus is not valid.
+</p>
+
+<p>
+To set a certificate trusted for your purpose, you have to sign it.
+The preferred way is to use local signatures that remain only in the
+keyring of your OpenVAS Server installation.
+</p>
+
+<p>
+To finally sign a certificate you need to know its KEY_ID.
+You either get it from the table at the bottom or via a
+"list-keys" command. Then you can locally sign:
+</p>
+
+<pre>
+# gpg --homedir=/etc/openvas/gnupg --list-keys
+
+# gpg --homedir=/etc/openvas/gnupg --lsign-key KEY_ID
+</pre>
+
+<p>
+Before signing you should be absolutely sure
+you it is the correct certificate you are ging to sign.
+You may use its fingerprint and other methods to
+convince yourself.
+</p>
+
+<h3>How to remove a certificate</h3>
+
+<pre>
+# gpg --homedir=/etc/openvas/gnupg --delete-keys KEY_ID
+</pre>
+
+<h3>Manual signature verification</h3>
+
+<p>
+In case you want to manually verify the validity
+of a .nasl file, you need to do the following:
+</p>
+
+<p>
+To verify signatures on the command line, you can either run GnuPG:
+</p>
+
+<pre>
+$ gpg --homedir=/etc/openvas/gnupg gpg --verify script.nasl.asc script.nasl
+</pre>
+
+<p>
+Or you can use the standalone nasl interpreter:
+</p>
+
+<pre>
+$ openvas-nasl -p script.nasl
+</pre>
+
+<p>
+The -p Option means that the script is only parsed and not executed.
+</p>
+
+<p>
+To debug the signature verification done by the nasl interpreter, use
+the -T Option to enable the trace mode.  The signature verification will
+leave some detailed information about the verification and the
+signatures found in the trace file.
+</p>
+
+<h3>Overview on existing certificates</h3>
+
+<p>
+<b>Note:</b> No certificates have been yet prepared for production
+mode. The following table illustrates a sample how it could look like:
+</p>
+
+<table>
+<tr>
+<th>Certificate Name</th>
+<th>ID</th>
+<th>Download</th>
+<th>Owner(s)</th>
+<th>Description</th>
+</tr>
+
+<tr>
+<td valign="top">OpenVAS: Original Nessus Plugin</td>
+<td valign="top">5DA7D579</td>
+<td valign="top"><a href="">OpenVAS_ONP.asc</a></td>
+<td valign="top">Max Headroom &lt;[EMAIL PROTECTED]&gt;</td>
+<td valign="top">
+This key is used to sign those NVTs that are identical
+to original Nessus Plugins as served via its GPL feed.
+<p>
+The owners of the key do execute diff-commands between
+the original Nessus Plugins and only sign if this
+results no difference. Naturally, the inline signature
+of the Nessus plugins is removed before comparison.
+</p>
+</td>
+</tr>
+</table>

_______________________________________________
Openvas-commits mailing list
[email protected]
http://lists.wald.intevation.org/mailman/listinfo/openvas-commits

Reply via email to