Archive for November, 2008



User Authentication for Web Server Access

Sunday 30 November 2008 @ 11:45 am

Imagine the following scenario: We have a web server on a DMZ protected by a Cisco ASA 5500 firewall. We would like to allow external Internet users to access this web server only after they successfully authenticate with a username/password credential. Maybe this scenario could be applicable in situations where we need to allow employees to access a corporate intranet web server when they are away from the office. The username/password accounts for the users could be stored either locally on the ASA firewall (not very scalable) or on an internal AAA (Authentication) Server, such as the Cisco Access Control Server (ACS). Let’s see an example diagram below to make things clear:

user authentication for web server access with cisco asa firewall

From the diagram above, assume that the Web Server (WEB_SRV) has a public IP address of 20.20.20.1. Any access from outside to this IP address must be intercepted by the ASA firewall which should prompt the user for authentication (username/password). After the user enters his/her credentials, the Firewall will communicate with the AAA Authentication server (AAA_SRV), using either TACACS+ or RADIUS protocols, to validate the credentials of the user. The AAA server will respond to the firewall with ACCESS_PERMITED or ACCESS_DENIED accordingly. If permitted, the user will be able to communicate with the Web Server. This functionality of the Cisco ASA Firewall is also called “cut-through Proxy” and works for only specific services (HTTP, HTTPs, FTP, and TELNET). This means that in addition to authenticating users for Web Server access, we can do the same for FTP or TELNET Servers as well.

Configuration Example:

! Specify a AAA server name (AAA_SRV) and which protocol to use (Radius or TACACS+)
CISCO-ASA(config)#  aaa-server AAA_SRV protocol tacacs+

! Designate the Authentication server IP address and the authentication secret key
CISCO-ASA(config)#  aaa-server AAA_SRV (inside) host 10.0.0.1
CISCO-ASA(config-aaa-server-host)#  key authentication-secret-key

! The following ACL specifies for which traffic flow the firewall will enforce authentication
CISCO-ASA(config)#  access-list 120 permit tcp any host 20.20.20.1 eq www

! Enable web server user authentication by matching the ACL configured above
CISCO-ASA(config)#  aaa authentication match 120 outside AAA_SRV

! The last statement above will authenticate traffic on the “outside” interface using
! server AAA_SRV only if this traffic matches Access List 120




Cisco Branch Virtual Office Solutions

Monday 24 November 2008 @ 7:23 am

Extending the central office enterprise environment to remote branch office locations gives employees greater flexibility while enhancing productivity and reducing costs. Cisco Virtual Office solution is an umbrella of technologies and products that delivers secure data, voice, and video communication to remote teleworkers and branch offices, providing to remote employees a seamless office-caliber experience to wherever they may be located.

A high level network topology of two remote branch offices with the enterprise central site is shown in the figure below:

cisco remote branch virtual office

The components that constitute the Cisco Virtual Office solution include the following products and technologies:

 REMOTE BRANCH LOCATION:

 In the remote user premises, the equipment includes Cisco 800 series ISR (Integrated Services Routers) to provide secure IPSEC VPN connectivity towards the central site, together with unified 7900 series IP Phones that offer voice and video communication with the central call manager system.

 CENTRAL SITE LOCATION:

 The equipment and technologies here include a VPN termination device (which can be either a VPN router or a Cisco ASA Firewall), central call manager system for voice and video control, and central management software for policy enforcement, authentication services, identity management etc.




Cisco ASA 5505 Vlans and Licensing

Wednesday 19 November 2008 @ 8:12 am

The eight physical network interfaces of the Cisco ASA 5505 firewall appliance can be divided into groups that function as separate security zone networks. Each group is a Layer 2 Vlan. Devices in the same group (Vlan) can communicate directly between them without passing through the security control of the firewall. On the other hand, devices between different Vlans can only communicate with each other by passing the traffic through the adaptive security appliance where relevant security policies are applied. By default, there are two Vlans (VLAN1 and VLAN2) preconfigured on the firewall by default. Port Ethernet0/0 belongs to VLAN2 and ports Ethernet0/1 to 0/7 belong to VLAN1. For example, when a switch port on VLAN1 is communicating with a switch port on VLAN2, the adaptive security appliance applies configured security policies to the traffic and routes or bridges the traffic between the two VLANs. Usually Port Ethernet0/0 connects to the outside untrusted interface (Internet), and ports Ethernet0/1 to 0/7 connect to the inside trusted network zone.

 The license installed on the 5505 firewall determines the number of active VLANs allowed on the appliance as described below:

 Basic ASA 5505 License:

The basic license allows only 3 active VLANs which you can use as Inside, Outside and DMZ. However, there is a restriction here that many people do not know about: The DMZ VLAN can access ONLY the Outside VLAN but can not access the Inside VLAN. The other two VLANs (Inside and Outside) can access all the other VLANs with no problems.

 Security Plus ASA 5505 License:

The Security Plus license, removes all limitations and allows up to 20 active VLANs to be configured. Since there are only 8 physical ports, you can create several vlan subinterfaces on each physical port to segment your network into different security zones (e.g Inside, Outside, DMZ1, DMZ2, Sales, Engineering etc).




Passing non-IP Traffic over IPSEC VPN using GRE over IPSEC

Friday 14 November 2008 @ 5:53 am

IPSEC VPN is a great technology for encrypting and securing communications between networks. The only drawback is that IPSEC supports ONLY pure IP unicast traffic and nothing else. If you want to securely pass multicast or non-IP traffic between sites then IPSEC alone will not work. Fortunately Cisco routers support the GRE protocol (Generic Routing Encapsulation) which is a tunneling protocol that can encapsulate a variety of network layer packet types into a GRE tunnel. GRE therefore can encapsulate multicast traffic, routing protocols (OSPF, EIGRP etc) packets, and other non-IP traffic inside a point-to-point tunnel. The downside of GRE is that it’s not as secure as IPSEC. Now, by using GRE over IPSEC, we can have the best of both technologies: Security and support for many network protocols. Some applications of using GRE over IPSEC are the following:
 

  • Pass multicast traffic from a video server of one site to another site over the Internet.
  • Pass routing protocol updates (multicast traffic) between sites working in an IPSEC VPN topology.
  • Running Novel IPX between IPSEC VPN sites.
  • Use load balancing with a routing protocol between IPSEC VPN sites.

Configuration example

Below we will describe a configuration example between two Cisco routers running GRE over IPSEC via the Internet.

cisco gre over ipsec between two routers

From the diagram above, we have two private LAN networks 192.168.1.0/24 and 192.168.2.0/24 and we want to send non-IP traffic between them (e.g multicast video server traffic from Site-A to Site-B or any other non-IP non-unicast traffic). For each router we have a static Public IP address on the FE0/1 outside interface (100.100.100.1 and 200.200.200.1) over which we will set up the IPSEC tunnel. The GRE tunnels will be running between two private IP addresses (10.0.0.1 and 10.0.0.2) configured on each router (with the interface Tunnel command). The scenario also involves NAT for general internet access of the local networks.

SITE-A

version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname SITE-A
!
boot-start-marker
boot-end-marker
!
enable secret 5 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
!
no aaa new-model
ip subnet-zero
!
!— This is the IPsec configuration.
!
crypto isakmp policy 10
authentication pre-share

crypto isakmp key testkey123 address 200.200.200.1
!
crypto ipsec transform-set ESPDES-TS esp-des esp-md5-hmac
!
crypto map myvpn 10 ipsec-isakmp
!
set peer 200.200.200.1
set transform-set ESPDES-TS
match address 101
!
!— This is one end of the GRE tunnel.
!
interface Tunnel0
ip address 10.0.0.1 255.255.255.0

!— Associate the tunnel with the physical outside interface.
tunnel source FastEthernet0/1
tunnel destination 200.200.200.1

!— Attach the IPSEC crypto map to the GRE tunnel.
crypto map myvpn

!— This is the internal network.

interface FastEthernet0/0
ip address 192.168.1.1 255.255.255.0
ip nat inside

!— This is the external interface and one end of the GRE tunnel.

interface FastEthernet0/1
ip address 100.100.100.1 255.255.255.0
ip nat outside
crypto map myvpn

!— Define the NAT pool.

ip nat pool NATPOOL 100.100.100.2 100.100.100.20 netmask 255.255.255.0
ip nat inside source route-map nonat pool NATPOOL overload
ip classless

ip route 0.0.0.0 0.0.0.0 100.100.100.254

!— Force the private network traffic into the tunnel.

ip route 192.168.2.0 255.255.255.0 10.0.0.2

!— All traffic that enters the GRE tunnel is encrypted by IPsec.
access-list 101 permit gre host 100.100.100.1 host 200.200.200.1

!— Use access list in route-map to address what to NAT.

access-list 175 deny ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
access-list 175 permit ip 192.168.1.0 0.0.0.255 any

route-map nonat permit 10
match ip address 175

end

 

SITE-B

version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname SITE-B
!
boot-start-marker
boot-end-marker
!
enable secret 5 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
!
no aaa new-model
ip subnet-zero
!
!— This is the IPsec configuration.
!
crypto isakmp policy 10
authentication pre-share

crypto isakmp key testkey123 address 100.100.100.1
!
crypto ipsec transform-set ESPDES-TS esp-des esp-md5-hmac
!
crypto map myvpn 10 ipsec-isakmp
!
set peer 100.100.100.1
set transform-set ESPDES-TS
match address 101
!
!— This is one end of the GRE tunnel.
!
interface Tunnel0
ip address 10.0.0.2 255.255.255.0

!— Associate the tunnel with the physical outside interface.
tunnel source FastEthernet0/1
tunnel destination 100.100.100.1

!— Attach the IPSEC crypto map to the GRE tunnel.
crypto map myvpn

!— This is the internal network.

interface FastEthernet0/0
ip address 192.168.2.1 255.255.255.0
ip nat inside

!— This is the external interface and one end of the GRE tunnel.

interface FastEthernet0/1
ip address 200.200.200.1 255.255.255.0
ip nat outside
crypto map myvpn

!— Define the NAT pool.

ip nat pool NATPOOL 200.200.200.2 200.200.200.20 netmask 255.255.255.0
ip nat inside source route-map nonat pool NATPOOL overload
ip classless

ip route 0.0.0.0 0.0.0.0 200.200.200.254

!— Force the private network traffic into the tunnel.

ip route 192.168.1.0 255.255.255.0 10.0.0.1

!— All traffic that enters the GRE tunnel is encrypted by IPsec.
access-list 101 permit gre host 200.200.200.1 host 100.100.100.1

!— Use access list in route-map to address what to NAT.

access-list 175 deny ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
access-list 175 permit ip 192.168.2.0 0.0.0.255 any

route-map nonat permit 10
match ip address 175

end




«« Previous Posts
cisco asa firewall ebook

Configuration Tutorial For Cisco ASA 5500 Firewalls
With FREE ASA 5505 Configuration Tutorial Bonus

CLICK HERE TO DOWNLOAD EBOOKS


Sponsored Links