Known is a Drop; Unknown is an Ocean: Cisco/Security

In this case we went with a SSL Certificate from GoDaddy.com because of price. The problem arose from the fact that the CSR (Certificate Signing Request) wasn’t generated from the Cisco VPN Concentrator itself. However, in retrospect, this was probably the only way to do it properly because there doesn’t seem to be a way to export the private key from the Cisco. This would have posed a problem in our case because we purchased a Wildcard SSL Certificate (*.domain.tld) that can be installed on unlimited servers in our domain, and secure any host server within our domain.

Required Resources: The following software was used to complete this project:

Resolution: These are the general steps necessary to set this up, and should work for most major Certificate Authorities (CAs):

Certificate Signing Request (CSR) generated on IIS Server. The CSR contains the Requested Public Key. The Private Key is left on the server.
CSR submitted to Certificate Authority (CA). They generate the SSL Certificate, and provide the Cert, along with their CA Cert and Intermediate Cert.
The CA Cert and Intermediate Cert are installed as CA Certs on the Cisco VPN Concentrator 3000.
Here’s the tricky part. The Cisco Concentrator requires the SSL Cert to be in PKCS8 format, and contain the Private key and SSL Cert.
I exported the Private/Public Key pair from the IIS Server, using the Windows Certificate Export Wizard; selecting to export both keys, and saving withOUT ‘high security’, and a password.
This generates an encrypted PKCS12 file.
At the unix command line (I used CYGWIN), I used OpenSSL (thanks to this site for OpenSSL basics)to first convert the PKCS12 file to standard format:

openssl pkcs12 -in CERTIFICATE_NAME.pfx -out CERTIFICATE_NAME.pem
The command prompts for the password used to export the key file from the IIS server. Then asks for a new password.
I then converted the standard file to PKCS8 format for the Cisco:

openssl pkcs8 -in CERTIFICATE_NAME.pem -topk8 -out CERTIFICATE_NAME.pk8
Again the command prompts for the ‘New Password’ from the last export, and asks again for a newer password.
Back on the Cisco Concentrator, I import a SSL certificate manually with Private Key for the Private Interface. Use the ‘copy and paste’ method.
One other issue we have is that our CA uses an ‘Intermediate Certificate’. Thus creating a ‘chain’ of 3 trusted certificates: Ours, the ‘intermediate’ CA and the ‘root’ CA.
In a text editor open both the CERTIFICATE_NAME.pk8 Private Key file you generated, along with the CERTIFICATE_NAME.cer SSL Certificate file provided to you by the CA.
Copy and paste the Private key into the text box on the concentrator.
Then immediately after, copy and paste the SSL Certifcate. Avoid any excess spaces, or blank lines.
Then copy and paste the Issuing certifacte after the SSL Certificate.
Finally copy and paste the Root Certificate at the end.
The whole thing should look something like this:

-----BEGIN ENCRYPTED PRIVATE KEY----- MIICiyuqweiSDuryiGquweryiDFuqweyGrqour 9bgt3ouiiDnmbweFmnriorGuweioruu8u= -----END ENCRYPTED PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIIEZkjasdlkDFajljkFyasdf8kGlyysfklysk asklfjsadkyy7DuklasyFdjfklyaGsdfjld= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIEQkjasdlkDFajljkFyasdf8kGlyysfklysk asklfjsadkyy7DuklasyFdjfklyaGsdfjld= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIC5jasdlkDFajljkFyasdf8kGlyysfklysk asklfjsadkyy7DuklasyFdjfklyaGsdfjld= -----END CERTIFICATE-----
Enter the same sequence of data again for the Public interface.

Unicast Reverse Path Forwarding is a small security feature

When configured on an interface, the router checks the incoming packet’s source address with its routing table. If the incoming packet’s source is reachable via the same interface it was received, the packet is allowed. URPF provides protection again spoofed packets with unverifiable source.

Though basically a single line command, URPF can be a little confusing when used with access-list feature if order of operation is not understood completely.

We’ll use this simple topology to demonstrate URFP

R1 and R2 are connected through frame-relay and an Ethernet connection.

We test our basic connectivity.

R2#ping 150.1.12.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.12.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/93/192 ms

R1#ping 150.1.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/45/84 ms

R1#ping 150.1.21.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.21.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/54/100 ms

All right we have reachability on both Ethernet and frame relay interfaces.

In order to demonstrate URPF we use two static routes on R1 and R2.
R1 uses frame-relay to reach R2’s loop back (2.2.2.2/24)

and

R2 user Ethernet to reach R1’s Loopback (1.1.1.1/24)

R1(config)#ip route 2.2.2.0 255.255.255.0 150.1.12.2
R2(config)#ip route 1.1.1.0 255.255.255.0 150.1.21.1

Without URPF, we should be able to ping R2’s loopback from R1’s loopback.

R1#ping 2.2.2.2 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/48/80 ms

Now we enable URPF on frame-relay interface on R2.
Now when the incoming packet arrives at the frame interface, R2 checks the source address (1.1.1.1/24) in its routing table.
Since the interface used to reach this address is Ethernet0/0 , URPF checks fail and ping is not successful.

!
interface S1/0
ip address 150.1.12.2 255.255.255.0
ip verify unicast reverse-path

R1#ping 2.2.2.2 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
…..
Success rate is 0 percent (0/5)

All right!
This was the most simple part.
Now we use URPF with an access-list.

Understanding URPF Order of Operation:

Here we have to understand the order of operations.

1) When packet arrives at the interface, URPF check is done. If the check is successful, the packet is transmitted, and ACL doesn’t come into play
2) If the check is failed, ACL is consulted. Traffic is allowed or denied based on ACL entries.
3) The thing to understand here is that an ACL with deny any any will not mean that all traffic is denied. It won’t come into play unless the URPF check is failed. If URPF check is successful all traffic is allowed. If it is failed then ACL is checked an traffic is allowed or denied based on the ACL.

R2:
!
interface Serial1/0
ip address 150.1.12.2 255.255.255.
ip verify unicast reverse-path 101

access-list 101 permit tcp any any
access-list 101 deny ip any any log-input

Here we are allowing the TCP traffic and denying all other traffic in ACL.
It means that a telnet sourced from the LoopBack 0 of R1 to LoopBack 0 of R2 will be successful, but all other traffic will be denied.

From R1:

R1#telnet 2.2.2.2 /source-interface loopback 0
Trying 2.2.2.2 … Open

Password required, but none set

[Connection to 2.2.2.2 closed by foreign host]

Success rate is 0 percent (0/5)
R1#ping 2.2.2.2 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
…..
Success rate is 0 percent (0/5)

Below is the log generated by ACL.

*Mar 1 00:16:40.171: %SEC-6-IPACCESSLOGDP: list 101 denied icmp 1.1.1.1 (Serial1/0 ) -> 2.2.2.2 (0/0),

Now lets ping the loopback with source frame-relay interface.

R1#ping 2.2.2.2 source S1/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 150.1.12.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/48/80 ms

As you can see that though ACL is denying all ICMP traffic our ping is successful.
For the simple reason that ACL won’t be checked until URPF check is failed. And in the above case, it’s successful.

Now lets change the ACL.
Now our intention is to allow HTTP traffic between the loopbacks as well as ICMP traffic and deny all other traffic.

R2:
access-list 101 permit tcp any any eq www
access-list 101 permit icmp any any
access-list 101 deny ip any any log-input

We’ll be able to ping or telnet at port 80 but regular telnet will fail

R1#ping 2.2.2.2 source lo 0

R1#telnet 2.2.2.2 /source-interface loopback 0
Trying 2.2.2.2 …
% Connection timed out; remote host not responding

R2: (:Log)
*Mar 1 00:20:18.895: %SEC-6-IPACCESSLOGP: list 101 denied tcp 1.1.1.1(35617) (S
erial1/0 ) -> 2.2.2.2(23), 1 packet

Well thats about it for URPF.
In lab exam if the feature shows up, be careful, as it can break connectivity if routers have asymmetrical routing.
Asymmetrical routing is not a problem in LAB generally as long as we have connectivity, but with URPF enabled, asymmetrical routing will break connectivity.
In that case,we can either tune unicast routing table or use the access-list with URPF to allow for connectivity.

Known is a Drop; Unknown is an Ocean

Wednesday, May 18, 2011

Setup SSL Certificate on Cisco 3000 Series VPN Concentrator

Tuesday, March 22, 2011

Unicast Reverse Path Forwarding-Tutorial