And again about ... LAMP and basic secure mini-hosting with your own hands

Seeing once again the despicable promise to Google in response to the question of how to deploy your own LAMP, I decided to write this post. In order to somehow dilute the tons of joyful reports on the successful installation of blogs, the essence of which boils down to one aptitude command install blah-blah .

No, well, of course it is clear, PHP is the most reliable language, and all the site engines written on it are a living embodiment of impenetrable protection against hacking. Then yes - aptitude install apache2 - and you will be happy. Do not forget to leave phpmyadmin at the default address, but install some leaky FTP sieve.

In general, as it turned out, many people do not even know that having hacked a site and having the opportunity to execute their PHP code, an attacker on a system with defensive settings can at least read almost anything on your system. It is understandable - working with Linux you get used to something that by default security is at a sufficient level. And here is a hole ...
')
In general - this article once again describes a trivial topic on how to deploy LAMP and give external users access to the files and databases of your sites. Those. how to quickly do a mini-hosting with your own hands. However, in contrast, hosting will be at least basic protected .

Those who are tired of the theme of web servers may be able to find in the article interesting techniques for multi-user limited access to the server via SFTP.

And no, this is not another article describing installing Linux and running aptitude install apache2. Quite the contrary: in this article I wanted to show the fatal insufficiency of these manipulations and to put it mildly the incompetence of those who replicate them on the Internet.

Installation

Everything will be described on the example of Debian.

First you need to install everything you need (by the way, for Ubuntu phpMyAdmin is better to install from the PPA ):

aptitude install apache2 mysql-server libapache2-mod-php5 ssh aptitude install phpmyadmin 

When installing phpMyAdmin, we generate an arbitrary password to connect to the database, otherwise everything is obvious.

How it will work

All users who need to access files on the server will have a local account with the ability to log in only via SFTP and only in the folder with the sites belonging to them. At the same time authorization will be supported both by password and by key. The interactive input via SSH will not be possible, although if you really need it, you can enable it, and also with private access to the system files.

There will be no FTP, although it can be easily screwed. SFTP is more reliable (encryption, the ability to authorize by key), and FTP in this case is elementarily redundant and is a fairly large potential security hole.

Each site will belong to a certain "account", i.e. under one 'account' there can be several sites. SFTP users are tied to these “accounts”, and no one bothers to link several users to one “account”. Further, inside the 'account', everything can be resolved with standard access rights mechanisms in Linux.

Users and passwords from the database will not depend on the system users, the database will be managed through standard phpMyAdmin.

Among other things, sites running on your server will not be able to climb out of their working directory and read or change any data that is not related to them.

A little more detail about the structure

All sites will be located in directories like / var / www / ACCOUNT / sites / SITENAME . ACCOUNT here does not necessarily mean some kind of system user, just some arbitrary identifier.

System users who will connect via SFTP to edit sites will have / var / www / ACCOUNT / home / USERNAME as their home directory. Accordingly, depending on the value of ACCOUNT, one or another user will have access to this or that account. Creating a home directory within an account is necessary in order to be able to authorize SFTP users by keys.

For all SFTP users, the main group will be set to www-data (default Apache2 group in deb-based). In addition, all created by both the user via SFTP and Apache, the default files will have 0660 permissions , and the directories will be 0770 . Since Apache and SFTP users have the same group, by default, both the user and the web server can write to any new file or directory, regardless of who created it. What is usually required.

Bases will use their own, completely separate authorization and access control mechanism. Everything is extremely simple: we create users and give them rights only to specific databases. Therefore, we will no longer return to this issue.

Creating 'accounts' and system users

Placing a site on a server should start with preparing a place for it and creating a user to work with it. As described above, for the site we need a folder of the form / var / www / ACCOUNT / . As ACCOUNT, we use for example 42 . Just 42 . Ok, create a folder:

 mkdir /var/www/42 

In addition, inside the account we need the directories home / USERNAME and sites . Create them:

 mkdir -p /var/www/42/home/marvin mkdir /var/www/42/sites 

For future SFTP setup, you should immediately make sure that / var / www / 42 / sites and all the subordinate folders belong to root: root and no one except root has write access to them.

Next, create a user. In order not to be confused with ordinary, full-fledged server users, SFTP users can be transferred to the UID range from 901 to 999 . If you do not need it - remove acc. options. If you want to log in only by key, then add the --disabled-password parameter . As a result, the command is as follows:

 adduser --home /var/www/42/home/marvin --no-create-home --shell /bin/false --firstuid 901 --lastuid 999 --ingroup www-data marvin 

Installing the shell in / bin / false ensures that the user will not be able to log in interactively.

SFTP Setup

The SFTP setup will consist in the fact that for all members of the www-data group we will make sure that when entering SFTP they immediately fall into the account account's folder in which their HOME directory is located, without being able to get higher in the directory tree.

This is done simply. Just add the code to the end of the / etc / ssh / sshd_config file

 #      www-data: chroot   HOME, #  umask 007,  0660    0770   Match Group www-data AllowTCPForwarding no X11Forwarding no ChrootDirectory %h/../../sites ForceCommand internal-sftp -u 0007 

And poke sshd to update the configuration:

 service ssh reload 

This piece of code for all users from the www-data group, first of all, disables TCP and X11 forvading (they have no reason to have access to your LAN). Secondly, when they enter chroot in the sites, the folder of their “account” does for them (for this we needed to make the sites of the folder available for writing only to root - otherwise the chroot does not work). Well, in the third, it changes the SFTP handler to the built-in one (which does not need a full environment with a shell and so on), simultaneously telling it to create all the files and folders with a umask value in 007 . That is, the default rights for new files will be 0660 , and for directories - 0770 .

Apache and phpMyAdmin setup

There is no need to specifically configure Apache to provide basic work. The only thing that in Debian is the PHP5 package that comes with the integrated Suhosin patch, which improves security. It will be necessary when setting up the configs of the site, although it is possible to do without it.

In general, for Apache, you only need to change the umask for the files and folders you create to the same one that we used to configure SFTP. This is done by adding lines to / etc / apache2 / envvars :

 # umask 007      0660    0770 umask 007 

For the minimum configuration of phpMyAdmin you only need to change the address at which it will be available, from indecently stupid your.site / phpmyadmin to something else. To do this, in the /etc/phpmyadmin/apache.conf file, you need to replace the line

 Alias /phpmyadmin /usr/share/phpmyadmin 

on, for example:

 #    ! Alias /_ /usr/share/phpmyadmin 

Do not forget to restart Apache:

 service apache2 restart 

Adding sites

To add sites to your hosting you need to do two things - firstly, to place the site files with the necessary rights on your server, and secondly, to create an Apache config for the site. In addition, most often you will need to create a database and configure access rights to it - but this is a trivial operation, so we will not consider it.

To place the files you need to create a site directory in the folder of the desired 'account' as root. For example:

 mkdir /var/www/42/sites/deep-thought.net 

Further set the desired rights. At a minimum, an SFTP user who will work with this directory must have write permissions. For example, you can do this:

 chown marvin:www-data /var/www/42/sites/deep-thought.net chmod 0750 /var/www/42/sites/deep-thought.net 

Ok, now the user can log in and upload the site files. It remains to configure the Apache. To do this, as always, create a configuration file in the / etc / apache2 / sites-available directory. The content of this file for the site deep-thought.net with the data in the /var/www/42/sites/deep-thought.net directory should be something like this:

 <VirtualHost *:80> ServerAdmin webmaster@deep-thought.net ServerName deep-thought.net #    DocumentRoot /var/www/42/sites/deep-thought.net <Directory /var/www/42/sites/deep-thought.net> #       #Options FollowSymLinks #AllowOverride All <IfModule mod_php5.c> #  php       php_admin_value open_basedir /var/www/42/sites/deep-thought.net #    -         php_admin_value upload_tmp_dir /var/www/42/sites/deep-thought.net/temp php_admin_value session.save_path /var/www/42/sites/deep-thought.net/temp #     URL php_admin_flag allow_url_include off #      PHP php_admin_flag enable_dl off #       php_admin_value suhosin.executor.func.blacklist apache_note,apache_setenv,closelog,debugger_off,debugger_on,define_syslog_variables,escapeshellarg,escapeshellcmd,ini_restore,openlog,passthru,pclose,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,shell_exec,syslog,system,url_exec </IfModule> </Directory> # ,   ,   temp <Directory /var/www/42/sites/deep-thought.net/temp> AllowOverride None Order Deny,Allow Deny from All </Directory> ErrorLog /var/log/apache2/error.log # Possible values include: debug, info, notice, warn, error, crit, # alert, emerg. LogLevel warn CustomLog /var/log/apache2/access.log combined </VirtualHost> 

Only the content of the <IfModule mod_php5.c> block is important here. It contains PHP settings that, firstly, prohibit accessing files outside the root directory of the site ( open_basedir and transfer to temp), secondly, disable two extremely dangerous PHP features ( allow_url_include , enable_dl ), which are still present in modern versions of PHP and can even be included. And finally, thirdly, PHP scripts are prohibited from using a whole range of OS interaction functions. For example, the execution functions of an arbitrary command. The list of functions is honestly removed from somewhere on the Internet and does not claim to be universal, although it seems to be sufficient for security.

A bit about temp : since we prohibit PHP from accessing files outside the root directory of the site, we need to specify a directory to save temporary files (files uploaded by site users to the server via the standard HTML form download mechanism) and session files inside the site root. This directory must, of course, be pre-created. In addition, it would be better to explicitly close access to it from the Internet, which is done in the second Directory block. Otherwise, someone can accidentally get a session of your users.

If Suhosin is not installed on the server, then instead of suhosin.executor.func.blacklist, you can use the standard PHP disable_functions option. True, it must be specified in php.ini , i.e. it will act on all sites on your server.

In addition, in the above settings, the eval function is not disabled. Alas, many sites need it for some reason, although it is still better to turn it off. Note the suhosin.executor.disable_eval and suhosin.executor.disable_emodifier options from Suhosin .

After you prepare the config you need, simply activate the site:

 a2ensite deep-thought.net 

And do not forget to kick the Apache:

 service apache2 reload 

And of course you need to upload the files and database of the site to the server - without them, it is unlikely something will work.

SSH tuning: keys and interactive input

For access of SFTP users by keys, you need to do everything too, which is always done: inside the HOME directory, create the .ssh / directory, in it the authorized_keys file, in which you must register the public keys for the user.

In addition, some users can open online access to the server. To do this, first of all, prepare the necessary chroot environment in the root folder of the corresponding 'account', at least with the interpreter and all the necessary virtual filesystems. This is done as standard and nothing complicated about it.

Then you can create an additional group for interactive login. For example, ssh-interactive :

 addgroup --gid 900 ssh-interactive 

Add the necessary users to it, changing SHELL with it to a full bash:

 usermod -a -G ssh-interactive --shell /bin/bash marvin 

And set specific settings for this group in sshd_config . To do this, you need to modify the Match directive related to www-data by adding the ! Ssh-interactive to it , so that it does not apply to users of this group:

 Match Group www-data,!ssh-interactive 

And after it, add another Match directive:

 #    SSH      Match Group www-data,ssh-interactive AllowTCPForwarding no X11Forwarding no ChrootDirectory %h/../../ 

The only problem is that for the members of the ssh-interactive group the umask will no longer be set to 007. You can fix this by adding the corresponding parameter in the global settings of the sftp subsystem in sshd_config . By the way, you are unlikely to want to drag the openssh components into the chroot environment, so you can also change the external sftp handler to the internal implementation:

 Subsystem sftp internal-sftp -u 0007 

More on SFTP configuration: http://en.wikibooks.org/wiki/OpenSSH/Cookbook/SFTP

Finally

I was always interested in the question - is there anywhere on the official resources of a complete list with a description of all PHP functions that one way or another can give the script access to the components and files of the system. The above list is honestly taken from the Internet, so if someone shares a link to the list of functions, I will be very grateful.

Well, yes - if there are any comments on what else can be done to ensure the safe operation of the simplest hosting - write.