Network

F5 iRule — No Pool Members Available Vanity Page

I wrote a iRule post located here, where I describe the essentials behind how beneficial iRules can be and the many use cases they have. I stumbled across a situation the other day for a client. This client had an F5 VIP load balancing 2 web servers of theirs. Now if those web servers for some reason are not available due to their healthcheck monitor failing, the users of that web site will receive a white page as the F5 will not proxy the traffic because there are no available pool members. I thought what if this was a big site, should users be left in the dark about a web site they use frequently when it’s not available? Then the idea of having the F5 LTM bounce back a well-formed splash page. This splash page would inform the user that the web site temporarily down, and if they believe this result is in error to contact their helpdesk.

This situation can be remedied with a couple of lines in an iRule.

when HTTP_REQUEST {
    #check if no members available
    if { [active_members [LB::server pool]] == 0 } {
       #create data variables with HTML content to send to client
       set httphost [string tolower [HTTP::host]]
       set data "<h2>$httphost</h2><h3>NOTICE: Site Unavailable.</h3>If you believe you are receiving this message in error, contact your site administrator."
       #send the HTML string
       HTTP::respond 200 content $data
    }
    #unset variables
    unset $httphost
    unset $data
}

Continue reading…

Cisco ACL — Dedicated Internet Edge Drop Device

A dedicated drop device is a network appliance, usually a router or L3 switch that sites at the very edge of your network infrastructure. Beyond the firewall, and usually acts a as either layer 2 or 3 transit devices for your ISP interconnect uplinks for public or untrusted segments. Distinguishing a dedicated drop devices in your infrastructure interconnected chain of paths can enhance and offload many irrelevant packet transactions from ever hitting your Firewall mitigation appliances. The thought around this approach is to remove processing cycles away from your more expensive security appliances such as firewalls or IPS, allowing said devices to dedicate their efforts toward more complicated session and/or application driven attacks.

Continue reading…

The Remote Access VPN Battle — SSL vs IPSec VPN

I’ve recently posted two articles covering two different VPN connection methods. SSL Remote VPN and IPSec Remote VPN via Cisco ASA security applicance. In the article I promised I would go thru and do a deteail compare and contrast of them. So Let’s get start!!

As promised here is the follow up post I mentioned here regarding setting up an Cisco AnyConnect remote access. Luckly the process is very similar to a remote access IPSec tunnel in the previous article with a few exceptions. Lets work through the differences between Cisco AnyConnect and a standard remote access IPSec Client VPN.

ComparisonSSL Remote VPNIPSec Remote VPN
Cost$$ per Connection, SSL certificate costsUsually none, no SSL certificate costs
CapacitySeats limited to licensingLimited to Crypto Hardware
PerformanceSSL with DTLS = Very FastIPsec without NAT-T = fast
VulnerabilitySSL vulnerabilties released frequentlyIPSec requires pre-shared key
RequirementsSSL requires TCP 443, DTLS requires UDP 443IPSec requires IP Protcol 50 (ESP) and UDP 500(IKEv1), NAT-T requires UDP 4500
Connection ConsiderationsSSL requires TCP 443 outbound for clientsIPSec requires both Layer 3 and Layer 4 protocols

NOTE: The table here is a quick reference when comprising SSL remote VPN with IPSec remote VPN. There are many things to consider when choosing between the two. SSL VPN is newer than IPSec, however the answer on which is better is not so straight forward.

IPSec remote VPN utilizes a variety of protocols and ports to form a successful tunnel. If you remember from my article on IPSec and NAT-Traversal, port requirements are UDP 500 for IKEv1 exchange, IP Protocol 50 for ESP communication, and if negotiated UDP 4500 for NAT-T. Most of the time these ports and protocols will not be allowed access outbound to the Internet. For instance, many guest networks like hotels and conferences only allow web browsable ports, such as 80(HTTP) and 443(HTTPS) outbound. That is a lot of firewall exceptions to establish an IPSec remote VPN.

SSL remote VPN introduces many connection and scalability improvements, making remote VPN functionality easier for the end user. SSL remote VPN solves the IPSec issues of a opening ports to establish a VPN session. Remote users no longer connect differently depending on where they are nor do they need to know how they are connected to the Internet, no fancy ports need to be opened, no issues with NAT-Traversal, etc. SSL remote VPN uses a very common trusted port for communication TCP 443 (and UDP 443, more on that later). This port is 99% of the time open to communicate with the Internet web sites. Using a commonly allowed port eliminates the issues seen with IPSec when establishing a VPN.

The trade-off, SSL remote VPN communicates via SSL/TLS. As stated this requires TCP, which is a stateful transport protocol. The issue arises when you have a remote host operating an application that uses TCP as well, such as web browser or Remote Desktop Connection. The scenario is now TCP on top of TCP, resulting in heavy overhead. Imaging the following scenario, you have a SSL remote VPN host connected, they then open a RDP session to a server on your network. So far so good. Now what happens when either the RDP session or the SSL remote VPN session requires a re-transmission because of connectivity problems. TCP re-transmission storms. Both the VPN session and RDP session will require re-transmissions, generating heavy overhead. Now this is not to say that either session will not recover, cause they will unless the connection is completely severed, TCP will do its job. Datagram Transport Layer Security(DTLS) to the rescue!!!

Datagram Transport Layer Security (DTLS)

DTLS is the savior and its what makes SSL client VPNs a very competitive remote access VPN technology. DTLS was designed to secure traffic similar to TLS, but without having to rely so heavily on the underlying TCP transport. TLS relies on TCP to guarantee delivery in the event of message fragmentation, message reordering, and message loss. So getting ride of any one of those TCP features will break the TLS crypto logic.  DTLS solution to these issues is as follows:

  • Message Fragmentation — Fragmentation occurs when a packet datagram is too large to fit within an MTU (usually 1500bytes’ish). Fragmentation is detected and handled by the transport technology (TCP/UDP). TCP has mechanisms built in to solve this while UDP does not. DTLS solves this issue by introducing its own fragmentation offset and length value in the DTLS message itself. This ensure that both ends of the communication are provided fragmentation information regardless of the underlying transport.
  • Message Reordering — Reordering occurs for several reasons, a common reason is delayed delivery of the underlying network. Reordering isn’t a huge issue for transport technologies like TCP because it uses sequence numbering to ensure the original data is reassembled properly. TLS requires the sequential delivery of packets to preform it’s crypto logic, meaning TLS needs the previous packet to be able to decrypt the next packet N+1. DTLS solves this by adding it’s own sequence numbering to the application, allowing it to not be dependent on the underlying transport technology.
  • Message Loss — Packet loss occurs when a packet in a data stream never reaches its destination in a certain period of time. Message loss is handled very similar to Message Recording. For TLS and it’s TCP transport, re-transmissions are triggered for lost packets when sequence numbering doesn’t compute correctly for a agreed upon window. DTLS fixes this by adding a simple re-transmission timer to it’s application logic, thereby allowing it to re-transmit packets without relying on the transport protocol.

Keep in mind that DTLS built-in functionality of these usually transport specific recovery mechanisms creates the need for additional RAM/memory on the server-side. Another cool fact is most of these “fixes” come from IPSec ESP technology! See RFC4347 for more information.

Helpful links:

PAC File and Web Proxy Auto-Configuration (WPAD) HowTo

Hello! I posted an article a while back on how to use a web proxy to block unwanted content. While this is good and fun, we need an easy way to configure clients to use the proxy. For this article I will be over both PAC file deployments and WPAD deployments. We will use the example proxy server of 172.16.0.5:3128. Let’s go!

First a few common ways clients are configured to use a Web Proxy:

  • Manual configuration — Client manually inputs configuration data into each of their browsers to use the web proxy for each protocol (HTTP, HTTPS, FTP, etc).
  • PAC File –– A PAC(Proxy Auto-configuration) file, is a method where the client’s browser is configured with the location of the PAC file via http:// or https:// to be downloaded automatically .
  • WPAD — WPAD (Web Proxy Automatic Detection) is the automatic and transparent configuration of client’s to use and send their web-traffic to a proxy server. This deployment of PAC files using already existing network protocols such as DNS or DHCP options.
  • GPO — GPO( Group Policy Objects deployments are primarily used in Windows Domain environments. User will obtain proxy configuration automatically through these Group Policy Objects upon log-in. (not-covered in this article)

Continue reading…

Cisco AnyConnect SSL/TLS Trustpoint

I wanted to put together a quick tutorial for setting up a Cisco ASA – AnyConnect with SSL/TLS. I’ve done it a few times and I always have to re-lookup each step and the order in which to do it, so why not make a quick post about it to remember!

Optional: Destroy Current Trustpoint

You will have to destroy or clear out the current trustpoint if it already exists. This must be done if you are going to re-generate the key, which is best practice when renewing a Certificate due to expiration or one that has been compromised.

asa01(conf)# no crypto ca trustpoint oldtrustpoint.trustpoint
  • It will warn you that it will destroy any certificates within the trustpoint.
Generate a Key

Here we start with the generation of our key, using 2048 bits. the key name can be anything you want, but I like call it by the service I will be putting it on, for my case for this tutorial is accessthejimmahknowscom.key

asa01(conf)# crypto key generate rsa label accessthejimmahknowscom.key modulus 2048
Setting up the trustpoint locale and generate a CSR for submission

    First we need to set up a trustpoint object, with our locale properties, etc

asa01(conf)# crypto ca trustpoint newtrustpoint.trustpoint
asa01(config-ca-trustpoint)# subject-name CN=access.thejimmahknows.com,O=thejimmahknows,C=US,St=Connecticut,L=Wethersfield
asa01(config-ca-trustpoint)# keypair accessthejimmahknowscom.key
asa01(config-ca-trustpoint)# fqdn access.thejimmahknows.com
asa01(config-ca-trustpoint)# enrollment terminal
asa01(config-ca-trustpoint)# exit
  • newtrustpoint.trustpoint — The name I gave to this trustpoint which will tie everything together.
  • subject-name This command holds the distinguished name of the Certificate’s profile, see RFC3039
  • keypair — This is what key to pair the trustpoint with, we generated this in the previous step.
  • fqdn — This is the main FQDN of our service that will use the trustpoint
  • enrolment terminal — This tells the Cisco ASA to output the CSR (which we will create in the next step) to the terminal screen. Otherwise you will have to SFTP to the ASA and download it.

Continue reading…

VoIP:101 — Getting started with your VoIP Network — Part 1

VoIP networks, VoIP phones, VoIP extensions, VoIP everything. VoIP seems to be one of those black box buzz words that IT pros toss around, like the “CLOUD!” But what is really going on behind the scenes? How does VoIP protocols actually work? How can I setup a Call System? How do I get an outside number people can use to dial me?

This next series of blog posts (Part1, Part2, Part3) are dedicated to walking through the many aspects related to VoIP(Voice over Internet Protocol) and it’s features.

PART #1 — Laying the foundation for our VoIP network
  • The Lab — Our Network pieces.
  • SIP — Life blood of VoIP
  • FreePBX/Asterisk — Call System Exchange
  • Phone Provisioning (Manual/Auto)
    • Manual Provisioning with Zoiper, Liphone, UbiPhone
    • Auto-provisioning with Cisco 7941G and 7945G (7961G,7965G)
  • Making your first VoIP call!
PART #2 — Call routing, Call numbers, SIP Trunks
  • VoIP SIP Termination — Where VoIP ends and PSTN begins
  • SIP Trunks and DID(external PTSN numbers)
  • Outbound and Inbound Call Routing
  • Optional: Install g729 codec
PART #3 — Ring Groups, Extension Shortcuts, Call Centers, Voicemails, Secure SIP with TLS, etc
  • Ring Groups
  • Extension Speed Dialing
  • IVR (Interactive Voice Response) — useful for Business Directory Prompt
  • Advanced Voicemail Services
  • Securing SIP (TLS and SRTP)
  • Other Cool Features

Continue reading…

Linux — HP Proliant SNMP Agent setup

I wanted to put together a quick post on configuring the hp-snmp-agent and hp-health agents on HP ProLiant servers using Linux. I stumbled across the need for this while working on a project to implement Icinga to monitor server hardware via SNMP.

First things first, check that you are running a compatible HP ProLiant G series. The current stable release of both hp-snmp-agent and hp-helath only work with G5+. This is important to keep in mind because I ran into this issue when trying to install both agents on a G4 Proliant. The dpkg install would fail because it cannot start the hp-health agent under a G4 Proliant. I am installing the agents ontop of Debian 7.

Let’s download the packages, check http://downloads.linux.hp.com/SDR/repo/mcp/debian/pool/non-free/ for latest versions

cd /root 
mkdir hp-agents 
cd hp-agents 
wget http://downloads.linux.hp.com/SDR/repo/mcp/debian/pool/non-free/hp-health_10.0.0.1.3-4._amd64.deb 
wget http://downloads.linux.hp.com/SDR/repo/mcp/debian/pool/non-free/hp-snmp-agents_10.0.0.1.23-21._amd64.deb

You will need snmp, snmpd, and some other library files before install the packages.

apt-get install snmpd snmp lib32gcc1 libc6-i386 libsnmp30

Now install the two(2) agents. Start with hp-health first, then install hp-snmp-agent

dpkg -i hp-health*.deb 
dpkg -i hp-snmp-agents*.deb

Continue reading…

CiscoASA — AnyConnect SSL VPN Setup

As promised here is my article on how to setup a SSL remote VPN, an alternative to IPSec Remote VPN from this article. What’s great is the steps to setup an SSL remote VPN service are very similar to IPSec remote VPN!! So let’s get started.

As with IPSec remote VPN we will need similar design considerations for SSL remote VPN.

  • First, a subnet is required for client’s to be put on when successfully authenticated and authorized via the SSL remote VPN. This can be the same subnet as one already existing on your network or a separate one with a firewall in-between The later being best in practice and security.
  • Secondly, deciding on split-tunneling vs all-tunneling. The difference being on the client would you like all traffic to be forced across the tunnel or allow clients to communicate with both their local network and the networks on the otherside of the VPN. For best practice and security, all-tunneling is recommended.
  • Third, Access Lists and tunneled networks. Here we will decided what SSL remote VPN users will have have access to in our other networks. We will also, in the case of split-tunneling, create an access-list of what networks to tunnel for the Remote VPN user.
  • Fourth, provisioning standard network services for VPN user’s. Remote VPN user’s will need a default gateway, DNS servers, domain suffix, an address pool, proxy settings, etc.

Continue reading…

Cisco ASA — Easy Remote Client VPN Solution

I’ve posted an article on Client VPN setup using OpenVPN and I noticed I didn’t have one regarding Cisco ASA. A Cisco ASA being a very common Security Appliance used by small and large companies. This article will cover how to setup a standard remote client VPN utilizing IPsec as the crypto carrier. Cisco also has their own proprietary remote client VPN solution called AnyConnect. I will be posting an article after this one on how to set an AnyConnect solution up and include what the differences are between it and the standard IPsec remote client VPN contained in this article.

A remote client VPN is something very common in workplace now-a-days. It allows users to appear as if they are on the company’s internal network over an insecure medium(e.g. Internet, untrused Network, etc). It does so by using IPsec. IPsec is a tried and true Layer 3 securing technique that requires both parties involved to mutually authenticate each other before passing traffic.

A few things to keep in mind regarding remote client VPNs.

  • First, a subnet is required for client’s to be put on when successfully authenticated and authorized via the remote client VPN. This can be the same subnet as one already existing on your network or a separate one with a firewall in-between The later being best in practice and security.
  • Secondly, deciding on split-tunneling vs all-tunneling. The difference being on the client would you like all traffic to be forced across the tunnel or allow clients to communicate with both their local network and the networks on the otherside of the VPN. For best practice and security, all-tunneling is recommended.
  • Third, Access Lists and tunneled networks. Here we will decided what Remote VPN users will have access to other networks. We will also, in the case of split-tunneling, create an access-list of what networks to tunnel for the Remote VPN user.
  • Fourth, provisioning standard network services for VPN user’s. Remote VPN user’s will need a default gateway, DNS servers, domain suffix, an address pool, proxy settings, etc.

Continue reading…