Hi all,
we all enjoy our FAIL2BAN and snippets of our Kamailio config when we see it successfully fight off the "friendly-scanner", and multiple futile attempts to fool our systems. But it got me thinking…
What is a sufficient level of security on our Kamailio machinery… ? Are we all just doing whatever, or is the nature of the beast, that every setup is different?
Eventually while having a beer, we will end up in the discussion Kamailio is as good (and even much better) as most of the commercially available SBCs. But, imho, that all depends on the configuration.
There are a few good reads available, and on the security front I personally love Pike, Topoh, Dnssec, Htable and recently I think I'm doing rather clever stuff with CNXCC… And I do feel comfortable on my setups, them won't be hacked…
But do we have a-sort -of stake in the ground example configuration which we can consider as being more than sufficiently secure? Some config where we can tick off all the known security risks for SIP (as chapter 26 of rfc3261 gives a state of the art back in 2002) Or would that be a nice idea for a micro project?
Grtz, Davy
Hello,
On 17/12/13 17:27, davy wrote:
Hi all,
we all enjoy our FAIL2BAN and snippets of our Kamailio config when we see it successfully fight off the "friendly-scanner", and multiple futile attempts to fool our systems. But it got me thinking…
What is a sufficient level of security on our Kamailio machinery… ? Are we all just doing whatever, or is the nature of the beast, that every setup is different?
Indeed, Kamailio being more like a framework, lot of deployments are different, even when targeting same features. In some cases, dictionary attacks don't apply (e.g., carriers interconnect when traffic is allowed by IP address).
Eventually while having a beer, we will end up in the discussion Kamailio is as good (and even much better) as most of the commercially available SBCs. But, imho, that all depends on the configuration.
There are a few good reads available, and on the security front I personally love Pike, Topoh, Dnssec, Htable and recently I think I'm doing rather clever stuff with CNXCC… And I do feel comfortable on my setups, them won't be hacked…
But do we have a-sort -of stake in the ground example configuration which we can consider as being more than sufficiently secure? Some config where we can tick off all the known security risks for SIP (as chapter 26 of rfc3261 gives a state of the art back in 2002) Or would that be a nice idea for a micro project?
It would be good to create a page (or group or pages) in kamailio.org/wiki to approach security considerations. Besides the well known situations and solutions for attacks, it happens quite often to see new types of attacks, so adding notes there along with hints on how to solve with Kamailio would be very useful for everybody.
Long time ago I made a wiki tutorial on my company site: - http://kb.asipto.com/kamailio:usage:k31-sip-scanning-attack
I don't mind being cloned and improved (well, I guess some parts could be trimmed as might not be relevant in general and some need to be updated for latest version).
There are many types of attacks not mentioned there, that can be highlighted for everyone to pay attention, e.g.,: - nonce reply (use one time nonce with auth module) - proper handling of route headers to avoid preset route headers in initial invite (is done in the default config file, but pointing at it makes people be more careful and don't miss it when building new configs)
Overall, yes, security is a topic very useful, hopefully there are be enough people willing to spend some time and share information.
Cheers, Daniel -
Cool, I'll spend some time this weekend to have a first stake in the ground on the wiki !
It's better to have our security measures being checked by peers than by hackers ;)
Op 18-dec.-2013, om 09:33 heeft Daniel-Constantin Mierla miconda@gmail.com het volgende geschreven:
Hello,
On 17/12/13 17:27, davy wrote:
Hi all,
we all enjoy our FAIL2BAN and snippets of our Kamailio config when we see it successfully fight off the "friendly-scanner", and multiple futile attempts to fool our systems. But it got me thinking…
What is a sufficient level of security on our Kamailio machinery… ? Are we all just doing whatever, or is the nature of the beast, that every setup is different?
Indeed, Kamailio being more like a framework, lot of deployments are different, even when targeting same features. In some cases, dictionary attacks don't apply (e.g., carriers interconnect when traffic is allowed by IP address).
Eventually while having a beer, we will end up in the discussion Kamailio is as good (and even much better) as most of the commercially available SBCs. But, imho, that all depends on the configuration.
There are a few good reads available, and on the security front I personally love Pike, Topoh, Dnssec, Htable and recently I think I'm doing rather clever stuff with CNXCC… And I do feel comfortable on my setups, them won't be hacked…
But do we have a-sort -of stake in the ground example configuration which we can consider as being more than sufficiently secure? Some config where we can tick off all the known security risks for SIP (as chapter 26 of rfc3261 gives a state of the art back in 2002) Or would that be a nice idea for a micro project?
It would be good to create a page (or group or pages) in kamailio.org/wiki to approach security considerations. Besides the well known situations and solutions for attacks, it happens quite often to see new types of attacks, so adding notes there along with hints on how to solve with Kamailio would be very useful for everybody.
Long time ago I made a wiki tutorial on my company site:
I don't mind being cloned and improved (well, I guess some parts could be trimmed as might not be relevant in general and some need to be updated for latest version).
There are many types of attacks not mentioned there, that can be highlighted for everyone to pay attention, e.g.,:
- nonce reply (use one time nonce with auth module)
- proper handling of route headers to avoid preset route headers in initial invite (is done in the default config file, but pointing at it makes people be more careful and don't miss it when building new configs)
Overall, yes, security is a topic very useful, hopefully there are be enough people willing to spend some time and share information.
Cheers, Daniel
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
On 18 Dec 2013, at 10:53, davy davy.van.de.moere@gmail.com wrote:
Cool, I'll spend some time this weekend to have a first stake in the ground on the wiki !
It's better to have our security measures being checked by peers than by hackers ;)
Thank you, Davy!
When you've got a template, ping me. I can send out info on the web site, FB and twitter to get feedback and cooperation.
/O
Op 18-dec.-2013, om 09:33 heeft Daniel-Constantin Mierla miconda@gmail.com het volgende geschreven:
Hello,
On 17/12/13 17:27, davy wrote:
Hi all,
we all enjoy our FAIL2BAN and snippets of our Kamailio config when we see it successfully fight off the "friendly-scanner", and multiple futile attempts to fool our systems. But it got me thinking…
What is a sufficient level of security on our Kamailio machinery… ? Are we all just doing whatever, or is the nature of the beast, that every setup is different?
Indeed, Kamailio being more like a framework, lot of deployments are different, even when targeting same features. In some cases, dictionary attacks don't apply (e.g., carriers interconnect when traffic is allowed by IP address).
Eventually while having a beer, we will end up in the discussion Kamailio is as good (and even much better) as most of the commercially available SBCs. But, imho, that all depends on the configuration.
There are a few good reads available, and on the security front I personally love Pike, Topoh, Dnssec, Htable and recently I think I'm doing rather clever stuff with CNXCC… And I do feel comfortable on my setups, them won't be hacked…
But do we have a-sort -of stake in the ground example configuration which we can consider as being more than sufficiently secure? Some config where we can tick off all the known security risks for SIP (as chapter 26 of rfc3261 gives a state of the art back in 2002) Or would that be a nice idea for a micro project?
It would be good to create a page (or group or pages) in kamailio.org/wiki to approach security considerations. Besides the well known situations and solutions for attacks, it happens quite often to see new types of attacks, so adding notes there along with hints on how to solve with Kamailio would be very useful for everybody.
Long time ago I made a wiki tutorial on my company site:
I don't mind being cloned and improved (well, I guess some parts could be trimmed as might not be relevant in general and some need to be updated for latest version).
There are many types of attacks not mentioned there, that can be highlighted for everyone to pay attention, e.g.,:
- nonce reply (use one time nonce with auth module)
- proper handling of route headers to avoid preset route headers in initial invite (is done in the default config file, but pointing at it makes people be more careful and don't miss it when building new configs)
Overall, yes, security is a topic very useful, hopefully there are be enough people willing to spend some time and share information.
Cheers, Daniel
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Awesome :)
Op 18-dec.-2013, om 11:02 heeft "Olle E. Johansson" oej@edvina.net het volgende geschreven:
On 18 Dec 2013, at 10:53, davy davy.van.de.moere@gmail.com wrote:
Cool, I'll spend some time this weekend to have a first stake in the ground on the wiki !
It's better to have our security measures being checked by peers than by hackers ;)
Thank you, Davy!
When you've got a template, ping me. I can send out info on the web site, FB and twitter to get feedback and cooperation.
/O
Op 18-dec.-2013, om 09:33 heeft Daniel-Constantin Mierla miconda@gmail.com het volgende geschreven:
Hello,
On 17/12/13 17:27, davy wrote:
Hi all,
we all enjoy our FAIL2BAN and snippets of our Kamailio config when we see it successfully fight off the "friendly-scanner", and multiple futile attempts to fool our systems. But it got me thinking…
What is a sufficient level of security on our Kamailio machinery… ? Are we all just doing whatever, or is the nature of the beast, that every setup is different?
Indeed, Kamailio being more like a framework, lot of deployments are different, even when targeting same features. In some cases, dictionary attacks don't apply (e.g., carriers interconnect when traffic is allowed by IP address).
Eventually while having a beer, we will end up in the discussion Kamailio is as good (and even much better) as most of the commercially available SBCs. But, imho, that all depends on the configuration.
There are a few good reads available, and on the security front I personally love Pike, Topoh, Dnssec, Htable and recently I think I'm doing rather clever stuff with CNXCC… And I do feel comfortable on my setups, them won't be hacked…
But do we have a-sort -of stake in the ground example configuration which we can consider as being more than sufficiently secure? Some config where we can tick off all the known security risks for SIP (as chapter 26 of rfc3261 gives a state of the art back in 2002) Or would that be a nice idea for a micro project?
It would be good to create a page (or group or pages) in kamailio.org/wiki to approach security considerations. Besides the well known situations and solutions for attacks, it happens quite often to see new types of attacks, so adding notes there along with hints on how to solve with Kamailio would be very useful for everybody.
Long time ago I made a wiki tutorial on my company site:
I don't mind being cloned and improved (well, I guess some parts could be trimmed as might not be relevant in general and some need to be updated for latest version).
There are many types of attacks not mentioned there, that can be highlighted for everyone to pay attention, e.g.,:
- nonce reply (use one time nonce with auth module)
- proper handling of route headers to avoid preset route headers in initial invite (is done in the default config file, but pointing at it makes people be more careful and don't miss it when building new configs)
Overall, yes, security is a topic very useful, hopefully there are be enough people willing to spend some time and share information.
Cheers, Daniel
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hello,
On 18/12/13 10:53, davy wrote:
Cool, I'll spend some time this weekend to have a first stake in the ground on the wiki !
great! Just use namespaces when creating new pages, to have a good structure of the wiki. It can be something under tutorials, such as:
tutorials:security:TITLE
where TITLE can be what you consider more appropriate, such as 'how-to', 'remarks' or what so ever...
Cheers, Daniel
It's better to have our security measures being checked by peers than by hackers ;)
Op 18-dec.-2013, om 09:33 heeft Daniel-Constantin Mierla miconda@gmail.com het volgende geschreven:
Hello,
On 17/12/13 17:27, davy wrote:
Hi all,
we all enjoy our FAIL2BAN and snippets of our Kamailio config when we see it successfully fight off the "friendly-scanner", and multiple futile attempts to fool our systems. But it got me thinking…
What is a sufficient level of security on our Kamailio machinery… ? Are we all just doing whatever, or is the nature of the beast, that every setup is different?
Indeed, Kamailio being more like a framework, lot of deployments are different, even when targeting same features. In some cases, dictionary attacks don't apply (e.g., carriers interconnect when traffic is allowed by IP address).
Eventually while having a beer, we will end up in the discussion Kamailio is as good (and even much better) as most of the commercially available SBCs. But, imho, that all depends on the configuration.
There are a few good reads available, and on the security front I personally love Pike, Topoh, Dnssec, Htable and recently I think I'm doing rather clever stuff with CNXCC… And I do feel comfortable on my setups, them won't be hacked…
But do we have a-sort -of stake in the ground example configuration which we can consider as being more than sufficiently secure? Some config where we can tick off all the known security risks for SIP (as chapter 26 of rfc3261 gives a state of the art back in 2002) Or would that be a nice idea for a micro project?
It would be good to create a page (or group or pages) in kamailio.org/wiki to approach security considerations. Besides the well known situations and solutions for attacks, it happens quite often to see new types of attacks, so adding notes there along with hints on how to solve with Kamailio would be very useful for everybody.
Long time ago I made a wiki tutorial on my company site:
I don't mind being cloned and improved (well, I guess some parts could be trimmed as might not be relevant in general and some need to be updated for latest version).
There are many types of attacks not mentioned there, that can be highlighted for everyone to pay attention, e.g.,:
- nonce reply (use one time nonce with auth module)
- proper handling of route headers to avoid preset route headers in initial invite (is done in the default config file, but pointing at it makes people be more careful and don't miss it when building new configs)
Overall, yes, security is a topic very useful, hopefully there are be enough people willing to spend some time and share information.
Cheers, Daniel
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
ACK
:)
Op 18-dec.-2013, om 15:30 heeft Daniel-Constantin Mierla miconda@gmail.com het volgende geschreven:
Hello,
On 18/12/13 10:53, davy wrote:
Cool, I'll spend some time this weekend to have a first stake in the ground on the wiki !
great! Just use namespaces when creating new pages, to have a good structure of the wiki. It can be something under tutorials, such as:
tutorials:security:TITLE
where TITLE can be what you consider more appropriate, such as 'how-to', 'remarks' or what so ever...
Cheers, Daniel
It's better to have our security measures being checked by peers than by hackers ;)
Op 18-dec.-2013, om 09:33 heeft Daniel-Constantin Mierla miconda@gmail.com het volgende geschreven:
Hello,
On 17/12/13 17:27, davy wrote:
Hi all,
we all enjoy our FAIL2BAN and snippets of our Kamailio config when we see it successfully fight off the "friendly-scanner", and multiple futile attempts to fool our systems. But it got me thinking…
What is a sufficient level of security on our Kamailio machinery… ? Are we all just doing whatever, or is the nature of the beast, that every setup is different?
Indeed, Kamailio being more like a framework, lot of deployments are different, even when targeting same features. In some cases, dictionary attacks don't apply (e.g., carriers interconnect when traffic is allowed by IP address).
Eventually while having a beer, we will end up in the discussion Kamailio is as good (and even much better) as most of the commercially available SBCs. But, imho, that all depends on the configuration.
There are a few good reads available, and on the security front I personally love Pike, Topoh, Dnssec, Htable and recently I think I'm doing rather clever stuff with CNXCC… And I do feel comfortable on my setups, them won't be hacked…
But do we have a-sort -of stake in the ground example configuration which we can consider as being more than sufficiently secure? Some config where we can tick off all the known security risks for SIP (as chapter 26 of rfc3261 gives a state of the art back in 2002) Or would that be a nice idea for a micro project?
It would be good to create a page (or group or pages) in kamailio.org/wiki to approach security considerations. Besides the well known situations and solutions for attacks, it happens quite often to see new types of attacks, so adding notes there along with hints on how to solve with Kamailio would be very useful for everybody.
Long time ago I made a wiki tutorial on my company site:
I don't mind being cloned and improved (well, I guess some parts could be trimmed as might not be relevant in general and some need to be updated for latest version).
There are many types of attacks not mentioned there, that can be highlighted for everyone to pay attention, e.g.,:
- nonce reply (use one time nonce with auth module)
- proper handling of route headers to avoid preset route headers in initial invite (is done in the default config file, but pointing at it makes people be more careful and don't miss it when building new configs)
Overall, yes, security is a topic very useful, hopefully there are be enough people willing to spend some time and share information.
Cheers, Daniel
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
I started the pages, to be found :
http://www.kamailio.org/wiki/tutorials/security/security-threats http://www.kamailio.org/wiki/tutorials/security/kamailio-security
They are a long from being complete, but it's a start, feel free to modify/correct/add content!
2013-12-18 davy davy.van.de.moere@gmail.com
ACK
:)
Op 18-dec.-2013, om 15:30 heeft Daniel-Constantin Mierla < miconda@gmail.com> het volgende geschreven:
Hello,
On 18/12/13 10:53, davy wrote:
Cool, I'll spend some time this weekend to have a first stake in the
ground on the wiki !
great! Just use namespaces when creating new pages, to have a good
structure of the wiki. It can be something under tutorials, such as:
tutorials:security:TITLE
where TITLE can be what you consider more appropriate, such as
'how-to', 'remarks' or what so ever...
Cheers, Daniel
It's better to have our security measures being checked by peers than
by hackers ;)
Op 18-dec.-2013, om 09:33 heeft Daniel-Constantin Mierla <
miconda@gmail.com> het volgende geschreven:
Hello,
On 17/12/13 17:27, davy wrote:
Hi all,
we all enjoy our FAIL2BAN and snippets of our Kamailio config when we
see it successfully fight off the "friendly-scanner", and multiple futile attempts to fool our systems. But it got me thinking...
What is a sufficient level of security on our Kamailio machinery... ?
Are we all just doing whatever, or is the nature of the beast, that every setup is different?
Indeed, Kamailio being more like a framework, lot of deployments are
different, even when targeting same features. In some cases, dictionary attacks don't apply (e.g., carriers interconnect when traffic is allowed by IP address).
Eventually while having a beer, we will end up in the discussion
Kamailio is as good (and even much better) as most of the commercially available SBCs. But, imho, that all depends on the configuration.
There are a few good reads available, and on the security front I
personally love Pike, Topoh, Dnssec, Htable and recently I think I'm doing rather clever stuff with CNXCC... And I do feel comfortable on my setups, them won't be hacked...
But do we have a-sort -of stake in the ground example configuration
which we can consider as being more than sufficiently secure? Some config where we can tick off all the known security risks for SIP (as chapter 26 of rfc3261 gives a state of the art back in 2002) Or would that be a nice idea for a micro project?
It would be good to create a page (or group or pages) in
kamailio.org/wiki to approach security considerations. Besides the well known situations and solutions for attacks, it happens quite often to see new types of attacks, so adding notes there along with hints on how to solve with Kamailio would be very useful for everybody.
Long time ago I made a wiki tutorial on my company site:
I don't mind being cloned and improved (well, I guess some parts could
be trimmed as might not be relevant in general and some need to be updated for latest version).
There are many types of attacks not mentioned there, that can be
highlighted for everyone to pay attention, e.g.,:
- nonce reply (use one time nonce with auth module)
- proper handling of route headers to avoid preset route headers in
initial invite (is done in the default config file, but pointing at it makes people be more careful and don't miss it when building new configs)
Overall, yes, security is a topic very useful, hopefully there are be
enough people willing to spend some time and share information.
Cheers, Daniel
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Hi!
I was just testing the digest replay possibilities against Kamailio. (findings: http://www.kamailio.org/wiki/tutorials/security/kamailio-security#digest_aut...)
It looks that by default (the typical default configs), a SIP replay attack can be done during 300 seconds (?) .
Now I tried the code snippet from the auth module:
http://kamailio.org/docs/modules/4.1.x/modules/auth.html#auth.p.nonce_count
But my setup can’t seem to find back the digest_challenge. I did read somewhere digest_challenge has been taken out of the codebase.
Is the documentation out of sync, or am I really having a facepalm moment? Btw I’m on 4.2.
Grtz, Davy
Op 29-jan.-2014, om 12:37 heeft davy van de moere davy.van.de.moere@gmail.com het volgende geschreven:
I started the pages, to be found :
http://www.kamailio.org/wiki/tutorials/security/security-threats http://www.kamailio.org/wiki/tutorials/security/kamailio-security
They are a long from being complete, but it's a start, feel free to modify/correct/add content!
2013-12-18 davy davy.van.de.moere@gmail.com ACK
:)
Op 18-dec.-2013, om 15:30 heeft Daniel-Constantin Mierla miconda@gmail.com het volgende geschreven:
Hello,
On 18/12/13 10:53, davy wrote:
Cool, I'll spend some time this weekend to have a first stake in the ground on the wiki !
great! Just use namespaces when creating new pages, to have a good structure of the wiki. It can be something under tutorials, such as:
tutorials:security:TITLE
where TITLE can be what you consider more appropriate, such as 'how-to', 'remarks' or what so ever...
Cheers, Daniel
It's better to have our security measures being checked by peers than by hackers ;)
Op 18-dec.-2013, om 09:33 heeft Daniel-Constantin Mierla miconda@gmail.com het volgende geschreven:
Hello,
On 17/12/13 17:27, davy wrote:
Hi all,
we all enjoy our FAIL2BAN and snippets of our Kamailio config when we see it successfully fight off the "friendly-scanner", and multiple futile attempts to fool our systems. But it got me thinking…
What is a sufficient level of security on our Kamailio machinery… ? Are we all just doing whatever, or is the nature of the beast, that every setup is different?
Indeed, Kamailio being more like a framework, lot of deployments are different, even when targeting same features. In some cases, dictionary attacks don't apply (e.g., carriers interconnect when traffic is allowed by IP address).
Eventually while having a beer, we will end up in the discussion Kamailio is as good (and even much better) as most of the commercially available SBCs. But, imho, that all depends on the configuration.
There are a few good reads available, and on the security front I personally love Pike, Topoh, Dnssec, Htable and recently I think I'm doing rather clever stuff with CNXCC… And I do feel comfortable on my setups, them won't be hacked…
But do we have a-sort -of stake in the ground example configuration which we can consider as being more than sufficiently secure? Some config where we can tick off all the known security risks for SIP (as chapter 26 of rfc3261 gives a state of the art back in 2002) Or would that be a nice idea for a micro project?
It would be good to create a page (or group or pages) in kamailio.org/wiki to approach security considerations. Besides the well known situations and solutions for attacks, it happens quite often to see new types of attacks, so adding notes there along with hints on how to solve with Kamailio would be very useful for everybody.
Long time ago I made a wiki tutorial on my company site:
I don't mind being cloned and improved (well, I guess some parts could be trimmed as might not be relevant in general and some need to be updated for latest version).
There are many types of attacks not mentioned there, that can be highlighted for everyone to pay attention, e.g.,:
- nonce reply (use one time nonce with auth module)
- proper handling of route headers to avoid preset route headers in initial invite (is done in the default config file, but pointing at it makes people be more careful and don't miss it when building new configs)
Overall, yes, security is a topic very useful, hopefully there are be enough people willing to spend some time and share information.
Cheers, Daniel
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Davy,
I would also weigh on the side of saying that Kamailio security, even in a best-practical, common denominator kind of way, is inextricably bound up in the specificity of how Kamailio is being used, the role it's playing as a network element, the topology in which it is participating, etc.
Kamailio itself can handle a ridiculously large amount of SIP throughput with no issue, from DoS attacks, dictionary scans, etc. There's no serious danger of overwhelming Kamailio per se with message volume. In in its principal role as a proxy, a lot of thinking about securing Kamailio really pertains to the securing of endpoints behind Kamailio, that Kamailio is routing calls to/from, or is somehow representing. It can also be about preventing entities on which Kamailio relies for call processing in a heavily I/O-bound way, e.g. databases, from being overwhelmed. The reason it is possible to DoS a Kamailio server is because its relatively small pool of worker threads can become tied up with waiting on third-party services that can become overwhelmed by the requests.
So, any security strategy is going to involve thinking about how to prevent those services or additional elements from becoming overwhelmed in their own right. The focus is seldom on Kamailio itself, but more on Kamailio as it relates to the zoo of other dependencies in which it is deployed to perform some sort of useful, integrated function.
All this to say, I cannot see much value in a blanket dogma of security principles that are supposedly applicable to any deployment, in any context.
-- Alex
On 12/17/2013 11:27 AM, davy wrote:
Hi all,
we all enjoy our FAIL2BAN and snippets of our Kamailio config when we see it successfully fight off the "friendly-scanner", and multiple futile attempts to fool our systems. But it got me thinking…
What is a sufficient level of security on our Kamailio machinery… ? Are we all just doing whatever, or is the nature of the beast, that every setup is different?
Eventually while having a beer, we will end up in the discussion Kamailio is as good (and even much better) as most of the commercially available SBCs. But, imho, that all depends on the configuration.
There are a few good reads available, and on the security front I personally love Pike, Topoh, Dnssec, Htable and recently I think I'm doing rather clever stuff with CNXCC… And I do feel comfortable on my setups, them won't be hacked…
But do we have a-sort -of stake in the ground example configuration which we can consider as being more than sufficiently secure? Some config where we can tick off all the known security risks for SIP (as chapter 26 of rfc3261 gives a state of the art back in 2002) Or would that be a nice idea for a micro project?
Grtz, Davy _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Alex,
Thx for your prompt feedback!
We could conclude that stating something like "This config is the best way to secure your Kamailio", is a contradictio in terminis ;)
But I think two aspects might be very handy. A first would be to list all the attacks on VoIP networks known to man, and how Kamailio can help defending on this, with e.g. config snippets, …
A second which I personally find very interesting, is how we can have Kamailio & opensource products in the vicinity, beat commercial SBCs at their own game, in terms of features. I do believe this would seriously reduce barfights :D
Grtz, Davy
Op 18-dec.-2013, om 11:48 heeft Alex Balashov abalashov@evaristesys.com het volgende geschreven:
Davy,
I would also weigh on the side of saying that Kamailio security, even in a best-practical, common denominator kind of way, is inextricably bound up in the specificity of how Kamailio is being used, the role it's playing as a network element, the topology in which it is participating, etc.
Kamailio itself can handle a ridiculously large amount of SIP throughput with no issue, from DoS attacks, dictionary scans, etc. There's no serious danger of overwhelming Kamailio per se with message volume. In in its principal role as a proxy, a lot of thinking about securing Kamailio really pertains to the securing of endpoints behind Kamailio, that Kamailio is routing calls to/from, or is somehow representing. It can also be about preventing entities on which Kamailio relies for call processing in a heavily I/O-bound way, e.g. databases, from being overwhelmed. The reason it is possible to DoS a Kamailio server is because its relatively small pool of worker threads can become tied up with waiting on third-party services that can become overwhelmed by the requests.
So, any security strategy is going to involve thinking about how to prevent those services or additional elements from becoming overwhelmed in their own right. The focus is seldom on Kamailio itself, but more on Kamailio as it relates to the zoo of other dependencies in which it is deployed to perform some sort of useful, integrated function.
All this to say, I cannot see much value in a blanket dogma of security principles that are supposedly applicable to any deployment, in any context.
-- Alex
On 12/17/2013 11:27 AM, davy wrote:
Hi all,
we all enjoy our FAIL2BAN and snippets of our Kamailio config when we see it successfully fight off the "friendly-scanner", and multiple futile attempts to fool our systems. But it got me thinking…
What is a sufficient level of security on our Kamailio machinery… ? Are we all just doing whatever, or is the nature of the beast, that every setup is different?
Eventually while having a beer, we will end up in the discussion Kamailio is as good (and even much better) as most of the commercially available SBCs. But, imho, that all depends on the configuration.
There are a few good reads available, and on the security front I personally love Pike, Topoh, Dnssec, Htable and recently I think I'm doing rather clever stuff with CNXCC… And I do feel comfortable on my setups, them won't be hacked…
But do we have a-sort -of stake in the ground example configuration which we can consider as being more than sufficiently secure? Some config where we can tick off all the known security risks for SIP (as chapter 26 of rfc3261 gives a state of the art back in 2002) Or would that be a nice idea for a micro project?
Grtz, Davy _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 12/18/2013 06:11 AM, davy wrote:
But I think two aspects might be very handy. A first would be to list all the attacks on VoIP networks known to man, and how Kamailio can help defending on this, with e.g. config snippets, …
A second which I personally find very interesting, is how we can have Kamailio & opensource products in the vicinity, beat commercial SBCs at their own game, in terms of features. I do believe this would seriously reduce barfights :D
True. And, although it might have come across that way, I didn't mean to suggest that there's nothing useful to say on a broad security overview page.
I am just very wary of telling people that This Is How You Make Kamailio Secure, when the answer is completely in the details of what you're doing and how you're doing. Kamailio, as you know, is a fairly low-level product, not a finished application. It somewhat resembles an SDK with a proxy service core. So, one can reasonably say that Asterisk or Freeswitch security consists in these general steps, because these are endpoints that do more or less one sort of thing, and usually by way of predictable mechanisms at an implementational level. With Kamailio, it's just far less constructive to make that sort of generalisation.
-- Alex
Hoho,
i want to implement RFC3578 (transaction oriented) in Kamailio. I see various ways of accomplishing this, but I stuck at all of my solutions. Find the algorithm I want to implement attached.
Shortly explained what RFC3578 is: In a open numbering plan you never know if the INVITE you received is already complete, or if there are more numbers coming in. One way of accomplishing this is to set up a timer. If the timer elapses you assume the number is complete. If not, you are receiving a new INVITE with one digit more. Now you have to close the old transaction with a "484 - Address Incomplete"-response and start the timer again. (Find the algorithm I want to implement attached)
Any advise appriciated!!
The following lines, I'm going to explain my thoughts. For reference I'm calling "Thread A" the first INVITE coming in and "Thread B" the second.
####################### ### using Module ASYNC * Thread A -> async_route("handle_overlap","<timer t99 value>"); * Thread B -> if new incoming transaction, ** set avp("<call-id>")= <digitlength of called number> and ** call async_route("handle_overlap","<timer t99 value>"); * in route[handle_overlap] ** if avp("call-id") greater than "<digitlength of called number>" *** cancel transaction with "484 -Address Incomplete" ** if avp("call-id") equals "<digitlength of called number>" *** handle call => the number is complete PROBLEM: The old transaction is not canceled immediately, but after t99 elapsed...
####################### ### using Module TMX using t_suspend() and t_continue(), but here i see the following problems: * Thread A calls "t_suspend()" ** How is it possible to cancel "Thread A"'s transaction from Thread B? ** If there is no Thread B, so the numbers were complete, how can I get Thread A to continue processing?? * General TMX-Question: Are there any examples available?
####################### ### using simple sleep() and shv()/avp() Sounds like dirty hacking... I'd appriciate a solution with one of aboves modules. But if there is a solution available, I'd try this.
Thx in advise Moritz
-
Alex Balashov -
Daniel-Constantin Mierla -
davy -
davy van de moere
-
Moritz Graf -
Olle E. Johansson