Tip
This is the documentation for the 19.02 version. Looking for the documentation of the latest version? Have a look here.
- orphan:
Default Behavior¶
After the installation completes and TNSR boots for the first time, TNSR has an empty default configuration. This means that TNSR has no pre-configured interfaces, addresses, routing behavior, and so on.
The host OS defaults are set during installation, and depend on the base OS, CentOS 7.4. For example, host management interfaces may have been configured by the installer.
Default Accounts and Passwords¶
By default, the TNSR installation includes host OS accounts for root
with
interactive login disabled, and a tnsr
account.
For ISO installations, the best practice is to create at least one additional initial administrator account during the installation process. That user is custom created by the person performing the installation, and thus is not a common default that can be listed here.
Warning
When installing TNSR from an ISO image, the installer allows the
root
account to be unlocked and assigned a password. The best practice,
however, is to leave the root
account locked and create at least one
additional administrator account using the installer. These additional
accounts may use sudo
to elevate privileges. Any users added to the
wheel
group later may also use sudo
to execute commands as root
.
The default behavior of the tnsr
account varies by platform:
- ISO/Bare Metal:
Login for the
tnsr
user is disabled until its password is reset by an administrator.- Appliances Shipped with TNSR Pre-installed:
The
tnsr
user is available with a default password oftnsr-default
.- AWS:
The
tnsr
account is present but restricted to key-based authentication via ssh, using a key selected when launching the TNSR instance.- Azure:
The
tnsr
account is present but restricted to key-based authentication via ssh, using a key selected when launching the TNSR instance.
The password for the tnsr
account can be reset by any other account with
access to sudo
. For example, the command sudo passwd tnsr
will prompt to
set and confirm a new password for the tnsr
user. The same action may also
be performed for the root
account (sudo passwd root
). As mentioned in the
previous warning, it is best to leave interactive logins for root
disabled.
Warning
Change default passwords, even randomized default passwords or passwords pre-configured when launching a cloud-based instance, after the first login. Do not leave default passwords active!
Note
User authentication is performed by the host OS. Though users may be created inside TNSR (User Management), these users are propagated to the host. To control what users may access, see NETCONF Access Control Model (NACM).
Default TNSR Permissions¶
By default, there is no TNSR configuration present. As such, there are no pre-configured access permissions for users to restrict access to TNSR. Thus, any operating system user on the TNSR host will be able to reach the TNSR CLI and make changes.
To restrict which accounts have access to TNSR, see NETCONF Access Control Model (NACM).
Default Allowed Traffic¶
For the default behavior of allowed traffic to and from TNSR, there are two separate areas to consider:
Traffic flowing through TNSR
Traffic for the host OS management interface
TNSR¶
By default, there is no TNSR configuration present. As such, there are no default access lists (ACLs) and once TNSR is able to route traffic, all packets flow freely. See Access Lists for information on configuring access lists.
Host OS¶
The TNSR installation configures a default set of Netfilter rules for the host OS management interface. The following traffic is allowed to pass into and out of the host operating system interfaces:
ICMP / ICMP6
ssh (TCP/22)
HTTP (TCP/80)
HTTPS (TCP/443)
BGP (TCP/179)
ISAKMP (UDP/500)
NTP (UDP/123, TCP/123)
DNS (UDP/53, TCP/53)
SNMP (UDP/161)
DHCP Server (UDP/67)
UDP Traceroute (UDP ports 33434-33524 with TTL=1)
Future versions of TNSR will include the ability to manage the host OS Netfilter rules.