Cupfighter.net

The Cisco ASA firewall offers protection for Denial of Service attacks, such as SYN floods, TCP excessive connection attacks etc.
With the Policy Framework functionality, you can configure granular controls for TCP Connection limits and timeouts. For example, you can control and limit the maximum number of simultaneous TCP and UDP connections that are allowed towards a specific host (or subnet), the maximum number of simultaneous embryonic connections allowed (for SYN flood attacks), the per-client max number of connections allowed etc.

STEP1: Identify the traffic to apply connection limits using a class map
ASA(config)# access list CONNECTIONS-ACL extended permit ip any 10.1.1.1 255.255.255.255
ASA(config)# class-map CONNECTIONS-MAP
ASA(config-cmap)# match access-list CONNECTIONS-ACL

STEP2: Add a policy map to set the actions to take on the class map traffic
ASA(config)# policy-map CONNECTIONS-POLICY
ASA(config-pmap)# class CONNECTIONS-MAP
! The following sets connection number limits
ASA(config-pmap-c)# set connection {[conn-max n] [embryonic-conn-max n]
[per-client-embryonic-max n] [per-client-max n] [random-sequence-number {enable | disable}]}

The conn-max n argument sets the maximum number of simultaneous TCP and/or UDP connections that are allowed, between 0 and 65535.
The embryonic-conn-max n argument sets the maximum number of simultaneous embryonic connections allowed, between 0 and 65535.
The per-client-embryonic-max n argument sets the maximum number of simultaneous embryonic connections allowed per client, between 0 and 65535.
The per-client-max n argument sets the maximum number of simultaneous connections allowed per client, between 0 and 65535.

! The following sets connection timeouts
ASA(config-pmap-c)# set connection timeout {[embryonic hh:mm:ss] {tcp hh:mm:ss
[reset]] [half-closed hh:mm:ss] [dcd hh:mm:ss [max_retries]]}

STEP3: Apply the Policy on one or more interfaces or Globaly
ASA(config)# service-policy CONNS-POLICY {global | interface interface_name}

The IP audit feature provides basic IPS support for the ASA. It supports a basic list of signatures, and you can configure the ASA to perform one or more actions on traffic that matches a signature.

STEP:1 To define an IP audit policy for informational signatures
ASA(config)# ip audit name policy_name info [action [alarm] [drop] [reset]]

STEP:2 To define an IP audit policy for attack signatures
ASA(config)# ip audit name policy_name attack [action [alarm] [drop] [reset]]

Where alarm generates a system message showing that a packet matched a signature, drop drops the packet, and reset drops the packet and closes the connection. If you do not define an action, then the default action is to generate an alarm.

STEP:3 To assign the policy to an interface
ASA(config)# ip audit interface interface_name policy_name

STEP:4 To disable signatures
ASA(config)# no ip audit signature [signature]

A few days ago while starting TortoiseSVN it prompted me to update to version 1.7

After I updated to version 1.7. I could not connect to our internal repository anymore. The connection failed with the following error: SSL error: sslv3 alert certificate unkown.

SSL error: sslv3 alert certificate unknown

Our internal respoitory is secured with a certificated issued by our internal CA infrastructure.

Root CA

|
v

Intermediate Certificate

|
v

Repository certificate

Surfing to the svn repository does not produce an error, so the certificate chain is fine. At first I figured that Tortoise was using its own certificate store, but it turns out that Tortoise does use the Windows Root CA store, so there is no need to add the Root CA.

After some more investigation we found out that Tortoise does use the Windows Root CA store to validate the certificate chain, but does not use the Intermediate CA store to complete the certificate chain, like windows does. Since all our client machines have the intermediate certificate in the Intermediate CA store we never noticed that the certificates offered by apache were not chained. After chaining the repository certificate with the intermediate certificate Tortoise was able to talk to the repository again.

The ACE has two different ways of treating the L7 connections internally, that we call “proxied” and “unproxied”. In essence, the proxied mode means that the traffic will be processed by one of the CPU (normally to inspect/modify the L7 data), while, on the unproxied mode, the ACE sets up a hardware shortcut (Fastpath) that allows forwarding traffic without the need to do any processing on it.

For a L7 connection, the ACE will proxy it at the beginning, and, once all the L7 processing has been done it will unproxy the connection to save resources until L7 processing is required again. Before it goes ahead with the unproxying, it needs to see the ACK for the last L7 data sent.
In packet captures, we see that the client is taking approximately 200ms to send this acknowledgement each time. When a connection is composed of many HTTP requests, the proxy/unproxy process can add up a total delay of several seconds.

The configuration of a sorry/backup server farm with for example a HTTP redirect to a sorry page will cause the ACE to treat the connections to the VIP as a L7 and influence the total page load time.

The proxy/unproxy delay can have a big impact for situations in which the client is taking a long time to send the acknowledgement, so, the ACE allows to change the behavior. It is possible to define a “round-trip-time” threshold so that connections from clients with a RTT value higher than the threshold are never unproxied.
You can do this by setting the threshold to 0 to ensure to keep connections always proxied. To do this, you would need to configure a parameter map like the one below and add it to the policy-map.
parameter-map type connection
set tcp wan-optimization rtt 0

Even though this setting will most likely solve the issue, it also has some drawbacks. The main one is that the ACE appliance only supports up to 256K simultaneous L7 connections in proxied state (which includes also the connections towards the servers, so, it would be 128K for client connections), so, if the amount of simultaneous connections reaches that limit, new connections would be dropped. The second issue, although not so impacting, would be that the maximum number of connections per second supported would also go down slightly due to the increased processing needed.

http://dnssec-debugger.verisignlabs.com/
http://dnsviz.net/

There are many concerns these days on security when taking services from cloud providers. All the areas where Schuberg Philis is actively being audited on, are area’s of concerns for IT managers.

How do I know my cloud service is being hacked and abused if it is not running inside my datacenter? What possibilities do I have to check if my employees are acting along the lines of my Acceptable Use policy? Where are the logs of that abuse, and how can I trust the logs? How do I know that my data is not copied elsewhere in the cloud, and analysed offline by my competitor?

With regards to cloud storage, the CDMI (Cloud Data Management Interface) is trying to address some of the questions, but is only one step forward.

Cloud service providers still have a long way to go. An initiative like Eurocloud  is doing great work in paving the road to trust in cloud service providers.

When cloud service providers will be able to succesfully address the concerns, they have a big advantage over the classical IT model of running your own IT: they provide all the securities you would normally build and control youself, but combined with cloud advantages like fast provisioning and fast reuse of resources.

Small and medium-sized business will then be able to actually get a better and more secure service with cloud services, then what they could build and control themselves.

What does this mean for SBP? Sure there will be competition from the cloud providers. But we are nothing more than just another cloud provider. We build services for our clients with our own cloud technologies of fast provisioning, centralized log analysis, but since we build private clouds for our customers, these customers can demand tailored solutions to address their specific needs and concerns.

Cloud computing is not a threath to our business model, but is preparing the market more and more for putting commodity services in the big generic clouds, combined with the need of supporting highly tailored private clouds.

So it is time to face the fact: Schuberg Philis, the private cloud company!

Powering the cloud. Multi marketing of course, but what is happening in the storage world? What does it mean for mission critical environments? These are the questions I am hoping to get answered today and tomorrow. Currently three sessions done. 1. Introduction to Data protection by Chriss Sop, 2. Optimizing storage in a cloudy, virtualized world by The 451 Group and 3. Enterprise Tiered Storage by John Locky.

First two sessions were somewhat low quality from a contect perspective. Too basic from on technology and on new innovations. Even for me as a non engineer. The difference between full backup, incrementals and differentials is not the thing we came here for. Although i must say that merging incrementals on the back end to always have full backups available sounds interesting. Curious to see this working in real life. How transprrent will that be? Lets ask Commvault later today. And if i can find them Quest as well. Would be nice to learn a bit on automated restore testing as well. Guaranteeing back ups remains an issue. Especially on tapes.

When i get answers, you’ll probably read more about it on cf.net or twitter.

In order to have the F5 BigIP LTM announce IPv6 Router Advertisements (RA) you have to logon to the console and create the following config file:

#
# /etc/radvd.conf
#
interface [interface name]
{
AdvSendAdvert on;
MinRtrAdvInterval 5;
MaxRtrAdvInterval 10;
AdvDefaultPreference low;
AdvHomeAgentFlag off;
prefix xxxx:xxxx:xxxx::/yy
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
};

You have to use lower-case characters for the interface or vlan name otherwise this will not work!

Then stop the service: bigstart stop radvd
And start the service again: bigstart start radvd

OpenFlow, the exciting new networking technology recently bursting out of academia and into industry, has generated considerable buzz since Interop Las Vegas 2011, which has been called “The Coming Out Party For OpenFlow.”

OpenFlow began at a consortium of universities, led by Stanford and Berkeley, as a way for researchers to use enterprise-grade Ethernet switches as customizable building blocks for academic networking experiments. They wanted their server software to have direct programmatic access to a switch’s forwarding tables, and so they created the OpenFlow protocol. The protocol itself is quite minimal — a 27-page spec that is an extremely low-level, yet powerful, set of primitives for modifying, forwarding, queuing and dropping matched packets. OpenFlow is like an x86 instruction set for the network, upon which layers of software can be built.

In an OpenFlow network, the various control plane functions of an L2 switch — Spanning Tree Protocol, MAC address learning, etc. — are determined by server software rather than switch firmware.

Today, the OpenFlow protocol has moved out of academia and is driven by the Open Networking Foundation, a nonprofit industry organization whose members include many major networking equipment vendors and chip technology providers and has a board of some of the largest network operators in the world like Google, Microsoft, Yahoo, Facebook, Deutsche Telekom and Verizon.

Most current OpenFlow solutions incorporate a three-layer architecture, where the first layer is comprised of the all-important OpenFlow-enabled Ethernet switches. Typically, these are physical Ethernet switches that have the OpenFlow feature enabled. We’ve also seen OpenFlow-enabled hypervisor/software switches and OpenFlow-enabled routers. More devices are certainly coming.

There are two layers of server-side software: an OpenFlow Controller and OpenFlow software applications built on top of the Controller.

The Controller is a platform that speaks southbound directly with the switches using the OpenFlow protocol. Northbound, the Controller provides a number of functions for the OpenFlow software applications — these include marshalling the switch resources into a unified view of the network and providing coordination and common libraries to the applications.

At the top layer, the OpenFlow software applications implement the actual control functions for the network, such as switching and routing. The applications are simply software written on top of the unified network view and common libraries provided by the Controller. Thus, those applications can focus on implementing a particular control algorithm and then can leverage the OpenFlow layers below it to instantiate that algorithm in the network.

This three-layer OpenFlow Architecture should feel very familiar to software architects. For example, consider the Web application server architecture: applications sitting on top of a Web application server sitting on top of a database layer. Each of the lower layers presents an abstraction/API upward that simplifies the design of the layers above it.

The big picture is that OpenFlow and the larger movement in the networking industry called “Software-Defined Networking” promise true disruption because they enable rapid innovation — new networking functionality implemented as a combination of software applications and programmable devices, effectively bypassing the multi-year approval/implementation stages of traditional networking protocols. This acceleration is possible because of the layered design of the software/hardware architecture.

This year the annual EuroBSDcon conference was held in the Netherlands. As usual it was a very interesting conference where each of the BSD’s (FreeBSD, OpenBSD and NetBSD) presented the cool things they are working on. The talks on Saturday started with Testing NetBSD which demonstrated how the NetBSD project is using unit-testing to improve code quality. After that there was the PF anniversary talk by Henning Brauer and Ryan McBride, which provided a nice contrast between Henning’s energy and Ryan’s calm demeanor and showed that they have quite a few plans for the next 10 years of PF. The next talk was about NPF, the new packetfilter in NetBSD. It was really cool to see that the OpenBSD PF developers where quite interested to see which new ideas they could borrow from NPF to make PF better, open source at its finest. Saturday concluded with the BSD history talk by Kirk McKusick, which was a very entertaining description of how Open Source and Unix started at Berkely even before people really knew what they were doing.

Sunday started with a very interesting talk by Herbert Bos about the work done at the VU University which pushes the limits of what’s possible with regards to reliable operating systems. Some of the other interesting talks were the Capsicum talk by Robert Watson which focused on providing applications what they need to solve real-world security problems and the OpenSSH talk by Damien Miller which described all the useful new features available to make our lives easier. The new rlimit-based sandboxing for OpenSSH is an especially neat trick.

Possibly the best part of the conference was the amount of Dutch speakers, it’s awesome to see this level of contributions from my home country. So let’s keep up the good work and make next year even better.

Byju Pularikkal, Cisco Systems, gave two detailed technology overview presentations on IPv6.

The first part covers the structure, addressing and services:
Pularikkal_PartI.pdf

The second part covers routing and transition mechanisms:
Pularikkal_PartII.pdf