Jump to content

Setting up a secure Nginx+PHP-FPM installation for IPS4


Recommended Posts

18 hours ago, Makoto said:

My guides are written using a template I purchased from ThemeForest a while back.

You can find it here,
http://themeforest.net/item/vsdocs-online-documentation-template/11418861

Eventually I'll have posts/guides like this compiled and posted somewhere online, instead of only available as post snippets here.

This is also the template I use to write the readme's included with my newer applications, such as Bulk Downloader,
https://www.makoto.io/docs/bulkdl/index.html

rz8tpiS.png

 

Those is not bbcodes though? 

 

Perhaps you copy-pasted and it included ur css? lol

Edited by Jimmy Gavekort
Link to comment
Share on other sites

  • 4 weeks later...

Firstly, great tutorial!

Unfortunately I've hit a bump, I can't do the ACL setup (VPS), so I've skipped that part and went on to the PHP-FPM section, however after completing everything I get a 502 Bad Gateway error.

What may the cause of this? I assume it might be the fact that the webapp config isn't right without the ACL setup?

 

EDIT: (Actually it occurs without PHP-FPM running at all)

Edited by Cyrem
Link to comment
Share on other sites

  • 1 month later...
  • 1 month later...

Dear @Makoto

Thank you for so good step-by-step solution, you are Awesome!! Thanks you!

Maybe you get error like i have..

In Admin CP -> Advanced configuration -> Server Environment i try to enable "Use Cron (Recommended)" option. But when i try to Save config system says:

Quote

In order to enable this setting you must make the /path-to-root/applications/core/interface/task/task.php file executable (i.e. chmod 0777).

I try to use
 

chmod +x task.php

w/o any result. I tried restart nginx/fpm, fix perm, and chmod again — no any lucky.

Then i tried fixperm with
 

Which individual files/directories should PHP be granted write access to? applications/core/interface/task/task.php

w/o success

No one had same problem? Or i do something wrong? Help please ^_^

Link to comment
Share on other sites

On 9/5/2016 at 1:30 PM, klierik said:

I try to use


chmod +x task.php

w/o any result. I tried restart nginx/fpm, fix perm, and chmod again — no any lucky.

3

ACL permissions override chmod, so you will need to grant executable permissions to task.php via setfacl instead.

setfacl -m "u:cron-user:r-x" applications/core/interface/task/task.php

Replace "cron-user" with whatever user is executing task via cron.

On 5/26/2016 at 2:07 AM, Cyrem said:

What may the cause of this? I assume it might be the fact that the webapp config isn't right without the ACL setup?

1

Do you see anything in your Nginx error log?

Your error indicates there is an issue communicating with the PHP-FPM backend. Your error log should highlight the specific issue.

Link to comment
Share on other sites

As a side note, regarding the security update in 4.14.1.3 (as it includes Apache specific information):

Quote

This release contains a security update to address a possible issue where uploaded files may execute as scripts. For this to happen, a server must be configured to allow for very loose rules for what is an executable script. Most servers will not be vulnerable to this issue but we have no way of detecting which may be so we are releasing this security update as a precaution.

It is recommended this release is installed as soon as possible.

This new version improves the security of the .htaccess protection for the /uploads folder on your site. If you have already enabled the security feature "Protect Writeable Folders From Dangerous Files", then you will need to manually update the .htaccess file which you can do simply by opening "uploads/.htaccess" in a text editor and replacing its contents with:


#<ipb-protection>
<Files ~ "^.*\.(php|cgi|pl|php3|php4|php5|php6|phtml|shtml|([a-z0-9]{32}))$">
    Order allow,deny
    Deny from all
</Files>
#</ipb-protection>
 

As long as you followed the instructions in this guide (specifically, see the "Rewrite" rules and named location blocks section), you are already completely protected from what IPS is referring to.

This is further prevented (the "correct" way) by ensuring cgi.fix_pathinfo is disabled in your PHP(-FPM) configuration and security.limit_extensions is locked down to only allowing execution of .php scripts in PHP-FPM.

Link to comment
Share on other sites

On September 7, 2016 at 11:26 PM, Makoto said:

Replace "cron-user" with whatever user is executing task via cron.

On May 26, 2016 at 9:07 AM, Cyrem said:

oh, i see... thanks you a lot.

So... this issue can be fixed via set ACL with the same user from "/etc/php5/fpm/pool.d/webapp.conf"

Quote

user = www-data

for example:

setfacl -m "u:www-data:r-x" applications/core/interface/task/task.php

And generate cron task for specific user with http://crontab-generator.org like:

crontab -e -u webapp

and the add to the end of file rule generated with crontab-generator

* * * * * /usr/bin/php -d memory_limit=-1 -d max_execution_time=0 /srv/http/yourdomain.com/root/html/applications/core/interface/task/task.php eeb9e745e6ef2e2c74930ecc3503c77d > /srv/http/yourdomain.com/root/logs/crontab.log

 

Link to comment
Share on other sites

I have these rules.. I'm safe?

server {

server_name domain.net www.domain.net;

add_header X-Content-Type-Options "nosniff" always;
add_header X-Xss-Protection "1; mode=block" always;
add_header X-Content-Type-Options "nosniff" always;  


# ngx_pagespeed & ngx_pagespeed handler
#include /usr/local/nginx/conf/pagespeed.conf;
#include /usr/local/nginx/conf/pagespeedhandler.conf;
#include /usr/local/nginx/conf/pagespeedstatslog.conf;


root /home/nginx/domains/domain.net/public;

include /usr/local/nginx/conf/cloudflare.conf;

location ~ (?:^|/)\. {
  deny all;
}  

location / {
  include /usr/local/nginx/conf/block.conf;
  try_files    $uri $uri/ /index.php;
}




# IP.Board PHP/CGI Protection

# Allow Access to Interface Files
# Add Your Specific Application to the List if you Add New Applications
location ~^(/applications/(blog|calendar|chat|cms|core|downloads|forums|gallery|nexus|pastebin|companydirectory|rules|videos|notes|iawards|links|pmviewer|readthattopic|rules)/interface/).*(\.php)$ {
  allow all;
  include /usr/local/nginx/conf/php.conf;
}

# Block Access to PHP / PHTML Files
location ~ ^/(uploads|datastore|system|plugins)/.*\.(?:php\d*|phtml)$ {
  deny all;
}

# Block Access to Application PHP / PHTML Files
# Add Your Specific Application to the List if you Add New Applications
location ~ ^/applications/(blog|calendar|chat|cms|core|downloads|forums|gallery|nexus|pastebin|companydirectory|rules|videos|notes|iawards|links|pmviewer|readthattopic|rules)/.*\.(?:php\d*|phtml)$ {
  allow 127.0.0.1;
  deny all;
}

location ~* /phpMyAdmin {
	deny all;
	include /usr/local/nginx/conf/php.conf;
}



include /usr/local/nginx/conf/staticfiles.conf;
include /usr/local/nginx/conf/php.conf;
include /usr/local/nginx/conf/drop.conf;
#include /usr/local/nginx/conf/errorpage.conf;
include /usr/local/nginx/conf/vts_server.conf;
}

 

Edited by Jimmy Gavekort
Link to comment
Share on other sites

@Jimmy Gavekort thanks for taking the time to share that, but I'm afraid there's not a practical use for it.

I had a similar set of rules at one point, but considering that the applications folder and so on are ordinarily always left writable, all someone would have to do to get around that is upload malicious scripts to the interface folders. Even if you whitelisted individual scripts in the interface folders, an attacker could still overwrite those files with malicious code.

So it's a lot of hassle for little to no benefit.

Link to comment
Share on other sites

1 minute ago, Makoto said:

@Jimmy Gavekort thanks for taking the time to share that, but I'm afraid there's not a practical use for it.

I had a similar set of rules at one point, but considering that the applications folder and so on are ordinarily always left writable, all someone would have to do to get around that is upload malicious scripts to the interface folders. Even if you whitelisted individual scripts in the interface folders, an attacker could still overwrite those files with malicious code.

So it's a lot of hassle for little to no benefit.

So what do I do to protect my self? lol

I warned IPS about this exploit months ago, met with ignorance and they told me it's my own fault...

Edited by Jimmy Gavekort
Link to comment
Share on other sites

One option is to keep your applications and plugins folders locked down (remove all writable permissions), but you have to be careful when doing this. If you ever need to update or install a new application (including IPS core applications themselves), you must remember to re-enable writable permissions to the folders.

Outside of that, if security is paramount one of the best things to do is implement a Mandatory Access Control system with grsecurity, but this is a very advanced and complicated topic.

Link to comment
Share on other sites

1 minute ago, Makoto said:

One option is to keep your applications and plugins folders locked down (remove all writable permissions), but you have to be careful when doing this. If you ever need to update or install a new application (including IPS core applications themselves), you must remember to re-enable writable permissions to the folders.

Outside of that, if security is paramount one of the best things to do is implement a Mandatory Access Control system with grsecurity, but this is a very advanced and complicated topic.

Welp.

I want to allow the users to upload photos though? 

i do not allow users to upload files at all, but i believe same exploit exists in gallery and avatar.

Edited by Jimmy Gavekort
Link to comment
Share on other sites

Hello,

I am confused what the relations is between webapp and www-data. Could you please explain more? Thanks.

On the other hands, I have got the permission denied issue, and cannot figure it out for long time,could you please help me this?

To debug, I run

# sudo -u nginx stat /datadrive/http/abc.com/root/
stat: cannot stat ‘/datadrive/http/abc.com/root/’: Permission denied

So I double check permission on /datadrive/http/abc.com/root

# ll /datadrive/http/abc.com/
total 12
drwxr-x---  9 webapp webapp 4096 Feb 15  2016 demo
drwxr-x---+ 5 webapp webapp 4096 Sep 16 22:58 root

# getfacl /datadrive/http/abc.com/root
getfacl: Removing leading '/' from absolute path names
# file: datadrive/http/abc.com/root
# owner: webapp
# group: webapp
user::rwx
user:www-data:r-x
user:nginx:r-x
group::r-x
mask::r-x
other::---
default:user::rwx
default:user:www-data:r-x
default:user:nginx:r-x
default:group::r-x
default:mask::r-x
default:other::---

# vim /etc/group
nginx:x:987:
webapp:x:986:
www-data:x:985:nginx

Everything seems correct, do you know what is wrong? Thanks.

Hello,

I am confused what the relations is between webapp and www-data. Could you please explain more? Thanks.

On the other hands, I have got the permission denied issue, and cannot figure it out for long time,could you please help me this?

To debug, I run

# sudo -u nginx stat /datadrive/http/abc.com/root/
stat: cannot stat ‘/datadrive/http/abc.com/root/’: Permission denied

So I double check permission on /datadrive/http/abc.com/root

# ll /datadrive/http/abc.com/
total 12
drwxr-x---  9 webapp webapp 4096 Feb 15  2016 demo
drwxr-x---+ 5 webapp webapp 4096 Sep 16 22:58 root

# getfacl /datadrive/http/abc.com/root
getfacl: Removing leading '/' from absolute path names
# file: datadrive/http/abc.com/root
# owner: webapp
# group: webapp
user::rwx
user:www-data:r-x
user:nginx:r-x
group::r-x
mask::r-x
other::---
default:user::rwx
default:user:www-data:r-x
default:user:nginx:r-x
default:group::r-x
default:mask::r-x
default:other::---

# vim /etc/group
nginx:x:987:
webapp:x:986:
www-data:x:985:nginx

Everything seems correct, do you know what is wrong? Thanks.

Link to comment
Share on other sites

  • 2 weeks later...

@Makato

Thanks for the guide. I used it and had one issue. For this part of the /etc/nginx/nginx.conf

gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

you need to add

application/javascript

as well. Otherwise some of the JS elements in IPB wont compress (and google pagespeed analyzer will complain). 

 

e.g.

$ curl -H "Accept-Encoding: gzip" -I https://www.example.com/uploads/javascript_global/root_framework.js.20da77cb1214419f844616d0b36c0ee4.js
HTTP/1.1 200 OK
Server: nginx/1.11.4
Date: Wed, 05 Oct 2016 21:33:25 GMT
Content-Type: application/javascript
Content-Length: 331572
Last-Modified: Wed, 05 Oct 2016 04:37:47 GMT
Connection: keep-alive
ETag: "57f4839b-50f34"
Strict-Transport-Security: max-age=31536000; includeSubdomains;
X-Content-Type-Options: nosniff
Accept-Ranges: bytes

^ didnt compress the application/javascript. 

 

 

Link to comment
Share on other sites

  • 2 weeks later...
17 hours ago, kmk said:

Hello,

I try follow this guide to set up nginx on my dreancompute instance, till using scripts 


/etc/nginx/scripts/fixperms yourdomain.com root

Then appear problem, see picture, what should I do?

Capture.PNG

Hello,

I forget the "sudo", with this resolved the issue.

Link to comment
Share on other sites

  • 3 weeks later...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...