Encrypting traffic with IPsec protected GRE tunnel

-

Let's take a look at some options available to us when securing traffic that is transmitted over the Internet. For the sake of a scenario to work with lets consider that site A is an existing site with a 3rd party network we must integrate with, and site B is a newly commissioned site that now needs to receive traffic.

The deployment initially consists of two Cisco ASA 5505X's, each with a connection to a public Internet connection. A VPN is configured between these two devices to allow secure transmission of traffic from the third party network over the Internet to the storage server. 

Worth mentioning is the basic configuration of a Cisco ASA. Out of the box it will require configuration for an 'Inside' and 'Outside' interface, as well as SSH for remote management: 

## Cisco ASA interface configuration:
 
interface GigabitEthernet1/1
 nameif outside
 security-level 0
 ip address (publicIP) 255.255.255.252

interface GigabitEthernet1/3
 nameif inside
 security-level 100
 ip address 192.168.2.2 255.255.255.252
 
 mtu outside 1500
 mtu inside 1500 
 
## Cisco ASA SSH configuration: 
## The 'ssh 0.0.0.0 0.0.0.0 line' can be made more secure by listing
## a specific IP address that is allowed to use SSH for management. 


aaa authentication ssh console LOCAL


ssh 0.0.0.0 0.0.0.0 outside
ssh timeout 5
ssh version 2


username (name here) password (password here) encrypted 







Cisco ASA's are not too dissimilar in their configuration of VPN tunnels to a Cisco router, but they are just different enough to cause headaches. Let's take a quick look a Cisco ASA VPN template (lines starting with "##" are comments):




## Cisco ASA VPN lan to lan configuration template.


## First, configure the phase 1 (IKE) tunnel between the two devices.


## Settings must match on both sides. 


 


 crypto ikev1 enable outside
 crypto ikev1 policy 1
 authentication pre-share
 encryption aes-256
 hash sha-256
 group 5
 lifetime 28800

 tunnel-group (peers public IP) type ipsec-l2l
 tunnel-group (peers public IP) ipsec-attributes
 ikev1 pre-shared-key (pre-share key)


 


## Phase 2 configuration - IPsec tunnel. 


## The transform-set defines the parameters for the IPsec tunnel. 


## The access-list identifies 'interesting' traffic.


 


 crypto ipsec ikev1 transform-set (setname) esp-aes esp-sha-hmac

 access-list (vpn accesslist name) extended permit ip (internal lan of ASA) 255.255.255.0 (peer public IP) 255.255.255.255
 access-list (vpn accesslist name) extended permit ip (public IP of ASA) 255.255.255.255 (peers internal lan) 255.255.255.0 


 


## Next, bind it all together with crypto map statements! 


## The configuration for PFS is included here for the sake of being complete.


 


  crypto map MAP 1 match address (vpn accesslist name)
  crypto map MAP 1 set peer (peers public IP) 
  crypto map MAP 1 set ikev1 transform-set (setname)
  crypto map MAP 1 set pfs group5   ## this line is completely optional. if it's being used, it needs to be used on both sides of the tunnel.
  crypto map MAP interface outside

## Cisco ASA's must always be NAT'ing traffic. Always.


## This poses a problem as NAT'ing traffic is not what we want to achieve here, 


## We want to encapsulate it in ESP instead. The solution is the following:


 


 object network (object network name1)
 subnet (internal lan of ASA) 255.255.255.0

 object network (object network name2)
 subnet (peers internal lan) 255.255.255.0

 nat (inside,any) source static (object network name1) (object network name1) destination static (object network name2) (object network name2) no-proxy-arp


 ## IP routing configuration.

 route outside (peers internal lan) 255.255.255.0 (peers external IP)



It's not as scary as it looks - really! 







After completing the initial deployment we discover that the 3rd party network is sending Multicast traffic as opposed to Unicast traffic. Multicast traffic is not routed over the Internet so the answer here is to encapsulate the traffic in a GRE tunnel, however, Cisco ASA's do not support termination of GRE tunnels. 



The answer to this problem is to deploy two Cisco 800 series routers, one alongside each ASA. The Cisco routers will be configured to handle multicast-routing and the GRE tunnel while the ASA's handle the VPN.



Looking at one of the Cisco routers now:




## First, enable multicast-routing




ip multicast-routing 


 


## Setup some interfaces on the Router


 


interface Vlan1
 description TO SERVER
 ip address 172.16.1.1 255.255.255.0
 ip pim sparse-mode

interface Vlan2
 description TO ASA
 ip address 192.168.2.1 255.255.255.252
 ip pim sparse-mode 


 


## Now set up the GRE tunnel


## The IP address on the tunnel can be anything you like. 


## The destination address is the remote network, in this case 192.168.1.1.


 


 interface Tunnel0
 ip address 192.168.3.2 255.255.255.252 
 ip pim sparse-mode
 tunnel source Vlan2
 tunnel destination 192.168.1.1 


 


## IP routing and IP 'multicast route' commands.


 


ip mroute 192.168.3.1 255.255.255.255 Tunnel0
ip mroute 172.24.17.2 255.255.255.255 Tunnel0
ip mroute 172.24.17.0 255.255.255.0 Tunnel0

ip route 172.24.17.0 255.255.255.0 192.168.3.1 


ip route 0.0.0.0 0.0.0.0 192.168.2.2 







Worth noting is that the size of each packet is well beyond 1500 bytes. With all the additional packet headers and encryption added by the GRE and VPN tunnels, packet fragmentation is now a problem. I'll explore this problem in much more depth later as it really deserves a post of its own.









































Comments











Post a Comment























Popular posts from this blog









Exploiting OpenSSH 4.7 / OpenSSL 0.9.8 (Metasploitable 2) 






-














Image







  Metasploitable 2 is a deliberately vulnerable machine designed by Rapid 7, the company behind the immensely powerful and popular Metasploit Project. The machine is intended to be used for general security training and target practice; a perfect way to spend a lazy Sunday!  The focus for this particular post will be the OpenSSH 4.7 protocol used by the vulnerable machine. This version of OpenSSH is several years old now, but the lessons learned here are still transferable to other services and newer versions. Before diving into the exploit it is necessary to understand the protocol being attacked and why it was vulnerable in the first place.          OpenSSH is the freely available, open-source version of the SSH protocol. SSH itself is a cryptographic network protocol used to connect with network services securely over an un-trusted network. In plain English this means SSH is a secure way to login to servers and embedded devices that support the SSH protocol. While SSH has other uses...








Read more










Reverse engineering a simple C program part 1: Strings, ltrace, hexdump






-














Image







Reverse engineering is something I find quite interesting, and a topic I am endeavoring to spend more time studying. There's nothing better than hands on practice, so lets take a look at a very simple 'license check' program written in C.    Here's the code:            This program will simply check for user input and then compare that input to a stored string. If the user input matches the string "ABCD-Z34K-42-OK" than the program will print "License confirmed" to the user. If the string does not match than the program will print "License incorrect" to the user. If no input is detected at all than the program simply prints "Usage: <key>" and exits.   When this program is compiled none of the source code will be available. The process of compiling will result in the source code being translated (it can also be thought of as transforming) into the machine language that is read by computer hardware. Our challenge is to compile...








Read more










501 million 'Pwned Passwords'






-














Image







 'Password strength' is a phrase that almost everyone will be familiar with to some degree. There is no universally agreed upon way to measure the strength of a password (this is somewhat part of a wider problem), which leads to every online service having a different system for gauging whether or not a given password is secure enough to be used. Normally, when discussing password security, the conversation will look something like this:   "Make all of your passwords at least 16 characters long and never use them more than once" .   I am going to take a different approach: I'm going to show you how not  to protect yourself online, how to crack weak passwords with little to no effort, and how to check whether a password is already compromised before you use it online. With any luck, you'll be a little wiser about password security by the end of this post.   To achieve all of this I'm going to use data from the recently released "Pwned Passwords" l...








Read more