Tuesday, July 29, 2014

Network Intrusion Detection on VNS3

The Docker subsystem available since version 3.5 allows additional virtualized network functions (VNFs) to be run on VNS3. I've previously written about using this capability for content cachingSSL termination and load balancing. This time I'll cover using it as a network intrusion detection system (NIDS).

Introducing Suricata


The archetypal NIDS system for Linux is Snort. Suricata is the newer alternative developed by the Open Information Security Foundation. It's multi threaded, to make it more scalable, has improved protocol and file identification, and is somewhat easier to install and configure (though that's taken care of with a Dockerfile anyway).

The demo application


For a little while I've used an application based on Nginx, Sinatra and MySQL to demo VNS3. It's gratuitously three tier, but it's a good way of showing off the various moving parts of an overlay network. The app implements a simple web based todo list with persistence to the database.

Getting the traffic into the NIDS


Firstly I uploaded my suricata-demo Dockerfile to VNS3 to become a container image, then I allocated a container from it, which was given the first available IP of 198.51.100.2. Getting traffic off the overlay and into the container just needs an entry like this in the firewall:

       
# copy all traffic from the overlay network to the NIDS container
MACRO_CUST -j COPY --from tun0 --to 198.51.100.2 --bidirectional
       
 

Whilst I'm there it's also worth putting in the rules so that I can connect to the container over SSH (in order to see detection in action):

       
# enable NAT to allow containers to talk to the outside world
-o eth0 -s 198.51.100.0/28 -j MASQUERADE
# forward port 2222 from the VNS3 manager to port 22 on the container
PREROUTING_CUST -i eth0 -p tcp -s 0.0.0.0/0 --dport 2222 -j DNAT --to 198.51.100.2:22
       
 

Application specific rules


A nice thing about application centric networks is that they can have application specific rules for intrusion detection - there's no need to have a kitchen sink list of rules to catch every possible attack that would apply to an entire enterprise network.

For demo purposes I have a single rule that detects Mastercard numbers:

       
alert tcp any any <> any any (pcre:"/5\d{3}(\s|-)?\d{4}(\s|-)?\d{4}(\s|-)?\d{4}/"; msg:"MasterCard number detected in clear text";sid:9000001;rev:1;)
       
 

This rule is looking for the pattern 5XXX-XXXX-XXXX-XXXX where each X is a digit and each - could be a dash, a space, or nothing. It's not doing any validation that the numbers are valid Mastercard numbers, it's just picking up the pattern of something that looks like a Mastercard number

When this triggers (by putting a Mastercard number into the todo list) an alert can be seen in Suricata's fast.log file e.g.:

       
07/22/2014-19:51:20.753227  [**] [1:9000001:1] MasterCard number detected in clear text [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.56.111:4567 -> 10.0.6.50:37589
       
 

Try it for yourself


The full cohesiveft/suricata image is available on Docker Hub (and Github). It uses Oinkmaster to pull a full set of rules from Emerging Threats.

The cut single rule down demo version cohesiveft/suricata-demo described above is also available on Docker Hub (and Github).

Whether you start out with a full rule set, and cut out the stuff that causes too much noise, or come at it the other way to build up a rule set to address specific concerns - the choice is yours.


Friday, July 25, 2014

Cloud & networking weekly news roundup: July 21 - 25

Cloud and Networking news for the week of July 21


  • From Cite World: Go free, apps! Microsoft will offer their popular apps across competitors' platforms
  • From Chris Swan on InfoQ: Docker Acquires Orchard Labs 
  • EIN Tech: Research and Markets: Cloud Computing Market in Canada 2014-2018 >> "Cloud Computing market in Canada will grow at a CAGR of 17.8 percent over the period 2013-2018."
  • Re/Code: Three Big Takeaways From Amazon’s Q2 Financial Results >> despite a slower quarter for revenue growth (from 60% to about 35%) AWS estimates customer growth is 90% year over year.
  • Happy Sys Admin Day! We got you this:

CohesiveFT in the news:

Catch up with the CohesiveFT team:

Thursday, July 24, 2014

Ask a Cloud Netwoking Expert: How is IPsec secure?

IPsec (Internet Protocol Security) is the communication method used to secure packets as they journey across an IP network, usually between two sites seperated by the public Internet. IPsec uses cryptographic security services to authenticate and encrypt each data packet as it travels two endpoints and protects that data from network sniffers or what we call looky-loos.

IPsec connections ensure you data isn't read or tampered with when you connect in any type of network. We think IPsec is especially important when you're building hybrid deployments between owned on-premises infrastructure and the public clouds.  Of course this is nothing new as enterprises have been using the IPsec network standard for years to build secure network connections to branch offices, partner and customer sites.

IPsec tunnels connect remote locations to
public cloud resources. Image CC CohesiveFT
An IPsec tunnel is built between two endpoint devices that "speak" the network standard.  You can think of the following two phases and these two devices cordially introducing themselves and establishing a connection via an appropriately firm and friendly handshake.  IPsec negotiation is divided into two phases:

Phase 1: Initial negotiation phase. Peers find each other over the internet and trade security parameters in order to create “session keys” that prove they are who they claim to be.  This is what security experts call a key exchange, and the peers use the Internet Key Exchange Protocol (IKE) to validate each other’s security claims.

Phase 2: Peers trade Phase 2 security parameters. The peers trust each other, and now can create an encrypted tunnel that connects them using IPsec Protocol Encapsulating Security Payload (ESP) to encrypt the IP Packet. That way, no one else can see what data is traveling between the peers. Even if someone was able to see the data, it is all encrypted and unreadable without a secure key.

IPsec has 2 types of implementation: a host-to-host transport mode, or network tunneling mode:

Transport mode
In transport mode, only the payload of the IP packet is usually encrypted and/or authenticated. Transport mode does not change the routing, since IP headers aren't modified or encrypted. Transport mode works best in host-to-host connections.

Tunnel mode
In tunnel mode, the entire IP packet is encrypted and/or authenticated. Tunnel mode must encapsulated the headers into a new IP packet with a new IP header. VPNs use tunnel mode for network-to-network communications, host-to-network communications, and host-to-host communications. Tunnel mode does support NAT traversal.

In VNS3 you can configure IPsec VPN tunnels from the web UI or API.  In either case, we've made the setup extremely easy while still providing all the configuration options to allow power users to drop some heat. In the IPsec configuration page, you can set up NAT-Traversal or local private IP addresses. From the VNS3 Admin Console you can then set remote endpoints, add extra parameters, and set up your tunnels.

Oh and VNS3 connects to everything...

Interested in checking out some screen shots of our IPsec setup process?  You can find the full VNS3 3.5 configuration guide, with IPsec configuration instructions, here.

Check out our other expert posts on IPsec issues, like IPsec lifetime issuesBuilding a Permanent IPsec Tunnel, and how VNS3 enhances AWS VPC with some IPsec features

Expert Profile 

Source: this guy
Name: Ryan Koop
Title: Director of Products and Marketing
Favorite Snack: Cashews
Credentials in the "Expert's" words: 
Do I have a bunch of certifications?  Nope.  Sadly my Smart Cloud Advisor and Architect expired.  My primary job function is marketing, let's see if I can self promote.

I have a over six years of experience designing our cloud network product.  I also moonlight as a member of our support team (does that make me a masochist?) and services team.  In those roles I have helped our customers design, deploy and tune hundreds of cloud networks and troubleshoot thousands of IPsec tunnel negotiations.  In many cases, I end up configuring both sides of the connection and have become familiar with a number of network security and routing hardware appliances from all corners of the market: Cisco, Juniper, Watchguard, Dell SONICWALL, Netgear, Fortinet, Barracuda Networks, Check Point, Zyxel USA, McAfee Retail, Citrix Systems, Hewlett Packard, D-Link, WatchGuard, and Palo Alto Networks.

Tuesday, July 22, 2014

Secure provisioning of Docker containers


By Nicholas Clements, Director of Engineering at CohesiveFT

One of the areas for which CohesiveFT is known is our technical support, with everyone pitching in. We provide such a high quality of support for our products that customers often ask about support and best practices for other products and services. One such event occurred recently when a customer was asking about best practices in the secure provisioning and configuration of Docker images and containers. Since we support the use of containers in version 3.5 of VNS3 Manager we were more than happy to talk.

The customer wanted to know how to create and customize Docker containers in a safe and secure manner. In general terms they wanted to have each container be individual with keys and configurations that would be applicable only to the group/user accessing the container. This would allow them to control who sees what and to easily add or revoke privileges. They wanted to distribute images and Dockerfiles without make them available to the world at large, they wanted to keep the generated credentials in a controlled, private repository.

And they wanted to do this without doing a ton of development work.

There are many ways to inject data into an image or a container. One approach used by many Docker aficionados is to keep the image itself suitable for public consumption and then pass sensitive information at container start time, either by environment variables or by mounting an external location into the container. Both the customer and CohesiveFT view that this approach compromises the “sandbox” aspect of Docker, although it is certainly a useful method to keep in the mental toolbox as Docker evolves.

Image credit: Lifehacker


This approach is not feasible with VNS3 -- the customer has no direct access to the VNS3 filesystem and we don’t (currently) support the passing of environment variables through our API or GUI. (We’re working on it. Promise. Maybe in version 3.7.)

Currently, customers can upload images directly or have the VNS3 appliance build them into the network platform. Customers can either start from scratch using Dockerfiles and public repositories or they can upload their own images.

We ran through a few scenarios with the customer. Their view was that there were two immediate options available with minimal risk:

Running a configuration management client inside the container -- but on reflection it was decided that this just pushed the issue further down the road, since the same problems would need to be solved at a later date.
Building images with predefined SSH keys, running sshd in the container, and connecting after the fact to deliver the individual keys and config files etc -- Issues here include timing, plus the need to figure out a method for pre-generating and storing all of the keys (or using a common key which, it was agreed, is a bad idea).

Even though Docker 1.0 is now out, Docker is still evolving rapidly as are the accepted best practices. In order to protect our customers as much as possible we decided to approach things from a conservative perspective.

The goals were:
  • Creation of a standard image in a secure manner, with as little exposure as possible
  • Customization of that image on a per-VNS3 instance, per-container possible, securely
  • Secure storage of modifications
  • Minimal development

We started with a secure but accessible way for storing objects, image files, Dockerfiles, configuration and supporting files. This was simple and the final implementation choice was left to the customer. Our suggestion was to use an internal, behind-the-firewall web server and have it join the VNS3 topology. An alternative was to use S3 and signed URLs with a long expiration.

Next we examined the choice between the use of a Dockerfile or a pre-built image. Since the customer was looking at adding containers to a preexisting topology we recommended the latter. It would have a lesser effect on the network. The result is the same - when we use images we use Dockerfiles to build them and then export the resulting container.

Finally, per-manager customization. One of the features that we implemented in VNS3 3.5 is the ability to rebuild an image based on a locally stored one. This approach uses a Dockerfile but since the base image being used is local the impact on the manager is slight. And if the commands used in the Dockerfile are minimal then the overall rebuild is quick.

The initial proof-of-concept used the VNS3 GUI to import a base image (unimaginatively called “base_image”) with an unknown root password and personalize it through an external Dockerfile archive.

   FROM vns3local:base_image
   RUN mkdir -p /root/.ssh
   RUN echo "[PUBLIC KEY HERE]" >> /root/.ssh/authorized_keys
   RUN chmod 400 /root/.ssh/authorized_keys

It took a further couple of hours to put together a simple bash script that made use of the VNS3 API and pulled the public key from a private key server as a proof-of-concept.

So with a couple of lines of code it’s possible to securely create -- and, more importantly, securely destroy -- personalized Docker containers within VNS3. The customer didn’t need to spend a lot of time or money on an elegant solution to their problem. Security and control.

Friday, July 18, 2014

Cloud & networking weekly news roundup: July 14 - 18

Cloud and Networking news for the week of July 14

  •  Gigaom Research Survey: new business will drive second wave of cloud adoption >> Surveys predict a near-term second wave of cloud technology adoption, driven by companies re-inventing their business. "Tech buyers of all stripes tell us they expect to nearly double their usage of software-defined-networking (SDN) in two years, to a nearly 30 percent adoption rate. "
  • BizTech : SMB Awareness of SDN Technology Is Small, but Growing >> "Techaisle estimates SDN awareness among SMBs will grow substantially over the next couple of years, reaching $204 million in 2016." 
  • Gigaom: Getting enterprise-y, AWS Marketplace adds annual software subscriptions >> hey, that's us! VNS3 Lite is one of the pay-as-you-go options in AWS
    https://aws.amazon.com/marketplace/pp/B00KFPTGA0/ref=_ptnr_ftpromo_cohesiveft
    Try VNS3 in the AWS Marketplace promo
  • Network World: Rackspace rolls out new hosted computing tier: Managed cloud >> on Tuesday Rackspace announced "Managed Cloud" a combination of managed service with cloud.
  • Chris Swan on InfoQ: New Low End T2 Instances for Amazon EC2 >> Our CTO takes the new t2 instances for a test drive in AWS 


CohesiveFT in the news:
  • VNS3 Lite Edition available for free in the AWS Marketplace in July. The Network Infrastructure Campaign runs from July 1 - 31, and active VNS3 users can qualify for $100 in AWS credit!
  • Annual pricing for VNS3 Lite Edition inside the AWS Marketplace. Now you can use VNS3 in AWS on an hourly, monthly, or annual subscription basis. Learn more.
Source: Gigaom Research 

Catch up with the CohesiveFT team:
  • Wed, July 23 AWS User Group London
  • Thurs, July 24 CloudCamp Chicago at TechNexus “Developer Night” theme
  • Wed, July 30 CohesiveFT hosts the July AWS User Group 
  • Sept 11 London CloudCamp on FinTech
  • Sept 12 DockerConf in London
Related Posts Plugin for WordPress, Blogger...