Security Dessert Models

MMCOOKIE

I had the good fortune last week to read a great post from Maish Saidel-Keesing (@MaishSK) that discussed security models in relation to candy.  It reminded me that I’ve been wanting to discuss security models in relation to desserts.  And since Maish got me hungry for a Snicker’s bar, I decided to lay out my ideas.

When we look at traditional security models of the past, everything looks similar to creme brûlée.  The perimeter is very crunchy, but it protects a soft interior.  This is the predominant model of the world where the “bad guys” all live outside of your network.  It works when you know where your threats are located.  This model is still in use today where companies explicitly trust their user base.

The creme brûlée model doesn’t work when you have large numbers of guest users or BYOD-enabled users.  If one of them brings in something that escapes into the network, there’s nothing to stop it from wreaking havoc everywhere.  In the past, this has caused massive virus outbreaks and penetrations from things like malicious USB sticks in the parking lot being activated on “trusted” computers internally.

A Slice Of Pie

A more modern security Continue reading

IOU Web Interface 1.2.2-23

iou-web is released “as-is” without warranty of any kind. iou-web does not include any Cisco IOU/IOL binaries or other materials under Cisco NDA. I’m not responsible for what you do with iou-web software. I DON’T OWN NOR HAVE ACCESS TO TOPOLOGY, INITIAL CONFIGS, IOU/IOL BINARIES OR ANY OTHER MATERIAL UNDER CCIE EXAM NDA OR COPYRIGHTED […]
(Visited 1,429 times since 2013-06-04, 6 visits today)

How Service Providers are Outpacing Enterprises in SDN Deployments

How Service Providers are Outpacing Enterprises in SDN Deployments


by Steve Harriman, VP of Marketing - July 15, 2014

Service providers are well ahead of enterprises in SDN deployments. The numbers confirm this according to Jim Duffy in his Network World article “Enterprise SDN use lags service providers.” ACG Research estimates that sales of SDN products for live service provider deployments will reach $15.6 billion by 2018, while those that may become live will reach $29.5 billion. Use of production SDNs by enterprises and cloud/service provider data centers will be a fraction of that according to Infonetics Research: $3.1 billion by 2017. 

Why are service providers so far ahead of enterprises? To paraphrase the oft-used political aphorism: It’s the business model, stupid. Duffy said it best in his article: “To service providers, the network is the business. To enterprises, the network enables or supports its core business.” 

To a network service provider, technology is the revenue generator in a competitive market. Better solutions and better technology lead to lower costs (and more profits), and/or competitive differentiation. 

Of course, competitive differentiators tend to become commodities over time, and we’ve seen that happen repeatedly Continue reading

OTV AEDs Are Like Highlanders

While prepping for CCIE Data Center and playing around with a lab environment, I ran into a problem I’d like to share.

I was setting up a basic OTV setup with three VDCs running OTV, connecting to a core VDC running the multicast core (which is a lot easier than it sounds). I’m running it in a lab environment we have at Firefly, but I’m not going by our normal lab guide, instead making it up as I go along in order to save some time, and make sure I can stand up OTV without a lab guide.

Each VDC will set up an adjacency with the other two, with the core VDC providing unicast and multicast connectivity.  That part was pretty easy to setup (even the multicast part, which had previously freaked me the shit out). Each VDC would be its own site, so no redundant AEDs.

On each OTV VDC, I setup the following as per my pre-OTV checklist:

  • Bi-directional IPv4 unicast connectivity to each join interface (I used a single OSPF area)
  • MTU of 9216 end-to-end (easy since OTV requires M line cards, and it’s just an MTU command on the interface)
  • An OTV site VLAN which requires:

Using Big Tools for Small Problems

BGP in the data center? And MPLS? Are you insane? Well, maybe, yes. But then again, I’ve been known to do a lot of crazy things in my time. Isn’t MPLS a core and edge service provider technology, while VXLAN is an enterprise data center technology? But let’s begin with this idea that technologies are […]

Author information

Russ White

Russ White
Principle Engineer at Ericsson

Russ White is a Network Architect who's scribbled a basket of books, penned a plethora of patents, written a raft of RFCs, taught a trencher of classes, and done a lot of other stuff you either already know about, or don't really care about. You want numbers and letters? Okay: CCIE 2635, CCDE 2007:001, CCAr, BSIT, MSIT (Network Design & Architecture, Capella University), MACM (Biblical Literature, Shepherds Theological Seminary). Russ is a Principal Engineer in the IPOS Team at Ericsson, where he works on lots of different stuff, serves on the Routing Area Directorate at the IETF, and is a cochair of the Internet Society Advisory Council. Russ will be speaking in November at the Ericsson Technology Day. he recently published The Art of Network Architecture, is currently working on a new book in the area Continue reading

JTRIG weekend projects

The Intercept has released a page of JTRIG tools and techniques. I thought I'd comment on them.

Largely, this is a long list of small projects. Few of these projects require more than a couple lines of code, or would take an average hacker more than a weekend to accomplish.

For example, there is CHANGELING, which says "Ability to spoof any email address and send email under that identity". That's the sort of thing you'd ask as an interview question for a cybersec company. You'd expect the candidate to produce this in 20 minutes.

Some sound like big projects, but they are in fact just leveraging existing large open-source projects. A tiny amount of scripting on top of a project like OpenBTS would deliver big, scary results, such as fuzzing GSM.

I point this out because people have the misapprehension that the intelligence services have advanced "cyber-weapons". That's not true. Instead, what's going on is like Rambo stuck in a jungle with only a knife, who can fashion anything into a weapon, from twigs to rocks. That's what you see going on here: given the existing base of open-source (and closed-source) code, cyber-warriors fashion new tools with a little bit Continue reading

Upcoming speaking schedule

I've an unusually dense talk schedule over the next month. Please ask questions at end of talk. Also ambush me afterward and ask more questions.


HopeX:
Sunday July 20, 2:00pm, Olson room
Technology walkthrough of XKeyScore and how to jam it


PasswordsCon 2014:
Wednesday August 6, 12:10pm Track 1
Overview of password hashes in network protocols


DEF CON 22:
Saturday August 9, 10:00am, Track 3
Masscan


DEF CON 22:
Friday August 8, 2:00pm, Track 2
Panel. I'm being this for several years, I still don't know what it is



Replacing an MPLS WAN with an Internet VPN Overlay

I received an email last week from a reader seeking advice on a fairly common predicament:

Our CIO has recently told us that he wants to get rid of MPLS because it is too costly and is leaning towards big internet lines running IPSEC VPNs to connect the whole of Africa.

As you can imagine, this has caused a huge debate between the networks team and management, we run high priority services such as Lync enterprise, SAP, video conferencing etc. and networks feel we need MPLS for guaranteed quality for these services but management feels the Internet is today stable enough to run just as good as MPLS.

What is your take on the MPLS vs Internet debate from a network engineer's point of view? And more so, would running those services over Internet work?

This is something I struggled with pretty frequently in a prior job working for a managed services provider. MPLS WANs are great because they provide flexible, private connectivity with guaranteed throughput. Most MPLS providers also allow you to choose from a menu of QoS schemes and classify your traffic so that real-time voice and video services are treated higher preference during periods of congestion.

Unfortunately, Continue reading

Brazil’s Winning Internet

Another World Cup is in the books, and it’s fair to say that most people will remember 2014 for the inglorious and improbable performance of the host nation, losing 7-1 and 3-0 in its semifinal and consolation matches. Brazil’s sad exit capped off a year of soul-searching about the nation’s massive investment in hosting the World Cup (and the Olympics yet to come).

But Brazil shouldn’t lose sight of one important silver lining to their World Cup cloud: the startlingly vibrant development of the Brazilian Internet, and the critical role Brazil now plays in the Internet connectivity and ICT development of South America.

Preparations for the World Cup and the Olympics may have helped light a fire under Brazil’s Internet infrastructure providers. Here’s a plot of the growth of the set of autonomous systems (that is, enterprises and service providers who originate IPv4 address space under their own registered Autonomous System Number) in Brazil over time. For comparison, we’ve also included the same statistic for South Africa. By this measure, the two World Cup host countries couldn’t be more different! brazil0

Brazil and South Africa invite comparison because of their many parallels: Continue reading

Show 196 – EVPN Introduction & Use-Cases with Russ White + Jeff Tantsura

This week, Packet Pushers’ hosts Ethan Banks and Greg Ferro queue up a discussion about a new technology, exploring EVPN with Russ White & Jeff Tantsura from Ericsson. What’s EVPN? Well, it’s short for Ethernet VPN, and it’s a way of using BGP as a routing system for MAC addresses. If that sounds like SPB […]

Author information

Ethan Banks

Ethan Banks, CCIE #20655, has been managing networks for higher ed, government, financials and high tech since 1995. Ethan co-hosts the Packet Pushers Podcast, which has seen over 2M downloads and reaches over 10K listeners. With whatever time is left, Ethan writes for fun & profit, studies for certifications, and enjoys science fiction. @ecbanks

The post Show 196 – EVPN Introduction & Use-Cases with Russ White + Jeff Tantsura appeared first on Packet Pushers Podcast and was written by Ethan Banks.

EIGRP Query bounding.

In the process of restudying EIGRP as a protocol, and more specifically as to how it converges, you can’t avoid running into the saying “Remember to bound your queries!”.

From a conceptual point of view its fairly easy to understand that the further out you ask for a prefix the longer the convergence process will take. But what really takes place when you have different tools in place to bound the query from taking place?

There are 3 different types of “Query Bounding” techniques that can be utilized:

1) Filters (fx. distribute lists).
2) Summarization
3) Stub routers.

How do they actually work to limit the query scope?

Well, the basic premise for EIGRP queries is the fact that you are asking your fellow EIGRP neighbour for an exact prefix, fx. 172.16.1.0/25. If for any reason you EIGRP neighbour does not have this in his topology table, it will simply respond right away that it doesn’t have a path to this prefix. Query stopped right there.

By using filters such as distribute lists you are removing the prefix from ever getting advertised to the neighbour and as such he will never receive it in his topology Continue reading

Explanation: TunnelX temporarily disabled due to recursive routing

I wanted to take a few minutes to share a scenario that some seem to struggle with. This scenario is a routing issue that sometimes occurs when an interior routing protocol allows routes to leak back through a tunnel. To demonstrate this, I’ve built a lab with three routers. R1 and R3 are participating in EIGRP and have a GRE tunnel configured directly between them.

Topology

TunnelRecurse

 

Router Configurations

R1

hostname R1
!
interface FastEthernet0/0
 ip address 192.168.12.1 255.255.255.0
!
interface Tunnel0
 ip address 192.168.13.1 255.255.255.0
 tunnel source 192.168.12.1
 tunnel destination 192.168.23.3
!
router eigrp 1
 network 192.168.0.0 0.0.255.255
!
ip route 0.0.0.0 0.0.0.0 192.168.12.2

R2 (hub)

hostname R2
!
interface FastEthernet0/1
 ip address 192.168.12.2 255.255.255.0
!
interface FastEthernet0/1
 ip address 192.168.23.2 255.255.255.0
!

R3

hostname R3
!
interface FastEthernet0/1
 ip address 192.168.23.3 255.255.255.0
!
interface Tunnel0
 ip address 192.168.13.3 255.255.255.0
 tunnel source 192.168.23.3
 tunnel destination 192.168.12. Continue reading

VyOS x64 Installation on Qemu

VyOS is a community fork of Vyatta, a Linux-based network operating system that provides software-based network routing, firewall, and VPN functionality. The VyOS project was started in late 2013 as a community fork of the GPL portions of Vyatta Core 6.6R1 with the goal of maintaining a free and open source network operating system in response to the decision to discontinue the community edition of Vyatta.

VyOS runs on both physical and virtual platforms. It supports paravirtual drivers and integration packages for virtual platforms. It is completely free and open source.

The aim of the tutorial is to show VyOS installation on Qemu virtual machine and  get it working on GNS3.

VyOS Qemu and VirtualBox virtual disks can be downloaded here.

I created a Bash script deploy_vyos for automatic deployment of VyOS to Qemu image. The script downloads stable VyOS ISO image from the Internet,  creates Qemu disk and starts Qemu virtual machine with attached ISO image. Then is  starts Expect script install_vyos that automatically configure all required configuration options  without user intervention.

deploy_vyos
install_vyos

Just copy both scripts to the same directory, assign run privileges to both scripts with the command below and run the deploy_vyos script.

$ chmod +x Continue reading

Confessions of a Troubleshooting Junkie

“Hey Fish, how good are you at BFD? None of my BFD neighbors will come up.” Two simple sentences and I am “hooked.”  I love troubleshooting!   Troubleshooting is just a blast for me!  It’s like being a Network Detective trying to figure out “whodunit” As I sit down in front of the CLI and the […]

Author information

Denise "Fish" Fishburne

Denise "Fish" Fishburne
CPOC Engineer at Cisco Systems

Denise "Fish" Fishburne, (CCIE #2639, CCDE #2009:0014, Cisco Champion) is a team lead with Cisco's Customer Proof of Concept Lab in Research Triangle Park, N.C. Fish loves playing in the lab, troubleshooting, learning, and passing it on.

The post Confessions of a Troubleshooting Junkie appeared first on Packet Pushers Podcast and was written by Denise "Fish" Fishburne.

Physical Networks in the Virtualized Networking World

[This post was co-authored by Bruce Davie and Ken Duda]

Almost a year ago, we wrote a first post about our efforts to build virtual networks that span both virtual and physical resources. As we’ve moved beyond the first proofs of concept to customer trials for our combined solution, this post serves to provide an update on where we see the interaction between virtual and physical worlds heading.

Our overall approach to connecting physical and virtual resources can be viewed in two main categories:

  • terminating the overlay on physical devices, such as top-of-rack switches, routers, appliances, etc.
  • managing interactions between the overlay and the physical devices that provide the underlay.

The latter topic is something we’ve addressed in some other recent posts (herehere and here) — in this blog we’ll focus more on how we deal with physical devices at the edge of the overlay.

We first started working to design a control plane to terminate network virtualization overlays on physical devices in 2012. We started by looking at the information model, defining what information needed to be exchanged between a physical device and a network virtualization controller such as NSX. To bound the problem space, Continue reading

Courage to change things

This was an internal email that I sent to the CloudFlare team about how we are not afraid to throw away old code. We thought it was worth sharing with a wider audience.

Date: Thu, 10 Jul 2014 10:24:21 +0100
Subject: Courage to change things
From: John Graham-Cumming
To: Everyone

Folks,

At the Q3 planning meeting I started by making some remarks about how much
code we are changing at CloudFlare. I understand that there were audio
problems and people may not have heard these clearly, so I'm just going to
reiterate them in writing.

One of the things that CloudFlare is being brave about is looking at old code
and deciding to rewrite it. Lots of companies live with legacy code and build
on it and it eventuallybecomes a maintenance nightmare and slows the company
down.

Over the last year we've made major strides in rewriting parts of our code
base so that they are faster, more maintainable, and easier to enhance. There
are many parts of the Q3 roadmap that include replacing old parts of our
stack. This is incredibly important as it enables us to be more agile and 
more stable in future.

We should feel good  Continue reading

Potential Issues with Multicast within a VLAN Spanning Switches

Background

I ran into an interesting issue yesterday at work. There is a new video system
being installed, which takes the video output from computers, encodes it and
sends it as multicast to a controller. The controller then displays it on
a video wall. I had been told that the network has to support multicast.
As all the devices were residing in the same VLAN, I did not expect any issues.
However, the system was not able to receive the multicast. At first we expected
it could be the virtual environment and that the vSwitch did not support multicast,
because one server was deployed on the ESX cluster. The topology was this:

Snooping1

Multicast at Layer 2

Before describing the issue, let’s think about how multicast at layer 2 works.
The source will send to a multicast destination IP. This IP is the converted to a
destination MAC address. If the group is 227.0.0.1, this would map to the MAC
address 0100.5e00.0001. Switches forward multicast and broadcast frames to all
ports in a VLAN. This is not effective in the case of multicast as the traffic
may not have been requested by the host connected to Continue reading