Healthy Paranoia Show 21: Windows Forensics with Andrew Case

That’s right, it’s time for another surveillance-free, EFF-approved episode of Healthy Paranoia! Where the passwords are salted and the packets are always encrypted. This episode is hosted by the infamous Mrs. Y, queen of metadata and official privacy advocate for Healthy Paranoia, and recorded in the NSA-proofed SCIF with Grecs, of Novainfosec.com and Shmoocon Firetalks. […]

Author information

Mrs. Y

Snarkitecht at Island of Misfit Toys

Mrs. Y is a recovering Unix engineer working in network security. Also the host of Healthy Paranoia and official nerd hunter. She likes long walks in hubsites, traveling to security conferences and spending time in the Bat Cave. Sincerely believes that every problem can be solved with a "for" loop. When not blogging or podcasting, can be found using up her 15 minutes in the Twittersphere or Google+ as @MrsYisWhy.
TwitterLinkedIn

The post Healthy Paranoia Show 21: Windows Forensics with Andrew Case appeared first on Packet Pushers Podcast and was written by Mrs. Y.

[Storage Flow Control] Part 1- Introduction

When making the leap to adopting FCoE as a storage medium, there are a few things to consider in order to be successful. Many of these concepts are foreign to the storage administrator who has been operating a native Fibre Channel SAN for the better part of the last decade or more - this is because while Fibre Channel networks are costly, they are purpose-built. There is no concept of a loop in Fibre Channel - with Ethernet we deal with these all the time.

[Storage Flow Control] Part 1- Introduction

When making the leap to adopting FCoE as a storage medium, there are a few things to consider in order to be successful. Many of these concepts are foreign to the storage administrator who has been operating a native Fibre Channel SAN for the better part of the last decade or more - this is because while Fibre Channel networks are costly, they are purpose-built. There is no concept of a loop in Fibre Channel - with Ethernet we deal with these all the time.

[Storage Flow Control] Part 1- Introduction

When making the leap to adopting FCoE as a storage medium, there are a few things to consider in order to be successful. Many of these concepts are foreign to the storage administrator who has been operating a native Fibre Channel SAN for the better part of the last decade or more - this is because while Fibre Channel networks are costly, they are purpose-built. There is no concept of a loop in Fibre Channel - with Ethernet we deal with these all the time.

Using the latest Open vSwitch with Devstack and OpenDaylight

While setting up my OpenDaylight OVSDB and Devstack following the awesome instructions from Kyle Mestery, I thought it would be fun to run the latest OVS from source on my compute nodes...

To do this, execute the following commands on one of your compute nodes before running stack.sh

sudo apt-get -y --force-yes install build-essential devscripts

gcc dkms make automake autoconf debhelper libssl-dev
pkg-config python-all python-qt4 python-zopeinterface
python-twisted-conch gdebi-core dh-autoreconf hardening-wrapper
libtool graphviz ipsec-tools module-assistant python-twisted-web
racoon git

git clone git://git.openvswitch.org/openvswitch
cd openvswitch
./boot.sh
dpkg-buildpackage -b -us -uc -nc
cd ..

Once you’ve built the .deb’s you can copy these to your other compute nodes using scp:

scp *.deb ubuntu@devstack-compute2:

Replace ubuntu with your username and devstack-compute2 with the name or IP address of your other compute nodes.

Finally we can install the packages as follows:

sudo dpkg -i *.deb

At the time of writing this will build Open vSwitch 2.1.90. You can check the version as follows:

sudo ovs-vsctl --version

Which will give the following output

ovs-vsctl (Open vSwitch) 2.1.90
Compiled Jan 16 2014 15:18:45

Huge thanks to @FlorianOtel for his help with Devstack!

@dave_tucker

A brief departure from talking IPv6

There is a lot of news surrounding Net Neutrality, and potential repercussions of decisions made by courts, and some players out there that want to grab as much cash as they can, and claim it is in the best interest of their customers.

Netflix is just an example people love citing because it is bandwidth intensive, yet is not the entire story itself. Take a moment and understand how the Internet is pieced together. The Internet is a mass of interconnections between networks. These interconnections happen basically 1 of 3 ways:

transit: network A pays network B to reach every other network that isn’t A or B. Good networks usually get multiple transits for failover, and/or alternate paths to those other networks. You can buy multiple ports for bonding to increase capacity, etc. Average transit price without a Service Level Agreement (SLA, guaranteed connectivity or you can yell at us a lot and we credit you) is around $1-2/mbit, and with a SLA can hit upwards of $10/mbit. These are current avg. prices when buying 10G at a time of connectivity/capacity right now.

peering (settlement free, or “free”): Network A spends a bunch of money to get into popular Continue reading

Large flow marking using hybrid OpenFlow

Top of rack switches are in a unique position at the edge of the network to implement traffic engineering controls. Marking large flows describes a use case for dynamically detecting and marking large flows as they enter the network:
Figure 1: Marking large flows
Physical switch hybrid OpenFlow example described how real-time sFlow analytics can be used to trigger OpenFlow controls to block denial of service attacks. This article will describe how the sFlow-RT, Floodlight OpenFlow controller, and Alcatel-Lucent OmniSwitch hybrid OpenFlow SDN controller setup can be programmed to dynamically detect and mark large (Elephant) flows as they enter the network.
Figure 2: Large flow marking controller results
In the experimental setup, a flood ping is used to generate a large flow: 
ping -f 10.0.0.238 -s 1400
Figure 2 shows the results, the left half of the chart shows traffic when the controller is disabled and the right half shows traffic when the controller is enabled. The blue line trends the largest unmarked flow seen in the network and the gold line shows the largest marked flow. When controller is disabled, none of the traffic is marked. When the controller is enabled, sFlow-RT detects the large flow Continue reading

Cisco ACI – Speculation of its Inner Workings

Last week I was at a Cisco users group meeting where some sales engineers were giving a presentation on the new Application Centric Infrastructure (ACI) architecture and Nexus 9000 products. It was a very high-level overview, but it was interesting. I had assumed when Cisco made the ACI announcement that it would be based on […]

Author information

Eric Flores

Eric Flores

Eric is a senior network engineer for a major real estate company. He has seven years in the field and has a passion for anything related to technology. Find him on Twitter @nerdoftech.
TwitterLinkedIn

The post Cisco ACI – Speculation of its Inner Workings appeared first on Packet Pushers Podcast and was written by Eric Flores.

Why We Need to Learn During Weekend

We are group of design architects/consultants who do network design in daily basis. We are spread in different countries across Asia, Europe and Middle East. We happen to have CCDE certification too. And all of us have the same dream to build the community filled up with real design experts, those who actually do design work to solve real world's network design problems. And we want to teach real design skills based on our experiences. To help those who want to become the next design architects/consultants, or to pass CCDE exam. To achieve this, we conduct design expert workshop in various locations, during the weekend.

Wait. What?

Why do we need to learn during the weekend?
It might be a good workshop. It might be an opportunity to hear real world's network design examples. It might be a good chance to meet another design professionals.
But come on, attending technical workshop during the weekend?

I hear you. I know how it feels.
After long hours of work during weekday, we deserve our weekend. When we need to learn something related to work, we should do it during workday. When we need to learn design, we can ask the company to Continue reading

sFlow leads convergence of multi-vendor application, server, and network performance management

Over the last six months, leading Application Delivery Controller (ADC) vendors F5 and A10 have added support for the sFlow standard to their respective TMOS and ACOS operating systems, making multi-vendor, real-time application layer visibility available in approximately 50% of commercial ADC market.
Figure 1: Best of Velocity 2012, The sFlow Standard
Equally important is the availability of sFlow support in leading open source web servers, load balancers, applications servers, hypervisors and operating systems, including: Apache, NGINX, Tomcat, Java, HAproxy, Hyper-V, Xen, KVM, Linux, Windows, Solaris, FreeBSD and AIX. The combination sFlow in ADCs and the application infrastructure behind them provides comprehensive end to end visibility in multi-tier, scale-out, application architectures.

Figure 1 shows the strategic role that ADCs (load balancers) play in controlling the flow of application requests, regulating admission, filtering, directing loads, and virtualizing services. RESTful control of ADCs combined with real-time visibility provides a powerful capability for flexing resources as demand changes, reducing costs and increasing performance as resources are closely matched to workloads.

What is unusual about diagram is the inclusion of the network. Application architects often give little thought to the network since its complexity is conveniently hidden behind APIs. Unfortunately, it is in the Continue reading

Show 175 Dying Desktops, Insecure Firewalls, Networking The Internet of Things

This week Greg and Ethan go back and forth on a bunch of current happenings. Data Networking is full of releases, updates and progress. In 80 minutes we will discuss the topics that look important to us.

Author information

Greg Ferro

Greg Ferro is a Network Engineer/Architect, mostly focussed on Data Centre, Security Infrastructure, and recently Virtualization. He has over 20 years in IT, in wide range of employers working as a freelance consultant including Finance, Service Providers and Online Companies. He is CCIE#6920 and has a few ideas about the world, but not enough to really count.

He is a host on the Packet Pushers Podcast, blogger at EtherealMind.com and on Twitter @etherealmind and Google Plus.

TwitterFacebookGoogle+

The post Show 175 Dying Desktops, Insecure Firewalls, Networking The Internet of Things appeared first on Packet Pushers Podcast and was written by Greg Ferro.

CEF Secret Attributes, Part 2

In Part 1 we saw there were three markings that can be potentially applied to a prefix in CEF. They are the Precedence, qos-group and traffic_index. It’s unfortunate these terms were used because we also find that we are marking prefixes in CEF, not packets, so these terms don’t perfectly map to our traditional sense […]

Author information

Dan Massameno

Dan Massameno is the president and Chief Engineer at Leaf Point, a network engineering firm in Connecticut.

The post CEF Secret Attributes, Part 2 appeared first on Packet Pushers Podcast and was written by Dan Massameno.

Overhauling PacketLife.net for 2014

Regular readers no doubt have noticed that I haven't posted anything new in the past few months. I've been pretty busy with the holidays, home projects, and adjusting to a new job, and haven't had much time or motivation to devote to writing. Good news though: I have started on a long-overdue refresh of the Packet Life design and code base.

When I originally debuted Packet Life, I ultimately wanted it to serve as major community hub, so I built in features like the wiki and discussion forum. Although Packet Life has grown quite popular over the last few years, these areas of the site have seen little activity. Acknowledging that there are more active and useful sites out there which serve these functions, I've decided to chop off some of the bloat in favor of focusing on the blog and the site's other more popular features.

Here's the fate I've outlined for each function of the site:

Blog: The blog is the heart of the site and will remain mostly unchanged, albeit refreshed and optimized. I'm considering allow guest posts but haven't committed to the idea.

Lab: No, there are no plans to bring the community lab back online Continue reading

Microloop!

Don’t look now, but you have microloops. How do I know? Because virtually every network with rings larger than three hops, running a link state protocol, will develop a microloop during normal convergence. Okay, so what’s a microloop, and how dangerous is it? Let’s figure this out looking at the (now rather standard) five router […]

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

The Journey Starts 2014 – CCIE Security – Blog Post1

Well it is time to buckle down and make it happen in 2014. The goal is to become a dual CCIE by the end of 2014. I have previously passed the CCIE Sec written in version 3 but I did not have the time to actually sit for the lab and I also wanted to refresh to the latest version of the track. That said I am taking a small step back to refresh and reinforce the theory. The plan is to go through the NP Security track while labbing but also taking the respective NP exam followed by the written and then ultimately sit for the lab.

Here is the order as it stands today:
  • 642-627 IPS - Implementing Cisco Intrusion Prevention System 
  • 642-618 FIREWALL - Deploying Cisco ASA Firewall Solutions 
  • 642-648 VPN - Deploying Cisco ASA VPN Solutions 
  • 642-637 SECURE - Securing Networks with Cisco Routers and Switches
  • ISE and WSA 
  • CCIE Written 
  • CCIE Lab
The primary partner that I am leveraging is CiscoPress and Cisco Docs for the theory and iPexpert for all the heavy labbing. 

The great thing about this journey is that I already eat, sleep, and breath Cisco .:|:.:|:.

Twitter: FE80CC1E

Physical switch hybrid OpenFlow example

Alcatel-Lucent OmniSwitch analytics driven control provided an example with a physical switch, using the Web Services API to send CLI controls to the switch as HTTP requests, the following screen shot shows the results:
Figure 1: Controller using HTTP / REST API
Integrated hybrid OpenFlow describes how the combination of normal forwarding combined with OpenFlow for control of large flows provides a scaleable and practical solution for traffic engineering. The article used the Mininet testbed to develop a DDoS mitigation controller consisting of the sFlow-RT real-time analytics engine to detect large flows and the Floodlight OpenFlow controller to push control rules to the software virtual switch in the testbed.
Figure 2: Performance aware software defined networking
The OmniSwitch supports hybrid mode OpenFlow and this article will evaluate the performance of a physical switch hybrid OpenFlow solution using the OmniSwitch. The following results were obtained when repeating the DDoS attack test using Floodlight and OpenFlow as the control mechanism:
Figure 3: OmniSwitch controller using hybrid OpenFlow
Figure 3 shows that implementing traffic controls using OpenFlow is considerably faster than those obtained using the HTTP API shown in Figure 1, cutting the time to implement controls from seconds to milliseconds.
Figure Continue reading
1 … 3,701 3,702 3,703 3,704 3,705 … 3,779