Looking for contacts at Hot-Net AS12849

[Bottiger]

Looking for contacts at Hot-Net AS12849 to fix a routing issue. Contacts
listed on RIPE are unresponsive.

Re: Cogent Layer 2

[Bottiger]

  Some of their routers in Houston are blocking random flows for us since
Friday. Support has been contacted and they claim nothing is wrong. It is
still broken today.

On Wed, Oct 14, 2020 at 10:38 AM Mike Hammett  wrote:

> Are any legitimate beefs with Cogent limited to their IP policies, BGP
> session charges, and peering disputes? Meaning, would using them for layer
> 2 be reasonable?
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
> 
>

Re: Abuse Desks

[Bottiger]

It is rather easy to block SSH cracking attempts from your own side. Rarely
do they put any significant load on your network or computer.

I would sympathize with this except for the fact that abuse desks won't
even respond to DDoS attacks, something that can't be fixed on your own end
without spending a lot of money.

That needs to be fixed first before worrying about password cracking.

On Tue, Apr 28, 2020 at 8:58 AM Mike Hammett  wrote:

> I noticed over the weekend that a Fail2Ban instance's complain function
> wasn't working. I fixed it. I've noticed a few things:
>
> 1) Abusix likes to return RIR abuse contact information. The vast majority
> are LACNIC, but it also has kicked back a couple for APNIC and ARIN. When I
> look up the compromised IP address in Abusix via the CLI, the APNIC and
> ARIN ones return both ISP contact information and RIR information. When I
> look them up on the RIR's whois, it just shows the ISP abuse information.
> Weird, but so rare it's probably just an anomaly. However, almost
> everything I see in LACNIC's region is returned with only the LACNIC abuse
> information when the ones I've checked on LACNIC's whois list valid abuse
> information for that prefix. Can anyone confirm they've seen similar
> behavior out of Abusix? I reached out to them, but haven't heard back.
> 2) Digital Ocean hits my radar far more than any other entity.
> 3) Azure shows up a lot less than GCP or AWS, which are about similar to
> each other.
> 4) Around 5% respond saying it's been addressed (or why it's not in the
> event of security researchers) within a couple hours. The rest I don't
> know. I've had a mix of small and large entities in that response.
> 5) HostGator seems to have an autoresponder (due to a 1 minute response)
> that just indicates that you sent nothing actionable, despite the report
> including the relevant log file entries.
> 6) Charter seems to have someone actually looking at it as it took them 16
> - 17 hours to respond, but they say they don't have enough information to
> act on, requesting relevant log file entries...  which were provided in the
> initial report and are even included in their response. They request
> relevant log file entries with the date, time, timezone, etc. all in the
> body in plain text, which was delivered.
> 7) The LACNIC region has about 1/3 of my reports.
>
>
>
> Do these mirror others' observations with security issues and how abuse
> desks respond?
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>

Re: Best way to get foreign ISPs to shut down DDoS reflectors?

[Bottiger]

I highly doubt NTT or any other major transit provider would ever cut off
Korea Telecom or China Telecom. And these are reflectors, they are not part
of a botnet.

On Thu, Apr 23, 2020 at 5:11 PM TJ Trout  wrote:

> Bottiger,
>
> If what you are saying is true and can be backed by documentation, I would
> start at the abuse contact for the offending 'Amplifier' and then start
> working your way up the transits of the offending AS# until someone cuts
> them off.
> The Squeaky wheel gets the grease!
>
> On Thu, Apr 23, 2020 at 3:33 PM Bottiger  wrote:
>
>> There are many decent options for ddos protection in the US and Europe,
>> however there are very few in Brazil and Asia that support BGP. Servers and
>> bandwidth in these areas are much more expensive.
>>
>> Even though we are already doing anycast to split up the ddos attack, a
>> majority of the attack traffic is now ending up in these expensive areas,
>> and to top it off, these ISPs won't respond to abuse emails.
>>
>> It makes me wonder what the point of these abuse email are and if the
>> regional registries have any power to force them to reply.
>>
>> On Thu, Apr 23, 2020 at 3:12 PM Compton, Rich A 
>> wrote:
>>
>>> Good luck with that.  😊  As Damian Menscher has presented at NANOG,
>>> even if we do an amazing job and shut down 99% of all DDoS reflectors,
>>> there will still be enough bandwidth to generate terabit size attacks.
>>> https://stats.cybergreen.net
>>>
>>> I think we need to instead collectively focus on stopping the spoofed
>>> traffic that allows these attacks to be generated in the first place.
>>>
>>> -Rich
>>>
>>>
>>>
>>> *From: *NANOG Email List  on behalf of
>>> Bottiger 
>>> *Date: *Thursday, April 23, 2020 at 3:32 PM
>>> *To: *Siyuan Miao 
>>> *Cc: *NANOG list 
>>> *Subject: *Re: Best way to get foreign ISPs to shut down DDoS
>>> reflectors?
>>>
>>>
>>>
>>> We are unable to upgrade our bandwidth in those areas. There are no
>>> providers within our budget there at the moment. Surely there must be some
>>> way to get them to respond.
>>>
>>>
>>>
>>> On Thu, Apr 23, 2020 at 2:23 PM Siyuan Miao  wrote:
>>>
>>> It won't work.
>>>
>>>
>>>
>>> Get a good DDoS protection and forget about it.
>>>
>>>
>>>
>>> On Fri, Apr 24, 2020 at 5:17 AM Bottiger  wrote:
>>>
>>> Is there a guide on how to get foreign ISPs to shut down reflectors used
>>> in DDoS attacks?
>>>
>>>
>>>
>>> I've tried sending emails listed under abuse contacts for their regional
>>> registries. Either there is none listed, the email is full, email does not
>>> exist, or they do not reply. Same results when sending to whatever other
>>> email they have listed.
>>>
>>>
>>>
>>> Example Networks:
>>>
>>>
>>>
>>> CLARO S.A.
>>>
>>> Telefonica
>>>
>>> China Telecom
>>>
>>> Korea Telecom
>>>
>>> The contents of this e-mail message and
>>> any attachments are intended solely for the
>>> addressee(s) and may contain confidential
>>> and/or legally privileged information. If you
>>> are not the intended recipient of this message
>>> or if this message has been addressed to you
>>> in error, please immediately alert the sender
>>> by reply e-mail and then delete this message
>>> and any attachments. If you are not the
>>> intended recipient, you are notified that
>>> any use, dissemination, distribution, copying,
>>> or storage of this message or any attachment
>>> is strictly prohibited.
>>>
>>

Re: Best way to get foreign ISPs to shut down DDoS reflectors?

[Bottiger]

There are many decent options for ddos protection in the US and Europe,
however there are very few in Brazil and Asia that support BGP. Servers and
bandwidth in these areas are much more expensive.

Even though we are already doing anycast to split up the ddos attack, a
majority of the attack traffic is now ending up in these expensive areas,
and to top it off, these ISPs won't respond to abuse emails.

It makes me wonder what the point of these abuse email are and if the
regional registries have any power to force them to reply.

On Thu, Apr 23, 2020 at 3:12 PM Compton, Rich A 
wrote:

> Good luck with that.  😊  As Damian Menscher has presented at NANOG, even
> if we do an amazing job and shut down 99% of all DDoS reflectors, there
> will still be enough bandwidth to generate terabit size attacks.
> https://stats.cybergreen.net
>
> I think we need to instead collectively focus on stopping the spoofed
> traffic that allows these attacks to be generated in the first place.
>
> -Rich
>
>
>
> *From: *NANOG Email List  on behalf of Bottiger <
> bottige...@gmail.com>
> *Date: *Thursday, April 23, 2020 at 3:32 PM
> *To: *Siyuan Miao 
> *Cc: *NANOG list 
> *Subject: *Re: Best way to get foreign ISPs to shut down DDoS reflectors?
>
>
>
> We are unable to upgrade our bandwidth in those areas. There are no
> providers within our budget there at the moment. Surely there must be some
> way to get them to respond.
>
>
>
> On Thu, Apr 23, 2020 at 2:23 PM Siyuan Miao  wrote:
>
> It won't work.
>
>
>
> Get a good DDoS protection and forget about it.
>
>
>
> On Fri, Apr 24, 2020 at 5:17 AM Bottiger  wrote:
>
> Is there a guide on how to get foreign ISPs to shut down reflectors used
> in DDoS attacks?
>
>
>
> I've tried sending emails listed under abuse contacts for their regional
> registries. Either there is none listed, the email is full, email does not
> exist, or they do not reply. Same results when sending to whatever other
> email they have listed.
>
>
>
> Example Networks:
>
>
>
> CLARO S.A.
>
> Telefonica
>
> China Telecom
>
> Korea Telecom
>
> The contents of this e-mail message and
> any attachments are intended solely for the
> addressee(s) and may contain confidential
> and/or legally privileged information. If you
> are not the intended recipient of this message
> or if this message has been addressed to you
> in error, please immediately alert the sender
> by reply e-mail and then delete this message
> and any attachments. If you are not the
> intended recipient, you are notified that
> any use, dissemination, distribution, copying,
> or storage of this message or any attachment
> is strictly prohibited.
>

Re: Best way to get foreign ISPs to shut down DDoS reflectors?

[Bottiger]

We are unable to upgrade our bandwidth in those areas. There are no
providers within our budget there at the moment. Surely there must be some
way to get them to respond.

On Thu, Apr 23, 2020 at 2:23 PM Siyuan Miao  wrote:

> It won't work.
>
> Get a good DDoS protection and forget about it.
>
> On Fri, Apr 24, 2020 at 5:17 AM Bottiger  wrote:
>
>> Is there a guide on how to get foreign ISPs to shut down reflectors used
>> in DDoS attacks?
>>
>> I've tried sending emails listed under abuse contacts for their regional
>> registries. Either there is none listed, the email is full, email does not
>> exist, or they do not reply. Same results when sending to whatever other
>> email they have listed.
>>
>> Example Networks:
>>
>> CLARO S.A.
>> Telefonica
>> China Telecom
>> Korea Telecom
>>
>

Best way to get foreign ISPs to shut down DDoS reflectors?

[Bottiger]

Is there a guide on how to get foreign ISPs to shut down reflectors used in
DDoS attacks?

I've tried sending emails listed under abuse contacts for their regional
registries. Either there is none listed, the email is full, email does not
exist, or they do not reply. Same results when sending to whatever other
email they have listed.

Example Networks:

CLARO S.A.
Telefonica
China Telecom
Korea Telecom

Re: UDP/123 policers & status

[Bottiger]

>
> but why isn't BCP 38 widely deployed?
>

Because it costs time and money. People have been asking for it to be
implemented for decades. It is never going to be deployed on every network.

What fraction of the
> world does implement BCP 38?
>

 Not enough. Everyone has to use it for it to work. Otherwise the hackers
will still find a network that doesn't have it.

I'd also be interested in general background info on DDoS.  Who is DDoS-ing
> whom and/or why?  Is this gamers trying to get an advantage on a
> competitor?
> Bad guys making a test run to see if the server can be used for a real
> run?


Most motivations for attacks can't be traced. But this is not just a gaming
problem. It is used to extort businesses for money, destroy competitors,
shutdown government critics, fame.

 Is DDoS software widely available on the dark web?


You don't need the dark web. It is widely available on Github like most
other attack types.

https://github.com/search?q=ntp+ddos

Broken protocols need to be removed and blacklisted at every edge. Pushing
the responsibility to BCP38 is unrealistic.


On Mon, Mar 23, 2020 at 7:43 AM Hal Murray <
hgm+na...@ip-64-139-1-69.sjc.megapath.net> wrote:

> Steven Sommars said:
> > The secure time transfer of NTS was designed to avoid amplification
> attacks.
>
> I work on NTP software (ntpsec).  I have a couple of low cost cloud
> servers in
> the pool where I can test things and collect data.
>
> I see bursts of 10K to several million packets "from" the same IP Address
> at
> 1K to 10K packets per second.  Ballpark of 100 events per day, depending
> on
> the size cutoff.  I saw one that lasted for most of a day at 1K
> packeets/sec.
>
> All the packets I've seen have been vanilla NTP requests - no attempt at
> amplification.  I'm only checking a very small fraction of the garbage.
>
> I haven't seen any pattern in the target IP Address.  Reverse DNS names
> that
> look like servers are rare.  I see legitimate NTP requests from some of
> the
> targets.
>
> Would data be useful?  If so, who, what, ... (poke me off list)
>
> I don't see any good solution that a NTP server can implement.  If I block
> them all, the victim can't get time.  If I let some fraction through, that
> just reduces the size of the DDoS.  I don't see a fraction that lets
> enough
> through so the victim is likely to get a response to a legitimate request
> without also getting a big chunk of garbage.  I'm currently using a
> fraction
> of 0.  If the victim is using several servers, one server getting knocked
> out
> shouldn't be a big deal.  (The pool mode of ntpd should drop that system
> and
> use DNS to get another.)
>
> If NTS is used, it would be possible to include the clients IP Address in
> the
> cookie and only respond to requests with cookies that were issued to the
> client.  That has privacy/tracking complications.
>
> --
>
> I don't want to start a flame war, but why isn't BCP 38 widely deployed?
> Can
> somebody give me a pointer to a talk at NANOG or such?  What fraction of
> the
> world does implement BCP 38?
>
> I'd also be interested in general background info on DDoS.  Who is
> DDoS-ing
> whom and/or why?  Is this gamers trying to get an advantage on a
> competitor?
> Bad guys making a test run to see if the server can be used for a real
> run?
> Is DDoS software widely available on the dark web?  ...
>
>
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
>

Re: TCP-AMP DDoS Attack - Fake abuse reports problem

[Bottiger]

I thought you said this on your blog? 
https://blog.octovpn.com/the-ddos-that-bans-you/ 
[https://blog.octovpn.com/the-ddos-that-bans-you/] "We are the first VPN on the 
market to come up with a solution for this, and that's why we are who we are. 
We're keeping our method completely private for now."

Did the method stop working? What was the method?

Since you are reselling OVH, you should ask them to block syn-ack spam. it 
should be trivial for them to block. I would be surprised if it wasn't 
automatically detected already.

Short of bribing Sony, I don't see how you can stop random honey pots from 
banning spoofed ips. There's no technical solution for that.

Re: Is anyone able to contact GTT?

[Bottiger]

One was mail sent from mxroute, the other was through gmail. noc at gtt.net
is listed as their contact at RIPE.

I tried using the inoc email on December 10th about 8 days ago, still no
reply.

I also asked one of my hosts which I think is a big customer of theirs, and
they got a reply yesterday asking for the source IP for a traceroute when
they could have just used any of the IPs near the top to see the issue.

I hope I don't have to wait another week for another reply. 1 week to reply
to a large customer is surprisingly long.

On Sat, Dec 14, 2019 at 11:19 AM Mark Milhollan  wrote:

> On Tuesday 2019-12-10 06:58, Matt Harris wrote:
> >On Tue, Dec 10, 2019 at 8:51 AM Bottiger  wrote:
>
> >>I sent an email to noc at gtt.net from 2 different emails and both got a
> >>reply saying:
> >>
> >> 5.1.0 - Unknown address error 550-'5.4.1 Recipient address rejected:
> >> Access denied [HE1EUR01FT058.eop-EUR01.prod.protection.outlook.com]'
> >>
> >>Not sure if this means if they are blocking my email or if their email is
> >>broken.
>
> Could be either, but my money is on them blocking that particular
> address (block perhaps) because it has been sending messages that seem
> to be low quality aka much of which seemed to be spam.  How different
> were the sources?  If both were Office 365 that turns out to not be very
> different and I'll stick with them hating on that particular address
> (block).  If the second was a service provider not using O365 then it
> swings to being more likely that GTT hates all those source (email)
> addresses/domains.
>
> >The response indicates that the recipient address was
> >rejected, not the sender address
>
> It is common to postpone rejections and deferrals until the RCPT TO
> phase, when possible.
>
>
> /mark
>

Is anyone able to contact GTT?

[Bottiger]

I sent an email to noc at gtt.net from 2 different emails and both got a
reply saying:

5.1.0 - Unknown address error 550-'5.4.1 Recipient address rejected: Access
denied [HE1EUR01FT058.eop-EUR01.prod.protection.outlook.com]'

Not sure if this means if they are blocking my email or if their email is
broken.

Anyone have contacts at Bharti Airtel?

[Bottiger]

Does anyone have any contacts at Bharti Airtel? I either get no response or
full inbox for emails in their WHOIS at AS9498 and AS24560.

Contact for Hetzner AS24940 and Host Europe AS20773?

[bottiger]

Anyone know of any contacts for Hetzner AS24940 and Host Europe AS20773?

Thanks in advance.

Re: SNMP DDoS: the vulnerability you might not know you have

[bottiger]

I realize the root cause is security-oblivious designers and one level
below that, lack of BCP38.

But realistically those 2 problems are not going to be solved any time
in the next decade. I have tested 7 large hosting networks only one of
them had BCP38.

To my knowledge it is practically impossible for someone outside a
multi-homed network to know if they allow spoofing which means it will
be difficult to punish. It also cost time and money to maintain these
ACLs, much more than blocking the occasional wide-spread protocol with
8000x amplification every couple of years.

I am here to talk about solutions today. BCP38 has been repeated to
death and people aren't going to start doing it because I said so. The
fact that the amplification factor is so high means that you need to
ensure near 100% conformity even if everyone started to become BCP38
compliant today.

On Wed, Jul 31, 2013 at 4:42 PM, Jimmy Hess  wrote:
> On 7/31/13, Blake Dunlap  wrote:
>> I bet blocking all SYN packets and non related flow UDP packets to
>> customers would be even more effective. Why don't we do that and be done
>> with it instead of playing whack a mole every 3 months when someone finds
>> some new service that was poorly designed so that it can be used to send a
>> flood?
>
> Because it breaks applications that people are paying to be able to use.
>
> The way I see it;  more and more samples keep getting found about
> protocols abused because networks have not implemented BCP38.
>
> The latest SNMP trend is just another uptick to the sample size,  and
> proof that  Closing off   perfectly OK  recursive DNS services  is
> totally inadequate and not a useful long-term fix  to the problem of
> DDoS or IP/UDP reflection attacks.
>
> Asking folks to improve the security of access to their SNMP instances
> is just chasing the latest exploit implementation,  with no attention
> to the vulnerability or the root cause
>
> --
> -JH
>

Re: SNMP DDoS: the vulnerability you might not know you have

[bottiger]

This vulnerability has been present ever since SNMP v2 was announced
back in 1993.

There is a reason why the biggest attacks these days are from
protocols that are decades old like DNS and Chargen.

People making widely spread protocols these days are aware of the
problem and are usually able to get their software to auto-update.

Enforcing source IP filtering seems like a lost cause. Not much
progress has been made that I can tell and it is difficult to discover
if the network allows it without being inside it.

I don't see many uses for unsecured SNMP access so this is not like
blocking all syn and udp packets.

On Wed, Jul 31, 2013 at 2:29 PM, Blake Dunlap  wrote:
> I bet blocking all SYN packets and non related flow UDP packets to
> customers would be even more effective. Why don't we do that and be done
> with it instead of playing whack a mole every 3 months when someone finds
> some new service that was poorly designed so that it can be used to send a
> flood?
>
> Yes, I'm being sarcastic above.
>
> This is hardly the first finger of death amplification attack, and I
> strongly doubt it'll be the last. Years ago it was smurf, then Quake
> servers, then DNS, then Battlefield boxes, etc etc. Now it seems to be snmp
> and recently chargen, and tomorrow it'll be some peer 2 peer service, the
> next day it'll be a voice app. It will never end, and breaking the internet
> port by port doesn't do anything to make it better.
>
> I've been the victim of week long DDoS attacks that took down our
> upstreams, not to mention us, and I still maintain the above.
>
> It works better to fix the design issues than to play whack a mole by
> blocking every imaginable service to your customers that responds to the
> public with data larger than a FIN. Like getting their providers to more
> proactively police their spew, manufactures to stop making negligent
> devices, or implementing more intelligent filter communication so the only
> option doesn't begin with calling your provider and asking them over the
> phone to block X ip for you since you're off the internet.
>
> Maybe even look into liability laws for allowing said attacks to originate
> from your customers and not doing anything about it, or being manufacturer
> of said devices that harm others through their lack of due diligence
> implementing proper security. It's still way more effective than trying to
> fix the *last instance* of the problem, instead of it's reasons for
> enduring as an issue at a global scale.
>
> -Blake
>
>
> On Wed, Jul 31, 2013 at 3:46 PM, Dobbins, Roland  wrote:
>
>>
>> On Aug 1, 2013, at 3:11 AM, bottiger wrote:
>>
>> > The most disturbing part is the lack of logging.
>>
>> Flow telemetry can be of use in this instance.
>>
>> ---
>> Roland Dobbins  // <http://www.arbornetworks.com>
>>
>>   Luck is the residue of opportunity and design.
>>
>>-- John Milton
>>
>>
>>

Re: SNMP DDoS: the vulnerability you might not know you have

[bottiger]

Public SNMP being exploited for 8000x amplification is a very serious
issue. It is
arguably worse than open email relays.

Not only does it expose critical information from your users
but it offers the largest possible amplified DDoS by far, likely
bigger than DNS when you take into account the amplification size and
ubiquity. It will also cause your user's device to lag.

The most disturbing part is the lack of logging. We have tried
reporting these exploited servers for many weeks and because of the
logging problem most of them never get shut down because they just
assume they were being spoofed. We even had replies threatening to
block us because they thought were because they couldn't see they
were sending anything. When we were reported chargen attacks we
had much more positive responses.

Maybe you could refine the block by denying SNMP requests with the
public string. As network operators some compromises must be
made for a problem of this magnitude instead of just saying that you
should only be the best dumb pipe you can be.

We have seen attacks large enough to disturb 10G uplinks so as network
administrators you should not ignore this issue because you think it
is a small problem affecting only end users. This will affect you once
more people figure out how to get 8000x amplification from it.

It is great news that Comcast is trying to proactively solve this
problem on their network and hope that more networks would follow
their example.

On Wed, Jul 31, 2013 at 8:24 AM, Blake Dunlap  wrote:
> Agreed, but progressively breaking every service on the internet at the edge
> because you think there might possibly be an issue just leads to bad places.
>
> Get better defaults sure, but don't slowly turn the internet into a cable
> distribution system because "they're just users". It's bad enough already,
> don't make it worse trying to solve every issue with the nuclear option
> before trying anything else.
>
> -Blake
>
>
> On Wed, Jul 31, 2013 at 10:17 AM, Thomas St-Pierre 
> wrote:
>>
>> The problem isn't the people on this list leaving the public snmp
>> community on their devices, it's the vendors of home routers leaving it
>> there in their devices. Normal end users don't know or even care what snmp
>> is. (nor can we expect them too)
>>
>> A simple scan of a large cable/dsl ISP's address space will likely net you
>> tens of thousands of devices which respond to the "public" snmp community.
>>
>> Thomas
>>
>>
>>
>> On 13-07-31 10:57 AM, "Blake Dunlap"  wrote:
>>
>> >This looks like more a security issue with the devices, not border
>> >security
>> >issues.
>> >
>> >If you're seeing replies of that size, it means the devices themselves
>> > are
>> >set up to allow public queries of their information (not secured by even
>> >keys), which no one should be comfortable with. People should never be
>> >leaving the public access snmp strings on devices even if they are
>> >internal. Edge blocking just masks the real issue.
>> >
>> >
>> >-Blake
>> >
>> >
>> >On Tue, Jul 30, 2013 at 11:25 PM, bottiger  wrote:
>> >
>> >> Before you skim past this email because you already read the Prolexic
>> >> report on it or some other article on the internet, there are 2
>> >> disturbing properties that I haven't found anywhere else online.
>> >>
>> >> 1) After sending abuse emails to many networks, we received many angry
>> >> replies that they monitored their traffic for days without seeing
>> >> anything (even as we were being attacked) and that their IPs were
>> >> spoofed and would block us for spamming them.
>> >>
>> >> What we discovered was that their firewalls/routers/gateways coming
>> >> from vendors like Cisco and SonicWall apparently didn't record SNMP
>> >> traffic going in or out of themselves. We confirmed this multiple
>> >> times by running a query to an IP that was claimed to be clean and
>> >> watching the response come 10-60 seconds later because the device was
>> >> being so heavily abused.
>> >>
>> >> 2) SNMP reflection offers the largest amplification factor by far,
>> >> even surpassing DNS, Chargen, or NTP by a wide margin. I have tested a
>> >> 68 byte query and received responses of up to 30,000 to 60,000 bytes.
>> >> The trick is to use GetBulkRequest to start enumerating from the first
>> >> OID and setting max repetitions to a large number. This is contrary to
>> >> the other articles online which suggest a much smaller amplification
>> >> factor with other queries.
>> >>
>> >> This protocol is also prevalent in many devices ranging from routers
>> >> to printers.
>> >>
>> >> To solve this problem you should block SNMP traffic coming from
>> >> outside your network and whitelist outside IPs that require it.
>> >>
>> >>
>>
>

SNMP DDoS: the vulnerability you might not know you have

[bottiger]

Before you skim past this email because you already read the Prolexic
report on it or some other article on the internet, there are 2
disturbing properties that I haven't found anywhere else online.

1) After sending abuse emails to many networks, we received many angry
replies that they monitored their traffic for days without seeing
anything (even as we were being attacked) and that their IPs were
spoofed and would block us for spamming them.

What we discovered was that their firewalls/routers/gateways coming
from vendors like Cisco and SonicWall apparently didn't record SNMP
traffic going in or out of themselves. We confirmed this multiple
times by running a query to an IP that was claimed to be clean and
watching the response come 10-60 seconds later because the device was
being so heavily abused.

2) SNMP reflection offers the largest amplification factor by far,
even surpassing DNS, Chargen, or NTP by a wide margin. I have tested a
68 byte query and received responses of up to 30,000 to 60,000 bytes.
The trick is to use GetBulkRequest to start enumerating from the first
OID and setting max repetitions to a large number. This is contrary to
the other articles online which suggest a much smaller amplification
factor with other queries.

This protocol is also prevalent in many devices ranging from routers
to printers.

To solve this problem you should block SNMP traffic coming from
outside your network and whitelist outside IPs that require it.