[Openvas-commits] r454 - in trunk/openvas-client: . doc

scm-commit@wald.intevation.org scm-commit at wald.intevation.org
Sun Oct 21 21:26:55 CEST 2007


Author: jan
Date: 2007-10-21 21:26:54 +0200 (Sun, 21 Oct 2007)
New Revision: 454

Removed:
   trunk/openvas-client/README_SSL
   trunk/openvas-client/doc/WARNING.En
   trunk/openvas-client/doc/WARNING.Fr
Modified:
   trunk/openvas-client/ChangeLog
Log:
* README_SSL, doc/WARNING.En, doc/WARNING.Fr: Removed due
to phrases that render the text files non-free.


Modified: trunk/openvas-client/ChangeLog
===================================================================
--- trunk/openvas-client/ChangeLog	2007-10-21 19:21:37 UTC (rev 453)
+++ trunk/openvas-client/ChangeLog	2007-10-21 19:26:54 UTC (rev 454)
@@ -1,3 +1,8 @@
+2007-10-21  Jan-Oliver Wagner <jan-oliver.wagner at intevation.de>
+
+	* README_SSL, doc/WARNING.En, doc/WARNING.Fr: Removed due
+	to phrases that render the text files non-free.
+
 2007-09-24  Jan-Oliver Wagner <jan-oliver.wagner at intevation.de>
 
 	* nessus/backend.c (backend_init): Replaced "nessus" by "openvas"

Deleted: trunk/openvas-client/README_SSL
===================================================================
--- trunk/openvas-client/README_SSL	2007-10-21 19:21:37 UTC (rev 453)
+++ trunk/openvas-client/README_SSL	2007-10-21 19:26:54 UTC (rev 454)
@@ -1,409 +0,0 @@
--*- Indented-Text -*-
-
-   * What you should know about SSL support in Nessus 1.2 *
-
- $Version$
-
-0. Copyright
-
-(C) 2001-2002 Michel Arboi <arboi at alussinan.org>
-I grant permission to redistribute this file, provided that it is not
-modified.
-
-
-1. What are the differences between Nessus 1.0.x and Nessus 1.2.x ?
-
-For miscellaneous reasons, libpeks (the library being used for the
-client - server communication) was removed. 
-(Have a look at the message that I posted on the nessus-devel mailing
-list for details.)
-
-Starting with Nessus 1.1.4, the communication between the nessusd server 
-and the nessus client is enciphered with TLSv1. 
-You may still disable the cipher layer when you configure & compile
-Nessus (this is the default if OpenSSL is not found), or by setting
-"ssl_version" to "NONE" in the configuration files.
-
-Note: in earlier 1.1.x versions, SSLv3 was used. You may still have
-this behaviour by setting "ssl_version" to "SSLv3".
-
-Authentication can be based upon the client certificate or the
-password.
-In fact, you will always have to enter a username & a password.
-
-
-2. What do you need?
-
-- the openSSL library - http://www.openssl.org
-  (use OpenSSL 0.9.6e. Older versions may be insecure. Versions
-   before 0.9.5 will not link)
-- a SSL server certificate & private key
-- the CA certificate
-- you may need client certificates if 'force_pubkey_auth' is set in
-  nessusd.conf 
-  There is no way to disable this for a specific user.
-
-
-3. How to install
-
-(In this chapter, $src stands for the directory where you extracted
-the sources, and $prefix the root directory installation,
-e.g. /usr/local)
-
-Once you have configure and installed Nessus (i.e. nessus-libraries,
-libnasl, nessus-core and nessus-plugins), you have three options:
-- disable encryption in the configuration files
-  Since we added this option, the insecure "Nessus kabale"
-  certificates should not be used anymore. 
-- use the mknessus-cert script
-- use your own certificates
-
-The fourth option is to configure Nessus with --disable-cipher: 
-the client/server communications will never be enciphered.
-
-
-3.0. No SSL layer - hard coded
-
-Configure nessus-libraries and nessus-core with --disable-cipher. 
-This is the default if OpenSSL is not installed.
-If it is installed, Nessus will use it to test SSL based services
-(e.g. HTTPS) however.
-
-
-3.1. Disable SSL layer in configuration files
-
-Setting "ssl_version=none" in nessusd.conf and in .nessusrc disables
-the cipher layer.
-
-This option is available in Nessus 1.2.0, and did not exist in the
-earlier 1.1.x. 
-That's why we created the INSECURE "Nessus Kabale" certificates, for
-people who would use pre-compiled packages. 
-You have no reason to use them any more. If you do not want to
-generate and install your own certificates, use clear text
-communications! 
-
-
-3.2. mknessus-cert
-
-This is much better, but not perfect, as the generated certificates
-ARE NOT PASSWORD PROTECTED.
-
-3.2.1. CA & server certificate
-
-As root,  run nessusclient-mkcert
-The script will ask you a few question then generate 2 certificates
-and 2 private keys:
-- the CA
-- the SSL server
-
-If you do not plan to use client certificates, you may destroy your CA
-private key, you will not need any more and this prevent some hacker
-from generating faked certificates.
-Otherwise, you'd better save the CA private key on some removable
-media, as it is NOT password protected (yes, you read it already, I
-know, but I have to insist: it is not password protected. Understood?)
-
-3.2.2. Client certificates 
-
-[TBD]
-Run nessusclient-mkcert and answer the questions.
-You'll have to copy the client certificate & key somewhere, as well as
-the std.cnf and stdC.cnf 
-Users will have to update their .nessusrc files:
-------------------------------------------------------------------
-cert_file = /path/to/e.g./cln.pem
-key_file = /path/to/e.g./clnP.pem
-------------------------------------------------------------------
-
-If I were you, I would NOT reuse those certificates for something
-else, like S/MIME.
-
-
-3.3. Your own certificates
-
-Much better. If you want to create your own certificates, you may use
-/usr/share/ssl/misc/CA.pl from OpenSSL.
-
-Here is what you should know:
-- Nessus only supports PEM files.
-- Although I only tested RSA keys, DSA keys should work as well.
-- You'd better create a "SSL server" certificate for nessusd, but we
-  do not check the usage, in fact.
-  OpenSSL may run some kind of consistency check though...
-- The behaviour of the Nessus client is described in §5 below. [TBD]
-- If "force_pubkey_auth" is set in nessusd.conf, the server will accept
-  a client certificate as long as it is signed by the CA you specified
-  in the "ca_file" parameter
-- the parameters in nessusd.conf are:
- - force_pubkey_auth = flag ("yes"/"no"). If set, the server verifies
-		       the peer (client) certificate.  
- - cert_file	     = path to your PEM certificate.
- - key_file	     = path to your PEM private key.
- - pem_password	     = the PEM password that protects your private key
- - ca_file	     = path to your PEM CA certificate.
- - ssl_version	     = SSL version used by the server.
-		       Allowed options are: NONE, SSLv2, SSLv3, TLSv1
-		       (the default) and SSLv23 (compatibility mode).
-		       - NONE disables the cipher layer.
-		       - if you want to use client certificates,
-			 choose SSLv3 or TLSv1. 
-
-- the parameters in the client .nessusrc are:
- - cert_file
- - key_file
- - ssl_version         Allowed options are the same as the
-		       server: NONE, SSLv2, SSLv3, TLSv1, SSLv23. 
-		       However, SSLv23 will not work if the server SSL
-		       version is SSLv3 or TLSv1.
-
-Note that the pem_password protection is not great as it is stored in
-the nessusd.conf files. We shall change that later.
-
-*Please* do not ask for support on all this. We are working on a
-security scanner, not a PKI project!
-You may find the "Open Source PKI Book" interesting. Its web site is
-http://ospkibook.sourceforge.net/ 
-
-
-4. Known problems
-
-4.1. Bugs?
-
-Oh yes, there are plenty of nasty big bugs sneaking around :-\
-If you find them, e-mail me or nessus-devel.
-
-4.2. No random device
-
-On Linux or BSD, you should not have any problem with this. 
-On operating systems like Solaris without a random device
-(e.g. /dev/urandom), OpenSSL init will fail with a "PRNG not seeded"
-error. 
-Cf. http://www.openssl.org/support/faq.html#USER1
-
-There are several solutions:
-
-- install a random generator device driver
-  There is a package for Solaris, for example.
-  If this does not work, I suspect that you may have to recompile and
-  reinstall OpenSSL afterwards.
-
-- use a seed file.
-  By default, OpenSSL looks for $HOME/.rng but you may override this
-  by setting the RAND environement variable.
-  You will have to fill this seed file with enough "random" data.
-  nessusclient-mkrand is your friend!
-
-- install and run egd, the entropy gathering daemon
-  Unless its Unix socket path is really weird, OpenSSL is supposed
-  to use it. That's what the documentation has said for some time,
-  but unfortunately, this looks unsupported in version before 0.9.7
-  If you still have a problem with it, reconfigure nessus-libraries
-  and  nessus-core with  
-   configure --with-egd=/path/to/egd-socket
-  recompile and reinstall.
-
-4.3. SSL not available for client architecture
-
-If your server is compiled with SSL support, your client must have it
-too. The only [simple] way to enable or disable the SSL layer at will
-would be to use two TCP ports on the server (just like 80 & 443 for 
-HTTP). Maybe we should implement this...
-
-4.4 Certificate based authentication does not work on Unix sockets
-
-This is a Nessus limitation. We should fix this.
-If you compile Nessus with the Unix socket support, you have to use
-password authentication.
-
-
-5. Trust & security
-
-Note: This chapter describes some things that do not exist _yet_ or
-are not fully implemented.
-
-5.1. Theoreticall weaknesses
-
-- Fake server
-  Some hacker installs a fake Nessus server. Using it, he is able to
-  steal your username & password.
-- Man in the middle
-  Some hacker hijacks the connection between the server and the
-  client. More or less equivalent to the first attack.
-- Brute force
-  Some hacker connects to the server and tries kazillons of
-  passwords. Sooner or later, he will find a good one.
-
-5.2. The server
-
-If force_pubkey_auth is not set, the server will accept a user if:
-
-- there is a file $prefix/var/nessus/users/$user/auth/dname and the
-  user was able to present a valid certificate with a DN that matches
-  the  content of it.
-  The certificate is accepted as soon as it is signed by a trusted
-  CA. i.e., at this time, by the same CA as the server [TBD]
-
-- or there is a file $prefix/var/nessus/users/$user/auth/password and
-  the user was able to give the right password. You do not need a
-  client certificate here.
-  (this was the standard behaviour)
-
-Note: if if you present an invalid client certificate, you will be
-rejected. Remove the cert_file and key_file lines from your .nessusrc
-file if you want to switch to password authentication.
-
-
-If force_pubkey_auth is set, any user MUST present a valid
-certificate. Then the rest of the procedure is applied, depending on
-the existence of the dname or password files.
-IMHO, in this situation, any user should be identified with his DN.
-
-Note: Nessus does not handle CRL yet because OpenSSL 0.9.6 does not
-support. OpenSSL 0.9.7 should be able to check them, we'll improve
-the code at the time.
-
-5.3. The client
-
-The client has three "levels of paranoia" (see paranoia_level in
-.nessusrc)
-1. The certificate hash is matched against what was previously stored
-   in .nessusrc.cert
-   If the certificate was modified (or is brand new), nessus will ask
-   you if you accept it. Please read it *carefully* and answer "yes"
-   or "no".
-   If "no", the connection will be rejected.
-   If "yes", the certificate SHA1 hash will be stored into
-   .nessusrc.cert and nessus will never bother you again with it,
-   EVEN WHEN THE CERTIFICATE BECOMES OUT OF DATE!
-
-2. The certificate will be accepted IF AND ONLY IF it is signed by a
-   trusted CA. In .nessusrc, trusted_ca should point to the right CA 
-   file.
-   We rely entirely upon OpenSSL for all this, and the certificate
-   will be rejected as soon as it is out of date, as far as I know.
-   Use this level if you manage many servers.
-
-3. The certificate MUST be accepted by OpenSSL first, i.e. be valid
-   AND signed by a trusted CA. After that, the behaviour looks like
-   level (1)
-   This level is good for paranoid who manage several servers.
-
-
-5.4. Known weaknesses
-
-5.4.1. Server names
-
-Certificates in .nessusrc.cert (for paranoia_level = 1 or 3) are
-identified by the hostname. That is, if your machine is "gizmo" in
-"localdomain", you will get "new certificate alerts" if you connect
-to your machine by using 127.0.0.1, then "localhost", then "gizmo",
-then "gizmo.localdomain".
-This also means that you may be vulnerable to some DNS spoofing
-attack.
-Paranoia level 1 is not better or worse than the previous behaviour
-(with peks). Paranoia levels 2 or 3 are definitely better.
-
-5.4.2. Man in the middle, etc.
-
-If some nasty guy tries to hijack your connection, you will get a "new
-certificate alert" in paranoia level 1, and a SSL error in 2 or 3.
-Be careful in level 1 before you accept a new certificate!
-Once again, SSL and X.509 protects you.
-
-
-6. HNFAQ
-
-This is the "hopefully not frequently asked questions"!
-
-- My client reports a SSL error when it connects to Nessusd
-  Maybe you are using an old SSLv3 client and a new TLSv1 server.
-  Set "ssl_version=SSLv3" in nessusd.conf or use a newer client
-  software. 
-
-- I want to use an old 1.0.x client with a new 1.2.x server, or vice
-  versa. 
-  Old client/server used PEKS, new uses SSL. There is no
-  compatibility. You have to disable the cipher layer by setting
-  ssl_version=none in .nessusrc or nessusd.conf
-  
-- Wasn't it better to use SSLv3 rather than TLSv1?
-  Who knows? Maybe. We just had to change a couple of lines in the
-  the source code, we can do it in the other way
-  (note to developers: you may have to change
-   nessus_register_connection if the change is more complex)
-
-- What key lengths are used?
-  As far as I know, 128 bits for the symetric session keys.
-  nessusclient-mkcert generates 1024 bit asymetric RSA keys.
-
-- In my democratic country, long keys are forbidden by law.
-  Then disable the cipher layer.
-  There is probably a way to use 40 bits or 56 bits keys in
-  OpenSSL. If you find how, just tell me. <grin>
-  (I suppose that limiting the RSA key to 512 bits should do the
-  trick but I really don't care)
-
-- Should I buy a certificate at Verisign, Thawte, whoever?
-  No. And you should definitely *not* do it.
-  Considering the way Nessus on SSL works, the client would believe
-  any server certificate sold by those people (e.g. a standard HTTPS
-  certificate) and this is *insecure*.
-  If you really want to spend money, support the Nessus project!
-  If you really really want to give money to Verisign [etc.], create
-  your *own* CA and ask them to certify it. Your Nessus client should
-  only trust *your* CA, not the Verisign [etc.] root CA.
-
-- I have a PKI. May I use it?
-  Yes, of course. You should create a delegate CA for Nessus.
-
-- My private keys are stored on smartcards. Does Nessus support this?
-  Nessus will support whatever gizmo OpenSSL supports. The day OpenSSL
-  supports marble engraved X509 certificates, we'll do.
-
-- Can I connect without a password?
-  No, you need either a PEM password or a Nessus password. But that
-  should not be a problem. 
-  If you cannot remember your password, uses the client certificate
-  based authentication and do not protect your PEM key file. That way,
-  you may enter any password :-)
-
-- It would be great if I could register my client certificate the
-  first time I connect, just with PEKS.
-  Yes, but X.509 is not PEKS. X.509, SSL & PKIs are really pains in the
-  a..., but at least, they are supposed to be secure.
-  So, either you use the password authentication, which is enough for
-  most people IMHO, or you use the certificate authentication, but in
-  a way that is 100% secure and not just 99%
-
-- I cannot generate my own certificates with CA.pl
-  I said "don't ask".
-
-- I installed SSH, how do I run Nessus?
-  You need SSL, not SSH.
-
-- How does SSL works?
-  I do not know. My monkey sat in front of the computer, hit the
-  keyboard, and voila...
-  You may read RFC 2246 "The TLS Protocol Version 1.0" or OpenSSL
-  documentation.
-
-- I am a complete newbie in X.509
-  So was my monkey.
-  
-- More information? Have a look at:
-  http://www.openssl.org/docs/
-
-  RFC2246 The TLS Protocol Version 1.0. T. Dierks, C. Allen. January 1999.
-  RFC2817 Upgrading to TLS Within HTTP/1.1. R. Khare, S. Lawrence. May
-	  2000. (Updates RFC2616)
-  RFC2818 HTTP Over TLS. E. Rescorla. May 2000.
-
-  http://home.netscape.com/eng/ssl3/
-  http://www.netscape.com/eng/ssl3/ssl-toc.html
-  http://www.netscape.com/security/techbriefs/ssl.html
-  http://developer.netscape.com/docs/manuals/security/sslin/contents.htm
-  http://developer.netscape.com/tech/security/ssl/howitworks.html
-
-  http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt
-  http://www.phrack.org/show.php?p=57&a=13

Deleted: trunk/openvas-client/doc/WARNING.En
===================================================================
--- trunk/openvas-client/doc/WARNING.En	2007-10-21 19:21:37 UTC (rev 453)
+++ trunk/openvas-client/doc/WARNING.En	2007-10-21 19:26:54 UTC (rev 454)
@@ -1,518 +0,0 @@
--*- Indented-Text -*-
-
-------------------------------------------------------------------------
-                     NESSUS RISKS
-------------------------------------------------------------------------
-
-
-0. Copyright
-
-This document was written by Michel Arboi <mikhail at nessus.org>
-Anybody may reproduce it, send it, print it, engrave in marble,
-transfer on a T-shirt, etc., provided it is not modified -- and this
-means, of course, that this copyright should stay here.
-Devin Harris <devin.harris at abraxis.com> read and fixed my quick &
-dirty French to English translation. I added typos & broken English
-since. 
-
-
-1. Why this document?
-
-One can have a very bad experience by launching a Nessus test against a
-fragile machine or by giving anybody access to such a tool.
-Some do not really understand how Nessus works, or even the risks of
-any "security test".
-
-
-2. Legal matter
-
-I am not a lawyer, so I will not be long.
-Nessus is distributed according to the GPL.  This may be incompatible
-in part with your local law.
-Nessus is distributed WITHOUT ANY WARRANTY, as any software. Do not
-complain if you break a production machine; besides, you have no
-warranty with a commercial scanner.
-At least we warned you!
-
-
-3. How Nessus works
-
- 3.1. Timing of operations
-
-a) Nessus looks for open ports
-   - by calling the external scanner nmap,
-   - by calling snmpwalk [*]
-   - by connecting to the netstat service [*] or by running netstat on
-     the machine if we have an SSH access.
-   - by using an internal plugin, based upon one of nmap's modes,
-   - or by reading an external file, in nmap format, written by any
-     tool, e.g. by connecting the output of the netstat command.
-b) Then, the "find_service" plugin tries to identify what runs behind
-   each port
-   - first by trying SSL connections (TLSv1, SSLv3, SSLv2), then plain
-     connections,
-   - then by sending miscellaneous sequences to the service and
-     looking at the answers.
-   find_service stores its finding as "keys" in the "knowledge base" (KB).
-c) Nessus then tries miscellaneous attacks on every open port.
-   For example, if a scripts targets web servers, it will be launched
-   against every port where a HTTP or HTTPS server has been found.
-
-[*] The fact that a machine leaks information through netstat or SNMP
-is a weakness. However, those services can be configured to answer
-only to a restricted set of machines, including the Nessus scanner.
-
- 3.2. Plugin types
-
-Nessus plugins are organised into "families".  They can be grouped in
-the graphical interface, but this does not change the scanner
-work.  There is a "denial of service" family, but all dangerous scripts
-are not there; only those which goal is to kill the system. More over,
-some scripts in this family are not dangerous: they just check if a
-software is vulnerable without killing it.
-
-Each plugin has a "category":
-- ACT_INIT
-  The scripts only set options and does not run any test.
-- ACT_SCANNER
-  The script is a port scanner or something like it (e.g. ping).
-- ACT_SETTINGS
-  Just like ACT_INIT, but runs after the scanners, when we are sure
-  that the machine is alive.
-- ACT_GATHER_INFO
-  The script gathers information on the system, e.g. identifies
-  services or look for a specific software.
-- ACT_ATTACK
-  The script tries to circumvent some defences, without any bad effect
-  on the system availability, in theory.
-- ACT_MIXED_ATTACK
-  Although this is not its main goal, the script may have disastrous
-  side effects.
-- ACT_DESTRUCTIVE_ATTACK
-  The script tries to disturb a specific software or delete data.
-- ACT_DENIAL
-  The script tries to kill a service
-- ACT_KILL_HOST
-  The script tries to kill the operating system.
-- ACT_FLOOD
-  The script tries to kill the machine by flooding with packets. It
-  may badly disrupt the whole network.
-- ACT_END
-  The script just compile information after everything else run.
-
-The border between those categories is fuzzy, and it is impossible to
-say in advance if a script that targets a specific software will not
-have dangerous effects on another one.
-Nessus first launches the ACT_INIT scripts, then the ACT_SCANNER
-plugins, then ACT_SETTINGS, ACT_GATHER_INFO, etc. 
-
-Notes: 
-- ACT_INIT, ACT_END and ACT_KILL_HOST were introduced in 1.3.0
-  Before that (1.2.6), ACT_INIT scripts (if any) were handled in
-  ACT_SETTINGS and ACT_KILL_HOST was merged with ACT_DENIAL.
-- ACT_FLOOD appeared in 2.1.0
-- before version 1.2.6, ACT_SETTINGS was run first, but we lost 
-  time when we scanned an address range with few "up" machines. By 
-  putting ACT_SCANNER first, we filter with ping.nasl
-
-Last, each script may declare "dependencies"
-- scripts that should run before.
-  e.g., most scripts depend upon "find_service".
-- open ports / services
-  e.g., scripts that test HTTP weaknesses will depend upon port 80 and
-  the "Services/www" key.
-
-A basic principle is that Nessus does not consider any piece of
-information as reliable.  Some security scanners rely on the banners;
-Nessus really attacks the services but in rare cases that are
-mentioned in the report, or if the "safe checks" option is enabled
-(read below).
-So:
-- Nessus is able to verify if a flaw that is _supposed_ to be fixed in
-  version N+1 of some software is still present.
-- Nessus may discover that an attack against software "X" also works
-  against software "Y".
-- Nessus demolishes *BAD* (broken as designed) services without mercy.
-
-
- 3.3. Scripts selection
-
-With the GUI, one can
-- select everything in one click,
-- select "Everything but dangerous plugins".
-  This choice eliminates the categories ACT_FLOOD, ACT_DENIAL,
-  ACT_KILL_HOST or ACT_DESTRUCTIVE_ATTACK. This is redundant with the
-  "safe checks" option and will probably disappear one day.
-- select or remove each plugin individually.
-- select a whole family.
-  Keep in mind that all dangerous scripts are not in the "denial of
-  service" family and that some scripts in this family are not dangerous!
-
- 3.4. Important options
-
-Three options change the way dependencies are solved:
-- Enable dependencies at run time
-- Optimize the test
-- Consider unscanned ports as closed
-And a fourth one changes the behaviour of aggressive scripts:
-- Safe checks
-
-   3.4.1. Enable dependencies at run time
-
-By default, Nessus does not launch a script if those upon which it
-depends on were not enabled.  This option automatically enables the needed
-dependencies.
-
-   3.4.2. Optimize the test
-
-By default, Nessus launches a test even if it has no chance of
-success, because the service was not identified (the default port will
-be attacked).  This option speeds the test up, but you may miss a few
-weaknesses.
-
-   3.4.3. Consider unscanned ports as closed
-
-By default, Nessus considers that unscanned ports are "open". This
-option inverts the behaviour and speeds the test up.
-It is useful only with "optimize the test".
-
-   3.4.4. Safe checks
-
-This option disables the dangerous script that may kill the system or
-some service.  Nessus then relies upon the version numbers in banners,
-for example.  If no clue is available, the test is simply dropped.
-
-This option is more dangerous that it looks:
-- You can get a false feeling of security. Not seeing a weakness in
-  the report does not mean it is not there.
-- If the script was badly written and does not check the option with
-  the safe_checks() function, the attack will be launched.
-  Scripts delivered with Nessus are supposed to be safe, but a
-  "unofficial" or experimental script might be dangerous.
-
-Note that ACT_FLOOD, ACT_DENIAL, ACT_KILL_HOST and
-ACT_DESTRUCTIVE_ATTACK scripts are never run when this option is on. 
-
-
-4. How a security test may kill your system
-
- 4.1. Politics
-
-Before you start giving bad names to Nessus, please know that touching
-a sensitive production machine is suicidal.  Security consultants are
-rarely loved: they are seen either as hackers, or cybercops.
-If a machine runs mad for any reason at the very moment when you start
-testing it, someone will be too happy to declare you responsible for the
-damages.
-Perhaps you will be convinced that you did nothing wrong; but I would
-not bet that this would be enough to convince a judge that will evaluate
-the responsibilities and the amount of the prejudice. 
-Simplistic clauses in contracts do not hold, in France at least.  Do
-not forget that law is not an exact science (and in fact, no science
-at all :-)
-
- 4.2. Dangers of port scanning
-
-- For TCP, the scanner opens a connection and closes it immediately
-  without sending any data.
-  Some software will die or loop forever if they cannot read
-  data.  An old terrifying bug is CVE-2001-0998: a TCP port scan could
-  kill a "high availability" cluster.
-  Although many believe the contrary, the stealth scans ("null scan"
-  or "Christmas tree") are less dangerous because the packets 
-  stay in kernel land and do not reach the buggy application software
-  in userland.  Unfortunately, those scans do not work against every
-  operating systems. 
-- For UDP, it sends a dataless packet.
-  This may be enough to kill some defective IP stacks or broken
-  software.
-- In a few cases, stealth scans or OS fingerprinting may kill the IP
-  stack.  Some embedded software is still vulnerable to this kind of
-  denial of service.
-- snmpwalk can also be dangerous!
-
-You can get the list of open ports with the netstat command and
-convert it with netstat2nmap.pl into a fake nmap file that can be read
-by Nessus.  So you do not need to run a scanner. However, the main
-point in this is to speed the test up, rather than limit the risk.
-Starting from version 2.1.2, one can use the netstat_portscan plugin,
-if the netstat service is running (this is a bad idea, unless the
-access is restricted to the Nessus scanner IP) or if Nessus has an SSH
-access to the target.
-
- 4.3. Nessus demolition company
-
-Some generic scripts are really nasty:
-- Buffer overflows against miscellaneous fields or requests in HTTP,
-  FTP, POP3... protocols.
-- Bad requests (HTTP, FTP...)
-- Flood, sending tons of bytes to an unknown service.
-- Format strings attacks
-
-Also, some services do not like the side effects of the port scanner,
-and others the "interrogation" by find_service, especially the
-multiple SSL connections.
-
-The check_port plugin looks for potential denial of service from a
-port scanner or find_service. It runs the equivalent of "nmap -sT" on
-the open ports, with the same (low) risks.
-
-Even a simple ACT_GATHER_INFO plugin may kill a broken service. There
-is no such thing as zero risk!
-
-Note that there is one test that might actually try to delete data:
-http_method.nasl. However, the dangerous part is disabled if "safe
-checks" is set.
-
-
-5. Limiting the risks
-
-You do want to test your sensitive application.  If there is a problem,
-you will be responsible for it, alone.  So, you want to claim your
-condition of free man by shooting yourself in the foot. But you ask that it
-does not hurt too much...
-
-[In the rest of this chapter, the target machine is named "guinea-pig"]
-
- 5.1. Do not port scan
-
-In version 2.0.x:
-- Log onto guinea-pig, run "netstat -a -n --inet" or any other command
-  that gives you the list of open IP ports (--inet) in a numeric
-  output (-n).
-- Write the result into the "guinea-pig" file (this is important: the
-  filename must be the same as the scanned host name)
-- Convert it into a nmap file with:
-  netstat2nmap guinea-pig > gp.nmap  
-- _Only_ select the "nmap" scanner and feed it with gp.nmap. The
-  "scanned" port range should be 1-65535
-
-Or in version 2.1.2 or later (including 2.2.x):
- - give Nessus an SSH access to guinea-pig and only enable
-   netstat_portscan
-Note: currently, the new Nmap wrapper only reads "grepable" output
-(nmap -oG), not the "normal" (netstat -oN) format which is produced by
-netstat2nmap. 
-
- 5.2. Remove Nessus' teeth
-
-- Enable the "safe checks" option.
-- Enable "optimize the test".
-- Disable "enable dependencies at run time".
-- Remove the useless or dangerous plugins.
-- if no service runs on top of SSL, disable "test SSL services" (one of
-  the "Prefs" of find_service)
-
- 5.3. Remaining risks
-
-- find_service may cause more problems than the port scanner, even
-  without the SSL connection attempts.
-- some ACT_GATHER_INFO plugins may cause the same effects, but
-  "optimize the test" reduces the risks.
-
-
-9. Nessus in the wrong hands
-
-Nessus is a terrible test tool, able to point patches to "white hats"
-as well as "exploits" to "black hats".
-
- 9.1. A weapon for sale?
-
-I do not want to launch the troll^W debate again "for / against full
-disclosure".
-Like many tools, Nessus itself is not good or bad; it's in the way you use it.
-
-Nessus was made for "white hats".  Its design choices are not great
-for crackers: it is very noisy.  Crackers do not want to be seen, in
-general...
-
-You can torture Nessus so that it uses one of the many open proxies on
-Internet.  For reasons that you will easily understand, I hope, I will
-not document this trick :-]
-
-Some logs (small extract) :
-Dec 15 16:43:32 casserole login(pam_unix)[5888]: authentication failure; logname= uid=0 euid=0 tty=pts/17 ruser= rhost=localhost  user=root
-Dec 15 16:43:32 casserole login(pam_unix)[5886]: check pass; user unknown
-Dec 15 16:43:32 casserole login(pam_unix)[5886]: authentication failure; logname= uid=0 euid=0 tty=pts/16 ruser= rhost=localhost 
-Dec 15 16:43:34 casserole login[5880]: FAILED LOGIN 1 FROM localhost FOR backdoor, Authentication failure
-Dec 15 16:43:56 casserole fam[1354]: fd 109 message length 1312236900 bytes exceeds max of 4135.
-Dec 15 16:44:11 casserole SERVER[5930]: Dispatch_input: bad request line '< NTP/1.0 >^M'
-127.0.0.1 - - [15/Dec/2001:16:44:39 +0100] "GET http://www.nessus.org HTTP/1.0" 200 2890 "-" "-"
-127.0.0.1 - - [15/Dec/2001:17:25:44 +0100] ".`" 501 - "-" "-"
-127.0.0.1 - - [15/Dec/2001:17:25:45 +0100] "GET /cgi-bin/nessus_is_probing_this_host_2033195663 HTTP/1.1" 404 335 "-" "Mozilla/4.75 [en] (X11, U; Nessus)"
-127.0.0.1 - - [15/Dec/2001:17:29:58 +0100] "are you dead ?" 400 339 "-" "-"
-
- 9.2. Anti NIDS functions
-
-Version 1.1.13 introduced TCP and HTTP "evasion" functions that are
-based upon public works:
-http://www.wiretrip.net/rfp/pages/whitepapers/whiskerids.html
-http://www.securityfocus.com/data/library/ids.ps
-http://rr.sans.org/intrusion/anti-ids.php
-
-The goal of those functions is not to allow "black hats" to attack
-systems on Internet more easily, but to allow "white hats" to tests
-the protection devices.
-
-The Snort freeware tool is not deceived by any option, and in fact
-Nessus is even more noisy when they are enabled.
-
- 9.3. Access control to Nessus
-
-A cracker may take control of a Nessus server pointed to your
-machines, or the machines of one of your customers. Although we cannot
-guarantee there is no bug, a couple of precautions should reduce the
-risk to an reasonable level:
-
-- If the client and the server run on the same machine, configure
-  Nessus to use Unix sockets. Verify that port 1241 is closed.
-Or:
-- Configure Nessus with the TCP wrappers and limit the access to a few
-  workstations, e.g. localhost.
-- Enable the strong authentication (X.509 client
-  certificates). Generate your own certificates, do not use those from
-  the "Nessus kabale"! (they have been removed from the CVS repository
-  for a long time)
-  You should also protect your server & client private keys with a
-  solid password. The nessus-mkcert script does not do this. You will
-  have to set up your own "certificate factory".
-- Switch off the machine that runs the Nessus server when you are not
-  using it.
-
-Note: currently, certificate based authentication is incompatible with
-Unix sockets.
-
-9.4. "Only paranoids survive"
-
-
-It was asked some times on the mailing lists how privilege separation
-can be implemented with Nessus.
-The short answer is that this question is a troll.
-The long answer follows.
-
-First, we must remind that privilege separation limits the
-consequences of a flaw by giving the cracker a non privileged access
-instead of a root access.
-In the case of Nessus, the gain is limited: if a cracker can control
-the nessusd daemon under any user identity, he will be able to attack
-the whole scanned network, which might be more dangerous than just
-controlling one machine.
-
-Therefore, we should  focus on the protection of the nessusd
-access rather than block a privilege increase once an attacker has
-pierced the first defence line.
-
- 9.4.1. Risks
-
-In theory, three ways would allow to control Nessusd by getting around
-the authentication mechanism [we ignore here potential bugs in this
-mechanism] : 
-- an attack against the Nessus listener or the OpenSSL layer which is
-used for the client / server communication.
-- a "reverse attack" against the NASL interpretor, for example a
-buffer overflow on reading abnormal data.
-- a "reverse attack" against the libraries that are used by NASL, or
-the system libraries, especially OpenSSL which is the most complex,
-thus definitely the most fragile.
-
- 9.4.2. Generic counter-measures
-
-PaX and "stack protector" lower the probability of success of the
-attack (or increase its difficulty), RBAC or privilege separation
-lower the impact of a succeeded attack.
-
-* PaX
-
-http://pax.grsecurity.net/
-PaX is a Linux kernel patch; its role is to block the exploitations of
-buffer overflows, or at least to make them much more complex.
-PaX is not compatible with some programs that use strange memory
-access methods.
-
-* gcc -fstack-protector
-
-This GCC option protects the compiled program against buffer
-overflows.
-
-* MAC, RBAC...
-
-Systems like SELinux or GrSec divide the role of the super user into
-several "privileges" and enforce fine grain access control to the
-miscellaneous objects that the operating system handles.
-Thus, if an exploit succeeds, a program will not be able to run
-programs or read files that are not needed usually.
-Managing those systems is cumbersome if the configuration is often
-changed.
-
-* GrSecurity 
-
-This "catch-all" patch combines generic protections against known
-attacks (PaX and other things) with a RBAC system.
-
-* Privilege separation
-
-This technique is similar to the previous ones, but it is implemented
-without kernel patch, by relying upong the standard Unix mechanisms.
-It is less fine grained, thus less efficient, and often needs a big
-programming work. However it works on a unpatched system.
-The principle is to cut the program in two pieces; the piece in charge
-of the "dangerous" operations (like interpreting input data) drops the
-root privileges.
-
- 9.4.3. NASL sandbox
-
-Nobody can claim he never makes any mistakes, but we tried (1) to
-implement clean code in NASL: we control array indexes, we always use
-a format string, etc., (2) we avoid some libc functions that have been
-flawed on some systems or that we do not trust. 
-At worst, a malicious server could crash a NASL script by using too
-much memory for example -- Nessus is protected against this by setting
-a limit to resource consumption by child processes.
-
-We call only one complex library that we are calling is OpenSSL
-because there is no other  library and because as SSL is complex, an
-SSL library will always be complex. There is no satisfying solution,
-maybe you want to recompile OpenSSL with gcc -fstack-protector or
-implement PaX.
-
-NB : even the SSH protocol is coded directly in NASL, using some
-cryptographic C functions.
-
- 9.4.4. SSL listener separation
-
-One can easily separate the SSL listener from the core daemon with
-stunnel.
-With this configuration, stunnel decrypts SSL data in a chroot jail,
-then connects in clear text to the nessusd daemon:
-- run "nessusd -a 127.0.0.1:1241" with "ssl_version=none" in "nessusd.conf"
-  The client software must use SSL however
-  (ssl_version=tlsV1 in .nessusrc)
-- run stunnel with a configuration file like that:
-  comme :
-chroot  = /chroot/stunnel	# For example
-client  = no
-accept  = 11.12.13.14:1241	# Put your external IP here
-connect = 127.0.0.1:1241
-#
-setgid = nessusnobody		# For example
-setuid = nessusnobody
-#
-verify = 2		# Asks for a client certificate
-CAfile = ...
-cert = ...
-key = ...
-CRLpath = ...
-CRLfile = ...
-
- 9.5. On the Nesuss client side
-
-The Nessus client also handles sensitive data: 
-- it receives reports which contain vulnerabilities on the target
-machines. Starting with version 2.3, the Unix GTK client stores those
-reports.
-- the ".nessusrc" file contains passwords to some services. Those
-passwords are hidden in the GUI but saved in clear text on the disk.
-
-It is important to protect the access to the client machine. It is
-also a good idea to save reports and nessusrc files on an encrypted
-disk.

Deleted: trunk/openvas-client/doc/WARNING.Fr
===================================================================
--- trunk/openvas-client/doc/WARNING.Fr	2007-10-21 19:21:37 UTC (rev 453)
+++ trunk/openvas-client/doc/WARNING.Fr	2007-10-21 19:26:54 UTC (rev 454)
@@ -1,549 +0,0 @@
--*- Indented-Text -*-
-
-------------------------------------------------------------------------
-                     LES RISQUES LIÉS À NESSUS
-------------------------------------------------------------------------
-
-Dernière modification: $Date: 2005-09-10 17:36:38 $
-
-0. Copyright
-
-Ce document a été rédigé par Michel Arboi <mikhail at nessus.org>
-Je permets à quiconque de le reproduire, transmettre, imprimer,
-calligraphier à la plume d'oie sur parchemin, graver dans le marbre,
-transférer sur un tee shirt, etc. pourvu qu'il ne soit pas modifié --
-et a fortiori, que ce copyright soit toujours présent.
-
-
-1. Pourquoi ce document ?
-
-On peut avoir de désagréables expériences en lançant un test Nessus 
-contre une machine fragile ou en laissant un tel outil à la portée de
-n'importe qui. 
-Certains n'ont pas vraiment compris le mode de fonctionnement de
-Nessus, ni même les risques liés à n'importe quel test dit "de
-sécurité". 
-
-
-2. Considérations légales
-
-N'étant pas juriste, je ne m'étendrai pas sur ce sujet.
-Nessus est distribué selon la GPL. Mélanie Clément-Fontaine a étudié
-cette licence http://crao.net/gpl/ mais à ma connaissance, il n'existe
-aucune jurisprudence.
-Nessus est distribué SANS AUCUNE GARANTIE, tout comme n'importe quel
-logiciel d'ailleurs. Ne venez pas vous plaindre si vous cassez une
-machine en production ; de toute façon, vous n'êtes pas plus couverts
-avec un scanner commercial.
-Mais au moins, nous vous aurons prévenus des dangers potentiels.
-
-
-3. Comment fonctionne Nessus
-
- 3.1. Séquence des opérations
-
-a) Nessus détermine les ports ouverts 
-   - en appelant le scanner externe nmap,
-   - en appelant snmpwalk [*],
-   - en se connectant au service netstat [*] ou en exécutant netstat
-     sur la machine s'il dispose d'un accès SSH, 
-   - en utilisant un plugin interne, calqué sur un des modes de
-     fonctionnement de nmap,
-   - ou en utilisant un fichier externe, vu comme un résultat de nmap,
-     obtenu par un moyen quelconque, par exemple en convertissant la
-     sortie de la commande netstat.
-b) Ensuite le plugin "find_service" tente d'identifier ce qui tourne
-   derrière chaque port  
-   - tout d'abord en tentant des connexions SSL (TLSv1, SSLv3, SSLv2),
-     puis standard, 
-   - ensuite en envoyant diverses séquences au service et en regardant
-     les réponses
-   find_service stocke ses découvertes sous forme de "clés" dans la
-   "base de connaissance" (KB).
-c) Sur chacun des ports ouverts, Nessus tente alors diverses
-   attaques.
-   Par exemple, si un script vise les serveurs web, il sera lancé
-   contre tous les ports où tourne un serveur HTTP _ou_ HTTPS.
-
-[*] Le fait qu'une machine divulgue des informations par netstat ou
-SNMP est une faiblesse. Toutefois, on peut configurer ces services
-pour ne répondre qu'à un petit nombre de machines de supervisions,
-dont le scanner Nessus.
-
- 3.2. Types et fonctionnements de plugins
-
-Les plugins de Nessus sont classés par famille. Ceci permet de les 
-regrouper dans l'interface graphique, mais n'a aucune influence sur le
-fonctionnement du scanner. Il existe une famille "déni de service",
-mais elle ne regroupe pas tous les scripts dangereux, seulement ceux
-dont le but premier est de tuer le système. De plus, certains scripts
-de cette famille ne sont pas dangereux : ils vérifient la présence
-d'un logiciel vulnérable à un déni de service sans le tuer.
-
-Chaque plugin a une "catégorie" :
-- ACT_INIT
-  Le script sert simplement à configurer des options et ne fait aucun
-  test.
-- ACT_SCANNER
-  Le script est un scanner de ports ou apparenté (e.g. ping).
-- ACT_SETTINGS
-  Même fonction qu'ACT_INIT, mais passe après les scanners, quand on
-  est sur que la machine répond.
-- ACT_GATHER_INFO
-  Le script récupère des informations sur le système, par exemple
-  identifie des services ou vérifie la présence d'un logiciel 
-  particulier.
-- ACT_ATTACK
-  Le script tente de percer certaines défenses, en théorie sans effet
-  pervers contre la disponibilité du système.
-- ACT_MIXED_ATTACK
-  Le script est susceptible d'avoir des effets secondaires désastreux,
-  bien que ce ne soit pas son but.
-- ACT_DESTRUCTIVE_ATTACK
-  Le script tente de perturber un service ou détruire des données.
-- ACT_DENIAL
-  Le script tente un déni de service contre un logiciel particulier.
-- ACT_KILL_HOST
-  Le script tente un déni de service contre la machine / le système
-  d'exploitation. 
-- ACT_FLOOD
-  Le script tente un déni de service par envoi massif de paquets et
-  peut perturber l'ensemble du réseau. 
-- ACT_END
-  le script se contente de compiler des information une fois que tout
-  le reste est passé.
-
-La frontière entre toutes ces catégorie est floue, et il est
-impossible de prédire a priori si un script qui vise un logiciel donné
-n'aura pas des effets dangereux contre un autre. 
-Nessus exécute en premier les scripts ACT_INIT, puis les plugins
-ACT_SCANNER, puis ACT_SETTINGS, ACT_GATHER_INFO, etc.
-
-Notes:
-- ACT_INIT, ACT_END et ACT_KILL_HOST ont été introduits en version 1.3.0
-  Avant (1.2.6), les éventuels scripts ACT_INIT étaient déclarés comme
-  ACT_SETTINGS et ACT_KILL_HOST était fusionné avec ACT_DENIAL
-- ACT_FLOOD est apparu en 2.1.0
-- avant la version 1.2.6, ACT_SETTINGS passait en tête, mais ceci
-  faisait perdre du temps lorsqu'on scannait une plage d'adresses où
-  peu de machines était vivantes. En mettant ACT_SCANNER en premier,
-  on filtre avec ping.nasl
-
-Enfin, chaque script déclare des "dépendances"
-- en terme de scripts qui ont dû tourner avant.
-  Par exemple, la plupart des scripts dépendent de "find_service".
-- en terme de ports /services ouverts
-  Par exemple, les scripts qui testent des vulnérabilités HTTP
-  déclareront dépendre du port 80 et de la clé "Services/www".
-
-Par principe, Nessus ne considère rien comme acquis. Contrairement à
-certains scanners de sécurité qui basent leurs vérifications sur les
-bannières présentées, Nessus attaque réellement les services, sauf
-dans quelques rares cas mentionnés dans le rapport, ou bien si
-l'option "safe checks" est active (voir ci-dessous).
-En conséquence :
-- Nessus est capable de détecter si une faille _censée_ être corrigée
-  dans la version N+1 d'un logiciel est toujours là.
-- Nessus peut découvrir qu'une faille dirigée contre le produit X
-  fonctionne aussi contre le produit Y.
-- Nessus a la mauvaise habitude de démolir les services codés "avec
-  les pieds" sans aucune pitié.
-
- 3.3. Sélection des scripts
-
-L'interface graphique permet de 
-- tout sélectionner en un clic,
-- sélectionner "tout sauf les plugins dangereux".
-  Ce choix élimine les plugins de catégorie ACT_FLOOD, ACT_DENIAL,
-  ACT_KILL_HOST ou ACT_DESTRUCTIVE_ATTACK. Il fait double emploi avec
-  l'option "safe checks" et devrait disparaître à terme. 
-- sélectionner ou non chaque plugin individuellement.
-- sélectionner une famille entière.
-  Gardez à l'esprit que les scripts dangereux ne sont pas tous dans la
-  famille "déni de service" et que certains des scripts de cette
-  famille ne sont pas dangereux !
-
- 3.4. Options importantes
-
-Trois options dans l'interface influencent la résolution des dépendances :
-- Enable dependencies at run time
-- Optimize the test
-- Consider unscanned ports as closed
-Et une quatrième modifie le comportement des scripts agressifs :
-- Safe checks
-
-   3.4.1. Enable dependencies at run time
-
-Par défaut, Nessus ne lance pas un script si ceux dont il dépend n'ont
-pas été activés. Cette option résout automatiquement les dépendances
-nécessaires. 
-
-   3.4.2. Optimize the test
-
-Par défaut, Nessus lance même les tests qui n'ont aucune chance de
-réussir, parce que le service n'a pas été identifié (il attaquera le
-port par défaut). Cette option accélère le test, au risque de rater
-quelques vulnérabilités.
-
-   3.4.3. Consider unscanned ports as closed
-
-Par défaut, Nessus considère les ports non scannés comme
-"ouverts". Cette option inverse le comportement et accélère le test. 
-Elle n'a d'effet que combinée avec "optimize the test".
-
-   3.4.4. Safe checks
-
-Cette option désactive les tests dangereux susceptibles de tuer le
-système ou un service. Nessus s'appuie si possible sur les numéros de
-version renvoyés par les bannières, par exemple.
-Si aucun indice n'est disponible, le test est tout simplement abandonné.
-
-Cette option est moins inoffensive qu'elle paraît :
-- Elle peut donner un faux sentiment de sécurité. Qu'une faille ne
-  soit pas mentionnée dans le rapport ne signifie pas qu'elle soit
-  absente du système. 
-- Si le script est mal écrit et ne vérifie pas la valeur de l'option
-  avec la fonction safe_checks(), l'attaque sera quand même lancé.
-  A priori, les scripts livrés avec Nessus sont sûrs, mais un script
-  "non officiel" ou expérimental pourrait être dangereux.
-
-NB : les scripts ACT_FLOOD, ACT_DENIAL, ACT_KILL_HOST et
-ACT_DESTRUCTIVE_ATTACK ne sont jamais lancés quand cette option est
-activée. 
-
-
-4. Comment un test de sécurité peut tuer votre système
-
- 4.1. Politique
-
-Avant d'accabler Nessus de sordides qualificatifs, sachez que toucher
-une machine sensible en production est suicidaire. Les consultants
-sécurité sont rarement appréciés : ils sont vus soit comme des
-pirates, soit comme des cyberflics. Si la machine part en vrille au
-moment où vous commencez votre test pour une raison externe, on sera
-trop heureux de vous rendre responsable des dommages causés.
-Que vous soyez convaincu de n'avoir rien fait de mal est une chose,
-que vous sachiez convaincre le juge qui doit évaluer les
-responsabilités et le montant du préjudice subi en est une autre.
-Les arguments contractuels simplistes ne tiennent pas devant un
-tribunal, en France du moins. N'oubliez pas que le droit n'est pas une
-science exacte (en fait, ce n'est pas une science du tout :-)
-
- 4.2. Les dangers du scan de ports
-
-- En TCP, le scanner ouvre une connexion puis la referme immédiatement
-  sans envoyer de données. 
-  Certains logiciels meurent ou partent en boucle s'ils n'arrivent pas
-  à lire de données. Un vieux bug effrayant est CVE-2001-0998 : n scan
-  TCP pouvait tuer un cluster "à haute disponibilité".
-  Contrairement à ce que certains pourraient penser, les scans furtifs
-  "nul scan" ou "Christmas tree" présentent moins de risques car ils
-  ne remontent pas jusqu'aux logiciels applicatifs potentiellement
-  bugués. Ils ne marchent pas contre tous les systèmes d'exploitation, hélas.
-- En UDP, il envoie un paquet sans données.
-  Ceci est suffisant pour tuer certaines piles IP défectueuses ou un
-  logiciel mal codé.
-- dans quelques cas rares maintenant, les scans furtifs ou
-  l'identification du système par "fingerprinting" peuvent tuer la
-  pile IP. On rencontre encore des logiciels embarqués vulnérables à
-  ce genre de déni de service.
-- snmpwalk peut lui aussi être dangereux !
-
-On peut récupérer la liste des ports ouverts par la commande netstat
-puis la convertir avec la commande netstat2nmap.pl en un pseudo
-fichier nmap, lisible par Nessus. Ainsi, on n'a pas à lancer le
-scanner. Toutefois, l'intérêt de cette opération est plutôt
-d'accélérer le test que d'en limiter les risques.
-On peut aussi, à partir de la version 2.1.2, utiliser le plugin
-netstat_portscan à condition d'ouvrir le service netstat (ce qui est
-une mauvaise idée, à moins de restreindre l'accès au seul scanner
-Nessus), ou de donner un accès SSH à Nessus sur la cible. 
-
-
- 4.3. Entreprise de démolition Nessus & Cie
-
-Certains scripts génériques sont particulièrement méchants :
-- Débordements mémoire contre divers champs / requêtes des protocoles
-  HTTP, FTP, POP3...
-- Requêtes mal formées (HTTP, FTP...)
-- Tests par saturation, inondant un service inconnu de myriades
-  d'octets.
-
-Par ailleurs, outre les effets secondaires du scanner de port,
-certains logiciels n'apprécient pas l'interrogatoire que leur fait subir
-find_service, à commencer par les multiples tentatives de connexion
-SSL. 
-
-check_ports, un plugin qui teste d'éventuels dénis de service
-provoqués par un scanner de ports ou find_service, fait l'équivalent
-d'un "nmap -sT" sur les ports supposés ouverts. Avec les risques
-(faibles) que cela comporte...
-
-Même un simple plugin de type ACT_GATHER_INFO peut tuer un service mal
-conçu. Le risque zéro n'existe pas !
-
-Notez qu'il existe un test qui pourrait réellement tenter d'effacer
-des données : http_methods.nasl. Toutefois, la partie de code
-dangereuse est désactivée en mode "safe checks".
-
-
-5. Limitation des risques
-
-Vous tenez à tester votre application sensible et en cas de problème,
-vous ne vous en prendrez qu'à vous même. En clair, vous voulez
-affirmer haut et fort votre condition d'homme libre en vous tirant
-dans le pied. Vous aimeriez bien que ça ne fasse pas trop mal...
-
-[Dans la suite, la machine cible s'appelle guinea-pig]
-
- 5.1. Supprimez le port scan
-
-En 2.0.x :
-- Connectez-vous sur guinea-pig, lancez "netstat -a -n --inet" ou tout
-  autre commande nécessaire sur votre système pour récupérer les ports
-  IP ouverts (--inet) sous forme numérique (-n).
-- Écrivez le résultat dans un fichier nommé "guinea-pig" (il est 
-  important que ce fichier porte le nom de la machine "scannée")
-- Convertissez-le en fichier nmap par :
-  netstat2nmap guinea-pig > gp.nmap  
-- ne sélectionnez _que_ le scanner "nmap" et jetez lui gp.nmap en
-  pâture. La plage de ports "scannée" devrait être 1-65535
-
-Ou alors, à partir de la version 2.1.2 :
-- donnez un accès SSH à Nessus sur guinea-pig et n'activez que le
-  scanner netstat_portscan
-Note: pour le moment, la nouvelle version du wrapper Nmap lit les
-fichiers en format "grepable" (nmap -oG) et non "normal" (nmap -oN)
-qui sont produits par netstat2nmap. 
-
- 5.2. Limez les dents de Nessus
-
-- Activez l'option "safe checks"
-- Activez "optimize the test".
-- Désactivez "enable dependencies at run time".
-- Supprimez les plugins que vous pensez inutiles ou dangereux.
-- Si aucun service ne s'appuie sur SSL, désactivez "test SSL services"
-  (une des "préférences" du plugin find_service)
-- désactivez check_ports.nasl
-
- 5.3. Risques résiduels
-
-- find_service est susceptible de faire plus de dégats que le scanner
-  de ports, même sans les essais de connexions SSL.
-- des plugins ACT_GATHER_INFO peuvent avoir le même effet, mais
-  "optimize the test" réduit les risques.
-
-
-9. Nessus entre de mauvaises mains
-
-Nessus est un redoutable outil de test, capable aussi bien d'indiquer 
-aux "chapeaux blancs" les correctifs qu'ils doivent appliquer pour
-durcir leur système ou aux "chapeaux noirs" les "exploits" qu'ils
-doivent utiliser pour percer les défenses de la machine.
-
- 9.1. Une arme en vente libre ?
-
-Je n'ai pas envie de relancer le troll^W débat "pour ou contre le full
-disclosure".
-Comme beaucoup d'outils, ce n'est pas Nessus lui même mais son
-utilisation qui peut être bonne ou mauvaise.
-
-Nessus est destiné aux "chapeaux blancs". Ses principes de conception
-ne facilitent pas la vie des pirates : il est terriblement bruyant.
-Les pirates cherchant généralement à être discrets, c'est raté.
-
-Il est possible de torturer Nessus pour le faire passer par l'un des
-nombreux proxys ouverts qui traînent sur Internet. Pour des raisons
-que vous comprendrez, j'espère, je n'ai pas envie de documenter la
-procédure :-]
-
-Quelques traces (petit extrait) :
-Dec 15 16:43:32 casserole login(pam_unix)[5888]: authentication failure; logname= uid=0 euid=0 tty=pts/17 ruser= rhost=localhost  user=root
-Dec 15 16:43:32 casserole login(pam_unix)[5886]: check pass; user unknown
-Dec 15 16:43:32 casserole login(pam_unix)[5886]: authentication failure; logname= uid=0 euid=0 tty=pts/16 ruser= rhost=localhost 
-Dec 15 16:43:34 casserole login[5880]: FAILED LOGIN 1 FROM localhost FOR backdoor, Authentication failure
-Dec 15 16:43:56 casserole fam[1354]: fd 109 message length 1312236900 bytes exceeds max of 4135.
-Dec 15 16:44:11 casserole SERVER[5930]: Dispatch_input: bad request line '< NTP/1.0 >^M'
-127.0.0.1 - - [15/Dec/2001:16:44:39 +0100] "GET http://www.nessus.org HTTP/1.0" 200 2890 "-" "-"
-127.0.0.1 - - [15/Dec/2001:17:25:44 +0100] ".`" 501 - "-" "-"
-127.0.0.1 - - [15/Dec/2001:17:25:45 +0100] "GET /cgi-bin/nessus_is_probing_this_host_2033195663 HTTP/1.1" 404 335 "-" "Mozilla/4.75 [en] (X11, U; Nessus)"
-127.0.0.1 - - [15/Dec/2001:17:29:58 +0100] "are you dead ?" 400 339 "-" "-"
-
- 9.2. Fonctions anti NIDS
-
-La version 1.1.13 a introduit des fonctions "d'évasion", au niveau TCP
-et HTTP, qui s'appuient sur divers travaux disponibles publiquement.
-http://www.wiretrip.net/rfp/pages/whitepapers/whiskerids.html
-http://www.securityfocus.com/data/library/ids.ps
-http://rr.sans.org/intrusion/anti-ids.php
-
-Le but de ces fonctions n'est pas de permettre aux "black hats"
-d'attaquer plus facilement les systèmes ouverts sur Internet, mais aux
-"white hats" de tester les mesures de protection mises en place.
-
-L'outil freeware Snort n'est trompé par aucune de ces options, et en
-fait Nessus est perçu comme plus bruyant quand elles sont actives.
-
- 9.3. Contrôle d'accès à Nessus
-
-Nettement plus grave, un pirate pourrait prendre le contrôle d'un
-serveur Nessus dirigé contre vos machines ou celles de vos
-clients. Nul n'est à l'abri d'un bug, mais certaines précautions
-devraient ramener le risque à un niveau acceptable :
-
-- Si le client et le serveur tournent sur la même machine, configurez
-  Nessus pour utiliser les sockets Unix. Vérifiez que le port 1241 est
-  fermé. 
-Ou bien :
-- Configurez Nessus avec les TCP wrappers et limitez l'accès aux rares
-  postes qui en ont besoin, par exemple localhost.
-- Activez l'authentification par certificats client X.509. Générez vos
-  propres certificats, n'utilisez surtout pas ceux de la "kabale
-  Nessus" ! (qui ont été supprimés du CVS depuis longtemps)
-  Le mieux est de protéger vos clés privées (serveur et client) par un
-  mot de passe solide, ce que le script nessus-mkcert ne fait
-  pas. Vous devrez mettre en place votre propre "usine à certificats".
-- Éteignez la machine qui héberge le serveur Nessus quand elle n'est
-  pas utilisée.
-
-Note: actuellement, l'authentification par certificats est
-incompatible avec les sockets Unix. 
-
- 9.4. "Seuls les paranïaques survivent"
-
-Il a été demandé quelques fois sur la liste de diffusions comment
-mettre en oeuvre une séparation de privilèges dans Nessus.
-La réponse courte est que ceci est un troll.
-La suite du paragraphe présente la réponse longue.
-
-Avant tout, il faut se rappeler que la séparation de privilèges limite
-l'impact d'une faille en donnant un accès non privilégié à l'attaquant
-plutôt qu'un accès root.
-Dans le cas de Nessus, l'intérêt est limité : si un pirate arrive à
-prendre le contrôle du daemon nessusd sous quelque identité que ce
-soit, il pourra attaquer l'ensemble du réseau surveillé, ce qui est 
-finalement plus grave que la prise de contrôle d'une seule machine.
-
-Il est donc plus important de se focaliser sur la protection de
-l'accès à Nessusd que d'empêcher une montée de privilèges chez un
-attaquant qui aurait franchi la première ligne de défense.
-
- 9.4.1. Les risques
-
-Trois voies permettraient théoriquement de prendre le contrôle de
-Nessusd en contournant le mécanisme d'authentification [on laisse ici
-de côté les bugs de ce mécanisme] :
-- une attaque contre le "listener" Nessus ou la couche OpenSSL mise en
-place pour la communication client / serveur. 
-- une attaque "à rebours" contre l'interpréteur NASL, provoquant par
-exemple un buffer overflow sur des données anormales.
-- une attaque "à rebours" contre les bibliothèques Nessus utilisées
-par NASL, ou les bibliothèques du système, en particulier OpenSSL qui
-est la plus complexe, donc certainement la plus fragile.
-
- 9.4.2. Les contre-mesures génériques
-
-PaX et stack protector réduisent le risque d'exploitation réussie, les
-RBAC ou la séparation de privilèges limitent l'impact d'une attaque
-réussie. 
-
-* PaX
-
-http://pax.grsecurity.net/
-PaX est un patch noyau dont le but est de bloquer l'exploitation de
-buffer overflows, ou du moins de la compliquer le plus possible.
-PaX est incompatible avec certains programmes qui accèdent bizarrement
-à la mémoire.
-
-* gcc -fstack-protector
-
-Cette option de GCC protège le programme compilé contre les buffer
-overflows.
-
-* MAC, RBAC...
-
-Des systèmes comme SELinux ou GrSec divisent le rôle du
-super-utilisateur en plusieurs "privilèges", et contrôlent finement
-l'accès aux différents objets manipulés par le système.
-Ainsi, en cas d'exploitation réussi, un programme ne pourra pas
-exécuter des programmes ou lire des fichiers dont il n'a pas besoin
-habituellement.
-Ces systèmes sont lourds à gérer si on modifie souvent la
-configuration.
-
-* GrSecurity 
-
-Ce patch fourre-tout combine des protections génériques pour bloquer
-des attaques connues (PaX et autres) et un système de RBAC.
-
-* Séparation de privilèges
-
-Cette technique est similaire au point précédent, mais elle est
-réalisée sans patch noyau, en s'appuyant sur les mécanismes standard
-Unix. Elle est moins fine donc moins efficace, et nécessite
-souvent un travail de programmation non négligeable ; mais elle
-fonctionne sur un système non patché. 
-Le principe consiste à couper un programme en deux morceaux, et à
-laisser faire les opérations "dangereuses" (comme interpréter des
-données venant de l'extérieur) par la partie qui a abandonné les
-droits root.
-
- 9.4.3. La sandbox NASL
-
-Nul n'est à l'abri d'une erreur, mais nous avons essayé (1) de coder
-NASL proprement en contrôlant les indices de tableaux, en donnant
-toujours une chaîne de format, etc., (2) en évitant d'appeler des
-fonctions de la libc qui ont été vulnérables sur certains systèmes ou
-n'inspirent pas confiance.
-Au pire, un serveur malveillant pourrait crasher un script NASL, par
-exemple en lui faisant consommer trop de mémoire -- Nessus se protège
-contre cela en fixant une limite à la consommation de ressources par
-les interpréteurs forkés.
-
-La seule bibliothèque complexe que nous appelons est OpenSSL,
-parce qu'il n'existe pas d'autre alternative, et parce que le
-protocole SSL étant ce qu'il est, une bibliothèque SSL sera toujours
-complexe. Il n'y a guère de solution satisfaisante, si ce n'est
-recompiler OpenSSL avec gcc -fstack-protector ou mettre PaX en place.
-
-Nota : même le protocole SSH est codé directement en NASL à partir de 
-primitives cryptographiques.
-
- 9.4.4. Séparation du listener SSL
-
-Il est possible de séparer le listener SSL à moindre coût avec l'outil
-stunnel.
-Avec la configuration qui suit, c'est stunnel qui déchiffre le SSL
-dans un chroot, puis la connexion vers le daemon nessusd est en clair :
-- lancez "nessusd -a 127.0.0.1:1241" avec ssl_version=none dans nessusd.conf
-  En revanche, les clients devront communiquer en SSL
-  (ssl_version=tlsV1 dans .nessusrc)
-- lancez stunnel avec dans le fichier de configuration quelque chose
-  comme :
-chroot  = /chroot/stunnel	# par exemple
-client  = no
-accept  = 11.12.13.14:1241	# Remplacez par votre IP externe
-connect = 127.0.0.1:1241
-#
-setgid = nessusnobody		# par exemple
-setuid = nessusnobody
-#
-verify = 2		# Demande un certificat client
-CAfile = ...
-cert = ...
-key = ...
-CRLpath = ...
-CRLfile = ...
-
- 9.5. Du côté du client Nessus
-
-Le client Nessus manipule aussi des données sensibles :
-- il reçoit les rapports, qui contiennent les vulnérabilités des
-machines visées. À partir de la version 2.3, le client stocke ces
-rapports.
-- le fichier ".nessusrc" contient des mots de passe d'accès à divers
-services. Ces mots de passe sont masqués dans l'interface graphique
-mais stockés en clair sur le disque. 
-Il est important de protéger l'accès à la machine qui héberge la
-partie cliente. Stocker les rapports et les fichiers nessusrc sur un
-disque chiffré peut être une bonne idée.



More information about the Openvas-commits mailing list