Jump to content

skizzerz

Clients
  • Posts

    89
  • Joined

Reputation Activity

  1. Like
    skizzerz got a reaction from The Old Man in How to keep your community secure   
    The disabling PHP functions bit is pure security theater and does not increase the security of your site. If an attacker is capable of running arbitrary PHP code on your server due to some vulnerability, it's already game over. Restricting those functions does not in any way, shape, or form prevent them from doing whatever it is they want to do. Using functions that are required to be enabled just to make pieces of Invision Community function, an attacker can read/write files, read/write the database, and open sockets (network connections). The combination of these is plenty to establish a persistent backdoor and/or gain a foothold into your network to launch attacks elsewhere.
    open_basedir is potentially a good idea though, depending on your setup. In places where you can safely enable it and enabling it won't break anything, it's a good idea to do so.
    A better setup for securing PHP would be ensuring that the user account PHP is running as for your Invision Community install is unprivileged (i.e. not root) and is dedicated to your site (i.e. not a shared apache user). If you have multiple sites, run each site under a separate user account. Then, set up file permissions appropriately so that the user accounts have read-only access to their own files and no access to the files of other users. Directories that must be writeable, such as cache and uploads, should have script execution disabled via server config. This ensures that a compromise is unable to write backdoor scripts to your filesystem (although they can still manipulate the database), which will limit the damage an attacker can do. By manipulating the database, an attacker can still establish persistent backdoors into your site with certain configurations (for example, by manipulating cache entries if they're stored in the db or by creating a new admin account), so this is not foolproof. As I wrote above, if an attacker is able to execute arbitrary PHP, it's game over. The setup I described in this paragraph blocks some of the ways they can do that, but not all of them.
×
×
  • Create New...