Note on AAA when using cisco ASA

It’s common practice to have multiple users on a firewall, and each user may have different levels of access, such as admin accounts, while others may have just read-only accounts. The cisco ASA is no different and it is quite easy to setup a local AAA (authentication / authorization / accounting) server so you can have just the scenario above. However, there is a small note here. Most people use ASDM to configure user authentication, and are satisfied when users can login using their username and password.

However, note that ASA makes a distinction between authentication and authorization. While authentication may be configured correctly (the user must present a valid username/password combo), and the ASDM interface may also prevent them from making any changes, if they login to the cli via telnet/ssh… they will still have full access (provided they know the enable password).

In order to make sure a user has read-only access, even via the cli, you need to make sure that user authorization is also correctly configured.

Recall that authentication is the act of validating somebody’s identity (usually via username and password) while authorization is the act of checking the permission a user has to run a certain action (such as an admin command)

Configuring basic authentication is simple in the ASDM. Simply go to

configure > device management > users/aaa > authentication

make sure all options are ticked and set to your appropriate AAA server (I am using the ASA itself in the below screenshot)


Secondly, configure authorization in a similar way, by clicking on the authorization tab and selecting all options:


PS: in the above screenshot the option was already used (hence why it is greyed out), but in order to configure read-only users, in the above screen click on the “set ASDM defined user roles”, one of which will be to change the privilege level of different commands to have read-only and admin users, as well as users who will only have dial in rights (eg for AnyConnect users)


Preserving client IP w/ apache reverse proxy

We recently had a scenario where an apache reverse proxy needed to be deployed in front of a pair of tomcat servers. Due to security concerns, this reverse proxy was hosting mod_security and acting as a web application firewall (WAF)

However, a critical requirement was that the tomcat applications would be able to see the original IP address of the client. This presented a problem because unlike squid, apache has no configurable option to act as a fully transparent proxy. In other words, once traffic was redirected through the apache reverse proxy, the traffic forwarded to the tomcat server was forwarded with it’s source IP address changed to the proxy, effectively hiding the public IP the client used to connect to the site.

The first solution that sprang to mind was the “X-Forwarded-For” headers, which is an HTTP header inserted into the original HTTP GET request whose value is equal to the client’s public IP. Turns out apache reverse proxy inserts this header by default, and even so the tomcat application could not extract the client’s IP. We somehow needed to instruct the tomcat server itself to provide the application with the correct client IP.

The solution that worked in my case was the RemoteIP tomcat valve. Official documentation lives here:

It’s quite simple to configure in that all that needs to be done is to modify tomcat server.xml to recognise original client IP rather than the proxy IP by adding the following to server.xml:

<Valve className="org.apache.catalina.valves.RemoteIpValve"
internalProxies="127\.0\.0\.1" />

make sure to change to the address of the apache reverse proxy.

The application could now recognise the original client IP.


PS as per the tomcat documentation, the apache equivalent of the above method is using the mod_remoteip