Saturday, May 31, 2014

Cisco IOS-XE one time passwords

Cisco has a feature that allows for you to create a  user and password and to walk away and forget about it. Its called one-time password and is simple to deploy.

here's a dialup user that I will allow access into our vpn-concentrator. He/she has a one-time user account and after the 1st successful login, the account will be exterminated and deleted

The configuration;



And here we make one login  attempt and then  exit. The 2nd login attempt, will  not be honored.



NOTE :  Keep in mind that the username will stay in the cfg, until  that  person actually logon to the router. 

If the  device is rebooted, before the configuration is saved, the username name will re-appear.



Ken Felix
Network & Security Engineer
kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^
=(   -   - )=
         o
      /     \

Thursday, May 29, 2014

TCP normalization & tricks for cisco ASA

The cisco ASA  firewall has a few tricks that you can do for the normalizing of tcp data.

1st let's look at  some tcp-options.  These are defined by iana & available here.
http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-parameters-1

1st  What is tcp normalization?

Normalization,  aka "scrubbing",  ensure that tcp-session conform to the correct standards or expect parameters.  This could be something as simple with clamping the  tcp-MSS values or the removal of certain tcp options like Window Scaling or Selective ACKs, or  dropping  SYN, SYN-ACK packets that  have data.

In a few cases, we normalize tcp datagrams to combat bad programs or application that misbehave with certain type of tcp parameters. This intermin fix  is typically used until the application is corrected, or the OS is updated.

examples of normalizations usages


  • In the past, I've  worked in the DDoS sector, and we used tcp-mss to clamp maximum tcp-segments  before entering a GRE tunnel.
  • In the finanicial sector, we had mis-behavin applications that couldn't be correct in the tcp/ip-stack, so we use a mix of tcp-normalization methods to remove certain options from the tcp SYN datagram    ( i.e SACK,WSCALE,TimeStp,etc....).  We ended up disable "SACK" for just one of the many services hosted on the server platform, without modifying the rest of the services.
  • Another example, we had a upstream external IPS that freaked out on certain tcp traffic. This particular IPS was aggressive and we really couldn't write exemptions rules to cover all possibilities. So we instead normalize the traffic b4 reaching the IPS sensor.


On the cisco ASA , you will have to define a tcp-map and reference  a class-map for the traffic we want to  normalized.

This usually requires the following;
  •  acl
  •  class-map 
  •  tcp-map
  •  policy-map

Here's a few samples with tcpdump screenshot of the cleanup tcp-datagram

( the dropping of TCP options SACKS using a defined ACL )







A TCP dump of my SYN and SYN-ACK shows;



( the dropping of the TCP options "WSCALE" using a defined ACL )




Tcpdump shows that the  WSCALEing option is now gone!


More Examples


 ( the dropping of the multiple TCP options using a defined ACL )

T
 TCpdump shows the SYN & tcp-option are now gone!



NOTE: if you  don't need  specific src/dst  matching ACL you can use a port-match  to accomplish the same. The ACL approach allows for fine control of the src/dst

NOTE:  The dropping SYN or SYN/ACK that  has data , is  very simple &  a tcp conversation should  never  start with data to begin with.



Ken Felix
Network & Security Engineer
kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^
=(   -   - )=
         o
      /     \

Monday, May 26, 2014

Reverse Route Injection via a Cisco ASA vpn and OSPF

In this post, we will look at  route-injection for ipsec-vpn and the cisco ASA.

The cisco ASA has the means  for route installation upon establishments of a active vpn-tunnel. This is accomplished via the set reverse-route command within our crypto map. This is similar to the cisco legacy vpn concentrator and the Reverse Route Injector.

1st let's look at our topology and the route table & then we will look at  the configurations and controls for route-injecting.

The Topology



ASA crypto map

crypto map EXTERNAL02_map0 10 match address VPN2FGTHQ
crypto map EXTERNAL02_map0 10 set peer 192.169.23.5
crypto map EXTERNAL02_map0 10 set ikev1 transform-set ESP-AES-128-SHA
crypto map EXTERNAL02_map0 10 set reverse-route   
#<-we add the route injection-command
crypto map EXTERNAL02_map0 interface EXTERNAL02



note: The  command set reverse-route will install the vpn remote-destination into the local route-table



Now in order to push this route into our DYNAMIC routing protocol  ( OSPF ), we will perform some redistribution and controls for this process.

1st  let's build a prefix-list matching only our remote vpn prefixes;

!
prefix-list myvpnroutes description USE THIS RT-map for controlling insertion of our vpn routes
prefix-list myvpnroutes seq 5 permit 192.168.254.0/24
!


Next, we will build a route-map that calls up our prefix-list. This route-map will be used  in our ospf process and for controlling routes that we populate into ospf.


!
route-map myvpn_learned_routes permit 10
 match ip address prefix-list myvpnroutes
 set metric 12000
 set metric-type type-1
!
route-map myvpn_learned_routes deny 100
!


and within our  ospf process;

router ospf 1
 router-id 10.200.21.254
 network 10.200.21.0 255.255.255.0 area 0
 log-adj-changes
 redistribute static subnets tag 700 route-map myvpn_learned_routes 
#---our-route-map
  default-information originate metric 1000 metric-type 1
!


Now within our routing domain, we will have the vpn injected route, we will check on our core-L3 switch;


The 192.168.254.0/24 prefix is now installed into  OSPF via the redistribution process on our  cisco ASA.

We can also check our ospf-database for confirmation;


 Ken Felix
 Freelance Network & Security Engineer
 kfelix -a--t- socpuppets ---d--o--t--- com

   ^      ^
=( *   * )=
       o 
      /  \

Sunday, May 25, 2014

Dialup Around the cloud with a Huawei usb-modem and Fortigate

In this blog posting, we will explore a simple dial backup solution based on a 3G  celluar provider usb-modem

In the olden days of the internet,  we used to called theses solutions a " dialup backup", or  " dial around the cloud"

These where commonly used when critical access was required or for dialing around a failure in the service-provider main delivery. They typically backed up the primary WAN path with a low-cost, affordable,  and a slower solution.

(e.g dial backup for any of the following )
  • frame-relay
  • x.25
  • lease-line
  • ADSL line

The ole school method, was to purchase a business 2wire phone-line or isdn-line. Now with  3/4G services commonly available, cheap, and easily obtainable, the Opportunities are much simpler and quicker.

1st the topology


So the components that are required;
  •  router/firewall
  •  existing WAN uplink device
  •  usb-external modem

In this case we are using a FWF60D for this example. The FWF60D fortigate appliance provides the direct lan clients wire and wireless access. The primary path would be our ADSL link , but we will also use the 3G modem as  a WAN link. Routes would be adjusted to be less preferred over the WAN modem link.


Now for the configuration and tip/tricks

1:

First you need a compatible  external usb-modem. Fortinet is always changing and adding new devices based on the software-release, but most huawei modems have a good track record for working.

note: Read the release notes from Fortinet before purchasing a modem. I will not list modems here, do some research is all that I'm telling you.


I'm using a E352 , the service  provider is Orange-GETESA. You need to execute the enabling of the modem from the cli

config sys modem
   set status enable
end


2:

You need to identify the model . You have a few methods for the execution of this. The diag sys modem command is the trick. I will show you 2 ways;

method one  ( issuing a "ati" command  diag sys modem  cmd ati   )



method two ( diag sys modem commands   diag sys modem  exeternal-modem  )


method three  ( looking at the WebGUI )

3:

Next, you will probably need to identify some service-provider specific. This will  be a YMMV & will depend on the  ServiceProvider  specifics (  example....... dialup#, APN,phone#, pin-lockout ,etc.... )

For the provider  Orange, I only need to provide a single dialup#. The card-sim in this case, does not use a PUK ( pin unlock code ) code or any type of pin  insertion before initialization.

note: If you have any PIN or PUK code requirements, make sure you confirm the numbers. You don't want to lockout the modem :)



Can't get any easier than that :)

4th

Since the modem is a interface, you will need a firewall policy. Make sure you apply the correct policy to allow traffic and sNAT.


Note: You can apply traffic-shaper to preference critical stuff like VoIP over this interface, the above fwpolicy is for my wireless clients to access the internet via the  3g UPLINK.

5th:

If this path is not to be used for the primary access, you might need to adjust the route preferences



So that's how you do a dialup around the cloud using a basic configuration , with a fortigate and huawei-modem. You can use this interface for VIP terminations, VPNs, or anything else as far as that goes.

Things to keep in mind;
  1. review if your modem is compatible and supported
  2. gather all dialup requirement from the provider
  3. keep in the back of your mind, that data usage charges could apply based on your service plan
  4. adjust route by increasing distance of the routes  available by this interface
  5. by using policy-based-routing you can throw some traffic down the slower path if required






add June 12 2014



Ken Felix
Consulting Engineer Network & Security  ( Cisco, Juniper, Fortinet )
kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^
=(   ~   ~ )=
         o
      /     \


Saturday, May 24, 2014

Source NAT based on destination for VPN topologies ( Lan2Lan connections cisco ASA )

In a hosted vendor business application scenario,  the needs for source-NAT ( SNAT ) might exist for VPN connections within the classic lan2lan vpn concept. This scenario might  create an ip_address management  issues if all customers are using rfc1918 address.  Overlapping rfc1918 blocks could cause a collision between customers address blocks.

1st lets look at a typical vendor hosted-business-server topology

Topology



The problem

Each client LAN network address needs to be unique. Clients that are using rfc1918 addressing , has no means to delegate and ensure unique address are being used between customers. So cust1 might be using the same 192.168.1.0/24 block as cust2 or cust3, and you have no control as to what the customer may or may not be using.

If the vendor grows his business-server  environment by adding more customers, this problem could be a nightmare to manage.

So how do we ensure that each customer who access the business servers domain, are using a unique address?

The Solution 

By source NAT'ing the client machines to a public address that he/she owns, we can ensure that all customers  are unique from the vendor's hosted business server perspective. In  a true remote business-server application farm that supports multiple customer, this is how they ensure uniqueness.


In this blog, I will demo a configuration that you can use just  for this & that's typically deployed within the cisco ASA firewall.  It would allow any one of the 3 above customer to use the same local lan subnet addressing, and all client's machines would be NAT'd to a public address that they own.

This address would  than be present to all connections to the business-server domain across the vpn-tunnel.

Cust & Vendors Details


Let's say Customer1 owns a public address of "1.0.0.1".  And their local lan is 192.168.1.0/24. So customer 1 will NAT his rfc1918 space behind the  "1.0.0.1" address and present this to the business servers located  at 192.168.254.0/24 for all connections establishment.

The Vendor firewall is located at 10.1.1.1 and  requires AES128/256, DHgrp2, no PFS. They are using a PSK of "cust1psk", and will allow the customer  full access to  the 192.168.254.0/24 block.


 Cust configuration  (  Cisco ASA ipsec type L2L vpn  )


 Tunnel-group



 Crypto Ikev1 policies





 

 The Encryption ACL


NOTE: This encryption ACL will encrypt the sNAT  global outside address across the encryption domain.

 Crypto-map & Transform-set




 
 NAT-control-SourceNAT

      (1st) objects
    
     (2nd) NAT  rules for SNAT based on the destination of  192.168.254.0/24


    
To summarize this SNAT scenario;




 Ken Felix
 Freelance Network & Security Engineer
 kfelix -a--t- socpuppets ---d--o--t--- com

   ^      ^
=( *   * )=
      o 
     /  \
 

Thursday, May 22, 2014

CCIE RS attempt

Will it's time for me to get serious at my next attempt. I'm going to Raleigh in NOV. I'm anxious and nervous due to their's new format in the lab.


http://www.cisco.com/web/learning/certifications/expert/ccie_rs/docs/ccieRS_examUpdates4-5.pdf

What I learned; 

  There's a section called diagnostic .What's involved I have no clue and cisco has very little posted about this section.

  T-shoot has been extended to give more time
 
  The lab is still a 8hr event (  5 1/2 for configuration )


I hope I pass this year.



Ken Felix
Network & Security Engineer
kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^
=(   <   > )=
         o
      /     \

HOWTO: ASR IOS-XE to Fortigate IKEv2 route-based VPN with VTI ( cisco )

In this blog we will look at a static VTI route-based vpn between a cisco ASR and fortigate appliance. This configuration is  the same as the earlier posting on the fortigate side.

The cisco device  has been reconfigured for a Static Virtual Tunnel Interface ( aka cisco routed-based  vpn )

1st the topology


Let's refresh our knowledge of the route-based vpn concept by looking at my earlier post.
http://socpuppet.blogspot.com/2014/05/howto-asr-ios-xe-to-fortigate-ikev2.html

The ASR has been configured with the correct IKEv2  policy, keyring, ipsec-profile and proposals for this vpn to be established. The configuration shown within this post, uses the  concept of a VTI interface and  makes use of a  static route ( aka route-based vpn  )

IKEv2 has been supported within the cisco IOS routers for some time, and actually earlier than the cisco ASA.

NOTE: IKE version2 has been well supported within  Juniper, PaloAlto  and a few other firewall vendors


Here's  the configurations and a few tips



====================   ASR  configuration =====================


We first have to cleanup & remove a few configuration parameters;
  •  remove the crypto map from interface
  •  delete the crypto-map ( not used in a VTI  scenario )
  •  delete the  ACL for encryption of the interesting traffic  ( not used in a VTI  scenario ) 
The new configuration encompass a few changes;
  •  we define a tunnel interface ( the actual VTI )
  •  we install a route to the destination network ( 192.168.254.0/24 ) using the tunnel interface ( the route-based function )
  •  build a ipsec-protection profile that we apply on the newly crafted tunnel

Okay let's get started. This will be quick and fun !

====================   ASR  configuration =====================
IKEv2



Crypto tranform-set

  ( no changes from earlier post )




Tunnel-creation

  A VTI must have a tunnel  will duh!







ipsec-profile



Static route ( aka route-based )

 

 NOTE:  A routed-based vpn needs  a route to the destination via static or some type of routing protocol


====================   FGT  configuration =====================

NOTHING CHANGES FROM THE EARLIER POST. It's  the exact same cfg.



DIAGNOSTIC comands used

cisco

show crypto ikev2 sa detail
show crypto ipsec sa
ping
show ip route
show int tunnel xxx



Fortigate

diag vpn ike gateway
diag vpn tunnel list
diag debug flow


IKEv2 SA cisco & fortigate




IPSEC-SAs cisco and fortigate



NOTICE: how  the SPIs matches for the 2 uni-directional IPSEC-SA

tunnel interface statistics







====================  keyPoints/takeaways  =====================


  • The VTI concept allows for more flexibility 
  • tunnels are used in the same concept and fashion like a /30 wan link
  • dynamic routing could be used across the tunnel interfaces
  • due to the VTI  is a virtual interface, we can apply interface specific ACL
  • due to the VTI  is a virtual interface, we can apply QoS Specific parameters
  • due to the VTI  is a virtual interface, we can use the ifIndex for SNMP monitoring
  • specific and unique ipsec profiles can be defined in a multiple VTI hub-spoke
  • the need for crypto-map or acl are eliminated
  • netflow could be exported for vpn tunnel specific traffic with much ease

Ken Felix
Consulting Engineer Network & Security  ( Cisco, Juniper, Fortinet )
kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^
=(   #   # )=
         o
      /     \


Wednesday, May 21, 2014

HOWTO: ASR IOS-XE to Fortigate IKEv2 route-based VPN

In  this blog we will look at a route-based ipsec vpn to a cisco router  running IOS-XE (  ASR1002 )  using the legacy crypto-map method . This vpn has been defined using IKEv2 , AES128.

1st the topology;



The ASR has been configured with the correct IKEv2  policy, keyring and proposals for this vpn to be established. The configuration shown here, is the basic  configuration required. YMMV

IKEv2 has been supported within the cisco IOS routers for some time, and actually earlier than the cisco ASA.

NOTE: IKE version2 has been well supported within  Juniper, PaloAlto  and a few other firewall vendors


Here's  the configurations and tips


====================   ASR  configuration =====================


IKEv2



note: enabling crypto logging for  log-messages


Crypto tranform  &  MAPs




note: don't forget to enable the  crypto map on the egress interface  via the config cmd

interface port 3
   crypto map myvpn 


ACL



note: this ACL defines the interesting traffic to encrypt. It should match  the src/dst-subnet of the fortigate exactly


====================   FGT  configuration =====================

The Fortigate side of things is no different than a IKEv1 config but we must toggle the version as IKEv2. We also limited the proposal to be the exact match between peers. No support for  multiple and different proposals between phase1  & 2

 
phase1





phase2



route



note: A route-based vpn must have a route installed with the next-hop interface of the phase1 name


firewall-policies




Tips

  ensure IKEv2 is support in the firewall and router b4 you try to build out a vpn
  diag vpn ike  gateway  will provide IKE SAs information for the fortigate
  diag vpn tunnel list will provide ipsec-SA informations
  show crypto ikev2 sa  will provide  cisco SA information for IKEv2
  show crypto ipsec sa  will provide SA details and packets encrypted or decrypted

NOTE: IKEv2 SA should always matches and the same for the phase2 SA. SA within IKEv2 are bidirectional while IPSEC-SAsa are uni-directional for in/out




Ken Felix
Consulting Engineer Network & Security  ( Cisco, Juniper, Fortinet )
kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^
=(   #   # )=
         o
      /     \