-2

I experience multiple attacks on my server recently (for past several days).

Types of these attacks are e.g.:

  1. Several SQL Injection methods (select/union/where/null, etc.)
  2. Brute force attacks (e.g. for root access via SSH, multiple authentication failures to different services)
  3. Scanning for commonly known vulnerable files etc.
  4. Scanning for not removed install.php install/ files/folders, etc.
  5. SSH insecure connection attempts (scans)
  6. Multiple web server 400 error codes (/w00tw00t.at.ISC.SANS.DFind:), etc.)
  7. Attempts to access forbidden file or directory
  8. Attempts to login using a non-existent user to different services.
  9. And so on...

The attacks are from China, France, US, etc.

Example IPs:

  • 122.225.109.205
  • 46.105.250.105
  • 108.23.96.102
  • ....

I've contacted (or at least tried) some of the possible owners of the servers, which attack was carried out from (If I could find any information about it).

What steps I undertook:

  1. Changed every password to all services/ssh/databases, etc. to 250-char random strings (including special chars of course).
  2. Revoke root access via SSH
  3. Set up firewall
  4. Set up hosts.deny
  5. Removed nearly all private/public key pairs from server (only crucial keys with only read access to repositories)
  6. Configured proper chmod/chown for web applications/sites
  7. Configured proper php.ini (with e.g. most strict settings for disable_functions, etc.)
  8. Upgraded all packages (databases/java/php, etc.)
  9. I've also installed security program (considering security here I won't say which one was that) which intercepts most of above attacks and e.g. autommatically adds IP addresses to hosts.deny & firewall, etc.

Is there anything else I can do?

My question is what can I do to defend & possibly prevent further attacks? It looks like somebody is eager to hack into my server...

Xeon
  • 97
  • 3
  • 2
    I'm surprised it took so long for you to notice. _Everyone_ who runs a server on the Internet sees this stuff. It is automated, and constant, and hits every IPv4 address. – Michael Hampton Sep 01 '14 at 17:32
  • @MichaelHampton I've noticed it immediately - I just asked now because it's escalating... :( Actually it started after some time when I hosted for a friend webapplication and he directed his subdomain to my server IP address (His server was infected completely, webapplication is clean). – Xeon Sep 01 '14 at 17:35

1 Answers1

1

I would add a few more tips:

  1. Install fail2ban on your servers

    It will block the IP address of the attacker when it detects (configurable) consecutive errors on a service (password incorrect on SSH, HTTP 404 on Apache, and so on). It makes more difficult to anyone do scans on your services.

  2. Install Port Sentry

    It will block anyone trying a portscan on you, after they hit n closed ports.

  3. Change the default ports if possible

    It will not help against a determined attacker, but running SSH on a higher random port will deter almost every mindless bot scanning the internet to reaching your server. You won't be able to change the HTTP port, but you can change the database ports, SSH, FTP and so on.

  4. Install honeypots on the network to have fun

    I installed sshpot on a system I have, and it's nice to see thousands of connections trying a bruteforce that will never ever succeed.

    As @deagh suggested, it can be used to feed data to iptables, as every connection to a honeypot system is an unauthorized one, and can be safely blocked. It will be useful to waste the resources of the attacker too.

ThoriumBR
  • 5,272
  • 2
  • 23
  • 34
  • adding a honeypot to a (production) server is no good idea unless you want to catch some information (maybe to feed iptables). Each connection will use ressource for nothing. – deagh Sep 01 '14 at 18:59
  • No, the idea is to install the honeypot on the network, not on the server. I will clarify it. And feeding iptables is a nice idea. – ThoriumBR Sep 01 '14 at 19:00
  • Instead of allowing fast (re-)connections and wasting a lot of (local) ressources you can give tarpitting with iptables a chance. you will obtain the same data but slow down the remote site. – deagh Sep 01 '14 at 20:32