********************
NSCA SECURITY README
********************


General Security Considerations
-------------------------------
Before you proceed with installing the NSCA daemon daemon on your
monitoring server, there are some security implications that you
should be aware of.  

The main thing you need to be aware of is the fact that malicious
users could potentionally use the NSCA client to send fake service
check results to the NSCA daemon (and thus Netsaint).  This is bad
for two reasons:

1) NetSaint gets fake service check results and could start 
   generating notifications (which would annoy you) or a service
   problems (like a security alert) could be cleared by the remote
   user.

2) Worse, since NetSaint can be configured to run event handlers
   for hosts and services, a remote user could indirectly cause
   NetSaint to shut down or restart a service (or do something 
   more serious).

Running the NSCA daemon under inetd and making use of TCP wrappers
allows you to perform some host-based authentication of clients.
That isn't really good enough, as any user on a blessed client
machine could use the client to send fake service check results
to the daemon (and thus to NetSaint).

So what's the solution?  Encryption.



Encrypting Communications
-------------------------
In order to avoid some of the security hassles associated with
allowing remote clients to provide NetSaint with service check
results, we can encrypt the data being sent from the client to the
NSCA daemon.

While encryption is good because it provides some privacy
as to the information that is being sent from the client to
the daemon, the main purpose of the encryption is to provide
the daemon with a way of authenticating the client and 
seeing if they're authorized to provide service check results.

Basically the daemon says:

   "Hey, if you (the client) used the same password and
    algorithm to encrypt the data as I use to decrypt it,
    I'll accept the check results you're providing me..." 



How The Authentication Works
----------------------------
Authentication of service checks results works as follows:

1) The user starts the NSCA client and passes the service
   check results to it.  A password that is used to encrypt
   the data being sent to the NSCA daemon is stored in the 
   send_nsca config file on the client machine.

2) The NSCA client stuff the service check results into a
   packet.

3) The NSCA client computes the CRC-32 value of the packet
   its about to send off and stores that value in the packet
   body.

4) The entire packet body (including the service checking 
   information, as well as the CRC-32 value) is encrypted
   using the password stored in the send_nsca.cfg file.  
   Encryption of the packet is done using the algorithm
   specified by the encryption_method variable in the
   send_nsca.cfg file.

... packet gets sent over the wire...

5) The NSCA daemon recieves the packet and decrypts it using
   the password stored in the nsca.cfg file.  Decryption of
   the packet is done using the algorithm specified by the
   decryption_method variable in the nsca.cfg file.

6) The daemon calculates the CRC-32 value of the decrypted
   packet to see if it matches the CRC-32 value stored in
   the packet body (this value was previously computed and
   stored by the client).

7) If the calculated CRC-32 value matches the value that is
   stored in the packet body, the service check results that
   are stored in the packet are assumed to be from an
   authorized user.  If the calculated CRC-32 value does NOT
   match the value in the packet body, the results are assumed
   to be from an unauthorized user and the packet (and 
   service check results contained therein) are discarded.



What This Means
---------------

1) If the client uses the wrong password to encrypt the
   packet, the daemon will discard it, as the CRC-32 value
   stored in the packet will not match the computed value
   once the packet it decrypted.

2) If the client uses the wrong encryption method, the
   daemon will discard the results, as the CRC-32 value
   stored in the packet will not match the computed value
   once the packet is decrypted.

3) If someone tries to dabble with the contents of the
   packet as it is being tranferred between the client and
   the server, the daemon will likely discard the packet, as
   the CRC-32 value of the packet will likely be invalid.

4) Even if someone manages to figure out a way to make
   the calculated CRC-32 value match the value stored
   in the packet, the check results stored in the packet
   that are passed along to NetSaint have to match a valid
   service definition.  NetSaint ignores all passive check
   results that come in that are not associated with any
   valid service definitions.



Preventing "Replay" Attacks
---------------------------

The methods described above help ensure that the data the
NSCA daemon receives is "valid" data - i.e., it was
encrypted with the appropriate passphrase and crypto 
algorithm.  One problem that remains is the fact that
someone could capture the data packets being sent from the
client to the daemon and send them back to the daemon at
a later time.  This is referred to as a "replay attack".
To help prevent this, the NSCA daemon generates what is
essentially a one-time, randomly generated IV that the
client must use to encrypt data for each particular
"session".  The IV does not need to be secret, just unique.
The IV is used in conjunction with the password during
encryption and decryption.  Encrypting a packet with the
same password but different IVs results in a different
result.  Since the daemon knows what IV it generated and
sent to the client, it can verify that the data the client
sends to it has been properly encrypted.  This provides
a reasonable mechanism of preventing replay attacks.



Caveats
-------

1) These assumptions rely on the fact that you are using a
   reasonably secure encryption/decryption method in the
   NSCA clients and NSCA daemon.

2) These assumptions rely on the fact that you're using a
   resonable secure password to encrypt/decrypt the data.
   Depending on the crypto algorithm used, this could mean
   length and/or randomness.  As a general rule, longer
   passwords or passphrases are better than shorter ones.
   Insert common sense here.

3) It is assumed that you keep tight security on the 
   send_nsca.cfg and nsca.cfg config files, as they contain
   both the algorithm and password used to encrypt/decrypt
   the packets sent between the client and daemon.



Questions?  Comments?  Suggestions?

	-- Ethan Galstad (netsaint@netsaint.org)