Sneak preview on the topics May 30:

- Storage/VDI performance considerations and measurement
- VDI I/O and workloads, boot storms
- Storage disk virtualization
- Architectural change with pooling
- Thin provisioning
- Forward error recovery and data integrity
- IDA based systems
- SSD economics
- Big data analytics

…and more

VDI is usually justified on a €/user basis. This really requires a lot of intelligence…and it almost always comes back to the storage system.

Lets get ready to rumble

psiepel@schubergphilis.com

In order to allow the STT tunnel (http://tools.ietf.org/html/draft-davie-stt-00) through a firewall you need to bypass the SYN/ACK security.
STT uses a header that looks just like the TCP header to the NIC. The NIC is thus able to perform Large Segment Offload on what it thinks is a TCP datagram.

The Cisco ASA is able to bypass this on specific interfaces with an ACL.

access-list tcp-bypass-syn-ack extended permit tcp src_network-host dst_network-host
access-list tcp-bypass-syn-ack extended permit tcp dst_network-host src_network-host

class-map tcp_bypass_syn_ack
match access-list tcp-bypass-syn-ack

policy-map tcp_bypass_syn_ack_policy
class tcp_bypass_syn_ack
set connection advanced-options tcp-state-bypass

service-policy tcp_bypass_syn_ack_policy interface ingress_interface
service-policy tcp_bypass_syn_ack_policy interface egress_interface

Verify the connections to show the bypassed connections: show connections | include flags b

• The NetApp and Brocade best practices state the “desired distance” of a ISL port should be set to 1.5 times the actual distance. This will then set the buffer credits to a certain amount.
• This article from NetApp also describes a second method: calculating the average frame rate to determine the needed amount of buffer credits.

Depending on the average frame size of your ISL traffic the difference between these two methods can be significant.

Use the following  to  calculate if your buffer credit settings might be a problem:

portstats64show <port> – This gives the amount of frames send (stat64_ftx) and amount of BB_credit zero occurrences (tim64_txcrd_z).

stat64_ftx      3           top_int : Frames transmitted
                970578587   bottom_int : Frames transmitted

tim64_txcrd_z   0           top_int : Time BB_credit zero
                46631371    bottom_int : Time BB_credit zero

The total amount of frames sent is (2^32)*<top_int>+<bottom_int>.
The total amount of BB_credit zero is (2^32)*<top_int>+<bottom_int>.
The percentage of BB_credit zero is (<BB_credit zero>/<frames sent>)*100.

According to Brocade some BB_credit zero is allowed, but no more than 15% (which still seems high).

Use the following to calculate the average frame size:

portstats64show <port> – This gives us the amount of words sent (stat64_wtx), which translates to bytes send.

stat64_wtx      1485        top_int : 4-byte words transmitted
                4108584283  bottom_int : 4-byte words transmitted

total amount of bytes sent = ((2^32)*<top_int>+<bottom_int>)*4.
average frame size = <bytes sent>/<frames sent>.

Use the following to calculate the desired distance which is used by the Brocade switch to set the buffer credits:

desired distance = (real distance*2112) / average frame size.

Set this distance on the Brocade switches using:

portCfgLongDistance <port> LS 1 <desired distance>

To see how the buffer credits are configured for each port and how many your switch still has available:

portbuffershow

If you want you can calculate how the switch will translate the desired distance to buffer credits:

buffer credits = <desired distance>*(<link speed>/2) + 6

If QoS is enabled on the port it will allocate another 14 buffer credits. By default QoS is enabled, but no QoS zones are configured. In effect this does nothing except consume an extra 14 buffer credits per port. Unless you are going to really use QoS by configuring QoS zones it is best to disable QoS on all ports. This will give you more buffer credits to use where they are really needed.

An example comparison of the two methods:

Real distance: 50km
Average frame size: 1016 bytes
Link speed: 4GB

NetApp best practices method desired distance: 50km*1.5 = 75km. This will configure the switch to use 75*4/2+6 = 156 buffer credits.
Average frame size method desired distance: (50*2112)/1016 = 104km. This will configure the switch to use 104*4/2+6 = 214 buffer credits.

In this example 214 buffer credits will be needed, while using best practices only 156 buffer credits would be configured..

Real world:

Using the average frame size method the BB_Credit zero percentage on one of our ISL’s dropped from 22% to 2%. On another ISL it dropped from 16% to 0.3%!

The differences will not always be this dramatic, and in a lot of cases the best practices method will ensure there are more buffer credits configured then needed. Which is a good thing. There is no advantage to having a lot of buffer credits available, so use them to get the maximum throughput between your switches!

psiepel@schubergphilis.com

On June 6th, 2012, IPv6 will permanently be enabled by many web sites like Facebook, Yahoo, Google and the likes.

Schuberg Philis is also part of this movement where per this date we will be running all our public services on IPv6; www.cupfighter.net being our first. Actually, it is already publicly available via IPv6 internet address 2001:67c:20c8:aa00::20. How cool is that!?

Read about what IPv6 will mean to Mission Critical businesses in our white paper. It addresses what it is and what it will mean to you and (your) online business(es).

IPv6; The future is forever… The future is now.

On the FortiGate gui or cli, there are options to export the certificate but it only exports the public key part.

It’s pretty simple to retrieve this information because the private key part is stored in plain text in the configuration, go to the cli and edit the certificate:
conf global
conf vpn certificate local
edit <certificate_name>

When you lost the password, you can set a new password:
unset password
set password <new_password>

Display the certificate so you can copy&paste the private key part to a keyfile:
show full-configuration

—–BEGIN RSA PRIVATE KEY—–
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,
……
—–END RSA PRIVATE KEY—–

Lego - A CC NC ND image

by Nikhal Mittal

Nikhal has written a tool call Kautilya which uses Teensy a programmable USB development board to mimic a keyboard. The good (or bad) thing about mimicking a HID (Human Interface Device)  is that HID devices are explicitly trusted by most modern operating systems. Kautilya is a tool that makes the use of Teensy in Penetration  Tests easy.

Teensy is a small board and thus is can be disguised as a USB toy, lost USB stick or something else clever and left in e.g. a parking lot or a smokers area.

Nikhal showed demonstrations in which he used Teensy to type out command line code that:

• Download a program and execute it
• Create a Windows administrative user
• Dumped system password hashes to pastebin
• Logged keystrokes to pastebin
• Bound a meterpreter shell to TCP port 444
• Created a metasploit reverse shell using a signed java applet
• Connect a computer to a hotspot and download a program from it

Kautilya makes a lot of these actions relatively easy for any pentester (and hacker) to perform.

Nikhal has used this in the past to get access to different targets.

• At a large media firm they used this to backdoor a library system and thus gain access to the network.
• At a telecom company they were able to gain access by enabling telnet access and adding an administrative user by selling the teensy’s as cheap pendrives

So how do you protect against this?

• Endpoint protection can help, but can be circumvented
• A GPO that prevens installation of hardware devices

Limitations of Teensy/Kautilya?

• Not much storage on the devices
• Many payloads require administrative privileges
• Inability to clear the payload after a run.
• Lots of traffic is generated to Pastebin
• Not very stable yet as it not well tested

Future extensions:

• Improved payloads
• SD card on teensy
• Support for non-english keyboards

Nikhil Mittal

Nikhil Mittal is a hacker, info sec researcher and enthusiast. His area of interest includes penetration testing, attack research, defence strategies and post exploitation research. He has over 3 years experience in Penetration Testing of many Government Organizations of India and other global corporate giants at his current job position.

He specializes in assessing security risks at secure environments which require novel attack vectors and “out of the box” approach. He is creator of Kautilya and Mareech. In his free time, Nikhil likes to scan full IP ranges of countries for specific vulnerabilities, writes some silly Metasploit scripts and does some vulnerability research. He has spoken at Clubhack’10, Hackfest’11, Clubhack’11 and Blackhat Abu Dhabi’11

No More Sake - A CC ND Image

By Antonios Atlasis

Antonios starts by giving us an overview of fragmentation attacks in IPv4. Attacks via IP packet fragmentation is not new, in fact the first attacks were documented in 1998. And many uses are currently documented:

• OS fingerprinting
• IDS/IPS insertion/evasion
• Firewall evasion
• Even remote code execution

So what does changes in packet fragmentation with the introduction of IPv6?

• IPv6 headers are limited to 40 bytes
• Extension Headers have been added
• The do not fragment bit has been removed

IPv6 attempts to minimize fragmentation. If the MTU is too small to handle an IPv6 packet it is up to the lower layers in the network stack to handle fragmentation and reassemblation. In IPv6 only the sending host is allowed to fragment a packet.

The IPv6 specification also tries to protect against overlapping fragments. If overlapping fragments are received the entire dataram should be discarded.

Antonios tested how well different operating systems handle fragmented IPv6 packets.

First attack tested: small fragments – All tested OS answer IPv6 echo request that was fragmented smaller then the IPv6 specification allows.

Why is this important? If we can use very small segments we may be able to split the IPv6 destination block in up to 32 fragments which forces a firewall to spend a lot of CPu cycles in reassemblation.

Next attack: overlapping fragments – Not accepted by Free BSD, Ubuntu 111 and Win 7, but accepted by Ubuntu 10 and OpenBSD

Why is this important? If can be used for OS identification and for IDS/IPS Insertion / Evation purposes

Next attack: The Paxson/Shankar Model – Not accepted by Free BSD, Ubuntu 111 and Win 7, but accepted by Ubuntu 10 and OpenBSD

Ubuntu follows the Linux reassembly policy and OpenBSD uses the BSD reassembly policy.

Next attack: 3 overlapping packets in over 22 scenarios and 22 scenario’s in reverse order

In this care only FreeBSD does not reply at all.

Antonious finished his talk with a demo.

Conclusion: fragments attacks still seem to be possible in IPv6 as not all OS-es seem to adhere to the specifications and seem to deviate in different ways.

Antonios Atlasis
Centre for Strategic Cyberspace + Security Science

Antonios Atlasis, MPhil, PhD, is an independent IT Security analyst with a passion for information security research. He has over 20 years of diverse Information Technology experience. Antonios is also an accomplished instructor and software developer with research interests in the areas of penetration testing, incident handling, intrusion analysis and bug-finding. Antonios recently joined the Centre for Strategic Cyberspace + Security Science non-profit organisation.

Jeni sells us XPath - CC image

By Sumit Siddharth & Tom Forbes

XPath is a language to query XML data.Sometimes XPath is used to query the backend data of web applications in stead of a database. XPath injection is a vulnerability that can be compared to SQL injection. An attacker can inject something that has a XPath ‘meaning’ into the string (e.g. ‘ or ’1=1) and get different results then the designer of the application intended.

Sumit and Tom show different examples of these injections.

But, XPath can also be used to get to metadata of the document. By creatively manipulating the query you can get the entire XML document without much trouble.

Tom has written the tool XCat that automates blind XPath injection to get the contents of the entire XML file.

XPath 2.0 adds loads of features. These functions speed up Xpath injection. But, it also has functions that allow you to access so called ‘cross file joins’ which allows an attacker to load any XML that is on the system. Also this function can be used to connect to external websites so more data can be exfiltrated and data extraction can be speeded up. Or, if outgoing HTTP is limited, you can append that data to a domain name and watch the logs of the authoritive DNS server of that domain.

In summary if you use XPath 1.0, sanitize any user input before inserting it into you XPath statement or make sure there is no sensitive data in the XML document you are querying.

If you use XPath 2.0 make sure you sanitize your XPath satements or all XML files on your system are at risk.

Some sites use XQuery, which is a super set of XPath. This allows an attacker even a greater attack surface.

Tom and Sumit found XPath injection vulnerabilities in eXist-DB which is used by databases in the wild. Using these vulnerabilities the entire content of the eXist-DB can be exfiltrated.

The mitigation of XPath/XQuery injection are the same as for any injection attack:Escape and validate any data that is passed to you by a user. XPath allows you to parameterize in the same way as prepared SQL statements and bound variables.

Blackhead Persian - A CC image

By Stephen de Vries

Security testing is the black sheep of application testing. Often developers run unit test, integration test, but security tests are often postponed to the end of the lifecycle.

How can we make security testing like unit and integration testing?

Stephen starts by showing us how a “normal” integration test works using selenium. By showing a functional test for a login page.

Function tests can be integrated into continuous integration platforms like e.g. Jenkins.

Stephen makes a case for using Behaviour Defined Development as a communication tool and JBehave as a test tool that supports this. JBehave can be run as JUnit tests.

BDD-Security is a combination of JBehave and Page Object method of Selenium in a security focused integration test framework.

BDD-Security can be used to test both the security of login functions as well as business functions.

Stephen demonstrates the BDD-Security platform with the iSpatula application and shows how the basic security tests are executed for the login page, but BDD-Security is more versatile then that. Using BDD-Security Stephen demonstrates a test that test is a non-admin user cannot have access to administrator functions.

So what about scanning? Does this replace it?

Stephen’s new tool Resty-Burp allow you to use Burp as a restful service. He shows how he has integrated Burp into BDD Security framework to include scanning for security scanning.

BDD Security allows the security requirements of an application to be defined and tested.

Stephen de Vries
Corsaire

Stephen de Vries is a principal consultant for Corsaire’s Security Assessment team. His focus is on application security and on improving the security practices in software development.

Stephen has worked in the security field since 1998 and has spent the last 12 years focused on Security Assessment and Penetration Testing at Corsaire, KPMG and Internet Security Systems. He was a founding leader of the OWASP Java project and regularly presents talks on secure programming and security testing.

Andy got interested by hacking HDMI when he was checking USB security on the Black Berry playbook.

When further investigating the HDMI port he found out that HDMI does not only provide Video out and Audio out, but also provides EDID to send information to and from the device.

Video standards have long history dating back to the 1970s.

VGA is one of the older standard describing how to transmit analog video.

In the VGA standard 4 pins were originally designed to provide monitor information.

VGA later supported DCC to communicate monitor capabilities.

DVI is a digital video standard.

It was designed to replace VGA and also includes DCC.

HDMI uses the same digital video signal as HDMI and it also supports DCC and a load of new functions such as Ethernet.

Display Port was developed by VESA as a complement to HDMI. It is getting wider use because it is a royalty free HDMI equivalent.

So what is DCC?

When a monitor is connected to a devices it takes a few seconds before an image is displayed. In that delay period the monitor and the host communicate their capabilities and the hosts decides how to best send the data to the device.

The host powers the chip in the monitor so DCC identification can still happen if the monitor is powered off.

E-DCC allows for even more data to be sent, which needs to be parsed. And parsers are notorious for their vulnerabilities.

One of the blocks that can be sent is the ‘localized string extension block’, and as any block of strings it has plenty of opportunities for overflowing buffers.

Andy decided to fuzz the E-DCC data to find out how this would affect the host. In order to do this he needed a way to emulate a monitor. Het used an Arduino microcontroller for this.

The Arduino firmware can be downloaded van the research section of http://ngssecure.com

So what were the results?

BlackBerry playbook: Stopped responding the VESA block was fuzzed. This bug triggered another bug which killed the system logger daemon.

Nvideo Windows driver: Various crashes detected, but no predictable overflows found yet

But the DDC protocol isn’t the only in/out protocol in HDMI, there are more.

CEC – Consumer Electronics Control

CEC allows you to control multiple HDMI devices with a single remote control and allows HDMI devices to control each other without user interaction.This protocol runs over the AV.link protocol a one-wire bi directional serial bus.

Unfortunately the CEC fuzzer is currently under development and results are unknown yet.

HEC – HDMI Ethernet Channel

Allows e.g. a BlueRay player to connect to the Internet using a wirelessly connect TV.

Andy did not test this protocol

HDCP – High-bandwidth Digital Content Protection HDCP’s intention is to prevent copyright infringes. However its key has allready leaded rendering it useless.

Conclusion:

• Video displays do send data back to devices, they do not just received data
• Users expect a seamless experience and thus this will be come more and more common
• There are (basic) vulnerabilities in the software that receives this information

Checking the obvious, no proxyserver enabled, TLS/SSL protocols enabled and also the steps mentioned in http://support.microsoft.com/kb/956196 gave no solution.
Debugging / sniffing / monitoring showed correct SYN-SYNACK-ACK handshake to the webserver but SSL session handshake failed. Okay, so there must be something wrong with certificates.

On a working system you can see the certificate being all okay:

Okay, so let’s export the root certificate and verify it on the failing server:

This certificate has an nonvalid digital signature and The integrity of this certificate cannot be guaranteed. The certificate may be corrupted or may have been altered.
I highlighted the interesting part: Signature algorithm….. On the working client it shows sha256RSA and the failing client 1.2.840.113549.1.1.11.

Let’s ask mr. Microsoft what this OID is: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381133(v=vs.85).aspx (CRYPT_ALGORITHM_IDENTIFIER structure).
szOID_RSA_SHA256RSA and that’s sha256 with RSA encryption, just like the working server can tell us. But why can’t the failing server validate this certificate based on a sha256RSA (SHA2) hash algorithm?

Here’s where the following MSKBs come to the rescue:

http://support.microsoft.com/kb/968730 - Windows Server 2003 and Windows XP clients cannot obtain certificates from a Windows Server 2008-based certification authority (CA) if the CA is configured to use SHA2 256 or higher encryption.

http://support.microsoft.com/kb/938397 - Applications that use the Cryptography API cannot validate an X.509 certificate in Windows Server 2003.

In Microsoft Windows Server 2003, applications that use the Cryptography API (CAPI) cannot validate an X.509 certificate. This problem occurs if the certificate is secured by the Secure Hash Algorithm 2 (SHA2) family of hashing algorithms. Applications may not work as expected if they require the SHA2 family of hashing algorithms.

Additionally, when you evaluate a certificate that uses the SHA2 family of hashing algorithms, you may receive the following message:

This problem occurs because the Cryptography API 2 (CAPI2) in Windows Server 2003 does not support the SHA2 family of hashing algorithms. CAPI2 is the part of the Cryptography API that handles certificates.

To add support for SHA2 you need the above hotfix 968730 and (obviously) add the missing rootCA certificates in the trusted certificate store, after reboot the server can use the SHA2 certificate and access the website.
*pfew* that was a toughie.

Some more background information can be found in the Windows PKI Blog post “SHA2 and Windows”: http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx

cheers,
Matthijs
 

update 2012-03-30:
If you have hotfix KB968730 installed and apply KB2641690 (crypt32.dll update) it seems to break SHA2 support, re-applying KB968730 seems to fix it.
 

In many ways my conclusions of the first two conference days were reconfirmed but additionally I learned that;

1. IPv4 is here to stay and it will take many more years before IPv4 is completely history. On the other hand, it is still unpredictable when IPv4 address space is really exhausted. See Geoff Huston’s IPv4 reports. Predictions are currently somewhere later this year or perhaps 2013 or even later, depending on the demand for IPv4 addresses and the way the use for IPv6 actually evolves.
2. Any NAT technology like Carrier Grade NAT (CGN) has disadvantages to make it a viable transition mechanism. As such it is less preferred.
3. Dual stack is the preferred transition mechanism. Where the content provider or hosting party provides access to (web) services via both IPv4 as well as IPv6.
4. The sheer size of the IPv6 address space requires to get rid of the classical IPv4 thinking regarding address waste and the use of private IP addressing. These limitations simply don’t exist anymore. Currently the smallest routable IPv6 subnet is a /64 subnet which could have up to a maximum of 18,446,744,073,709,551,616 unique IPv6 addresses. Think about it; each /64 subnet is significantly larger than the existing IPv4 address space altogether!
5. If the 100 biggest web sites in the world (the likes of FB, Google, Yahoo, Amazon, Microsoft, Akamai, etc) would get accessible via IPv6, it would ensure that the world would adopt IPv6 much faster.
6. End users need to have IPv6 enabled Customer-premises equipment (CPE) such as mobile devices, DSL modems and routers, before the content providers and ISPs really would benefit the transition. Without these IPv6 enabled devices there is simply no demand for IPv6. This chicken-egg problem needs to be addressed on either side; both the ISPs as well as content providers needs to provide IPv6 solutions to address the IPv4 exhaustion and global expansion of Internet enabled devices.
7. If vendors say that they are IPv6 ready, do not take this for granted. Many implementations have shown (interoperability) limitations when deployed. Inform the vendor of any issues so that this gets improved.
8. Basic IP address space allocation:
   a. /32 for Schuberg Philis
   b. /48 per customer environment
   c. /64 per smallest subnet (VLAN)
   d. /127 potentially for point-to-point links (on demand, implementation specific, not internet routable)

The Dual stack mechanism
an interesting solution to implement IPv6 is providing web services in a so called ‘dual stack’ setup. This means that content is provided both via IPv4 as via IPv6. There are several dual stack scenario’s.

Tore Anderson of Redpill Linpro AS discussed the following scenario, an IPv6 centric dual stack set up, his recommendation and in his opinion most future proof:

I found this an interesting view as it emphasizes on the majority of components within an IT (hosting) environment being IPv6 configured but only a small part of it being IPv4 capable. This scenario would lead to a more future proof set up, focusing on the phase out of IPv4 altogether.

A bogon is a …
Something I also learned but until this conference I’ve never heard of before, is a so called bogon.

It’s wikipedia definition is:

“a bogus IP address, and an informal name for an IP packet on the public Internet that claims to be from an area of the IP address space reserved, but has not yet been allocated or delegated by the Internet Assigned Numbers Authority (IANA) or a delegated Regional Internet Registry (RIR).”

I actually found this quite funny because I’ve been around in this industry for some time now so I was somewhat surprised that I haven’t heard of this word before.

All in all,
This was a very interesting conference where I learned that IPv6 is inevitable and that the momentum is now to prepare for it. 6 June 2012 is the day to mark your agenda; it will be the day when IPv6 will permanently be turned on by many internet (content) providers.

Don Lee from Facebook and author of the Cisco Press book “Enhanced IP Services for Cisco Networks” argued; “It’s our job as IT professionals to make the transition to IPv6 as smooth as possible. The end users should not bother about it, much less as they bother nowadays about IPv4.”

And as Paul Zawacki, Enterprise Architect at Oracle so eloquently put; “IPv6 is a giant leap in IT evolution. It might very well be the most challenging moment in your professional career.”

I feel that these remarks are no understatements… Do you?

The opening speech
was done by John Curran, the founder and president of ARIN (the American Internet Registrar, the equivalent of the European RIPE organization). John was involved in IPng the early RFCs of what eventually became known as IPv6. How cool is that!?

My colleague Erwin Blekkenhorst (maintainer of IPv6.net) also tweeted a lot of interesting remarks and sound bites. Follow ‘@ipv6dotnet’ for getting those tweets.

During the panel discussions several companies shared their views and experiences on the IPv6 implementation and IPv4 to IPv6 transition. Better said co-existence or ‘dual stack’ providing your services via IPv4 and IPv6 in parallel.

I will not bore you with an exhaustive summary (send me a message and I will) of each presentation but I’d like to condense it into a) it’s interesting and worthwhile being at this conference and b) I feel that this is the environment were ‘it’ actually happens; the Internet industry adopting IPv6.

My conclusions
of the second day would be:

1. Moving from IPv4 to IPv6 is inevitable. Not being part of it is basically ‘missing the boat’ and loosing the competitive advantage.
2. Be prepared before actually implementing IPv6. Have a sound strategy resp implementation plan.
3. Implementing IPv6 is a ‘journey‘. Take it on a step by step basis and learn as you go and grow.
4. Despite many (hw or sw) vendors say that they support IPv6 they do not always interact as you’d expect.
5. So in addition; try before you die (i.e. perform a POC ensuring that your design is providing what you aim for. Feed the findings back to the hw/sw vendors.
6. Expect to spend a lot of time on awareness and training. Knowledge on IPv6 is the critical success factor.
7. From a Schuberg Philis IPv6 Task Force perspective we seem to be aligned with what the industry as a whole is doing; we are part of the IPv6 community for some time now and are already enabled on connectivity level. Application layer IPv6 is our next challenge.
8. I believe it is important that Schuberg Philis and our customers who are able to participate are part of the IPv6 World Day June 6, 2012. Let’s go for it!
   The FUTURE is NOW!

Central question of this congress is: “Enterprises Migration: How and When?”

Amongst others, both Erwin and me are IPv6 task force members within Schuberg Philis and we are determined to increase the IPv6 awareness with our fellow collegues and our customers. The questions we would like to address are: How will it impact us, our business and what will it mean to our customers, what are the ways to ‘migrate’ safely from IPv4 to IPv6 resp to operate a dual stack setup?

On this blog I’ll be posting our experiences and impressions of this congress on a day-to-day basis.

Day 1 – Technical Tutorial Day – Tue Feb 7th

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]

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.

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.

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!