Point the server to the document root<\/h4>\n
The document root <\/strong>(also known as the web server root) is the directory tree that contains files and directories\u00a0that are made available for your web server to deliver to visitors.<\/p>\n Your PHP engine may, in certain circumstances, traverse higher-up\u00a0directories, so you must be very smart about the location of your web server root.<\/p>\n You want your web content to reside\u00a0in either \/var\/www\/<\/span>\u00a0, \/srv<\/span>\u00a0, or \/usr\/share\/www<\/span>\u00a0.<\/p>\n Never use system directories, the home directory of the root user on the system, or the root directory (\/) to serve web content! It’s a no-no. This practice opens up a can of worms and could result in a disaster, should\u00a0a visitor manage to\u00a0coerce your\u00a0web server\/your PHP engine to traverse directories up the directory tree (which isn’t impossible, as you will learn later in this article).<\/p>\n The document root should be defined\u00a0within the server {} block<\/strong> of your site’s configuration file.<\/p>\n Do NOT place your\u00a0document root in the standard document root directory that is part of the installation of NGINX on your system. This directory may be overwritten during an upgrade and there is no recourse for data loss. “You should have known better” (or so the theory), so don’t put anything that’s dear to you\u00a0there.<\/p>\n Set your listen directive correctly, for example (“listen on port 443 on all network interfaces”):<\/p>\n Never use a\u00a0hostname<\/strong> in your server’s listen<\/strong> directive and avoid doing so in an upstream<\/strong> location (you only need an upstream location when you are using NGINX as an HTTP load balancer). Using an\u00a0IP address instead of a hostname is a lot safer because NGINX will be able to bind to it even if it fails to\u00a0resolve the hostname, for example:<\/p>\n If NGINX listens to requests directed at several virtual servers on only one port, it has to decide how to route these requests based on the header alone. To accomplish this, NGINX uses the server_name directive (“respond to requests directed to these host names based on this server block, otherwise route to the default server”):<\/p>\n The first server block that NGINX encounters when parsing its configuration files will be its default server. If you don’t like that, use the default_server <\/b>directive (a property of the listen port, NOT the server name; it defines the default server per port):<\/p>\n Hide NGINX version number (put this in the http block in\u00a0\/etc\/nginx\/nginx.conf):<\/p>\n Don’t use SSLv3 and stay away from TLS v1\/1.1:<\/p>\n Put the index directive either once in the http { } block, or once in each\u00a0server {} block, but not in both. For example:<\/p>\n Do not use ‘If’ statements (if<\/em> you can help it, lol!); the ‘If’\u00a0implementation in NGINX was a half-baked attempt at appeasing some users who considered it a priority at the time. As a result, ‘If’ statements\u00a0waste server resources and are terribly\u00a0inefficient.<\/p>\n Instead of using ifs, use multiple server and location blocks. That’s what they are for. (If you want to know more about the danger of If statements, refer to this article: If Is Evil<\/a><\/em>)<\/p>\n If your purpose for an If statement is checking whether a file exists, NGINX wants you to use\u00a0try_files instead:<\/p>\n This tells the server: try\u00a0$uri and serve it if found; if\u00a0$uri doesn’t exist, try the next best thing which is a directory of that name ($uri\/ with a forward slash at the end), and if that doesn’t exist either, then tough\u00a0luck, fall back to\u00a0\/index.html.<\/p>\n Instead of using a file as the fallback location you can\u00a0use a status code ( You still need a location to catch \\.php$ URIs as otherwise try_files will serve an\u00a0$uri that is found to exist as a plain text file.<\/p>\n To get a CMS system such as WordPress, Drupal or Joomla running, use this (adjust the query string for your CMS if appropriate):<\/p>\n WordPress can even read from (REQUEST_URI):<\/p>\n Do not use this syntax (it will cost you dearly in terms of precious performance):<\/p>\n Instead, put this in the relevant location {} block and it will get you much better results:<\/p>\n For example, if you want to redirect visitors from yoursite.tld using http to www.yoursite.tld using https, this is how to do it the NGINX way: create two separate server blocks and use the return directive like this:<\/p>\n This will redirect all http traffic to yoursite.tld using http to www.yoursite.tld using https.<\/p>\n To redirect\u00a0all traffic from your old domain(s) to your new domain (yournewdomain.tld), use multiple server {} blocks with a return directive (and, optionally, a catch-all server_name) like in this example:<\/p>\n If you are interested in using regular expressions in server names, try this<\/a><\/em>.<\/p>\n How to activate HTTP\/2 with https is covered in this post: How to Activate HTTP\/2 with TLS Encryption in NGINX for Secure Connections without a Performance Penalty<\/a>.<\/p>\n Disallowing the execution of PHP files in any directory that contains user uploads is a good practice on any web server. With NGINX, this is how to best accomplish it:<\/p>\n You can also use the\u00a0try_files directive to filter out the problem condition:<\/p>\n or a nested location: If you want to allow only specific scripts to\u00a0execute, use this in your PHP location block ([backend] is your backend of choice):<\/p>\n The parenthesis in the above example contain a list of allowed script files, delimited with a pipe to signify an OR statement.<\/p>\n If you use a proxy, do it right. One way is this:<\/p>\n This will also work fine:<\/p>\n In the above example, if the URI is not a file or directory, it gets\u00a0passed on to your proxy.<\/p>\n Verify the status of NGINX after installation:<\/p>\n Enable automatic launch of NGINX on system startup:<\/p>\n You should see output indicating that a symbolic link has been created by the utility:<\/p>\n Start NGINX (once):<\/p>\n or<\/p>\n At this point, NGINX should be able to serve static pages, assuming that file system permissions and SELinux security contexts are correctly set on the web server document directory (continue reading for more, and see this post<\/a>\u00a0for some tips on SELinux).<\/p>\n Using your web browser, navigate\u00a0to the IP address of the web server, or to the domain\/host name (if correctly configured). You should see the NGINX Welcome page.<\/p>\n Aside from the obvious things like a rogue firewall or a missing DNS resolver, there are a couple of things you need to be aware of.<\/p>\n On AWS, the command to find public addresses of your server (ip addr) will yield the “internal” private IPv4, not your public IPv4 addresses, in addition to any IPv6 addresses (those are always both “private” and “public”). In the listen directive of NGINX, you can use the private IPv4 addresses and IPv6, but not public IPv4 as your instance is unaware of them.<\/p>\n Restart nginx whenever you need to\u00a0apply changes:<\/p>\n When in doubt, clear the browser cache and flush the DNS cache of your local machine.<\/p>\n There are two aspects to setting access permissions: Unix\/GNU Linux file system permissions and SELinux.<\/p>\n It is considered a good practice to run NGINX as the user and group nginx. The installation script may have created them; to verify whether such a user and group exist, use this command:<\/p>\n If these users exist, skip to the section “Create website owners\u00a0and set ownership on the web server document tree” below.<\/p>\n Create a group named nginx:<\/p>\n If such a user does not yet exist in your \/etc\/passwd file, create a new system user (-r) named nginx and set that user’s shell (-s) to\u00a0\/sbin\/nologin so no one can start an interactive shell session with\u00a0nginx’ credentials:<\/p>\n The user is created with a home directory located in\u00a0\/var\/cache\/nginx. (Feel free to empty\u00a0this\u00a0directory if it gets populated from the skeleton directory. The contents of \/var\/cache\/nginx are\u00a0owned by and 777 (rwx) accessible to\u00a0the user nginx with root as the group at 0 (—) permissions and others at 0 (—) as well. The parent directory is owned by root:root with permissions set at 755. This is the default setup on CentOS 7. See section on SELinux below for advanced configuration.)<\/p>\n Add the user nginx to the group nginx:<\/p>\n The ownership of files and directories inside of document root is of paramount importance when it comes to security.<\/p>\n If you think it’s a good idea to assign\u00a0the web server document directory tree to the owner and group nginx (nginx:nginx), think again. This is not the safest way to go about web hosting. Rather, create a separate owner for each web server root directory, then assign the ownership to each site’s respective owner, then add each of these site owners to the group\u00a0nginx alongside the nginx user.<\/p>\n For the simplest configuration possible,\u00a0you do not need an additional user to own the web server document directory. The user and group nginx:nginx will suffice. However, this is not a good practice when running multiple\u00a0<\/i><\/b>websites: each website should have an\u00a0owner of its own and each of these owners should be a member of the nginx group.<\/p>\n If you also happen to run PHP and want to grant\u00a0the web server the ability\u00a0to perform automatic updates of your web applications, then the SAPI service (php-fpm) must run with the permissions of the\u00a0user who owns\u00a0the contents of the installation\u00a0directory it will be asked to keep up to date.\u00a0This also means that you need to ensure that php-fpm starts\u00a0separate pools<\/strong> for each of the websites with the privileges of their respective owners. In the resulting setup, individual web applications will be running in a “sandboxed” environment of sorts. Should one of them become compromised, it will not spill over to the others.<\/p>\n Step 1. Create users to be owners of each website’s directory tree<\/strong><\/p>\n For each website (or web application) that you want to “sandbox”, create a user named websiteowner1.\u00a0If you don’t want this user to have a home (assuming they won’t be signing in) or shell access, create it\u00a0as a system user<\/span> (-r) with no shell (-s):<\/p>\n To create a user with a home directory (for example, for remote access to the web server directory tree using SFTP with keys), use this command:<\/p>\n It creates a user account and the user’s home directory (-m) without granting the user the right to a shell (-s \/sbin\/nologin) and without a private group (-n).<\/p>\n If the use needs to perform uploads using SFTP, it also needs a shell:<\/p>\n TIP: If you need to remove a user, userdel is helpful.<\/p>\n Step 2. Add website owners to the web server group<\/strong><\/p>\n Add the user websiteowner1 to the group nginx:<\/p>\n This user will own the document tree of the website’s root directory with the group set to nginx (websiteowner1:nginx).<\/p>\n Step 3. Correct the ownership on each website’s document directory and its contents<\/strong><\/p>\n Set the\u00a0owner and and group of website 1 using the command (-R for recursive):<\/p>\n Repeat this procedure for each individual website that has its own NGINX root directory. Each site’s web root directory and its contents should be owned by the website owner<\/strong>\u00a0and read-execute-accessible to the group<\/strong> nginx (see section on SELinux for advanced configuration).<\/p>\n Once you adjust the ownership of the web server document directory for each website\/web application, you also need to set correct Unix access permissions<\/strong> on it (750 for directories, 640 for files).<\/p>\n Which specific permissions you need for various objects depends on the type of content you intend to be serving.<\/p>\n Rule No. 1: NEVER use 777.<\/span> <\/strong>(If 750\/640 permissions on directories\/files seem insufficient, SELinux could be the problem; for troubleshooting SELinux see further below.) Since the master process of NGINX runs with\u00a0root permissions and spawning worker processes as\u00a0user nginx (or a similar unprivileged user), if you were to set permissions to 777, you could enable any user to run any code as root. Do not do this!<\/p>\n Rule No. 2. The web server should never have the ability to modify the files it is executing.<\/strong><\/span><\/p>\n The web server needs the following permissions on its document directory tree<\/strong>:<\/p>\n The service that will be writing to the directory tree (php-fpm) needs the following permissions on files and directories contained within:<\/p>\n In short:<\/p>\n Unlike binaries and shell scripts, interpreted scripts such as PHP or Ruby\u00a0work just fine without the execute permission (x).<\/strong> However, in order to traverse (enter) a directory, the\u00a0execute permission on that directory<\/strong>\u00a0is nonetheless required. The web server needs this permission to list the contents of a directory or serve any files that are located inside of it.<\/p>\n To set permissions on the web server document directory tree for files and directories, use these commands:<\/p>\n All files receive the permissions 640\u00a0(-rw-r—–) and all directories are 750 (drwxr-x—). Because the group nginx is assigned\u00a0to all files and directories, the user nginx who belongs to this group alongside the website owners can read<\/strong> these files, but (unlike the website owners) cannot write<\/strong> to them. Directories that\u00a0must be written to, such as the upload directory, are a special case and will be discussed later below.<\/p>\n WARNING:<\/span> Be careful to apply the above permissions to the home directory of each site and its contents only. Changing the parent path in this way will produce the dreaded “No input file specified.” error. This simply means that NGINX is denied access to the web server document directory (see Step 5 below for details). The correct permissions on it are:<\/p>\n To traverse (enter) a directory and list its contents, the web server needs the execute<\/strong> permission (x) on that directory<\/strong> and all its parent directories. When it comes to serving content from a\u00a0directory, it also needs the read<\/strong> permission on the files<\/strong> contained within it.\u00a0Granting the web server the execute permission for the directory tree and the read permission for files as a member of the group (not the owner, and not “other” users) should suffice.<\/p>\n Verify that NGINX is allowed to traverse directories down to the web server document directory of each site:<\/p>\n In the above\u00a0example, the x privilege allows everyone including “other users” to traverse the directory tree down to \/var\/www. \u00a0The website directory is accessible to the website owner and the group. The web server, as a member of this group, can traverse the directory (x) and list its contents.<\/p>\n Once this is done, there are still a few things on the to-do list:<\/p>\n When running a CMS that is expected to have the ability to upload files (such as updates) you will have\u00a0to make special provisions in order to ensure security while giving some processes the ability to write to web server directories.<\/p>\n Before you go there, however, you need to get PHP up and running.<\/p>\n Nginx uses php-fpm as it’s SAPI (server API). We covered the installation of\u00a0PHP 7.x in this post<\/a>. In this post, you’ll learn how to configure it to work with NGINX.<\/p>\n In short: install the remi repo, install PHP with modules, enable it to launch\u00a0during system startup, configure, restart, done!<\/p>\n In your web browser, navigate to the Remi repo<\/a> configuration wizard:<\/p>\n Select the parameters of your desired installation and follow the directions.<\/p>\n Here is an example for PHP 7.2.6 on Fedora 28.<\/p>\n First, install the remi repository configuration package:<\/p>\n Next, install your PHP modules, for example:<\/p>\n Start PHP once:<\/p>\n Should the\u00a0PHP-FPM service fail to start, read this post on troubleshooting SELinux for php-fpm<\/a>.<\/p>\n Enable automatic launch on system startup:<\/p>\n You should see output resembling this line:<\/p>\n To find out the status of php-fpm, ask your system:<\/p>\n This means that the php-fpm.service is running with a master process pool spun in accordance with the configuration file:<\/p>\n Navigate to the parent directory of the main php-fpm configuration\u00a0file on your system (php-fpm.conf). List the contents of this directory,\u00a0and you will find php.ini<\/strong>, the main configuration file that controls the behavior of the PHP interpreter, as well as various other configuration files including those that initiate pools:<\/p>\n Next, adjust settings in your php.ini.<\/p>\n Path info is information appended to\u00a0the URI of a PHP script. Path info, generally speaking, starts with a forward slash and\u00a0ends before the query arguments that begin\u00a0with a question mark (?).<\/p>\n With cgi.fix_pathinfo enabled, PHP can tell\u00a0 Since\u00a0nonexistent.php cannot be found in the file system, while\u00a0malicious.jpg is found in the location stipulated by the URI, nonexistent.php is deemed to be PATH_INFO and malicious.jpg it is considered a script, and executed.<\/p>\n A partial fix to the\u00a0problem consists of\u00a0disallowing the execution of anything that does not end in .php. Recent versions of PHP-FPM set the default correctly, but it never hurts to verify.<\/p>\n To confirm\u00a0that\u00a0the version installed on your system is using correct defaults, open the configuration file www.conf (and its equivalent for each of the other pools you configured) on your system and\u00a0find a\u00a0parameter named\u00a0security.limit_extensions. The default value in PHP 7 is:<\/p>\n Should you come across some compatibility issues, you may need to adjust this setting, for example:<\/p>\n Even disallowing the execution of anything that does not end in .php is not completely fool-proof. For this very reason, the makers of NGINX recommend you set the\u00a0cgi.fix_pathinfo parameter in your php.ini to 0:<\/p>\n With this option set, the PHP interpreter is only allowed to execute the script specified literally by the\u00a0URI, not any variations of it.<\/strong><\/p>\n Tip: if your configuration changes don’t reflect in your browser, clear caches (browser and DNS resolver), or change the browser.<\/p>\n In the same directory as php.ini, you will find\u00a0the directory php-fpm.d and in it the file www.conf<\/strong>. This file sets up the initial pool.<\/p>\n HINT: If you are not sure how to find the location, execute<\/p>\n in the command line and look for the location of the php-fpm master process.<\/p>\n The file you are looking for is located at the same location, inside of the php-fpm.d<\/strong> directory.<\/p>\n Open it in a text editor of your choice. Find these two lines:<\/p>\n and change them to:<\/p>\n This setting necessitates\u00a0that nginx be the owner<\/strong> of the web server document directory and its contents; otherwise, the web application won’t be able to change files (membership in\u00a0the group should not<\/strong> be sufficient for write access! inside of the web server document directory). It is a good practice to create separate Unix\/Linux users and assign them ownership of their respective website directories (see section Adding pools for multiple website owners<\/em> below for details on how to do this).<\/p>\n FastCGI requests between NGINX and php-fpm can be passed back and forth either with the help of a Unix socket or via TCP\/IP; sockets are slightly faster but a lot less scaleable than TCP\/IP connections. If you want to use a Unix socket, you’ll have to uncomment the lines<\/p>\n (otherwise, leave them unchanged), and also adjust the corresponding setting in your site’s config file (otherwise, don’t touch the defaults).<\/p>\n If you want your PHP application(s) to be able\u00a0to write to a website’s\u00a0document directory, PHP must spawn a\u00a0pool for this application\u00a0with the permissions of the owner of that\u00a0document directory (a\u00a0web server document\u00a0directory and its contents must not be writable by the group!).<\/p>\n For php-fpm to initialize an\u00a0additional\u00a0pool, create a\u00a0copy of\u00a0the www.conf file:<\/p>\n rename the pool it contains:<\/p>\n If you are using TCP sockets, assign the new pool a higher port number for the TCP socket:<\/p>\n Change the user and group as follows:<\/p>\n In the NGINX configuration file of the same website, remember to adjust the port number to the exact same port its pool will be using.<\/p>\n After that, restart both services (php-fpm and nginx).<\/p>\n Correct the SELinux labels on the configuration file of the newly created pool:<\/p>\n If you encounter any other problems, they are most likely due to a misconfiguration of SELinux (see this post on troubleshooting SELinux for TCP sockets<\/a>).<\/p>\n MariaDB 5.x is drop-in compatible with MySQL. Having said that, you may want to remove MySQL if it is installed on your system, and use the 10.x branch of MariaDB (or above).<\/p>\n Create a new text file containing the configuration of the official\u00a0MariDB repository for your system, for example for CentOS 7:<\/p>\n and save it in this directory:<\/p>\n Install MariaDB using:<\/p>\n On Fedora:<\/p>\n Unless you already\u00a0have the MariaDB GPG Signing key on your system, YUM will prompt you to install it after downloading the packages and\u00a0before installing them. Manual installation of the GPG key using the rpm takes this oneliner:<\/p>\n Start MariaDB (once):<\/p>\n Enable automatic launch of MariaDB on system startup:<\/p>\n Verify if MariaDB is running:<\/p>\n Securing your installation\u00a0of MariaDB works just the same as for MySQL and begins with the command:<\/p>\n Follow the onscreen instructions.<\/p>\n If you are seeing this error:<\/p>\n you need to install the extension:<\/p>\n Download your CMS with wget to a temp directory (grab the download link from the download page of your CMS). Unzip the archive and copy its contents into the web server document directory for your intended website.<\/p>\n In order for the CMS to access your database, you need an unprivileged database user (never the database root!) and the database. The CMS system has a way to store this information for future access. Follow the setup instructions. For WordPress, the installation is described below but the principle is always more or less the same.<\/p>\n To create a database user and\u00a0the database in MySQL or MariaDB, you can use the mysql\u00a0client in the command line. Connect using:<\/p>\n Enter the root password. Once you are signed in and greeted with the MySQL prompt, create a new user and the database:<\/p>\n As soon as you create a new database, you have to IMMEDIATELY grant all privileges on it to the mysql root:<\/p>\n To verify the changes, use these commands:<\/p>\n Now you can flush privileges and exit:<\/p>\n If you are using WordPress, copy the file wp-config-sample.php to its intended location:<\/p>\n Next, open it in a text editor of your choice.<\/p>\n Find the lines that define the four parameters and make adjustments so that the parameters’s values match the settings in mysql:<\/p>\n Also, make sure you follow the instructions detailed\u00a0in the section\u00a0Authentication Unique Keys and Salts in wp-config.php.<\/p>\n Save the file.<\/p>\n Next, navigate to your WordPress installation in a web browser of your choice in order to set up the access of the first WordPress administrator to the administrative backend of your CMS. Do NOT enter here any user credentials that you have ever previously used: this is NOT a Unix\/Linux system user and NOT a mysql user. This is a new administrator of the CMS that will only ever access it in the web browser.<\/p>\n If you decide to use a different\u00a0WordPress Database Table prefix than the default, make sure that you replace the default (wp_) with\u00a0the new\u00a0value\u00a0in wp-config.php in a\u00a0line that looks like this:<\/p>\n In the\u00a0default configuration, WordPress is\u00a0unable to\u00a0upload updates or anything else for that matter\u00a0without FTP\/FTPS credentials. Since FTP can present a security vulnerability,\u00a0you may want to opt out of this entirely and either install a plug-in for key pair based authentication or allow for direct uploads via PHP.<\/p>\n In order to bypass the default request for FTP(S) credentials, open wp-config.php and enter this line:<\/p>\n right before the editable section ends with this line:<\/p>\n Whether this setting immediately\u00a0reflects\u00a0in the behavior of WordPress depends\u00a0on whether\u00a0your file system access privileges and the SELinux security contexts or relevant files and directories\u00a0are set correctly. This is the next thing you should tackle (see below).<\/p>\n Even after\u00a0you have adjusted the\u00a0ownership of files and directories within the web server root and set correct access permissions\u00a0on the entire web server\u00a0directory tree and its contents, NGINX may\u00a0still refusing to serve files with the 403 excuse (access denied).<\/p>\n Or, in a more subtle but no less unnerving scenario, your web application may fail to perform activities that depend on its ability to create or write to directories, such as installing or updating plug-ins by WordPress.<\/p>\n If either\u00a0is the case, you should look into adjusting alternative access methods such as SELinux.<\/p>\n (Nothing else, not even adding<\/p>\n to wp-config.php will fix the problem unless SELinux context labels are correctly set.) Still need convincing? A look at the audit log can help you find the culprit:<\/p>\n Simply deactivating SELinux is not the wisest course of action. SELinux is not the evil it’s made out to be. Don’t deactivate it, tame it.<\/p>\n In order to understand what’s at stake here it helps being able to view the SELinux labels on files and directories.<\/p>\n For a full directory listing that includes SELinux security context, use the -Z option with ls, for example:<\/p>\n where\u00a0www.yourwebstite.tld is the web server root directory.<\/p>\n In order to view\u00a0the\u00a0SELinux context for the master and worker processes of NGINX, use the following\u00a0command:<\/p>\n The command reveals the user NGINX is running as. It selects ‘nginx’ from all running processes (option -e is interchangeable with -A for ‘all’) and\u00a0requests full-format listing (-f ;\u00a0use option -F for extra full options).<\/p>\n To verify which adjustments of\u00a0the SELinux security context are required to conform to the defaults, run restorecon without writing any changes (-n):<\/p>\n The\u00a0verbose output of this command should give you an idea as of what’s going to happen when you omit the -n flag.<\/p>\n In order to apply SELinux defaults\u00a0that are inherited from the parent directory \/var\/www, use the above command without the -n option:<\/p>\nserver {\r\n server_name www.yourdomain.com;\r\n root \/var\/www\/nginx-default\/;\r\n location \/ {\r\n # [...]\r\n }\r\n location \/foo {\r\n # [...]\r\n }\r\n location \/bar {\r\n # [...]\r\n }\r\n}<\/pre>\n![\"The](\"https:\/\/www.cloudinsidr.com\/content\/wp-content\/uploads\/2015\/12\/nginx_default_directory_.png\")
<\/a>Tell the server how to listen to incoming requests<\/h4>\n
server {\r\n listen<\/strong> 443 ssl http2; # IPv4\r\n listen<\/strong> [::]:443 ssl http2; # IPv6<\/pre>\nupstream {\r\n server http:\/\/10.48.41.12;\r\n}\r\n\r\nserver {\r\n listen 127.0.0.16:80;\r\n # [...]\r\n}<\/pre>\nConfigure routing requests to virtual hosts based on server_name<\/h4>\n
server {\r\n server_name<\/strong> www.cloudinsidr.com cloudinsidr.com;\r\n}<\/pre>\nlisten 443 default_server<\/b>;<\/pre>\n
Hide Nginx version number<\/h4>\n
server_tokens off;<\/pre>\n
Permit only the most secure TLS versions<\/h4>\n
ssl_protocols TLSv3 TLSv1.2;<\/pre>\n
Specify\u00a0the index (only\u00a0once!)<\/h4>\n
http {\r\n index<\/strong> index.php index.htm index.html;\r\n server {\r\n server_name www.yourdomain1.com yourdomain1.com;\r\n location \/ {\r\n # [...]\r\n }\r\n }\r\n server {\r\n server_name www.yourdomain2.com yourdomain2.com;\r\n location \/ {\r\n # [...]\r\n }\r\n location \/foo {\r\n # [...]\r\n }\r\n }\r\n}<\/pre>\nDo not use If statements: use multiple server and location blocks<\/h4>\n
server {\r\nroot \/var\/www\/www.domain.com;\r\nlocation \/ {\r\ntry_files $uri $uri\/ \/index.html;\r\n}\r\n}<\/pre>\n=404<\/code>), but if you do point to\u00a0a file for fallback,\u00a0the file\u00a0must exist<\/strong>. One other thing worth noting: try_files will not issue an internal redirect for anything but the last parameter.<\/p>\ntry_files $uri $uri\/ \/index.php?q=$uri&$args;<\/pre>\n
try_files $uri $uri\/ \/index.php;<\/pre>\n
Implementing redirects: do not use rewrites, use multiple (server) blocks and\u00a0the return directive<\/h4>\n
# DO NOT use this syntax!!! Use the return directive instead!\r\nrewrite ^\/(.*)$ http:\/\/exampledomain.tld\/$1 permanent;<\/pre>\n
return 301 https:\/\/exampledomain.tld$request_uri;<\/pre>\n
server {\r\n listen 80;\r\n server_name yoursite.tld;\r\n return 301 https:\/\/www.yoursite.tld$request_uri;\r\n}\r\n\r\nserver {\r\n listen 443 ssl http2;\r\n listen [::]:443 ssl http2; \r\n server_name www.yoursite.tld;\r\n ...\r\n}<\/pre>\nserver {\r\n listen 443;\r\n server_name yournewdomain.tld www.yournewdomain.tld;\r\n ...\r\n}\r\n\r\nserver {\r\n listen 80 default_server<\/strong>;\r\n # the following line is a catch-all server name\r\n server_name _;\r\n return 301 http:\/\/yournewdomain.tld$request_uri;\r\n}<\/pre>\nDisallow\u00a0the execution of PHP files in any directory that allows uploads by a user<\/h4>\n
location \/path\/to\/uploads { location ~ \\.php$ {return 403;} # [...] }<\/pre>\nlocation ~* \\.php$ {\r\n try_files $uri =404;\r\n fastcgi_pass [backend];\r\n # [...]\r\n}<\/pre>\n
\n<\/span><\/p>\nlocation ~* \\.php$ {\r\n location ~ \\..*\/.*\\.php$ {return 404;}\r\n fastcgi_pass [backend];\r\n # [...]\r\n}<\/pre>\n(Optional, for the paranoid) Allow only specific scripts to\u00a0execute<\/h4>\n
location ~* (file_a|file_b|file_c)\\.php$ {\r\n fastcgi_pass [backend];\r\n # [...]\r\n}<\/pre>\nUse a proxy the right way<\/h4>\n
server {\r\n server_name _;\r\n root \/var\/www\/site;\r\n location \/ {\r\n try_files $uri $uri\/ @proxy;\r\n }\r\n location @proxy {\r\n include fastcgi_params;\r\n fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;\r\n fastcgi_pass unix:\/tmp\/phpcgi.socket;\r\n }\r\n}<\/pre>\nserver {\r\nserver_name _;\r\nroot \/var\/www\/site;\r\nlocation \/ {\r\ntry_files $uri $uri\/ \/index.php;\r\n}\r\nlocation ~ \\.php$ {\r\ninclude fastcgi_params;\r\nfastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;\r\nfastcgi_pass unix:\/tmp\/phpcgi.socket;\r\n}\r\n}<\/pre>\nEnable NGINX on startup<\/h4>\n
systemctl status nginx<\/pre>\n
systemctl enable nginx<\/pre>\n
ln -s '\/usr\/lib\/systemd\/system\/nginx.service' '\/etc\/systemd\/system\/multi-user.target.wants\/nginx.service'<\/pre>\n
Start NGINX<\/h4>\n
service nginx start<\/pre>\n
systemctl start nginx<\/pre>\n
Tips for troubleshooting connectivity problems<\/h4>\n
service nginx restart<\/pre>\n
![\"ipconfig](\"https:\/\/www.cloudinsidr.com\/content\/wp-content\/uploads\/2015\/12\/ipconfig_flushdns.png\")
<\/a>Setting correct permissions for NGINX<\/h3>\n
cat \/etc\/passwd<\/pre>\n
Create the user and group nginx<\/h4>\n
groupadd nginx<\/pre>\n
useradd -s \/sbin\/nologin -r -d \/var\/cache\/nginx nginx<\/pre>\n
usermod -G nginx nginx<\/pre>\n
Create website owners\u00a0and set ownership on the web server document tree<\/h4>\n
useradd websiteowner1 -r -s \/sbin\/nologin<\/pre>\n
useradd -md \/home\/websiteowner1 -s \/sbin\/nologin websiteowner1<\/pre>\n
<\/pre>\n
usermod -s \/bin\/bash username<\/pre>\n
usermod -G nginx websiteowner1<\/pre>\n
chown -Rf websiteowner1:nginx \/var\/www\/www.website1-root.tld<\/pre>\n
Step 4. Correct file access permissions on the web server directory and its contents<\/h4>\n
\n
\n
\n
Set correct permissions for interpreted scripts and directories<\/h5>\n
find \/var\/path\/to\/web\/directory -type f -exec chmod 640 {} \\;\r\nfind \/var\/path\/to\/web\/directory -type d -exec chmod 750 {} \\;<\/pre>\ndrwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 www<\/pre>\n
Step 5. Verify\u00a0if NGINX is allowed to traverse the directory tree down to the root directory of each site<\/strong><\/h4>\n
namei -l \/var\/www\/www.youwebsite.tld\/\r\nf: \/var\/www\/www.youwebsite.tld\/\r\ndr-xr-xr-x root root \/\r\ndrwxr-xr-x root root var\r\ndrwxr-xr-x nginx nginx www\r\ndrwxr-x--- websiteowner1 nginx www.youwebsite.tld<\/pre>\n
\n
Special considerations for\u00a0PHP applications with the ability to write to the web server document directory<\/h5>\n
Set Up PHP 7.x<\/h3>\n
Install the repository<\/h4>\n
https:\/\/rpms.remirepo.net\/wizard\/<\/pre>\n
![\"Remi](\"https:\/\/www.cloudinsidr.com\/content\/wp-content\/uploads\/2015\/12\/RemiRepo_wizard.png\")
<\/a>dnf install http:\/\/rpms.remirepo.net\/fedora\/remi-release-28.rpm<\/pre>\n
dnf --enablerepo=remi-php70 install php70-php-pear php70-php-bcmath php70-php-pecl-jsond-devel php70-php-mysqlnd php70-php-gd php70-php-common php70-php-fpm php70-php-intl php70-php-cli php70-php php70-php-xml php70-php-opcache php70-php-pecl-apcu php70-php-pecl-jsond php70-php-pdo php70-php-gmp php70-php-process php70-php-pecl-imagick php70-php-devel php70-php-mbstring php70-php-mcrypt<\/del><\/pre>\ndnf install php php-mcrypt php-cli php-gd php-curl php-mysql php-ldap php-zip php-fileinfo<\/pre>\n
Enable\u00a0PHP launch on system startup<\/h4>\n
systemctl start php-fpm<\/pre>\n
systemctl enable php-fpm<\/pre>\n
ln -s '\/usr\/lib\/systemd\/system\/php-fpm.service' '\/etc\/systemd\/system\/multi-user.target.wants\/php-fpm.service'<\/pre>\n
Find info.php on your system<\/h4>\n
systemctl status php-fpm.service<\/pre>\n
![\"Output](\"https:\/\/www.cloudinsidr.com\/content\/wp-content\/uploads\/2015\/12\/systemctl_status_php-fpm.png\")
<\/a>\/etc\/php-fpm.conf<\/pre>\n
# ls -lat . | grep -i php\r\ndrwxr-xr-x. 2 root root 4096 Jun 18 15:50 php-fpm.d\r\ndrwxr-xr-x. 2 root root 4096 Jun 18 15:50 php.d\r\ndrwxr-xr-x. 2 root root 4096 Jun 18 15:50 php-zts.d\r\n-rw-r--r--. 1 root root 4023 May 23 08:26 php-fpm.conf\r\n-rw-r--r--. 1 root root 62221 May 23 08:26 php.ini<\/pre>\n
Fix your server’s Path Info behavior\u00a0\u00a0in php.ini (What is PATH_INFO\u00a0and why would\u00a0you care?)<\/h4>\n
http:\/\/www.domain.com\/path\/to\/a\/php-script.php\/PATH_INFO?query_args=foo<\/pre>\n
PATH_INFO<\/code> and SCRIPT_FILENAME<\/code>\u00a0apart (the latter one defined as the script file name prefixed with the document root).\u00a0This behavior opens up a security vulnerability<\/strong>, however: when calling a non-existent PHP script that’s appended to an image file, it is possible to execute malicious code in that file. (Since image files\u00a0can contain arbitrary code, it is possible \u00a0for a malicious user to craft an image that contains valid PHP that may be executed when the attacker exploits PATH_INFO.)\u00a0An example URI with that effect could look something like this:<\/p>\nhttp:\/\/www.domain.com\/malicious.jpg\/nonexistent.php<\/pre>\n
security.limit_extensions = .php<\/pre>\n
security.limit_extensions = .php7<\/pre>\n
cgi.fix_pathinfo=0<\/pre>\n
Configure the initial pool<\/h4>\n
systemctl status php-fpm | \u00a0grep \"master process\"<\/pre>\n
![\"php-fpm](\"https:\/\/www.cloudinsidr.com\/content\/wp-content\/uploads\/2015\/12\/php-fpm_master_process-1024x71.png\")
<\/a>user = apache\r\ngroup = apache<\/pre>\n
user = nginx\r\ngroup = nginx\r\n<\/pre>\n
;listen.owner = nobody\r\n;listen.group = nobody<\/pre>\n
Adding pools for multiple website owners<\/h4>\n
cp www.conf www.website1.tld.conf<\/pre>\n
[www]<\/del> [websiteowner1]<\/pre>\nlisten = 127.0.0.1:9009<\/pre>\n
user = websiteowner1\r\ngroup = nginx<\/pre>\n
chcon -R -v system_u:object_r:etc_t:s0\u00a0www.websitename1.com.conf\r\nrestorecon www.websitename1.com.conf<\/pre>\n
Set up MariaDB (a replacement for MySQL)<\/h2>\n
Add the official repository<\/h3>\n
[mariadb]\r\nname = MariaDB\r\nbaseurl = http:\/\/yum.mariadb.org\/10.1\/centos7-amd64\r\ngpgkey=https:\/\/yum.mariadb.org\/RPM-GPG-KEY-MariaDB\r\ngpgcheck=1<\/pre>\n
\/etc\/yum.repos.d\/<\/pre>\n
Install MariaDB<\/h3>\n
yum install MariaDB-server MariaDB-client<\/pre>\n
dnf install mariadb mariadb-server<\/pre>\n
sudo rpm --import https:\/\/yum.mariadb.org\/RPM-GPG-KEY-MariaDB<\/pre>\n
Start MariaDB<\/h3>\n
systemctl start mariadb<\/pre>\n
systemctl enable mariadb<\/pre>\n
systemctl status mariadb<\/pre>\n
Secure your installation immediately<\/h4>\n
mysql_secure_installation<\/pre>\n
YourPHP installation appears to be missing the MySQL extension which is required by WordPress.<\/pre>\n
dnf install php-mysql<\/pre>\n
Set up\u00a0WordPress (or another CMS of your choice)<\/h3>\n
Create an unprivileged database user and a database<\/h5>\n
mysql -u root -p<\/pre>\n
CREATE USER 'dbuser'@'localhost';\r\n\r\nselect * from mysql.user;\r\n\r\ncreate database db_name;\r\n\r\nGRANT ALL PRIVILEGES ON db_name.* TO dbuser@localhost IDENTIFIED BY 'mysqldbuserpassword';<\/pre>\n
GRANT ALL PRIVILEGES ON *.* TO root@'::1' IDENTIFIED BY 'rootsownpassword' WITH GRANT OPTION;\r\nSET PASSWORD FOR 'root'@'::1' = PASSWORD('rootsownpassword');<\/pre>\nSHOW GRANTS FOR 'root'@'localhost';\r\nSHOW GRANTS FOR 'Info_wrdp1'@'localhost';<\/pre>\n
flush privileges; exit;<\/span><\/pre>\nEnter database access credentials of the unprivileged user into the WP configuratIon<\/h5>\n
cp\u00a0wp-config-sample.php\u00a0wp-config.php<\/pre>\n
\/** The name of the database for WordPress *\/\r\ndefine('DB_NAME', 'db_name');\r\n\r\n\/** MySQL database username *\/\r\ndefine('DB_USER', 'dbuser');\r\n\r\n\/** MySQL database password *\/\r\ndefine('DB_PASSWORD', 'mysqldbuserpassword');\r\n\r\n\/** MySQL hostname *\/\r\ndefine('DB_HOST', 'localhost');<\/pre>\nAccess your WordPress installation in a web browser to create an admin account<\/h4>\n
$table_prefix \u00a0= 'wp_';<\/pre>\n
Allow write\u00a0operations for updates and plug-in installs: running WordPress without a need for (S)FTP access<\/h4>\n
![\"WordPress:](\"https:\/\/www.cloudinsidr.com\/content\/wp-content\/uploads\/2015\/12\/WordPress_SFTP.png\")
<\/a>define('FS_METHOD','direct');<\/pre>\n\/* That's all, stop editing! Happy blogging. *\/<\/pre>\n
Setting SELinux security context for web server document directories of NGINX<\/h3>\n
![\"403](\"https:\/\/cloudinsidr.com\/content\/wp-content\/uploads\/2015\/12\/403_forbidden.jpg\")
<\/a>![\"An](\"https:\/\/www.cloudinsidr.com\/content\/wp-content\/uploads\/2015\/12\/permissions_conflict_plugins.png\")
<\/a>define('FS_METHOD','direct');<\/pre>\ntail \/var\/log\/audit\/audit.log<\/pre>\n
List files and directories with their respective security context<\/h4>\n
ls -laZ\u00a0\/var\/www\/www.yourwebstite.tld\/<\/pre>\n
View the current SELinux security context for the NGINX master and worker processes while\u00a0running<\/h4>\n
ps -efZ | grep 'nginx'<\/pre>\n
![\"View](\"https:\/\/www.cloudinsidr.com\/content\/wp-content\/uploads\/2015\/12\/nginx_in_SELinux_context-1024x78.png\")
<\/a>restorecon -RFv -n \/var\/www\/<\/pre>\n
restorecon -RFv \/var\/www\/<\/pre>\n