4 thoughts on - Asterisk Bugs Make A Right Mess Of RTP
This specific issue exists in a lot of different implementations and devices. Unfortunately there’s nothing within SDP that guarantees or provides what the source of media should be for most things. You can guess that where you are sending (what you are told in the SDP) is the correct source, but in the case of NAT that isn’t true. Using SRTP is one way to work around this as mentioned on the disclosure[1] from the reporter. I’m sure the strict RTP implementation will evolve even further, but we also have to ensure that we don’t just start blocking all RTP so people can’t actually place calls. It’s certainly a challenge.
This is one of the things that WebRTC got right – information is conveyed that allows you to verify that the sender of media is who you expect.
As Josh mentioned this is an issue with RTP and the SDP and when customers use NAT you need a way to figure out what their external RTP IP is. One option is to use IPv6 so the IP in the SDP is the one and only IP the media should be coming from. Another option is to increase the range of RTP ports in use. By default asterisk uses ports 10,000 to 20,000. You can change that to say use 20,000 to 30,0000 or better yet use 10,000 to 20,0000
widening the range of ports being used.
Another point to keep in mind is they have to hit the same ports that you are using. Say for instance you have 1000 calls on a box that’s 1000 UDP
ports being used. If you use a spread of 20,000 ports (and they know this)
they have a 1 in 20 chances of hitting a port that you want. Also if you are using strictrtp=yes that means they need to hit the box at the exact moment that the call is being set up. Even if they used say G711 that’s roughly 64kbit per second (let’s forget about the bits for the IP’s, timing etc.)) Now if they spray 5000 ports at once (since they need to hit every call as it is being set up) thats an extra 333 mbits per second of added your traffic. Your monitoring tool (if you don’t have one, get one) should pick up on it. One you see the ports being hit you can easily tweak your configs. IMHO It’s not different then needing to tweak your fw configs when getting hit with a DDOS attack.
I’m not quite sure what numbers you’re trying to quote here. I agree that Asterisk uses 10,000 to 20,000 by default.
What are you suggesting this can be changed to in order to increase the range?
4 thoughts on - Asterisk Bugs Make A Right Mess Of RTP
This specific issue exists in a lot of different implementations and devices. Unfortunately there’s nothing within SDP that guarantees or provides what the source of media should be for most things. You can guess that where you are sending (what you are told in the SDP) is the correct source, but in the case of NAT that isn’t true. Using SRTP is one way to work around this as mentioned on the disclosure[1] from the reporter. I’m sure the strict RTP implementation will evolve even further, but we also have to ensure that we don’t just start blocking all RTP so people can’t actually place calls. It’s certainly a challenge.
This is one of the things that WebRTC got right – information is conveyed that allows you to verify that the sender of media is who you expect.
[1]
https://github.com/EnableSecurity/advisories/tree/master/ES2017-04-asterisk-rtp-bleed
As Josh mentioned this is an issue with RTP and the SDP and when customers use NAT you need a way to figure out what their external RTP IP is. One option is to use IPv6 so the IP in the SDP is the one and only IP the media should be coming from. Another option is to increase the range of RTP ports in use. By default asterisk uses ports 10,000 to 20,000. You can change that to say use 20,000 to 30,0000 or better yet use 10,000 to 20,0000
widening the range of ports being used.
Another point to keep in mind is they have to hit the same ports that you are using. Say for instance you have 1000 calls on a box that’s 1000 UDP
ports being used. If you use a spread of 20,000 ports (and they know this)
they have a 1 in 20 chances of hitting a port that you want. Also if you are using strictrtp=yes that means they need to hit the box at the exact moment that the call is being set up. Even if they used say G711 that’s roughly 64kbit per second (let’s forget about the bits for the IP’s, timing etc.)) Now if they spray 5000 ports at once (since they need to hit every call as it is being set up) thats an extra 333 mbits per second of added your traffic. Your monitoring tool (if you don’t have one, get one) should pick up on it. One you see the ports being hit you can easily tweak your configs. IMHO It’s not different then needing to tweak your fw configs when getting hit with a DDOS attack.
I’m not quite sure what numbers you’re trying to quote here. I agree that Asterisk uses 10,000 to 20,000 by default.
What are you suggesting this can be changed to in order to increase the range?
Antony.
That is correct. have a look at rtp.conf.