Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Hardening a vps?
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Hardening a vps?

mahjongmahjong Member
edited December 2011 in General

Dear Users,
I'm hardening/securing my vps, and i would really love to know the steps which i should take, which are necessary to be secure.

I'm using debian 6, nginx, php-fpm, mysql-server 5.5, nsd3 for dns. I'm an end user, noone except me uses the system, only my sites are running (going to run) on it.

So, the steps that i have taken:
- change ssh port
- disable root login, hard root pass (i know ssh keys would be the best method, later i will set it up)
- create sudoer user, sudo needs root pass not user pass
- use iptables to disable all unused port, also install some rules so after 5 login attempt user can't try again for 3 minutes
- mysql_secure_installation used (no anonym users, no passwordless login, no test db after it), also root has really hard password and my application uses a user with privilages only to that database that it is using
- secure /temp /var/temp /dev/shm

What is planned (but i need advice on them, as there are a lot of stupid tutorials of it):
- secure php - disable few php functions. Also to mention: i'm using php package with suhosin from dotdeb.

Thats all.
Also i heard that chrooting mysql and nsd is a possibility too. Is it really needed? How should i do it?
Also read a few tutorials where users chmoding binaries? Should i? Which one?
What is the correct way to secure php?
Are there any steps that i'm missing?

Thanks for any help!

Comments

  • I think you should try free hackerguardian PCI scan. They will suggest you what to do next :P

    But if you could pass PCI scan, everything would be fine :D

  • @mahjong said: Also i heard that chrooting mysql

    Since mysql is only listening on localhost i don't think thats necessary.

  • marrcomarrco Member
    edited December 2011

    keep your system updated, do not install unnecessary daemons, backup often and don't provide access to your server in unsecure matter (ie. no plain ftp, telnet or other scripts that allow to upload and execute code to unauthenticated users) even if that will cause problem with some CMS autoupdate scripts

  • Install fail2ban, it can be a memory hog, but setup right it will keep unauthorised people out of your system

  • @marrco said: keep your system updated

    This is a big one. ALWAYS update your VPS when you first get it. We find some of our client's containers still running the stock OpenVZ template from 2009-ish.

    @Daniel said: Install fail2ban, it can be a memory hog, but setup right it will keep unauthorised people out of your system

    Set up wrong and it will keep you out of your system too! :)

  • KeithKeith Member
    edited December 2011

    I set up nginx to disallow access by numeric ip after seeing some of the attempted accesses in my logs.
    Also disallowing some user agents.

  • johannesjohannes Member
    edited December 2011

    @Keith said: I set up nginx to disallow access by numeric ip after seeing some of the attempted accesses in my logs.

    Also disallowing some user agents.

    Hi, would you mind elaborating on these nginx-specific rules? Im looking for something similar.

    Thanks,
    Johannes

  • SpeedBusSpeedBus Member, Host Rep

    @johannes : Why not just block the IP's in iptables ?

  • @SpeedBus said: @johannes : Why not just block the IP's in iptables ?

    Read again

  • @johannes In Squeeze, /etc/nginx/sites-available (ipv4 only server) is

    server {
        listen 80 default_server; ## listen for ipv4
        server_name  _;
        access_log  /var/log/nginx/default.log main;
        return 444;
    }
    

    With virtual domains no numeric ips are used for server_name

    I've created 2 files /etc/nginx/disallow-agent.conf

    if ($http_user_agent ~* "(Morfeus|larbin|ZmEu|Toata|Huawei|talktalk)" ) {
        access_log /var/log/nginx/disallow.log main;
        return 444;
    }
    

    Blocking my previous ISP there also.

    and /etc/nginx/disallow.conf

    location ~* (roundcube|webdav|smtp|http\:|soap|w00tw00t) {        
        access_log /var/log/nginx/disallow.log main;
        return 444;
    }
    

    In the virtual server conf file I insert

        include disallow.conf;
        location / {
            include disallow-agent.conf;
        }
    
    Thanked by 1johannes
  • @Keith

    Cool!
    Just a little issue, probably due to the nginx version:

    Reloading nginx configuration: nginx: [emerg] unknown log format "main" in /etc/nginx/sites-enabled/default:4
    

    So, I only removed the 'main' word.

    About the user agents that you forbide, is something specific to you? or these are common attack vectors?

  • @Yomero I also define the log format
    In nginx.conf it's

    #   access_log /var/log/nginx/access.log;

    with /etc/nginx/conf.d/keith.conf

    server_tokens off;
    ignore_invalid_headers on;
    
    ## Size Limits
    #client_body_buffer_size      16k;
    #client_header_buffer_size     1k;
    #client_max_body_size          1k;
    #large_client_header_buffers 1 1k;
    ##
    
    log_format  main  '$remote_addr $host $remote_user [$time_local] "$request" '
                   '$status $body_bytes_sent "$http_referer" "$http_user_agent" "$gzip_ratio"';
    access_log /var/log/nginx/access.log main;
    
    upstream php {
        server 127.0.0.1:9000;
    }
    

    The user agents blocked were found from looking at the nginx logs, which I also found mentioned in a Google search.

  • Thanks, you are the man!

    (woman? xD)

  • You just have to rub it a bit.

Sign In or Register to comment.