Operating base (applies to CentOS and Ubuntu)
Single user
Each machine is setup with a single day-to-day user account (web) and a super-privileged root user. The web user's home directory is in /home/web.
Secure shell (SSH)
SSH access is setup on a non-standard port (15022) to improve security.
SSH access using password
Dev
web only, then su to root or better sudo
Staging/live
web only, then su to root
SSH access using PKI
Public-private key pairs give excellent security and are a handy way to manage communication, both to your server and from it to other sites, such as github.com. Every Devopera server and VM comes with a private-public key pair installed. By copying out the private key and loading it on your local host machine, you can SSH to your server without being prompted to login (instructions for Windows/Putty/Pageant, Linux and Mac OS X).
PKI key agent
Dev
The private key is loaded automatically using a hardcoded passphrase. This is very convenient for dev machines, because they can talk to other non-secure infrastructure as soon as started up.
Staging/live
Live and staging servers rely on the passphrase being entered the first time the web user logs on. From that point on it's stored by the ssh-agent (until the next restart or refresh of ssh-agent) and used to authenticate the machine with other servers. It does mean that live servers require the user to enter the key passphrase before they're able to start talking, but that additional security measure helps ensure they don't go rogue.Credentials
Dev/staging
web user password: admLn**
root user password: devopera
Key passphrase: admLn**
Live
All initial usernames and passwords for our live builds are supplied to you by email at the time of delivery.
SFTP access
Secure File Transfer Protocol (SFTP) is also enabled by the SSH daemon. While almost all command-line versions of the SSH client support port (-p) and user@host settings, some older versions of SFTP don't. However you can configure all the settings (port, user, host, even forwarding) in ~/.ssh/config which simplifies your command line (ssh
Security-Enhanced Linux (SELinux)
SELinux is enabled and set to enforcing for both dev and live machine types. All services described here are configured to work with SELinux in their current configurations. While many sysadmins choose to disable SELinux, we prefer to start with the most secure setup we know how to create and let you make decisions about how you want to relax it. Please see later notes on how to maintain the security of your devopera servers.
Standard tools
NTP
Network Time Protocol is used to synchronise this machine's time with network-based time servers.
Compass
Dev/staging
Compass is an open-source CSS Authoring Framework, mainly used to compile SASS into CSS.
Live
Dev tools are not installed on live servers by default.
Version control systems (VCS)
Git/Subversion repos
Git and subversion are setup. Many applications are available from repositories. These applications are organised in the /var/www directory by the VCS they use and the server from which they are sourced:
e.g. /var/www/git/github.com/my_git_repo
Samba
Dev
Samba shares are setup for the web user's home directory and /var/www. Each samba share is configured to create and modify files with a certain set of permissions: read-write for web and read-only for www-data.
No matter how diligent your are, you may find certain programs set different permissions so a bit of chmod'ing is often required! To access samba using Windows file sharing, just connect to:
\\<ip address>
or
\\<machine alias>
if you've set one up.
Staging/live
We don't encourage using samba for access to live machines. While it can be enabled and port-forwarded over SSH securely, we recommend using a VCS such as git/svn for code deployment and SSH/SFTP or SCP to send files to the server.
Credentials
Dev
The web user account has a corresponding but independent Samba user (web) with initial password 'admLn**'. Usernames and passwords are case sensitive.
Samba username: web
Samba password: admLn**
Staging/Live
The Samba service is not turned on by default for live servers or their corresponding staging peers. It's for security.
Firewall
Dev
We restrict only the incoming port list to those services that are available. For dev machines, your environment may be properly secured behind a firewall, so you could disable the VM's firewall by running sudo service iptables stop
Staging/live
Live servers typically run in exposed environments or on open networks, hence our firewall policy is a lot more involved for staging VMs or live builds.
ConfigServer Firewall is setup to protect both incoming and outgoing ports. If you want to do install new services, you must open the necessary ports in /etc/csf/csf.conf and ask CSF to reload them.
RootKit hunter is designed to identify binaries that have been corrupted with intent to compromise a server. To run rkhunter manually (non-interactive):
/usr/bin/rkhunter -c -sk
After updating any of the monitored binaries, you'll need to tell rkhunter to update its database in order to avoid false positives:
/usr/bin/rkhunter --propupd
Finally, if you receive rkhunter's 'something has changed' email (that reads "Please inspect this machine, because it may be infected."), we recommend looking at the logs (in /var/log/rkhunter) to understand what triggered it.
Linux Malware Detect looks for malware on a server.
DNS
Dev
Currently dev machines do not offer local DNS support, but it is planned. For now, you can always put records in your /etc/hosts file, which under Windows lives in /Windows/system32/drivers/etc/hosts.
Staging/live
DNS is not configured for live servers as the domain name resolution system was not really designed for web servers to host their own DNS records. We recommend using a registrar that provides DNS management services, like Domainmonster.com who we use.
