This post originally appeared on the CohesiveFT blog
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 caching, SSL 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.
Filed under: CohesiveFT, Docker, networking, security | 1 Comment
Tags: Docker, intrusion, NIDS, rules, Snort, Suricata, VNS3
This post originally appeared on the CohesiveFT blog
Amazon recently announced the new t2 family of low end instances, which I wrote about on InfoQ. Pricing wise the headline is that the t2.micro is ¢1.3/hr, which is a fair bit cheaper than the ¢2/hr of the t1.micro it replaces. It also has much better performance, and more consistent performance, and more transparent performance characteristics, and more RAM.
¢1.3/hr is good, but it’s still not sub penny. It somehow reminds me of the big old pre decimal pennies that people still had in little china pots when I was a kid.
¢1.3/hr is however the on demand pricing. It’s also possible to get t2.micro reserved instances in medium and heavy usage varieties. Pushing things to the max gets a 3yr heavy utilisation reserved instance that costs $109 up front and ¢0.2/hr. If we leave the instance up for the full 3 years, and amortise the $109 up front then that comes out to ¢0.615/hr – a little less than half the on demand pricing.
¢0.615/hr – now that’s sub penny :)
Filed under: cloud, CohesiveFT | Leave a Comment
Tags: amazon, aws, cloud, iaas, penny, pricing
Conventional wisdom says that high performance networking needs inflexible hardware based on application specific integrated circuits (ASICs). That same conventional wisdom says that software implemented networks – aka Network Function Virtualization (NFV) – are slow, particularly if implemented on top of the convoluted networking stack in Linux. Snabb Switch defies that conventional wisdom by putting high performance switching software into Linux on regular Intel-based servers (and even virtual machines).
Continue reading at The Stack
Filed under: networking, The Stack | Leave a Comment
Tags: Neutron, NFV, OpenStack, Snabb, switch
Docker Inc have announced their acquisition of Orchard Labs, a provider of hosted Docker services. Orchard are also the developers of Fig, a composition and orchestration tool for multi container Docker applications. The London based Orchard team is two strong, with prolific developers Ben Firshman and Aanand Prasad.
Filed under: Docker, InfoQ news | Leave a Comment
Tags: Docker, Orchard Labs
Multi tier Docker apps with Fig
I had a play with Fig whilst researching my InfoQ story on Docker’s acquisition of Orchard Labs.
Rather than just going through the quick start guide and firing up their example app I thought I’d try out my own three tier demo from when I last wrote about multi tier apps with Docker. The three docker run commands get placed into a Fig config file[1]:
todomvcdb: image: cpswan/todomvc.mysql expose: - "3306" volumes: - /data/mysql:/var/lib/mysql todomvcapp: image: cpswan/todomvc.sinatra expose: - "4567" links: - todomvcdb:db todomvcssl: image: cpswan/todomvc.ssl ports: - "443:443" links: - todomvcapp:app
It’s as simple as that[2]. The application is then brought up using[3]:
sudo fig up
Whilst at one level this is simply moving complexity from one place (docker run) to another (fig.yml) the result is more manageable and elegant. I look forward to seeing what happens to Fig as the Orchard team integrate into Docker.
Notes:
[1] Sadly WordPress doesn’t support YAML with it’s code tag.
[2] Though I did need to remove the underscore separators I’d previously had e.g. todomvc_app.
[3] The need for sudo isn’t pointed out in the Fig docs :(
Filed under: Docker | 2 Comments
Tags: Docker, Fig, Orchard Labs
This was a warm up for a presentation I’ll be doing at AppSec USA later in the year.
I got some good feedback on the night, but if you have more then please make a comment below.
Filed under: CohesiveFT, Docker, presentation, security | Leave a Comment
Tags: Chicago, DevOps, Docker, meetup, security
Amazon has launched new web services designed to simplify the building and operation of mobile applications using their cloud as a back end. Cognito provides an identity management platform and key/value store, and is complemented by Mobile Analytics. The AWS Mobile SDK has been updated to version 2.0 to provide integration with the new services, and there are samples in github for iOS and Android.
Filed under: cloud, identity, InfoQ news, mobile | Leave a Comment
Tags: amazon, analytics, android, aws, Cognito, identity, iOS, mobile
This post originally appeared on the CohesiveFT blog
Want to do more with your AWS Virtual Private Cloud (VPC)? We have 10 ways you can enhance cloud networking with our virtual appliance, VNS3.
First, a quick background on the product: VNS3 creates an overlay networking on top of AWS infrastructure. This allows you to control security, topology, addressing and protocols for your applications wherever they are.
Since its launch in 2008, VNS3 has secured over 100 Million virtual device hours in public, private, and hybrid clouds. VNS3 is software-only, and acts as 6 devices in 1:
- Router
- Switch
- VPN concentrator for IPsec and SSL
- Firewall
- Protocol re-distributor
- Scriptable network function virtualization
1. You control the cipher suites and keys
The AWS VPC default (and only) encryption algorithm choice for VPN connections is AES-128. AES-128 is a good, but what if your industry regulations or internal policies need AES-256, or the partner you’re connecting to insists on 3DES? Then there’s the question of how exactly pre shared keys (PSKs) are shared – are you really happy to share keys with a 3rd party service provider?
2. Connect across availability zones, regions, and into other clouds
Fault boundaries are there for a reason, and a resilient application should be spread across fault boundaries. The only good reason for VPC subnets being limited to a single availability zone (AZ) is simplicity for Amazon’s network engineers. VPC has provided VPC Peering but is limited in number of VPCs that can be peered, intra-region only, and security features. VNS3 subnets can span across AZs, regions or even into different clouds such as Azure, HP and Google Compute Engine.
3. Pay only once for IPsec connectivity and NAT (not twice)
VNS3 providers IPsec and NAT capabilities in one virtual instance. With AWS VPC IPsec is one billable service, and the NAT AMI also runs up the EC2 bill.
4. Oh no – everybody picked the 10.0.0.0/16 default and now we can’t connect
As previously mentioned, VPC now has a peering feature to join networks together. That great but bad luck if you picked the default VPC subnet and so did the person you’re connecting to. Beware the default network. VNS3 can map network address ranges, so you can connect to all those partners who didn’t know better than to pick the default. This also applies to IPsec end points, so you can connect to multiple parties with the same IP ranges on their internal networks.
5. You want to connect your VPN gateway to more than one VPC
Once a public IP has been used for a remote endpoint for a VPC VPN connection that public IP can’t be used again in that region. Only one VPC VPN can connect to a specific endpoint’s public IP per region. Of course you could assign another IP at the gateway end, but that’s extra cost and hassle.
6. Your partners want to use IPsec over NAT-T
VPC hardware gateways only support native IPsec, whilst VNS3 can deal with either native IPsec or IPsec with network address translation traversal (NAT-T) – just not both at once[1].
7. Multicast (and other neglected protocols)
AWS is not alone in having no support for multicast – most other clouds don’t either[2] – it’s pretty hard to make a multi endpoint networking protocol work in a multi tenant environment. Not only does VNS3 enable multicast in the cloud by using overlay networking, you can also connect to enterprise multicast networks. We can also use generic routing encapsulation (GRE) to get other protocols out of the data centre and into the cloud.
8. Monitoring
VNS3 supports SNMP, and you can also dump traffic from network interfaces for additional logging and debugging.
9. Extensibility
Want to add SSL termination, a proxy server, some load balancing or content caching. You could use a bunch of extra VMs on your network edge, or you could avoid the additional cost, complexity and security concerns by using some Docker containers on VNS3.
10. Reliability
A major telco was finding that most of its cloud based customers had repeated connectivity problems, but a handful didn’t. It turned out that handful was running VNS3.
Try Before You Buy – VNS3 Lite Edition free trial in AWS
CohesiveFT is participating in the AWS Marketplace Network Infrastructure free trial campaign this July. The Lite Edition is available for a 1 month free trial for all AWS public cloud users. Customers who actively use VNS3 Lite Edition trial in AWS will receive $100 in AWS credits.
- Get started now in the AWS Marketplace.
- See our press release for more details and the full terms.
Notes
[1] It is possible to support native IPsec alongside NAT-T, and we have customers doing that, all that’s needed is a couple of VNS3 managers in the cloud.
[2] See Sam Mitchell’s “Ask a Cloud Networking Expert” post on why multicast is disabled in public cloud.
Filed under: cloud, CohesiveFT, networking | Leave a Comment
Tags: amazon, aws, ec2, VNS3, VPC
Amazon have introduced T2, a new class of low cost general purpose instances for EC2 intended for workloads that don’t drive consistently high CPU usage. At the low end t2.micro offers higher performance, more memory (1GiB) and a lower cost (1.3¢/hr) than the previous t1.micro. The T2 class also offers small and medium sizing with 2GiB and 4GiB RAM respectively. T2 instances all offer burstable performance, which is intended for peaky workloads.
Filed under: cloud, InfoQ news | Leave a Comment
Tags: amazon, aws, cloud, EBS, ec2, iaas, instances, T2
Chris Swan's Weblog 