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. A serious FreePBX vulnerability has been reported. Update your Framework Module immediately. Click here for details.
  4. Critical FreePBX vulnerability! Update your server immediately. Details here.

ALERT please report hacks

Discussion in 'Open Discussion' started by anonymous, Sep 16, 2008.

  1. angoyr Guru

    The hack attempts continues. I need to know what parameter or variable I have to set in order to slow down the failed attempts.
    I have findtime in fail2ban set to 600 but that is not doing the trick. Below is an excerpt from a email I received a few moments ago from fail2ban.

    Code:
    The IP 196.7.30.202 has just been banned by Fail2Ban after
    [COLOR=Red][B]11761 attempts[/B][/COLOR] against ASTERISK at approximately 14:33 :07 EST.
    
    Here is more information about 196.7.30.202:
    I saw somewhere where you can delay the response of a failed attempt on an IAX connection. Can someone tell me how to do the same for SIP?

    I have the permit / deny mask set for each extension, thanks to the great security tips from Ward. I need to slow them down enough, hopefully they will become frustrated and go somewhere else, like the LIME GREEN folks.

    Thanks.

    Robin
  2. wardmundy Nerd Uno

    Have you updated Fail2Ban? That's a lot of attempts in 3-5 seconds.
  3. angoyr Guru

    Ward,

    I hope I have the latest fail2ban from update-* earlier this year.

    I have findtime=600, I assume that's in seconds which I hope is 10 mins. Sorry if I misled anyone, the attempts happened in about 10 mins.

    Thanks,

    Robin
  4. ronw Guru

    Unless you have remote extensions or allow anonymous sip, remove the port forward on 5060 in your router and these attempts will never make it to your pbx.
  5. The attack on my system continues as well. I know it's a scam to get account numbers because a bank called me today wanting to know why I was asking for their customer's information. I told the bank rep about the breach and sent her a call record of all the people in her area code that were called through my system (about 104). She did say that she had reported it to their sheriff. I, in turn, have reported it to the computer crimes division of our county police so I also have a case number if the sheriff from the other jurisdiction calls my local police.

    I will say this: I wouldn't have found the hack as fast if it hadn't been for a prospective victim calling me back to ask about the call.

    In the meantime, since I do have remote extensions, I had to put a firewall rule in effect to block the attacking IP address. I had already hardened my system earlier with address restriction in freePBX, but I decided to not to burden my PBiF system with it and block at the firewall.
  6. angoyr Guru

    Hello All,

    I run A2Billing with remote users and pin-less calling service. I also have remote PBX extensions. I don't think it's practical to block port 5060. Now, since that's not an option, I'm looking for a way to delay the authentication failure response to somewhere between 10 to 30 seconds. Is there such a setting for SIP? I would appreciate some help on this.

    troycarpenter,

    I'm really sorry about your break in. I just hope we can find a way to bring those crooks to justice. Unfortunately most of them are from far away lands and there isn't much we can do.
    A few hours ago someone from South Africa made over 11 thousand attempts in less than ten minutes on one of my servers before fail2ban banned him. What we need is a daemon that would monitor login attempts against a list of IP addresses we have defined somewhere in the system. It would run a whois query at the first attempt and block them instantly if they are from an undefined region. Most of the attempts on my system are from Poland, China, Egypt and recently England and now South Africa.

    Maybe someone already has that solution that they are willing to share.

    Good luck,

    Robin.
  7. tel0p Guru

    won't this block SIP based service providers?
  8. ronw Guru

    It will block any incoming attempt on port 5060 from any sip provider that you do not have a registration string. I have three different sip providers, but do not have any ports forwarded in my router. I have no issues making or receiving sip calls.

    You only need ports forwarded if you have remote extensions or you elect to receive anonymous sip requests.
  9. tel0p Guru

    ahh 'duhh' the elusive register string! thanks
  10. wayhigh New Member

    If there's enough interest, I may be willing to release the alpha code for the blocking portion of AsteRBL.

    The one caveat though is that the most effective RBL at the moment is the all foreign ip's one. It effectively blocks 99% or more of all voip attacks by stopping foreign addresses. I'll be breaking out the foreign ip's by country and NIC in the future but it's not there yet.

    The code itself is definitely functional and it hasn't shown any sign of crashing my systems after being left running for about 3 weeks straight.
  11. peanuts New Member

    Unless you have offsite or x-nat connections, why would you need a black list? Just permit your trunk providers address and block all others. I would think a blacklist would be someone proc intensive as it has deny all the rbl numbers before it gets to a permit. Maybe it's not as bad as I think though. If you do have x-nat connections and they have a static then permit the statics as well. If you have x-nat connections and they do not have a static, have them use dyn-dns, or no-ip and then do a reverse lookup. I'd write the ip to domain locally though for faster lookup. In the end I'm a VOIP newb compared to most here and trying to learn as I go I guess.
  12. thunderheart New Member

    Suspicious External SIP calls

    I got 4 "from SIP external" entries in my call log today. That is unusual because nobody should be attempting to reach us that way. Could someone take a look at the following log entries and tell me how alarmed I should be and what I should do about it (if anything). Could just be a mistaken call attempt but the IP address was different each time. It looks like all the attempts terminated in a system recording (Congestion or No Service) but I blocked all my SIP and DUNDI pinholes until I hear from the gurus here.

    This box was originally installed from the PIAF 1.2 ISO but was update-*'d (most recently) on 03/19/09 which I think corresponds to a security alert Ward put out. It is behind a router with NAT.

    Here is a relevant snippet from var/log/asterisk/full:

    [2010-01-08 22:33:34] VERBOSE[17715] logger.c: == Spawn extension (from-sip-external, s, 3) exited non-zero on 'SIP/91.121.173.176-08b0cab8'
    [2010-01-08 22:33:42] WARNING[3099] chan_sip.c: Maximum retries exceeded on transmission 552497625-02063381451-2095695574@91.121.173.176 for seqno 102 (Criti
    cal Response)
    [2010-01-09 00:00:02] VERBOSE[18008] logger.c: == Parsing '/etc/asterisk/manager.conf': [2010-01-09 00:00:02] VERBOSE[18008] logger.c: Found
    [2010-01-09 00:00:02] VERBOSE[18008] logger.c: == Parsing '/etc/asterisk/manager_additional.conf': [2010-01-09 00:00:02] VERBOSE[18008] logger.c: Found
    [2010-01-09 00:00:02] VERBOSE[18008] logger.c: == Parsing '/etc/asterisk/manager_custom.conf': [2010-01-09 00:00:02] VERBOSE[18008] logger.c: Found
    [2010-01-09 00:00:02] VERBOSE[18008] logger.c: == Manager 'admin' logged on from 127.0.0.1
    [2010-01-09 00:00:02] VERBOSE[18008] logger.c: == Manager 'admin' logged off from 127.0.0.1
    [2010-01-09 01:52:40] NOTICE[3099] chan_sip.c: Peer '6812' is now UNREACHABLE! Last qualify: 107
    [2010-01-09 01:53:18] NOTICE[3099] chan_sip.c: Peer '6812' is now Reachable. (208ms / 2000ms)
    [2010-01-09 02:50:31] VERBOSE[18636] logger.c: -- Executing [011441844208220@from-sip-external:1] NoOp("SIP/64.62.243.6-08b0cab8", "Received incoming SIP
    connection from unknown peer to 011441844208220") in new stack
    [2010-01-09 02:50:31] VERBOSE[18636] logger.c: -- Executing [011441844208220@from-sip-external:2] Set("SIP/64.62.243.6-08b0cab8", "DID=011441844208220")
    in new stack
    [2010-01-09 02:50:31] VERBOSE[18636] logger.c: -- Executing [011441844208220@from-sip-external:3] Goto("SIP/64.62.243.6-08b0cab8", "s|1") in new stack
    [2010-01-09 02:50:31] VERBOSE[18636] logger.c: -- Goto (from-sip-external,s,1)
    [2010-01-09 02:50:31] VERBOSE[18636] logger.c: -- Executing [s@from-sip-external:1] GotoIf("SIP/64.62.243.6-08b0cab8", "0?from-trunk|011441844208220|1")
    in new stack
    [2010-01-09 02:50:31] VERBOSE[18636] logger.c: -- Executing [s@from-sip-external:2] Set("SIP/64.62.243.6-08b0cab8", "TIMEOUT(absolute)=15") in new stack
    [2010-01-09 02:50:31] VERBOSE[18636] logger.c: -- Channel will hangup at 2010-01-09 07:50:46 UTC.
    [2010-01-09 02:50:31] VERBOSE[18636] logger.c: -- Executing [s@from-sip-external:3] Answer("SIP/64.62.243.6-08b0cab8", "") in new stack
    [2010-01-09 02:50:31] VERBOSE[18636] logger.c: -- Executing [s@from-sip-external:4] Wait("SIP/64.62.243.6-08b0cab8", "2") in new stack
    [2010-01-09 02:50:33] VERBOSE[18636] logger.c: -- Executing [s@from-sip-external:5] Playback("SIP/64.62.243.6-08b0cab8", "ss-noservice") in new stack
    [2010-01-09 02:50:33] VERBOSE[18636] logger.c: -- <SIP/64.62.243.6-08b0cab8> Playing 'ss-noservice' (language 'en')
    [2010-01-09 02:50:38] VERBOSE[18636] logger.c: -- Executing [s@from-sip-external:6] PlayTones("SIP/64.62.243.6-08b0cab8", "congestion") in new stack
    [2010-01-09 02:50:38] VERBOSE[18636] logger.c: -- Executing [s@from-sip-external:7] Congestion("SIP/64.62.243.6-08b0cab8", "5") in new stack
    [2010-01-09 02:50:43] VERBOSE[18636] logger.c: == Spawn extension (from-sip-external, s, 7) exited non-zero on 'SIP/64.62.243.6-08b0cab8'
    [2010-01-09 02:50:43] VERBOSE[18636] logger.c: -- Executing [h@from-sip-external:1] NoOp("SIP/64.62.243.6-08b0cab8", "Hangup") in new stack
    [2010-01-09 02:50:43] VERBOSE[18636] logger.c: -- Executing [h@from-sip-external:2] Set("SIP/64.62.243.6-08b0cab8", "DID=s") in new stack
    [2010-01-09 02:50:43] VERBOSE[18636] logger.c: -- Executing [h@from-sip-external:3] Goto("SIP/64.62.243.6-08b0cab8", "s|1") in new stack
    [2010-01-09 02:50:43] VERBOSE[18636] logger.c: -- Goto (from-sip-external,s,1)
    [2010-01-09 02:50:43] VERBOSE[18636] logger.c: -- Executing [s@from-sip-external:1] GotoIf("SIP/64.62.243.6-08b0cab8", "0?from-trunk|s|1") in new stack
    [2010-01-09 02:50:43] VERBOSE[18636] logger.c: -- Executing [s@from-sip-external:2] Set("SIP/64.62.243.6-08b0cab8", "TIMEOUT(absolute)=15") in new stack
    [2010-01-09 02:50:43] VERBOSE[18636] logger.c: -- Channel will hangup at 2010-01-09 07:50:58 UTC.
    [2010-01-09 02:50:43] VERBOSE[18636] logger.c: -- Executing [s@from-sip-external:3] Answer("SIP/64.62.243.6-08b0cab8", "") in new stack
    [2010-01-09 02:50:43] VERBOSE[18636] logger.c: == Spawn extension (from-sip-external, s, 3) exited non-zero on 'SIP/64.62.243.6-08b0cab8'
    [2010-01-09 02:50:51] WARNING[3099] chan_sip.c: Maximum retries exceeded on transmission 1069601654-00195426032-1973086489@64.62.243.6 for seqno 102 (Critica
    l Response)
    [2010-01-09 04:02:26] VERBOSE[3093] logger.c: -- Remote UNIX connection

    There is more and I can provide if helpful.

    Thanks,

    Dallas
  13. jmullinix Guru

    Dallas,

    This appears to be coming in on the as anonymous sip. If it were the Dundi side, this would be IAX2 instead of Sip.

    What I would do is set up an Any/Any inbound route that goes to hang up. Right now, I suspect that you don't have an Any/Any inbound route and Asterisk handles incoming calls to unknown DID's with a Zapateller and an ss-noservice. Once the hacker hears this, he suspects an Asterisk box and starts looking at error messages to see if he can determine the version and get in through a vulnerability.

    Also, setting an Any/Any route to hangup will get the call off of your box a lot quicker.
  14. jroper Guru

    Hi

    I too would strongly advise this approach.

    Set up the numbers correctly in inbound routes, that you own, and anything else send them straight to hangup.

    So create an entry in inbound routes that is either _. in the DID field or just left blank and in either case set to hangup.

    This approach can also be used with allow anon sip calls as well.

    The Sorry Not in service, not only tells the hacker it's Asterisk, but there is a good likelihood that this a FreePBX based system, so the potential hacker knows which toolbox to reach for.

    With this approach, anyone can ring you, provided they know your number, which is just like any other phone, and gives the advantage that anyone can ring you free of charge by publishing a DID and SIP address, just like John does in his signature:-

    sip://17066323343@qth.cohutta.org

    Joe
  15. mstults New Member

    I had one

    I had one yesterday as well. The connection came from an Indian ip. I don't really know what they did but I was in the process of installing some dahdi extensions and they called on that did not have a phone connected. It just showed ringing for 454 minutes. I haven't had time to study the log thoroughly.
  16. jeffmac Guru

    I, too, have seen several attempts in the past few days.

    I have taken John and Joe's advice and added an Any Did/Any Callerid route to my inbound routes with a Hangup destination.

    Hopefully that will minimize the risk.

    Jeff
  17. dswartz Guru

    Huh, I just checked my logs, and there were 10 attempts in the last week, none from US IP addresses :( I get both DIDs from the same provider (one of two SIP servers, so I think I'll just lock the firewall down to those two IPs for port 5060.
  18. evp New Member

    Hi I have seen quite a few of these over the last 2 or 3 days, 15 in the last 24hrs.

    I will be preparing the any/any route, not sure whether I should live allow sip anonymous to no or yes?
  19. jroper Guru

    Allow Yes; if no, then the message will play, thus telling the caller what sort of platform you are using.

    Joe
  20. evp New Member

    great thanks so much..

Share This Page