Cisco ASA Firewall Archives

Access Control Lists (ACLs) are sequential lists of permit and deny conditions applied to traffic flows on a device interface. ACLs are based on various criteria including protocol type source IP address, destination IP address, source port number, and/or destination port number.

ACLs can be used to filter traffic for various purposes including security, monitoring, route selection, and network address translation. ACLs are comprised of one or more Access Control Entries (ACEs). Each ACE is an individual line within an ACL.

[ad#embedded-square]

ACLs on a Cisco ASA Security Appliance (or a PIX firewall running software version 7.x or later) are similar to those on a Cisco router, but not identical. Firewalls use real subnet masks instead of the inverted mask used on a router. ACLs on a firewall are always named instead of numbered and are assumed to be an extended list.

The syntax of an ACE is relatively straight-forward:

Ciscoasa(config)#access-list name [line number] [extended] {permit | deny} protocol

source_IP_address source_netmask [operator source_port] destination_IP_address

destination_netmask [operator destination_port] [log [[disable | default] | [level]] [interval seconds]] [time-range name] [inactive]

Here’s an example:

asa(config)# access-list demo1 permit tcp 10.1.0.0 255.255.255.0 any eq www

asa(config)# access-list demo1 permit tcp 10.1.0.0 255.255.255.0 any eq 443

asa(config)# show access-list demo1

access-list demo1; 2 elements

access-list demo1 line 1 extended permit tcp 10.1.0.0 255.255.255.0 any eq www

access-list demo1 line 2 extended permit tcp 10.1.0.0 255.255.255.0 any eq https

In the above example, an ACL called “demo1″ is created in which the first ACE permits TCP traffic originating on the 10.1.0.0 subnet to go to any destination IP address with the destination port of 80 (www). In the second ACE, the same traffic flow is permitted for destination port 443. Notice in the output of the show access-list that line numbers are displayed and the extended parameter is also included, even though neither was included in the configuration statements.

You can deactivate an ACE without deleting it by appending the inactive option to the end of the line.

As with Cisco routers, there is an implicit “deny any” at the end of every ACL. Any traffic that is not explicitly permitted is implicitly denied.

**Editing ACLs and ACEs**

New ACEs are appended to the end of the ACL. If you want, however, to insert the new ACE at a particular location within the ACL, you can add the line number parameter to the ACE:

asa04(config)# access-list demo1 line 1 deny tcp host 10.1.0.2 any eq www

asa04(config)# show access-list demo1

access-list demo1; 3 elements

access-list demo1 line 1 extended deny tcp host 10.1.0.2 any eq www

access-list demo1 line 2 extended permit tcp 10.1.0.0 255.255.255.0 any eq www

access-list demo1 line 3 extended permit tcp 10.1.0.0 255.255.255.0 any eq https

Notice in the first line of the example above that an ACE is added at line one in the ACL. Notice in the output from the show access-list demo1 command that the new entry is added in the first position in the ACL and the former first entry becomes line number two.

You can remove an ACE from an ACL by preceding the ACE configuration statement with the modifier no, as in the following example:

Asa04(config)#no access-list demo1 deny tcp host 10.10.2.1 any eq www

In my next article, I’ll show you how to use time-ranges to apply access-control lists only at certain times and/or on certain days. I’ll also show you how to use object-groups with access-control lists to simplify ACL management by grouping similar components such as IP addresses or protocols together.

Copyright (c) 2008 Don R. Crawley

Don R. Crawley, CCNA-certified, is president and chief technologist at soundtraining.net, the Seattle training firm specializing in business skills and technical training for IT professionals.

Article Source: http://EzineArticles.com/?expert=Don_R._Crawley

Allowing Microsoft PPTP through Cisco ASA

The Microsoft Point to Point Tunneling Protocol (PPTP) is used to create a Virtual Private Network (VPN) between a PPTP client and server. It is used for remote access from mobile users to connect back to their corporate network over the Internet. A PPTP client connects and authenticates to the PPTP server which assigns an IP address to the client and attaches the remote user to the network. After that, the remote user has full network connectivity just like being connected locally.

In the older PIX version 6.x, you could configure the PIX firewall itself to work as a PPTP server, thus you didn’t even need to have a Windows PPTP server in place. With the new ASA firewall however, you cannot terminate PPTP on the ASA itself. Therefore you must have a Microsoft PPTP server in the network in order to terminate PPTP connections from clients.

[ad#embedded-square]

PPTP uses two protocols: GRE to encapsulate PPP packets and a control channel at TCP port 1723. Any stateful firewall would have a problem with allowing PPTP protocol without any special “fixup” because of the two protocols needed for communication (GRE and TCP 1723). Cisco ASA allows you to pass PPTP traffic through with a special “inspection” mechanism which checks the control traffic (TCP 1723) in order to dynamically open also access for GRE traffic to pass through with no problems.

In this post we will see two scenarios of allowing PPTP traffic through a Cisco ASA. In the first scenario we have a PPTP client on the inside of ASA which communicates with a PPTP server on the outside zone. In the second scenario we have a PPTP client on the outside of ASA which communicates with a PPTP server on the inside.

Scenario 1: PPTP client on inside and server on outside

The first scenario above depicts a PPTP server located on the outside of the ASA (Internet) and PPTP clients on the inside. Using the “inspect” command in the global policy-map we can enable access from inside to outside for PPTP.

! enable Port Address Translation on the outside interface
ciscoasa(config)#nat (inside) 1 0.0.0.0 0.0.0.0 0 0
ciscoasa(config)#global (outside) 1 interface

! Add PPTP inspection to the default policy-map using the default class-map
ciscoasa(config)# policy-map global_policy
ciscoasa(config-pmap)# class inspection_default
ciscoasa(config-pmap-c)# inspect pptp

Scenario 2: PPTP client on outside and server on inside

This scenario depicts a PPTP server located on the inside network. Here we must configure static NAT for the PPTP server and allow the appropriate protocols from outside (GRE, TCP 1723)

! translate the PPTP server private address 192.168.1.1 to public 50.50.50.1
ciscoasa(config)# static (inside,outside) 50.50.50.1 192.168.1.1 netmask 255.255.255.255

! allow the appropriate protocols from outside to inside
ciscoasa(config)# access-list acl-out permit gre any host 50.50.50.1
ciscoasa(config)# access-list acl-out permit tcp any host 50.50.50.1 eq 1723
ciscoasa(config)# access-group acl-out in interface outside

Cisco ASA 5505 User License Explained

I get a lot of questions regarding the meaning of user license numbers for the Cisco ASA 5505. This model is offered in three User License options. 10 users, 50 users and UL (unrestricted license). The meaning of user license basically refers to concurrent IP addresses that can communicate between Internal (inside) network and Internet (outside) interface. So, for 10 user license, only 10 concurrent internal hosts (IP addresses) can access the internet. The same applies for 50 users (only 50 concurrent IP addresses can access the Internet). For UL license, there is no such restriction.

The user licensing has also an effect on the maximum number of IP addresses that can be assigned by the DHCP server of the ASA5505 to the internal hosts. For a 10-user license, the max number of DHCP clients on the internal network is 32. For 50-user license, the max number of DHCP clients is 128.

The official explanation from Cisco regarding the Cisco ASA5505 user licensing is as follows:

“In routed mode, hosts on the inside (Business and Home VLANs) count towards the limit only when they communicate with the outside (Internet VLAN). Internet hosts are not counted towards the limit. Hosts that initiate traffic between Business and Home are also not counted towards the limit. The interface associated with the default route is considered to be the Internet interface. If there is no default route, hosts on all interfaces are counted toward the limit. In transparent mode, the interface with the lowest number of hosts is counted towards the host limit. See the show local-host command to view host limits. “

The terms “Business” and “Home” VLANs above refer to the Internal and DMZ network zones.

Policy NAT on Cisco ASA Firewall

As we know, the conventional NAT functionality on Cisco devices (routers, ASA firewalls etc) translates the SOURCE IP address to something else. There is also the so called “Destination based NAT” (or you may see it referred as “Reverse NAT”) which changes the destination IP address. Here we will deal with conventional source based NAT with a policy.

Sometimes we need to change the source IP address to another source address (lets call it “translated-A”) when we are communicating with “destination-A”, and also change the source IP to “translated-B” when we are communicating with “destination-B”.

 So, to be clearer, the scenario is the following:
 

  • When internal host 192.168.1.1 wants to communicate with external host 100.100.100.1, then the internal host must be translated to 50.50.50.1
  • When the internal host 192.168.1.1 wants to communicate with external host 200.200.200.1, then the internal host must be translated to 50.50.50.2

 We can achieve the functionality above with Policy-Based NAT.

Configuration Example:

Assume that the internal host 192.168.1.1 is connected to the inside interface of ASA. We have also in our possession the public IP range 50.50.50.0/24. We will use the public IP range to translate our internal host according to the destination.

! First create the access lists for the policy NAT
ASA(config)# access-list POLICYNAT-A extended permit ip host 192.168.1.1 host 100.100.100.1
ASA(config)# access-list POLICYNAT-B extended permit ip host 192.168.1.1 host 200.200.200.1

! Now create the static NAT translation for Destination-A
ASA(config)# static(inside,outside) 50.50.50.1 access-list POLICYNAT-A

! Now create the static NAT translation for Destination-B
ASA(config)# static(inside,outside) 50.50.50.2 access-list POLICYNAT-B

The above commands will do the following: When source address is 192.168.1.1 and destination address is 100.100.100.1, then change the source address to 50.50.50.1.

Similarly, when source address is 192.168.1.1 and destination is 200.200.200.1, then change the source address to 50.50.50.2.

The above static nat commands will only take effect if and only if the traffic is between the hosts referenced in the access-lists (either inbound or outbound traffic).

SNMP stands for Simple Network Management Protocol. Up to ASA software 8.1, the SNMP version supported was v1 and v2c. The newest ASA software 8.2 supports also SNMP v3 which is the most secure snmp protocol version.

The ASA works as an SNMP server (or agent), so you need also a Network Management System (NMS) which will act as the SNMP manager in order to provide network monitoring and management functionality. The NMS is basically a management server such as the CiscoWorks product. With the NMS you can either poll the ASA appliance to collect information, or the ASA appliance can send snmp traps (event notifications) to the NMS server. SNMP Traps are sent on UDP port 162 and SNMP poll uses UDP port 161. So, the ASA will listen on udp 161 and the NMS will listen on udp 162 and 161.

Configuring SNMP

 Step1: Enable the snmp server on the ASA

ASA(config)# snmp-server enable
 

Step2: Identify the NMS host that can connect to the ASA for SNMP management

ASA(config)# snmp-server host [interface_name][ ip_address] community [community string]

Where “interface name” is the ASA interface through which the NMS can be reached, and “ip address” is the NMS address. “community string” is like a preshared password which must be configured on both the ASA and the NMS in order for the two elements to communicate.

Step3: Specify the ASA community string

 ASA(config)# snmp-server community [community string]
 

Step4: Enable the ASA to send snmp traps to the NMS

 ASA(config)# snmp-server enable traps [all | snmp [trap] [trap] ]

The default configuration has all snmp traps enabled (snmp-server enable traps snmp authentication linkup linkdown coldstart). It is recommended to leave all traps enabled as the default setting.

Configuration Example:

ASA(config)# snmp-server enable
ASA(config)# snmp-server host inside 10.1.1.100 community somesecretword
ASA(config)# snmp-server community somesecretword
ASA(config)# snmp-server enable traps snmp authentication linkup linkdown coldstart

 Page 6 of 15  « First  ... « 4  5  6  7  8 » ...  Last »