This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
tutorials:security:kamailio-security [2014/01/29 11:55] davy.van.de.moere_gmail.com [Accept their traffic] |
tutorials:security:kamailio-security [2014/02/03 16:38] davy.van.de.moere_gmail.com |
||
---|---|---|---|
Line 108: | Line 108: | ||
</ | </ | ||
+ | In the same category you have the sip_warning parameter, which is by default enabled. This setting exposes a lot of information about your infrastructure. In production it is advisable to just disable: | ||
+ | |||
+ | < | ||
+ | sip_warning=0 | ||
+ | </ | ||
===== Anti-Flood ===== | ===== Anti-Flood ===== | ||
Line 246: | Line 251: | ||
You can do something similar for pike alerts. | You can do something similar for pike alerts. | ||
+ | |||
+ | ===== Active detection and monitoring ===== | ||
==== Accept their traffic ==== | ==== Accept their traffic ==== | ||
Line 295: | Line 302: | ||
} | } | ||
</ | </ | ||
+ | |||
+ | ===== Digest authentication ===== | ||
+ | |||
+ | ==== What is a digest ==== | ||
+ | |||
+ | Just in case the reader wouldn' | ||
+ | |||
+ | As a very simplified example, assume having two parties Alice and Bob. | ||
+ | |||
+ | Bob and Alice agree a ' | ||
+ | |||
+ | When Bob contacts Alice, Alice ' | ||
+ | |||
+ | Offcourse, the math needs to be a bit more complex, and in SIP it's generally based on MD5 ;) | ||
+ | |||
+ | A SIP digest looks like: | ||
+ | |||
+ | < | ||
+ | Authorization: | ||
+ | uri=" | ||
+ | </ | ||
+ | |||
+ | Nonce == the challenge the server sends | ||
+ | Response == the Nonce + a cryptographic function + the secret as a variable. | ||
+ | |||
+ | |||
+ | ==== The secret being too simple ==== | ||
+ | |||
+ | One of the inherit weaknesses of MD5 is that the calculation goes really fast. Which means if one is able to intercept a sip digest, the secret can be bruteforced. | ||
+ | |||
+ | Being the Nonce, the Response & the algoritm is known, the only unknown is the secret. So one can start guessing which secret it is. Today a password between 1 and 6 characters can be cracked on a normal PC in about an hour. To make matters worse, over Amazon EC2, it is claimed a password of 10 characters can be cracked for less then $100. There are even online services offering this, e.g. [[https:// | ||
+ | |||
+ | As such, it is advisable to have your secrets be autogenerated, | ||
+ | |||
+ | Also, it is advisable to always use TLS to exchange SIP messages. Do note that it is up to the client to verify the correct certificate is used (otherwise a man in the middle attack is not that difficult) | ||
+ | |||
+ | ==== Replay attack ==== | ||
+ | |||
+ | It is not sufficient for the server to check if the digest is correct. The server should also check if that digest has not been used already! Otherwise an attacker could at infinitum re-use the digest to make calls. | ||
+ | |||
+ | Kamailio has stock already a few mechanisms to combat this, but it can be tweaked to be better. By default a digest can be replayed for 300 seconds, but Kamailio can do better. If you want to test, ngrep an INVITE which has a digest, and follow this [[http:// | ||
+ | |||
+ | You can improve this by adding the following. This will break the possibility to do a replay attack from a different machine, and will reduce the timeframe in which a replay attack can be done. | ||
+ | |||
+ | < | ||
+ | modparam(" | ||
+ | modparam(" | ||
+ | modparam(" | ||
+ | modparam(" | ||
+ | modparam(" | ||
+ | |||
+ | modparam(" | ||
+ | modparam(" | ||
+ | modparam(" | ||
+ | modparam(" | ||
+ | |||
+ | # For REGISTER requests we hash the Request-URI, | ||
+ | # request into the nonce string. This ensures that the generated credentials | ||
+ | # cannot be used with another registrar, user agent with another source IP | ||
+ | # address or Call-ID. Note that user agents that change Call-ID with every | ||
+ | # REGISTER message will not be able to register if you enable this. | ||
+ | modparam(" | ||
+ | |||
+ | # For dialog-establishing requests (such as the original INVITE, OPTIONS, etc) | ||
+ | # we hash the Request-URI and source IP. Hashing Call-ID and From tags takes | ||
+ | # some extra precaution, because these checks could render some UA unusable. | ||
+ | modparam(" | ||
+ | |||
+ | # For mid-dialog requests, such as re-INVITE, we can hash source IP and | ||
+ | # Request-URI just like in the previous case. In addition to that we can hash | ||
+ | # Call-ID and From tag because these are fixed within a dialog and are | ||
+ | # guaranteed not to change. This settings effectively restrict the usage of | ||
+ | # generated credentials to a single user agent within a single dialog. | ||
+ | modparam(" | ||
+ | |||
+ | </ | ||
+ |