By default, the only externally accessible service running on the VPSLink installation of Gentoo is sshd. Other software gets installed, but it isn't running by default. Some configuration will be necessary to prepare the system for use after it is installed.
The first thing to do once the installation has finished is to log into your Gentoo machine. To do so, you should use a compatible ssh client. You can use PuTTY on Windows, Terminal on Mac OS X, and most Unix installations come with a capable ssh client.
Once in, you'll notice that the server is pretty minimalist. The following steps should be taken to configure the site:
The password for your server is set during the installation based on what you provided for the control panel. This password, while better than nothing, isn't really secure. The password requires the first character be a lower case character, and the only special characters allowed are the hyphen ("-") and underscore ("_"). Your password should be set to something that is easy to remember but difficult to guess, which means it should be fairly long (more than 8 characters) and should use as much keyspace as required, including lower-case characters, upper-case characters, numbers, and special characters (all the stuff on the keyboard that isn't a lower-case or upper-case character or number.)
Setting your password is easy using the passwd tool:
blah ~ # passwd New UNIX Password: <PASSWORD> Retype New UNIX Password: <PASSWORD> passwd: Password Updated Successfully blah ~ #
It just isn't safe using the root account for everything. From a security best-practices standpoint, allowing folks to access your system as root is a really bad practice. You'll want to add user accounts that you, and your users, will use to access the system. Once these accounts are created, it is always a good idea to lock down your services so that they don't allow root to even log in. You and your users will instead use the "su" command to access the root account when they need access.
Like the other Linux distributions, to add a user, you would use the "useradd" command, as demonstrated below:
blah ~ # useradd -m -g users -G wheel -s /bin/bash john blah ~ # passwd john New UNIX Password: <PASSWORD> Retype New UNIX Password: <PASSWORD> passwd: Password Updated Successfully
Useradd has a number of really helpful options:
|-c, --comment||A text string which is included in the comment field of the user's record.|
|-d, --home||The user's home directory, usually /home/<user id>.|
|-m, --create-home||This option tells useradd to create a home directory for the user if it doesn't already exist.|
|-u, --uid||The numerical value of the user's ID.|
|-s, --shell||The name of the user's default login shell, usually /bin/bash.|
|-g, --gid||Initial group that the user will be added to.|
|-G, --groups||A list of other groups the user is also a member of.|
|-e, --expiredate||On what date in the future should the user's account be disabled.|
|-f, --inactive||The maximum number of days of inactivity before the account is disabled. This is in addition to the system maximum password age setting, so a setting of 0 means that when the user hasn't changed their password before the password ages out, then the account is disabled.|
|-b, --base-dir||The base directory for users on a system, usually /home. Not necessary if -m is used. If -d is not specified, the system will take the user's id and concatenate it with the base directory for the user directory.|
Other options exist for useradd, but they aren't as frequently used. You can find all of the options for useradd by reading the useradd manual page, by typing 'man useradd'
Make sure that you add any user that you create that you want to be able to log into the root account using "su" to the wheel group, otherwise you will not be able to do so.
If you prefer not to mess around with useradd (which is completely understandable,) there is a nice program available in the Portage Tree that works as a front-end to useradd. The superadduser program will ask you all of the necessary questions and configure the user account for you. You will need to install superadduser before you can use it, by running the command below:
blah ~ # emerge superadduser
Once installed, just run it. Everything listed in brackets are the defaults that superadduser will use to create the account. To choose the default, just press the Enter/Return key.
blah ~ # superadduser Login name for new user : john User ID ('UID') [ defaults to next available ]: Initial group [ users ]: Additional groups (comma separated) : wheel Home directory [ /home/john ] Shell [ /bin/bash ] Expiry date (YYYY-MM-DD) : New account will be created as follows: --------------------------------------- Login name.......: john UID..............: [ Next available ] Initial group....: users Additional groups: wheel Home directory...: /home/john Shell............: /bin/bash Expiry date......: [ Never ] This is it... if you want to bail out, hit Control-C. Otherwise, press ENTER to go ahead and make the account. Creating new account... Changing the user information for john Enter the new value, or press ENTER for the default Full Name : John P. Juanes Room Number : Work Phone : Home Phone : Other : New UNIX password: Retype new UNIX password: passwd: password updated successfully Account setup complete.
Make sure that you add any user that you create that you want to be able to log into the root account using "su" to the wheel group, otherwise you will not be able to do so.
By default, sshd allows anyone who knows the root userid and password access to the system. This can be dangerous, especially if someone manages to discover your root password. With the root account, the user has complete control over your system. Plus, with the root account, it is basically an anonymous account, as it can be shared among users. It is better to lock down sshd to not allow root to log in, thus forcing your users to log in as themselves, and then switch over to the root account once they log in using the "su" command.
To accomplish this, sshd includes an option within its configuration file (/etc/ssh/sshd_config) to tell the sshd server not to allow root to log in. This option ("PermitRootLogin no") is disabled by default, but to enable it you should remove the hash sign ('#') in front of it. Make sure that you have created user accounts and added them to the wheel group before you do this; otherwise you will not be able to log in anymore.
Once you have changed the file, restart the service, as shown below:
blah ~ # /etc/init.d/sshd restart * Restarting sshd ... [ ok ]
To make things even more secure, you can use the "AllowUsers" option to specify what accounts will be able to log into sshd. This further restricts the possibility of an attacker gaining access to your system via brute-force guessing. Only users specified in the "AllowUsers" option will be able to log in using sshd.
AllowUsers joe john jill jed julie
In the above example, sshd will refuse all users who are not named joe, john, jill, jed, or julie. The sshd daemon will still ask for a password from the user, but even if the account exists on the system, if they aren't in the above list, they'll get the error "Permission Denied."
The timezone set on the default server basically is a hook to tell you that you need to update your timezone. If you don't change this, anything that uses or displays time will likely put a nag message in there telling you to fix your timezone. This process is easy.
All the necessary timezone files (called zonefiles in Linux,) are kept in /usr/share/zoneinfo. To set your timezone, you need to create a symbolic link from one of the files in this directory (or its subdirectories) to /etc/localtime, overwriting the hook.
In the example below, substitute your timezone for "PST8PDT".
blah ~ # ln -sf /usr/share/zoneinfo/PST8PDT /etc/localtime
In the default installation of Gentoo, metalog (a system logging tool) and dcron (a task scheduling service) are provided but not activated by default (as is Apache2, which will be discussed later.) These tools -- or other available replacements for these tools -- are necessary for the proper operation of the server. Many other services use them. Metalog and dcron are sufficient for the task but there are other more popular or powerful alternatives available. If you don't have any preferences towards a system logging service or a task scheduling service, you should use what has been provided.
To activate these services from boot, you will need to use the Gentoo rc-update script. This tool creates the appropriate links from your init.d scripts directory to the /etc/runlevels directory, which is consulted during the boot process. When you reboot your system, anything in the /etc/runlevels/boot and /etc/runlevels/default directories will be executed. Of course, this won't start these services, so you'll need to start them manually this time.
blah ~ # rc-update add metalog default * metalog added to runlevel default * rc-update complete blah ~ # /etc/init.d/metalog start * Starting metalog ... [ ok ] blah ~ # rc-update add dcron default * dcron added to runlevel default * rc-update complete blah ~ # /etc/init.d/dcron start * Starting dcron ... [ ok ] blah ~ #
If you want syslog-ng and vixie-cron instead of what is provided by default, you'll need to uninstall metalog and dcron and install syslog-ng and vixie-cron instead. To do so, you'll have to use Gentoo's software installation mechanism emerge (more on that later.)
blah ~ # emerge --unmerge metalog dcron app-admin/metalog selected: 0.8-r1 protected: none omitted: none sys-process/dcron selected: 3.2 protected: none omitted: none >>> 'Selected' packages are slated for removal. >>> 'Protected' and 'omitted' packages will not be removed. >>> Waiting 5 seconds before starting... >>> (Control-C to abort)... >>> Unmerging in: 5 4 3 2 1 [ ... ] >>> Regenerating /etc/ld.so.cache... * GNU info directory index is up-to-date. blah ~ # emerge syslog-ng vixie-cron Calculating dependencies... done! >>> Verifying ebuild Manifests... >>> Emerging (1 of 3) dev-libs/libol-0.3.18 to / [ ... ] >>> app-admin/syslog-ng-1.6.11-r1 merged. >>> No packages selected for removal by clean >>> Auto-cleaning packages... >>> No outdated packages were found on your system. blah ~ # rc-update add syslog-ng default * syslog-ng added to runlevel default * rc-update complete blah ~ # /etc/init.d/syslog-ng start * Starting syslog-ng ... [ ok ] blah ~ # rc-update add vixie-cron default * vixie-cron added to runlevel default * rc-update complete blah ~ # /etc/init.d/vixie-cron start * Starting vixie-cron ... [ ok ] blah ~ #
Many of the services needed to run a useful server rely on knowing where in the Network Universe they live. Without this important information, they easily get lost and will not work as expected. VPSLink sets up a number of files for you, such as the network IP and Gateway configuration in /etc/conf.d/net, and the DNS resolver configuration stored in /etc/resolv.conf. However, they didn't configure everything for you.
To configure this information, you'll need to have set up your DNS in the VPSLink Control Panel and at your domain registrar. For this document, we'll use the DNS domain "example.com", but you should substitute the domain you will be using on your server instead.
First, Gentoo stores its configuration files in /etc (like all other UNIX Operating Systems.) Within the /etc directory is a conf.d subdirectory, that Gentoo is using more and more as a "simple local configuration" directory (so that you can make quick changes without having to delve deep into long configuration files.) Two of the files (hostname and domainname) that need to be modified reside in this /etc/conf.d directory. Edit the files to add your host and domain names (you can use either vi or nano to edit the files; nano is a little easier on those who have never used vi.)
# /etc/conf.d/hostname # Set to the hostname of this machine HOSTNAME="www.example.com"
# /etc/conf.d/domainname # When setting up resolv.conf, what should take precedence? # 0 = let dhcp/whatever override DNSDOMAIN # 1 = override dhcp/whatever with DNSDOMAIN OVERRIDE=1 # To have a proper FQDN, you need to setup /etc/hosts and /etc/resolv.conf # (domain entry in /etc/resolv.conf and FQDN in /etc/hosts). # # DNSDOMAIN merely sets the domain entry in /etc/resolv.conf, see # the resolv.conf(5) manpage for more info. DNSDOMAIN="example.com" # For information on setting up NIS, please see: # http://www.linux-nis.org/nis-howto/HOWTO/ NISDOMAIN=""
Another file you'll likely want to change is your /etc/hosts file. This file is used to map IP Addresses to Hostnames locally, which helps many of the services avoid having to consult the DNS server every time they want to look up a specific local IP Address. The dionysos entry was obscured below for security, but you shouldn't modify it in your file. Change the IP Address and domain name below to reflect your site:
# /etc/hosts: This file describes a number of # hostname-to-address mappings for the TCP/IP # subsystem. It is mostly used at boot time, when # no name servers are running. On small systems, # this file can be used instead of a "named" name # server. Just add the names, addresses and any # aliases to this file... # 127.0.0.1 localhost.example.com localhost xxx.xxx.xxx.xxx dionysos.xxx.xxx dionysos xxx.xxx.xxx.xxx www.example.com www
When the server reboots, the new domain and host name will be updated. To force this to occur now, you'll need to use the hostname and domainname tools.
blah ~ # hostname www.example.com blah ~ # domainname example.com
Once this is done, the server should be ready to accept new services.
If you plan on running your server as a webserver -- which you more-than-likely plan on doing -- then you'll need to activate and configure it. Like metalog and dcron, VPSLink has installed Apache2 for you, but hasn't activated it. To activate Apache2, you should follow the same directions as listed above for dcron and metalog. However, don't start it yet, until you get a chance to configure it.
blah ~ # rc-update add apache2 default * apache2 added to runlevel default * rc-update complete blah ~ #
Now, configuring Apache2 can be a little tricky, especially when you start adding modules to it. For the sake of just getting the server online though, a simple modification of the configuration to point to your html files is all that is necessary.
The assumption is made that you will use this website for Virtual Hosting, which means that the site will be set up with more than one domain name. This is a safe assumption, as even those who aren't running more than one domain name for their site will not be hindered in any way by activating Apache's Virtual Hosting capabilities. This will leave you room to grow in the future. Luckily, VPSLink already made this assumption for you, by modifying /etc/conf.d/apache2 to include the option "DEFAULT_VHOST" as shown below:
If your /etc/conf.d/apache2 is missing this line, make sure to add it to the file. Now, you'll need to modify the /etc/apache2/vhosts.d/00_default_vhost.conf file to reflect your website. Most of the defaults in this file are good, but you may want to provide a ServerName, ServerAlias, ServerAdmin, and CustomLog/ErrorLog entries in the file to refect your site. Here is an example of an updated 00_default_vhost.conf file which will be used as the default website for users accessing your web-server:
NameVirtualHost *:80 <IfDefine DEFAULT_VHOST> <VirtualHost *:80> DocumentRoot "/var/www/localhost/htdocs" <Directory /var/www/localhost/htdocs> Options Indexes FollowSymLinks AllowOverride All Order allow,deny Allow from all </Directory> ServerName example.com ServerAlias www.example.com ServerAdmin email@example.com ScriptAlias "/cgi-bin/" "/var/www/localhost/cgi-bin/" CustomLog "/var/log/httpd/access_log" "combined" ErrorLog "/var/log/httpd/error_log" <IfModule peruser.c> ServerEnvironment apache apache MinSpareProcessors 4 MaxProcessors 20 </IfModule> <IfModule itk.c> AssignUserID apache apache MaxClientsVHost 50 </IfModule> </VirtualHost> </IfDefine>
Of course, when you go to actually run multiple virtual hosts, or plan on using SSL, or adding other modules, you'll likely need to modify this again (which will be covered more below,) but for now this should work well enough to get the webserver up and running. Move your content into the /var/www/localhost/htdocs directory, then start the server and access it through a web-browser.
blah ~ # /etc/init.d/apache2 start * Starting apache2 ... [ ok ]
OpenSSL is installed on your system by default too. All you need to do is to add "-D SSL" to /etc/conf.d/apache2.
Restart the Apache2 server and you'll be able to access your content on both port 80 (HTTP) and port 443 (HTTPS).
Apache2 generates a self-signed certificate on install using the script gentestcrt.sh. For most people, using a self-signed "test" certificate is extremely unprofessional. Every time a user visits your website using SSL, they will get a warning from their web browser telling them that you have a self-signed certificate and they cannot trust you.
You can use cacert.org or other Certification Authorities to generate a certificate for your webserver for you. Cacert.org certificates are free, while Verisign tends to charge quite a bit for the opportunity. When these certificates are generated, store the key and the cert file in the /etc/apache2/ssl directory. (Also, make sure your key files are owned by Apache and are set to 0400 (read-only for user).)
As stated above, Apache2 is configured with the "-D DEFAULT_VHOSTS" directive in order to run with Virtual Directories by default. In doing so, when the Apache2 server boots up, it reads the /etc/apache2/vhosts.d directory, specifically the 00_default_vhost.conf and default_vhost.include files. In doing so, the system is set up to respond to all queries to any IP address on the server by directing them to the contents of /var/www/localhost/htdocs directory.
This works well for one default virtual host. But if you add new virtual hosts to your computer, this default virtual host directive actually causes problems (since everything is sent to the /var/www/localhost/htdocs directory.)
The 00_default_vhost.conf tells you to change the Listen directive from "Listen 80" to "Listen 126.96.36.199:80" to keep the server from taking control of all of the IP addresses you may be using. Then you can create other files to bind to your other IP addresses. This sometimes works, but if you are going to use both name-based and IP-based virtual hosting (which yes, this works fine,) and SSL, you should remove the "-D DEFAULT_VHOSTS" directive from /etc/conf.d/apache2.
The best practice for virtual hosting in Apache is to use IP-based virtual hosting, and create an IP address for each one of the virtual hosts you'll be using. Of course, VPSlink has an upper limit on the IP addresses you can use, depending on the level you are using, and thus for large systems you'll likely run out of IP addresses before too long. When you run out of IP addresses, you are going to have to switch to using name-based virtual hosting.
Create files in your /etc/apache2/vhost.d directory for each IP address you will be using as your virtual hosts (i.e. 01_xxx.xxx.xxx.xxx.conf, where xxx.xxx.xxx.xxx is your IP address.) Within this file, for IP-based virtual hosting, use the following directives:
Listen xxx.xxx.xxx.xxx:80 <VirtualHost xxx.xxx.xxx.xxx:80> Include /etc/apache2/vhosts.d/modules.include DocumentRoot "/var/www/example.com/htdocs" ServerAdmin "firstname.lastname@example.org" ScriptAlias "/cgi-bin/" "/var/www/example.com/cgi-bin/" CustomLog "/var/www/example.com/access_log" "combined" ErrorLog "/var/www/example.com/error_log" <Directory /var/www/example.com/htdocs> Options Indexes Includes FollowSymLinks AllowOverride All Order allow,deny Allow from all </Directory> </VirtualHost>
If you are using name-based and IP-based virtual hosting, use the following directives:
Listen xxx.xxx.xxx.xxx:80 NameVirtualHost xxx.xxx.xxx.xxx:80 <VirtualHost xxx.xxx.xxx.xxx:80> Include /etc/apache2/vhosts.d/modules.include ServerName example.com:80 DocumentRoot "/var/www/example.com/htdocs" ServerAlias "ftp.example.com" "www.example.com" ServerAdmin "email@example.com" ScriptAlias "/cgi-bin/" "/var/www/example.com/cgi-bin/" CustomLog "/var/www/example.com/access_log" "combined" ErrorLog "/var/www/example.com/error_log" <Directory /var/www/example.com/htdocs> Options Indexes Includes FollowSymLinks AllowOverride All Order allow,deny Allow from all </Directory> </VirtualHost> <VirtualHost xxx.xxx.xxx.xxx:80> Include /etc/apache2/vhosts.d/modules.include ServerName example2.com:80 DocumentRoot "/var/www/example2.com/htdocs" ServerAlias "ftp.example2.com" "www.example2.com" ServerAdmin "firstname.lastname@example.org" ScriptAlias "/cgi-bin/" "/var/www/example2.com/cgi-bin/" CustomLog "/var/www/example2.com/access_log" "combined" ErrorLog "/var/www/example2.com/error_log" <Directory /var/www/example2.com/htdocs> Options Indexes Includes FollowSymLinks AllowOverride All Order allow,deny Allow from all </Directory> </VirtualHost>
Continue building files for each IP address you are using.
Apache2 is big, complex, and expensive (in terms of memory, disk usage, and processor usage.) While most folks will like the fact that Apache2 does just about everything they want to do for them without much work (as its plugin model means that you can add PHP, SSL, and a ton of other modules easily.) However, there are a lot of folks who don't want to use Apache2 as their server.
While VPSLink builds and installs Apache2 for you, there is no reason that you have to use it. There are several other web servers out there that work just as well, and in some cases, better than Apache2. A lot of folks like using the smaller and less complex lighttpd instead. To do so, run the following commands:
blah ~ # /etc/init.d/apache2 stop * Stopping apache2 ... [ ok ] blah ~ # rc-update delete apache2 default * apache2 removed from the following runlevels: default * rc-update complete blah ~ # emerge --unmerge Apache2 www-servers/apache2 selected: 2.0.58-r2 protected: none omitted: none >>> 'Selected' packages are slated for removal. >>> 'Protected' and 'omitted' packages will not be removed. >>> Waiting 5 seconds before starting... >>> (Control-C to abort)... >>> Unmerging in: 5 4 3 2 1 [ ... ] >>> Regenerating /etc/ld.so.cache... * GNU info directory index is up-to-date. blah ~ # emerge lighttpd Calculating dependencies... done! >>> Verifying ebuild Manifests... >>> Emerging (1 of 1) www-servers/lighttpd-1.4.18 to / [ ... ] >>> www-servers/lighttpd-1.4.18 merged. >>> No packages selected for removal by clean >>> Auto-cleaning packages... >>> No outdated packages were found on your system. blah ~ # rc-update add lighttpd default * lighttpd added to runlevel default * rc-update complete blah ~ #
Edit the /etc/lighttpd/lighttpd.conf file to conform to your system. Once you fix the config files, start up the server by running the following command:
blah ~ # /etc/init.d/lighttpd start * Starting lighttpd ... [ ok ] blah ~ #
Emerge does not delete config files or content when it finishes its unmerge. This is usually a good thing, but the config files can take space that can be used for other things. If you don't plan on running apache2 ever again, or haven't made too many changes to the apache2 config files (they will be recreated when you install the software again,) you can delete everything in the /etc/apache2 directory.
The following items are included to help lock down your system more than it is already. They are entirely optional, but recommended.
The Internet isn't safe. There are a number of machines out there looking for open servers; running bots specifically designed to brute-force services such as sshd. These systems are usually compromised themselves, but attackers will scan the network periodically looking for a new machine to install bots on themselves, so not all machines scanning you are compromised machines.
This is where the tool DenyHosts comes in. It automatically scans your log files and determines if someone is trying to use brute-force guessing attacks against your services. Once DenyHosts finds a potential attacker, the attacker's IP address is added to the hosts.deny file, which permanently denies their access in the future to your system.
DenyHosts is highly configurable, and works with the most common log servers (sysklogd, syslog-ng, and metalog.) It can be run as a cron-job, or as a system service (running at boot.)
blah ~ # emerge denyhosts
Once DenyHosts is installed, if you are running sysklogd or syslog-ng, all you have to do is add DenyHosts to your crontab, or install it as a service and run it:
blah ~ # rc-update add denyhosts default * denyhosts added to runlevel default * rc-update complete blah ~ # /etc/init.d/denyhosts start * Starting denyhosts ... [ ok ] blah ~ #
If you are using metalog, the default logger, then you'll have to do some additional work. First, comment out (disable) the current "SECURE_LOG =" entry:
# # Gentoo/SuSE: # SECURE_LOG = /var/log/messages # <---Make sure to place a # in front of this line.
Now add your own SECURE_LOG entry to the bottom of the section:
################################################################ SECURE_LOG = /var/log/everything/current ################################################################
Now you should be able to start the DenyHosts software.
blah ~ # /etc/init.d/denyhosts start * Starting denyhosts ... [ ok ] blah ~ #