A-21
Cisco Intrusion Prevention System Sensor CLI Configuration Guide for IPS 5.0
78-16527-01
Appendix A System Architecture
MainApp
The Administrator can add additional user accounts either through the CLI or an IPS manager. For more
information, see
User Roles, page A-28
.
Configuring Authentication on the Sensor
When a user tries to access the sensor through a service such as Web Server or the CLI, the user’s identity
must be authenticated and the user’s privileges must be established. The service that is providing access
to the user initiates an execAuthenticateUser control transaction request to AuthenticationApp to
authenticate the user’s identity. The control transaction request typically includes the username and a
password, or the user’s identity can be authenticated using an SSH authorized key.
AuthenticationApp responds to the execAuthenticateUser control transaction request by attempting to
authenticate the user’s identity. AuthenticationApp returns a control transaction response that contains
the user’s authentication status and privileges. If the user’s identity cannot be authenticated,
AuthenticationApp returns an unauthenticated status and anonymous user privileges in the control
transaction response. The control transaction response also indicates if the account’s password has
expired. User interface applications that authenticate users by initiating an execAuthenticateUser control
transaction prompt the user to change the password.
AuthenticationApp uses the underlying operating system to confirm a user’s identity. All the IPS
applications send control transactions to AuthenticationApp, which then uses the operating system to
form its responses.
Remote shell services, Telnet and SSH, are not IPS applications. They call the operating system directly.
If the user is authenticated, it launches the IPS CLI. In this case, the CLI sends a special form of the
execAuthenticateUser control transaction to determine the privilege level of the logged-in user. The CLI
then tailors the commands it makes available based on this privilege level.
Managing TLS and SSH Trust Relationships
Encrypted communications over IP networks provide data privacy by making it impossible for a passive
attacker to discover from the packets exchanged alone the secret key needed to decrypt the data in the
packets.
However, an equally dangerous attack vector is for an imposter to pretend to be the server end of the
connection. All encryption protocols provide a means for clients to defend themselves from these
attacks. IPS supports two encryption protocols, SSH and TLS, and AuthenticationApp helps manage
trust when the sensor plays either the client or server role in encrypted communications.
The IPS Web Server and SSH server are server endpoints of encrypted communications. They protect
their identities with a private key and offer a public key to clients that connect to them. For TLS this
public key is included inside an X.509 certificate, which includes other information. Remote systems
that connect to the sensor should
verify that the public key received during connection establishment is
the key they
expect.
Clients must maintain a list of trusted public keys to protect themselves from man-in-the-middle attacks.
The exact procedure by which this trust is established varies depending on the protocol and client
software. In general, the client displays a fingerprint of 16 or 20 bytes. The human operator who is
configuring the client to establish trust should use an out-of-band method to learn the server’s key
fingerprints before attempting to establish trust. If the fingerprints match, the trust relationship is
established and henceforth the client can automatically connect with that server and be confident that the
remote server is not an imposter.
