Security

This section contains the answers to commonly asked security related questions.

How are the Netrix secured

•To log on to the turret and make calls a valid User Id and PIN must be entered. Note the TSS can be configured to lock the user out after X failed logins.

•To SSH to the turret a valid Linux account username/password must be entered.

•To change any configuration via the turrets web diagnostics a valid HTTP username/password must be entered.

Authentication method

•At boot up the turret authenticates as a device with the TSS using HTTPS/HTTP.

•When the user logs on with their User Id and PIN the turret authenticates the user with the TSS using HTTPS/HTTP.

•SSH access currently uses a predetermined Linux username/password.

•Web diagnostics access currently uses a predetermined HTTP username/password.

Protocol capability

•DHCP

•NTP

•FTP / FTPES – Legacy support as from 9.6 Netrix uses soley HTTP / HTTPS.

•HTTP / HTTPS

•SIP

•RTP / SRTP

•SNMP / AgentX

•SSH

Open Ports

•22/tcp (SSH)

•80/tcp (HTTP)

•443/tcp (HTTPS)

•705/tcp (SNMP / AgentX)

•5060/tcp (SIP)

 Known vulnerabilities

See the Nessus report provided with each Netrix release.

802.1x

Not supported, however beware if trying to set up NAC using the turrets MAC addresses to identify/allow the device. In which case NAC will need to allow the turret to establish a TCP connection to the TSS within 10 seconds, otherwise the turret will assume the TSS is unavailable and reboot as part of its recovery strategy.

TLS or Certificate management

• Web diagnostics uses a self-signed certificate so that site engineers can access the turrets diagnostics via HTTPS.

• Netrix can be configured to use TLS between itself and the TSS, and hence downloads a CA certificate from the TSS an adds it to its persisted ca-bundle.crt file (which can be reset by the security tab on the web diagnostics)