Administration services

Conﬁguring administration IP addresses

Unrestricted access to the firewall’s administration interfaces raises the risk of intrusion attempts and of the firewall being controlled by other appliances that have obtained illegal access to it.

R11 | Define administration sub-networks clearly
The IP addresses or administration sub-networks allowed to access an appliance’s administration interfaces should be explicitly defined in System > Configuration > Firewall administration.

These IP addresses and administration sub-networks must be configured using specific objects placed together in an object group. In line with chapter Filter policy, the use of such groups makes it possible to better manage permissions consistently with filter rules.

R12 | Use an administrator object group
The use of object groups is recommended, containing all sub-networks and IP addresses allowed to manage the firewall.

Dedicated administration interface

Sharing an administration interface with the production network increases the number of individuals and appliances with access to the firewall’s administration interface, and also increases the volume of traffic that the interface must handle. As a result, this raises the risk of the administration interface being attacked or unreachable. Moreover, using VLANs does not guarantee airtight access between the configured networks.

R13 | Dedicate an Ethernet interface to administration
SNS appliances should be managed on a dedicated Ethernet interface connected to an administration network also dedicated to such operations. The filtering applied must be as restrictive as possible.

The ANSSI guide Recommendations on the secure administration of information systems (in French) sets out the recommended measures regarding the secure administration of information systems.

Security on the web administration interface

Security on the web administration interface contributes to the security of the appliance by protecting the confidentiality and integrity of legitimate administration traffic.

By default, sslparanoiac mode is enabled, imposing the use of TLS 1.2 and robust cryptographic suites. The TLS settings of the web administration interface can be checked using the NSRPC command config auth show. The cryptographic suites suggested by default are:

ECDHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
DHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES256-SHA256

R14 | Keep default cryptographic suites
Keeping the default conﬁguration of cryptographic suites facilitates compliance with the ANSSI’s Security recommendations relating to TLS (in French) and Appendix B1 of the ANSSI’s RGS.

INFORMATION
A recent Internet browser is required for the use of TLS 1.2 and robust cryptographic suites.

R14 + | Harden TLS parameters on the administration interface
Users are advised to keep only TLS suites with ECDHE as recommended in the guide Security recommendations relating to TLS (in French).

Cryptographic suites can be restricted using the NSRPC command:

config auth https cipherlist="ECDHE-RSA-AES128-GCM-SHA256,ECDHE-RSA-AES128-SHA256,ECDHE-RSA- AES256-GCM-SHA384,ECDHE-RSA-AES256-SHA384"
config auth activate

Changing the certificate of the web administration interface

By default, the certiﬁcate presented to administrators when they connect to the web administration interface is a certificate signed by the Netasq CA. As such, there is no control over the criteria for generating the private key used, or how it can be used.

R15 | Replace the web interface certiﬁcate
The certiﬁcate of the web administration interface should be replaced with a certiﬁcate issued by a controlled PKI to strengthen the security involved in accessing it.
Refer to the ANSSI’s General Security Guidelines (in French), in particular appendices A4 and B1.

The server certificate configuration used by the SNS web administration interface can be configured in Configuration > System > Configuration > Firewall administration > Configure the SSL certificate of the service.

INFORMATION
To allow administrators to authenticate the appliances they are connecting to, the public key of the CA that signed the certificate must be in the certificate store of the browser that administrators use.

Administration via NSRPC

During direct connections to the NSRPC server, the firewall requires read-only access to the user’s password hash (this information is required for the authentication protocol to function properly). If the firewall’s access to the directory is hijacked, all saved password hashes may then be compromised. The hash is a critical component, as brute force attacks can compromise passwords. The use of such accounts in the information system must therefore be monitored (connections from another appliance, illegal requests, etc.).

An NSRPC console is available from the web interface. Access to this console does not require additional authentication. Hashes do not need to be accessed.

R16 | Use NSRPC from the web interface
NSRPC commands should only be used from System > CLI console in the web interface.

R16 ⁃ | Use accounts dedicated to direct NSRPC connections
During direct access to the NSRPC console, dedicated accounts are recommended for this purpose, and only the hashes of these accounts on the remote directory should be exposed.

INFORMATION
By default, Active Directory and OpenLDAP directories do not allow password hashes to be read.

Localization features

Several localization features can be found on the appliance:

Web interface language, which can be selected in the connection window,
Keyboard layout of the console, which can be configured in System > Configuration,
Language in which logs are generated, which can be conﬁgured in System > Configuration.

The language in which logs are generated changes the messages displayed in the Dashboard and in local and remote log files. The language chosen affects:

How users understand log files,
Patterns that monitoring systems look for,
The types of searches conducted in the knowledge base on the vendor’s website.

All existing messages are listed in Notifications > System events and their translations are available on the appliance in the /usr/Firewall/System/Language/ folder. Every generated message bears an index number associated with the corresponding error. This number is the same in all translations.

R17 | Use the same language in logs
The same language should be configured for all logs on all SNS appliances. This will make it easier to read them and integrate them into monitoring tools.

R18 | Use a language that users understand
Appliances must be configured in a language that users understand.

INFORMATION
Most of the pages in Stormshield’s knowledge base are written in English. This base can be accessed from Stormshield’s personal area.