1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
  2. If you had a PIAF Forum account in the vBulletin days, log in with your old credentials. Otherwise, sign up again and we'll get you back in business as soon as we can.
  3. Guest: We think the problem with locked threads from long message subjects has been resolved. Post a link here if you still see a problem.
Cookies Welcome Back Long Message Subjects SOLVED

Asterisk IAX Security Alert

Discussion in 'Bug Reporting and Fixes' started by wardmundy, Sep 4, 2009.

Page 1 of 2

  1. wardmundy Nerd Uno

    Be aware that there's a new denial-of-service security alert on all Asterisk systems. If you only use IAX to interconnect servers or to connect to a service provider, THERE IS NO REASON TO HAVE PORT 4569 MAPPED TO YOUR ASTERISK SERVER FROM YOUR ROUTER! You do have a hardware-based firewall/router between your Asterisk server and the Internet, don't you? The IAX registration process between the servers will automatically create the IAX route much like what happens when you browse the Internet with http from behind a router.

    So... either upgrade Asterisk on your server or close down the UDP 4569 port mapping to avoid DOS attacks!

    Bulletin is attached...

    NOTE: If you upgrade your server, see this thread for important changes in FreePBX to get IAX working reliably again.

    Attached Files:

    wardmundy, Sep 4, 2009
    #1

  2. dswartz Guru

    ward, the above isn't quite right. if you are connecting to an ITSP, i agree. if you are connecting two IAX servers of your own, one of them has to have 4569 opened...
    dswartz, Sep 4, 2009
    #2

  3. wardmundy Nerd Uno

    Right you are. So at least one needs to be upgraded... the other guy's. ;)
    wardmundy, Sep 4, 2009
    #3

  4. jehowe Guru

    Thanks for the heads up Ward. Update-source safely updated my primary IAX machine from asterisk 1.4.21.2 to the latest (1.4.26.2) without fuss.
    jehowe, Sep 4, 2009
    #4

  5. dobbs New Member

    How did update-source bring you up to that version? Mine says Asterisk/Zaptel are frozen at Asterisk/Zaptel 1.4.21.2/1.4.12.1? Or did you take the "unsafe" DAHDI plunge? I can't as I'm running some Sangoma cards.
    dobbs, Sep 4, 2009
    #5

  6. jroper Guru

    In my experience, Sangoma cards have no issues with Dahdi.

    Joe
    jroper, Sep 5, 2009
    #6

  7. MyKroFt Guru

    So you guys are saying there is no hope ever of anything past 1.4.21.2 if running zaptel? This blows my whole interconnect right out of the water, I have to have the port open on the router......
    MyKroFt, Sep 5, 2009
    #7

  8. wardmundy Nerd Uno

    One solution. Add another upgraded box behind your router to grab the IAX traffic safely. And then route all the calls to your existing boxes from there. And, remember, you only have to have the IAX port open and rerouted to your Asterisk server on one end of the calls. So, for example, if you had a hub-and-spoke arrangement of servers, only the hub needs to be an upgraded box. All the rest can stay safely tucked behind hardware-based routers/firewalls with no port mapping for IAX to the individual servers.
    wardmundy, Sep 5, 2009
    #8

  9. MyKroFt Guru

    Wont this blow the DUNDi cloud setup out of the water as well? Does not this setup make outbound requests to other peers in the cloud, whos ports in firewalls need to be open to receive the query?

    Is there a way to force interconnect servers to use a non standard port # just for the interconnect links?
    MyKroFt, Sep 5, 2009
    #9

  10. jroper Guru

    Hi

    From the documentation, it would appear that a large number of "remote authenticated Sessions" needs to be created in order to do the denial of service.

    One imagines that these unauthenticated sessions are logged in asterisk, and if that is the case, then presumably a fail2ban rule could be created to drop the sessions before they get to asterisk, thus removing the problem.

    Joe
    jroper, Sep 5, 2009
    #10

  11. dodgly New Member

    update-source16 (Version 1.4.6 released on Date 100808.) complains that it hasn't been updated and dies.

    Are there still any legitimate concerns with Asterisk 1.6? I'm just on a testing box but would like to keep it updated for this security fix as I use IAX.

    Ward, I'm happy to help update or test new versions of update-source16, but alas the source is closed.

    Or is there an updated update-source16 that I'm not seeing?

    Thanks,

    --Lyle
    dodgly, Sep 5, 2009
    #11

  12. darmock PIAF Developer

    As it should. This was suspended until the source for 1.6 became more stable. The current 1.6.1 tree is becoming more stable however and this program should be coming back when 1.5 is released. For the moment your only alternative is to re-install piaf - 16. I am still updating the 1.6 load files to reflect the latest *STABLE* 1.6.1 source so you will need to be a little patient for this. I will make an announcement once it has been propagated thru PIAF space.

    Joe's suggestion about using fail2ban has some merit and I am currently experimenting with it and the exploit to see if this will work for the frozen version of Asterisk/Zaptel (aka Gold Standard)

    Hope this helps

    Tom
    darmock, Sep 5, 2009
    #12

  13. MyKroFt Guru

    I also forgot and woke up in the middle of the night because this was bothering me, but using hamachi or any vpn will stop this as well because the port does not need to be open.

    Dundi/iax tho is gonna be a different story....
    MyKroFt, Sep 5, 2009
    #13

  14. jehowe Guru

    After updating to 1.4.26.2 I have two separate IAX providers inbound did's failing with 'CHANUNAVAIL' responses. Will look at iax debug later, but for now routing over SIP resolves these inbound failures.

    A bit ironic isn't it :banghead:.
    jehowe, Sep 6, 2009
    #14

  15. jehowe Guru

    FYI- Digium introduced token validation with this update which none of my current providers supports, hence the 'chanunavail' they were receiving when attempting to route an inbound call. To disable this requirement and get things working again, I added two lines to the iax_custom.conf file:

    Code:
    calltokenoptional = 0.0.0.0/0.0.0.0
maxcallnumbers = 16382
    This of course, defeats the purpose of the upgrade entirely, but is what was required to get my inbound IAX calls flowing again. I really hope there can be a fail2ban solution. Tokens and the requirements for getting provider support are going to be messy.
    jehowe, Sep 7, 2009
    #15

  16. patrick_elx Guru

    patrick_elx, Sep 7, 2009
    #16

  17. Alex728 Guru

    I am planning to use IAX2 both for the trunks (FonicaVOIP) and to link to another server at another site so this could be an issue in the future

    but both the servers have static IPs, so is there any way of only allowing the known server IP through and refusing connections for anything else?
    Alex728, Sep 7, 2009
    #17

  18. jroper Guru

    Hi

    Yes. you can use IP tables, or you can use permit and deny statements.

    Joe
    jroper, Sep 7, 2009
    #18

  19. dswartz Guru

    sure, add a custom iptables rule for UDP/4569.
    dswartz, Sep 7, 2009
    #19

  20. MyKroFt Guru

    permit/deny would be easier if ips ever change in the future
    MyKroFt, Sep 7, 2009
    #20
Page 1 of 2

Share This Page