>>I don’t know of _who_ else may have more expertise in developing and >>deploying attack mitigation solutions than ARIN.
Get real, just because they assign IP's and ASN's does not mean that they have dpi expertise.... ! >>> IMHO - it’s going worsen soon because of another vicious cycle of >>> “deregulations” and passing on more control over the Internet to 3rd >>> (foreign) parties. That is a bunch of Bull !, and fear mongering.... ARIN is an organization that manages assignment... they are not a Traffic COP nor are they responsible for checking packet content ! Faisal Imtiaz Snappy Internet & Telecom > From: "GregoryB" <[email protected]> > To: "[email protected]" <[email protected]> > Sent: Saturday, March 19, 2016 1:28:01 PM > Subject: Re: [VoiceOps] . DDOS Attacks and ITSP's > Just in case anyone may have any doubts… ARIN is again under the attack (2nd > time this month). > I don’t know of _who_ else may have more expertise in developing and deploying > attack mitigation solutions than ARIN. > IMHO - it’s going worsen soon because of another vicious cycle of > “deregulations” and passing on more control over the Internet to 3rd (foreign) > parties. > == > Date: Fri, 18 Mar 2016 15:37:48 -0400 > From: ARIN < [email protected] > > To: [email protected] > Subject: [arin-announce] ARIN DDoS Attack > Message-ID: < [email protected] > > Content-Type: text/plain; charset=utf-8; format=flowed > Starting at 1:25 PM EDT on Friday, 18 March, a DDoS attack began against > ARIN. This was and continues to be a sustained attack against our > provisioning services, email, and website. We initiated our DDoS > mitigation plan and are in the process of mitigating various types of > attack traffic patterns. All our other public-facing services (Whois, > Whois-RWS, RDAP, DNS, IRR, and RPKI repository services) are not > affected by this attack and are operating normally. > We will announce an all clear 24 hours after the attacks have stopped. > Regards, > Mark Kosters > Chief Technology Officer > American Registry for Internet Numbers (ARIN) > == > I have reasons of not wanting to provide my address nor name. > == >> On Mar 19, 2016, at 12:42 PM, Tim Linn < [email protected] > >> wrote: >> Ryan, >> This is a great discussion to start. I can't contribute at this time, but I >> certainly plan on giving you guys all of the information about what we at VI >> have been doing, what has worked, what hasn't worked, what we saw, what we >> didn't see, etc. Certain contacts may not allow me to name company names, >> but I >> still think we can give out enough information to be useful. >> We definitely plan on giving this information out. Like you said, events like >> these are typically embarrassing and companies don't like to come out and >> describe exactly how negligent or naive they were to allow it. >> I feel that getting the knowledge out there is much more important than our >> pride though. Right now, we're not giving out a whole lot of information on >> what we are doing in fear that it will be "used against us." I do somewhat >> agree with your assessment about these people knowing this stuff already, but >> at this point we don't want to take the chance (as irrational as that seems). >> Once we're in a more stable place, I will certainly work with our Networking >> Engineer, Owner, and Operations Manager on trying to talk them into giving >> out >> the most information possible to arm you guys in the event that this occurs >> to >> any of you. >> In the meantime, if you have any questions, please feel free to email me. I >> will >> do my best to help as much as I can. >> Timothy Linn >> Lead Systems Engineer >> Voip Innovations >> Sent from my Verizon Wireless 4G LTE smartphone >> -------- Original message -------- >> From: [email protected] >> Date: 2016/03/19 12:00 (GMT-05:00) >> To: [email protected] >> Subject: VoiceOps Digest, Vol 81, Issue 38 >> ---------------------------------------------------------------------- >> Message: 1 >> Date: Fri, 18 Mar 2016 17:07:56 -0700 >> From: Ryan Delgrosso < [email protected] > >> To: " [email protected] " < [email protected] > >> Subject: [VoiceOps] DDOS Attacks and ITSP's >> Message-ID: < [email protected] > >> Content-Type: text/plain; charset="utf-8"; Format="flowed" >> With the current mega-thread about VI I figured I would get an >> educational discussion going about DDOS. Search the archives, Ive >> probably started this discussion a few times in the past but each time >> the context is different. >> I have given talks at several different venues (anyone here a CFCA >> member, or been to a Metaswitch forum event?) about DDOS and what the >> current arsenal of internet attacks means to voice. Unfortunately many >> network operators treat DDOS like a shameful thing and don't share >> information about it. This makes it that much harder for network >> operators to do the right thing and take meaningful and decisive action >> and ultimately makes the jobs of the attackers that much easier. >> Keep in mind sharing these kinds of tactics isn't "helping the >> attackers". They know this stuff. Its OK to tell them what they know. >> Who doesn't know this stuff are other operators that haven't been hit yet. >> Have you been hit by DDOS? Have you built out solutions to cope with DDOS? >> Ill start things off: >> 1. How do you know its a DDOS and something isn't just broken? >> 1. netflow >> 2. SBC retransmissions (this will often be your first warning) >> 3. Significant deviation from normal traffic volumes >> 2. As a VoIP carrier, my network looks like a DDOS attack all the time >> (oodles of UDP traffic). this makes most commercial solutions a >> square peg / round hole problem. >> 3. DDOS survivability must be designed into the network not bolted on. >> 1. Place Access SBC's, Peering SBC's, Webservers, etc on different >> networks and on different BGP adertisements. >> 2. Have multiple access SBC's on different networks / routers / BGP >> advertisements >> 3. Use DNS to home ALL clients. When your Access SBC succumbs to a >> reflection attack you can flip your customers using SRV records >> to the surviving SBC's. Customers using straight IP will remain >> down. >> 4. Use CDN networks like Cloudflare / Cloudfront or just put >> webservers in EC2. Keep web away from voice. Webservers are >> attack magnets. >> 5. Build defense in depth. Your network is a medieval castle, have >> moats and walls and soldiers. >> 4. Be a good netizen. If you are an ISP, implement BCP38. No open DNS >> recursors, no open NTP or SNMP services that are reflection targets. >> Leave no loaded weapons for others in your network. >> 5. Traffic scrubbing services typically don't mix well with VoIP >> carriers. This is basically the TSA of the network. (there are >> exceptions, the price tags have commas). >> 6. How do you go about testing your protections? Don't just sit smugly >> in your house made of straw. >> 7. Most upstream carrier DDOS protection strategies include "blackhole >> the destination to protect the network". This saves them but >> accomplishes your attackers goal. >> 8. Do you know how big of a DDOS it actually takes to hurt you? Ill bet >> its less than you think. >> So lets hear it. Who has experience on this front? What would you like >> to share? Comments on the above? >> -Ryan >> This message is for the designated recipient only and may contain privileged, >> proprietary, or otherwise confidential information. If you have received this >> message in error, please notify the sender immediately and delete the >> original. >> Any other use of the e-mail by you is prohibited. Unauthorized interception >> of >> this e-mail is a violation of federal criminal law. We reserve the right, >> when >> permitted by law, to scan electronic communications, including e-mail and >> instant messaging, for the purposes of security and compliance with our >> internal policy. >> _______________________________________________ >> VoiceOps mailing list >> [email protected] >> https://puck.nether.net/mailman/listinfo/voiceops > _______________________________________________ > VoiceOps mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list [email protected] https://puck.nether.net/mailman/listinfo/voiceops
