Flooded inbound calls

Discussion in 'General' started by Telco, Aug 28, 2009.

  1. Telco

    Joined:
    Oct 4, 2007
    Messages:
    275
    Likes Received:
    0
    My system is being flooded by inbound calls from the following:

    Source: MichaelJackson
    Src Chanel: SIP/66.197.156.197-089659d0

    Is there anyway to block this on the elastix?

    I have read that this is a worm.

    There is no ph# to block, I turned on the anonymous rejection, but I guess because the name shows, it gets thru.
     
  2. Telco

    Joined:
    Oct 4, 2007
    Messages:
    275
    Likes Received:
    0
    Sorry here is the image. [​IMG]
     
  3. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    You (perhaps all of us) should have a catchall inbound route with no did or cid that sends all calls to the hangup context or perhaps more satisfyingly to michaeljackson@66.197.156.197 (you'll need a custom extension for that) ). (all recognised DID's still will work)

    Or deny the culprit host on your firewall,.

    Fail2ban might work also, as might adding

    alwaysauthreject=yes

    to /etc/asterisk/sip_custom.conf

    Looks like a new exploit to me, can you post your sip debug output

    (sip debug ip 66.197.156.197)

    for one of those calls, just for my edification.

    technically you should report this to:

    network:Abuse-Email:abuse@hostnoc.net
    network:Abuse-Phone:+1-570-343-8551

    (from the whois of this IP address)
    unfortunately nobody gives a damn anymore about who they host and what they allow, so my guess is you will be ignored


    dicko
     
  4. Patrick_elx

    Joined:
    Dec 14, 2008
    Messages:
    1,120
    Likes Received:
    0
    I'm receiving these calls also since yesterday, it was approximately once per hour.

    My catch all has the privacy mode activated then none of these calls reached my extensions.
    But since I blocked this ip in iptables.

    What is strange is that all these calls are all coming from the same IP. Strange that nobody shut downed this server already...
     
  5. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
  6. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    Interesting thread, that's why I asked for a SIP debug, I suspect it's a SIP header rewrite and we need to identify the underlying perpetrator.
     
  7. Patrick_elx

    Joined:
    Dec 14, 2008
    Messages:
    1,120
    Likes Received:
    0
    Does zapateller do anything for the caller using a purely SIP URI call?
    If it was going through a PSTN link I would assume that it will be considered, but on a SIP link, the SIP header will inform of the answering first then it will just be a tone..

    Would congestion not be better in that case?

    anyway, this IP is banned.
     
  8. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    Are you sure the originator is that 66.197.156.197 and it's not a rewrite?

    66.197.156.197 seems to be possibly a lowly apple machine (nmap -vv -p 1-65000 66.197.156.197) somewhere in hillbilly land (sorry Tennessee and South Carolina, but that's where that host is)

    [edit]
    of course if it doesn't actually come from that ip, one would have to go for a more expansive sip debug.
     
  9. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    And Yes congestion would be more adult, I just like messing with knuckle-draggers
     
  10. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    update:

    66.197.156.197

    seems to have disappeared from "the tubes", (maybe he didn't like us messing with him)
     
  11. Patrick_elx

    Joined:
    Dec 14, 2008
    Messages:
    1,120
    Likes Received:
    0
    No as I'm not flooding my log with sip ip debug normally..
    Can we trust the IP info in the channel name SIP/66.197.156.197-08ac6580? or is this one susceptible to spoofing?

    Code:
    -- Executing [4312297140@from-sip-external:1] NoOp("SIP/66.197.156.197-08ac6580", "Received incoming SIP connection from unknown peer to 4312297140") in new stack
    -- Executing [4312297140@from-sip-external:2] Set("SIP/66.197.156.197-08ac6580", "DID=4312297140") in new stack
    -- Executing [4312297140@from-sip-external:3] Goto("SIP/66.197.156.197-08ac6580", "s|1") in new stack
    If not, is there a way to force to log a sip debug for the invite only of anonymous sip call?
     
  12. Patrick_elx

    Joined:
    Dec 14, 2008
    Messages:
    1,120
    Likes Received:
    0
    Thank you for taking the time to contact the BurstNET Abuse Dept.
    BurstNET in no way condones any spam related activities, hacking, warez, pirating, or other related abuse on our network.
    BurstNET is one of the largest web hosting companies in the world, and unfortunately such activities will occur no matter how much preventive action we take against such.

    :angry:
     
  13. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    :) :)

    trust nothing! go with the force!
     
  14. Patrick_elx

    Joined:
    Dec 14, 2008
    Messages:
    1,120
    Likes Received:
    0

    Another answer... Fast response. Good for them, they are more reactive than I thought.

     
  15. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    See, they don't give a damn!! they don't enforce their "terms of service" and there is no way to get past their mail bots.

    Call the phone number and leave a message with a never to be heard voicemail service.

    :) :)

    [edit]
    I thusly redact

    a shame it took 4 days (assuming the aussies complained)!!
     
  16. Patrick_elx

    Joined:
    Dec 14, 2008
    Messages:
    1,120
    Likes Received:
    0
    but still, is the channel IP reported in the standard verbose asterisk log is the IP of the UDP packets or is it taken from the content of the SIP invite and then easily 'spoofable'?

    if the second, is there a way to record the invite packet only of anonymous call without filling the log with all the sip set debug ip?
     
  17. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    1
    From the ultimately negotiated invite, I believe, hence the vulnerability

    the SIP non RFC

    alwaysauthreject=yes

    largely fixes one vulnerability, this one seems a little cleverer, and I don't believe it will go away with one host "taken out".

    2

    Not an easy one, a well constructed grep filter or perhaps at a lower level a ethereal capture might help.

    If anyone can be more specific here I would appreciate input.

    on tenterhooks, (but always ready to cross swords,)

    dicko

    FWIW

    the host 66.197.156.197 (probably a virtual one hosted as previously identified) aka as jack, Brazilian or otherwise has been "interested" in mysql and VOIP on the internet (according to google) for five years now.
     
  18. Patrick_elx

    Joined:
    Dec 14, 2008
    Messages:
    1,120
    Likes Received:
    0
    but I still don't understand the goal of these calls. Is it just spam or does it harvest info for another later attack. If so, why calling many times the same pbx with the same scenario. One call would be enough to collect info.
     
  19. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    Me neither, but I have always maintained that these guys, whilst they might be many things, are rarely stupid. The Whirlpool site and others indicate that ip-chains is penetrable by something involved in the exploit, presumably not the IP that was denied by the firewall rule.
     

Share This Page