Send VoiceOps mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/voiceops
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of VoiceOps digest..."
Today's Topics:
1. Re: Main number fail-safe solution for small ITSP
(Carlos Alcantar)
2. Re: DDOS attacks against ITSPs (PE)
3. Re: DDOS attacks against ITSPs (Simon Woodhead)
4. Re: DDOS attacks against ITSPs (J. Oquendo)
----------------------------------------------------------------------
Message: 1
Date: Mon, 15 Oct 2012 06:50:40 +0000
From: Carlos Alcantar <[email protected]>
To: VoiceOps <[email protected]>
Subject: Re: [VoiceOps] Main number fail-safe solution for small ITSP
Message-ID: <cca10010.6b7e3%[email protected]>
Content-Type: text/plain; charset="us-ascii"
Have pri's or sip trunks from a totally different carrier for your support
lines.
Carlos Alcantar
Race Communications / Race Team Member
1325 Howard Ave. #604, Burlingame, CA. 94010
Phone: +1 415 376 3314 / [email protected] / http://www.race.com
From: Carlos Alvarez <[email protected]>
Date: Friday, October 12, 2012 10:25 AM
To: VoiceOps <[email protected]>
Subject: [VoiceOps] Main number fail-safe solution for small ITSP
I'm curious how other small VoIP providers handle having a fail-over for
their main (support) phone number in case their entire infrastructure is
unable to take calls. I know we all build in redundancy, but for the big
what-if scenario where nothing is available and the calls fail, you still
need to take your customer support calls.
We have one carrier who does PSTN failover, but they're far from our primary
or an ideal carrier for us. None of our major origination providers do
this.
--
Carlos Alvarez
TelEvolve
602-889-3003
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/voiceops/attachments/20121015/fcc9a3d1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5571 bytes
Desc: not available
URL:
<https://puck.nether.net/pipermail/voiceops/attachments/20121015/fcc9a3d1/attachment-0001.p7s>
------------------------------
Message: 2
Date: Mon, 15 Oct 2012 08:56:35 -0400
From: PE <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [VoiceOps] DDOS attacks against ITSPs
Message-ID:
<CAHm=Sa+USn+0HRDcYjxmw3KoqhU-uGgibth=fdchkctzq6s...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
This is an important topic. And whether you know it or not, your network
has, at some time I'm sure, been under fire, whether a DDoS, Registration
flood, or other. A true DDoS is obviously the hardest to deal with, though
the others can also cause harm. In my experience, a Registration flood is
the most common, and the signatures are generally:
1. Scan of your IP's
2. Attempt to register to any that reply to SIP
3. Registrations are usally to 4-digit extensions. I guess the attacker is
hoping to hit a PBX, not necesarily an ITSP
4. User-agent is usually "friendly-scanner" (i.. SipVicious)
5. Many come from international locations
Acme has some good documentation on the topic as well as best common
practices for configuration. Their ACLs are supposed to offload the
processing from the CPU (where the heavy lifting of SIP B2BUA is done) to
the interface. Of course, no interface can truly stop a flood that fills
the pipe.
So, what to do?
First, check your configs and do the most you can there. Next, if you have
the tools, keep an eye on registrations and overall bandwidth in and out of
your network and to specific interfaces. When you see an odd spike, dig
into it and block the sender, where appropriate. Geographic diversity may
help, but IP diversity might be equally effective, though some gear does
not support this.
I'm curious if anyone has set up a honey-pot to find the bad guys before
they find you and if so, what has the success been. Would the list be
willing to share their blacklists?
On Fri, Oct 12, 2012 at 8:23 PM, Ryan Delgrosso <[email protected]>wrote:
> All,
> I am relatively certain most of you have heard about the issue CallCentric
> had experienced recently where they came under a significant DDOS attack.
> My question to the community at large is, who here has been down this road
> and been attacked; and what was the signature of that attack. I am sure
> your are not alone and we could probably all do fairly well to compare
> notes on the topic.
>
> This year alone we have seen at least 7 different flavors of DDOS attacks
> aimed at our resources some impactful some not, and I would be extremely
> interested in comparing notes with anyone else (especially callcentric
> engineers) who are interested in hoping to share information and perhaps
> prevent the next major incident.
>
> Feel free to respond on or off list as you see fit.
>
> -Ryan
> ______________________________**_________________
> VoiceOps mailing list
> [email protected]
> https://puck.nether.net/**mailman/listinfo/voiceops<https://puck.nether.net/mailman/listinfo/voiceops>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/voiceops/attachments/20121015/e3c5104b/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 15 Oct 2012 14:06:16 +0100
From: Simon Woodhead <[email protected]>
To: PE <[email protected]>
Cc: [email protected]
Subject: Re: [VoiceOps] DDOS attacks against ITSPs
Message-ID:
<CAEp9JpAqQqFfBVD8L6ttkz8=CorLRk4iTuU0ox8W7B=t4k-...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi folks,
> I'm curious if anyone has set up a honey-pot to find the bad guys before
> they find you and if so, what has the success been. Would the list be
> willing to share their blacklists?
We (Simwood) have been operating a honeypot for some-time. The results
are in the public domain at http://mirror.simwood.com/honeypot
cheers
Simon
--
***** Email confidentiality notice *****
This message is private and confidential. If you have received this message in
error, please notify us and remove it from your system.
Simwood eSMS Limited is a limited company registered in England and Wales.
Registered number: 03379831. Registered office: c/o HW Chartered Accountants,
Keepers Lane, The Wergs, Wolverhampton, WV6 8UA. Trading address: Falcon Drive,
Cardiff Bay, Cardiff, CF10 4RU.
------------------------------
Message: 4
Date: Mon, 15 Oct 2012 08:01:25 -0500
From: "J. Oquendo" <[email protected]>
To: PE <[email protected]>
Cc: [email protected]
Subject: Re: [VoiceOps] DDOS attacks against ITSPs
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Mon, 15 Oct 2012, PE wrote:
> This is an important topic. And whether you know it or not, your network
> has, at some time I'm sure, been under fire, whether a DDoS, Registration
> flood, or other. A true DDoS is obviously the hardest to deal with, though
> the others can also cause harm. In my experience, a Registration flood is
> the most common, and the signatures are generally:
>
> 1. Scan of your IP's
> 2. Attempt to register to any that reply to SIP
> 3. Registrations are usally to 4-digit extensions. I guess the attacker is
> hoping to hit a PBX, not necesarily an ITSP
> 4. User-agent is usually "friendly-scanner" (i.. SipVicious)
> 5. Many come from international locations
>
> Acme has some good documentation on the topic as well as best common
> practices for configuration. Their ACLs are supposed to offload the
> processing from the CPU (where the heavy lifting of SIP B2BUA is done) to
> the interface. Of course, no interface can truly stop a flood that fills
> the pipe.
>
> So, what to do?
>
> First, check your configs and do the most you can there. Next, if you have
> the tools, keep an eye on registrations and overall bandwidth in and out of
> your network and to specific interfaces. When you see an odd spike, dig
> into it and block the sender, where appropriate. Geographic diversity may
> help, but IP diversity might be equally effective, though some gear does
> not support this.
>
> I'm curious if anyone has set up a honey-pot to find the bad guys before
> they find you and if so, what has the success been. Would the list be
> willing to share their blacklists?
>
Google VoIP Abuse Project. (It's Moday and I'm too lazy to
type/dig it out)
As for honeypots, I have created one primarily for Asterisk
but it can be modified for most systems with a little expect
scripting. I also built an alerting VoIP based notifier for
nCite/Netrake/Audiocodes/_Whatever_they_call_themselves_now.
1) Can be blocked using common sense firewalling (block all
allow in trusted)
2) Can be mitigated with strong(sensible) usernames and
passwords
3) See #2 ... Also we don't do username/password auth on the
SBC level
4) 1.1.1.1 no brainer. Can also be filtered/SIEM'd/etc
5) Many MORE come from cloud providers right in North
America
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM
"It takes 20 years to build a reputation and five minutes to
ruin it. If you think about that, you'll do things
differently." - Warren Buffett
42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF
------------------------------
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
End of VoiceOps Digest, Vol 40, Issue 13
****************************************
