Jump to content

Recommended Posts

Posted (edited)
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
  • 4 weeks later...
Posted (edited)

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
  • 1 month later...
  • 1 month later...
Posted

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 ^_^

Posted
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.

Posted

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.

Posted
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

 

Posted

Correct, except if you are running the cron task under the user webapp, you would give that user executable permissions on task.php, not www-data.

Posted (edited)

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
Posted

@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.

Posted (edited)
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
Posted

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.

Posted (edited)
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
Posted

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.

  • 2 weeks later...
Posted

@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. 

 

 

Posted

I keep trying to follow your guy but after setting things up I keep getting a 500 error as im trying to set this up with PHP 7 - is there anything that needs to be done for that version because PHP isn't even running as a service

Posted
18 hours ago, Foxy420 said:

I keep trying to follow your guy but after setting things up I keep getting a 500 error as im trying to set this up with PHP 7 - is there anything that needs to be done for that version because PHP isn't even running as a service

 is php-fpm running?

  • 2 weeks later...
Posted

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

Posted
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.

Posted

hello @Makoto

I follow step by step by your guide, only replacing php5 by php7.0 when installing the php, I have to chance something more to concordance the guide?

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

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