Archive

Category Archives for "Security"

What John Oliver gets wrong about Bitcoin

John Oliver covered bitcoin/cryptocurrencies last night. I thought I'd describe a bunch of things he gets wrong.


How Bitcoin works

Nowhere in the show does it describe what Bitcoin is and how it works.

Discussions should always start with Satoshi Nakamoto's original paper. The thing Satoshi points out is that there is an important cost to normal transactions, namely, the entire legal system designed to protect you against fraud, such as the way you can reverse the transactions on your credit card if it gets stolen. The point of Bitcoin is that there is no way to reverse a charge. A transaction is done via cryptography: to transfer money to me, you decrypt it with your secret key and encrypt it with mine, handing ownership over to me with no third party involved that can reverse the transaction, and essentially no overhead.

All the rest of the stuff, like the decentralized blockchain and mining, is all about making that work.

Bitcoin crazies forget about the original genesis of Bitcoin. For example, they talk about adding features to stop fraud, reversing transactions, and having a central authority that manages that. This misses the point, because the existing electronic banking system already Continue reading

Rough Guide to IETF 101: Internet Infrastructure Resilience

In this post of the Internet Society Rough Guide to IETF 101, I’ll focus on important work the IETF is doing that helps improve security and resilience of the Internet infrastructure.

BGP

What happens if an IXP operator begins maintenance work on the switches without ensuring that BGP sessions between the peers have been shut down? A network disruption and outage. A draft now in the RFC editor queue, “Mitigating Negative Impact of Maintenance through BGP Session Culling”, provides guidance to IXP operators on how to avoid such situations by forcefully tearing down the BGP sessions (session culling) affected by the maintenance before the maintenance activities commence. This approach allows BGP speakers to pre-emptively converge onto alternative paths while the lower layer network’s forwarding plane remains fully operational.

Another draft also in the RFC editor queue, “Graceful BGP session shutdown”, addresses issues related to planned maintenance. The procedures described in this document can be applied to reduce or avoid packet loss for outbound and inbound traffic flows initially forwarded along the peering link to be shut down.  These procedures trigger, in both Autonomous Systems (AS), rerouting to alternate paths if they exist within the Continue reading

CGN, IPv6 and fighting online crime…

Carrier Grade NAT (CGN) is commonly used by network operators as a way of ekeing out the limited supply of public IPv4 addresses. This is where private IPv4 addresses are allocated to end customers, who in turn also use private IPv4 address ranges on their own Local Area Networks, which means there can be multiple layers of Network Address Translation (NAT) before traffic reaches the publicly addressed Internet.
Whilst CGN offers something of a technical solution to the shortage of public IPv4 addresses, it presents a number of problems for investigating and solving online crime. A CGN environment means that many hundreds of users can be sharing a single public IPv4 address, so that when a crime is committed, tracing the perpetrator is very difficult. Furthermore, sometimes action needs to be taken against a public IPv4 address that’s the origin of particular problems, but this then penalises many hundreds or even thousands of innocent users who may also be sharing that IP address.
Europol, the European Union Agency for Law Enforcement Cooperation, has identified that CGN is an impediment to investigating online crime, and is therefore consulting the Internet community on how network operators can be encouraged to deploy IPv6.

Some notes on memcached DDoS

I thought I'd write up some notes on the memcached DDoS. Specifically, I describe how many I found scanning the Internet with masscan, and how to use masscan as a killswitch to neuter the worst of the attacks.


Test your servers

I added code to my port scanner for this, then scanned the Internet:

masscan 0.0.0.0/0 -pU:11211 --banners | grep memcached

This example scans the entire Internet (/0). Replaced 0.0.0.0/0 with your address range (or ranges).

This produces output that looks like this:

Banner on port 11211/udp on 172.246.132.226: [memcached] uptime=230130 time=1520485357 version=1.4.13
Banner on port 11211/udp on 89.110.149.218: [memcached] uptime=3935192 time=1520485363 version=1.4.17
Banner on port 11211/udp on 172.246.132.226: [memcached] uptime=230130 time=1520485357 version=1.4.13
Banner on port 11211/udp on 84.200.45.2: [memcached] uptime=399858 time=1520485362 version=1.4.20
Banner on port 11211/udp on 5.1.66.2: [memcached] uptime=29429482 time=1520485363 version=1.4.20
Banner on port 11211/udp on 103.248.253.112: [memcached] uptime=2879363 time=1520485366 version=1.2.6
Banner on port 11211/udp on 193.240.236.171: [memcached] uptime=42083736 time=1520485365 version=1.4.13

The "banners" check filters out Continue reading

Before Commenting on Someone Mentioning RFC1925 ;)

Some of my readers got annoyed when I mentioned Google’s BeyondCorp and RFC 1925 in the same sentence (to be perfectly clear, I had Rule#11 in mind). I totally understand that sentiment – reading the reactions from industry press it seems to be the best thing that happened to Enterprise IT in decades.

Let me explain in simple terms why I think it’s not such a big deal and definitely not something new, let alone revolutionary.

Read more ...

Routing Security BoF – APRICOT 2018

On Sunday, 25 February, the first day of APRICOT 2018, a “Routing Security BoF” (birds of a feather: An informal discussion group) was organized to address the ever-growing routing related incidents happening on daily basis. We have discussed routing security in general within the Asia Pacific region but there was a need to have a platform for open and candid discussion among the network operator community to find a possible way forward, where operators can share their approach in securing their own infrastructure and keeping the internet routing table clean as well.

A quick introduction was provided by the moderator (Aftab Siddiqui) on why it is important to have this BoF. Here are the introductory slides:

The first technical community presenter was Yoshinobu Matsuzaki (Maz) from Internet Initiative Japan (IIJ), the first ISP in Japan started in 1992. IIJ is one of the few ISPs in the region implementing prefix filtering, source address validation for their end customers, and making sure that all their routing information is reflecting the current status in the peeringdb for AS2497. IIJ was the first Asia Pacific ISP to join MANRS (Mutually Agreed Norms for Routing Security), a global initiative, supported by the Continue reading

Routing Security is a Serious Problem – and MANRS Can Help. A Report from APRICOT 2018.

Last week, at APRICOT 2018 in Kathmandu, Nepal, there were a lot of talks and discussions focused on routing security and the Mutually Agreed Norms for Routing Security (MANRS).

First, there was a Routing Security BoF, attended by about 150 people, where we talked about what it takes to implement routing security practices, how CDNs and other players can help, and why it is so difficult to make progress in this area. The BoF included an interactive poll at the end, and it showed some interesting results:

  • Participants almost unanimously see lack of routing security as a serious problem.
  • Slow progress in this area is largely seen as due to a lack of incentives
  • Participants see community initiatives (like MANRS) as the main driving forces for improvement, followed by CDNs and cloud providers. They doubt that governments or end-customers can effectively drive change.

My colleague Aftab Siddiqui is writing a separate blog post just about that BoF, so watch the blog in the next day or two.

Later, in the security track of the main APRICOT programme, Andrei Robachevsky, ISOC’s Technology Programme Manager, presented statistics on routing incidents and suggested a way forward based on the MANRS approach. In his Continue reading

Memcached DDoS – There’s Still Time to Save Your Mind

In case you haven’t heard, there’s a new vector for Distributed Denial of Service (DDoS) attacks out there right now and it’s pretty massive. The first mention I saw this week was from Cloudflare, where they details that they were seeing a huge influx of traffic from UDP port 11211. That’s the port used by memcached, a database caching system.

Surprisingly, or not, there were thousands of companies that had left UDP/11211 open to the entire Internet. And, by design, memcached responds to anyone that queries that port. Also, carefully crafted packets can be amplified to have massive responses. In Cloudflare’s testing they were able to send a 15 byte packet and get a 134KB response. Given that this protocol is UDP and capable of responding to forged packets in such a way as to make life miserable for Cloudflare and, now, Github, which got blasted with the largest DDoS attack on record.

How can you fix this problem in your network? There are many steps you can take, whether you are a system admin or a network admin:

  • Go to Shodan and see if you’re affected. Just plug in your company’s IP address ranges and have it Continue reading