Can we enable AAA in FWSM System Execution Space?

[limtohsoon]

Hi Sir,

I have an FWSM version 3.1(8) installed in a Catalyst 6513 (with Sup720). It is configured in multiple context mode.

All the contexts (admin + user) initially have AAA Authentication configured to authenticate CLI access against a TACACS+ server(ACS v3.2).

Users typically telnet to the Admin context, switch to system execution space, and from there switch to other contexts. The whole FWSM is under one common administrative control.

Lately I configured AAA Accounting on all the contexts to account for the commands executed by the users. It works. I can see the logs in TACACS+ Administration in the ACS.

I have the following concerns:

1. Can we enable AAA accounting for the system execution space? I notice AAA commands are not available there. This is to counter for users who telnet to the Admin context, get authenticated, and then switch to the system execution space. Also to counter for the scenario whereby users log in to the switch and session into the FWSM. I need to authenticate and account them against the same TACACS+ server.

2. How to prevent users from sessioning into the FWSM from the switch CLI? I can think of changing the enable password of the system execution space. They will be forced to execute the "login" command and be prompted for username. Then again, I think the usernames are only kept in local database since we can configure AAA here.

Any suggestions are most welcome.

Thank you.

B.Rgds,

Lim TS

[c.hulcher]

1. No, there does not seem to be a way to account for commands entered within the system execution space. The admin context is the "gateway" for the system execution space so access to there will always get you to the other.

2. Setup command authorization for the host switch and restrict access to the "session slot X" command.

[limtohsoon]

Hi Carson,

I tested this:

Telnet to admin context and log in. "changeto system" and made changes there. My commands were not accounted in the ACS. Then switched to other contexts and made some changes. Those commands were accounted in the ACS, clearly showing my username and the commands I executed in those contexts.

I agree with you, we can set up command authorization for the host switch and restrict access to the "session slot X" command. However as my test shows, we can't avoid a user from doing "changeto system" from the admin context.

Any insight? Configure command authorization?

Thank you.

B.Rgds,

Lim TS

[c.hulcher]

That was kind of my point, anyone that you trust to be within the admin context is going to be able to control the entire firewall including being able to get into the system execution space. The admin context (along with sessioning from the host device) is your gateway and where you have to restrict access.

Is your admin context used strictly for access to the firewall and not for actively passing traffic? If so, remove everyone that you don't want getting into the system execution space from the allowed list of users. If not, then command authorization within the admin context would definitely do the trick.