Monday 19 August 2013

setting up a VPN to an AWS instance

When you set up you instance in AWS and you want to configure a VPN to connect to it. A configuration file can be generated in the AWS console. You'll get something like the following

! Amazon Web Services
! Virtual Private Cloud
!
! AWS utilizes unique identifiers to manipulate the configuration of 
! a VPN Connection. Each VPN Connection is assigned an identifier and is 
! associated with two other identifiers, namely the 
! Customer Gateway Identifier and Virtual Private Gateway Identifier.
!
! Your VPN Connection ID                  : 
! Your Virtual Private Gateway ID         : 
! Your Customer Gateway ID                : 
!
!
! This configuration consists of two tunnels. Both tunnels must be 
! configured on your Customer Gateway. Only a single tunnel will be up at a 
! time to the VGW.
! 
! You may need to populate these values throughout the config based on your setup:
!  - External interface of the ASA
!  - Inbound ACL on the external interface
!  - Outside crypto map
!  and  - VPC address range
!  and  - Local subnet address range
!  - Target address that is part of acl-amzn to run SLA monitoring

! --------------------------------------------------------------------------------
! IPSec Tunnels
! --------------------------------------------------------------------------------
! #1: Internet Key Exchange (IKE) Configuration
!
! A policy is established for the supported ISAKMP encryption, 
! authentication, Diffie-Hellman, lifetime, and key parameters.
!
! Note that there are a global list of ISAKMP policies, each identified by 
! sequence number. This policy is defined as #201, which may conflict with
! an existing policy using the same number. If so, we recommend changing 
! the sequence number to avoid conflicts.
!
crypto isakmp identity address 
crypto isakmp enable 
crypto isakmp policy 201
  encryption aes
  authentication pre-share
  group 2
  lifetime 28800
  hash sha
exit
!
! The tunnel group sets the Pre Shared Key used to authenticate the 
! tunnel endpoints.
!
tunnel-group XX.XXX.XXX.40 type ipsec-l2l
tunnel-group XX.XXX.XXX.40 ipsec-attributes
   pre-shared-key somepassword
!
! This option enables IPSec Dead Peer Detection, which causes periodic
! messages to be sent to ensure a Security Association remains operational.
!
   isakmp keepalive threshold 10 retry 3
exit
!
tunnel-group XX.XXX.XXX.44 type ipsec-l2l
tunnel-group XX.XXX.XXX.44 ipsec-attributes
   pre-shared-key anotherpassword
!
! This option enables IPSec Dead Peer Detection, which causes periodic
! messages to be sent to ensure a Security Association remains operational.
!
   isakmp keepalive threshold 10 retry 3
exit

! --------------------------------------------------------------------------------
! #2: Access List Configuration
!
! Access lists are configured to permit creation of tunnels and to send applicable traffic over them.
! This policy may need to be applied to an inbound ACL on the outside interface that is used to manage control-plane traffic. 
! This is to allow VPN traffic into the device from the Amazon endpoints.
!
access-list  extended permit ip host XX.XX.XX.40 host my.fw.pub.ip
access-list  extended permit ip host XX.XX.XX.44 host my.fw.pub.ip
! The following access list named acl-amzn specifies all traffic that needs to be routed to the VPC. Traffic will
! be encrypted and transmitted through the tunnel to the VPC. Association with the IPSec security association
! is done through the "crypto map" command.
!
! This access list should contain a static route corresponding to your VPC CIDR and allow traffic from any subnet.
! If you do not wish to use the "any" source, you must use a single access-list entry for accessing the VPC range.
! If you specify more than one entry for this ACL without using "any" as the source, the VPN will function erratically.
! See section #4 regarding how to restrict the traffic going over the tunnel
!
!
access-list acl-amzn extended permit ip any  

!---------------------------------------------------------------------------------
! #3: IPSec Configuration
!
! The IPSec transform set defines the encryption, authentication, and IPSec
! mode parameters.
!
crypto ipsec transform-set transform-amzn esp-aes esp-sha-hmac
! The crypto map references the IPSec transform set and further defines
! the Diffie-Hellman group and security association lifetime. The mapping is created
! as #1, which may conflict with an existing crypto map using the same
! number. If so, we recommend changing the mapping number to avoid conflicts.
!
crypto map  1 match address acl-amzn
crypto map  1 set pfs group2
crypto map  1 set peer  XX.XXX.XXX.40 XX.XXX.XXX.44
crypto map  1 set transform-set transform-amzn
!
! Only set this if you do not already have an outside crypto map, and it is not applied:
!
crypto map  interface 
!
! Additional parameters of the IPSec configuration are set here. Note that
! these parameters are global and therefore impact other IPSec
! associations.
! Set security association lifetime until it is renegotiated.
crypto ipsec security-association lifetime seconds 3600
!
! This option instructs the firewall to clear the "Don't Fragment"
! bit from packets that carry this bit and yet must be fragmented, enabling
! them to be fragmented.
!
crypto ipsec df-bit clear-df 
!
! This configures the gateway's window for accepting out of order
! IPSec packets. A larger window can be helpful if too many packets
! are dropped due to reordering while in transit between gateways.
!
crypto ipsec security-association replay window-size 128
!
! This option instructs the firewall to fragment the unencrypted packets
! (prior to encryption).
!
crypto ipsec fragmentation before-encryption 
!
! This option causes the firewall to reduce the Maximum Segment Size of
! TCP packets to prevent packet fragmentation.
sysopt connection tcpmss 1387
!
! In order to keep the tunnel in an active state, the ASA needs to send traffic to the subnet 
! defined in acl-amzn. SLA monitoring can be configured to send pings to a destination in the subnet and
! keep the tunnel active. A possible destination for the ping is the VPC Gateway IP, which is the 
! first IP address in one of your subnets.
! For example: a VPC with a CIDR range of 192.168.50.0/24 will have a gateway: 192.168.50.1.
! 
! The monitor is created as #1, which may conflict with an existing monitor using the same
! number. If so, we recommend changing the sequence number to avoid conflicts.
!
sla monitor 1
   type echo protocol ipIcmpEcho  interface 
   frequency 5
exit
sla monitor schedule 1 life forever start-time now
!
! The firewall must allow icmp packets to use "sla monitor" 
icmp permit any 

!---------------------------------------------------------------------------------------
! #4: VPN Filter
! The VPN Filter will restrict traffic that is permitted through the tunnels. By default all traffic is denied.
! The first entry provides an example to include traffic between your VPC Address space and your office.
! You may need to run 'clear crypto isakmp sa', in order for the filter to take effect.
!
! access-list amzn-filter extended permit ip    
access-list amzn-filter extended deny ip any any
group-policy filter internal
group-policy filter attributes
vpn-filter value amzn-filter
tunnel-group XX.XXX.XXX.40 general-attributes
default-group-policy filter
exit
tunnel-group XX.XXX.XXX.44 general-attributes
default-group-policy filter
exit

!---------------------------------------------------------------------------------------
! #5: NAT Exemption
! If you are performing NAT on the ASA you will have to add a nat exemption rule.
! This varies depending on how NAT is set up.  It should be configured along the lines of:
! object network obj-SrcNet
!   subnet 0.0.0.0 0.0.0.0
! object network obj-amzn
!   subnet  
! nat (inside,outside) 1 source static obj-SrcNet obj-SrcNet destination static obj-amzn obj-amzn
! If using version 8.2 or older, the entry would need to look something like this:
! nat (inside) 0 access-list acl-amzn
! Or, the same rule in acl-amzn should be included in an existing no nat ACL.
!
!---------------------------------------------------------------------------------------
!  Additional Notes and Questions
!  - Amazon Virtual Private Cloud Getting Started Guide: 
!       http://docs.amazonwebservices.com/AmazonVPC/latest/GettingStartedGuide
!  - Amazon Virtual Private Cloud Network Administrator Guide: 
!       http://docs.amazonwebservices.com/AmazonVPC/latest/NetworkAdminGuide
!  - Troubleshooting Cisco ASA Customer Gateway Connectivity:
!       http://docs.amazonwebservices.com/AmazonVPC/latest/NetworkAdminGuide/Cisco_ASA_Troubleshooting.html
!  - XSL Version: 2009-07-15-1119716

If you have a brand new firewall you could *probably* copy paste this stuff in and it would work, but I still wouldn't advise it. Most users have a lot of config on their firewalls already. Also there are some global settings in there that you might not be comfortable with changing if you have VPNs to other customers for example.

The config generated by AWS didn't match up exactly to the 8.6 code running on my ASA.

Template from amazon
My config
Already present
crypto isakmp identity address
crypto isakmp identity address
Yes
crypto isakmp enable <outside_interface>
crypto ikev1 enable OUTSIDE
Yes
crypto isakmp policy 201
crypto ikev1 policy 201
No, needed to be added. Keep in mind on other firewalls a policy 201 may exist already and you’ll have to use a different number
tunnel-group xx.xx.xx.xx type ipsec-l2l

No, needs to be copied exactly from the template
access-list <outside_access_in> extended permit ip host XX.XXX.XX.44 host my.fw.pub.ip

No, needs to be added. You need to determine what is the name of the ACL applied to the outside interface.
access-list acl-amzn extended permit ip any <vpc_subnet> <vpc_subnet_mask>
access-list CUSTOMER_AWS extended permit ip any int.net.ip.add 255.255.0.0
No, needs to be added. You should use a descriptive name for the ACL
crypto ipsec transform-set transform-amzn esp-aes esp-sha-hmac
crypto ipsec ikev1 transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac
Yes, there was already a transform set for aes 128 and sha1
crypto map <amzn_vpn_map> 1
crypto map S2S 190
No, needs to be added, you need to make sure the map number is not in use. Make sure to update the ACL name and the transform set.
crypto map <amzn_vpn_map> interface <outside_interface>
crypto map S2S interface OUTSIDE
Yes
Additional global settings

No, going to leave these out for now. If we have issues with the VPNs we can test.
VPN Filter

No, needs to be added, ACL, networks and Filter names should be updated.
NAT exemption

No, needed to add an object for the customer private network


Config applied to the ASA firewall in the end, you can see I left out a lot of the global settings. So far the VPNs are working fine:

crypto ikev1 policy 201
authentication pre-share
encryption aes
hash sha
group 2
lifetime 28800

tunnel-group XX.XXX.XX.44 type ipsec-l2l
tunnel-group XX.XXX.XX.44 ipsec-attributes
ikev1 pre-shared-key *****
isakmp keepalive threshold 10 retry 3

tunnel-group XX.XXX.XX.40 type ipsec-l2l
tunnel-group XX.XXX.XX.40 ipsec-attributes
ikev1 pre-shared-key *****
isakmp keepalive threshold 10 retry 3
  
access-list outside_in extended permit ip host XX.XXX.XX.44 host my.fw.pub.ip
access-list outside_in extended permit ip host XX.XXX.XX.40 host my.fw.pub.ip

access-list CUSTOMER_AWS extended permit ip any cust.int.net.id 255.255.0.0

crypto map S2S 190 match address CUSTOMER_AWS
crypto map S2S 190 set pfs group2
crypto map S2S 190 set peer  XX.XXX.XX.44 XX.XXX.XX..40
crypto map S2S 190 set transform-set ESP-AES-128-SHA
crypto map S2S 190 set security-association lifetime seconds 3600
crypto map S2S 190 set security-association lifetime kilobytes 4608000

access-list CUSTOMER_AWS_VPN_FILTER_ACL extended permit ip cust.int.net.id 255.255.0.0 192.168.1.0 255.255.255.0
access-list CUSTOMER_AWS_VPN_FILTER_ACL extended deny ip any any
group-policy CUSTOMER_AWS_VPN_FILTER internal
group-policy CUSTOMER_AWS_VPN_FILTER attributes
vpn-filter value CUSTOMER_AWS_VPN_FILTER_ACL
tunnel-group XX.XXX.XX.44 general-attributes
default-group-policy CUSTOMER_AWS_VPN_FILTER
exit
tunnel-group XX.XXX.XX.40 general-attributes
default-group-policy CUSTOMER_AWS_VPN_FILTER

object network obj-cust.int.net.id
subnet cust.int.net.id 255.255.0.0

nat (inside,outside) 1 source static obj-192.168.1.0 obj-192.168.1.0 destination static obj-cust.int.net.id obj-cust.int.net.idnation static obj-cust.int.net.id obj-cust.int.net.id

Thursday 15 August 2013

Tip on using packet tracer on Cisco ASA

I use the packet tracer tool quite often on ASA's. A Cisco engineer told me its better to always do the traces from the inside out, because traffic coming from the VPN is encrypted and we cannot inject encrypted traffic. He also said its a good idea to run it twice just incase the VPN isn't up already.

packet-tracer input INSIDE tcp 192.168.10.10 22 172.30.10.10 4444 detailed

instead of

packet-tracer input OUTSIDE tcp 172.30.10.10 4444 192.168.10.10 22 detailed

When we see the follow at the end of our trace

Type: VPN
Subtype: encrypt
Result: ALLOW

We know the data was encrypted and sent over the VPN

I've also seen
Phase: 7
Type: VPN
Subtype: encrypt
Result: DROP

Everything looked good on my end. The other need needed to update the proxy ID's.

Email Header Analyzer

http://www.mxtoolbox.com

Great website for testing email stuff

Allowing external access to a webserver on the usual ports on Cisco ASA

Had to restrict access to a web app, figured it would be useful to leave this here

Setup the object 

object network obj-172.20.50.50
 host 172.20.50.50

Setup the static NAT

object network obj-172.20.50.50
 nat (INSIDE,OUTSIDE) static 200.100.200.300

Setup the group of hosts who are allowed access (you can use any if you want the internet to have access but I want to restrict)

object-group network MYWEBAPP_HOSTS_ALLOWED_IN
 network-object host 80.70.60.50
 network-object host 90.100.200.50
 network-object host 100.123.123.123

Set up the group of ports you want to allow access

object-group service PORTS_80_AND_443 tcp-udp
 port-object eq 80
 port-object eq 443

Add an entry to the outside access-list
access-list OUTSIDE_IN extended permit tcp object-group MYWEBAPP_HOSTS_ALLOWED_IN 172.20.50.50 object-group PORTS_80_AND_443


Monday 12 August 2013

can't get to servers with a static NAT from internal servers in other DMZ's

This was the NAT method I was using:
nat (INSIDE,OUTSIDE) source static obj-172.20.100.140 obj-172.20.100.140 destination static OBJ-200.100.100.200 OBJ-200.100.100.200 no-proxy-arp route-lookup

The above has worked fine for me before in many situations but I had an issue that I couldn't connect to servers with a static NAT because the firewall was trying to get to the Public IP.

Had to change to this NAT method

Make sure you have your object is set up

object network obj-172.20.100.140
 host 172.20.100.140

This does the static NAT
object network obj-172.20.100.140
 nat (INSIDE,OUTSIDE) static 200.100.100.200

This NAT is processed at the right time so internal servers can get to the server but it still has it's static NAT.




Thursday 8 August 2013

tracking what servers are using port 25 with linux CLI tools

There was an issue with an unknown server sending out emails and getting the public IPs blacklisted, one of my colleagues came up with this line to find what that server was by searching the syslog.

grep 'Built outbound TCP connection' my-asa-log.log | grep '/25' | grep -v 'INSIDE:192.160.10.50' | awk -F " " '{print $15}' | awk -F "/" '{print $1} | sort | uniq -c


grep 'Built outbound TCP connection' my-asa-log.log
search for outbound connections in the ASA syslog file

grep '/25'
Search for connections to port 25

grep -v 'INSIDE:192.160.10.50'
Remove entires for 192.160.10.50 (the real email server)

awk -F " " '{print $15}'
Print column 15 which was

awk -F "/" '{print $1}'
I think this was the date

sort
sorts the data alpha numeric

uniq -c
Only shows one instance of an IP address and shows the count of how many times it appeared