Hi Reza, Thanks for sharing your solution. It reminds me of an SMTP tar pit.
While there's no arguing with your first-hand observations of reduced deadlocks and system load, I wonder if this reduces the impact of scripted/brute force attacks but creates another risk. If a buffoon can connect and cause your system to play screaming monkeys, could they not make hundreds or thousands of calls and cause a serious load problem on the system? The calls won't reach a proper remote termination of course, but if mere denial of service was the goal, could this be an issue? I'm not administering public-facing Asterisk boxes so maybe I'm overlooking something obvious. The issue could be possibly mitigated by sip call-limit or something. If it ever became a problem, I'm sure there's a way to reduce the amount of resources used in the buffoon context, like giving Ringing() (which doesn't send audio if I'm right) for a loooong time then a HangUp(). As you say, the malicious scripts criteria for success is logging in, not necessarily completing a call. I was also reminded of this quote: “The green reed which bends in the wind is stronger than the mighty oak which breaks in a storm.” ― Confucius Thanks again for contributing, Dave On 29 July 2015 at 16:42, Reza - Voipernetics <[email protected]> wrote: > Contrary to advise and suggestions from many professionals in the industry > per Brute Force attacks, firewalls, log monitoring for brute registrations, > increased CPU usage due to brute force, my experience shows that a > "controlled form of anarchy, keeping things simple, appears to be the best > strategy. > > Unlike rejecting and banning IPs, which still invokes bandwidth usage and > cpu usage, this is what I have done: > > a) Have a separate context exclusively for unauthorized calls. > b) Allow all fake registrations to think they have registered (they no > longer pound with brute force if they think they got in) > c) Send ALL the calls for fake registrations (who think they logged in) > into a "SCREAMING MONKEYS" context. > > My observation invoking these simple techniques has resulted into zero > dead locks on clients machines and production machines that get hammered on > a regular basis, running different versions of Asterisk. > > Yes, ideally you would want to have an SBC but for those of you who do not > have the knowledge or resources for SBC, the above steps per our experience > has been rock solid stable. Our technical support requests for all our > installations across the globe, as gone done from few calls per day, to > zero calls in the last 30 days. > > Technical: > > a) Have a separate context exclusively for unauthorized calls. > I call this context "MONKEYS", you could choose "BUFFOONS" if you wanted. > > b) Allow all fake registrations to think they have registered (they no > longer pound with brute force if they think they got in). That is do the > following: > For sip.conf file, edit "default" context which looks like "[default]" > to "[MONKEYS]" or "[BUFFOONS]". > context=MONKEYS > allowguest=yes > ;authfailureevents=no (make sure this is commented) > alwaysauthreject = yes > > > c) Send ALL the calls for fake registrations (who think they logged in) > into a "SCREAMING MONKEYS" context. > That is modify the extensions file "extensions.conf" and insert the > following: > [MONKEYS] > exten => _X.,1,NoOp(Thugs, Monkeys and Buffons are attempting to dial > in) > exten => _X.,n,NoOp(======================================) > exten => _X.,n,NoOp(BUFFOONS IP ADDRESS: ${CHANNEL(recvip)}. This > actually shows you the IP address of the caller) > exten => _X.,n,NoOp(Buffoon tried to call: ${EXTEN}. This is for > your records what number he actually dialed) > exten => _X.,n,NoOp(======================================) > exten => _X.,n,Answer > exten => _X.,n,Playback(tt-monkeys) > exten => _X.,n,Wait(100) > exten => _X.,n,Hangup > > FYI, all default asterisk distribution comes with a sound file which is > the sound of screaming monkeys... and that file is " tt-monkeys " > > For those of you who do not have an SBC (as with close to 100% of our > clients), the above simple techniques has been superb. In a brute force > attack, using stress testing software such as SIPviscious or other scripts, > the objective of the idiot is to try to hack into your server for the > purpose of toll fraud. So in the above scenario - rather than your server > having to manage and block thousands and thousands of registration attempts > in seconds, or responding to a "Failed authorization", which further > provokes software like SIPViscious to do more brute attempts, it "thinks" > it has registered successfully, and starts attempting calls to expensive > destinations, eliminating another attempt for 10K retries. In their > attempt, all they hear is screaming monkeys. > > Leaving SBC's aside, would like to hear from others, what simple steps you > may have taken to rid these attacks. > No... FAIL2BAN does not help in a massive DDOS attack, even if you have > everything perfect. > > Cheers! > Reza. > > -- > FOUNDER & SR. TELECOM ANALYST > VOIPERNETICS COMMUNICATIONS > TEL: 647-847-2287 x2016 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
