Безопасность

1. Как мне защитить сайт от взлома
2. Что такое chmod/чмод и права файлов (777, 664 и т.д. )
3. А если меня взломали как мне проанализировать ситуацию, предотвратить такое в будущем
4. Что делать в случае обнаружения взлома
5. Что еще можно сделать для обеспечения безопасности
6. Как разрешить доступ к админке только с определенных IP-адресов
7. Где можно включить/выключить параметр RG_EMULATION?
8. Что можно сделать с особо важным файлом configuration.php
9. Пример .htaccess директив, от старых мамбо-joomla уязвимостей

1. Как мне защитить сайт от взлома
Сразу же надо оговориться, что стопроцентной защиты нет. Существуют лишь некоторые правила, без соблюдения которых, защиту точно не составит труда обойти.

* register_globals - не надо думать, что это вот такая дыра в пхп, дыра прежде всего в головах у разработчиков, которые не умеют пользоваться средствами языка правильно. Так вот в последнее время (сентябрь 2006) число найденных дыр использующих неглубокие познания девелоперов экспоненциально возросло. Для самой примитивной защиты в файл .htaccess надо добавить строчку "php_value register_globals 0"(или "php_flag register_globals off") (без кавычек) (если вы это сделали, а у вас вывалилась ошибка 500 и вы не знаете что делать, значит вы нихрена не читали фак с самого начала, читайте его полностью)

* Рекоменудется прочитать "Руководство по обеспечению безопасости для мамбо" (с тех времен мало что изменилось, так что и для joomla все должно прокатить)

* После сохранения конфига дать как можно меньше прав на файл configuration.php, вплоть до 444 (правда потом и вы не сможете перезаписать файл )

* На ВСЕ файлы и папки делайте CHMOD 644 и 755 соответственно. Если Joomla нужны будут права для записи/перезаписи, то она скажет об этом сама, подсветив нужные ей папки и файлы КРАСНЫМ цветом с сообщением Недоступно для записи.

Для работы Joomla (полностью настроенного сайта, когда нужные расширения уже установлены) только у нижеуказанных папок могут быть CHMOD 777:

* administrator/backups/ - chmod 777 иногда требуется для различных компонентов, делающих бэкап базы Joomla.
* images/
* images/banners/ - chmod 777, если записываете сюда баннеры с помощью Joomla
* images/stories/ -
* Каталог кэша cache/ - папка для записи кэша
* Каталог сессий - определено в настройках PHP - ДОЛЖЕН БЫТЬ ДОСТУПЕН ДЛЯ ЗАПИСИ

Защитите папку administrator паролем. В большинстве хостинговых панелей это делается за несколько секунд, а нервы здорово сбережет. Обязательно переименуйте файл htaccess.txt в .htaccess, даже если вы не используете ЧПУ (SEF-урл'ы)

2. Что такое chmod/чмод и права файлов (777, 664 и т.д. )
* Чмод для чайников
* http://chmod.ru/

3. А если меня взломали как мне проанализировать ситуацию, предотвратить такое в будущем
Прежде всего нужны логи за тот день, в который это предположительно произошло. Понятно, что логи большие и читать каждую строку смысла не имеет, но чаще всего можно найти необходимые строки где произошел взлом по следующим ключевым словам:

mosConfig
http://
wget
perl
_REQUEST

Во-вторых надо проверить вашу текущую версию Joomla, для этого нужно зайти на joomla.org и почитать новости. Если ваша версия устарела - есть повод ее обновить.

В третьих следует составить список установленных компонентов (не входящих в стандартный пакет), и зайти на их официальные сайты в поисках информации об их текущей версии и возможных сообщениях об найденных уязвимостях.

Помимо просмотра логов надо найти то место, где может быть расположен вредоносный код. Лучше всего искать зараженные файлы после того, как скачали на домашний компьютер архив с файлами хостинга. Просто разархивируем его и, например, в проводнике задаем поиск по маске *.* с дополнительным параметром, а именно датой последнего изменения. Если вы примерно знаете, когда был взлом - то легко можете установить примерный период дат. По идее файлы на хостинге вообще не должны меняться (ну пожалуй за исключением вновь установленных расширений, но их-то уж можно будет смело отделить - вы всегда знаете что ставили а что нет). После того как файлы найдены (обычно это не один, а несколько файлов) можно уже смотреть их более внимательно на предмет постороннего кода. И чаще всего он находится в самом начале или конце файла, так как туда проще его вставлять взломщику.

Также может помочь найти файл сканирование архива антивирусной программой.

После выяснения причины уязвимости следует прочитать следующий пункт FAQ.

4. Что делать в случае обнаружения взлома
Мало его обнаружить и обнаружить почему он произошел. Надо еще правильно выйти из ситуации. Прежде всего делаем бэкап всех файлов и базы. Если есть возможность восстановиться с ранее созданного бэкапа - стоит им воспользоваться. Если такой возможности нет, то стоит залить свежий дистрибутив джумлы, заново настроить configuration.php. [Очень сильно рекомендуется после установки сайта сохранить куда-нибудь хотя бы configuration.php (если нет возможности сделать бэкап всего сайта)(это не касается конкретно взломов, но это надо знать)]. После восстановления файлов джумлы надо (если были найдены уязвимости в каких-то компонентах или взлом был осуществлен через них) обновить файлы компонентов (чаще всего выходят патчи одного-двух файлов).

Теперь надо проверить сайт на работоспособность. Если всё работает, то надо визуально убедиться в отсутствии лишних файлов в основных директориях джумлы и еще раз сделать бэкап.

5. Что еще можно сделать для обеспечения безопасности
Ниже лежит частично переведенный Security FAQ с офф. сайта. Только самое полезное.

Для вашей же безопасности, надо после установки как можно скорее сменить имя админстратора, которое ему дается по умолчанию, т.е. 'admin'. Для этого идем в админку -> Управление пользователями (Пользователи), выбираем себя и меняем имя.

6. Как разрешить доступ к админке только с определенных IP-адресов
Для этого, если используется веб-сервер apache, надо создать файл .htaccess в папке /administrator/ и написать нечто вроде этого


Order Deny, Allow
Deny from all
Allow from 100.100.100.100


Если надо ввести несколько адресов, то это можно сделать разделив их запятой, например так:

100.100.100.100, 100.100.100.105

7. Где можно включить/выключить параметр RG_EMULATION?
В файле globals.php в строчке

define('RG_EMULATION',1)

Цифра 1 означает, что он включен, 0 - выключен. Этот параметр (насколько я знаю) предназначен для старых, древних как сама жизнь компонентов, которые до сих пор не знают, что такое register_globals. Возможно, со старыми компонентами и выключенным режимом эмуляции их работа станет невозможной (и не надо тут искать слово "безопасность", хоть девелоперы и говорят о безопасности, но ерунда это всё, один криворукий девелопер ремозитория не означает, что все такие).

8. Что можно сделать с особо важным файлом configuration.php
Можно вынести его за пределы www-директории (у некоторых она называется public_html). Для этого копируем его за ее пределы, возможно рядом с ней, переименовываем например в "joomla.conf", а в том, что должен быть в корне Joomla пишем нечто вроде этого

require( dirname( __FILE__ ) . '/../joomla.conf' );
?>

В результате особо-чувствительные данные теперь не находятся в www-директории и хотя бы на чуть-чуть стали более защищенными.

9. Пример .htaccess директив, от старых мамбо-joomla уязвимостей
Вот пример .htaccess директив, от старых мамбо-joomla уязвимостей, времен каменного века, возможно будет не лишним его использовать, хотя надо еще посмотреть на нагрузку, возможно она возрастет, тогда эти директивы надо отключить. Автор сборника - некто RobS.

########## Начало
#                            
# Попытка модификации переменных mosConfig* через URL
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR]
# (сам не понял нафик запрещать base64_encode :), будем верить автору)
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]
# Запрет передачи тэгов