admin - Manage administration services and accesses


[1] admin [(snmp | ssh | ssh password | wadmin | waudit) [on | off]]

[2] admin tls [<tls-id>[:<ca-id>]]

[3] admin [ssh [fingerprint | generate [on | off] | (key [raz | (add | del | show) <key-id> | load <key-id> (ftp | sftp | tftp) <file-server> <file-name>])]]

[4] admin topology (internal | external | auxiliary | vpnipsec) [on | off]

[5] admin user [raz | (add | del) <admin-name> [<admin-password>]]

[6] admin snmp [(user [<user-name>]) | (community [<community-password>]) | (privacy [<privacy-password>]) | (udp | tcp | tls [(on | off)]) | engine | (mode [(on | off)])]

[7] admin snmp certificate [raz | load (ftp | sftp | tftp) <file-server> <file-name>]

[8] admin snmp [trap [raz | add (v1 | v2c) <receiver-server> [<port> [<community>]] | del (v1 | v2c) <receiver-server> [<port>] | test]]

[9] admin snmp [trap [raz | add v3 <receiver-server> <port> <user-name> (sha256 | sha384 | sha512) (des | aes) [<auth-password> [<privacy-password>]] | del v3 <receiver-server> <port> <user-name>]]


The first usage form of this command allows you to activate or deactivate administration and management services. To activate a service, use its name (snmp, ssh, wadmin or waudit) followed by the keyword on. Use the keyword off to deactivate it. Available services are as follows:

snmp: the SNMP agent with the possibility to send SNMP traps.

ssh: the SSH server.

wadmin: the Web administration GUI

waudit: the Web auditing GUI

The usage form ssh password allows you to activate or deactivate the SSH password authentication.

Web administration and auditing GUI allow you to configure and audit the system using a Web browser. The auditing service allows you to have a live summary view of different available logs (virus, access...) and inspect Web requests on reverse websites (only for reverse websites when the waf mode is activated. The Web auditing service is for debugging purpose only and should not be activated in normal circumstances with the risk of weakening the system. The auditing is available at the URL https://<admin-ip>:<wadmin-port> where <admin-ip> and <waudit-port> are respectively the administration IP address and the waudit port number. The administration IP address maybe be the internal, external or auxiliary IP address of the appliance according to the configured administration topology (see below). When the vlan mode is activated the native internal IP address can no longer be used. Instead of that, the IP address associated to the administration 802.1q pseudo device can be used (see the command vlan for further information).

The second usage form allows you set the TLS certificate to use for the Web GUI and the SNMP agent over TLS. The TLS certificate is specified by a giving a TLS server identifier. You can optionally specify an intermediate CA certificate by giving its identifier separated by a colon from the TLS server identifier. In this case the specified intermediate CA certificate will be used for the Web GUI.

The third usage form allows you to:

• Show the fingerprint of the RSA and DSA keys used by the SSH server.

• Regenerate those RSA/DSA keys.

• Manage public SSH keys.

By importing a public SSH key, the owner of the private SSH key associated to the imported public SSH key, can login to the system as the admin (or restricted administrator) user without having to enter a password.

To show the SSH server fingerprints, use the keywords admin ssh fingerprint. To arm the regeneration of the SSH server keys, use the keywords admin ssh generate on. Use the keyword off (instead of on) to cancel the regeneration.

The keywords ssh key without any additional arguments allows you to display the list of defined public SSH keys (each key is identified by an identifier). The keywords key raz allows you to reset that list. Importing a public SSH key is done in two steps. First and empty public SSH key should be added using the keywords ssh key add followed by an identifier associated to that public SSH key. In a second step, the public SSH key content can be loaded from a trusted file server (refer to the access command to define trusted file servers). To load a public SSH key use the keywords ssh key load followed by the public SSH key identifier to load and the public SSH key location. The public SSH key location is specified by three arguments: the protocol to use (ftp, sftp, tftp) to load the public SSH key file, the IP address (or name) of the file server on which the public SSH key file is located and the public SSH key file name. The specified file must contain a valid RSA (or DSA) public key. To remove a public SSH key use the keywords ssh key del followed by the public SSH key identifier to delete. Finally the usage form ssh key show followed by an SSH key identifier allows you to show the content of a public key. Note that the system supports the SSH protocol version 2 only. Public SSH keys are activated after using the apply command. Also if you try to load an SSH key that already exists in the system, the loading is simply ignored.

Please note that SSH keys are not part of the configuration thus they are not saved when the configuration is saved with the conf command. To save SSH keys and all other loaded files you cane make a backup of the system using the system command. You have also the possibility to load/save SSH keys among other files related to the configuration using the file command.

The fourth usage form allows you to define the access topology for administration services. The access topology defines logical network interfaces to which administrators (or SNMP manager systems) can connect. To allow administration on a logical network interface, use its name (internal, external, auxiliary or vpnipsec) followed by the keyword on. To deny the administration, use the keyword off instead. Activating the administration on the vpnipsec virtual network interface allows the administration on the internal network interface via an IPsec VPN tunnel.

The fifth usage form allows you to add or remove unprivileged administrator users. Unprivileged administrators have read rights only (ie. they can only consult the configuration). Without any arguments, this command displays the list of unprivileged administrators. To add an unprivileged administrator use the keyword add followed by its user name. To delete an unprivileged administrator use the keyword del followed by the name of the unprivileged administrator to remove. A valid administrator name must begin with an alphabetic character followed by alpha numeric characters as well as the characters "_" and "-". To erase all unprivileged administrators, use the keyword raz.

In interactive mode, when a new unprivileged administrator is added, the privileged administrator (admin user) is invited to define a password for the added unprivileged administrator. The first time an unprivileged administrator is logged in, she/he is invited to modify her/hist password. The new defined password is then applied to the console as well as to the Web GUI interfaces. Please note that administrator passwords are not part of the configuration. Hence, they are not saved when the configuration is saved.

In a non interactive mode (for instance when a configuration file is loaded from a file server), if the added unprivileged administrator does not exist, a password is automatically generated for the added unprivileged administrator as follows: the admin user name (<admin-name>) followed by the character @ (at), the string "appliance", the the character - (dash) and the current year. As an example for the an unprivileged administrator added during the 2023 year and called foo, the automatically generated password would be foo@appliance-2023.

The sixth usage form of the admin command allows you to configure the internal SNMP (Simple Network Management Protocol) agent. The keyword community allows you to set the community string for SNMP-v1 and SNMP-v2c. With SNMP-v3 the community string takes the role of the authentication password using SHA-256 hash function. The keyword user allows you to set the SNMP-v3 user name. When using SNMP-v3 the data portion of the message being sent could be encrypted using AES (Advanced Encryption Standard). The keyword privacy allows you to set the encryption password for the encryption algorithm. Note that the privacy encryption is not mandatory and the agent accepts requests without encryption. The keywords udp, tcp and tls allow you to activate or deactivate respectively SNMP over UDP, TCP and TCP tunnelled over TLS (for encryption). Please note that the SNMP agent listens on the following ports:

• SNMP over UDP: port 161

• SNMP over TCP: port 161

• SNMP TCP tunneled over TLS: port 10161

Please note that only trusted monitoring managers are allowed to access the SNMP agnet. Use the access command to define allowed SNMP managers to access the SNMP agent.

The SNMP agent supports TLS over TCP connections using mandatory client and server SSL certificates. The SSL server certificate is the same as the SSL server certificate used for the Web GUI (see the second usage form above). The seventh usage form allows you to associate the defined SNMP-v3 user name (see above) to a client SSL certificate. The client certificate can be loaded from a file server. Only trusted file servers are allowed. Trusted file servers are defined with the access command.

The eighth and ninth usage forms of the command admin allow you to configure SNMP managers (SNMP trap receivers) to which SNMP traps and notifications are sent. The system uses TCP to send SNMP notifications (and not UDP). The system is able to send different SNMP versions traps and notifications. Supported version are: v1, v2c and v3 respectively for SNMP-v1 traps, SNMP-v2c inform notifications and SNMP-v3 inform notifications. SNMP traps and notifications are sent to receivers specified by its IP addresses (or network names) and port numbers. For SNMP-v1 and SNMP-v2c if the port number is omitted, the port number is set to 162 (SNMP trap default port). To send SNMP-v1 traps and SNMP-v2c inform notifications a community string should be specified (a community string acts as a password for SNMP versions prior to v3). To send SNMP-v3 inform notifications the user name, the authentication hash function (sha256, sha384 and sha512) and the encryption algorithm (des or aes) should be specified. According to the security level required by the SNMP-v3 receiver, an authentication password and possibly a privacy encryption password should be specified. If the receiver does not require those security levels just omit related parameters in the command. Please note that when passwords are specified they must be at least 8 characters long.

To check the connectivity with SNMP receivers you can send testing traps to all configured receivers by using the admin snmp trap test command. Please note that the new configuration should be applied using the command apply before being able to send testing traps.

The following is a brief description of some notifications sent by the system:

• During the installation, the system reserves the required space on HDDs to store different logs based mainly on users number and reverse websites. If a log file abnormally grows too quickly (maybe because the system is under a DoS attack) an SNMP trap is sent to notify that misbehaviour.

• During the installation, the system reserves required space for different filesystems according to the HDDs capacities so the system should never have a lack of space on disks. If for any reason (maybe an introduced bug) a filesystem’s free disk space falls below the threshold of 5%, an SNMP trap is sent to notify that misbehaviour.

• All network links are monitored so in case of a link up or down an SNMP trap is sent to notify that change.

• The load average of the system is continuously monitored and average loads for the past 5 and 15 minutes are calculated. If averages exceed the thresholds of 99% and 95% respectively for the past 5-minutes and 15-minutes, an SNMP trap is sent to notify that overload.

• All essential services are monitored so in case of a failure, disruption or lack of hardware resources to start enough related system processes to support the load an SNMP trap is sent to notify the disruption.

• A health checker service continuously examines all vital services and in case of a service failure, tries to restart it. In that case an SNMP trap is sent to notify that action. After the attempt to restart the service, another SNMP trap is sent to notify the result of that operation (failure or success). Finally if the High Availability mode is activated (see the command "mode ha") and the attempt to restart the service fails, an SNMP trap is sent to notify the failure. In this case all VRRP interfaces are shut down to explicitly remove the failed node from the pool of HA nodes.

• During URL lists auto loading if one or more URL list files can’t be loaded an SNMP trap is sent to notify the failure.

• If the antivirus mode is activated and the virus signature data base is outdated by more the one day an SNMP trap is sent to notify the dysfunction.

• If the hardware hosting system have HDDs with SMART (Self-Monitoring, Analysis and Reporting Technology) capapabilities, they are monitored and in case of failures on HDDs notifications are sent.

• If the system has been installed with software RAID capabilites, the RAID is monitored and in case of failures on HDDs notifications are sent.

• If a USB Ethernet adapter is plugged or unplugged the system sends an SNMP trap. A similar SNMP trap is sent during the appliance startup if a NIC is added to or removed from the system.

• If the IP routing table contains multi gateways routes, the system sends an SNMP trap in case of unavailability of those gateway.

The system supports known MIBs used to monitor Linux systems and also a dedicated MIB called CACHEGUARD-MIB. You can find the ASN.1 MIB description of the CacheGuard MIB on the original installation CDROM or on the official CacheGuard website.


access (1) apply (1) file (1) mode (1) password (1) system (1) tls (1) vlan (1) vrrp (1)


CacheGuard Technologies Ltd <>

Send bug reports or comments to the above author.


Copyright (C) 2009-2024 CacheGuard - All rights reserved