Thursday, December 31, 2009

Goodbye '09

Hi Everyone,

As the year winds up, I figured I'ld steal a quick post - the very last one for 2009.

2009 was a quite a phenomenal one - You'ld probably be in 2010 by the time you are reading this ;)

Highlights of the year include; GEM (Global Economic Meltdown), Graduation from the University, Passing the CCIE R&S lab, Serving my country, Starting this blog and a whole lot of other events.

Looking back at the year, there is a lot to be happy about and I am immensely grateful to God and everyone that made the year a special one. Thank you to family, friends, peers, colleagues and everyone.

Wish you all a great new year. Its about 90mins away from here. Let the fireworks begin :-)

Cheers,

Amplebrain.

ASA Cut-Through Proxy Part 2: Radius Authorization

AAA Authorization and Authentication are two separate processes. Authorization must be performed after Authentication has taken place. That makes sense because we have to know who the user is before we can know what he can do right?

While User Authentication and Authorization are separate processes, they are implemented together in the RADIUS server. The User is Authenticated and downloadable access-lists are used to perform Authorization for the user.
From a configuration perspective, no further authorization command is needed on the ASA as the authentication and authorization is performed at once on the RADIUS server.


From the radius server perspective, there are two ways to accomplish authoriztaion.

1. The radius server can reference an ACL configured on the ASA which is now 'activated' after the user has authenticated. In this case, the access-list name is specified under the radius attribute 11 (filter-id). The access-list can also be specified under the cisco AV pair (009,001) attribute.


2. The Access-list entries can be defined on the ACS server and downloaded unto the ASA after the user has authenticated.
Downloadable access-lists can be created on the server using the Advanced downloadable access-list features, (This must be activated from the Interface configuration tab). Check the box for "group-level downloadable access-lists"


The other option is to specify the access-list entries in the cisco-av-pair using the "inbound access-list" syntax.

ip:inacl#[acl-line-number]=[acl permit/deny statement] for example:

ip:inacll#1=permit ip any any



Note that there must be an authentication protocol for authorization to work, if none of the authentication protocols (telnet, http(s) or ftp) is configured, then the virtual telnet/http command should be used.



Consider the following same topology as the previous post;

R1 --- (inside)ASA(outside) -- R2 where the Radius server is on the inside interface.

The user would be authorized to telnet from the outsude interface to R1 on port 3070.



1. Configure the authentication AAA server on the ASA.

aaa-server ACS protocol radius

aaa-server ACS (inside) host 10.10.10.5

key bauxite



2. Configure the Authentication access-list


access-list AUTH extended permit tcp any host 2.2.2.2 eq telnet

virtual telnet 2.2.2.2




3. Since it is on the outside the access-list must be configured to allow the authentication traffic:



access-list OUTSIDE_IN permit tcp any host 2.2.2.2 eq telnet

access-group OUTSIDE_IN in interface outside



4. Configure AAA for authentication


aaa authentication match AUTH inside ACS




5. Configure the AAA server: To keep things simple, we would define the access-list test_auth on the ASA and then refer to it through the filter-id attribute of the RADIUS server:



access-list test_auth extended permit tcp any any eq 3070

access-list test_auth extended permit tcp any host 2.2.2.2 eq telnet



The 2nd line of the acl is added so that the telnet session for authentication does not die after the authorization has taken place on the ASA. If the telnet session is not allowed by the authorization acl, though authorization would still take place, the telnet session would die immediately after the user is authorized and an error would be returned (though the process was successful), we would rather add the line for sanity sake. :-)



On the Radius server:



6. Enable Per-user override on the inbound access list on the outside interface;

This makes the downloaded access-list take precedence over the existing interface access-list

access-group OUTSIDE_IN in interface outside per-user-override



7. Verification


Enable telnet on port 3070 on R1



line con 0

rotary 70

password cisco





Before Authorization:



R2#telnet 10.10.10.3 3070

Trying 10.10.10.3, 3070 ...

% Connection timed out; remote host not responding



R2#telnet 2.2.2.2

Trying 2.2.2.2 ... Open



LOGIN Authentication



Username: Amplebrain



Password:




Authentication Successful




[Connection to 2.2.2.2 closed by foreign host]



R2#telnet 10.10.10.3 3070

Trying 10.10.10.3, 3070 ... Open




User Access Verification



Password:

R1>





Show User Authentication on the ASA


ASA#sh uauth


Current Most Seen



Authenticated Users 1 1


Authen In Progress 0 1


user 'Amplebrain' at 192.168.1.2, authenticated


access-list test_auth (*)


absolute timeout: 0:05:00


inactivity timeout: 0:00:00



As I mentioned earlier, Authorization can also be accomplished using the tacacs+ protocol but this is implented entirely differently. I hope to put up a post on this sometime in the future.




Anyway, this is the last technical post for the year 2009!



Wishing everyone a prosperous 2010...Cheers!


Amplebrain

Tuesday, December 29, 2009

ASA Cut-Through Proxy: Part 1

In the previous post, I discussed the IOS Authentication Proxy and hw it is used for 'authorization' using downloadable access-lists. In this post, I would describe the Cut-through proxy feature of the ASA.

The Proxy Authentication feature of the ASA is tied to the AAA process.
Authentication proxy can be configured for any protocol but authentication is performed by the telnet, http, https and FTP protocols. If any other protocol is requires authentication, one of the other "authentication protocols" (ftp, http(s) or telnet) MUST also be configured to authenticate the user before access can be granted.
Once a protocol is configured for authentication under the AAA process, unauthenticated users are not given access to the protocol.

The Authentication and Authorization processes are separate on the ASA.
Users can be authenticated using the local database, tacas+ server and the RADIUS server. Users can only be authorized with Radius or Tacacs+ but not the local user database.

Unlike Auth-Proxy, the traffic required for authentication MUST be allowed in the access-lists otherwise Authentication/Authorization wouldnt be able to take place. Authorization can be used to allow further traffic.


Lets look at a simple example of proxy-authentication using the local database. Assuming we have the topology:


R1 ---- (inside)ASA(outside) ---- R2

Base configuration:

interface Ethernet0
nameif inside
security-level 100
ip address 10.10.10.1 255.255.255.0
!

interface Ethernet1
nameif outside
security-level 0
ip address 192.168.1.1 255.255.255.0
!

1. Specify traffic to be Authenticated using an access-list

access-list AUTH extended permit icmp any any
fixup protocol icmp

The fixup protocol is used to ensure icmp traffic is inspected. (It is a quick fix compared to using the MPF). Another option would be to allow icmp inbound on the outside interface.

2. Configure AAA server: We would just add a user since we are using the local database.
username Amplebrain password cisco


3. Configure AAA on the ASA


aaa authentication match AUTH inside LOCAL
auth-prompt prompt Authenticate Before Access
auth-prompt accept Access Granted
auth-prompt reject Access Denied

The line "aaa authentication match AUTH inside LOCAL" means that traffic matched by the AUTH access-list on the inside interface must be authenticated using the local database before they can be allowed to pass through.

4. Test

R1#ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

We cant reach R2. This is because we are authenticating icmp protocol but icmp is NOT one of the authentication protocols. At least one authentication protocol configured for authentication for this to work.
The ASA uses the virtual command for this.



5. Configure Virtual Telnet address and add 2.2.2.2 to the AUTH traffic


virtual telnet 2.2.2.2
access-list AUTH extended permit tcp any host 2.2.2.2 eq telnet

The authenticating user must have a route to 2.2.2.2 for this to work properly.

6. Test Again: Authenticate with virtual telnet and then ping.


R1#telnet 2.2.2.2
Trying 2.2.2.2 ... Open

LOGIN Authentication

Authenticate Before Access
Username: Amplebrain

Password:
Access Granted

Authentication Successful


[Connection to 2.2.2.2 closed by foreign host]
R1#ping 192.168.1.2

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

R1#


On the ASA, we can show authenticated users

ASA(config)# sh uauth
Current Most Seen
Authenticated Users 1 1
Authen In Progress 0 1
user 'Amplebrain' at 10.10.10.3, authenticated
absolute timeout: 0:05:00
inactivity timeout: 0:00:00
ASA(config)#

The next post would describe proxy-authorization using the Radius Server.

Compliments of the season :-)

Amplebrain.

Monday, December 28, 2009

IOS Authentication Proxy

Authentication Proxy is a very useful cisco IOS Firewall Feature.
IMO, It is a more 'advanced' form of dynamic access-list.
Back with Dynamic access-lists, users were required to authenticate using Telnet and then the dynamic entry in the access-list is activated using the "access-enable" command. This can be automated using the autocommand feature either with the username command or under the line configuration.

Drawbacks of Dynamic access-list include;
1. It requires that the user first telnets into the router.
2. You can only have one dynamic entry line in an access list. The work around was normally to give access to a bastion host that is now used to access further resources (or to use)
3. You cannot have user specific (or group specific) profiles.

Documentation for dynamic access-list can be found here.

The IOS Auth-proxy feature was designed to fix these issues. It uses the ACS Server for Authentication and Authorization. Either the radius or tacacs+ server can be used for auth-proxy.

The IOS auth-proxy service uses user/group specific downloadable acls that is downloaded from the ACS server unto the router. This access-lists are specified on the AAA and attached to the auth-proxy service. This is implemented a little differently on the radius and the tacacs+ server.

On the Tacacs+ server, the auth-proxy service is first added, from the Interface Configuration Section, then access-list is specified under the user/group settings. The privilege level must be set to 15 for the access-list to be downloaded correctly. An example of the custom attributes of the auth-proxy service that would be defined in group settings would be:


priv-lvl=15
proxyacl#1=permit ip any any


With the Radius server, the downloadable access-list is set as the cisco-av-pair (9,1) as we would see in the example below.
Assuming we have the topology below;


We want to implement AP for users in the inside network. We would use telnet and http as our protocols for authentication.

Default configuration:
interface FastEthernet0/0
ip address 10.10.10.1 255.255.255.0
ip access-group 101 in
interface FastEthernet1/0
ip address 192.168.1.1 255.255.255.0
access-list 101 permit ip host 10.10.10.5 host 10.10.10.1
access-list 101 deny ip any any


Note that the address of the ACS server is allowed to communicate with the router so that authentication can take place.

There are 5 steps in this configuration:

1. Configure AAA on the router

FW#sh run | i aaa
aaa new-model
aaa authentication login default group radius
aaa authentication login cons none
aaa authorization auth-proxy default group radius
radius-server host 10.10.10.5 auth-port 1645 acct-port 1646 key bauxite


The 'cons' method is defined so as to exclude the console line from AAA authentication.

2. Configure AAA on the server. The radius configuration snapshot is shown below




3. Configure auth-proxy on the router.

ip auth-proxy auth-proxy-banner http #Authenticate before Access....#
ip auth-proxy auth-proxy-banner telnet #Please Authenticate#
ip auth-proxy name test http inactivity-time 60
ip auth-proxy name test telnet inactivity-time 60


4. Configure http-server for http authentication process
ip http server ip http authentication aaa

5. Apply Auth-proxy on the interface.

int f0/0 ip auth-proxy test

Verification:
From the Inside Router:

INSIDE#telnet 192.168.1.2
Trying 192.168.1.2 ... Open

Please Authenticate
Username:Amplebrain
Password:
Firewall authentication Success.
Connection will be closed if remote server does not respond
Connecting to remote server...

User Access Verification

Password:
OUTSIDE>


For http: Here are snapsots from the From the inside host:

After Authentication:

Friday, December 25, 2009

Merry Christmas!

Hi Everyone,
Merry Christmas.
Hope you all have fun and stay away from 'geeky' stuff :-)
Here's what I'ld call a totally "cisco-geeky" xmas.
Thanks to Joe Astorino on GS for the link.

As the year comes to an end, it's time to take stock and make resolutions for 2010.
Feliz Navidad guys!

Amplebrain