Archive

Category Archives for "Security"

Securing BGP: A Case Study

What would it take to secure BGP? Let’s begin where any engineering problem should begin: what problem are we trying to solve? This series of posts walks through a wide range of technical and business problems to create a solid set of requirements against which to measure proposed solutions for securing BGP in the global Internet, and then works through several proposed solutions to see how they stack up.

Post 1: An introduction to the problem space
Post 2: What can I prove in a routing system?
Post 3: What I can prove in a routing system?
Post 4: Centralized or decentralized?
Post 5: Centralized or decentralized?
Post 6: Business issues with centralization
Post 7: Technical issues with centralization
Post 8: A full requirements list
Post 9: BGPSEC (S-BGP) compared to the requirements
Post 10: RPKI compared to the requirements

I will continue updating this post as I work through the remaining segments of this series.

LinkedInTwitterGoogle+FacebookPinterest

The post Securing BGP: A Case Study appeared first on 'net work.

Technology Short Take #66

Welcome to Technology Short Take #66! In this post you’ll find a collection of links to articles about the major data center technologies. Hopefully something I’ve included here will be useful to you. Enjoy!

Networking

  • I recently spoke at Interop 2016 in Las Vegas, and while I was there I scribbled down some notes pertaining to how decomposing applications into microservices-based architectures was similar in some respects to decomposing networks into an overlay network and an underlay (physical) network. It’s still something I’m exploring, but I hope to get something written up soon. In the meantime, I’d love to hear your thoughts about it. Feel free to hit me up on Twitter or drop me an e-mail.
  • While I’m talking about the overlay/underlay model, I found this article by Tom Nolle discussing how using the overlay/underlay model could enable agile infrastructure. It’s a good post, well worth reading (in my opinion).

Servers/Hardware

Nothing this time around. Maybe next time?

Security

  • In the event you’re interested in an idea of how much latency the use of in-kernel hypervisor firewalling (such as that offered by VMware NSX) adds, have a look at this article by Sean Howard.

Cloud Computing/Cloud Management

Monitoring CPU on firewalls

There is a trend in network monitoring toward Push Model (versus Pull Model) where network devices send metrics to a collector in a ‘netflow’ like fashion (read blog post of Matt Oswalt). It is up to the collector to interpret that data; no need to standardize what is being sent. The only agreement is on data format […]

The post Monitoring CPU on firewalls appeared first on Packet Pushers.

Monitoring CPU On firewalls

There is a trend in network monitoring toward Push Model (versus Pull Model) where network devices send metrics to a collector in a ‘netflow’ like fashion (read blog post of Matt Oswalt). It is up to the collector to interpret that data; no need to standardize what is being sent. The only agreement is on data format […]

The post Monitoring CPU On firewalls appeared first on Packet Pushers.

Infographic: Survey Reveals IT Organizations Underestimate Security Threats

Did you know the average organization’s security has been compromised an average of four times over the past year? If that seems like a lot, well, that’s because it is—especially considering that, according to a survey conducted by Forrester of 210 IT risk and compliance decision-makers, the vast majority of organizations also believe they are “extremely secure.” Fortunately, by virtualizing your network with VMware NSX, you can dramatically strengthen your security with micro-segmentation.

Click here to get our FREE VMware NSX resource kit  your guide to micro-segmentation.

Find out more about leveraging micro-segmentation to build a Zero Trust network in the infographic below.

Networking

The post Infographic: Survey Reveals IT Organizations Underestimate Security Threats appeared first on The Network Virtualization Blog.

Getting Traffic to a Virtual Firepower Sensor

I wanted to jot down some quick notes relating to running a virtual Firepower sensor on ESXi and how to validate that all the settings are correct for getting traffic from the physical network down into the sensor.

Firepower is the name of Cisco’s (formerly Sourcefire’s) so-called Next-Gen IPS. The IPS comes in many form-factors, including beefy physical appliances, integrated into the ASA firewall, and as a discrete virtual machine.

Since the virtual machine (likely) does not sit in-line of the traffic that needs to be monitored, traffic needs to be fed into the VM via some method such as a SPAN port or a tap of some sort.

1 – Validate vSwitch Settings

This is probably not a very real-world example since most environments will be running some form of distributed vSwitch (dvSwitch) and not the regular vSwitch, but all I’ve got in my lab is the vSwitch, so work with me. The same considerations apply when running a dvSwitch.

Ensure that the port-group where you’re attaching the NGIPSv allows promiscuous mode. The NGIPSv acts as sniffer and will attempt to put its NICs into promisc mode.

NGIPSv_ESXi_Port_Group_Promisc
Set ESXi Port Group to Allow Promiscuous Mode

Set this either at Continue reading

Securing BGP: A Case Study (10)

The next proposed (and actually already partially operational) system on our list is the Router Public Key Infrastructure (RPKI) system, which is described in RFC7115 (and a host of additional drafts and RFCs). The RPKI systems is focused on solving a single solution: validating that the originating AS is authorized to originate a particular prefix. An example will be helpful; we’ll use the network below.

RPKI-Operation

(this is a graphic pulled from a presentation, rather than one of my usual line drawings)

Assume, for a moment, that AS65002 and AS65003 both advertise the same route, 2001:db8:0:1::/64, towards AS65000. How can the receiver determine if both of these two advertisers can actually reach the destination, or only one can? And, if only one can, how can AS65000 determine which one is the “real thing?” This is where the RPKI system comes into play. A very simplified version of the process looks something like this (assuming AS650002 is the true owner of 2001:db8:0:1::/64):

  • AS65002 obtains, from the Regional Internet Registry (labeled the RIR in the diagram), a certificate showing AS65002 has been issued 2001:db8:0:1::/64.
  • AS65002 places this certificate into a local database that is synchronized with all the other operators participating in Continue reading

Freaking out over the DBIR

Many in the community are upset over the recent "Verizon DBIR" because it claims widespread exploitation of the "FREAK" vulnerability. They know this is impossible, because of the vulnerability details. But really, the problem lies in misconceptions about how "intrusion detection" (IDS) works. As a sort of expert in intrusion detection (by which, I mean the expert), I thought I'd describe what really went wrong.

First let's talk FREAK. It's a man-in-the-middle attack. In other words, you can't attack a web server remotely by sending bad data at it. Instead, you have to break into a network somewhere and install a man-in-the-middle computer. This fact alone means it cannot be the most widely exploited attack.

Second, let's talk FREAK. It works by downgrading RSA to 512-bit keys, which can be cracked by supercomputers. This fact alone means it cannot be the most widely exploited attack -- even the NSA does not have sufficient compute power to crack as many keys as the Verizon DBIR claim were cracked.

Now let's talk about how Verizon calculates when a vulnerability is responsible for an attack. They use this methodology:
  1. look at a compromised system (identified by AV scanning, IoCs, etc.)
  2. look at Continue reading

Vulns are sparse, code is dense

The question posed by Bruce Schneier is whether vulnerabilities are "sparse" or "dense". If they are sparse, then finding and fixing them will improve things. If they are "dense", then all this work put into finding/disclosing/fixing them is really doing nothing to improve things.

I propose a third option: vulns are sparse, but code is dense.

In other words, we can secure specific things, like OpenSSL and Chrome, by researching the heck out of them, finding vulns, and patching them. The vulns in those projects are sparse.

But, the amount of code out there is enormous, considering all software in the world. And it changes fast -- adding new vulns faster than our feeble efforts at disclosing/fixing them.

So measured across all software, no, the secure community hasn't found any significant amount of bugs. But when looking at critical software, like OpenSSL and Chrome, I think we've made great strides forward.

More importantly, let's ignore the actual benefits/costs of fixing bugs for the moment. What all this effort has done is teach us about the nature of vulns. Critical software is written to day in a vastly more secure manner than it was in the 1980s, 1990s, or even the Continue reading

Software-Defined Security and VMware NSX Events

I’m presenting at two Data Center Interest Group Switzerland events organized by Gabi Gerber in Zurich in early June:

  • In the morning of June 7th we’ll talk about software-defined security, data center automation and open networking;
  • In the afternoon of the same day (so you can easily attend both events) we’ll talk about VMware NSX microsegmentation and real-life implementations.

I hope to see you in Zurich in a bit more than a month!

Security ‘net: Privacy and Cybercrime Edition

DDoS blackmail is an increasingly common form of cybercrime, it appears. The general pattern is something like this: the administrator of a large corporate site receives an email, threatening a large scale DDoS attack unless the company deposits some amount of bitcoin in an untraceable account. Sometimes, if the company doesn’t comply, the blackmail is followed up with a small “sample attack,” and a second contact or email asking for more bitcoin than the first time.

The best reaction to these types of things is either to work with your service provider to hunker down and block the attack, or to simply ignore the threat. For instance, there has been a spate of threats from someone called Armada Collective over the last several weeks that appear to be completely empty; while threats have been reported, no action appears to have been taken.

We heard from more than 100 existing and prospective CloudFlare customers who had received the Armada Collective’s emailed threats. We’ve also compared notes with other DDoS mitigation vendors with customers that had received similar threats. -via Cloudflare

The bottom line is this: you should never pay against these threats. It’s always better to contact your provider and work Continue reading

Satoshi: how Craig Wright’s deception worked

My previous post shows how anybody can verify Satoshi using a GUI. In this post, I'll do the same, with command-line tools (openssl). It's just a simple application of crypto (hashes, public-keys) to the problem.

I go through this step-by-step discussion in order to demonstrate Craig Wright's scam. Dan Kaminsky's post and the redditors comes to the same point through a different sequence, but I think my way is clearer.

Step #1: the Bitcoin address


We know certain Bitcoin addresses correspond to Satoshi Nakamoto him/her self. For the sake of discussion, we'll use the address 15fszyyM95UANiEeVa4H5L6va7Z7UFZCYP. It's actually my address, but we'll pretend it's Satoshi's. In this post, I'm going to prove that this address belongs to me.

The address isn't the public-key, as you'd expect, but the hash of the public-key. Hashes are a lot shorter, and easier to pass around. We only pull out the public-key when we need to do a transaction. The hashing algorithm is explained on this website [http://gobittest.appspot.com/Address]. It's basically base58(ripemd(sha256(public-key)).

Step #2: You get the public-key


Hashes are one-way, so given a Bitcoin address, we can't immediately convert it into a public-key. Instead, we have to look it Continue reading

Satoshi: That’s not how any of this works

In this WIRED article, Gaven Andresen says why he believes Craig Wright's claim to be Satoshi Nakamoto:
“It’s certainly possible I was bamboozled,” Andresen says. “I could spin stories of how they hacked the hotel Wi-fi so that the insecure connection gave us a bad version of the software. But that just seems incredibly unlikely. It seems the simpler explanation is that this person is Satoshi.”
That's not how this works. That's not how any of this works.

The entire point of Bitcoin is that it's decentralized. We don't need to take Andresen's word for it. We don't need to take anybody's word for it. Nobody needs to fly to London and check it out on a private computer. Instead, you can just send somebody the signature, and they can verify it themselves. That the story was embargoed means nothing -- either way, Andresen was constrained by an NDA. Since they didn't do it the correct way, and were doing it the roundabout way, the simpler explanation is that he was being bamboozled.

Below is an example of this, using the Electrum Bitcoin wallet software:


This proves that the owner of the Bitcoin Address has signed the Message Continue reading

Securing BGP: A Case Study (9)

There are a number of systems that have been proposed to validate (or secure) the path in BGP. To finish off this series on BGP as a case study, I only want to look at three of them. At some point in the future, I will probably write a couple of posts on what actually seems to be making it to some sort of deployment stage, but for now I just want to compare various proposals against the requirements outlined in the last post on this topic (you can find that post here).securing-bgp

The first of these systems is BGPSEC—or as it was known before it was called BGPSEC, S-BGP. I’m not going to spend a lot of time explaining how S-BGP works, as I’ve written a series of posts over at Packet Pushers on this very topic:

Part 1: Basic Operation
Part 2: Protections Offered
Part 3: Replays, Timers, and Performance
Part 4: Signatures and Performance
Part 5: Leaks

Considering S-BGP against the requirements:

  • Centralized versus decentralized balance:S-BGP distributes path validation information throughout the internetwork, as this information is actually contained in a new attribute carried with route advertisements. Authorization and authentication are implicitly centralized, however, with the Continue reading

Touch Wipe: a question for you lawyers

Whether the police can force you to unlock your iPhone depends upon technicalities. They can't ask you for your passcode, because that would violate the 5th Amendment right against "self incrimination". On the other hand, they can force you to press your finger on the TouchID button, or (as it has been demonstrated) unlock the phone themselves using only your fingerprint.

So I propose adding a new technicality into the mix: "Touch Wipe". In addition to recording fingerprints to unlock the phone, Apple/Android should add the feature where users record fingerprints to wipe (erase) the phone. For example, I may choose my thumb to unlock, and my forefinger to wipe.

Indeed, I may record only one digit to unlock, and all nine remaining digits to wipe. Or even, I may decide to record all 10 digits on both hands to wipe, and not use Touch ID at all to unlock (relying solely on the passcode).

This now presents the problem for the police. They can't force me to unlock the phone. They can't get around that by using my fingerprints, because they might inadvertently destroy evidence.

The legal system is resilient against legal trickery such as this. If think you've Continue reading
1 … 149 150 151 152 153 … 182