PIX V6.2 access-lists and authentication

[jim-bell]

We have a PIX 501 v6.2 internal on an intranet and are looking to allow certain subnets and other specific IP hosts through from high security(inside) to low security side(outside) without any authentication or authorization.

However at the same time we want to authenticate some other users taking the same route and to apply an access-list from our CiscoSecure ACS v2.6.

We are using http authentication.

How would I combine these two different requirements on the inside interface

e.g. permit tcp 10.10.10.2 255.255.255.0 any eq 1022 and

(if authenticated) permit tcp host 10.120.10.1 any eq 8051

We have a similar set-up working on a router using authentication-proxy of firewall feature set, in that the access-list has the static entries and is dynamically altered when users are authenticated with their access requirements.

[shannong]

This would be accomplished on a pix with the [aaa] command. To apply authentication to some users and not others, use an ACL to define what is authenticated and what is not. The "radius-group" must defined with the [aaa-server] command.

aaa authentication match someacl inside radius-group

access-list someacl permit host 10.120.10.1 any

The host at 10.120.10.1 will need to authenticate before passing ANY traffic through the Pix. This can be accomplished with a web browser, ftp, or telnet session. After initial authentication, all traffic will be allowed by the 10.120.10.1 host to any other host/service.

Optinally, you can define an ACL on the pix of what a USER can do when they authenticate. When authenticating the user to ACS, the ACS server can tell the Pix to enforce the ACL on the users traffic. This allows user level control of traffic rather than host/IP only level.

Check the Pix documentation for the [aaa] command the the [access-list] command. They have brief examples for all of these.

[jim-bell]

Thanks Shannon,

We had achieved that using commands below;

aaa-server RADIUS protocol radius

aaa-server AuthOutbound protocol radius

aaa-server AuthOutbound (inside) host 10.x.x.x a1b2c3d4e5 timeout 5

access-list auth_user permit tcp host 10.120.10.1 any eq www

aaa authentication match auth_user inside AuthOutbound

and the ACL that was passed down from Ciscosecure ACS was

permit tcp host 10.120.10.1 any eq 8051

However as the default on the PIX is to permit everything from the inside going outside 10.120.10.1 can get out without authentication so we tried to restrict 10.120.10.1 until it was authenticated by using the access-list below;

access-list acl_in permit 10.10.10.2 255.255.255.0 any eq 1022

access-list acl_in deny tcp host 10.120.10.1 any eq 8051

however this access-list acl_in blocks 10.120.10.1 to 8051 before it gets

to the AAA-user ACL that was downloaded from Ciscosecure ACS in order to permit it.

Is it possible to mix access-lists that restrict traffic into the inside interface with

aaa authentication - or would it be possible if we swapped inside and outside

interfaces around.

Thanks

[shannong · Accepted solution]

Don't use an ACL on the inside interface to accomplish this. Rather, define you ACL to include authentication for all traffic from that host going out.

access-list auth_user permit ip host 10.120.10.1 any

This means the user cannot pass ANY traffic out until it receives authentication. The host can accomplish this by opening a web browser to anything outside and giving the firewall appropriate credentials. Or FTP to anything outside... Or telnet to anything outside.

When the ACS validates the users credentials, pass back the ACL for that user to define exactly what you want to allow and what you want to deny. If you only permit outbound to TCP/8501, then all other traffic will be implicitly denied. The ACLs per user work like any other access-list. This will not require an ACL to be bound to the inside interface.

-Shannon

[jim-bell]

Shannon,

The use of the ip host 10.120.10.1 any has done the trick.

Thanks for all your help.

One additional point is it possible for the PIX firewall to return an http pop-up window ( like Cisco IOS FFS with authentication-proxy) to indicate that authentication was successful.

Thanks again

Jim.

[shannong]

That isn't possible to my knowledge. The pix will send a html page about denied authentication, but that is all.