1******************** 2NSCA SECURITY README 3******************** 4 5 6General Security Considerations 7------------------------------- 8Before you proceed with installing the NSCA daemon daemon on your 9monitoring server, there are some security implications that you 10should be aware of. 11 12The main thing you need to be aware of is the fact that malicious 13users could potentionally use the NSCA client to send fake service 14and host check results to the NSCA daemon (and thus Nagios). This 15is bad for two reasons: 16 171) Nagios could get fake check results and start generating 18 notifications (which would annoy you) or host/service 19 problems (like security alerts) could be cleared by the remote 20 user. 21 222) Worse, since Nagios can be configured to run event handlers 23 for hosts and services, a remote user could indirectly cause 24 Nagios to shut down or restart a service (or do something 25 more serious). 26 27Running the NSCA daemon under inetd and making use of TCP wrappers 28allows you to perform some host-based authentication of clients. 29That isn't really good enough, as any user on a blessed client 30machine could use the client to send fake check results to the 31daemon (and thus to Nagios). 32 33So what's the solution? Encryption. 34 35 36 37Encrypting Communications 38------------------------- 39In order to avoid some of the security hassles associated with 40allowing remote clients to provide Nagios with host and service 41check results, we can encrypt the data being sent from the client 42to the NSCA daemon. 43 44While encryption is good because it provides some privacy 45as to the information that is being sent from the client to 46the daemon, the main purpose of the encryption is to provide 47the daemon with a way of authenticating the client and 48seeing if they're authorized to provide check results. 49 50Basically the daemon says: 51 52 "Hey, if you (the client) used the same password and 53 algorithm to encrypt the data as I use to decrypt it, 54 I'll accept the check results you're providing me..." 55 56 57 58How The Authentication Works 59---------------------------- 60Authentication of checks results works as follows: 61 621) The user starts the NSCA client and passes the host and/or 63 service check results to it. A password that is used to 64 encrypt the data being sent to the NSCA daemon is stored in 65 the send_nsca config file on the client machine. 66 672) The NSCA client stuff the check results into a packet (or 68 several packets if you send multiple results). 69 703) The NSCA client computes the CRC-32 value of the packet 71 its about to send off and stores that value in the packet 72 body. 73 744) The entire packet body (including the service checking 75 information, as well as the CRC-32 value) is encrypted 76 using the password stored in the send_nsca.cfg file. 77 Encryption of the packet is done using the algorithm 78 specified by the encryption_method variable in the 79 send_nsca.cfg file. 80 81... packet gets sent over the wire... 82 835) The NSCA daemon recieves the packet and decrypts it using 84 the password stored in the nsca.cfg file. Decryption of 85 the packet is done using the algorithm specified by the 86 decryption_method variable in the nsca.cfg file. 87 886) The daemon calculates the CRC-32 value of the decrypted 89 packet to see if it matches the CRC-32 value stored in 90 the packet body (this value was previously computed and 91 stored by the client). 92 937) If the calculated CRC-32 value matches the value that is 94 stored in the packet body, the service check results that 95 are stored in the packet are assumed to be from an 96 authorized user. If the calculated CRC-32 value does NOT 97 match the value in the packet body, the results are assumed 98 to be from an unauthorized user and the packet (and the 99 host or service check results contained therein) are 100 discarded. 101 102 103 104What This Means 105--------------- 106 1071) If the client uses the wrong password to encrypt the 108 packet, the daemon will discard it, as the CRC-32 value 109 stored in the packet will not match the computed value 110 once the packet it decrypted. 111 1122) If the client uses the wrong encryption method, the 113 daemon will discard the results, as the CRC-32 value 114 stored in the packet will not match the computed value 115 once the packet is decrypted. 116 1173) If someone tries to dabble with the contents of the 118 packet as it is being tranferred between the client and 119 the server, the daemon will likely discard the packet, as 120 the CRC-32 value of the packet will likely be invalid. 121 1224) Even if someone manages to figure out a way to make 123 the calculated CRC-32 value match the value stored 124 in the packet, the check results stored in the packet 125 that are passed along to Nagios have to match a valid 126 host or service definition. Nagios ignores all passive 127 check results that come in that are not associated with 128 any valid host or service definitions. 129 130 131 132Preventing "Replay" Attacks 133--------------------------- 134 135The methods described above help ensure that the data the 136NSCA daemon receives is "valid" data - i.e., it was 137encrypted with the appropriate passphrase and crypto 138algorithm. One problem that remains is the fact that 139someone could capture the data packets being sent from the 140client to the daemon and send them back to the daemon at 141a later time. This is referred to as a "replay attack". 142To help prevent this, the NSCA daemon generates what is 143essentially a one-time, randomly generated IV that the 144client must use to encrypt data for each particular 145"session". The IV does not need to be secret, just unique. 146The IV is used in conjunction with the password during 147encryption and decryption. Encrypting a packet with the 148same password but different IVs results in a different 149result. Since the daemon knows what IV it generated and 150sent to the client, it can verify that the data the client 151sends to it has been properly encrypted. This provides 152a reasonable mechanism of preventing replay attacks. 153 154 155 156Caveats 157------- 158 1591) These assumptions rely on the fact that you are using a 160 reasonably secure encryption/decryption method in the 161 NSCA clients and NSCA daemon. 162 1632) These assumptions rely on the fact that you're using a 164 resonable secure password to encrypt/decrypt the data. 165 Depending on the crypto algorithm used, this could mean 166 length and/or randomness. As a general rule, longer 167 passwords or passphrases are better than shorter ones. 168 Insert common sense here. 169 1703) It is assumed that you keep tight security on the 171 send_nsca.cfg and nsca.cfg config files, as they contain 172 both the algorithm and password used to encrypt/decrypt 173 the packets sent between the client and daemon. 174 175 176 177Questions? Comments? Suggestions? 178 179 -- Ethan Galstad (nagios@nagios.org) 180