Некоторые советы безопасности, которые помогут защитить сайт от хакеров:
1. Первым делом следует проверить сайты всех поставщиков/разработчиков веб скриптов и приложений, которые используются в Вашем аккаунте, на предмет обновлений. Это же касается и всех модов (расширений и модификаций, созданных сторонними разработчиками) используемых веб приложений. Если Вы используете open source программы (программы с открытым исходным кодом), то наибольшее подозрение в плане безопасности вызывают именно они. Тем не менее, следует обновить абсолютно все приложения. Для проверки на обновления и исправления можно воспользоваться базой данных на www.secunia.com.
2. Как только Вы проверили то, что все скрипты обновлены, необходимо просмотреть все файлы и убедиться, что среди них нет хакерских, которые могли попасть как при обновлении, так и остаться с более ранних времен. Такие файлы могут размещаться в папках, на которые Вы бы никогда не подумали! Можно использовать файловые менеджеры ftp или cpanel, чтобы просмотреть все файлы в public_html и сравнить их со своей локальной копией сайта (Вы всегда должны иметь сохраненную локальную копию как для подобного сравнения, так и для осуществления отката версии (backup)).
3. Убедитесь, что все пароли состоят из сочетания буквенных и цифровых символов и при этом не содержат словарных слов. То, что вы подобрали сложное словарное слово, не сделает Ваш пароль менее уязвимым.
4. Доступ к базам данных MySQL всегда должен осуществляться от имени других (не основного) пользователей. Никогда не используйте логин и пароль основного аккаунта сайта. Ваш основной логин и пароль никогда не должен храниться в каком-либо файле сайта.
5. Используя панель управления (кнопка Raw Log Manager), активируйте функцию архивирования журнала событий (web log). Это даст вам возможность проследить, как хакеры используют скрипты. Если функцию архивации не активировать, то после создания статистического отчета все log-данные будут удалены. Если Вас уже взломали, то подобная мера не поможет, но для отслеживания будущих атак еще пригодится.
6. Если Вы надстраивали в какое-либо приложение мод, то проверьте, чтобы он был самой последней версии. Многие распространенные веб приложения могут быть защищены, но вот дополнительные моды к ним могут оказаться уязвимыми, особенно если перестают обновляться.
7. Если Вы написали часть кода самостоятельно, убедитесь, чтобы все входные переменные были проверены на действительность данных. Иначе всего одна строчка ошибочного кода может предоставить внутренний доступ к сайту. Одна из грубых ошибок — включение в код ссылки на файл, требующий ввод информации со стороны пользователя (user input). Так что еще раз обратите внимание — все скрипты должны быть проверены на действительность входящей информации. Все уязвимости основой своей имеют входные данные. Если Ваш сайт не получает входную информацию (то есть это полностью статический сайт вообще без использования скриптов), то он 100% защищен от веб атак.
8. Что касается сайтов на php, то приложения, использующие опцию register_globals, делают Ваш сайт гораздо более уязвимыми. Избегайте использования таких приложений.
9. Если Вы используете e-mail скрипты, то проверьте их на ошибки безопасности в части объявления класса header injection. А именно, удостоверьтесь, что адрес электронной почты, тема письма и другие фрагменты информации, которые будут отправлены пользователем, не содержат переносов строки (line breaks). Множество подобных полезных советов можно найти на форумах.
10. Использование бесплатных open source веб приложений удобно и вообще хорошо, но не забывайте следить за обновлениями, иначе рискуете потерять всю информацию и свой сайт, как только в таком приложении найдут новую уязвимость. Как владелец хостингового аккаунта, Вы несете полную ответственность за установку только стабильного в плане безопасности программного обеспечения.
11. Тот факт, что Ваш сайт успешно и без проблем проработал многие годы, не значит, что в его безопасности нет дыр. Это значит то, что об этих дырах не было известно, или Вам просто повезло, что их никто не использовал.
12. Чтобы обеспечить безопасность, дополнительно Вы можете изменить параметр доступа файлов конфигурации (используя базу данных параметров доступа) на 660. Это делается посредством ftp или файловых менеджеров. Это сработает только если на вашем сервере включена функция phpsuexec.
13. Также можно заблокировать доступ к некоторым зонам администрирования сайта. Сделать это можно разрешив доступ в такие зоны только авторизованным IP и блокируя всех остальных, или защитив их паролем.
14. Если на Вашем сайте есть инструменты загрузки файлов, убедитесь, что только авторизованные пользователи могут их применять. Также загруженные файлы не должны быть доступны непосредственно через URL ссылку (то есть не должны быть сохранены вне зоны public_html) если только файлы не были:
- загружены администратором сайта (ответственным лицом)
- проверены на предмет уязвимостей.
15. Если на сайте действуют службы URL-переадресации или почтовые инструменты для участников, то необходимо удостовериться, что эти услуги не могут быть предоставлены без авторизации и не могут быть использованы для рассылки спама.
16. Если вы просто тестируете или пробуете что-либо, и это нужно только Вам и нет желания часто обновлять и следить за безопасностью этого «объекта», просто закройте это что-либо паролем.
17. Так как на многих хостинг-серверах используется режим работы suphp, Вам не нужен файл или папка с прописанными параметрами доступа. Для обычных папок, параметр доступа не может превышать 755. Для файлов php/html его значение — 644 (или меньшее для ssh (средство удаленного доступа)). Скриптам CGI/perl также можно присвоить значение параметра доступа 755.