(ve):Get started with Ubuntu
- This page was last modified on May 18, 2012, at 10:18.
From (mt) Community Wiki
Contents |
Keep in mind that your (ve) Server is very much a blank slate when provisioned. It is your responsibility to administer your server from Day 1. Following some of the information below will definitely help you on your way, with an emphasis on security. After completing this guide, you will probably want to install some software. Following our LAMP guide would be a great way to get your feet wet.
Logging in as root
By default, all of the distributions offered with your (ve) Server have only the root user installed. For security reasons, we do not include the root password in your Service Activation Letter. To obtain the root user password, you will need to visit the "SSH Access" section of your (ve) Control Panel in the AccountCenter. Then you can change the password to one you know.
After you change the password, you can simply use an SSH client to connect to your server using your new password and root as the user.
Once connected, you will have root access to your server.
Adding a User
For security reasons, we strongly encourage setting up an "admin" user that has 'sudo' privileges. With 'sudo' you can give selected users temporary "root" privileges. This is a good safeguard to prevent misuse of the root user. Follow the steps below to add a user with sudo access:
Log into your (ve) as root via ssh.
ssh@root@Your.IP.Goes.Here
Create the new user. We will use the name jsmith as an example
root@ve: adduser jsmith
We now need to grant jsmith sudo privileges using the visudo command.
root@ve: visudo
This will launch the '/etc/sudoers' file for editing. Using root as an example just add another line for jsmith and save the file using ctrl-O (and ctrl-x to exit editing the file):
# /etc/sudoers # # This file MUST be edited with the 'visudo' command as root. # # See the man page for details on how to write a sudoers file. # Defaults env_reset # Host alias specification # User alias specification # Cmnd alias specification # User privilege specification root ALL=(ALL) ALL jsmith ALL=(ALL) ALL # Uncomment to allow members of group sudo to not need a password # (Note that later entries override this, so you might need to move # it further down) # %sudo ALL=NOPASSWD: ALL
To test your new user and sudo privileges, logout as root and log back in as jsmith.
Now that you have sudo enabled you can simply run any command typically run by root as the jsmith user. Just add sudo to the beginning of your command. You will be prompted to enter your password.
Updating Your Server
It is very easy to keep your Ubuntu server up to date using the apt-get packaging system. This system uses a private database to keep track of which packages are installed, which are not installed, and which are available for installation. The apt-get program uses this database to find out how to install packages requested by the user, and to find out which additional packages are needed in order for a selected package to work properly.
Because /tmp is mounted as noexec and to avoid errors with the apt-get tool, you will need to relocate the temporary directory it's using. (ve):Configure apt.
To keep this database current run the following command:
jsmith@ve:~#sudo apt-get update
This command looks for the package lists in the archives found in '/etc/apt/sources.list'. It's a good idea to run this command regularly to keep yourself and your system informed about possible package updates, particularly security updates. You should see output similar to:
Hit http://archive.ubuntu.com intrepid Release.gpg Hit http://archive.ubuntu.com intrepid-updates Release.gpg Hit http://archive.ubuntu.com intrepid-security Release.gpg Hit http://archive.ubuntu.com intrepid Release Hit http://archive.ubuntu.com intrepid-updates Release Hit http://archive.ubuntu.com intrepid-security Release Hit http://archive.ubuntu.com intrepid/main Packages Hit http://archive.ubuntu.com intrepid/restricted Packages Hit http://archive.ubuntu.com intrepid/universe Packages Hit http://archive.ubuntu.com intrepid-updates/main Packages Hit http://archive.ubuntu.com intrepid-updates/restricted Packages Hit http://archive.ubuntu.com intrepid-updates/universe Packages Hit http://archive.ubuntu.com intrepid-security/main Packages Hit http://archive.ubuntu.com intrepid-security/restricted Packages Hit http://archive.ubuntu.com intrepid-security/universe Packages Reading package lists... Done
After updating your database you can simply install all available updates with:
jsmith@ve:~#sudo apt-get -u upgrade
APT will then download the latest versions of each package and will install them in the proper order, taking care of all dependencies.
This is just a general overview of keeping your server updated. For more information we strongly suggest Debian's authoritative page on package management. This page would apply to Ubuntu as well.
Installing Developer Tools
(ve) distributions do not have any developer tools installed by default. All developer tools, including GCC C/C++ compilers, make and others, can easily be installed using the apt-get command. There is a convenient meta-package called 'build-essential' that will install all the Developer Tools with just one command.
Run the following command to begin:
jsmith@ve:~#sudo apt-get update && sudo apt-get install build-essential
You will see text scroll by as the server determines what packages need to be installed. A base install should output the following packages to be installed/updated. Please enter 'Y' for yes when prompted. At this time all the packages will be downloaded and installed. There is no need to reboot your server. All changes are made live on the server. Please take note of any warnings displayed and act accordingly.
Get:1 http://archive.ubuntu.com intrepid Release.gpg [189B] Get:2 http://archive.ubuntu.com intrepid-updates Release.gpg [189B] Get:3 http://archive.ubuntu.com intrepid-security Release.gpg [189B] Get:4 http://archive.ubuntu.com intrepid Release [65.9kB] Get:5 http://archive.ubuntu.com intrepid-updates Release [51.2kB] Get:6 http://archive.ubuntu.com intrepid-security Release [51.2kB] Get:7 http://archive.ubuntu.com intrepid/main Packages [1254kB] Get:8 http://archive.ubuntu.com intrepid/restricted Packages [8420B] Get:9 http://archive.ubuntu.com intrepid/universe Packages [4516kB] Get:10 http://archive.ubuntu.com intrepid-updates/main Packages [344kB] Get:11 http://archive.ubuntu.com intrepid-updates/restricted Packages [8444B] Get:12 http://archive.ubuntu.com intrepid-updates/universe Packages [111kB] Get:13 http://archive.ubuntu.com intrepid-security/main Packages [133kB] Get:14 http://archive.ubuntu.com intrepid-security/restricted Packages [3870B] Get:15 http://archive.ubuntu.com intrepid-security/universe Packages [57.0kB] Fetched 6604kB in 3s (1693kB/s) Reading package lists... Done Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: dpkg-dev g++ g++-4.3 gcc gcc-4.3 libc6-dev libstdc++6-4.3-dev libtimedate-perl linux-libc-dev patch Suggested packages: debian-keyring g++-multilib g++-4.3-multilib gcc-4.3-doc libstdc++6-4.3-dbg gcc-multilib manpages-dev autoconf automake1.9 libtool flex bison gdb gcc-doc gcc-4.3-multilib libmudflap0-4.3-dev gcc-4.3-locales libgcc1-dbg libgomp1-dbg libmudflap0-dbg glibc-doc libstdc++6-4.3-doc diff-doc The following NEW packages will be installed: build-essential dpkg-dev g++ g++-4.3 gcc gcc-4.3 libc6-dev libstdc++6-4.3-dev libtimedate-perl linux-libc-dev patch 0 upgraded, 11 newly installed, 0 to remove and 16 not upgraded. Need to get 13.0MB of archives. After this operation, 43.7MB of additional disk space will be used. Do you want to continue [Y/n]
Securing Your Server
This guide is a general overview of how to get started with your (ve) Server. It covers a good general overview of basic security philosophy and a number of specific examples of how to better secure your (ve) Virtual-Environment server when first getting started. If you have any improvements, constructive criticism, additions, or corrections, please feel free to provide feedback on the discussion page.
(Optional) Expiring Passwords
When creating user accounts, you might want to consider expiring passwords after a given amount of time. This will force you and your users to change passwords every so often.
To easily view the current status of a user account, use the following syntax:
jsmith@ve:~#sudo chage -l jsmith
The output below shows interesting facts about the user account, namely that there are no policies applied:
Last password change : Aug 13, 2009 Password expires : never Password inactive : never Account expires : never Minimum number of days between password change : 0 Maximum number of days between password change : 99999 Number of days of warning before password expires : 7
To set any of these values, simply use the following syntax, and follow the interactive prompts:
jsmith@ve:~#sudo chage jsmith
The following example will set a maximum password age (-M) of 90 days and a warning time period (-W) of 14 days before password expiration.
jsmith@ve:~#sudo chage -M 90 -W 14 jsmith
To verify changes, use the same syntax from above:
jsmith@ve:~#sudo chage -l jsmith
The output below shows the new policies that have been established for the account:
Last password change : Aug 13, 2009 Password expires : Nov 11, 2009 Password inactive : never Account expires : never Minimum number of days between password change : 0 Maximum number of days between password change : 90 Number of days of warning before password expires : 14
Disabling Root Login
Allowing the root user to login directly via ssh is a major security issue. You can still use the root account after logging in as another user first.
SSH into your server as 'jsmith' Open the /etc/ssh/sshd_config file using your editor of choice. We will use nano.
jsmith@ve:~#sudo nano /etc/ssh/sshd_config
Change the PermitRootLogin directive on Line 26 to 'no':
... 21 SyslogFacility AUTH 22 LogLevel INFO 23 24 # Authentication: 25 LoginGraceTime 120 26 PermitRootLogin no 27 StrictModes yes ...
Save the file and make sure to restart the SSH server:
jsmith@ve:~#sudo /etc/init.d/ssh restart
Please note that you will no longer be able to login directly as root unless you revert these changes. Make sure you remember both passwords moving forward.
Securing SSH
Using SSH Keys
SSH keys should only be used on a computer that is not shared, or one that has multiple logins or accounts. If you share your computer with others under the same username you should NOT follow the steps outlined in this article.
Generating your key
The first step we need to take is generating a key on your local computer using strong encryption:
jsmith@ve:~#ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa -C "Enter an optional comment about your key"
You should receive a prompt asking for a password. Please use a strong password. If you plan on using your key for automated tasks that don't require interaction, such as rsync, you might want to leave this blank. Once you have entered your password twice make sure you have the permissions set properly for your .ssh directory and your newly created ssh files on your local computer using the following commands:
jsmith@ve:~#chmod 700 ~/.ssh
jsmith@ve:~#chmod 600 ~/.ssh/*
Installing your key
Your public key now needs to be uploaded to your server. The code below reads the content of your key, creates your ssh directory on your (ve), and creates a new file called 'authorized_keys' with the same information.
jsmith@ve:~#cat ~/.ssh/id_rsa.pub | ssh user@ve.example.com 'mkdir ~/.ssh;cat - >> ~/.ssh/authorized_keys'
We should also change the permissions for the ssh directory and files as we did up above. On your (ve) run the same commands:
jsmith@ve:~#chmod 700 ~/.ssh
jsmith@ve:~#chmod 600 ~/.ssh/*
Changing default SSH Port
By default SSH uses the standard port 22 for all connections. To help prevent malicious automated attacks on this port it is best to use a non-standard port. Please note that you will have to use the '-p' flag with the ssh command to specify the port you choose. SSH into your server as 'jsmith' Open the /etc/ssh/sshd_config file using your editor of choice. We will use nano.
jsmith@ve:~#sudo nano /etc/ssh/sshd_config
Change Line 5 to use your new port number. In the example we will use 4791. Please make sure to choose a port higher than 1024 to prevent conflicts with reserved port numbers:
... 1 # Package generated configuration file 2 # See the sshd(8) manpage for details 3 4 # What ports, IPs and protocols we listen for 5 Port 4791 6 # Use these options to restrict which interfaces/protocols sshd will bind to 7 #ListenAddress :: 8 #ListenAddress 0.0.0.0 ...
Save the file and make sure to restart the SSH server:
jsmith@ve:~#sudo /etc/init.d/ssh restart
Using iptables
iptables is a powerful firewall that comes pre-installed with Ubuntu. Using iptables you can lock down your server, allowing access based on port numbers and IP addresses. Although you can create very sophisticated rules for your server, this brief introduction will just show you how to only allow access to ports 80/443 (http/https) and port 22, the default port for ssh. We will elaborate more on iptables usage in future articles.
Defining your rules
Out of the box you can see that no rules are defined by running:
jsmith@ve:~#sudo iptables -L
You should see very minimal output:
Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
As you can see we are allowing all traffic in and out of the server. We will need to create a file that includes new rules to only allow certain ports.
Create a file using your favorite text editor named iptables.rules in the /etc directory.
jsmith@ve:~#sudo nano /etc/iptables.rules
Once inside the editor place the following code and save the file (do not forget to change port number if you have previously changed default SSH port 22 (4791 etc.):
*filter # Allow loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use the lo0 interface -A INPUT -i lo -j ACCEPT -A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT # Accept established inbound connections -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Allow all outbound traffic -A OUTPUT -j ACCEPT # Allow HTTP and HTTPS connections -A INPUT -p tcp --dport 80 -j ACCEPT -A INPUT -p tcp --dport 443 -j ACCEPT # Allow SSH # Change the value 22 if you are using a non-standard port -A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT # Allow ping requests # Some might want to block this altogether. -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT # Reject all other inbound - default deny unless explicitly allowed policy -A INPUT -j REJECT -A FORWARD -j REJECT COMMIT
Now that we have our rules in place let's test them. Using the iptables-restore command we can load these rules:
jsmith@ve:~#sudo iptables-restore < /etc/iptables.rules
We can now verify the rules using the same command above:
jsmith@ve:~#sudo iptables -L
You should see the following output:
Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere REJECT all -- anywhere 127.0.0.0/8 reject-with icmp-port-unreachable ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere tcp dpt:www ACCEPT tcp -- anywhere anywhere tcp dpt:https ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh ACCEPT icmp -- anywhere anywhere icmp echo-request REJECT all -- anywhere anywhere reject-with icmp-port-unreachable Chain FORWARD (policy ACCEPT) target prot opt source destination REJECT all -- anywhere anywhere reject-with icmp-port-unreachable Chain OUTPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere
Once you have verified your rules you can save them. See the next section for ensuring these rules run at boot time. You need to be logged in as root to run this command, so if you have disabled root, you will need to temporarily re-enable the root account (do not forget to restart SSS server after).
root@ve:~#iptables-save > /etc/iptables.rules
If you have saved your new rules you can disable root user again and restart SSH.
Making your rules permanent
Now that we have our rules in place we need to configure the server to load these rules upon reboot. This is very easily done using the file we already created. We will need to edit the template file 'etc/network/interfaces.template' which contains network interface configuration info for your server.
jsmith@ve:~#sudo nano /etc/network/interfaces.template
Add line 3 below to your file:
1 auto lo 2 iface lo inet loopback 3 pre-up iptables-restore < /etc/iptables.rules 4 address 127.0.0.1 5 netmask 255.0.0.0 6 broadcast 127.255.255.255 7 up ip route replace 127.0.0.0/8 dev lo
Now that we have our rules defined and configured to run on boot we should do one last test. Reboot your server and make sure your rules are loaded.
jsmith@ve:~#sudo reboot