{{Note| If using a 64 bit kernel you will need to create $JAIL/usr/lib64 and a symbolic link to this directory: cd $JAIL; ln -s usr/lib64 lib64. The 64bit libraries will need to be copied in a later section}}

Then mount {{ic|$JAIL/tmp}} and {{ic|$JAIL/run}} as tmpfs's. The size

Then mount {{ic|$JAIL/tmp}} and {{ic|$JAIL/run}} as tmpfs's. The size

Line 98:

Line 100:

/lib/ld-linux-x86-64.so.2 (0x00007fdb1aaef000)</nowiki>}}

/lib/ld-linux-x86-64.so.2 (0x00007fdb1aaef000)</nowiki>}}

−

# cp /usr/lib/libpthread.so.0 $JAIL/usr/lib/

+

# cp /usr/lib/linux-vdso.so.1 $JAIL/usr/lib/

−

# cp /usr/lib/libcrypt.so.1 $JAIL/usr/lib

+

# cp /usr/lib/libpthread.so.0 $JAIL/usr/lib

...

...

# cp /lib/ld-linux-x86-64.so.2 $JAIL/lib

# cp /lib/ld-linux-x86-64.so.2 $JAIL/lib

Line 141:

Line 143:

# chown -R root:root $JAIL/

# chown -R root:root $JAIL/

−

# chown -R #USER:$GROUP $JAIL/www

+

# chown -R http:http $JAIL/www

−

# chown -R #USER:$GROUP $JAIL/etc/nginx

+

# chown -R http:http $JAIL/etc/nginx

−

# chown -R #USER:$GROUP $JAIL/var/{log,lib}/nginx

+

# chown -R http:http $JAIL/var/{log,lib}/nginx

−

# chown #USER:$GROUP $JAIL/run/nginx.pid

+

# chown http:http $JAIL/run/nginx.pid

# find $JAIL/ -gid 0 -uid 0 -type d -print | xargs chmod -rw

# find $JAIL/ -gid 0 -uid 0 -type d -print | xargs chmod -rw

Line 160:

Line 162:

=== Modify nginx.service to start chroot ===

=== Modify nginx.service to start chroot ===

+

+

Before modifying the nginx.service unit file, it may be a good idea to copy it to

+

{{ic|/etc/systemd/system/}} since the unit files there take priority over those in {{ic|/usr/lib/systemd/system/}}.

{{Note|I'm not sure if the pid file needs to be stored in the chroot jail.}}

−

{{hc|/usr/lib/systemd/system/nginx.service|<nowiki>

+

{{hc|/etc/systemd/system/nginx.service|<nowiki>

[Unit]

[Unit]

Description=A high performance web server and a reverse proxy server

Description=A high performance web server and a reverse proxy server

Line 181:

Line 188:

WantedBy=multi-user.target</nowiki>}}

WantedBy=multi-user.target</nowiki>}}

−

== Starting Service ==

+

{{Note|Upgrading nginx with pacman will not upgrade the chrooted nginx installation. You have to take care of the updates manually by repeating some of the steps above. Don't forget to also update the libraries it links against. }}

−

To start the Nginx service, run:

+

You can now safely get rid of the non-chrooted nginx installation.

−

# rc.d start nginx

+

# pacman -Rsc nginx

−

The default served page at http://127.0.0.1 is:

+

If you don't remove the non-chrooted nginx installation, you may want to make sure that the running nginx process is in fact the chrooted one. You can do so by checking where {{ic|/proc/{PID}/root}} symmlinks to. If should link to {{ic|/srv/http}} instead of {{ic|/}}.

If you are going to process .html and .htm files with php, you should have something like this:

+

You could create {{Ic|/etc/nginx/php.conf}} and save this configuration there, then when needed just include this file into the {{Ic|server}} block.

−

+

server = {

+

...

+

include php.conf;

+

...

+

}

+

+

If you are going to process .html and .htm files with PHP, you should have something like this:

location ~ \.(php|html|htm)$ {

location ~ \.(php|html|htm)$ {

fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;

fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;

fastcgi_index index.php;

fastcgi_index index.php;

−

root /usr/share/nginx/html;

include fastcgi.conf;

include fastcgi.conf;

−

}

−

location / {

−

root /usr/share/nginx/html;

−

index index.html index.htm index.php;

}

}

−

Non .php files processing in php-fpm should be explicitly enabled in configuration

+

Non .php files processing in php-fpm should be explicitly enabled in

−

{{Ic|/etc/php/php-fpm.conf}}

+

{{Ic|/etc/php/php-fpm.conf}}:

−

security.limit_extensions = .php .html .htm

security.limit_extensions = .php .html .htm

−

You need to restart a php-fpm daemon if you changed configuration

+

You need to restart the php-fpm daemon if you changed the configuration.

+

# systemctl restart php-fpm

'''Pay attention''' to the {{Ic|fastcgi_pass}} argument, as it must be the TCP or Unix socket defined by the chosen FastCGI server in its config file. The '''default''' Unix for {{Ic|php-fpm}} is

'''Pay attention''' to the {{Ic|fastcgi_pass}} argument, as it must be the TCP or Unix socket defined by the chosen FastCGI server in its config file. The '''default''' Unix for {{Ic|php-fpm}} is

−

fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;

+

fastcgi_pass unix:/run/php-fpm/php-fpm.sock;

−

and for {{Ic|spawn-fcgi-php}},

+

Or you may use the common TCP socket, '''not default''',

−

fastcgi_pass unix:/var/run/spawn-fcgi-php.sock;

−

. Or you may use the common TCP socket, '''not default''',

fastcgi_pass 127.0.0.1:9000;

fastcgi_pass 127.0.0.1:9000;

−

. Unix domain sockets are however much better.

+

Unix domain sockets are however much better.

{{Ic|fastcgi.conf}} or {{Ic|fastcgi_params}} are usually included because they hold FastCGI settings for Nginx; the use of the latter is deprecated, though. They come within the Nginx installation.

{{Ic|fastcgi.conf}} or {{Ic|fastcgi_params}} are usually included because they hold FastCGI settings for Nginx; the use of the latter is deprecated, though. They come within the Nginx installation.

Line 274:

Line 276:

Finally, if Nginx has been working, run:

Finally, if Nginx has been working, run:

# systemctl restart nginx

# systemctl restart nginx

−

If you would like to test the FastCGI implementation, create {{ic|/usr/share/nginx/html/index.php}} with content

If you would like to test the FastCGI implementation, create {{ic|/usr/share/nginx/html/index.php}} with content

Line 443:

Line 444:

Also notice that not only php script should have read permission, but also the entire directory structure should have execute permission so that PHP user can traverse the path.

Also notice that not only php script should have read permission, but also the entire directory structure should have execute permission so that PHP user can traverse the path.

+

+

=== Error: chroot: '/usr/sbin/nginx' No such file or directory ===

+

+

If you encounter this error when running the daemon of nginx using chroot, this is likely due to missing 64 bit libraries in the jailed environment.

+

+

If you are running chroot in {{ic|/srv/http}} you need to add the required 64 bit libraries.

+

+

First, set up the directories (these commands will need to be run as root)

+

+

# mkdir /srv/http/usr/lib64

+

# cd /srv/http; ln -s usr/lib64 lib64

+

+

Then copy the required 64 bit libraries found using {{ic|ldd /usr/sbin/nginx}} to {{ic|/srv/http/usr/lib64}}

+

+

if run as root, permissions for the libraries should be read and executable for all users, so no modification is required.

== See Also ==

== See Also ==

Revision as of 17:38, 22 February 2013

zh-CN:NginxNginx (pronounced "engine X") written by Igor Sysoev (Russia) in 2005, is a free, open-source, high-performance HTTP server and reverse proxy, as well as an IMAP/POP3 proxy server. According to Netcraft's April 2012 Web Server Survey, Nginx now hosts 10.32% of all domains worldwide, while Apache hosts about 65.46%. Nginx is now well known for its stability, rich feature set, simple configuration, and low resource consumption.

Installation

Installation in a chroot

Installing Nginx in a chroot adds an additional layer of security. For
maximum security the chroot should include only the files needed to run
the Nginx server and all files should have the most restrictive
permissions possible, e.g., as much as possible should be owned by root,
directories such as /usr/bin should be unreadable and unwriteable,
etc.

Arch comes with an http user and group by default which will run the
server. The chroot will be in /srv/http.

A perl script to create this jail is available at
jail.pl gist. It expects to be run
as root. You'll need to uncomment a line before it makes any changes.

Create Necessary Devices

Nginx needs /dev/null, /dev/random, and
/dev/urandom. To install these in the chroot we create the
/dev/ folder and add the devices with mknod. We avoid mounting
all of /dev/ to ensure that, even if the chroot is compromised, an
attacker must break out of the chroot to access important devices like
/dev/sda1.

Tip: See man mknod and ls -l
/dev/{null,random,urandom} to better
understand the argument to mknod.

Note: If using a 64 bit kernel you will need to create $JAIL/usr/lib64 and a symbolic link to this directory: cd $JAIL; ln -s usr/lib64 lib64. The 64bit libraries will need to be copied in a later section

Then mount $JAIL/tmp and $JAIL/run as tmpfs's. The size
should be limited to ensure an attacker cannot eat all the RAM.

Now copy over required libraries. Use ldd to list them and then copy
them all to the correct location. Copying is preferred over hardlinks to
ensure that even if an attacker gains write access to the files they
cannot destroy or alter the true system files.

Create restricted user/group files for the chroot. This way only the
users needed for the chroot to function exist as far as the chroot
knows, and none of the system users/groups are leaked to attackers
should they gain access to the chroot.

$JAIL/etc/group

http:x:33:
nobody:x:99:

$JAIL/etc/passwd

http:x:33:33:http:/:/bin/false
nobody:x:99:99:nobody:/:/bin/false

$JAIL/etc/shadow

http:x:14871::::::
nobody:x:14871::::::

$JAIL/etc/gshadow

http:::
nobody:::

# touch $JAIL/etc/shells
# touch $JAIL/run/nginx.pid

Finally make set very restrictive permissions. As much as possible
should be owned by root and set unwritable.

If your server will bind port 80 (or any port 0-1024), give the
chrooted executable permission to bind these ports without root.

# setcap 'cap_net_bind_service=+ep' $JAIL/usr/sbin/nginx

Modify nginx.service to start chroot

Before modifying the nginx.service unit file, it may be a good idea to copy it to
/etc/systemd/system/ since the unit files there take priority over those in /usr/lib/systemd/system/.
This means upgrading nginx wouldn't modify your custom .service file.

Note: Upgrading nginx with pacman will not upgrade the chrooted nginx installation. You have to take care of the updates manually by repeating some of the steps above. Don't forget to also update the libraries it links against.

You can now safely get rid of the non-chrooted nginx installation.

# pacman -Rsc nginx

If you don't remove the non-chrooted nginx installation, you may want to make sure that the running nginx process is in fact the chrooted one. You can do so by checking where /proc/{PID}/root symmlinks to. If should link to /srv/http instead of /.

Configuring

FastCGI

FastCGI, also FCGI, is a protocol for interfacing interactive programs with a web server. FastCGI is a variation on the earlier Common Gateway Interface (CGI); FastCGI's main aim is to reduce the overhead associated with interfacing the web server and CGI programs, allowing a server to handle more web page requests at once.

FastCGI technology is introduced into Nginx to work with many external tools, i.e.: Perl, PHP and Python. So, you cannot use these unless a FastCGI server has been started.

PHP implementation

There are different ways to run a FastCGI server for PHP. We cover php-fpm, a recommended solution.

Step 1: PHP configuration

The open_basedir in /etc/php/php.ini has to list base directories which contain PHP files, like /srv/http/ and /usr/share/webapps/:

CGI implementation

Systemd

The systemd unit file is currently being discussed on this ArchLinux task page. You may want to examine the unit file yourself to ensure it will work the way you want. Copy the unit file from /usr/lib/systemd/system/fcgiwrap.service to /etc/systemd/system/fcgiwrap.service (and the fcgiwrap.socket unit, if present), and modify the ExecStart line to suit your needs.

If you want to spawn multiple worker threads, it's recommended that you use multiwatchAUR, which will take care of restarting crashed children. You'll need to use spawn-fcgi to create the unix socket, as multiwatch seems unable to handle the systemd-created socket, even though fcgiwrap itself doesn't have any trouble if invoked directly in the unit file. Here is a unit file that uses multiwatchAUR. Make sure fcgiwrap.socket is not started or enabled, because it will conflict with this unit:

Multiple Workers

You can increase the number of worker threads by adding the -F <num> option to the SPAWNER_ARGS variable in /etc/conf.d/fcgiwrap. Although this option will work, you may find it difficult to monitor the workers, because they have no parent process.

A better way to handle multiple worker threads is to use the multiwatch package from the AUR. After installing the package, perform the following configuration to achieve this:

Troubleshooting

Accessing local IP redirects to localhost

Edit /etc/nginx/nginx.conf and locate the "server_name localhost" line without a # infront of it, and add below:

server_name_in_redirect off;

Default behavior is that nginx redirects any requests to the value given as server_name in the config.

Error: 403 (Permission error)

This is most likely a permission error. Are you sure whatever user configured in the Nginx configuration is able to read the correct files?

If the files are located within a home directory, (e.g. /home/arch/public/webapp) and you are sure the user running Nginx has the right permissions (you can temporarily chmod all the files to 777 in order to determine this), /home/arch might be chmod 750, simply chmod it to 751, and it should work.

If you have changed your document root

If you are sure that permissions are as they should be, make sure that your document root directory is not empty. Try creating index.html in there.

Error: 404 (Pathinfo error)

In some framework (like thinkphp, cakephp) or CMS, they need the pathinfo function.

Error: The page you are looking for is temporarily unavailable. Please try again later.

This is because the FastCGI server has not been started, or the socket used has wrong permissions.

Error: No input file specified

Most Likely you do not have the SCRIPT_FILENAME containing the full path to you scripts.
If the configuration of nginx (fastcgi_param SCRIPT_FILENAME) is all right, this kind of error means php fail to load the requestd script. Usually it is simply a permissions issue, you can just run php-cgi as root

# spawn-fcgi -a 127.0.0.1 -p 9000 -f /usr/bin/php-cgi

or you should create some group and user to start the php-cgi. For example:

Another occasion is that, wrong "root" argument in the "location ~ \.php$" section in nginx.conf, make sure the "root" points to the same directory as it in "location /" in the same server. Or you may just set root as global, do not define it in any location section.

Also keep in mind that your php script path was defined as /srv/www/nginx/html by default using the variable "open_basedir" in /etc/php/php.ini; you can change them if you need.

Also notice that not only php script should have read permission, but also the entire directory structure should have execute permission so that PHP user can traverse the path.

Error: chroot: '/usr/sbin/nginx' No such file or directory

If you encounter this error when running the daemon of nginx using chroot, this is likely due to missing 64 bit libraries in the jailed environment.

If you are running chroot in /srv/http you need to add the required 64 bit libraries.

First, set up the directories (these commands will need to be run as root)

# mkdir /srv/http/usr/lib64
# cd /srv/http; ln -s usr/lib64 lib64

Then copy the required 64 bit libraries found using ldd /usr/sbin/nginx to /srv/http/usr/lib64

if run as root, permissions for the libraries should be read and executable for all users, so no modification is required.