|
     |
The configuration of Tectia Server typically sets limitations on secure system administration. Tectia Server often resides in the DMZ. Strong two-factor authentication is often required from privileged users and connections are allowed only from certain hosts.
Restrictions on Secure Shell services, as described for non-privileged users in Restricting Services, do not prevent users with shell access to the system from setting up the equivalent services.
It is also possible to limit users with administrative privileges to predefined commands if shell access is not needed.
Shell access is often desired for remote administration of the server computer. It is
recommended to have users log in first to their non-privileged user accounts and once logged
in elevate their rights using sudo or su especially if the
root account is used instead of individual administrator accounts.
The following configuration setup prevents logging directly in to the privileged accounts:
<authentication-methods>
<authentication action="deny">
<selector>
<user-privileged value="yes" />
</selector>
</authentication>
...
</authentication-methods>
Tectia Server can be configured to reject connection attempts from unknown hosts. For example
the following allows connections only from the internal network 10.1.0.0/8 IP
addresses and from an external host with the IP address 195.20.116.1:
<connections>
<connection action="allow">
<selector>
<ip address="10.1.0.0/8" />
<ip address="195.20.116.1" />
</selector>
</connection>
<connection action="deny" />
</connections>
Using the Tectia Server Configuration GUI, the same settings can be made under the Connections and Encryption page, on the Selectors tab. See Editing Connection Rules.
For information on the selectors, see Using Selectors in Configuration File.
On systems with several network interfaces, Tectia Server can also be bound to a specific
network interface so that the server can be only accessed from the intended network. For
example, the following will bind the listener to address 10.1.60.25 using the
Secure Shell default port 22:
<params> <listener id="intranet" address="10.1.60.25" /> ... </params>
Using the Tectia Server Configuration GUI, this can be set on the Network page. See Network.
By default, file access by users is restricted by the file system access controls. On
Unix, access can be further restricted with the usage of the chroot attribute.
The chroot attribute can be used with the subsystem,
terminal, and command elements.
The chroot attribute must be a directory path. Values
%username%, %homedir%, and %hostname% will be
substituted with the user name, user's home directory, and the FQDN of the connected client,
respectively. The values are read from the environment variables defined in the system.
The following sections give instructions on chrooting the terminal, remote commands, and subsystems.
An example of chrooting the terminal is shown below:
<services>
<rule>
<terminal action="allow" chroot="%homedir%" />
...
</rule>
...
</services>When users are restricted to the chrooted environment, they cannot access the normal
shell binary. This means that the shell specified in the /etc/passwd file for
the user has to be present in the equivalent place under the chrooted directory. For
example, if /etc/passwd lists /bin/bash as the shell and the
user is chrooted to the home directory, a statically linked
%homedir%/bin/bash should exist.
If the user's shell is dynamically linked, you must make sure that the required shared
libraries are also in the chrooted environment. You can resolve the dependencies with the
ldd command:
$ ldd /bin/bash
libtermcap.so.2 => /lib/libtermcap.so.2 (0x40026000)
libdl.so.2 => /lib/libdl.so.2 (0x4002a000)
libc.so.6 => /lib/libc.so.6 (0x4002d000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$ ls lib
ld-linux.so.2 libc.so.6 libdl.so.2 libtermcap.so.2 libtermcap.so.2.0.8
Also note that shared libraries can have other dependencies:
$ ldd libtermcap.so.2.0.8
libc.so.6 => /lib/libc.so.6 (0x40017000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
The user's environment might also need some other tools, such as:
ls for listing files
stty for setting tty modes
You might also need some device files under the user's virtual root directory. At
least a /dev/null file is needed on Linux. You can create it as
follows:
$ mkdir dev $ cd dev $ ls -l /dev/null crw-rw-rw- 1 root root 1, 3 Jan 30 2003 /dev/null $ mknod null c 1 3 $ chmod go+w null $ ls -l null
An example of chrooting a remote command is shown below:
<services>
<rule>
<command application="date" action="allow" chroot="%homedir%" />
...
</rule>
...
</services>Now, the user is restricted to the home directory when running sshg3 with
the remote command date:
$ sshg3 user@server date
The command to be run has to be statically linked and available under the chrooted
environment. In the above example when the user is chrooted to the home directory, a
statically linked date command should exist in
%homedir%/bin.
If the command is dynamically linked, you must make sure that the required shared libraries are also in the chrooted environment. See Chrooting Terminal above.
By default, file access by the user using the SFTP subsystem is restricted by the file
system access controls. On Unix, access can be further restricted with the usage of the
chroot attribute.
An example of chroot usage is shown below:
<services>
<rule>
<subsystem type="sftp"
application="sft-server-g3"
action="allow"
chroot="/home/%username%" />
...
</rule>
...
</services>Here %username% will be substituted with the current user name. For a
user named example, the path would be /home/example. During an
SFTP session, the user is now restricted to this directory (and its
subdirectories).
![[Note]](images/note.gif) | Note |
|---|---|
Chrooting the SFTP subsystem affects both SFTP and SCP2 operations to the server,
but it does NOT affect legacy OpenSSH-style SCP operations.
To chroot also OpenSSH SCP (version 8 and older), you
should chroot the |
A forced command causes a specified application to run automatically when the user logs in. All other applications are implicitly denied.
If you have maintenance jobs requiring non-interactive access to your server, use public-key authentication and forced commands. This way, if the private key is compromised, the public key cannot be used to perform anything other than the predetermined command on the server. This is, of course, also bad, but it would be worse if the malicious attacker would have unrestricted access to the machine.
Do not use the root (administrator) account for jobs where it is not absolutely necessary.
You can set up a forced command in the ssh-server-config.xml file.
<services>
<rule group="backup">
<terminal action="deny" />
<!-- This account is only used to backup the disk drive. -->
<subsystem type="sftp" application="sft-server-g3" action="deny" />
<command application="dd if=/dev/hda" action="forced" />
<tunnel-local action="deny" />
<tunnel-remote action="deny" />
</rule>
...
</services>
This would, on a successful login as the group backup, force a backup job
to start.
Using the Tectia Server Configuration GUI, the same setting can be made under the Services page on the Commands tab. See Commands.
You can also use the command that was given on the sshg3 command
line:
<services>
<rule group="admin">
<command application="echo $SSH2_ORIGINAL_COMMAND" action="forced" />
...
</rule>
...
</services>
Running sshg3:
$ sshg3 localhost kukkuu kukkuu $
| |