Jump to content

Invision Community Blog


Managing successful online communities

Lindy
 Share


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.

open_basedir

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.

disable_functions

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.

 Share

Comments

Recommended Comments



  • If you have a dedicated server...
  • First and most important keep your server software updated and patched. Especially old PHP and kernels which can be insecure.
  • A couple links with lots of info: Website security precautions, and Secure settings for PHP on Apache.
  • Suhosin will further harden your PHP installation.
  • Close unneeded open ports.
  • Maintain access logs. Depending on the size of your site these can quickly grow in size, but they can be very useful in identifying any access points.
  • Disable direct root login, and change the default ssh port.
  • Secure passwords, limit access
  • Disable allow_url_fopen in php (recommended in the securing PHP link above).
  • If an attack happens, preserve the time stamps of the files affected (ie: using cp -p before deleting the files).
  • Disable world writable permissions (777) for directories. As a general rule, chmod 755 for directories, 644 for files.
  • mod_security
  • Firewall, brute force protection, email notification when someone logs in as root.
  • Backup, backup, backup, maintain off-site backups.
  • Cloudflare? Clouflare blocks IP addresses, and many Asian countries share IPs (as do dial-up users). Many false positives if you have visitors from these areas, but worthy for high-risk sites.
  • A security diligent host or server admin can be amazing.
Link to comment
Share on other sites

Excellent. :)

 

The only small thing I'd like to add is IPBoard specific. Where possible it is worth visiting the Security Centre and running the IPB php/cgi .htaccess protection tool. As far as I'm aware this will work on all 'nix servers but not Windows based ones.

 

For those who do not know, this writes 'no execute' permissions to various writeable directories such as uploads etc. Put simply if someone did manage to upload an executable file such as a script for instance disguised as an image (which seems very unlikely given boards built in protection) this adds a further layer of protection by preventing said file from being able to be run in the first place.

Link to comment
Share on other sites

I have a question! I have this in my php conf

 

open_basedir

no value

no value

 

What does no value mean? in this case?

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

Link to comment
Share on other sites

if you are on unix then in your vhost.conf add 'php_admin_value open_basedir' inside <IfModule> section with value of actual path you want restrict to and other shared libraries, e.g. php_admin_value open_basedir /var/www/html/:/usr/local/php/, this also can be added in .htaccess of single web. Such config is useful when you have subdomains or many separate domains.

Link to comment
Share on other sites

disable_functions is something I probably should have made better use of long ago, but with things like that I get afraid I'll disable something IPB relies on and end up breaking some function of my site without noticing it until a month or so later.

 

Though I guess it should be common sense that most of what's listed there wouldn't be used, either way, thanks for the useful post.

 

Minus that, I already make use of most all the basic stuff, including open_basedir. This is basically a template of the VirtualHost configuration I have on Apache, maybe someone will find it useful. It basically makes use of most everything the security section of the ACP recommends, but without the need of throwing .htaccess in all your sub-directories. Obviously it won't work out of the box, but it includes all the .htaccess directives the IP.Board PHP/CGI .htaccess Protection function installs.

http://pastie.org/private/i3pldoxkhzia43iaymmra

 

If you're running on your own dedicated server, you may also want to take the time to secure your website permissions further. The standard is generally to allow public access to your web documents so Apache can read and write to them.

 

Apache offers documentation on a more secure way to do this. While this may not do much to prevent a direct attack on your site, it can help further prevent your site from being infected if another service on your server is compromised.

https://wiki.apache.org/httpd/FileSystemPermissions

 

The end result will look something like this,

http://pastie.org/private/ucxo4dzyfvrfg9vrmmm4qg

 

Adding to blair's suggestions, you should also flat out disable SSH password authentication if possible.

https://help.ubuntu.com/community/SSH/OpenSSH/Keys

Link to comment
Share on other sites

Excellent. :smile:

 

The only small thing I'd like to add is IPBoard specific. Where possible it is worth visiting the Security Centre and running the IPB php/cgi .htaccess protection tool. As far as I'm aware this will work on all 'nix servers but not Windows based ones.

 

For those who do not know, this writes 'no execute' permissions to various writeable directories such as uploads etc. Put simply if someone did manage to upload an executable file such as a script for instance disguised as an image (which seems very unlikely given boards built in protection) this adds a further layer of protection by preventing said file from being able to be run in the first place.

many forget about the security center, mentioning it more often can never hurt :)

Link to comment
Share on other sites

All I entered in the WHM/cPanel disable_functions field was the following:

 

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
Link to comment
Share on other sites

Too bad there isn't a button that we can click that is labeled 'Dismayed.'

 

Not all of us are tech wizards that can skip through the grassy fields, sing aloud, and log on to our dedicated servers or persuade our shared hosting support service to enable or adjust the settings for open_basedir and disable_functions.

 

Your blog entry implies that the security patch you have provided is not, in and of itself, enough to protect our ipboard installation and that we must take these other security measures.

 

So are IPS products safe as installed or not?  Yes or No.

Link to comment
Share on other sites

fpassthru is needed for minifiy isn't it? 

Nope. 

 

 

 

Too bad there isn't a button that we can click that is labeled 'Dismayed.'

 

Not all of us are tech wizards that can skip through the grassy fields, sing aloud, and log on to our dedicated servers or persuade our shared hosting support service to enable or adjust the settings for open_basedir and disable_functions.

 

Your blog entry implies that the security patch you have provided is not, in and of itself, enough to protect our ipboard installation and that we must take these other security measures.

 

So are IPS products safe as installed or not?  Yes or No.

There will always be vulnerabilities in software. You are never 100% secure.

 

This blog post is mainly intended for those who run their own dedicated server or VPS, or for hosting providers.

If you run an unmanaged server without understanding what's written here, you really shouldn't. With managed servers you usually have support technicians that takes care of the server, and you can pass them the link to this blog post, asking if these precautions have been taken.

 

Also, this is to point out that you can only secure your self as much trough the software on it's own. If vulnerabilities or weak spots are found in the core system (PHP, Apahce, MySQL, etc), IPS can't really do much about it. 

Link to comment
Share on other sites

  • Management

surferboy - IPS products are inherently secure. There have been very few security concerns over the years and even this one surrounded an issue with PHP, although exploited through IP.Board. 

 

I provided this information merely as a courtesy from a best practices standpoint. It's not a requirement, but goes a long way in further protecting yourself against attacks, not only through IPB but any other PHP application that may reside on your server... whether in your account or not. 

 

If your host will not provide that level of protection (either on a server level, or an account level), I would strongly suggest you find a new host. 

Link to comment
Share on other sites

This might be just me, but I've tested out setting open_basedir = /var/www/html (happens to be my web root default) with some negative side effects. The ability to upload files with ip.downloads or upload avatars seems to not work. Everything else seems to function which is good.

 

Commenting open_basedir out again from my /etc/php.ini allows things to be uploaded again. Is this expected? The use of ip.downloads is pretty important to me and it would be nice if there is a work around for security sake.  Note that I'm running on a physical host and have full control over the OS and files. I've tested this out with the latest and greatest version of IP.Board and IP.Downloads.

Link to comment
Share on other sites

Thanks Lindy, Kirito, AncientMariner!!

 

AncientMariner's suggestion worked but I'm curious about what is more appropriate...

 

open_basedir = /var/www/html:/usr/bin

upload_tmp_dir = /tmp

 

or

 

open_basedir = /tmp:/var/www/html:/usr/bin

 

Also, please confirm the /usr/bin definition there, I use ImageMagick as well for mediawiki but I'm not sure if /usr/bin leaves a vulnerability. I'll try it out in the next few days.

 

One more thing, I hear about root kits installing themselves in /tmp so I'm also wondering about defining something other than /tmp, or are we stuck with that. I'm assuming we're stuck with /tmp and probably need something like selinux to protect the OS. I've gone way too far here. Thanks though for your help!

Link to comment
Share on other sites

Couple of points -

 

There are legitimate uses for allow_url_fopen, so I would not recommend disabling that, personally.  I saw it was noted in an earlier comment.

 

As for whether to use upload_tmp_dir, or to add /tmp to your open_basedir configuration - either way is fine and gives you the same net end result.  If you prefer to use a directory other than /tmp, you could also create a temp directory under your web root (say, /var/www/html/tmp), leave open_basedir set to your web root, and then adjust upload_tmp_dir to the new temp directory under your web root.

 

There are many ways to configure a server.  The above guides outline a few steps you can take to secure your server, but never be hesitant to contact your host and/or do your own research on best practices you can make.

Link to comment
Share on other sites

With all this stuff going out of the layman limit. Can you please rephase the main blog and what all this open closing stuff is doing? I'm not understanding what we should or shouldn't be doing and what does it do and why?

Link to comment
Share on other sites

With all this stuff going out of the layman limit. Can you please rephase the main blog and what all this open closing stuff is doing? I'm not understanding what we should or shouldn't be doing and what does it do and why?

If you don't understand it then the blog isn't meant for you.

Link to comment
Share on other sites

If you don't understand it then the blog isn't meant for you.

 

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.

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.

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

Loading...

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

×