#title Stricter Defaults ## This is an ongoing work in progress. As more default settings are found that ## could be seen as insecure, new recommendations for changes to those settings ## can be added here. ||<>|| While Ubuntu comes secure and ready to use, many people decide to offer a wide range of services on their computer, such as running a FTP server or Apache. The purpose of this page is to advise these users on possible settings that could be changed to have an even stricter environment. Be warned that these recommendations are not always a good idea, as they can cause usability trade-offs that the Ubuntu Security Team has traditionally not agreed with. == Shared Memory == By default, `/run/shm` is mounted read/write, with permission to execute programs. In recent years, many security mailing lists have noted many exploits where `/run/shm` is used in an attack against a running service, such as `httpd`. Most of these exploits, however, rely on an insecure web application rather than a vulnerability in Apache or Ubuntu. There are a few reasons for it to be mounted read/write in specific configurations, such as real-time configuration of a Synaptics touchpad for laptops, but for servers and desktop installations there is no benefit to mounting `/run/shm` read/write. To change this setting, edit the `/etc/fstab` file to include the following line: {{{ none /run/shm tmpfs defaults,ro 0 0 }}} This will mount /run/shm in read-only mode. If you have a good reason to keep it writable, put this line in `/etc/fstab` instead: {{{ none /run/shm tmpfs rw,noexec,nosuid,nodev 0 0 }}} This will mount /run/shm writable, but without permission to execute programs, without permission to change the UID of running programs, or to create block or character devices in the namespace. The changes will take effect the next time you reboot, unless you remount /run/shm with the command `sudo mount -o remount /run/shm`. '''Note''': MANY programs will '''not''' work if you make `/run/shm` read-only (e.g. Google Chrome). Note also that on '''Ubuntu 8.10''', if you make `/dev/shm` read-only, then reboot, the `mount` command will show that `/dev/shm` has not been mounted as read-only and the output will look like this: `none on /dev/shm type tmpfs (rw,nosuid,nodev)` So `/dev/shm` must be remounted manually with the following command, in order for changes to take effect: {{{ sudo mount -o remount /dev/shm }}} == SSH Settings == While the SSH daemon is secure enough for most people, some may wish to further enhance their security by changing certain `sshd` settings. Some settings which could be changed to enhance security are given here. All changes, unless otherwise stated, are made in the `/etc/ssh/sshd_config` file. Lines with a pound sign (`#`) are commented and not read. To edit this file from a terminal: {{{ sudoedit /etc/ssh/sshd_config }}} For a Gnome editor, press Alt+F2 and use: {{{ gksudo gedit /etc/ssh/sshd_config }}} For a KDE editor, press Alt+F2 and use: {{{ kdesu kate /etc/ssh/sshd_config }}} Please remember, after making any changes, `sshd` must be restarted, which can be done from the terminal with this command: {{{ service ssh restart }}} On older versions, e.g. '''Ubuntu 8.10''', the above command might not work, so you may need to run this command instead: {{{ sudo /etc/init.d/ssh restart }}} === SSH Root Login === By default, the SSH daemon ships with remote root logins enabled. Normally Ubuntu does not allow direct access to the root user, so this setting is unimportant. If you have set a password on the root account, this setting can be a potential security risk, and should be disabled. To disable root login, edit the `/etc/ssh/sshd_config` file and replace the following line: {{{ PermitRootLogin yes }}} with this line: {{{ PermitRootLogin no }}} Sometimes it is necessary to allow root logins when doing automated tasks such as backups. To disallow normal logins but allow forced commands, you can use: {{{ PermitRootLogin forced-commands-only }}} See `man (5) sshd_config` for details. === SSH Login Grace Time === The login grace time is a period of time where a user may be connected and not begin the authentication process. By default, `sshd` will allow a connected user to wait for 120 seconds (2 minutes) before starting to authenticate. This could be used to conduct a Denial of Service (DoS) or a brute force attack against a running SSH daemon. One solution is lowering this to 20 seconds. This should be used in combination with iptables rules to reduce the number of SSH connection attempts, otherwise a DoS can be launched well within the login timeout. To change this, replace this line: {{{ LoginGraceTime 120 }}} with this line: {{{ LoginGraceTime 20 }}} === SSH Welcome Banner === The SSH daemon will allow a message to be displayed to users attempting to log in to the SSH server. To enable login messages, remove the pound sign from this line: {{{ #Banner /etc/issue.net }}} so it looks like this: {{{ Banner /etc/issue.net }}} Now, edit /etc/issue.net and place a warning to unauthorized users. The following is taken from the [[AdvancedOpenSSH| Advanced OpenSSH]] page and is modified from a U.S. Department of Defense warning banner. {{{ *************************************************************************** NOTICE TO USERS This computer system is the private property of its owner, whether individual, corporate or government. It is for authorized use only. Users (authorized or unauthorized) have no explicit or implicit expectation of privacy. Any or all uses of this system and all files on this system may be intercepted, monitored, recorded, copied, audited, inspected, and disclosed to your employer, to authorized site, government, and law enforcement personnel, as well as authorized officials of government agencies, both domestic and foreign. By using this system, the user consents to such interception, monitoring, recording, copying, auditing, inspection, and disclosure at the discretion of such personnel or officials. Unauthorized or improper use of this system may result in civil and criminal penalties and administrative or disciplinary action, as appropriate. By continuing to use this system you indicate your awareness of and consent to these terms and conditions of use. LOG OFF IMMEDIATELY if you do not agree to the conditions stated in this warning. **************************************************************************** }}} Once this is in place, restart `sshd` and all users will see this warning before they get the login prompt. This will obviously not dissuade automated SSH attacks, and will potentially worsen DoS effects, but it may tip off a human attacker that the system is being looked after closely, and that they should move on to some other system on the network. === SSH Allowed Users === By default, SSH will permit every user with an account to attempt to log in. PAM (the authentication system under SSH) already does not allow attackers to guess user accounts. However, if you have a set of users you want to never allow SSH access to, you can use the `AllowUsers` directive. To do this, add a line like this in your sshd configuration file: {{{ AllowUsers jsmith tallen }}} Or to limit access to a specific user from a specific ip address, use something like:{{{ AllowUsers jsmith@192.168.0.2 tallen }}} The `AllowUsers` directive is the list of all users that are allowed to log in through SSH. If you have a large number of users, or you intend to have a changing list of users, you can also use the `AllowGroups` directive and create a group specifically for users allowed to log in through SSH. You can add a group for this purpose with this command: {{{ sudo addgroup sshlogin }}} Using the example name of 'sshlogin', you would then add this line to your sshd configuration file: {{{ AllowGroups sshlogin }}} After you restart sshd, only users in the `AllowUsers` list (or users who are members of the 'sshlogin' group if you chose that method instead) will be allowed to log in through SSH. See `man (5) sshd_config` for details. === Disable Password Authentication === One may also tighten security by forcing public key authentication and disabling password authentication entirely. While this greatly enhances security and completely defeats brute-force attacks, it will lock you out of the machine if you lose your private key. Use with caution. On the client, generate a key pair with a strong passphrase using: {{{ $ ssh-keygen -t rsa -b 4096 Generating public/private rsa key pair. Enter file in which to save the key (/home//.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home//.ssh/id_rsa. Your public key has been saved in /home//.ssh/id_rsa.pub. The key fingerprint is: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx @ }}} Next, copy the above key to the machine you'd like to login to (this puts the key in `/home//.ssh/authorized_keys` on the server):{{{ $ ssh-copy-id -i /home//.ssh/id_rsa.pub @ }}} Verify you can login to the server with your new key:{{{ $ ssh @ Enter passphrase for key '/home//.ssh/id_rsa': @