Jump to content

Good Security Practices?


Recommended Posts

Well, the perfect security is achieved when you have nothing. xD There is nothing to be hacked. But I'm not saying this just for jokes, I'm making a serious base case.

Every time you enable 1 more service, that's 1 more access point. Not just for you, but for everyone else including hackers. So, the starting point becomes enable minimum number of services, programs, etc. that you need to have and disable everything else. And then you start trying to secure what you have. Minimizing the routes of how a system can be compromised means you can more diligently minimize the remaining essential services.

Then comes securing what you have.

Internet access is an obvious necessity to operate a server. So you install a firewall, use something like CSF to create a whitelist of what's allowed rather than what's not allowed. Minimizing what is available.

Under linux, you obviously have "users". So, you limit accesses to users and possibly even turn off high-risk users like root from being used directly (although this is something I'm too often too lazy to abide by).

You probably have a PHP website, so secure your PHP. What's your server handler? Apache? Then secure your apache. Minimize their powers to what's essential.

This doesn't really end with softwares only. It also includes hardwares. You can encrypt the harddrive. Disable alternate boots like USB from BIOS.

And you basically repeat this process of minimizing risk for everything and everywhere. And of course, there are additional programs like SELinux also assists with that.

I think that's what security really is. Minimizing your risks.

Link to comment
Share on other sites

Not forgetting if your on a VPS or dedicated adding a firewall and configuring it and setting up mod sec properly

CFS- Config Firewall Security (free) is very good and there is also ASL Atomicorp Secure Linux (although paid for)

If you are getting hit from countries that you never deal with then block the country code in the firewall

And you'll need to tweak your mod security rules as out of the box they tend to block quite a lot that annoys your customers (if you have installed it - recommended) - Atomicorp (paid for) and Trustwave Spider Labs (paid for) update on a daily basis a set of ModSec rules that work very well for everything

If your on cPanel/WHM there are some good cpanel docs on securing the server from a cPanel point of view

Remember to whitelist your IPs (if on static) as you can end up being blocked by the firewall (or brute force)

Another thing is to scan your sever for dodgy php scripts that have been uploaded - CFS do an add on for this (paid for but cheap)

Just to add I am in no way affiliated with CFS - But i do use there firewall and other products and services and find them very well priced with a good service for server security

Link to comment
Share on other sites

I provided some good basic (but very often overlooked) security practices in a Nginx configuration guide I wrote a while back.

To start, there are many good points listed in the blog entry Rhett posted. I would definitely recommend going through the advice there. (Note: The blog entry suggests you add system to disabled_functions, but If you use ImageMagick on your forum, you can't do that. You will have to remove system from the disabled_functions list.)


You should also ensure your websites permissions are set sanely. At the very least, never ever chmod 0777 your entire site. This is very very bad practice, but it's sadly pretty common to see. If you administer your own server or VPS, this is a good reference for using more secure permissions with Apache:
http://wiki.apache.org/httpd/FileSystemPermissions

You will need to update the folders that need write permissions to chmod 0770 and the files that need write permissions to 0660. Notice this is using 0770 and 0660, not 0777 and 0666. This means your IP.Board files will not have public read or write access. Thus, no (potentially compromised) process or user on your system should be able to access IP.Boards system files. This will not apply to newly generated cache data or newly uploaded files files however, so if you really want to be vigilant you will have to re-run this whenever you regenerate your templates. This may make the entire process seem kind of pointless, but even just securing conf_global.php from public access can prevent someone from gaining access to your websites database credentials if an account or process on your web server ever becomes compromised.

I could probably write a cron script to periodically "fix" permissions actually, I'll do that and upload it some other time.


Second, I have my AdminCP directory renamed so it's not the blatantly obvious and inviting "/admin". Instructions on how to do that can be located here. On top of that I also have my web server configured to only allow connections to the AdminCP directory from my specific IP address. This effectively ensures that no one other than myself should ever be able to even attempt to access my forums AdminCP.


Lastly, I have IP.Board PHP/CGI .htaccess Protection enabled on my forum. For Nginx, I just have these rules added to my web servers configuration,

    # IP.Board PHP/CGI Protection
    location ~^(/uploads/).*(.php)$ {
        deny     all;
    }
    location ~^(/hooks/).*(.php)$ {
        deny     all;
    }
    location ~^(/cache/).*(.php)$ {
        deny     all;
    }
    location ~^(/screenshots/).*(.php)$ {
        deny     all;
    }
    location ~^(/downloads/).*(.php)$ {
        deny     all;
    }
    location ~^(/blog/).*(.php)$ {
        deny     all;
    }
    location ~^(/public/style_).*(.php)$ {
        deny     all;
    }

But if you're using Apache, you can set these rules up automatically in the Security Center page of your AdminCP. It's worth noting though, the last time I checked, the automated method in the Security Center didn't account for the writable directories other IP.Board applications (such as IP.Blog, IP.Downloads, and etc.) use, so keep that in mind.

Link to comment
Share on other sites

  • 2 months later...

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

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