Re: Spitballing IoT Security

[Pierre Lamy]

On 30/10/2016 12:43 AM, Eric S. Raymond wrote:
> Ronald F. Guilmette :
>> Two kids with a modest amount of knowledge
>> and a lot of time on their hands can do it from their mom's basement.
> 
> I in turn have to call BS on this.  If it were really that easy, we'd
> be inundated by Mirais -- we'd have several attacks a *day*.
> 

It's not easy, Mirai was closed source until the actor released it. We
see a pattern again and again, where the bad guys find a private
monetization strategy, milk it, and get out before too much attention is
focused on just them. By dumping the code, the Mirai actors obfuscate
attribution.

Now that the code is public, we see a huge surge in dumb & pointless
attacks against gaming/mod sites, Dyn, public schools and so on. We also
see bad code "improvements" which were recently referenced.

http://motherboard.vice.com/read/wannabe-hackers-are-adding-terrible-and-stupid-features-to-mirai

The long term problem isn't any manufacturer or Mirai, it's going to be
the long tail of IoT devices that never see a patch, deployed by people
who don't know anything about security (nor should they need to... flame
suit on). When millions of any type of device are put online, times
thousands of products, it only takes one bad guy's "a-ha" moment for
this to happen again. They'll milk it for a while, the attack
vector/method will get pushed down to the skid level, and we'll see a
massive increase in un-targeted attacks by those script kiddies until
the cycle repeats. There's an endless fresh supply of script kiddies.

While I agree with BCP38 etc, it wouldn't have prevented Mirai.
Self-update functions at some point for these devices are going to get
borked as well, such as a company going bust or forgetting to renew
their auto-update target domain. If you can't get (thousands?) of major
operators to deploy common sense security configurations, how will
similar best practices be implemented by tens of thousands of
manufacturers? Putting device regulations in one country won't impact
the rest of the internet's connected devices either.

Solutions...? Someone's going to have to take out a hammer, not a
scalpel, for these issues.

Re: BGP FlowSpec

[Pierre Lamy]

I was looking into using this mechanism for blocking DDoS on Juniper
devices, but at the time, they only supported 8k flowspec entries/routes
and this was not sufficient to deal with the problem. My fallback was to
poison the routing table with null routes, but the problem with this was
that it didn't address inbound traffic, only the replies.

We ended up ditching all of this in favor of a third party external
scubbing vendor. They tend to prefer big honking boxes running
signatures whereever possible to drop identified malicious traffic.

When you get right down to it, the vendors have a lot of experience
day-to-day performing mitigations, and flowspec (or other BGP
mitigations) are more useful to carriers and ISPs to null out the
destination rather than the source.

Pierre

On 29/04/2016 9:08 AM, dennis wrote:
> 
> 
> Hi
> Amplification attacks and syn floods are just touching the surface of ddos 
> attack vectors.  You should look into some industry reports:
> Here are a couple examples to get you started.
> https://www.radware.com/ert-report-2015/
> http://www.verizonenterprise.com/verizon-insights-lab/dbir/2016/
> 
> Sent via the Samsung GALAXY S® 5, an AT 4G LTE smartphone
> 
>  Original message 
> From: Martin Bacher  
> Date: 4/29/2016  2:02 AM  (GMT-08:00) 
> To: Tyler Haske  
> Cc: NANOG list  
> Subject: Re: BGP FlowSpec 
> 
> Hello Tyler,
> 
> thanks for your reply.
> 
>> Am 28.04.2016 um 17:37 schrieb Tyler Haske :
>>
>> Martin,
>>
>>
>>> Last but not least: I am also looking for anonymized statistical data about 
>>> DDoS attacks which I could use in the thesis. I am mainly interested in 
>>> data about the
>>> type of attacks, attack time, sources, source and destination ports, and so 
>>> on. I know this something which is generally not shared, so I would really 
>>> appreciate it if
>>> someone would be able to share such data.
>>
>> Many companies are extremely reluctant to share their attack data. But 
>> that's OK, because there are other ways to get it.
>>
>> Have you investigated backscatter analysis? It's used to see ongoing and 
>> current Internet scope DDoS attacks.
> I just had a look on that and thought that its only be able to detect some of 
> the attacks. You might not detect large state of the art reflection and 
> amplification attacks with that method. But i think it is useful for some 
> sort of attacks like SYN flood. Do you agree?
> 
>>
>> Inferring Internet Denial of Service Activity
>> https://cseweb.ucsd.edu/~savage/papers/UsenixSec01.pdf
>>
>> Analyzing Large DDoS Attacks Using Multiple Data Sources
>> https://www.cs.utah.edu/~kobus/docs/ddos.lsad.pdf
>>
>> ISP Security - Real World Techniques
>> https://www.nanog.org/meetings/nanog23/presentations/greene.ppt
>>
>> A Summary of DoS/DDoS Prevention, Monitoring and Mitigation Techniques in a 
>> Service Provider Environment
>> https://www.sans.org/reading-room/whitepapers/intrusion/summary-dos-ddos-prevention-monitoring-mitigation-techniques-service-provider-enviro-1212
>>
>> Maybe you have access to some public IPs, then you can do this data 
>> collection yourself.
> Sure, I will definitely think about hat.
> 
> Thanks again for your reply and for providing the links.
> 
> Greetings,
> Martin
> 
>>
>> Regards,
>>
>> Tyler
>>
> 
> 

Re: OpenNTPProject.org

[Pierre Lamy]

BCP38 will only ever get implemented if governments and ruling 'net 
bodies force deployment. There's otherwise very little benefit seen by 
the access network providers, since the targets are other orgs and the 
attacks are happening in a different backyard.


On 14/01/2014 10:36 AM, Paul Ferguson wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 1/13/2014 11:18 PM, Saku Ytti wrote:


On (2014-01-13 21:33 +), Bjoern A. Zeeb wrote:


BCP38!  I am always surprised when people need crypto if they
fail the simple things.

Saying that BCP38 is solution to the reflection attacks is not
unlike 5 year old wishing nothing but world peace for christmas,
endearing, but it's not going to change anything. BCP38 is
completely unrealistic, many access networks are on autopilot,
many don't have HW support for BCP38, one port configured has
low-benefit, only that machine can stop attacking (but whole
world).

That does *not* make it an unworthy goal, nor should it stop people
from encouraging it's implementation.

- - ferg (co-author of BCP38)


- -- 
Paul Ferguson

PGP Public Key ID: 0x54DC85B2

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlLVWXoACgkQKJasdVTchbIrtAD/T2bNNAgZOnnlniBPd6sEquxJ
v01mmrhJxFTIDFq7EIkA/3vQbiwtEwBeVyCtc3coEkz50zSDh3j9QQjT+TQWCNVs
=Al3Y
-END PGP SIGNATURE-

Re: Ddos mitigation service

[Pierre Lamy]

The 3 major scrubbing vendors:

Prolexic
Verisign
Akamai

Prolexic has the ability to announce a /24 for you, and scrub the whole 
thing, then pipe it back to you via a GRE tunnel or dedicated circuit. 
All of the companies mentioned do this for a living, and are pretty good 
at what they do. There are other vendors as well that do FQDN scrubbing 
for you (which is the normal way to do it). You swing the DNS A record 
to point to their provisioned VIP, and they proxy back the traffic to 
you. This doesn't do anything to prevent attacks against IP addresses 
rather than resolved FQDNs.


It's important to note that all mitigation techniques can have a 
negative impact and should be tested first. The scrubbing centers are 
only one solution and you should equip yourself with multiple layers of 
defense, separated by where they live:


Beyond the carrier perimeter
- Scrubbing farms in IP-routed mode
- Scrubbing farms in DNS-routed mode
- CDNs to deliver high value target pages, like main corporate pages and 
login windows

- Globally Anycast DNS auth slaves through a CDN

Beyond your perimeter (carriers)
- Geoblocks
- Zombie detection and rate limits
- Flowspec routes via monitoring tools like Arbor's
- Various other carrier-specific security offerings
- Provision a secondary circuit to carry non-public IP space, for 
corporate web/out, phones, VPN etc. If the main pipe comes under attack, 
you can still carry out some critical business and B2B functions


Within the perimeter
- Load balancers
- Firewalls
- IPS
- WAF
- Reverse proxies
- Blackhole routes
- Flowspec routes (ie Arbor)
- A span tap on the internet feed(s) connected to a tcpdump box (silly 
and cheap, but highly useful to generate sigs and collect intel)


Not all DDoS are created equal, and there can always be some leakage by 
protections further out; the protections closer in allow for a faster 
and more granular response, but you're really limited to the circuit 
sizes, session limits etc. I would highly recommend that you also join 
industry specific cyberintelligence organizations, like any of the 
-ISACs, and/or a cyberintel provider if you don't have access to an 
-ISAC. The 3 major areas of infosec business focus in 2013 that I see 
will be insourcing malware analysis + automation of IOC generation, 
cyberintelligence, and DDoS mitigations. Businesses have realized that 
relying solely in external vendors to provide these services in a 
generic way results in good service but slower turnaround times; the 
insourced components become both a first tier of defense, and also a 
specialized set of incident responders that understand the business.


Pierre

On 31/01/2013 1:13 PM, matt kelly wrote:

Can anyone recommended ddos mitigation companies with US east coast
presence that provide the services via bgp?  We are not interested in an
appliance but rather offloading the traffic.

Thanks.

Re: Ddos mitigation service

[Pierre Lamy]

I'm aware that they exist but don't have any knowledge or experience 
with CloudFlare.


if you're considering using them, I would ask them for a list (under 
NDA) of what large enterprises use them, what their POPs are - global is 
good - and for any analytical product they have relating to DDoS that 
they have mitigated and investigated. Also a procedure guide on how you 
would engage them in event of a DDoS. You should really be asking a lot 
of questions before signing anything with anyone, and once you select 
one - TEST IT!!! A lot of orgs do not test their mitigation processes. 
The total time to mitigation if you're not already swung to a provider, 
should be down to 30 mins to an hour, this is reasonable for detection 
to full mitigation in large companies. Without running through an 
exercise, companies will find that mitigation takes 1-4 hours. It's also 
highly recommended that you have incident handlers who are able to make 
big decisions.


-Pierre

On 01/02/2013 10:48 AM, James Thomas wrote:

Hi Pierre,

Thank you for your interesting note.

On 01/02/2013 09:57, Pierre Lamy wrote:

The 3 major scrubbing vendors:

Prolexic
Verisign
Akamai

IIRC, CloudFlare claims to the same capcity of DDOS mitigation as
Prolexic (500gb) and also has a free option with fewer scrubbing
features.  Do you have experience with it, or is there some other reason
to have excluded it from your list?  I apologize for my noobish question.

Cheers,

James