Archive

Category Archives for "Security"

RadiUID: Palo Alto User-ID and RADIUS

The Palo Alto User-ID feature is awesome as long as you can feed it IP-to-User mappings. PAN provides agents to do this which work in many environments, but not usually without Active Directory. I wrote RadiUID to perform this function is situations where all you have is RADIUS. Approx Reading Time: 5-15 Minutes You see, […]

The post RadiUID: Palo Alto User-ID and RADIUS appeared first on Packet Pushers.

RadiUID: Palo Alto User-ID and RADIUS

The Palo Alto User-ID feature is awesome as long as you can feed it IP-to-User mappings. PAN provides agents to do this which work in many environments, but not usually without Active Directory. I wrote RadiUID to perform this function in situations where all you have is RADIUS. Approx Reading Time: 5-15 Minutes You see, […]

The post RadiUID: Palo Alto User-ID and RADIUS appeared first on Packet Pushers.

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

1 … 144 145 146 147 148 … 177