Re: [External] announcing IPs by scrubbing service to help with DDoS attacks and ROAs
Tom, thanks. I'm an academic researcher, no a network operator, sorry for the confusion, I should have been clearer. The practice you described indeed shouldn't requite ROA. I didn't even consider it, probably since I've been working so much on prefix hijacks, and this prefix would result in increased vulnerability to prefix hijacks. But if there's only a DDoS attack on the prefix and it's not being hijacked at the same time, then I think this practice may be fine - which would make such `emergency ROA' unnecessary. So that's very very useful feedback, thanks a lot!! Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/cybersecurity On Fri, Nov 17, 2023 at 12:09 AM Tom Krenn wrote: > It has been a few years, but I recall advertising my routes to the > scrubbing center via a tunnel and just prepending to my other peers when in > mitigation. This was pre-RPKI days, but my ASN was still originating the > route. So, I would assume no change in ROA would be needed in that > scenario. Are you allowing them to originate your routes or are they just > another hop in your as-path? > > > > Tom Krenn > > Network Architect > > Enterprise Architecture - Information Technology > > [image: Hennepin County logo] > > > > > > *From:* NANOG *On Behalf > Of *Amir Herzberg > *Sent:* Thursday, November 16, 2023 19:58 > *To:* NANOG > *Subject:* [External] announcing IPs by scrubbing service to help with > DDoS attacks and ROAs > > > > *CAUTION:* This email was sent from outside of Hennepin County. Unless > you recognize the sender and know the content, do not click links or open > attachments. > > Hi, do people use scrubbing services, when under DDoS attack, by having > the scrubbing service announce the attacked IP prefix(es)? > > > > If so, and you have a ROA for these prefixes, do you authorize the > scrubbing AS (by issuing ROA or otherwise), and if so, do you do it in > advance or only when you need the scrubbing service to announce your > prefix? > > > > To clarify: we have a possible method to allow such `emergency ROAs' but > I'm not convinced if we have a solution to a real problem - or if we just > found a cute crypto solution and will end up writing it for a non-real > problem. I prefer not to waste our time on presenting cute solutions to > non-real problems :) > > > > So thanks for your help! Use your judgement if to respond on list or off > list. > > > > Many thanks, Amir > > -- > > Amir Herzberg > > > > Comcast professor of Security Innovations, Computer Science and > Engineering, University of Connecticut > > Homepage: https://sites.google.com/site/amirherzberg/home > > `Applied Introduction to Cryptography' textbook and lectures: > https://sites.google.com/site/amirherzberg/cybersecurity > > > > > > > *Disclaimer:* If you are not the intended recipient of this message, > please immediately notify the sender of the transmission error and then > promptly permanently delete this message from your computer system. >
RE: [External] announcing IPs by scrubbing service to help with DDoS attacks and ROAs
It has been a few years, but I recall advertising my routes to the scrubbing center via a tunnel and just prepending to my other peers when in mitigation. This was pre-RPKI days, but my ASN was still originating the route. So, I would assume no change in ROA would be needed in that scenario. Are you allowing them to originate your routes or are they just another hop in your as-path? Tom Krenn Network Architect Enterprise Architecture - Information Technology [Hennepin County logo] From: NANOG On Behalf Of Amir Herzberg Sent: Thursday, November 16, 2023 19:58 To: NANOG Subject: [External] announcing IPs by scrubbing service to help with DDoS attacks and ROAs CAUTION: This email was sent from outside of Hennepin County. Unless you recognize the sender and know the content, do not click links or open attachments. Hi, do people use scrubbing services, when under DDoS attack, by having the scrubbing service announce the attacked IP prefix(es)? If so, and you have a ROA for these prefixes, do you authorize the scrubbing AS (by issuing ROA or otherwise), and if so, do you do it in advance or only when you need the scrubbing service to announce your prefix? To clarify: we have a possible method to allow such `emergency ROAs' but I'm not convinced if we have a solution to a real problem - or if we just found a cute crypto solution and will end up writing it for a non-real problem. I prefer not to waste our time on presenting cute solutions to non-real problems :) So thanks for your help! Use your judgement if to respond on list or off list. Many thanks, Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures:https://sites.google.com/site/amirherzberg/cybersecurity Disclaimer: If you are not the intended recipient of this message, please immediately notify the sender of the transmission error and then promptly permanently delete this message from your computer system.
announcing IPs by scrubbing service to help with DDoS attacks and ROAs
Hi, do people use scrubbing services, when under DDoS attack, by having the scrubbing service announce the attacked IP prefix(es)? If so, and you have a ROA for these prefixes, do you authorize the scrubbing AS (by issuing ROA or otherwise), and if so, do you do it in advance or only when you need the scrubbing service to announce your prefix? To clarify: we have a possible method to allow such `emergency ROAs' but I'm not convinced if we have a solution to a real problem - or if we just found a cute crypto solution and will end up writing it for a non-real problem. I prefer not to waste our time on presenting cute solutions to non-real problems :) So thanks for your help! Use your judgement if to respond on list or off list. Many thanks, Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/cybersecurity
DDoS Attacks targeting VPN/IPSEC endpoints
Any one else seeing this? Hearing some isolated events across different industry segments. If you are, can you provide any TTPs?
Re: Data on latency and loss-rates during congestion DDoS attacks
I have no idea who was the reviewer (academic or industry or whatever). However, he didn't actually object to the assertion that latency increases with congestion; he only raised the question of the which latency values would be typical/reasonable for a congestion DoS attack. Notice also that the relevant parameter is end-to-end latency (or RTT), not the per-device latency. And surely, there can be wide variety here (that's why we do experiments under different values and plot graphs). The question is, what is the most important range to focus on (when measuring and comparing different protocols). Anyway, thanks for the comments; if anyone has such data they can share, that'll be great and appreciated. -- Amir On Sun, Jan 26, 2020 at 7:17 AM Saku Ytti wrote: > On Sun, 26 Jan 2020 at 13:11, Etienne-Victor Depasquale > wrote: > > > " he/she doubts that delays increase significantly under network > congestion since he/she thinks that the additional queuing is something > mostly in small routers such as home routers (and maybe like the routers > used in our emulation testbed) " > > > > Wow, this is the first time I've found an academic challenging the > increase of delay in routers under network congestion. > > I don't know if context implies reviewer was academic. Whilethe common > case remains that latencies per link jump from low microseconds to > tens of milliseconds during congestion of BB interface, there are also > a lot of deployments using devices (trident, tomahawk) with minimal > buffering not allowing even millisecond of buffering during > congestion. Reviewer may have thought of those devices when they > answered, but I agree that answer would be generally wrong. > > > -- > ++ytti >
Re: Data on latency and loss-rates during congestion DDoS attacks
On Sun, 26 Jan 2020 at 13:11, Etienne-Victor Depasquale wrote: > " he/she doubts that delays increase significantly under network congestion > since he/she thinks that the additional queuing is something mostly in small > routers such as home routers (and maybe like the routers used in our > emulation testbed) " > > Wow, this is the first time I've found an academic challenging the increase > of delay in routers under network congestion. I don't know if context implies reviewer was academic. Whilethe common case remains that latencies per link jump from low microseconds to tens of milliseconds during congestion of BB interface, there are also a lot of deployments using devices (trident, tomahawk) with minimal buffering not allowing even millisecond of buffering during congestion. Reviewer may have thought of those devices when they answered, but I agree that answer would be generally wrong. -- ++ytti
Re: Data on latency and loss-rates during congestion DDoS attacks
" he/she doubts that delays increase significantly under network congestion since he/she thinks that the additional queuing is something mostly in small routers such as home routers (and maybe like the routers used in our emulation testbed) " Wow, this is the first time I've found an academic challenging the increase of delay in routers under network congestion. The doubt is childish. It's like a question you'd expect to hear in a "networking 101" class. On Sat, Jan 25, 2020 at 4:28 AM Amir Herzberg wrote: > Damian, thanks! > > That's actually roughly the range of losses we focused on; but it was > based on my rough feeling for reasonable loss rates (as well as on > experiments where we caused losses in emulated environments), and a > reviewer - justifiably - asked if we can base our values on realistic > values. So I would love to have real value, I'm sure some people have these > measured (I'm actually quite sure I've seed such values, but the challenge > is recalling where and finding it...). > > Also, latency values (under congestion) would be appreciated. Also here, > we used a range of values, I think the highest was 1sec, since we believe > that under congestion delays goes up considerably since many queues fill up > [and again I seem to recall values around this range]. But here the > reviewer even challenged us and said he/she doubts that delays increase > significantly under network congestion since he/she thinks that the > additional queuing is something mostly in small routers such as home > routers (and maybe like the routers used in our emulation testbed). So I'll > love to have some real data to know for sure. > > Apart from knowing these things for this specific paper, I should know > them in a well-founded way anyway, as I'm doing rearch on and teaching > net-sec (incl. quite a lot on DoS) :) > > -- > Amir > > > > On Fri, Jan 24, 2020 at 5:31 PM Damian Menscher wrote: > >> I suggest testing with a broad variety of values, as losses as low as 5% >> can be annoying, but losses at 50% or more are not uncommon. >> >> Damian >> >> On Fri, Jan 24, 2020 at 4:41 AM Amir Herzberg >> wrote: >> >>> Dear NANOG, >>> >>> One of my ongoing research works is about a transport protocol that >>> ensures (critical) communication in spite of DDoS congestion attack (which >>> cannot be circumvented), by (careful) use of Forward Error Correction. Yes, >>> obviously, this has to be done and used carefully since the FEC clearly >>> increases traffic rather than the typical congestion-control approach of >>> reducing it, I'm well aware of it; but some applications are critical (and >>> often low-bandwidth) so such tool is important. >>> >>> I am looking for data on loss rate and congestion of DDoS attacks to >>> make sure we use right parameters. Any chance you have such data and can >>> share? >>> >>> Many thanks! >>> -- >>> Amir Herzberg >>> Comcast chair of security innovation, University of Connecticut >>> Foundations of cybersecurity >>> <https://www.researchgate.net/publication/323243320_Introduction_to_Cyber-Security_Part_I_Applied_Cryptography_Lecture_notes_and_exercises>, >>> part >>> I (see also part II and presentations): >>> https://www.researchgate.net/publication/323243320_Introduction_to_Cyber-Security_Part_I_Applied_Cryptography_Lecture_notes_and_exercises >>> <https://www.researchgate.net/project/Lecture-notes-on-Introduction-to-Cyber-Security> >>> >>> >>> -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Data on latency and loss-rates during congestion DDoS attacks
Hi Damian, thanks, that's right; actually in high-latency and 10% loss, you get _much_ better performance than either TCP or Quic. However, these are not as common scenarios as clogging due to DDoS... So we still want to find relevant data, to know which ranges of latency and loss make sense. Guys: if you can share data but only privately, please do :) thanks! Amir -- Amir On Sat, Jan 25, 2020 at 12:38 PM Damian Menscher wrote: > Getting (and releasing) numbers from DDoS attacks will be challenging for > most, but I think your research could apply to more than just DDoS. There > are often cases where one might want to work from an environment which has > very poor networking. As an extreme example, in 2007 I got online from an > internet cafe in Paramaribo. But, as I told a friend at the time, "latency > is about 1s and packet loss around 10%". It would be great if forward > error correction could have improved that experience. > > Damian > > On Fri, Jan 24, 2020 at 7:27 PM Amir Herzberg > wrote: > >> Damian, thanks! >> >> That's actually roughly the range of losses we focused on; but it was >> based on my rough feeling for reasonable loss rates (as well as on >> experiments where we caused losses in emulated environments), and a >> reviewer - justifiably - asked if we can base our values on realistic >> values. So I would love to have real value, I'm sure some people have these >> measured (I'm actually quite sure I've seed such values, but the challenge >> is recalling where and finding it...). >> >> Also, latency values (under congestion) would be appreciated. Also here, >> we used a range of values, I think the highest was 1sec, since we believe >> that under congestion delays goes up considerably since many queues fill up >> [and again I seem to recall values around this range]. But here the >> reviewer even challenged us and said he/she doubts that delays increase >> significantly under network congestion since he/she thinks that the >> additional queuing is something mostly in small routers such as home >> routers (and maybe like the routers used in our emulation testbed). So I'll >> love to have some real data to know for sure. >> >> Apart from knowing these things for this specific paper, I should know >> them in a well-founded way anyway, as I'm doing rearch on and teaching >> net-sec (incl. quite a lot on DoS) :) >> >> -- >> Amir >> >> >> >> On Fri, Jan 24, 2020 at 5:31 PM Damian Menscher >> wrote: >> >>> I suggest testing with a broad variety of values, as losses as low as 5% >>> can be annoying, but losses at 50% or more are not uncommon. >>> >>> Damian >>> >>> On Fri, Jan 24, 2020 at 4:41 AM Amir Herzberg >>> wrote: >>> >>>> Dear NANOG, >>>> >>>> One of my ongoing research works is about a transport protocol that >>>> ensures (critical) communication in spite of DDoS congestion attack (which >>>> cannot be circumvented), by (careful) use of Forward Error Correction. Yes, >>>> obviously, this has to be done and used carefully since the FEC clearly >>>> increases traffic rather than the typical congestion-control approach of >>>> reducing it, I'm well aware of it; but some applications are critical (and >>>> often low-bandwidth) so such tool is important. >>>> >>>> I am looking for data on loss rate and congestion of DDoS attacks to >>>> make sure we use right parameters. Any chance you have such data and can >>>> share? >>>> >>>> Many thanks! >>>> -- >>>> Amir Herzberg >>>> Comcast chair of security innovation, University of Connecticut >>>> Foundations of cybersecurity >>>> <https://www.researchgate.net/publication/323243320_Introduction_to_Cyber-Security_Part_I_Applied_Cryptography_Lecture_notes_and_exercises>, >>>> part >>>> I (see also part II and presentations): >>>> https://www.researchgate.net/publication/323243320_Introduction_to_Cyber-Security_Part_I_Applied_Cryptography_Lecture_notes_and_exercises >>>> <https://www.researchgate.net/project/Lecture-notes-on-Introduction-to-Cyber-Security> >>>> >>>> >>>>
Re: Data on latency and loss-rates during congestion DDoS attacks
Getting (and releasing) numbers from DDoS attacks will be challenging for most, but I think your research could apply to more than just DDoS. There are often cases where one might want to work from an environment which has very poor networking. As an extreme example, in 2007 I got online from an internet cafe in Paramaribo. But, as I told a friend at the time, "latency is about 1s and packet loss around 10%". It would be great if forward error correction could have improved that experience. Damian On Fri, Jan 24, 2020 at 7:27 PM Amir Herzberg wrote: > Damian, thanks! > > That's actually roughly the range of losses we focused on; but it was > based on my rough feeling for reasonable loss rates (as well as on > experiments where we caused losses in emulated environments), and a > reviewer - justifiably - asked if we can base our values on realistic > values. So I would love to have real value, I'm sure some people have these > measured (I'm actually quite sure I've seed such values, but the challenge > is recalling where and finding it...). > > Also, latency values (under congestion) would be appreciated. Also here, > we used a range of values, I think the highest was 1sec, since we believe > that under congestion delays goes up considerably since many queues fill up > [and again I seem to recall values around this range]. But here the > reviewer even challenged us and said he/she doubts that delays increase > significantly under network congestion since he/she thinks that the > additional queuing is something mostly in small routers such as home > routers (and maybe like the routers used in our emulation testbed). So I'll > love to have some real data to know for sure. > > Apart from knowing these things for this specific paper, I should know > them in a well-founded way anyway, as I'm doing rearch on and teaching > net-sec (incl. quite a lot on DoS) :) > > -- > Amir > > > > On Fri, Jan 24, 2020 at 5:31 PM Damian Menscher wrote: > >> I suggest testing with a broad variety of values, as losses as low as 5% >> can be annoying, but losses at 50% or more are not uncommon. >> >> Damian >> >> On Fri, Jan 24, 2020 at 4:41 AM Amir Herzberg >> wrote: >> >>> Dear NANOG, >>> >>> One of my ongoing research works is about a transport protocol that >>> ensures (critical) communication in spite of DDoS congestion attack (which >>> cannot be circumvented), by (careful) use of Forward Error Correction. Yes, >>> obviously, this has to be done and used carefully since the FEC clearly >>> increases traffic rather than the typical congestion-control approach of >>> reducing it, I'm well aware of it; but some applications are critical (and >>> often low-bandwidth) so such tool is important. >>> >>> I am looking for data on loss rate and congestion of DDoS attacks to >>> make sure we use right parameters. Any chance you have such data and can >>> share? >>> >>> Many thanks! >>> -- >>> Amir Herzberg >>> Comcast chair of security innovation, University of Connecticut >>> Foundations of cybersecurity >>> <https://www.researchgate.net/publication/323243320_Introduction_to_Cyber-Security_Part_I_Applied_Cryptography_Lecture_notes_and_exercises>, >>> part >>> I (see also part II and presentations): >>> https://www.researchgate.net/publication/323243320_Introduction_to_Cyber-Security_Part_I_Applied_Cryptography_Lecture_notes_and_exercises >>> <https://www.researchgate.net/project/Lecture-notes-on-Introduction-to-Cyber-Security> >>> >>> >>>
Re: Data on latency and loss-rates during congestion DDoS attacks
On Sat, Jan 25, 2020 at 2:12 AM Saku Ytti wrote: > On Sat, 25 Jan 2020 at 05:30, Amir Herzberg wrote: > > DDoS is very very cheap, if there is a single global egress for given > interface then the DDoS traffic can easily be 100 times the egress > capacity (1GE egress, 100GE DDoS). Thanks. However, my question is about statistics of attacks actually seen `in the wild' - and not just the `worst' but also more common attacks. Furthermore, I'm asking about the _outcome_ of the congestion - mainly, loss-rates and latency - and not about the _amount_ of DDoS traffic. DDoS traffic often gets lost itself in different intermediate routers, so its ultimate impact is not trivial to estimate. > I'm very skeptical if FEC will > help, I think this is case of cat and mouse hmm, I don't think so; it is more a matter of justification, and also, obviously, amount of over-capacity - which is still, obviously, a basic thing anybody concerned about congestion would worry about. Let me be extreme and simplify... Suppose idd attacker can send 100 times the capacity of a (say, single) router, resulting in 99% loss rate. Then FEC should work - but, of course, with high overhead, let's even simplify and say it requires 100 times redundancy (although it's actually not as bad as that). Still, this can be Ok if I have 100 times overcapacity - which for many critical applications, is not even a big deal, as crazy as it sounds (and is) for general applications. > , based on data you see now > it may seem reasonable, but now is only result of minimum viable ddos, > which is trivial to increase should need occur. I still think evaluation should preferably compare to attacks reported in reality, with potential additional analysis of projections of potential attacks. > Similarly DDoS attacks > are excessive dumb often, like dumb UDP ports which are easy drop, but > should we solve protection well for these, it's trivial to make it > proper HTTPS TCP SYN. > hmm, tcp-syn is already a different story (and we have pretty good defenses against it and many other attacks on the end host). I do work on some of these attacks (and defenses) too but in this specific case I'm focusing on bandwidth-DoS attacks (network congestion). I'm further focusing in this work on a defense which may involves a transport (end to end) protocol, of course I'm aware of network-based defenses, it's just not focus of this work (think of customer with no ability to `fix' the network service). > > Backbone device interface can add hundreds of milliseconds during > congestion, but more commonly we're talking about tens of milliseconds > during congestion and low microseconds to high nanoseconds outside > congestion. > Backbone device buffer space is highly googlable, BRCM > trident/tomahawk styte boxes have very little, but they are more > intended for DC/LAN scenarios, than WAN. Nokia FP, Huawei Solar, > EZchip, Cisco nPower, Cisco Silicon One, Juniper Trio, Juniper > Paradise, Broadcom Jericho all will buffer high tens of milliseconds > to low hundreds. > Thanks again, but I'm not looking for data on particular devices; the latency during congestion attacks may be impacted by multiple devices along the path. So again my interest is mainly in measured values under real attacks. tks! Amir > > -- > ++ytti >
Re: Data on latency and loss-rates during congestion DDoS attacks
On Sat, 25 Jan 2020 at 05:30, Amir Herzberg wrote: > That's actually roughly the range of losses we focused on; but it was based > on my rough feeling for reasonable loss rates (as well as on experiments > where we caused losses in emulated environments), and a reviewer - > justifiably - asked if we can base our values on realistic values. So I would > love to have real value, I'm sure some people have these measured (I'm > actually quite sure I've seed such values, but the challenge is recalling > where and finding it...). DDoS is very very cheap, if there is a single global egress for given interface then the DDoS traffic can easily be 100 times the egress capacity (1GE egress, 100GE DDoS). I'm very skeptical if FEC will help, I think this is case of cat and mouse, based on data you see now it may seem reasonable, but now is only result of minimum viable ddos, which is trivial to increase should need occur. Similarly DDoS attacks are excessive dumb often, like dumb UDP ports which are easy drop, but should we solve protection well for these, it's trivial to make it proper HTTPS TCP SYN. > Also, latency values (under congestion) would be appreciated. Also here, we > used a range of values, I think the highest was 1sec, since we believe that > under congestion delays goes up considerably since many queues fill up [and > again I seem to recall values around this range]. But here the reviewer even > challenged us and said he/she doubts that delays increase significantly under > network congestion since he/she thinks that the additional queuing is > something mostly in small routers such as home routers (and maybe like the > routers used in our emulation testbed). So I'll love to have some real data > to know for sure. Backbone device interface can add hundreds of milliseconds during congestion, but more commonly we're talking about tens of milliseconds during congestion and low microseconds to high nanoseconds outside congestion. Backbone device buffer space is highly googlable, BRCM trident/tomahawk styte boxes have very little, but they are more intended for DC/LAN scenarios, than WAN. Nokia FP, Huawei Solar, EZchip, Cisco nPower, Cisco Silicon One, Juniper Trio, Juniper Paradise, Broadcom Jericho all will buffer high tens of milliseconds to low hundreds. -- ++ytti
Re: Data on latency and loss-rates during congestion DDoS attacks
Damian, thanks! That's actually roughly the range of losses we focused on; but it was based on my rough feeling for reasonable loss rates (as well as on experiments where we caused losses in emulated environments), and a reviewer - justifiably - asked if we can base our values on realistic values. So I would love to have real value, I'm sure some people have these measured (I'm actually quite sure I've seed such values, but the challenge is recalling where and finding it...). Also, latency values (under congestion) would be appreciated. Also here, we used a range of values, I think the highest was 1sec, since we believe that under congestion delays goes up considerably since many queues fill up [and again I seem to recall values around this range]. But here the reviewer even challenged us and said he/she doubts that delays increase significantly under network congestion since he/she thinks that the additional queuing is something mostly in small routers such as home routers (and maybe like the routers used in our emulation testbed). So I'll love to have some real data to know for sure. Apart from knowing these things for this specific paper, I should know them in a well-founded way anyway, as I'm doing rearch on and teaching net-sec (incl. quite a lot on DoS) :) -- Amir On Fri, Jan 24, 2020 at 5:31 PM Damian Menscher wrote: > I suggest testing with a broad variety of values, as losses as low as 5% > can be annoying, but losses at 50% or more are not uncommon. > > Damian > > On Fri, Jan 24, 2020 at 4:41 AM Amir Herzberg > wrote: > >> Dear NANOG, >> >> One of my ongoing research works is about a transport protocol that >> ensures (critical) communication in spite of DDoS congestion attack (which >> cannot be circumvented), by (careful) use of Forward Error Correction. Yes, >> obviously, this has to be done and used carefully since the FEC clearly >> increases traffic rather than the typical congestion-control approach of >> reducing it, I'm well aware of it; but some applications are critical (and >> often low-bandwidth) so such tool is important. >> >> I am looking for data on loss rate and congestion of DDoS attacks to make >> sure we use right parameters. Any chance you have such data and can share? >> >> Many thanks! >> -- >> Amir Herzberg >> Comcast chair of security innovation, University of Connecticut >> Foundations of cybersecurity >> <https://www.researchgate.net/publication/323243320_Introduction_to_Cyber-Security_Part_I_Applied_Cryptography_Lecture_notes_and_exercises>, >> part >> I (see also part II and presentations): >> https://www.researchgate.net/publication/323243320_Introduction_to_Cyber-Security_Part_I_Applied_Cryptography_Lecture_notes_and_exercises >> <https://www.researchgate.net/project/Lecture-notes-on-Introduction-to-Cyber-Security> >> >> >>
Re: Data on latency and loss-rates during congestion DDoS attacks
I suggest testing with a broad variety of values, as losses as low as 5% can be annoying, but losses at 50% or more are not uncommon. Damian On Fri, Jan 24, 2020 at 4:41 AM Amir Herzberg wrote: > Dear NANOG, > > One of my ongoing research works is about a transport protocol that > ensures (critical) communication in spite of DDoS congestion attack (which > cannot be circumvented), by (careful) use of Forward Error Correction. Yes, > obviously, this has to be done and used carefully since the FEC clearly > increases traffic rather than the typical congestion-control approach of > reducing it, I'm well aware of it; but some applications are critical (and > often low-bandwidth) so such tool is important. > > I am looking for data on loss rate and congestion of DDoS attacks to make > sure we use right parameters. Any chance you have such data and can share? > > Many thanks! > -- > Amir Herzberg > Comcast chair of security innovation, University of Connecticut > Foundations of cybersecurity > <https://www.researchgate.net/publication/323243320_Introduction_to_Cyber-Security_Part_I_Applied_Cryptography_Lecture_notes_and_exercises>, > part > I (see also part II and presentations): > https://www.researchgate.net/publication/323243320_Introduction_to_Cyber-Security_Part_I_Applied_Cryptography_Lecture_notes_and_exercises > <https://www.researchgate.net/project/Lecture-notes-on-Introduction-to-Cyber-Security> > > >
Data on latency and loss-rates during congestion DDoS attacks
Dear NANOG, One of my ongoing research works is about a transport protocol that ensures (critical) communication in spite of DDoS congestion attack (which cannot be circumvented), by (careful) use of Forward Error Correction. Yes, obviously, this has to be done and used carefully since the FEC clearly increases traffic rather than the typical congestion-control approach of reducing it, I'm well aware of it; but some applications are critical (and often low-bandwidth) so such tool is important. I am looking for data on loss rate and congestion of DDoS attacks to make sure we use right parameters. Any chance you have such data and can share? Many thanks! -- Amir Herzberg Comcast chair of security innovation, University of Connecticut Foundations of cybersecurity <https://www.researchgate.net/publication/323243320_Introduction_to_Cyber-Security_Part_I_Applied_Cryptography_Lecture_notes_and_exercises>, part I (see also part II and presentations): https://www.researchgate.net/publication/323243320_Introduction_to_Cyber-Security_Part_I_Applied_Cryptography_Lecture_notes_and_exercises <https://www.researchgate.net/project/Lecture-notes-on-Introduction-to-Cyber-Security>
Re: [SECURITY] Application layer attacks/DDoS attacks
The idea of restricting access to a certain content during an attack on the trusted networks only will make all interested ISPs be more trusted don't the lawyers already have enough money?
RE: [SECURITY] Application layer attacks/DDoS attacks
Without a concomitant increase in trustworthy, assigning greater levels of trust is fools endeavour. Whatever this trusted network initiative is, I take that it was designed by fools or government (the two are usually indistinguishable) for the purpose of creating utterly untrustworthy networks. -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ramy Hashish Sent: Sunday, 24 May, 2015 22:49 To: morrowc.li...@gmail.com; nanog@nanog.org Subject: Re: [SECURITY] Application layer attacks/DDoS attacks The idea of restricting access to a certain content during an attack on the trusted networks only will make all interested ISPs be more trusted Ramy On Mon, May 25, 2015 at 5:01 AM, Christopher Morrow morrowc.li...@gmail.com wrote: On Sat, May 23, 2015 at 9:12 PM, jim deleskie deles...@gmail.com wrote: However, the trusted network initiative might be a good approach to start influencing operators to apply anti-spoofing mechanisms. explain how you think the 'trusted network initiative' matters in the slightest? -chris
Re: [SECURITY] Application layer attacks/DDoS attacks
Keith, I agree, we can't even get everyone including some LARGE ( I'll avoid Tier's because people get stupid around that too) networks to filter customers based on assigned netblocks. -jim On Mon, May 25, 2015 at 9:44 AM, Keith Medcalf kmedc...@dessus.com wrote: Without a concomitant increase in trustworthy, assigning greater levels of trust is fools endeavour. Whatever this trusted network initiative is, I take that it was designed by fools or government (the two are usually indistinguishable) for the purpose of creating utterly untrustworthy networks. -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ramy Hashish Sent: Sunday, 24 May, 2015 22:49 To: morrowc.li...@gmail.com; nanog@nanog.org Subject: Re: [SECURITY] Application layer attacks/DDoS attacks The idea of restricting access to a certain content during an attack on the trusted networks only will make all interested ISPs be more trusted Ramy On Mon, May 25, 2015 at 5:01 AM, Christopher Morrow morrowc.li...@gmail.com wrote: On Sat, May 23, 2015 at 9:12 PM, jim deleskie deles...@gmail.com wrote: However, the trusted network initiative might be a good approach to start influencing operators to apply anti-spoofing mechanisms. explain how you think the 'trusted network initiative' matters in the slightest? -chris
Re: [SECURITY] Application layer attacks/DDoS attacks
On 25 May 2015, at 19:44, Keith Medcalf wrote: Whatever this trusted network initiative is, I take that it was designed by fools or government (the two are usually indistinguishable) for the purpose of creating utterly untrustworthy networks. AFAICT, the 'Trusted Network Initiative' largely consists of 'all the cool kids should do multilateral peering at AMS-IX and NL-ix across vl112': https://www.thehaguesecuritydelta.com/projects/project/cyber-security/60-trusted-networks-initiative https://www.thehaguesecuritydelta.com/images/TNI_Info_Sheet_01-04-2015.pdf --- Roland Dobbins rdobb...@arbor.net
Re: [SECURITY] Application layer attacks/DDoS attacks
On 25 May 2015, at 19:49, jim deleskie wrote: I agree, we can't even get everyone including some LARGE ( I'll avoid Tier's because people get stupid around that too) networks to filter customers based on assigned netblocks. Customer of my customer [of my customer, of my customer . . . ]. It's customers all the way down. http://en.wikipedia.org/wiki/Turtles_all_the_way_down#History ; --- Roland Dobbins rdobb...@arbor.net
Re: [SECURITY] Application layer attacks/DDoS attacks
Application layer DDoS attacks , in most (all?) cases require a valid TCP/IP connection, therefore are not spoofed and BCP38 is irrelevant Sent from Steve's iPhone On May 25, 2015, at 8:00 AM, nanog-requ...@nanog.org wrote: Send NANOG mailing list submissions to nanog@nanog.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-requ...@nanog.org You can reach the person managing the list at nanog-ow...@nanog.org When replying, please edit your Subject line so it is more specific than Re: Contents of NANOG digest... Today's Topics: 1. Re: [SECURITY] Application layer attacks/DDoS attacks (Christopher Morrow) 2. Re: [SECURITY] Application layer attacks/DDoS attacks (Ramy Hashish) 3. Re: [SECURITY] Application layer attacks/DDoS attacks (Randy Bush) -- Message: 1 Date: Sun, 24 May 2015 23:01:50 -0400 From: Christopher Morrow morrowc.li...@gmail.com To: jim deleskie deles...@gmail.com Cc: Ramy Hashish ramy.ihash...@gmail.com, NANOG list nanog@nanog.org Subject: Re: [SECURITY] Application layer attacks/DDoS attacks Message-ID: cal9jlayf7v-ng_1qgehthhasod6vea5vjcsjcwhs29gpcru...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 On Sat, May 23, 2015 at 9:12 PM, jim deleskie deles...@gmail.com wrote: However, the trusted network initiative might be a good approach to start influencing operators to apply anti-spoofing mechanisms. explain how you think the 'trusted network initiative' matters in the slightest? -chris -- Message: 2 Date: Mon, 25 May 2015 06:48:41 +0200 From: Ramy Hashish ramy.ihash...@gmail.com To: morrowc.li...@gmail.com, nanog@nanog.org Subject: Re: [SECURITY] Application layer attacks/DDoS attacks Message-ID: caolsbot_sowhlzvrgb31nmmx5isis8rkxojupp9nynvu05d...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 The idea of restricting access to a certain content during an attack on the trusted networks only will make all interested ISPs be more trusted Ramy On Mon, May 25, 2015 at 5:01 AM, Christopher Morrow morrowc.li...@gmail.com wrote: On Sat, May 23, 2015 at 9:12 PM, jim deleskie deles...@gmail.com wrote: However, the trusted network initiative might be a good approach to start influencing operators to apply anti-spoofing mechanisms. explain how you think the 'trusted network initiative' matters in the slightest? -chris -- Message: 3 Date: Mon, 25 May 2015 15:18:43 +0900 From: Randy Bush ra...@psg.com To: Ramy Hashish ramy.ihash...@gmail.com Cc: North American Network Operators' Group nanog@nanog.org Subject: Re: [SECURITY] Application layer attacks/DDoS attacks Message-ID: m2r3q5b2nw.wl%ra...@psg.com Content-Type: text/plain; charset=US-ASCII The idea of restricting access to a certain content during an attack on the trusted networks only will make all interested ISPs be more trusted don't the lawyers already have enough money? End of NANOG Digest, Vol 88, Issue 25 *
Re: [SECURITY] Application layer attacks/DDoS attacks
On 25 May 2015, at 20:31, Steve via NANOG wrote: Application layer DDoS attacks , in most (all?) cases require a valid TCP/IP connection DNS query-floods are a notable exception. --- Roland Dobbins rdobb...@arbor.net
Re: [SECURITY] Application layer attacks/DDoS attacks
Application layer DDoS attacks , in most (all?) cases require a valid TCP/IP connection DNS query-floods are a notable exception. may i remind you of the dns query flood i had which you helped research? udp and tcp, from the same sources. randy
Re: [SECURITY] Application layer attacks/DDoS attacks
On 26 May 2015, at 4:27, Randy Bush wrote: may i remind you of the dns query flood i had which you helped research? udp and tcp, from the same sources. Yes - we determined that the TCP-based queries were a result of RRL, which is optimized to help with spoofed reflection/amplification attacks, but isn't intended to handle non-spoofed query-floods (hence S/RTBH, flowspec, IDMS, et. al.) like the particular ANY query-flood directed at your auths. --- Roland Dobbins rdobb...@arbor.net
Re: [SECURITY] Application layer attacks/DDoS attacks
The idea of restricting access to a certain content during an attack on the trusted networks only will make all interested ISPs be more trusted Ramy On Mon, May 25, 2015 at 5:01 AM, Christopher Morrow morrowc.li...@gmail.com wrote: On Sat, May 23, 2015 at 9:12 PM, jim deleskie deles...@gmail.com wrote: However, the trusted network initiative might be a good approach to start influencing operators to apply anti-spoofing mechanisms. explain how you think the 'trusted network initiative' matters in the slightest? -chris
Re: [SECURITY] Application layer attacks/DDoS attacks
On Sat, May 23, 2015 at 9:12 PM, jim deleskie deles...@gmail.com wrote: However, the trusted network initiative might be a good approach to start influencing operators to apply anti-spoofing mechanisms. explain how you think the 'trusted network initiative' matters in the slightest? -chris
Re: [SECURITY] Application layer attacks/DDoS attacks
Just to ask, what is the expected effect on DDoS attacks if folks implemented BCP38? How does the cost of implementing BCP38 compare to the cost of other solution attempts? H
Re: [SECURITY] Application layer attacks/DDoS attacks
--- st...@ntp.org wrote: From: Harlan Stenn st...@ntp.org Just to ask, what is the expected effect on DDoS attacks if folks implemented BCP38? --- A moot point these days. After all the years it has been out (15 years: https://tools.ietf.org/html/bcp38) it can be seen that many are not implementing it. Those that care (NANOG type folks) already have deployed it and those that don't care have not and will not. I have met a lot of the latter in recent years. Maybe I'm getting cynical? scott What's going on? Isn't everybody headed to the beach or the mountains for Memorial Day weekend? ;-)
Re: [SECURITY] Application layer attacks/DDoS attacks
Yes Harlan, you are absolutely right, even if this won't stop the botnet-based DDoS attacks, but at least will significantly decrease the volume/frequency of the volume based attacks. On the other side, the DDoS protection now become a business where all-tiers ISPs make money of, and those ISPs is the exact place where the implementation of anti-spoofing make the best sense, conflict of interests now... However, the trusted network initiative might be a good approach to start influencing operators to apply anti-spoofing mechanisms. Salam, Ramy On 23 May 2015 10:48 pm, Harlan Stenn st...@ntp.org wrote: Just to ask, what is the expected effect on DDoS attacks if folks implemented BCP38? How does the cost of implementing BCP38 compare to the cost of other solution attempts? H
Re: [SECURITY] Application layer attacks/DDoS attacks
On 24 May 2015, at 3:14, Scott Weeks wrote: Those that care (NANOG type folks) already have deployed it and those that don't care have not and will not. Concur 100%. https://app.box.com/s/r7an1moswtc7ce58f8gg --- Roland Dobbins rdobb...@arbor.net
Re: [SECURITY] Application layer attacks/DDoS attacks
While I don't think any ISP wants DDoS to make $$, I do based on experience believe that business cases have to be made for everything. With the prices pay for BW in most of the world now, ( or the last number of years) its going to be VERY hard to get anyone to allocated time/$$ or energy to do anything they don't need to, to get the bit to you. -jim On Sat, May 23, 2015 at 6:33 PM, Ramy Hashish ramy.ihash...@gmail.com wrote: Yes Harlan, you are absolutely right, even if this won't stop the botnet-based DDoS attacks, but at least will significantly decrease the volume/frequency of the volume based attacks. On the other side, the DDoS protection now become a business where all-tiers ISPs make money of, and those ISPs is the exact place where the implementation of anti-spoofing make the best sense, conflict of interests now... However, the trusted network initiative might be a good approach to start influencing operators to apply anti-spoofing mechanisms. Salam, Ramy On 23 May 2015 10:48 pm, Harlan Stenn st...@ntp.org wrote: Just to ask, what is the expected effect on DDoS attacks if folks implemented BCP38? How does the cost of implementing BCP38 compare to the cost of other solution attempts? H
[SECURITY] Application layer attacks/DDoS attacks
Hello there, As a reaction to the increasing demand -from enterprises- over the DDoS protection services, a fierce competition between vendors is about to start in this playground, big upfront investments started to happen in the tier one, tier two and tier three ISPs, IMHO this will have its aggressive effect on the volume of the DDoS attacks, and will eventually steer the mindset of the enterprises towards hosting the most critical applications/services in a well geographically-dispersed cloud and increasing the surface area using anycast then relatively decreasing the attack volume. Back to the DDoS protection, most anti-DDoS vendors are marketing their products as application layer attack DDoS defense, I am little bit confused; aren't the application firewalls -either integrated in a NGFW or a UTM- the responsible for mitigating application layer attacks? Thanks, Ramy
Re: [SECURITY] Application layer attacks/DDoS attacks
On 23 May 2015, at 19:56, Ramy Hashish wrote: I am little bit confused; aren't the application firewalls -either integrated in a NGFW or a UTM- the responsible for mitigating application layer attacks? https://app.box.com/s/a3oqqlgwe15j8svojvzl https://app.box.com/s/4h2l6f4m8is6jnwk28cg --- Roland Dobbins rdobb...@arbor.net
Re: [SECURITY] Application layer attacks/DDoS attacks
To many pieces to answer on a weekend on NANOG, but those of us that work in the DDoS space the last number of years have seen huge growth in the application layer attacks. This does not mean a decrease in volumetric attack, just that now you have to worry about both and lots of each. FW's while they have got better are still not the solution for many reasons. Moving things to the cloud helps in come cases but not all. This is an arms race, the better we protecting the better the bad guys get at attacking. -jim On Sat, May 23, 2015 at 9:56 AM, Ramy Hashish ramy.ihash...@gmail.com wrote: Hello there, As a reaction to the increasing demand -from enterprises- over the DDoS protection services, a fierce competition between vendors is about to start in this playground, big upfront investments started to happen in the tier one, tier two and tier three ISPs, IMHO this will have its aggressive effect on the volume of the DDoS attacks, and will eventually steer the mindset of the enterprises towards hosting the most critical applications/services in a well geographically-dispersed cloud and increasing the surface area using anycast then relatively decreasing the attack volume. Back to the DDoS protection, most anti-DDoS vendors are marketing their products as application layer attack DDoS defense, I am little bit confused; aren't the application firewalls -either integrated in a NGFW or a UTM- the responsible for mitigating application layer attacks? Thanks, Ramy
Re: ddos attacks
On (2013-12-20 03:24 +), Dobbins, Roland wrote: I think ipv4 udp is just going to become operationally deprecated. Too much pollution. It is really an epic amount of trash / value ratio in ipv4 udp. This isn't a realistic viewpoint. What are realistic options? a) QUIC and MinimaLT - 0 RTT overhead, like UDP - no reflection attacks, like TCP - all traffic encrypted - parity packets to match packet loss to avoid need for resends (QUIC) - non-bursty via packet pacing - solution for buffer bloat (packet pacing can be affected by changing latency) (QUIC) - CPU hit, encryption isn't free, but shouldn't be issue today - mobility, IP is not needed to recognize end-point, you can hop from WLAN to 4G without disconnecting b) ACL between transit provider and transit customer - 50k ports to configure in whole world to make UDP reflection useless DoS vector c) ACL/RPF in significant portion of access ports in whole world - i'm guessing significant portion of access ports are on autopilot with no one to change their configs, so probably not practical. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton -- ++ytti
Re: ddos attacks
On Dec 20, 2013, at 3:27 PM, Saku Ytti s...@ytti.fi wrote: c) ACL/RPF in significant portion of access ports in whole world - i'm guessing significant portion of access ports are on autopilot with no one to change their configs, so probably not practical. d) The current state of affairs persists, with no meaningful change in the foreseeable future, except the problem growing worse. My guess is that d) is the most likely outcome. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: ddos attacks
* James Braunegg Of course for any form of Anti DDoS hardware to be functional you need to make sure your network can route and pass the traffic so you can absorb the bad traffic to give you a chance cleaning the traffic. So in order for an Anti-DDoS appliance to be functional the network needs to be able to withstand the DDoS on its own. How terribly useful. Tore
Re: ddos attacks
Hi, You can also test WANGUARD, http://www.andrisoft.com/ for DDoS detection and BGP triggered blackholing. On Thu, Dec 19, 2013 at 11:32 AM, Eugeniu Patrascu eu...@imacandi.netwrote: Hi, You can also take a look at http://www.packetdam.com/ for DDoS protection. Eugeniu On Thu, Dec 19, 2013 at 10:53 AM, Tore Anderson t...@fud.no wrote: * James Braunegg Of course for any form of Anti DDoS hardware to be functional you need to make sure your network can route and pass the traffic so you can absorb the bad traffic to give you a chance cleaning the traffic. So in order for an Anti-DDoS appliance to be functional the network needs to be able to withstand the DDoS on its own. How terribly useful. Tore
Re: ddos attacks
On Wed, 18 Dec 2013 15:12:28 -0800 cb.list6 cb.li...@gmail.com wrote: I am strongly considering having my upstreams to simply rate limit ipv4 UDP. It is the simplest solution that is proactive. I understand your willingness to do this, but I'd strongly advise you to rethink such a strategy. At its simplest implementation, as soon as you do this any UDP flood of that size will then starve important UDP traffic. Yes DNS is probably the most important, but NTP is another one important one you may inadvertently harm. The facts are that during steady state less than 5% of my aggregate traffic is ipv4 udp. I had found this to be generally true years back when I was doing ops at an edu and had in fact put UDP (and other IP protocol) rate limits at the ingress edge, host facing interfaces. This actually worked pretty well, at least after I also remove the aggregate UDP rate limit in the middle of the network that led to the public Internet. So for instance, a Slammer/Sapphire worm infection was severely limited and contained to impact only a small portion of the infrastructure, meanwhile we could immediately spot the problem when the rate limit alarms were triggered. The problem with your proposal is that it complete the job for your entire network. Now perhaps if you excluded, or provided a separate limit for what you know to be important UDP flows, then the idea may be more palatable to everyday operations. John
Re: ddos attacks
On Dec 19, 2013, at 3:53 PM, Tore Anderson t...@fud.no wrote: So in order for an Anti-DDoS appliance to be functional the network needs to be able to withstand the DDoS on its own. How terribly useful. Due to the nature of network infrastructure devices and TCP/IP, it's quite necessary that they themselves are resilient in the face of attack: https://app.box.com/s/osk4po8ietn1zrjjmn8b This is a base requirement for any network operator, without exception. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: ddos attacks
On 19/12/2013 13:17, Dobbins, Roland wrote: This is a base requirement for any network operator, without exception. in fact, this comes down to cost / benefit / application analysis, without exception. Many hosting profiles don't require this sort of anti-DDoS kit. In many cases it's far cheaper to permanently disconnect a customer who is the subject of continual DoS's rather than fork out loadsamoney for boxes like this. For applications at the higher end of the spectrum, there are many situations where it's more cost effective / resilient / sensible to farm out online content to CDNs, whose infrastructure will be much better equipped to handle several tens of gigs of DDoS traffic than even a reasonably large deployment of local anti-ddos boxes. I'm sure mitigation boxes like this serve well in many situations if the cost / benefit justifies the expenditure, but as with most things, it's a case of applying the best tool for the job rather than blind application of shiny toys. Nick
Re: ddos attacks
On Dec 19, 2013, at 8:40 PM, Nick Hilliard n...@foobar.org wrote: Many hosting profiles don't require this sort of anti-DDoS kit. My post had nothing to do with 'anti-DDoS kit'. I'm sure mitigation boxes like this serve well in many situations if the cost / benefit justifies the expenditure, but as with most things, it's a case of applying the best tool for the job rather than blind application of shiny toys. 'Mitigation boxes' like what? Again, my post had nothing to do with 'mitigation boxes' or 'shiny toys'. Unless you count routers and switches as 'shiny toys'. I've never advocated the 'blind application' of any feature, function, mechanism, or 'shiny toy'. Perhaps you've confused me with someone else. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: ddos attacks
On 19/12/2013 14:08, Dobbins, Roland wrote: My post had nothing to do with 'anti-DDoS kit'. hmm, re-reading it, your post was contextually ambiguous and I read it in a different way to the way that apparently you meant. but yes, if you're doing onsite ddos scrubbing, you needs lotsabandwidth. Nick
Re: ddos attacks
On 12/18/13 8:03 PM, Jon Lewis jle...@lewis.org wrote: On Wed, 18 Dec 2013 valdis.kletni...@vt.edu wrote: On Wed, 18 Dec 2013 15:12:28 -0800, cb.list6 said: I am strongly considering having my upstreams to simply rate limit ipv4 UDP. It is the simplest solution that is proactive. What are the prospects for ipv6 UDP not suffering the same fate? Roughly 0%, but there's so little v6 traffic compared to v4, you probably don't have to worry about v6 attack traffic yet...particularly if you're not dual stack yet. :) -1 uninsightful Can't find any public data showing IPv6 as a percent of total bits, but it's certainly a meaningful percent of hits in many countries and networks. See also http://tools.ietf.org/html/draft-gont-opsec-ipv6-implications-on-ipv4-nets- 00 which describes risks from IPv6 to people who think they are running an IPv4-only network. Lee
Re: ddos attacks
On Dec 18, 2013, at 18:12, cb.list6 wrote: I am strongly considering having my upstreams to simply rate limit ipv4 UDP. It is the simplest solution that is proactive. Recently it's been said that when a protocol is query/response (like DNS), willingly suppressing responses might be as harmful as passing all the traffic. This comes from a presentation at October's DNS-OARC workshop: https://indico.dns-oarc.net//getFile.py/access?contribId=4resId=0materialId=slidesconfId=1 This is a what is possible in theory presentation, said to help you set your expectation whether this is a true threat or not. The underlying message is that while a querier is waiting for a response, there is a window of vulnerability in which a forged response might be accepted. If the responder elects not to respond, they increase the (time) duration of that window. While smart rate limiting exhibits benefits I suspect simple rate limiting might have some undesirable consequences. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 Why is it that people who fear government monitoring of social media are surprised to learn that I avoid contributing to social media?
Re: ddos attacks
On Thu, 19 Dec 2013, Lee Howard wrote: I am strongly considering having my upstreams to simply rate limit ipv4 UDP. It is the simplest solution that is proactive. What are the prospects for ipv6 UDP not suffering the same fate? Roughly 0%, but there's so little v6 traffic compared to v4, you probably don't have to worry about v6 attack traffic yet...particularly if you're not dual stack yet. :) -1 uninsightful Can't find any public data showing IPv6 as a percent of total bits, but it's certainly a meaningful percent of hits in many countries and networks. See also http://tools.ietf.org/html/draft-gont-opsec-ipv6-implications-on-ipv4-nets- 00 which describes risks from IPv6 to people who think they are running an IPv4-only network. Apparently your humor detector is defective. It was meant as a jab at the poor adoption of IPv6. I'd hope that most people on NANOG would know if they're actually doing any IPv6. I know there's more v6 where I am now, but at a previous employer, out of hundreds of hosting and colo customers, I think the ones who'd even asked about IPv6 could be counted on my fingÂers, and the ones actually doing v6 on one hand. AFAIK, my cable internet provider still isn't offering it...so if I wanted it at home, I'd have to tunnel someplace else. -- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: ddos attacks
On Thu, Dec 19, 2013 at 8:18 AM, Edward Lewis ed.le...@neustar.biz wrote: On Dec 18, 2013, at 18:12, cb.list6 wrote: I am strongly considering having my upstreams to simply rate limit ipv4 UDP. It is the simplest solution that is proactive. Recently it's been said that when a protocol is query/response (like DNS), willingly suppressing responses might be as harmful as passing all the traffic. This comes from a presentation at October's DNS-OARC workshop: https://indico.dns-oarc.net//getFile.py/access?contribId=4resId=0materialId=slidesconfId=1 This is a what is possible in theory presentation, said to help you set your expectation whether this is a true threat or not. The underlying message is that while a querier is waiting for a response, there is a window of vulnerability in which a forged response might be accepted. If the responder elects not to respond, they increase the (time) duration of that window. While smart rate limiting exhibits benefits I suspect simple rate limiting might have some undesirable consequences. I completely agree. This why i have not yet implemented IPv4 UDP rate-limiting yet, but it seems inevitable for 2014 if these attacks go on. The profile i have in mind is when UDP exceeds 5x the baseline, then tail-drop. Keep in mind, when UDP exceeds 5x the baseline, the chances are are 99% that the UDP is consuming the entire ISP pipe and everything is rate-limited due to the pipe being saturated. So, this is not a simple either / or. This is degrade UDP proactively or suffer all traffic degrading because there is a huge DDoS coming in (which is the current situation). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 Why is it that people who fear government monitoring of social media are surprised to learn that I avoid contributing to social media?
Re: ddos attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm really surprised no one has mentioned Akamai/Prolexic, especially since their recent marriage. If someone has already mentioned it: Apologies. - - ferg On 12/19/2013 4:08 AM, Adrian M wrote: Hi, You can also test WANGUARD, http://www.andrisoft.com/ for DDoS detection and BGP triggered blackholing. On Thu, Dec 19, 2013 at 11:32 AM, Eugeniu Patrascu eu...@imacandi.netwrote: Hi, You can also take a look at http://www.packetdam.com/ for DDoS protection. Eugeniu On Thu, Dec 19, 2013 at 10:53 AM, Tore Anderson t...@fud.no wrote: * James Braunegg Of course for any form of Anti DDoS hardware to be functional you need to make sure your network can route and pass the traffic so you can absorb the bad traffic to give you a chance cleaning the traffic. So in order for an Anti-DDoS appliance to be functional the network needs to be able to withstand the DDoS on its own. How terribly useful. Tore -BEGIN PGP SIGNATURE- Version: PGP Desktop 10.2.0 (Build 2317) Charset: utf-8 wj8DBQFSs0qFq1pz9mNUZTMRAlHzAJ4snDXa9MSpzSAniMUKcea0L521jQCgxHLH gBUm4ScmJlf5FsC5kJJrmZs= =tLUd -END PGP SIGNATURE- -- Paul Ferguson PGP Public Key ID: 0x63546533
Re: ddos attacks
Just about every security, network and ADC vendor out there is claiming anti-dos capabilities. Be careful when going that route and do your own validation. I suggest looking at Radware and Arbor (both leaders in the market). To successfully mitigate an attack the ideal solutions will weed out the attack and allow legitimate traffic to continue. Many of the solutions in the commercial market are not much more than rate limiters and are not very forgiving. Just as important realize while spoofed udp floods are popular they are oftened only the first vector, if successfully mitigated attackers quickly adjust and follow with more complex vectors such as application attacks toward http, ssl, dns query floods, etc.. Remember their goal is to bring you down, , divert your attention while they steal your data or perhaps transfer funds. They will go to far lengths to achieve their end result. As you can imagine it's much harder to identify the attack characteristics or for that matter the attacker in these more complex cases. In summary, I'm a firm believer in a hybrid approach with combination of infrastructure acls, rtbh, qos, URPF, tcp stack hardening, local anti-ddos appliances for application attacks and network floods under link capacity to allow you to stay up while deciding to shift routes into cloud band ability to swing up stream to cloud scrubbing center (in house or third party). Sent from my Sprint phone. - Reply message - From: Paul Ferguson fergdawgs...@mykolab.com To: nanog@nanog.org Subject: ddos attacks Date: Thu, Dec 19, 2013 2:35 PM -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm really surprised no one has mentioned Akamai/Prolexic, especially since their recent marriage. If someone has already mentioned it: Apologies. - - ferg On 12/19/2013 4:08 AM, Adrian M wrote: Hi, You can also test WANGUARD, http://www.andrisoft.com/ for DDoS detection and BGP triggered blackholing. On Thu, Dec 19, 2013 at 11:32 AM, Eugeniu Patrascu eu...@imacandi.netwrote: Hi, You can also take a look at http://www.packetdam.com/ for DDoS protection. Eugeniu On Thu, Dec 19, 2013 at 10:53 AM, Tore Anderson t...@fud.no wrote: * James Braunegg Of course for any form of Anti DDoS hardware to be functional you need to make sure your network can route and pass the traffic so you can absorb the bad traffic to give you a chance cleaning the traffic. So in order for an Anti-DDoS appliance to be functional the network needs to be able to withstand the DDoS on its own. How terribly useful. Tore -BEGIN PGP SIGNATURE- Version: PGP Desktop 10.2.0 (Build 2317) Charset: utf-8 wj8DBQFSs0qFq1pz9mNUZTMRAlHzAJ4snDXa9MSpzSAniMUKcea0L521jQCgxHLH gBUm4ScmJlf5FsC5kJJrmZs= =tLUd -END PGP SIGNATURE- -- Paul Ferguson PGP Public Key ID: 0x63546533
Re: ddos attacks
Just about every security, network and ADC vendor out there is claiming anti-dos capabilities. Be careful when going that route and do your own validation. I suggest looking at Radware and Arbor (both leaders in the market). To successfully mitigate an attack the ideal solutions will weed out the attack and allow legitimate traffic to continue. Many of the solutions in the commercial market are not much more than rate limiters and are not very forgiving. Just as important realize while spoofed udp floods are popular they are oftened only the first vector, if successfully mitigated attackers quickly adjust and follow with more complex vectors such as application attacks toward http, ssl, dns query floods, etc.. Remember their goal is to bring you down, , divert your attention while they steal your data or perhaps transfer funds. They will go to far lengths to achieve their end result. As you can imagine it's much harder to identify the attack characteristics or for that matter the attacker in these more complex cases. In summary, I'm a firm believer in a hybrid approach with combination of infrastructure acls, rtbh, qos, URPF, tcp stack hardening, local anti-ddos appliances for application attacks and network floods under link capacity to allow you to stay up while deciding to shift routes into cloud band ability to swing up stream to cloud scrubbing center (in house or third party). Sent from my Sprint phone. - Reply message - From: Paul Ferguson fergdawgs...@mykolab.com To: nanog@nanog.org Subject: ddos attacks Date: Thu, Dec 19, 2013 2:35 PM -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm really surprised no one has mentioned Akamai/Prolexic, especially since their recent marriage. If someone has already mentioned it: Apologies. - - ferg On 12/19/2013 4:08 AM, Adrian M wrote: Hi, You can also test WANGUARD, http://www.andrisoft.com/ for DDoS detection and BGP triggered blackholing. On Thu, Dec 19, 2013 at 11:32 AM, Eugeniu Patrascu eu...@imacandi.netwrote: Hi, You can also take a look at http://www.packetdam.com/ for DDoS protection. Eugeniu On Thu, Dec 19, 2013 at 10:53 AM, Tore Anderson t...@fud.no wrote: * James Braunegg Of course for any form of Anti DDoS hardware to be functional you need to make sure your network can route and pass the traffic so you can absorb the bad traffic to give you a chance cleaning the traffic. So in order for an Anti-DDoS appliance to be functional the network needs to be able to withstand the DDoS on its own. How terribly useful. Tore -BEGIN PGP SIGNATURE- Version: PGP Desktop 10.2.0 (Build 2317) Charset: utf-8 wj8DBQFSs0qFq1pz9mNUZTMRAlHzAJ4snDXa9MSpzSAniMUKcea0L521jQCgxHLH gBUm4ScmJlf5FsC5kJJrmZs= =tLUd -END PGP SIGNATURE- -- Paul Ferguson PGP Public Key ID: 0x63546533
Re: ddos attacks
On Thu, Dec 19, 2013 at 10:30 PM, den...@justipit.com den...@justipit.comwrote: Just about every security, network and ADC vendor out there is claiming anti-dos capabilities. Be careful when going that route and do your own validation. I suggest looking at Radware and Arbor (both leaders in the market). To successfully mitigate an attack the ideal solutions will weed out the attack and allow legitimate traffic to continue. Many of the solutions in the commercial market are not much more than rate limiters and are not very forgiving. Just as important realize while spoofed udp floods are popular they are oftened only the first vector, if successfully mitigated attackers quickly adjust and follow with more complex vectors such as application attacks toward http, ssl, dns query floods, etc.. Remember their goal is to bring you down, , divert your attention while they steal your data or perhaps transfer funds. They will go to far lengths to achieve their end result. As you can imagine it's much harder to identify the attack characteristics or for that matter the attacker in these more complex cases. In summary, I'm a firm believer in a hybrid approach with combination of infrastructure acls, rtbh, qos, URPF, tcp stack hardening, local anti-ddos appliances for application attacks and network floods under link capacity to allow you to stay up while deciding to shift routes into cloud band ability to swing up stream to cloud scrubbing center (in house or third party). I know a bit about Radware, and what they do is to learn a traffic pattern from where traffic usually comes and when in case of exceeding a certain threshold, they start dropping traffic from new sources never seen before and then drop some seen before traffic. This works if you are a company with a very localized visitor base (like banking site for certain national or local bank, e-shop and so on) but it kind of doesn't scale that much when it comes to we have people all over the place and we get DDoS-ed with legitimate requests that only consume server resources. What providers do in some regions is to blackhole your subnet if you reach a certain number of packets per second. It sucks, but hey, they also have infrastructure to protect. Eugeniu
Re: ddos attacks
I have to disagree with the scaling as I've personally deployed both Arbor and Radware in carrier and MSSP environments, including tier 1, CLEC and cable operators. Deployment models vary from infrastructure protection to scrubbing center and top of rack solutions. Happy to discuss with you further offlist. Cheers Dennis Sent from my Sprint phone. - Reply message - From: Eugeniu Patrascu eu...@imacandi.net To: den...@justipit.com den...@justipit.com Cc: fergdawgs...@mykolab.com, NANOG list nanog@nanog.org Subject: ddos attacks Date: Thu, Dec 19, 2013 3:51 PM On Thu, Dec 19, 2013 at 10:30 PM, den...@justipit.com den...@justipit.com wrote: Just about every security, network and ADC vendor out there is claiming anti-dos capabilities. Be careful when going that route and do your own validation. I suggest looking at Radware and Arbor (both leaders in the market). To successfully mitigate an attack the ideal solutions will weed out the attack and allow legitimate traffic to continue. Many of the solutions in the commercial market are not much more than rate limiters and are not very forgiving. Just as important realize while spoofed udp floods are popular they are oftened only the first vector, if successfully mitigated attackers quickly adjust and follow with more complex vectors such as application attacks toward http, ssl, dns query floods, etc.. Remember their goal is to bring you down, , divert your attention while they steal your data or perhaps transfer funds. They will go to far lengths to achieve their end result. As you can imagine it's much harder to identify the attack characteristics or for that matter the attacker in these more complex cases. In summary, I'm a firm believer in a hybrid approach with combination of infrastructure acls, rtbh, qos, URPF, tcp stack hardening, local anti-ddos appliances for application attacks and network floods under link capacity to allow you to stay up while deciding to shift routes into cloud band ability to swing up stream to cloud scrubbing center (in house or third party). I know a bit about Radware, and what they do is to learn a traffic pattern from where traffic usually comes and when in case of exceeding a certain threshold, they start dropping traffic from new sources never seen before and then drop some seen before traffic. This works if you are a company with a very localized visitor base (like banking site for certain national or local bank, e-shop and so on) but it kind of doesn't scale that much when it comes to we have people all over the place and we get DDoS-ed with legitimate requests that only consume server resources. What providers do in some regions is to blackhole your subnet if you reach a certain number of packets per second. It sucks, but hey, they also have infrastructure to protect. Eugeniu
Re: ddos attacks
I have to disagree with the scaling as I've personally deployed both Arbor and Radware in carrier and MSSP environments, including tier 1, CLEC and cable operators. Deployment models vary from infrastructure protection to scrubbing center and top of rack solutions. Happy to discuss with you further offlist. Cheers Dennis Sent from my Sprint phone. - Reply message - From: Eugeniu Patrascu eu...@imacandi.net To: den...@justipit.com den...@justipit.com Cc: fergdawgs...@mykolab.com, NANOG list nanog@nanog.org Subject: ddos attacks Date: Thu, Dec 19, 2013 3:51 PM On Thu, Dec 19, 2013 at 10:30 PM, den...@justipit.com den...@justipit.com wrote: Just about every security, network and ADC vendor out there is claiming anti-dos capabilities. Be careful when going that route and do your own validation. I suggest looking at Radware and Arbor (both leaders in the market). To successfully mitigate an attack the ideal solutions will weed out the attack and allow legitimate traffic to continue. Many of the solutions in the commercial market are not much more than rate limiters and are not very forgiving. Just as important realize while spoofed udp floods are popular they are oftened only the first vector, if successfully mitigated attackers quickly adjust and follow with more complex vectors such as application attacks toward http, ssl, dns query floods, etc.. Remember their goal is to bring you down, , divert your attention while they steal your data or perhaps transfer funds. They will go to far lengths to achieve their end result. As you can imagine it's much harder to identify the attack characteristics or for that matter the attacker in these more complex cases. In summary, I'm a firm believer in a hybrid approach with combination of infrastructure acls, rtbh, qos, URPF, tcp stack hardening, local anti-ddos appliances for application attacks and network floods under link capacity to allow you to stay up while deciding to shift routes into cloud band ability to swing up stream to cloud scrubbing center (in house or third party). I know a bit about Radware, and what they do is to learn a traffic pattern from where traffic usually comes and when in case of exceeding a certain threshold, they start dropping traffic from new sources never seen before and then drop some seen before traffic. This works if you are a company with a very localized visitor base (like banking site for certain national or local bank, e-shop and so on) but it kind of doesn't scale that much when it comes to we have people all over the place and we get DDoS-ed with legitimate requests that only consume server resources. What providers do in some regions is to blackhole your subnet if you reach a certain number of packets per second. It sucks, but hey, they also have infrastructure to protect. Eugeniu
Re: ddos attacks
On Dec 19, 2013, at 10:40 PM, Nick Hilliard n...@foobar.org wrote: hmm, re-reading it, your post was contextually ambiguous and I read it in a different way to the way that apparently you meant. It was quite clear what was meant, even without looking at the linked presentation, which clarified matters even further. but yes, if you're doing onsite ddos scrubbing, you needs lotsabandwidth. Once again, nothing in my post said or referred to bandwidth; in fact, simply throwing bandwidth at the problem won't work, as attackers have access to what are for all practical purposes near-infinite resources. In future, it might be a good idea to ensure that the points one attempts to make actually apply to the specific post to which one is replying. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: ddos attacks
On Dec 19, 2013, at 6:12 AM, cb.list6 cb.li...@gmail.com wrote: I am strongly considering having my upstreams to simply rate limit ipv4 UDP. QoS is a very poor mechanism for remediating DDoS attacks. It ensures that programmatically-generated attack traffic will 'squeeze out' legitimate traffic. During an attack, 100% of the attack traffic is ipv4 udp (dns, chargen, whatever). Have you checked to see whether you and/or your customers have open DNS recursors, misconfigured CPE devices, etc. which can be used as reflectors/amplifiers on your respective networks? Have you implemented NetFlow and S/RTBH? Considered building a mitigation center? http://mailman.nanog.org/pipermail/nanog/2010-January/016747.html Do you work with your peers/upstreams/downstreams to mitigate DDoS attacks when they ingress your network? There are lots of things one can do to increase one's ability to detect, classify, traceback, and mitigate DDoS attacks, yet which aren't CAPEX-intensive. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: ddos attacks
On Dec 19, 2013 4:25 PM, Dobbins, Roland rdobb...@arbor.net wrote: On Dec 19, 2013, at 6:12 AM, cb.list6 cb.li...@gmail.com wrote: I am strongly considering having my upstreams to simply rate limit ipv4 UDP. QoS is a very poor mechanism for remediating DDoS attacks. It ensures that programmatically-generated attack traffic will 'squeeze out' legitimate traffic. I agree. But ... i am pretty sure i am going to do it. Trade offs. During an attack, 100% of the attack traffic is ipv4 udp (dns, chargen, whatever). Have you checked to see whether you and/or your customers have open DNS recursors, misconfigured CPE devices, etc. which can be used as reflectors/amplifiers on your respective networks? Have you implemented NetFlow and S/RTBH? Considered building a mitigation center? http://mailman.nanog.org/pipermail/nanog/2010-January/016747.html Do you work with your peers/upstreams/downstreams to mitigate DDoS attacks when they ingress your network? Not answering any of that. But thanks for asking. There are lots of things one can do to increase one's ability to detect, classify, traceback, and mitigate DDoS attacks, yet which aren't CAPEX-intensive. I think ipv4 udp is just going to become operationally deprecated. Too much pollution. It is really an epic amount of trash / value ratio in ipv4 udp. I recommend folks enable their auth dns servers for ipv6 ... and dont run open resolvers CB --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: ddos attacks
--- cb.li...@gmail.com wrote: On Dec 19, 2013 4:25 PM, Dobbins, Roland rdobb...@arbor.net wrote: On Dec 19, 2013, at 6:12 AM, cb.list6 cb.li...@gmail.com wrote: I am strongly considering having my upstreams to simply rate limit ipv4 UDP. QoS is a very poor mechanism for remediating DDoS attacks. It ensures that programmatically-generated attack traffic will 'squeeze out' legitimate traffic. I agree. But ... i am pretty sure i am going to do it. Trade offs. - If you don't mind, after your first legit attack reply back to this thread with the details, so others can learn from it when they're looking through the archives. scott
Re: ddos attacks
* Dobbins, Roland Once again, nothing in my post said or referred to bandwidth; The post of mine, to which you replied, did. Perhaps if you had taken your own advice quoted below when replying to me, Nick wouldn't have been contextually confused. Tore In future, it might be a good idea to ensure that the points one attempts to make actually apply to the specific post to which one is replying.
Re: ddos attacks
On Dec 20, 2013, at 4:39 AM, cb.list6 cb.li...@gmail.com wrote: Not answering any of that. But thanks for asking. I wasn't asking those questions in order to elicit information from you, but rather as food for thought as you work through these issues. I think ipv4 udp is just going to become operationally deprecated. Too much pollution. It is really an epic amount of trash / value ratio in ipv4 udp. This isn't a realistic viewpoint. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: ddos attacks
Can anyone recommend a vendor solution for DDOS mitigation? We are looking for a solution that detects DDOS attacks from sflow information and automatically announces BGP /32 blackhole routes to our upstream providers, or a similar solution. Thank You. On 08/05/13 21:09 +1000, Ahad Aboss wrote: Scott, Use a DDOS detection and mitigation system with DPI capabilities to deal with traditional DDOS attack and anomalous behaviour such as worm propagation, botnet attacks and malicious subscriber activity such as flooding and probing. There are only a few vendors who successfully play in this space who provide a self healing/self defending system. Cheers Ahad -Original Message- From: sgr...@airstreamcomm.net [mailto:sgr...@airstreamcomm.net] Sent: Friday, 2 August 2013 11:37 PM To: nanog@nanog.org Subject: ddos attacks I’m curious to know what other service providers are doing to alleviate/prevent ddos attacks from happening in your network. Are you completely reactive and block as many addresses as possible or null0 traffic to the effected host until it stops or do you block certain ports to prevent them. What’s the best way people are dealing with them? Scott -- Dan White
Re: ddos attacks
We use Arbor for this - works quite well…. Peakflow/TMS .. We don’t do anything announcement wise upstream but don’t see why you couldn’t via communities... I’ve looked at one cloud based solution to date and decided appliance is a better solution specific to our needs. Paul On 12/18/2013, 11:36 AM, Dan White dwh...@olp.net wrote: Can anyone recommend a vendor solution for DDOS mitigation? We are looking for a solution that detects DDOS attacks from sflow information and automatically announces BGP /32 blackhole routes to our upstream providers, or a similar solution. Thank You. On 08/05/13 21:09 +1000, Ahad Aboss wrote: Scott, Use a DDOS detection and mitigation system with DPI capabilities to deal with traditional DDOS attack and anomalous behaviour such as worm propagation, botnet attacks and malicious subscriber activity such as flooding and probing. There are only a few vendors who successfully play in this space who provide a self healing/self defending system. Cheers Ahad -Original Message- From: sgr...@airstreamcomm.net [mailto:sgr...@airstreamcomm.net] Sent: Friday, 2 August 2013 11:37 PM To: nanog@nanog.org Subject: ddos attacks I’m curious to know what other service providers are doing to alleviate/prevent ddos attacks from happening in your network. Are you completely reactive and block as many addresses as possible or null0 traffic to the effected host until it stops or do you block certain ports to prevent them. What’s the best way people are dealing with them? Scott -- Dan White
Re: ddos attacks
Dan, If you are using sFlow for your measurements, then you might want to take a look sFlow-RT for DDoS mitigation. The following case study describes how sFlow and null routing are being used to mitigate flood attacks: http://blog.sflow.com/2013/03/ddos.html The analytics engine will detect flood attacks in less than a second and you can use the embedded scripting API to initiate automated responses. The following articles contain basic DDoS mitigation scripts - you just need to replace the block() and allow() functions with calls to expect scripts, OpenFlow rules, or REST API calls - whatever makes sense in your environment. http://blog.sflow.com/search/label/DoS This is a commercial product, but it's free to try out (no registration required): http://inmon.com/products/sFlow-RT.php Cheers, Peter On Wed, Dec 18, 2013 at 8:36 AM, Dan White dwh...@olp.net wrote: Can anyone recommend a vendor solution for DDOS mitigation? We are looking for a solution that detects DDOS attacks from sflow information and automatically announces BGP /32 blackhole routes to our upstream providers, or a similar solution. Thank You. On 08/05/13 21:09 +1000, Ahad Aboss wrote: Scott, Use a DDOS detection and mitigation system with DPI capabilities to deal with traditional DDOS attack and anomalous behaviour such as worm propagation, botnet attacks and malicious subscriber activity such as flooding and probing. There are only a few vendors who successfully play in this space who provide a self healing/self defending system. Cheers Ahad -Original Message- From: sgr...@airstreamcomm.net [mailto:sgr...@airstreamcomm.net] Sent: Friday, 2 August 2013 11:37 PM To: nanog@nanog.org Subject: ddos attacks I’m curious to know what other service providers are doing to alleviate/prevent ddos attacks from happening in your network. Are you completely reactive and block as many addresses as possible or null0 traffic to the effected host until it stops or do you block certain ports to prevent them. What’s the best way people are dealing with them? Scott -- Dan White
Re: ddos attacks
On Aug 2, 2013 10:31 AM, sgr...@airstreamcomm.net wrote: I’m curious to know what other service providers are doing to alleviate/prevent ddos attacks from happening in your network. Are you completely reactive and block as many addresses as possible or null0 traffic to the effected host until it stops or do you block certain ports to prevent them. What’s the best way people are dealing with them? Scott I am strongly considering having my upstreams to simply rate limit ipv4 UDP. It is the simplest solution that is proactive. The facts are that during steady state less than 5% of my aggregate traffic is ipv4 udp. During an attack, 100% of the attack traffic is ipv4 udp (dns, chargen, whatever). The attacks last for about 10 minutes, so manual intervention is not possible. Automated intervention has its own warts. Conclusion: ipv4 udp is a toxic dump. It is a shame that DNS (can be tcp), webrtc (should be sctp), and Google's QUIC are going to suffer the rate limited fate. My advice to them is to get aways from ipv4 udp, the problem is getting worse not better. CB
RE: ddos attacks
Scott, Use a DDOS detection and mitigation system with DPI capabilities to deal with traditional DDOS attack and anomalous behaviour such as worm propagation, botnet attacks and malicious subscriber activity such as flooding and probing. There are only a few vendors who successfully play in this space who provide a self healing/self defending system. Cheers Ahad -Original Message- From: sgr...@airstreamcomm.net [mailto:sgr...@airstreamcomm.net] Sent: Friday, 2 August 2013 11:37 PM To: nanog@nanog.org Subject: ddos attacks I’m curious to know what other service providers are doing to alleviate/prevent ddos attacks from happening in your network. Are you completely reactive and block as many addresses as possible or null0 traffic to the effected host until it stops or do you block certain ports to prevent them. What’s the best way people are dealing with them? Scott
ddos attacks
I’m curious to know what other service providers are doing to alleviate/prevent ddos attacks from happening in your network. Are you completely reactive and block as many addresses as possible or null0 traffic to the effected host until it stops or do you block certain ports to prevent them. What’s the best way people are dealing with them? Scott
Re: ddos attacks
On Fri, 02 Aug 2013 08:37:21 -0500, sgr...@airstreamcomm.net said: Iâm curious to know what other service providers are doing to alleviate/prevent ddos attacks from happening in your network. The answers will vary from nothing to extensive network planning and contracts with mitigation services, depending on the respondent's budget and how many DDoS attacks they attract per fiscal year... pgpmmuQqSTuCR.pgp Description: PGP signature
Re: ddos attacks
On Aug 02, 2013, at 09:37 , sgr...@airstreamcomm.net wrote: I’m curious to know what other service providers are doing to alleviate/prevent ddos attacks from happening in your network. Are you completely reactive and block as many addresses as possible or null0 traffic to the effected host until it stops or do you block certain ports to prevent them. What’s the best way people are dealing with them? #1: Ensure your network is BCP38 compliant. Hard to complain about others attacking you when you are not clear. And if you do not block source-address spoofing, you are not clean. As for the rest, I'll let others with more recent experience explain what they do. -- TTFN, patrick signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ddos attacks
On Aug 2, 2013, at 10:38 AM, Patrick W. Gilmore patr...@ianai.net wrote: On Aug 02, 2013, at 09:37 , sgr...@airstreamcomm.net wrote: I’m curious to know what other service providers are doing to alleviate/prevent ddos attacks from happening in your network. Are you completely reactive and block as many addresses as possible or null0 traffic to the effected host until it stops or do you block certain ports to prevent them. What’s the best way people are dealing with them? #1: Ensure your network is BCP38 compliant. Hard to complain about others attacking you when you are not clear. And if you do not block source-address spoofing, you are not clean. As for the rest, I'll let others with more recent experience explain what they do. We have had challenges with deploying BCP38, even on simple connections. We have outstanding defects in IOS-XR that prevent us from deploying it. Wherever possible we have enabled source address validation (bcp38). I do have a map of some networks that don't do this as a result of the OpenResolverProject.org data. Here's some top ASNs that can send spoofed packets: Count ASN --- 1006 18747 1004 262824 877 196753 522 29119 516 5617 514 34977 513 47570 513 12615 512 262336 512 12301 372 6739 These ASNs spoof my machine I use to send queries out to 8.8.8.8 and goole responds back to me. Likely some firewall/CPE/NAT that does this, but the provider lets those spoofed packets reach outside their network to google. I have many more of these if folks want to see a broader list. If you look at the ASN relationships involved here, it means either 3491 or 3257 allows these spoofed packets from 18747. - Jared
Re: ddos attacks
In message 1c2f65d3-1e71-4c08-9a05-ba6536fdb...@puck.nether.net, Jared Mauch writes: On Aug 2, 2013, at 10:38 AM, Patrick W. Gilmore patr...@ianai.net wrote: On Aug 02, 2013, at 09:37 , sgr...@airstreamcomm.net wrote: I'm curious to know what other service providers are doing to alleviate/prevent ddos attacks from happening in your network. Are you completely reactive and block as many addresses as possible or null0 traffic to the effected host until it stops or do you block certain ports to prevent them. What's the best way people are dealing with them? #1: Ensure your network is BCP38 compliant. Hard to complain about others attacking you when you are not clear. And if you do not block source-address spoofing, you are not clean. As for the rest, I'll let others with more recent experience explain what they do. We have had challenges with deploying BCP38, even on simple connections. We have outstanding defects in IOS-XR that prevent us from deploying it. Wherever possible we have enabled source address validation (bcp38). I do have a map of some networks that don't do this as a result of the OpenResolverProject.org data. Here's some top ASNs that can send spoofed packets: Count ASN --- 1006 18747 1004 262824 877 196753 522 29119 516 5617 514 34977 513 47570 513 12615 512 262336 512 12301 372 6739 These ASNs spoof my machine I use to send queries out to 8.8.8.8 and goole responds back to me. Likely some firewall/CPE/NAT that does this, but the provider lets those spoofed packets reach outside their network to google. I have many more of these if folks want to see a broader list. If you look at the ASN relationships involved here, it means either 3491 or 3257 allows these spoofed packets from 18747. - Jared Please publish the full list. It is long past the time when operators should be filtering out spoofed source address traffic. This sort of data should be refreshed and published quarterly. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DDoS Attacks Cause of Game Servers
On Thu, Jan 31, 2013 at 11:23:11AM +0330, Shahab Vahabzadeh sh.vahabza...@gmail.com wrote a message of 55 lines which said: Those ip addresses I send were only sample, its 5 page :D and not only those addresses. Because the attacker attacks when they have a new opponent. They DoS it long enough to win a race, then start a new fight in the game. And you are looking to target 128.141.X.Y its mine and I change it because of mailing list, maybe attackers are here. You must check the sources not destination. What Jeroen said is that source IP addresses are spoofed (which is common with UDP-based protocols such as the DNS). They are the victim's addresses, not the attacker's.
Re: DDoS Attacks Cause of Game Servers
Hi. The IPs you see is the exploited gameservers, so just contact them, and send them the link below. There is a workaround for it: http://rankgamehosting.ru/index.php?showtopic=1320 We have had problem with this in the past. Usually we get abuse complaints from the admin of the game server(s) claiming one of our customers is DDoSing them, when in fact their servers are used to DDoS our customer(s). After explaining how the DDoS works and sending them the link above, they fix the problem on their side. We have also tried to send abuse messages to the ISPs of the exploited servers, and can't say that we are pleased with the response, the small ISPs responded and took care of the issue (talked with their customers), most big ones didn't even send a ACK back. When this attack type was used (1+ year ago) we had aprox 3.5 Gbit coming from the gameservers. On 2013-01-31 07:02, Stephane Bortzmeyer wrote: On Thu, Jan 31, 2013 at 11:23:11AM +0330, Shahab Vahabzadeh sh.vahabza...@gmail.com wrote a message of 55 lines which said: Those ip addresses I send were only sample, its 5 page :D and not only those addresses. Because the attacker attacks when they have a new opponent. They DoS it long enough to win a race, then start a new fight in the game. And you are looking to target 128.141.X.Y its mine and I change it because of mailing list, maybe attackers are here. You must check the sources not destination. What Jeroen said is that source IP addresses are spoofed (which is common with UDP-based protocols such as the DNS). They are the victim's addresses, not the attacker's. -- Fredrik Holmqvist I2B (Internet 2 Business) 070-740 5033
Re: DDoS Attacks Cause of Game Servers
On Thu, 31 Jan 2013 10:34:29 +0330 Shahab Vahabzadeh sh.vahabza...@gmail.com wrote: Attacks takes only 20 or 30 minutes and it happens only 4 times in two days. I could'nt capture any packet but this is out put of my show ip accounting that time: Attacks on gaming systems or at the gamers themselves are unfortunately quite common. Many of the DNS 'IN ANY' amplification and reflection attacks for instance appear to involve online games. We've also seen some similar reflection attacks involving CoD systems as someone else alluded in a link post. Dissimilar in attack profile, but similar in target were the frequent, but brief Xbox packet floods that attempted to disrupt a gamer's session. It can be extremely difficult to assign attribution for any particular attack without a great deal of effort on your part, often in being prepared with lots of data collection in advance, plus the selfless cooperation of other network operators. The latter is often the biggest challenge given that you're often relying on the good will and limited available time of 3rd parties to work on it. While many of the most recent attacks are performing address spoofing, collecting raw packet detail and knowing where it enters your network can offer at least the start of where to look for it. You can at least start with your peer or upstream. Examine IP TTLs to gauge at least how far back those packets are coming from. If your network is diverse enough from a global routing perspective, you may be able to triangulate it better. I'd be particularly interested in working with folks in tracking down the DNS 'IN ANY' style attacks to the attack code or source attacks. Please shoot me an email off list or see me at NANOG 57 to discuss. John
Re: DDoS Attacks Cause of Game Servers
On 2013-01-31 08:04 , Shahab Vahabzadeh wrote: Hi everybody, Last two days I was under an interesting attack which comes from multiple sources to three of my ADSL users destination. You say that it comes from multiple sources to 3 of your DSL users. The below source/dest though shows that the destination is from CERN in Switzerland, you know the people who build black holes ;) The IP does not ping at the moment, but the whois indicates 'dyn' in the netname thus that is not too unsurprising. The attack make router to ran out of CPU and we had to reload it to solve. I ask those three users and they said we are only game players and all of them were kids, I think they told the true, they told we are playing: http://intl.garena.com/ Looks not like a game, just another messenger / IM client. Attacks takes only 20 or 30 minutes and it happens only 4 times in two days. I could'nt capture any packet but this is out put of my show ip accounting that time: You'll be needing a bit more info than that... and 117 packets with a total of 5148 bytes is not a lot of traffic to put anything down (unless it is a targeted attack) You might though contact the CERN NOC, if you really think something is funny there. Timestamps might be very useful to provide though, especially if the IP is really dynamic. Greets, Jeroen
Re: DDoS Attacks Cause of Game Servers
On 2013-01-31 08:53 , Shahab Vahabzadeh wrote: Those ip addresses I send were only sample, its 5 page :D and not only those addresses. And you are looking to target 128.141.X.Y its mine 128.141.0.0/16 is CERN in Switzerland. Thus not yours, but owned(*) by n...@cern.ch. (unless you work there, but I don't think that is the case...) If you have the need to hide your IP addresses, then do so properly by marking them as x.x.x.x, don't use other people's IP addresses as examples that only causes alarm bells to ring and people to do unnecessary work. And then the next time you complain people will nicely just ignore you. and I change it because of mailing list, maybe attackers are here. Obviously you have something to hide from and something that those attackers want to attack. That is the first problem that you need to solve IMHO, not having anything that needs to be attacked is a very good strategy. Greets, Jeroen (* = pre-RIR alloc, then then it is more 'owned' right? :)
DDoS Attacks Cause of Game Servers
Hi everybody, Last two days I was under an interesting attack which comes from multiple sources to three of my ADSL users destination. The attack make router to ran out of CPU and we had to reload it to solve. I ask those three users and they said we are only game players and all of them were kids, I think they told the true, they told we are playing: http://intl.garena.com/ Attacks takes only 20 or 30 minutes and it happens only 4 times in two days. I could'nt capture any packet but this is out put of my show ip accounting that time: Source Destination Packets Bytes 212.180.138.90 128.141.119.209117 5148 135.62.255.246 128.141.119.209117 5148 46.136.27.13 128.141.119.209117 5148 25.181.84.74 128.141.119.209117 5148 108.0.207.17 128.141.119.209117 5148 181.95.89.1 128.141.119.2091175148 36.161.28.42 128.141.119.209117 5148 39.130.139.157 128.141.119.209117 5148 139.81.4.106 128.141.119.209117 5148 3.229.28.78 128.141.119.2091175148 115.28.11.208128.141.119.209117 5148 206.42.151.199 128.141.119.209117 5148 213.221.149.41 128.141.119.209117 5148 81.203.234.196 128.140.109.209117 5148 43.134.71.94 128.141.119.2091175148 157.69.74.39 128.141.119.2091175148 16.206.47.71 128.141.119.2091175148 77.25.17.243 128.141.119.2091175148 If you have any information in this field and you can help me to find who is behind this, please share. Thanks -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90
Re: DDoS Attacks Cause of Game Servers
I see these type of reflection/amplification attacks pretty frequently. Some games (mostly older games) are exploitable in this manner. The attacker sends a short spoofed request, and the game server sends back a huge chunk of data aimed at you. The chances of you finding the actual source are pretty slim. Usually this type of attack is going to be coming from / going to a specific port that you (or your upstream provider) can ACL. Clayton Hi everybody, Last two days I was under an interesting attack which comes from multiple sources to three of my ADSL users destination. The attack make router to ran out of CPU and we had to reload it to solve. I ask those three users and they said we are only game players and all of them were kids, I think they told the true, they told we are playing: http://intl.garena.com/ Attacks takes only 20 or 30 minutes and it happens only 4 times in two days. I could'nt capture any packet but this is out put of my show ip accounting that time: Source Destination Packets Bytes 212.180.138.90 128.141.119.209117 5148 135.62.255.246 128.141.119.209117 5148 46.136.27.13 128.141.119.209117 5148 25.181.84.74 128.141.119.209117 5148 108.0.207.17 128.141.119.209117 5148 181.95.89.1 128.141.119.2091175148 36.161.28.42 128.141.119.209117 5148 39.130.139.157 128.141.119.209117 5148 139.81.4.106 128.141.119.209117 5148 3.229.28.78 128.141.119.2091175148 115.28.11.208128.141.119.209117 5148 206.42.151.199 128.141.119.209117 5148 213.221.149.41 128.141.119.209117 5148 81.203.234.196 128.140.109.209117 5148 43.134.71.94 128.141.119.2091175148 157.69.74.39 128.141.119.2091175148 16.206.47.71 128.141.119.2091175148 77.25.17.243 128.141.119.2091175148 If you have any information in this field and you can help me to find who is behind this, please share. Thanks -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90
Re: DDoS Attacks Cause of Game Servers
Those ip addresses I send were only sample, its 5 page :D and not only those addresses. And you are looking to target 128.141.X.Y its mine and I change it because of mailing list, maybe attackers are here. You must check the sources not destination. Thanks On Thu, Jan 31, 2013 at 11:06 AM, Jeroen Massar jer...@massar.ch wrote: On 2013-01-31 08:04 , Shahab Vahabzadeh wrote: Hi everybody, Last two days I was under an interesting attack which comes from multiple sources to three of my ADSL users destination. You say that it comes from multiple sources to 3 of your DSL users. The below source/dest though shows that the destination is from CERN in Switzerland, you know the people who build black holes ;) The IP does not ping at the moment, but the whois indicates 'dyn' in the netname thus that is not too unsurprising. The attack make router to ran out of CPU and we had to reload it to solve. I ask those three users and they said we are only game players and all of them were kids, I think they told the true, they told we are playing: http://intl.garena.com/ Looks not like a game, just another messenger / IM client. Attacks takes only 20 or 30 minutes and it happens only 4 times in two days. I could'nt capture any packet but this is out put of my show ip accounting that time: You'll be needing a bit more info than that... and 117 packets with a total of 5148 bytes is not a lot of traffic to put anything down (unless it is a targeted attack) You might though contact the CERN NOC, if you really think something is funny there. Timestamps might be very useful to provide though, especially if the IP is really dynamic. Greets, Jeroen -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90
Re: VIDEO: Mitigating DDoS Attacks: Best Practices for an Evolving Threat Landscape – NYC 12/5 #DDoS
It has been pointed out to me ( Thanks Yuri!) that I screwed up the url for the AMARA translation page for this, it is http://www.universalsubtitles.org/en-gb/videos/lvgGlpwZR0lA/info/mitigating-ddos-attacks-best-practices-for-an-evolving-threat-landscape/#video If I may say a bit more.about captioning in general... The Internet Society recently produced a paper 'Moving Forwardhttp://www.internetsociety.org/doc/internet-accessibility-internet-use-persons-disabilities-moving-forward' on the importance of increasing our efforts on accessibility, and another 'Local Content http://www.internetsociety.org/localcontent' on how important language is in fostering the growth of the Internet. Video captioning is one area where everyone, via crowd-sourcing, can easily contribute, given the tools. AMARA is just such a tool. It's a simple 4 step process. Type, sync, info, and check. One can do as much/little as one can and then leave it for someone else to pick up and continue. It's a practice we can, and should, all learn. j On Sat, Dec 15, 2012 at 5:28 AM, Joly MacFie j...@punkcast.com wrote: As promised this is the full video of PIR's recent DDoS event in NYC. I've waited to post it until we got the closed captioning done. If anyone should be willing to volunteer to help translate the captions into other languages they can do so via AMARA - http://www.universalsubtitles.org/en/videos/lvgGlpwZR0lA/info/mitigating-ddos-attacks-best-practices-for-an-evolving-threat-landscape/- it's possible to just contribute as much or as little as you have time to do. ** joly posted: The Internet Society's New York Chapter (ISOC-NY) and the New York Technology Council (NYTECH) joined the Public Interest Registry (PIR) in presenting a midday symposium Mitigating DDoS Attacks: Best Practices for an Evolving Threat Landscape in New Yor [image: Mitigating DDoS Attacks 12/5/2012]http://isoc-ny.org/p2/wp-content/uploads/2012/11/end43.pngThe Internet Society's New York Chapter (ISOC-NY http://isoc-ny.org) and the New York Technology Council (NYTECH http://nytech.org) joined the Public Interest Registry (PIR http://www.pir.org) in presenting a midday symposium Mitigating DDoS Attacks: Best Practices for an Evolving Threat Landscape http://www.pir.org/why/security/ddos in New York City on December 5 2012. Participating organizations included Afilias, Google, Neustar, Symantec, EFF, and De Natris Consult. The event was webcast live via the Internet Society Chapters Livestream Channel. Audio / transcript links are below. English Closed captions are available. MODERATOR Brian Cute - CEO, Public Interest Registry (PIR) SPEAKERS Jeff Greene - Senior Policy Counsel, Symantec Ram Mohan - EVP Chief Technology Officer, Afilias Damian Menscher -- Security Engineer, Google Miguel Ramos - Senior Product Manager, Neustar Danny McPherson - Chief Security Officer, Verisign Jillian York - Director for International Freedom of Expression, Electronic Frontier Foundation (EFF) http://www.youtube.com/watch?v=FR0660X9lGc?rel=0 - Download audio : http://isoc-ny.org/ddos/mitigating_ddos.mp3 - Download transcript: http://isoc-ny.org/ddos/mitigating_ddos.txt Comment http://isoc-ny.org/p2/4505#respondSee all commentshttp://isoc-ny.org/p2/4505#comments *Trouble clicking?* Copy and paste this URL into your browser: http://isoc-ny.org/p2/4505 -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -- - -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -- -
VIDEO: Mitigating DDoS Attacks: Best Practices for an Evolving Threat Landscape – NYC 12/5 #DDoS
As promised this is the full video of PIR's recent DDoS event in NYC. I've waited to post it until we got the closed captioning done. If anyone should be willing to volunteer to help translate the captions into other languages they can do so via AMARA - http://www.universalsubtitles.org/en/videos/lvgGlpwZR0lA/info/mitigating-ddos-attacks-best-practices-for-an-evolving-threat-landscape/- it's possible to just contribute as much or as little as you have time to do. ** joly posted: The Internet Society's New York Chapter (ISOC-NY) and the New York Technology Council (NYTECH) joined the Public Interest Registry (PIR) in presenting a midday symposium Mitigating DDoS Attacks: Best Practices for an Evolving Threat Landscape in New Yor [image: Mitigating DDoS Attacks 12/5/2012]http://isoc-ny.org/p2/wp-content/uploads/2012/11/end43.pngThe Internet Society's New York Chapter (ISOC-NY http://isoc-ny.org) and the New York Technology Council (NYTECH http://nytech.org) joined the Public Interest Registry (PIR http://www.pir.org) in presenting a midday symposium Mitigating DDoS Attacks: Best Practices for an Evolving Threat Landscape http://www.pir.org/why/security/ddos in New York City on December 5 2012. Participating organizations included Afilias, Google, Neustar, Symantec, EFF, and De Natris Consult. The event was webcast live via the Internet Society Chapters Livestream Channel. Audio / transcript links are below. English Closed captions are available. MODERATOR Brian Cute - CEO, Public Interest Registry (PIR) SPEAKERS Jeff Greene - Senior Policy Counsel, Symantec Ram Mohan - EVP Chief Technology Officer, Afilias Damian Menscher -- Security Engineer, Google Miguel Ramos - Senior Product Manager, Neustar Danny McPherson - Chief Security Officer, Verisign Jillian York - Director for International Freedom of Expression, Electronic Frontier Foundation (EFF) http://www.youtube.com/watch?v=FR0660X9lGc?rel=0 - Download audio : http://isoc-ny.org/ddos/mitigating_ddos.mp3 - Download transcript: http://isoc-ny.org/ddos/mitigating_ddos.txt Comment http://isoc-ny.org/p2/4505#respondSee all commentshttp://isoc-ny.org/p2/4505#comments *Trouble clicking?* Copy and paste this URL into your browser: http://isoc-ny.org/p2/4505 -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -- -
Mitigating DDoS Attacks: Best Practices for an Evolving Threat Landscape – NYC 12/5
[I wouldn't normally post our event notices to NANOG but I figure this might be of interest. Any of you in the NYC area we'd very much like to see you. I will tape it and post again when that's up -j] The Internet Society’s New York Chapter (ISOC-NY http://isoc-ny.org/) and the New York Technology Council (NYTECH http://nytech.org/) will join the Public Interest Registry (PIR http://www.pir.org/) in presenting a midday symposium “Mitigating DDoS Attacks: Best Practices for an Evolving Threat Landscape http://www.pir.org/why/security/ddos” in New York City on December 5 2012. Participating organizations include Afilias, Google, Neustar, M3AAWG, Symantec, EFF, and De Natris Consult. As a public service PIR are generously covering the $99 fee for all attendees – thus registration is free! The event will be webcast live via the Internet Society Chapters Livestream Channel. Distributed Denial of Service (DDoS) attacks are an all-too-common reality in today’s Internet landscape and are an escalating global problem. Whether a DDoS attack is motivated by criminal intent, like cyber extortion, or is executed as an extreme form of free expression, the resulting service interruptions can have wide-ranging effects. This program will address the motives behind and targets of DDoS attacks. It will also explore the various ways attacks are carried out, as well as mitigation techniques and the risks of “unintended consequences.” The goal is to foster a discussion and provide a platform for developing a framework of best practices to mitigate DDoS attacks. *What*: Mitigating DDoS Attacks: Best Practices for an Evolving Threat Landscape http://www.pir.org/why/security/ddos *When*: Wednesday December 5 2012 1000-1300 EST | 1500-1800 UTC *Where*: AMA Executive Conference Centerhttp://www.amaconferencecenter.org/new-york.htm, 1601 Broadway, 8th Floor, New York, NY 10019 *Program*: http://www.pir.org/why/security/ddos *Webcast*: http://www.livestream.com/internetsocietychapters *Register*: http://www.regonline.com/Register/Checkin.aspx?EventId=1108367 * *Twitter*: #DDoS https://twitter.com/search/realtime?q=%23ddos Registration is not required for the webcast, just for in person attendance. Space is limited, please do not register unless you truly intend to come. -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -- -
Re: Copyright Enforcement DoS/DDoS Attacks
No matter how they spin it, it isn't legal. Likely he won't be touched in India but in the U.S. he and the industry paying him would be facing a judge. The guy is a moron. Wanna be elitist. --Original Message-- From: Michael Painter To: nanog@nanog.org Subject: Re: Copyright Enforcement DoS/DDoS Attacks Sent: Sep 9, 2010 12:13 AM Brandon Galbraith wrote: http://www.smh.com.au/technology/technology-news/film-industry-hires-cyber-hitmen-to-take-down-internet-pirates-20100907-14ypv.html http://www.smh.com.au/technology/technology-news/film-industry-hires-cyber-hitmen-to-take-down-internet-pirates-20100907-14ypv.htmlHas anyone dealt with this in the wild? I wasn't aware DoS/DDoS attacks were suddenly legal. It's gotta' be tough reading that when you're in the slammer, eh? http://www.theregister.co.uk/2010/05/25/second_scientology_ddoser_jailed/
Re: Copyright Enforcement DoS/DDoS Attacks
man.. this guy is retarded.. good luck posing your company, face and such. lol
Re: Copyright Enforcement DoS/DDoS Attacks
He may get some business out of it, now that he has effectively put out a DDoS for hire ad. Jeff On Thu, Sep 9, 2010 at 8:56 PM, Beavis pfu...@gmail.com wrote: man.. this guy is retarded.. good luck posing your company, face and such. lol -- Jeffrey Lyon, Leadership Team jeffrey.l...@blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions
Re: Copyright Enforcement DoS/DDoS Attacks
On Sep 9, 2010, at 11:43 PM, Jeffrey Lyon wrote: He may get some business out of it, now that he has effectively put out a DDoS for hire ad. The relevant Indian authorities have been notified - my guess is that he'll soon be receiving some interesting visitors. ; --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sell your computer and buy a guitar.
Re: Copyright Enforcement DoS/DDoS Attacks
He mentioned doing work (for hire) in AU and such. I think he may be in for a rude awakening since our past experience with the Australian authorities is they are more active chasing ddos/cyber-crimes than the U.S. Those guys pull out all the stops to prosecute. (Which I am happy to see) Sadly, here in the U.S. you have little to no chance of getting assistance unless the client is a bank or very public company. In fact, that doesn't always work. (Even with direct FBI contacts in multiple field offices) Kind of a shame.. We are likely already tracking his botnets so I almost welcome it as well. Out of curiosity, I did pull some stats over the last 60 days and we have seen more attacks originating from the India area than we have seen in the past 12 months. Maybe it's a coincidence. I would almost bet this guy has never carried out an attack in his life and simply trying to gain some publicity. *shrug* --Original Message-- From: Jeffrey Lyon To: Beavis Cc: nanog@nanog.org Subject: Re: Copyright Enforcement DoS/DDoS Attacks Sent: Sep 9, 2010 11:43 AM He may get some business out of it, now that he has effectively put out a DDoS for hire ad. Jeff On Thu, Sep 9, 2010 at 8:56 PM, Beavis pfu...@gmail.com wrote: man.. this guy is retarded.. good luck posing your company, face and such. lol -- Jeffrey Lyon, Leadership Team jeffrey.l...@blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions
Re: Copyright Enforcement DoS/DDoS Attacks
He mentioned doing work (for hire) in AU and such. I think he may be in for a rude awakening since our past experience with the Australian authorities is they are more active chasing ddos/cyber-crimes than the U.S. Those guys pull out all the stops to prosecute. (Which I am happy to see) Sadly, here in the U.S. you have little to no chance of getting assistance unless the client is a bank or very public company. In fact, that doesn't always work. (Even with direct FBI contacts in multiple field offices) Kind of a shame.. We are likely already tracking his botnets so I almost welcome it as well. Out of curiosity, I did pull some stats over the last 60 days and we have seen more attacks originating from the India area than we have seen in the past 12 months. Maybe it's a coincidence. I would almost bet this guy has never carried out an attack in his life and simply trying to gain some publicity. *shrug* --Original Message-- From: Jeffrey Lyon To: Beavis Cc: nanog@nanog.org Subject: Re: Copyright Enforcement DoS/DDoS Attacks Sent: Sep 9, 2010 11:43 AM He may get some business out of it, now that he has effectively put out a DDoS for hire ad. Jeff On Thu, Sep 9, 2010 at 8:56 PM, Beavis pfu...@gmail.com wrote: man.. this guy is retarded.. good luck posing your company, face and such. lol -- Jeffrey Lyon, Leadership Team jeffrey.l...@blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions
Re: Copyright Enforcement DoS/DDoS Attacks
On Fri, Sep 10, 2010 at 1:29 AM, khatfi...@socllc.net wrote: Kind of a shame.. We are likely already tracking his botnets so I almost welcome it as well. Out of curiosity, I did pull some stats over the last 60 days and we have seen more attacks originating from the India area than we have seen in the past 12 months. There's no shortage of botted PCs and wide open dsl providers in India - extremely high # of cbl listings for massmailer bots for example. So could be any number of bots .. not like russian, brazilian etc botmasters arent able to compromise PCs in India, or in Outer Mongolia if they want to. -- Suresh Ramasubramanian (ops.li...@gmail.com)
Copyright Enforcement DoS/DDoS Attacks
http://www.smh.com.au/technology/technology-news/film-industry-hires-cyber-hitmen-to-take-down-internet-pirates-20100907-14ypv.html http://www.smh.com.au/technology/technology-news/film-industry-hires-cyber-hitmen-to-take-down-internet-pirates-20100907-14ypv.htmlHas anyone dealt with this in the wild? I wasn't aware DoS/DDoS attacks were suddenly legal. -- Brandon Galbraith Voice: 630.492.0464
Re: Copyright Enforcement DoS/DDoS Attacks
If that's the india story .. seems to be a press release fed by the vendor - which from their website also offers medical transcription and SEO On Thu, Sep 9, 2010 at 10:15 AM, Brandon Galbraith brandon.galbra...@gmail.com wrote: http://www.smh.com.au/technology/technology-news/film-industry-hires-cyber-hitmen-to-take-down-internet-pirates-20100907-14ypv.html http://www.smh.com.au/technology/technology-news/film-industry-hires-cyber-hitmen-to-take-down-internet-pirates-20100907-14ypv.htmlHas anyone dealt with this in the wild? I wasn't aware DoS/DDoS attacks were suddenly legal. -- Brandon Galbraith Voice: 630.492.0464 -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Copyright Enforcement DoS/DDoS Attacks
Brandon Galbraith wrote: http://www.smh.com.au/technology/technology-news/film-industry-hires-cyber-hitmen-to-take-down-internet-pirates-20100907-14ypv.html http://www.smh.com.au/technology/technology-news/film-industry-hires-cyber-hitmen-to-take-down-internet-pirates-20100907-14ypv.htmlHas anyone dealt with this in the wild? I wasn't aware DoS/DDoS attacks were suddenly legal. It's gotta' be tough reading that when you're in the slammer, eh? http://www.theregister.co.uk/2010/05/25/second_scientology_ddoser_jailed/
Re: Copyright Enforcement DoS/DDoS Attacks
I look forward to receiving those attacks. Jeff On Thu, Sep 9, 2010 at 9:43 AM, Michael Painter tvhaw...@shaka.com wrote: Brandon Galbraith wrote: http://www.smh.com.au/technology/technology-news/film-industry-hires-cyber-hitmen-to-take-down-internet-pirates-20100907-14ypv.html http://www.smh.com.au/technology/technology-news/film-industry-hires-cyber-hitmen-to-take-down-internet-pirates-20100907-14ypv.htmlHas anyone dealt with this in the wild? I wasn't aware DoS/DDoS attacks were suddenly legal. It's gotta' be tough reading that when you're in the slammer, eh? http://www.theregister.co.uk/2010/05/25/second_scientology_ddoser_jailed/ -- Jeffrey Lyon, Leadership Team jeffrey.l...@blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions
