Jump to content

Invision Community Blog

Managing successful online communities

Sign in to follow this  

Securing your community

There has been much confusion over the recent exploit reported to us and subsequently patched. I would like to personally apologize for any confusion and inconvenience caused. We have conducted a review and made appropriate changes to our policies to ensure a smoother release and notification schedule for any future incidents.

With that said, it is very important to note that while an IP.Board vulnerability did exist, its impact would have been minimal, if not non-existent on servers that have their PHP installations properly secured. I would like to touch on a couple of basics to minimize the effects of future vulnerabilities not only in IP.Board, but any other PHP application you may be using on your website.


It's very important that you (if you manage your own web hosting server) or your web host enable open_basedir. In a shared hosting environment without open_basedir, an attacker has the ability to exploit a vulnerability, perhaps on another customer's account, then use that vulnerability to scan for other customers on the server. From there, they could gain access to config files containing database details, write malicious files to world-writeable directories and a host of other ill-willed activities. Enabling open_basedir "locks" all internal PHP functions such as readfile() to the specified path, which is generally a temporary directory and your home directory.


While open_basedir is a very positive step in securing your PHP scripts, there are unfortunately instances in which it can be bypassed and this is how the recent IP.Board vulnerability gained ground so quickly. For example, the exec(), system() and passthru() functions allow a command to be issued directly to the operating system to view key system files, navigate through other users' web root directories, install 'remote shell' scripts into other users' directories, etc. without any regard to other restrictions such as open_basedir. For this reason, disable_functions should be set to disable system level functions. For example, this is a recommended disable_functions:


disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system

You or your host may need to tweak to suit, but at a minimum, execution commands should be disabled.

Following the above, you will not necessarily create a fool-proof environment, but you will have additional reassurances that you or your host have taken appropriate measures to better secure your PHP applications.

For those that run a cPanel/WHM server you may enable open_basedir by visiting WHM and clicking the "PHP open_basedir Tweak" link under "Security Center" then clicking enable.

You may modify the disable_functions line by visiting WHM and clicking "PHP Configuration Editor" under "Service Configuration" then clicking "advanced" and searching for "disable_functions"

If you are unsure or do not have the necessary permissions to carry out these tasks, please do contact your host. You are free to link them to this blog entry as well.

I hope this helps better explain the recent security concern and what you can do to help protect yourself and your users in the future. As always, please feel free to contact us with any questions or concerns you might have. Thank you for your cooperation and understanding.

Sign in to follow this  


Recommended Comments


It does concern me as I'm run a IPS applications and worry about security as well. Please keep your "smart" remarks to yourself as they are not needed in such a place.

Do you manage your server?

The given answer is valid, if you do not know what any of this means, point your host at the entry.

If you do manage your own server and do not know what any of this means, god help you.

Share this comment

Link to comment
Share on other sites

yes, I manage my own server, and I know only enough to make me extremely dangerous.  The most oft-cited phrase in my world is from the support folks at Media Temple: "I'm afraid that is outside our scope of support."


Since religion has no meaning to me, I gaze upon the ocean and send server-dudes a pm or two or twenty.... hoping they can help!!

Share this comment

Link to comment
Share on other sites

It basically means there is nothing passed in the open_basedir. Try putting "open_basedir = 1" as the "1" normally means "enable" or "on".

I am not good at this; my question to clerify what I need to do on my server...

I have no value, so what do i need to change to make my server more secure...


=1 or on or I don't need to change anthing in that case no value works just fine????


Share this comment

Link to comment
Share on other sites

This is a great blog, for the past week, my site has been hacked twice.  The first time I realized I did not harden my sever enough.  I spent a lot of time hardening apache, using iptables, changing ssh port, blocking mysql port and so on.


I thought I did a great job and then yesterday server got hacked again.  Luckily I had a backup of my entire /var/www/html and restored it and everything was fine.  I really do not know what the hacker is doing, except breaking the site where i get no access to the admin panel, and anyone who tried to login would get a white screen.  I think the attacker was dropping some sort of php files and it cause the site to break.



I tried to install mod_security and seem to work but when I applied ModSecurity Core Rule Set, my site went down, could not do anything.  I had to disable.  Does anyone have a good set of rules specifically that will work with IP board?



Also does anyone know is php 5.4 more secure then 5.3.18?  If so will it work fine with ipboard 3.3.4?  Also is apahce 2.4 more secure then 2.2.15?  What about nginx vs apache in terms of security?




Share this comment

Link to comment
Share on other sites

I don't really see the point in disabling escapeshellarg, escapeshellcmd, and parse_ini_file. None of them actually allow for any sort of code execution, and parse_ini_file is limited by the open_basedir setting. Other scripts may rely on some of these in order to do whatever it is they do (namely the use of parse_ini_file as a builtin method of reading non-php configuration files). Beyond that, the rest of those look sane and should certainly be disabled if they are not needed for other applications (MediaWiki, for example, needs access to shell_exec if you want to use ImageMagick or rsvg for thumbnailing, but it is not required if you use GD instead).


Other security points I feel that were missed in the above post (some have been covered by other comments):

1. Always make sure your software is up-to-date. This includes both web applications such as IP.Board as well as server applications such as PHP and Apache.

2. Only grant the webserver user write permissions to the directories that they actually need to write to for your application, such as the avatar, cache, and temporary directories. Don't give the webserver user write permission to other directories containing code files; this will protect from a vulnerability that could potentially overwrite your script's PHP files with something malicious

3. Per the above, make sure that in the directories the webserver CAN write to, that script execution is disabled. If you are using mod_php, add php_admin_value engine off into your .htaccess. If you have other scripting languages (perl/python), make sure you disable those as well. Also, serve all unrecognized file extensions as application/octect-stream or text/plain to force a download or display the contents instead of executing it as an added precaution.

4. If using mod_php with Apache, make sure that your apache conf is loading PHP via the SetHandler directive instead of AddHandler. Otherwise someone tricksy would be able to name a file blahblah.php.txt and have it run as php code.

5. Make MySQL only listen on localhost and firewall off the port as well so people cannot attempt to remotely break into your database (actually, just go ahead and firewall off every port except for the ones you need like 80 and 443 for HTTP, and the respective ports of other applications you are running. I personally recommend installing ConfigServer Firewall, aka csf, if you aren't all that familiar with managing firewalls).

Share this comment

Link to comment
Share on other sites

Just noting for what it's worth.. disabling system breaks ImageMagick in IP.Gallery,

PHP message: PHP Warning:  system() has been disabled for security reasons in .../ips_kernel/classImageImagemagick.php on line 341

Share this comment

Link to comment
Share on other sites

Why should we disable escapeshellarg  and escapeshellcmd ?


escapeshellcmdEscape shell metacharacters

escapeshellargEscape a string to be used as a shell argument


That's function to escape dangerous characters not dangerous functions !


You could also add popen() to dangerous ones :)

Share this comment

Link to comment
Share on other sites

by using this in php.ini and restarting apache, I got a blank page ...


open_basedir = /var/www/XYZ:/var/www/XYZ/tmp


I did not got the point, because there is no really good example :-(  .... anywhere in the web ...

Share this comment

Link to comment
Share on other sites
On 11/23/2013 at 4:23 AM, Duque said:

by using this in php.ini and restarting apache, I got a blank page ...


open_basedir = /var/www/XYZ:/var/www/XYZ/tmp


I did not got the point, because there is no really good example :-(  .... anywhere in the web ...

Please consult with your hosting provider/server administrator for help with this. 

Share this comment

Link to comment
Share on other sites

this php.ini config set is currently running on my server with no apparent issues atm,
does anyone see any issue with this hardened php.ini config set specifically for IPS4?

/home/username/var = chmod 755
/home/username/var/lib = chmod 755
/home/username/var/lib/php = chmod 755

/home/username/var/lib/php/tmp_upload/ = chmod 666
/home/username/var/lib/php/session/ = chmod 666
/home/username/var/lib/php/soap_cache/ = chmod 666

/home/username/var/lib/php/error_log = chmod 644

;Remote Connections
allow_url_fopen = 0
allow_url_include = 0

;Runtime Settings
max_input_time = 30
max_execution_time = 30
;max_execution_time = 600
;memory_limit = 8M
memory_limit = 128M
register_globals = off
expose_php = 0
cgi.force_redirect = 1

;Input Data Restrictions
;post_max_size = 256K
post_max_size = 32M
max_input_vars = 100
;max_input_vars = 5000

;Error Handling
display_errors = 0
display_startup_errors = 0
log_errors = 1
error_log = /home/username/var/lib/php/error_log

;Restrict File Access
open_basedir = "/home/username/public_html:/home/username/var/lib/php/tmp_upload:/home/username/var/lib/php/session:/home/username/var/lib/php/soap_cache"

;File Uploads
;file_uploads = 0
file_uploads = 1
;upload_max_filesize = 2M
upload_max_filesize = 32M
upload_tmp_dir = /home/username/var/lib/php/tmp_upload

;Session Security
session.use_strict_mode = 1
session.cookie_httponly = 1
session.use_cookies = 1
session.use_only_cookies = 1
session.use_trans_sid = 0
session.name = custom_session_id
session.cookie_secure = 1
session.referer_check = mywebsite.com
session.save_path = "/home/username/var/lib/php/session"
session.hash_function = sha512
session.bug_compat_42 = 0
session.bug_compat_warn = 0

;Disable Vulnerable Functions
disable_functions = ini_set,php_uname,getmyuid,getmypid,passthru,leak,listen,diskfreespace,link,ignore_user_abord,shell_exec,dl,set_time_limit,exec,system,highlight_file,source,show_source,fpaththru,virtual,posix_ctermid,posix_getcwd,posix_getegid,posix_geteuid,posix_getgid,posix_getgrgid,posix_getgrnam,posix_getgroups,posix_getlogin,posix_getpgid,posix_getpgrp,posix_getpid,posix,_getppid,posix_getpwnam,posix_getpwuid,posix_getrlimit,posix_getsid,posix_getuid,posix_isatty,posix_kill,posix_mkfifo,posix_setegid,posix_seteuid,posix_setgid,posix_setpgid,posix_setsid,posix_setuid,posix_times,posix_ttyname,posix_uname,proc_open,proc_close,proc_get_status,proc_nice,proc_terminate,phpinfo,popen,curl_multi_exec,parse_ini_file,allow_url_fopen,allow_url_include,pcntl_exec,chgrp,lchgrp,lchown,putenv,escapeshellarg,escapeshellcmd,ini_alter,symlink

;Soap Cache
soap.wsdl_cache_dir = /home/username/var/lib/php/soap_cache


Edited by Chris Bell

Share this comment

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


Important Information

We use technologies, such as cookies, to customise content and advertising, to provide social media features and to analyse traffic to the site. We also share information about your use of our site with our trusted social media, advertising and analytics partners. See more about cookies and our Privacy Policy