Having helped fund Embrane, Cisco is ready to acquire the Layer 4-7 startup.
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.
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 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
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”.
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.
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
"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 |
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 ...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?
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.
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.
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
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.
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
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
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