Шаг нулевой. Отставить тупое следование инструкциям.
Никогда, вы слышите? Никогда! без полного понимания того, что произойдет от совершаемых действий, не следуйте инструкциям с интернета (книжек и вообще любых источников) и особенно форумным советам (вы же еще не забыли знаменитый однострок на perl'e?). Даже если вы настраиваете веб-сервер по супер крутой статье от самих разработчиков apache и компилируете ядро по инструкции Линуса Торвальдса, помните, что людям свойственно ошибаться и никто не застрахован от опечаток и ошибок в инструкциях, которые могут привести к фатальным последствиям. Поэтому если вы что-то в инструкции не понимаете, то сначала следует разобраться, а потом делать.
Собственно без соблюдения этого пункта, вообще в IT лучше не соваться.
Шаг первый. Настройка удаленного доступа (ssh).
Перевешиваем ssh на нестандартный порт. От злоумышленника, решившего во чтобы то не стало взломать ваш сервер, это не спасет, однако мы избавимся от кучи ломящихся ботов и в логах найти нужную строчку будет гораздо проще, если вдруг что.
Для параноиков можно реализовать port knocking (это когда мы порт с ssh по умолчанию закрыт и открывается только после того, как мы постучимся в определенный другой). Для совсем безнадежных параноиков можно выстроить цепочку из портов, в которые нужно стучаться.
Запрещаем логин от рута (по умолчанию он, как ни странно, разрешен).
Явно задаем список пользователей, которым разрешено логиниться на сервер.
Ставим фильтр, который банит ipшники после, скажем, пяти неудачных попыток залогиниться (fail2ban, например).
(опционально, т.к. не всегда является возможным) Запрещаем логин по паролю и разрешаем ходить только по сертификатам.
Шаг второй. Собственно сам веб-сервер.
В качестве веб-серверов преимущественно используется apache, либо apache+nginx, реже просто nginx, еще реже различные lighttpd, cherokee и прочее. Поэтому шаг относится в большей части все относится именно к apache и nginx.
Не пренебрегать open_basedir (многие просто его отключают, т.к. не могут с ним справиться: видят, что возникает ошибка из-за open_basedir и просто тут же его вырубают)
Ограничивать доступ по ip (либо по паролям) к важным объектам (если их не нужно показывать всем остальным посетителям) с помощью .htaccess (в apache) либо прямым указанием limit_except'ов (в nginx), а к некоторым вещам (например .htaccess) и вовсе запретить досутп по веб.
Скрыть версию используемого ПО. В apache это ServerSignature и ServerTokens, в nginx — server_tokens off;.
В php.ini так же есть возможность урезать отображаемую информацию, так же отключаем опасные функции в php.ini (exec, passthru, shell_exec, system, proc_open, popen, curl_exec, curl_multi_exec, parse_ini_file, show_source, etc).
Шаг третий. Обновление ПО.
Своевременное обновление ПО на сервере — один из важнейших моментов. Лучше к тому же и подписаться на рассылку безопасности, дабы своевременно получать информацию об уязвимостях. Причем данный пункт относится не только к установленной unix-системе, но так же и исползуемым cms.
Шаг четвертый. Права.
Никогда не выставляйте права 777 на файлы cms'ок (да и вообще они, права 777, крайне редко нужны). Это совершенно ни к чему, даже несмотря на повальное требование к таким правам у некоторых горе-кодеров. На php-шном хостинге вполне достаточно 644 для файлов и 755 для директорий. И раздел, где лежат файлы сайтов вообще лучше монтировать с noexec.
find /path/to/dir -type f -exec chmod 644 {} \;
Да и вообще неплохо бы четко понимать, нужны ли выставляемые права файлу или нет.
Шаг пятый. Мониторинг.
Необходимо настроить систему мониторинга с оповещением о нестандартном поведении (имеется в виду превышение установленных норм). Идеально подходит munin (легкий в настройке, удобно расширять функционал и графики красивые).
csf + lfd — автоматически обнаруживает брутфорс, при флуде тоже помогает.
Шаг шестой и последний. Закрываем все неиспользуемые порты для внешнего доступа с помощью iptables.
Как правило, достаточно оставить открытыми порты для ssh + 80 и 443 для веб-сервера + порт для мониторинга. Собтсвенно все.
FTP не случайно отстуствует в этом списке, т.к., на мой взгляд, является небезопасным протоколом и для обмена файлами лучше использовать scp.
Если пользователю не нужен 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
Все это не является в полной мере исчерпывающей информацией по вопросу безопасности, но даже при соблюдении лишь этих пунктов, подобраться к вам будет значительно сложнее.