Lonnie
I think you are spot on from my testing and the use of TLS would not stop brute
force attacks. I imagine that it would slow it down though.
I am thinking that other options to mitigate this problem could be:
1) Don't use numbers for the SIP UserID
2) Long and difficult passwords
3) Use custom firewall rules to prevent multiple SIP registration attempts. One
of my customers has this configured which seems to be working (shown below).
4) Use a TLS SIP proxy like reSIProcate which does support client certificate
checking. http://www.resiprocate.org/Main_Page
Any input would be appreciated.
Thanks Mike
#-------------------
# Defines new iptables chains. At boot, these two commands run without
error because the chains are new. At reload, they cause a log error, but
who cares.
iptables -N SCAN_CHECK
iptables -N LOG_SCANDROP
# Flush any existing rules in the chains. Only useful at reload
iptables -F SCAN_CHECK
iptables -F LOG_SCANDROP
# Uncomment the following to log every packet entering the SCAN_CHECK
chain. Causes lots of logs
#iptables -A SCAN_CHECK -p udp --dport 5060 -j LOG --log-prefix "**SIP "
# Uncomment the following to perform ad-hoc logging of various packet
types in the SCAN_CHECK chain. Good for identifying particular scans
#iptables -A SCAN_CHECK -p udp --dport 5060:5063 -m string --string
"REGISTER sip:" --algo bm --to 65 -j LOG --log-prefix "SIP Register "
#iptables -A SCAN_CHECK -p udp --dport 5060:5063 -m string --string
"INVITE sip:" --algo bm --to 65 -j LOG --log-prefix "SIP Invite "
#iptables -A SCAN_CHECK -p udp --dport 5060:5063 -m string --string
"SUBSCRIBE sip:" --algo bm --to 65 -j LOG --log-prefix "SIP Subscribe "
#iptables -A SCAN_CHECK -p udp --dport 5060:5063 -m string --string
"NOTIFY sip:" --algo bm --to 65 -j LOG --log-prefix "SIP Notify "
# Define the scan rules - works with any protocol (ie create a different
INPUT chain rule for each protocol/port)
# There are several timers - arranged so you can burst a few packets in a
short time, but much smaller number allowed through in the long term
iptables -A SCAN_CHECK -m recent --set --name SCAN
iptables -A SCAN_CHECK -m recent --rcheck --name SCAN --seconds 600
--hitcount 20 -j LOG_SCANDROP
iptables -A SCAN_CHECK -m recent --rcheck --name SCAN --seconds 180
--hitcount 10 -j LOG_SCANDROP
iptables -A SCAN_CHECK -m recent --rcheck --name SCAN --seconds 60
--hitcount 5 -j LOG_SCANDROP
# This chain saves having to write separate logging rules for each drop
condition
iptables -A LOG_SCANDROP -j LOG --log-prefix "AIF:ScanDrop "
iptables -A LOG_SCANDROP -j DROP
# Add separate rules into the INPUT chain for each protocol
(tcp/udp/icmp/all) and each port or port range to be scan-protected
iptables -I INPUT 1 -p udp --dport 5060:5063 -i eth0 -m state --state NEW
-j SCAN_CHECK
#-------------------
On 12/11/2012, at 11:53 AM, Lonnie Abelbeck wrote:
> Recently David Kerr posted to the [Astlinux-devel] list the post below. I'm
> responding, with some questions, to the broader users list here...
>
> I want to add Asterisk SIP-TLS-Cert generation in the web interface, but
> while testing I've discovered the following:
>
> 1) For the server, only the asterisk.key + asterisk.crt (asterisk.pem)
> generated from ast_tls_cert seem required.
>
> 2) For the client, only the server's ca.crt seems required, and not even that
> if the client does not verify the server cert.
>
> There appears to be no working tlsverifyclient=[yes|no] in Asterisk, though
> it is in the code. Enabling tlsverifyclient causes a segfault when a TLS
> client tries to connect.
>
> This issue is unresolved, but still open for over a year ago:
> https://issues.asterisk.org/jira/browse/ASTERISK-17856
>
> Are client certificates not supported in most SIP clients ?
>
> It seems the ast_tls_cert script generation of client certificates has no
> purpose.
>
> So, is ca.crt and asterisk.key + asterisk.crt (asterisk.pem) all that is
> needed to be generated via the web interface for SIP TLS ?
>
>
> Finally, it seems to me SIP TLS/SRTP does not solve the drive-by SIP
> brute-force bots without client certificate support. Am I thinking correctly?
>
> Edit: Ahhh, before sending this email, I confirmed that if the CA CommonName
> is set to pbx2.priv.abelbeck.com (not the IP 10.10.50.61) and then try to
> connect via 10.10.50.61 the TLS fails. I suppose that is a hurdle by setting
> the CommonName to a DNS name rather than an IP address.
>
> Lonnie
>
> PS: It looks like we should also set the subjectAltName object in the CA
> certificate as we do for IPsec Certificates...
>
> SIP TLS certificates should be verified according to RFC 5922
> https://issues.asterisk.org/jira/browse/ASTERISK-17719
>
>
> On Oct 7, 2012, at 9:47 AM, David Kerr wrote:
>
>> This week I tried playing with TLS and SRTP for the first time. Following
>> instructions I found at http://www.voip-info.org/wiki/view/SIP+TLS I was
>> quickly able to create the necessary certificate on Astlinux and enable TLS
>> in sip.conf. Then it was a simple case of setting transport=tls and
>> encryption=yes in the settings for one of my extensions to turn on both TLS
>> and SRTP. It worked without a problem (I used Arcobits Softphone on iOS as
>> the client device to test with).
>>
>> The reason I bring this up here is that the process of certificate creation
>> (at the voip-info wiki) has me create a self signed certificate, and it
>> looks awfully similar to the process that the Astlinux web interface goes
>> through to create a IPSec certificate -- the distinguished name section of
>> the Prefs tab holds all the info that I needed to create the certificate.
>> So, I'm wondering if it makes sense for the web interface to offer a way to
>> create the asterisk TLS certificate?
>>
>> Maybe create a new tab "Certificates" or whatever... move the distinguished
>> names fields here from Prefs, and the certificate creation actions from
>> IPSec / OpenVPN pages so that there is one place to manage & create server
>> certificates, and maybe list any client credentials (though I think creation
>> of those should stay on the IPSec / OpenVPN pages?)
>>
>> Does it makes sense to have only the one server certificate shared by
>> IPSec/OpenVPN/AsteriskTLS? Or at least ensure that the same distinguished
>> name is used? Or should they be separate and different? I'm not a security
>> person so don't know the answers to this.
>>
>> David.
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_nov
> _______________________________________________
> Astlinux-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to
> [email protected].
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
Astlinux-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to
[email protected].
