Toll fraud on poorly protected Asterisk servers seems to have mushroomed in the last 12 months. I constantly see evidence of scanning and brute force password guessing attempts on port 5060 of many different servers and PBX's.
If you operate a Trixbox or any Asterisk based PBX then you urgently need to review how secure it is and make sure you have not left any gaps in your defences. Failure to do so could leave you with an astronomical phone bill and very little, if any, redress.
Learn about the vulnerabilities and how to protect your Asterisk based PBX by reading my three part article:
How secure is your Asterisk PBX? Part 1
How secure is your Asterisk PBX? Part 2
How secure is your Asterisk PBX? Part 3
If you find the articles useful, please pass the link on.
Friday 10 December 2010
Friday 28 May 2010
Caller ID in SIP and Asterisk - Part 2
Caller ID, ANI, PAI, RPI, Privacy - what Asterisk does
I didn't plan on writing a "Part 2" to this article, but since nobody has posted any answers to my questions in Part 1, I had no option other than to test it for myself. In some ways, the answers are quite simple, but there are some subtle details that are not at all intuitive.
P-Asserted-Identity
First, what does Asterisk do when it receives a P-Asserted-Identity header. The answer is an unqualified nothing! As far as I could ascertain, it ignores it totally no matter what settings you use for "trustrpid" or "sendrpid". It does not copy it from an inbound call leg to an outbound call leg for a bridged SIP-to-SIP call.
Remote-Party-ID
Next, what about the Remote-Party-ID header? Well, if you have set "sendrpid=yes" in the settings for the destination peer in sip.conf then Asterisk will always add an RPI header. Here is a typical example:
Remote-Party-ID: "Johns Linksys" <sip:1001@192.168.1.15>;privacy=off;screen=no
The name "Johns Linksys" and the number, 1001, were taken from the From header of the inbound call leg. The IP address 192.168.1.15 is the IP of the Asterisk server, but can be over-ridden using the "fromdomain" parameter in the definition of the destination peer in sip.conf.
If you set "trustrpid=yes" in the definition of the source peer in sip.conf, then Asterisk will use the number from the RPI header in the request it received on the inbound call leg.
Privacy
Asterisk respects the privacy setting in the RPI header it receives (if there is an RPI header in the request) irrespective of any setting for "trustrpid". However, I have not found a way to tell Asterisk to change the privacy setting for a call it is bridging. Asterisk ignores the PAI Privacy header if the inbound call leg includes one.
<1001@192.168.1.15>
We're moving!Blogspot has been a great way to start blogging, but it has limitations. We've just completed a brand new annex to the smartvox web site called the Smartvox Knowledgebase - it is a combined blog plus a complete archive of all the blogs and VoIP articles I've written in the last few years. Please visit the new Smartvox Knowledgebase at:http://kb.smartvox.co.uk/. To read the latest revision of this article on Caller ID in SIP and Asterisk at the new site, follow this link: http://kb.smartvox.co.uk/asterisk/how-it-works/caller-id-in-sip-and-asterisk-part-2 |
I didn't plan on writing a "Part 2" to this article, but since nobody has posted any answers to my questions in Part 1, I had no option other than to test it for myself. In some ways, the answers are quite simple, but there are some subtle details that are not at all intuitive.
P-Asserted-Identity
First, what does Asterisk do when it receives a P-Asserted-Identity header. The answer is an unqualified nothing! As far as I could ascertain, it ignores it totally no matter what settings you use for "trustrpid" or "sendrpid". It does not copy it from an inbound call leg to an outbound call leg for a bridged SIP-to-SIP call.
Remote-Party-ID
Next, what about the Remote-Party-ID header? Well, if you have set "sendrpid=yes" in the settings for the destination peer in sip.conf then Asterisk will always add an RPI header. Here is a typical example:
Remote-Party-ID: "Johns Linksys" <sip:1001@192.168.1.15>;privacy=off;screen=no
The name "Johns Linksys" and the number, 1001, were taken from the From header of the inbound call leg. The IP address 192.168.1.15 is the IP of the Asterisk server, but can be over-ridden using the "fromdomain" parameter in the definition of the destination peer in sip.conf.
If you set "trustrpid=yes" in the definition of the source peer in sip.conf, then Asterisk will use the number from the RPI header in the request it received on the inbound call leg.
Privacy
Asterisk respects the privacy setting in the RPI header it receives (if there is an RPI header in the request) irrespective of any setting for "trustrpid". However, I have not found a way to tell Asterisk to change the privacy setting for a call it is bridging. Asterisk ignores the PAI Privacy header if the inbound call leg includes one.
<1001@192.168.1.15>
Tuesday 20 April 2010
Caller ID in SIP and Asterisk - Part 1
Caller ID, ANI, PAI, RPI, Privacy - can Asterisk cope?
Equipment receiving calls, whether a humble handset or a sophisticated Call centre ACD system, likes to know the identity of the caller. It may simply display the caller's number on an LCD display, look it up in a directory so the caller's name can be displayed or pre-populate a screen with information about the caller recovered from a database. However, the network also needs to know the caller's identity because it may be important for billing or to notify the emergency services of the caller's location.
In the UK, a caller may choose to block their ID so it is not visible to the called party by prefixing the dialed number with 141. However, this must not interfere with the more serious network requirements like billing or 999 call location. To accommodate both requirements, telephony signalling protocols tend to use two different pieces of data - a display ID that can optionally be blocked and an asserted ID or ANI that cannot. Protocols such as ISDN also include single bit privacy flags that show if the ID should be hidden.
The SIP protocol also has elements that allow for all the caller ID requirements. The From header provides basic caller ID data but it is too easily modified, blocked or spoofed to be of use to the network. Alongside this, the SIP protocol was extended to support the use of the Remote-Party-Id (RPI) header which should be added to an Invite by the first server within the trusted network cloud. It is described in an IETF memo:
http://tools.ietf.org/id/draft-ietf-sip-privacy-04.txt
The RPI header is added by one of the network servers so it should provide a much more reliable and trustworthy identification than the From header which can be set by users at the client device. The IETF memo also makes provision for the inclusion of certain tag values on the RPI header: "privacy" indicates to what extent the ID should be hidden and "screen" indicates what level of trust the network associates with the Remote-Party-ID information.
Another approach is described in RFC 3325. It explains the requirements for provision of an authenticated caller ID within a trusted network using the P-Asserted-Identity (PAI) header to convey the authenticated identity of a caller along with a separate Privacy header to show if this data must be hidden.
Decisions about adding or removing these ID headers depend partly on whether the call is entering or leaving your own infrastructure cloud and whether the remote peer or UA is trusted or not. If necessary, servers must use authentication challenges to ensure that a remote device can be trusted and only then should they add a P-Asserted-Identity header. When a request is sent to an untrusted device, it is necessary first to delete any such headers.
What control is provided within Asterisk?
Regrettably, all I have here are questions. Lots of questions and very few answers. Lets start with some basic facts about the configuration settings available in sip.conf:
Asterisk has two parameters for controlling handling of Remote-Party-Id as follows:
sendrpid=yes¦no : If an RPI header should be sent to the peer
trustrpid=yes¦no : If the RPI from this peer can be trusted
However, I am not sure what these parameters mean in practice. For example, will Asterisk automatically add an RPI header when sendrpid is set to "yes" or will it remove the header when set to "no". When I get time I will do some testing to see how it actually behaves.
To see the results of my testing, take a look at Part 2.
How does Asterisk handle caller ID when bridging calls from SIP to ISDN? For example, does it automatically populate the ANI and other caller ID fields using data sent in the RPI and From headers? If so, does this behaviour depend on the setting of trustrpid?
Areas where Asterisk seems to be very weak include:
1. The handling of P-Asserted-Identity. The only control I am aware of is the ability to add a PAI header (and a Privacy header) using the SIPAddHeader() function. Why doesn't Asterisk have a SIPDeleteHeader() function?
2. Access to the Privacy settings of ISDN calls. You can see the setting using the pri debug command at the CLI, but there seems to be no way of accessing the data within the dial plan.
We're moving!Blogspot has been a great way to start blogging, but it has limitations. We've just completed a brand new annex to the smartvox web site called the Smartvox Knowledgebase - it is a combined blog plus a complete archive of all the blogs and VoIP articles I've written in the last few years. Please visit the new Smartvox Knowledgebase at:http://kb.smartvox.co.uk/. To read the latest revision of this article on Caller ID in SIP and Asterisk at the new site, follow this link: http://kb.smartvox.co.uk/asterisk/how-it-works/caller-id-in-sip-and-asterisk-part-1 |
Equipment receiving calls, whether a humble handset or a sophisticated Call centre ACD system, likes to know the identity of the caller. It may simply display the caller's number on an LCD display, look it up in a directory so the caller's name can be displayed or pre-populate a screen with information about the caller recovered from a database. However, the network also needs to know the caller's identity because it may be important for billing or to notify the emergency services of the caller's location.
In the UK, a caller may choose to block their ID so it is not visible to the called party by prefixing the dialed number with 141. However, this must not interfere with the more serious network requirements like billing or 999 call location. To accommodate both requirements, telephony signalling protocols tend to use two different pieces of data - a display ID that can optionally be blocked and an asserted ID or ANI that cannot. Protocols such as ISDN also include single bit privacy flags that show if the ID should be hidden.
The SIP protocol also has elements that allow for all the caller ID requirements. The From header provides basic caller ID data but it is too easily modified, blocked or spoofed to be of use to the network. Alongside this, the SIP protocol was extended to support the use of the Remote-Party-Id (RPI) header which should be added to an Invite by the first server within the trusted network cloud. It is described in an IETF memo:
http://tools.ietf.org/id/draft-ietf-sip-privacy-04.txt
The RPI header is added by one of the network servers so it should provide a much more reliable and trustworthy identification than the From header which can be set by users at the client device. The IETF memo also makes provision for the inclusion of certain tag values on the RPI header: "privacy" indicates to what extent the ID should be hidden and "screen" indicates what level of trust the network associates with the Remote-Party-ID information.
Another approach is described in RFC 3325. It explains the requirements for provision of an authenticated caller ID within a trusted network using the P-Asserted-Identity (PAI) header to convey the authenticated identity of a caller along with a separate Privacy header to show if this data must be hidden.
Decisions about adding or removing these ID headers depend partly on whether the call is entering or leaving your own infrastructure cloud and whether the remote peer or UA is trusted or not. If necessary, servers must use authentication challenges to ensure that a remote device can be trusted and only then should they add a P-Asserted-Identity header. When a request is sent to an untrusted device, it is necessary first to delete any such headers.
What control is provided within Asterisk?
Regrettably, all I have here are questions. Lots of questions and very few answers. Lets start with some basic facts about the configuration settings available in sip.conf:
Asterisk has two parameters for controlling handling of Remote-Party-Id as follows:
sendrpid=yes¦no : If an RPI header should be sent to the peer
trustrpid=yes¦no : If the RPI from this peer can be trusted
However, I am not sure what these parameters mean in practice. For example, will Asterisk automatically add an RPI header when sendrpid is set to "yes" or will it remove the header when set to "no". When I get time I will do some testing to see how it actually behaves.
To see the results of my testing, take a look at Part 2.
How does Asterisk handle caller ID when bridging calls from SIP to ISDN? For example, does it automatically populate the ANI and other caller ID fields using data sent in the RPI and From headers? If so, does this behaviour depend on the setting of trustrpid?
Areas where Asterisk seems to be very weak include:
1. The handling of P-Asserted-Identity. The only control I am aware of is the ability to add a PAI header (and a Privacy header) using the SIPAddHeader() function. Why doesn't Asterisk have a SIPDeleteHeader() function?
2. Access to the Privacy settings of ISDN calls. You can see the setting using the pri debug command at the CLI, but there seems to be no way of accessing the data within the dial plan.
Subscribe to:
Posts (Atom)
