Video: Automating Network Security
The video of my Automating Network Security talk @ Troopers 15 has been published on YouTube. They used fixed camera and the slides are a bit hard to read; you’ll find a better copy of the slide deck on my content web site.
For a bit of fun, turn on closed captions (CC) – public cloud became public lout.
Edgewater Networks Featured White Paper: SaaS Model Gives an Enterprise Feel to SMB Security
In this featured white paper from Edgewater Networks, we learn how an SaaS model gives an enterprise feel to SMB security. Download the white paper now to read more.
Check Point – Upgrade Without Dropping Connections
Check Point firewall upgrades have always been painful. The loss of connection state is a big part of this. Existing connections stop working, and many applications need restart. It looks like there is a way of minimising this pain on upgrade.
Stateful firewalls record the current ‘state’ of traffic passing through, so they can recognise and allow reply or related traffic. If you have a firewall cluster, they need to synchronise state between the cluster members. This is so that if there is a failover, the new Active node will be aware of all connections currently in flight.
If you have a failover, and the standby member is NOT aware of current connection state, it will drop all currently open sessions. Any packet that isn’t a SYN packet will get dropped, and the applications need to establish new connections. Some applications handle this well – especially those that use many short-lived connections such as HTTP or DNS. But other applications that have long-running connections – e.g. DB connections – may struggle with this. They think the connection is still open, and take a long time to figure out it’s broken. They may eventually recover on their own, or they may Continue reading
How to boot an encrypted system safely
These are my notes on how to set up a system securely, in a way that would prevent attackers from being capable of performing an “evil maid attack”.
The threat model
You have a Linux server that you want to protect against data theft and other backdoors. The attacker can get physical access to your hardware, for example by having access to the server room that houses your rack.
Your attacker is funded, but not super well funded. This will not protect you against intelligence agencies.
The attacker can buy a new server that looks just like the one you have. You will not be able to tell the difference from physical inspection.
You want to know that it’s safe to log in to your server after a suspicious power outage or reboot.
This solution assumes that once the system is booted and you log in, you have access to the secret data. In other words, this is not a protection for gaming consoles or kiosks.
Overview of the solution
First of all, full disk encryption using dm-crypt. Obviously. (other FDE also acceptable, of course)
Walking up to the server and typing the passphrase every reboot is not only tedious Continue reading
Message to Errata employees
Dear employees,Starting next week, Errata Security will be following RSA Conference's lead and institute a "Morality Dress Code" in order to deal with the problem of loose women on the premises.
Attire of an overly revealing or suggestive nature is not permitted. Examples of such attire may include but are not restricted to:
- Tops displaying excessive cleavage;
- Tank tops, halter tops, camisole tops or tube tops;
- Miniskirts or minidresses;
- Shorts;
- Lycra (or other Second-Skin) bodysuits;
- Objectionable or offensive costumes.
These guidelines are applicable to all staff, regardless of gender, and will be strictly enforced. Therefore, Dave's practice of showing up on casual Friday's in a miniskirt and push-up bra will no longer be tolerated. We have burkas on hand of varying sizes for those who fail to comply.
If you have any questions, please consult the Morality Officer for your department.
Regards,
Robert Graham
CEO, Errata Security
 |
| "Shalim" by Zivya - Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons - http://commons.wikimedia.org/wiki/File:Shalim.JPG#/media/File:Shalim.JPG |
PS: This is satire, of course. We don't support RSA's morality code.
MLD Considered Harmful
Multicast Listener Discovery (MLD) protocol is well hidden deep in the bowels of IPv6 protocol stack and most of us tend to gloss over it when we discuss IPv6 neighbor discovery process… until MLD raises its ugly head to bite an unsuspecting network administrator.
The problems with MLD are not new (and I wrote exhaustively about them a while ago), but it’s always nice to see other people raise awareness of broken IPv6 features like Enno Rey and his security team did during the IPv6 Security Summit (part of Troopers 15 conference).
Read more ...x86 is a high-level language
Just so you know, x86 machine-code is now a "high-level" language. What instructions say, and what they do, are very different things.I mention this because of those commenting on this post on OpenSSL's "constant-time" calculations, designed to avoid revealing secrets due to variations in compute time. The major comment is that it's hard to do this perfectly in C. My response is that it's hard to do this even in x86 machine code.
Consider registers, for example. Everyone knows that the 32-bit x86 was limited to 8 registers, while 64-bit expanded that to 16 registers. This isn't actually true. The latest Intel processors have 168 registers. The name of the register in x86 code is really just a variable name, similar to how variables work in high-level languages.
So many registers are needed because the processor has 300 instructions "in flight" at any point in time in various stages of execution. It rearranges these instructions, executing them out-of-order. Everyone knows that processors can execute things slightly out-of-order, but that's understated. Today's processors are massively out-of-order.
Consider the traditional branch pair of a CMP (compare) followed by a JMPcc (conditional jump). While this is defined as two separate instructions as Continue reading
DNSSEC – Moving the Needle
The New Zealand ISP market is dominated by Spark, Vodafone & CallPus/Orcon. A side effect of this is that if one player does the Right Thing™, it really moves the needle. Recently, Spark has done the Right Thing with DNSSEC.
DNSSEC takeup has been low with New Zealand ISPs. The APNIC stats indicated that around 5% of users were using DNS resolvers that had DNSSEC validation capabilities. But in December 2014, that number jumped to ~15%:
It turns out this is because Spark has enabled DNSSEC validation on some of their resolvers. NZRS have done some analysis, and found that Spark turned on 4 new resolvers that do DNSSEC validation:
They’re still running their old resolvers, so right now it’s hit & miss for their customers. But it’s a great start, and presumably they’ll upgrade the remaining systems soon.
So Vodafone, CallPlus, Snap, Trustpower…when are you going to take customer security seriously too? And Spark…how long until DNSSEC is enabled for all your resolvers?
And please, no arguments about “we’re not sure if it will work.” Google has been doing it since March 2013…who do you think processes more DNS requests per day? Google, or your ISP?
What ever it is, CISA isn’t cybersecurity
In the next couple months, Congress will likely pass CISA, the Cybersecurity Information Sharing Act. This is a bad police-state thing. It will do little to prevent attacks, but do a lot to increase mass surveillance.They did not consult us security experts when drafting this bill. If they had, we would have told them the idea doesn’t really work. Companies like IBM and Dell SecureWorks already have massive “cybersecurity information sharing” systems where they hoover up large quantities of threat information from their customers. This rarely allows them to prevent attacks as the CISA bill promises.
In other words, we’ve tried the CISA experiment, and we know it doesn’t really work.
While CISA won’t prevent attacks, it will cause mass surveillance. Most of the information produced by countermeasures is in fact false-positives, triggering on innocent anomalies rather than malicious hackers. Your normal day-to-day activities on the Internet occasionally trigger these false-positives. When this information gets forwarded to law enforcement, it puts everyone in legal jeopardy. It may trigger an investigation, or it may just become evidence about you, for example, showing which porn sites you surf. It’s mass surveillance through random sampling.
That such mass surveillance is the goal Continue reading
Presentation: Automating Network Security
The fantastic Troopers 15 conference is in full swing… and I’m done with the presentations ;) The last talk I had during the conference focused on automating network security. The slides are already online; I’ll add the link to the recording when they upload the videos.
Docker Governance Advisory Board: 2nd meeting
On February 17th, the Docker project had its second Docker Governance Advisory Board ( DGAB ) meeting to discuss the operations of the project. As this was our second meeting, it was great to see everyone again. As a bit … ContinuedInsecurity Guards
Pick a random headline related to security today and you’ll see lots of exclamation points and dire warnings about the insecurity of a something we thought was inviolate, such as Apple Pay or TLS. It’s enough to make you jump out of your skin and crawl into a dark hole somewhere never to use electricity again. Until you read the article, that is. After going through a couple of paragraphs, you realize that a click-bait headline about a new technology actually underscores an age-old problem: people are the weakest link.
Engineered To Be Social
We can engineer security for protocols and systems until the cows come home. We can use ciphers so complicated that even Deep Thought couldn’t figure them out. We can create a system so secure that it could never be hacked. But in the end that system needs to be used by people. And people are where everything breaks down.
Take the most recent Apple Pay “exploit” in the news that’s been making all the headlines. The problem has nothing to do with Apple Pay itself, or the way the device interacts with the point-of-sale terminal. It has everything to do with enterprising crooks calling in to Continue reading
Evaluation Guide: Encryptors for Metro and Carrier Ethernet
Christoph Jaggi, the author of Metro Ethernet and Carrier Ethernet Encryption Market Overview published an awesome follow-up document: an evaluation guide that lists most of the gotchas one has to be aware of when considering encryption gear, from deployment scenarios, network overhead and key exchange details to operational considerations. If you have to deal with any aspect of network encryption, this document is a must-read.
Integrating FortiOS (Fortigate VM64/VM32) into GNS3
We work a lot with fortigates so though it would be good to try and use their VM Firmware and integrate it with GNS3, I have used VmwareUK traffic diverted through Ukraine
On the heels of the BGP leak yesterday that briefly impaired Google services around the world, comes another routing incident that impacted some other important Internet services.
Beginning on Saturday, Ukrainian telecom provider, Vega, began announcing 14 British Telecom (BT) routes, resulting in the redirection of Internet traffic through Ukraine for a handful of British Telecom customers. Early yesterday morning, Vega announced another 167 BT prefixes for 1.5 hours resulting in the rerouting of additional traffic destined for some of BT’s customers, including the UK’s Atomic Weapons Establishment, the “organization responsible for the design, manufacture and support of warheads for the United Kingdom’s nuclear deterrent.”
Background
In early 2013, Ukrainian provider Vega (AS12883) became a reseller of BT services, but prior to Saturday had never announced any BT routes. Then, in the middle of a weekend night in Europe (02:37 UTC on Saturday, March 7th), Vega began announcing 14 prefixes typically announced by AS2856 of BT. These prefixes are listed below.
109.234.168.0/21 Thales Transport and Security Ltd (Barnet, GB)
109.234.169.0/24 Thales Transport and Security Ltd (Ealing, GB)
144.87.142.0/24 Royal Mail Group Limited (Sheffield, GB)
144.87.143.0/24 Royal Mail Group Limited (Chesterfield, GB)
147.182.214.0/24 Black & Veatch (Manchester, GB)
193.113.245.0/24 BT - 21CN (GB)
193.221.55.0/24 Svenska Cellulosa Aktiebolaget SCA (GB)
193. Continue reading
Role Based Access Control in IOS
I don’t believe this is well known: Cisco IOS has Role Based Access Control (RBAC) which can be used to create and assign different levels of privileged access to the device. Without RBAC there are two access levels in IOS: a read-only mode with limited access to commands and no ability to modify the running config (also called privilege level 1) and enable mode with full administrative access. There is no middle ground; it’s all or nothing. RBAC allows creation of access levels somewhere between nothing and everything. A common use case is creating a role for the first line NOC analyst which might allow them to view the running config, configure interfaces, and configure named access-lists.
A “role” in IOS is called a “view” and since views control which commands are available in the command line parser, they are configured under the parser. A view can be assigned a password which allows users to “enable” into the view. More typically, the view is assigned by the RADIUS/TACACS server as part of the authorization process when a user is logging into the device.
A view is configured with the “parser view <view-name>” config command after which commands are added/removed to/from Continue reading
GitHub won because it’s social-media
Today Google shut down Google Code, because GitHub has taken over that market. GitHub won not because Git is a better version-control system, but because it became a social-media website like Facebook and Twitter. Geeks like me express ourselves through our code. My GitHub account contains my projects just like Blogger contains my blogs or Twitter contains my tweets.
To be sure, Git's features are important. The idea of forking a repo fundamentally changed who was in control. Previously, projects were run with tight control. Those in power either accepted or rejected changes made by others. If your changes were rejected, you could just fork the project, making it your own version, with your own changes. That's the beauty of open-source: by making their source open, the original writers lost the ability to stop you from making changes.
However, forking was discouraged by the community. That's because it split efforts. When forks became popular, some people would contribute to one fork, while others would contribute to the other. Drama was a constant factor in popular open-source projects over the evil people who "hurt" projects by forking them.
But with Git, forking is now encouraged. Indeed, that's now the first step Continue reading
Routing Leak briefly takes down Google
This morning, users of Google around the world were unable to access many of the company’s services due to a routing leak in India. Beginning at 08:58 UTC Indian broadband provider Hathway (AS17488) incorrectly announced over 300 Google prefixes to its Indian transit provider Bharti Airtel (AS9498).
Bharti in turn announced these routes to the rest of the world, and a number of ISPs accepted these routes including US carriers Cogent (AS174), Level 3 (AS3549) as well as overseas incumbent carriers Orange (France Telecom, AS5511), Singapore Telecom (Singtel, AS7473) and Pakistan Telecom (PTCL, AS17557). Like many providers around the world, Hathway peers with Google so that their customers have more direct connectivity with Google services. But when that private relationship enters the public Internet the result can be accidental global traffic redirection.
Last fall, I wrote two blog posts here and here about the issues surrounding routing leaks such this one. Routing leaks happen regularly and can have the effect of misdirecting global traffic. Last month, I gave a talk in the NANOG 63 Peering Forum entitled “Hidden Risks of Peering” that went over some examples of routing leaks like this one.
Below is a graph showing the Continue reading
No, the CIA isn’t stealing Apple’s secrets
The Intercept news site by Glenn Greenwald is activism rather than journalism. Their stories don't reference experts knowledgeable about subjects, but only activists who are concerned about the subjects. This was demonstrated yet against in their piece claiming "The CIA Campaign to Steal Apple's Secrets". Yes, the Snowden documents are real, but pretty much everything else is made up.Here's the deal. Terrorist leaders use iPhones. They are a status symbol, and status symbols are important to leaders. Moreover, since Apple's security is actually pretty good, terrorists use the phones for good reason (most Android devices suck at security, even the Blackphone).
When CIA drones bomb a terrorist compound, iPhones will be found among the bodies. Or, when there is a terrorist suspect coming out of a dance club in Karachi, a CIA agent may punch them in the face and run away with their phone. However, it happens, the CIA gets phones and wants to decrypt them.
Back in 2011 when this conference happened, the process of decrypting retrieved iPhones was time consuming (months), destructive, and didn't always work. The context of the presentation wasn't that they wanted to secretly spy on everyone's phones. The context was Continue reading
Some notes on DRAM (#rowhammer)
My twitter feed is full of comments about the "rowhammer" exploit. I thought I'd write some quick notes about DRAM. The TL;DR version is this: you probably don't need to worry about this, but we (the designers of security and of computer hardware/software) do.There are several technologies for computer memory. The densest, and hence cheapest-per-bit, is "DRAM". It consists of a small capacitor for each bit of memory. The thing about capacitors is that they lose their charge over time and must be refreshed. In the case of DRAM, every bit of memory must be read them re-written every 64-milliseconds or it becomes corrupt.
These tiny capacitors are prone to corruption from other sources. One common source of corruption is cosmic rays. Another source is small amounts of radioactive elements in the materials used to construct memory chips. So, chips must be built with radioactive-free materials. The banana you eat has more radioactive material inside it than your DRAM chips.
The upshot is that capacitors are unreliable (albeit extremely cheap) technology for memory which readily get corrupted for a lot of reasons. This "rowhammer" exploit works by corrupting the capacitors by overwriting adjacent rows hundreds of thousands Continue reading