tutorials:security:kamailio-security
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
tutorials:security:kamailio-security [2014/01/29 11:01] – [Accept their traffic] davy.van.de.moere_gmail.com | tutorials:security:kamailio-security [2019/05/23 10:42] (current) – pepelux | ||
---|---|---|---|
Line 5: | Line 5: | ||
Davy Van De Moere | Davy Van De Moere | ||
< | < | ||
+ | |||
+ | Added info of the secfilter module: | ||
+ | Jose Luis Verdeguer | ||
+ | < | ||
</ | </ | ||
Line 92: | Line 96: | ||
</ | </ | ||
- | ==== Change the server header ==== | + | ==== Change the server |
When Kamailio sends you a packet back, it will be friendly enough to tell you which version of Kamailio is running. This informs the attacker which types of attacks might make sense. | When Kamailio sends you a packet back, it will be friendly enough to tell you which version of Kamailio is running. This informs the attacker which types of attacks might make sense. | ||
Line 113: | Line 117: | ||
sip_warning=0 | sip_warning=0 | ||
</ | </ | ||
+ | |||
+ | To change the user agent header (e.g. used from the dispatcher module to send out OPTIONS requests) use this parameter: | ||
+ | |||
+ | < | ||
+ | user_agent_header=" | ||
+ | </ | ||
+ | |||
===== Anti-Flood ===== | ===== Anti-Flood ===== | ||
Line 302: | Line 313: | ||
} | } | ||
</ | </ | ||
+ | |||
+ | ==== Secfilter module ==== | ||
+ | |||
+ | Secfilter is a module that has been designed to offer an additional layer of security over our communications. To achieve this, the following features are available: | ||
+ | |||
+ | * Blacklist to block user agents, IP addresses, countries, domains and users. | ||
+ | * Whitelist to allow user agents, IP addresses, countries, domains and users. | ||
+ | * Blacklist of destinations where the called number is not allowed. | ||
+ | * SQL injection attacks prevention. | ||
+ | |||
+ | For example, to block IP addresses we have to use a database because it is very common to update the blacklist, since every day we receive many attacks from different places. The goal of this module is to avoid unnecessary queries to the database, so all the data will be in the memory. | ||
+ | |||
+ | We can use RPC commands to update blacklists and whitelists. And also to see some statistics of blocked messages. | ||
+ | |||
+ | Example of use: | ||
+ | |||
+ | < | ||
+ | loadmodule | ||
+ | loadmodule | ||
+ | |||
+ | ... | ||
+ | |||
+ | modparam(" | ||
+ | modparam(" | ||
+ | |||
+ | ... | ||
+ | |||
+ | route[SECURITY_CHECKS] { | ||
+ | if (geoip2_match(" | ||
+ | secf_check_country($gip2(src=> | ||
+ | # return values ... | ||
+ | # 2 = whitelisted | ||
+ | # 1 = not found | ||
+ | # -1 = error | ||
+ | # -2 = blacklisted | ||
+ | if ($? == -2) { | ||
+ | xalert(" | ||
+ | exit; | ||
+ | } | ||
+ | } | ||
+ | |||
+ | secf_check_ip(); | ||
+ | if ($? == -2) { | ||
+ | xalert(" | ||
+ | exit; | ||
+ | } | ||
+ | |||
+ | secf_check_sqli_all(); | ||
+ | |||
+ | secf_check_ua(); | ||
+ | if ($? == -2) { | ||
+ | xalert(" | ||
+ | exit; | ||
+ | } | ||
+ | |||
+ | secf_check_from_hdr(); | ||
+ | # return values ... | ||
+ | # 4 = name whitelisted | ||
+ | # 3 = domain whitelisted | ||
+ | # 2 = user whitelisted | ||
+ | # 1 = not found | ||
+ | # -1 = error | ||
+ | # -2 = user blacklisted | ||
+ | # -3 = domain blacklisted | ||
+ | # -4 = name blacklisted | ||
+ | switch ($?) { | ||
+ | case -2: | ||
+ | xalert(" | ||
+ | exit; | ||
+ | case -3: | ||
+ | xalert(" | ||
+ | |||
+ | case -4: | ||
+ | xalert(" | ||
+ | exit; | ||
+ | }; | ||
+ | |||
+ | secf_check_to_hdr(); | ||
+ | switch ($?) { | ||
+ | case -2: | ||
+ | xalert(" | ||
+ | exit; | ||
+ | case -3: | ||
+ | xalert(" | ||
+ | exit; | ||
+ | case -4: | ||
+ | xalert(" | ||
+ | exit; | ||
+ | }; | ||
+ | |||
+ | secf_check_contact_hdr(); | ||
+ | switch ($?) { | ||
+ | case -2: | ||
+ | xalert(" | ||
+ | exit; | ||
+ | case -3: | ||
+ | xalert(" | ||
+ | exit; | ||
+ | }; | ||
+ | |||
+ | if (is_method(" | ||
+ | secf_check_dst($rU); | ||
+ | if ($? == -2) { | ||
+ | xalert(" | ||
+ | exit; | ||
+ | } | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | Some RPC commands: | ||
+ | |||
+ | < | ||
+ | $ kamcmd secfilter.print ua | ||
+ | |||
+ | User-agent | ||
+ | ========== | ||
+ | [+] Blacklisted | ||
+ | ----------- | ||
+ | 0001 -> friendly-scanner | ||
+ | 0002 -> pplsip | ||
+ | 0003 -> sipcli | ||
+ | 0004 -> sundayddr | ||
+ | 0005 -> iWar | ||
+ | 0006 -> sipsak | ||
+ | 0007 -> VaxSIPUserAgent | ||
+ | 0008 -> SimpleSIP | ||
+ | 0009 -> SIP Call | ||
+ | 0010 -> Ozeki | ||
+ | 0011 -> VoIPSec | ||
+ | 0012 -> SIPScan | ||
+ | 0013 -> Conaito | ||
+ | 0014 -> UsaAirport | ||
+ | 0015 -> PortSIP VoIP SDK | ||
+ | 0016 -> zxcvfdf11 | ||
+ | 0017 -> fdgddfg546df4g8d5f | ||
+ | |||
+ | [+] Whitelisted | ||
+ | ----------- | ||
+ | 0001 -> my custom ua | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | $ kamcmd secfilter.stats | ||
+ | |||
+ | Blocked messages (blacklist) | ||
+ | ============================ | ||
+ | [+] By user-agent | ||
+ | [+] By country | ||
+ | [+] By from domain | ||
+ | [+] By to domain | ||
+ | [+] By contact domain: 1 | ||
+ | [+] By IP address | ||
+ | [+] By from name : 0 | ||
+ | [+] By to name : 0 | ||
+ | [+] By contact name : 0 | ||
+ | [+] By from user : 316 | ||
+ | [+] By to user : 134 | ||
+ | [+] By contact user : 0 | ||
+ | |||
+ | Allowed messages (whitelist) | ||
+ | ============================ | ||
+ | [+] By user-agent | ||
+ | [+] By country | ||
+ | [+] By from domain | ||
+ | [+] By to domain | ||
+ | [+] By contact domain: 0 | ||
+ | [+] By IP address | ||
+ | [+] By from name : 0 | ||
+ | [+] By to name : 0 | ||
+ | [+] By contact name : 0 | ||
+ | [+] By from user : 0 | ||
+ | [+] By to user : 0 | ||
+ | [+] By contact user : 0 | ||
+ | |||
+ | Other blocked messages | ||
+ | ====================== | ||
+ | [+] Destinations | ||
+ | [+] SQL injection | ||
+ | </ | ||
+ | |||
+ | |||
+ | ===== 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(" | ||
+ | |||
+ | </ | ||
+ |
tutorials/security/kamailio-security.1390993301.txt.gz · Last modified: 2014/01/29 11:01 by davy.van.de.moere_gmail.com