18 Dec
2013
18 Dec
'13
1:11 p.m.
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(a)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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users