Archive

Category Archives for "Security"

Rough Guide to IETF 101: Internet of Things

The Internet of Things (IoT) is an increasingly hot buzzword around the Internet industry and the broader technology and innovation business arenas. We are often asked what the IETF is doing in relation to IoT and in this short Rough Guide to IETF 101 post I’d like to highlight some of the relevant sessions scheduled during the upcoming IETF 101 meeting in London. Also check out the IETF Journal IoT Category, the IETF IoT page, the IETF IoT Directorate, the Internet Society’s IoT page, or the Online Trust Alliance IoT page for more details about many of these topics. See also this recent article in the IETF Journal: Internet of Things: Standards and Guidance from the IETF.

The IETF Hackathon, held the weekend preceding the main IETF meeting (17-18 March), will include at least four projects directly related to IoT, with the possibility of more being added. More information is on the Hackathon wiki.

Continue reading

Deprecating TLS 1.0 and 1.1 on api.cloudflare.com

Deprecating TLS 1.0 and 1.1 on api.cloudflare.com

On June 4, Cloudflare will be dropping support for TLS 1.0 and 1.1 on api.cloudflare.com. Additionally, the dashboard will be moved from www.cloudflare.com/a to dash.cloudflare.com and will require a browser that supports TLS 1.2 or higher.

No changes will be made to customer traffic that is proxied through our network, though you may decide to enforce a minimum version for your own traffic. We will soon expose TLS analytics that indicate the percent of connections to your sites using TLS 1.0-1.3, and controls to set a specific minimum version. Currently, you may enforce version 1.2 or higher using the Require Modern TLS setting.

Prior to June 4, API calls made with TLS 1.0 or 1.1 will have warning messages inserted into responses and dashboard users will see a banner encouraging you to upgrade your browser. Additional details on these changes, and a complete schedule of planned events can be found in the timeline below.

Background

Transport Layer Security (TLS) is the protocol used on the web today to encrypt HTTPS connections. Version 1.0 was standardized almost 20 years ago as the successor to SSL Continue reading

Applied Networking Research Workshop (ANRW) Call for Papers Due 20 April

We’re excited to share news of the third edition of the Applied Networking Research Workshop (ANRW2018), which will take place in Montreal, Quebec, on Monday, July 16 at the venue of the Internet Engineering Task Force (IETF) 102 meeting. The workshop program already includes some great invited talks and the Call for Papers is open now, with a deadline of 20 April.

ANRW2018 will provide a forum for researchers, vendors, network operators and the Internet standards community to present and discuss emerging results in applied networking research. The workshop will also create a path for academics to transition research back into IETF standards and protocols, and for academics to find inspiration from topics and open problems addressed at the IETF. Accepted short papers will be published in the ACM Digital Library.

ANRW2018 particularly encourages the submission of results that could form the basis for future engineering work in the IETF, that could change operational Internet practices, that can help better specify Internet protocols, or that could influence further research and experimentation in the Internet Research Task Force (IRTF).

If you have some relevant work and would like to join us in Montreal for the workshop and maybe stick Continue reading

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 ...