Basic recommendations for improving security * nix web server

Inspired by the article on finding traces of hacking , I decided to write an article on hacking prevention and basic steps to reduce the possibility of hacking the server to a minimum.

All steps are extremely important, and it is impossible to single out the most important, or secondary.

This article is not a step by step instruction, but only a list of recommended steps.

Step zero. Stop stupid following the instructions.

Never, do you hear? Never! without a full understanding of what will happen from the actions performed, do not follow the instructions from the Internet (books and any sources in general), and especially forum advice (have you not forgotten the famous one-word perl'e yet?). Even if you are setting up a web server using a super cool article from apache developers themselves and compiling the kernel according to the Linus Torvalds instructions, remember that people can be mistaken and no one is immune from typos and errors in instructions that can lead to fatal consequences. Therefore, if you do not understand something in the instructions, you should first understand, and then do.

Actually, without complying with this clause, it is generally better not to go into IT.

Step one. Remote access configuration (ssh).

• We move ssh to a non-standard port. This will not save an attacker who decides to prevent your server from being hacked, however, we’ll get rid of a heap of cracking bots and find the right line in the logs if it suddenly happens.
  
  For paranoids, you can implement port knocking (this is when we port with ssh is closed by default and opens only after we knock on a certain other). For completely hopeless paranoids, you can build a chain of ports into which you need to knock.
• We prohibit login from root (it is, oddly, allowed by default).
• Explicitly set the list of users allowed to log in to the server.
• We put a filter that bans ipshniki after, say, five unsuccessful attempts to log in (fail2ban, for example).
• (optional, since it is not always possible) We prohibit the login with a password and allow walking only with public keys.

')

Step two. Actually the web server itself.

Apache or apache + nginx is used primarily as web servers, less often just nginx, and even less often various lighttpd, cherokee, and so on. Therefore, the step relates for the most part to apache and nginx.

• Do not neglect open_basedir (many simply turn it off, because they cannot cope with it: they see that an error occurs because of open_basedir and just cut it off right away)
• Restrict access by ip (or by password) to important objects (if they do not need to be shown to all other visitors) using .htaccess (in apache) or directly specifying limit_except (in nginx), and to some things (for example .htaccess) and completely banned access to the web.
• Hide the version of the software used. In apache, this is ServerSignature and ServerTokens, in nginx, server_tokens off; ( upd from alxsad ).
• In php.ini, it is also possible to cut the displayed information.
• upd from edhell : also disable dangerous functions in php.ini (exec, passthru, shell_exec, system, proc_open, popen, curl_exec, curl_multi_exec, parse_ini_file, show_source, etc).

Step three. Software Update.

Timely software update on the server is one of the most important moments. It is also better to subscribe to the security newsletter in order to receive information about vulnerabilities in a timely manner. Moreover, this item refers not only to the installed unix-system, but also to the cms that is being used.

Step Four. The rights.

777 cms' ( , 777, ). , -. php- 644 755 . , noexec.

hint:find /path/to/dir -type f -exec chmod 644 {} \;

, .

. .

( ). munin ( , ).

upd gunya: csf + lfd — , .

. iptables.

, ssh + 80 443 - + . .

FTP , .., , scp.

upd. farcaller: shell, , ssh.



, 123456 qwerty . :

$ apg -t -q -n 2

dickluer (dick-luer)

JicNeut3 (Jic-Neut-THREE)

$ apg -t -q -m 12 -a 1 -n 2

@%p-a^b`kI>R

dKYeK{7)E`Es





, , .