Куда идем?

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

Основная проблема всех статей, посвященных безопасности сайтов, заключается в их сложности. Многие уязвимости носят сугубо технический характер и их описание, для простого человека, превращается в набор непонятных слов.  Эта статья начинает серию по защите Joomla от взлома. Все вопросы безопасности я постараюсь описывать максимально простым и доступным языком. Чтение данной серии будет полезно всем владельцам Joomla-сайтов, а также начинающим разработчикам.

Нельзя защищаться от врага, не зная, какое оружие он использует. Первое, и самое важное, о чем следует узнать – какие существуют виды атак на сайты. Зная, как сайт можно взломать, гораздо проще понять, как его защитить, или в чем уязвимость, если сайт уже взломан.  В этой статье я расскажу про основные виды атак, которые могут быть совершены на Joomla-сайт.

Особенность безопасности Joomla, как CMS с открытым исходным кодом

Как известно, Joomla является проектом с открытым исходным кодом. Это означает, что код Joomla может просматривать любой желающий. Хорошо это или плохо? Вопрос спорный.

Чтобы понять преимущества и недостатки открытого кода, представим себе два ящика. Черный и прозрачный. Черный ящик представляет собой закрытый код. Если сайт работает на самописной CMS или же просто на PHP, то увидеть его исходный код нельзя. Все, что можно делать – отправлять какое-то входное воздействие и следить за результатом, который будет получен на выходе. Т.е. вы отправляется запрос (например, заполняете форму и отправляете данные), а в ответ получаете результат выполнения (например, данные успешно приняты или ошибка).

Если же говорить о прозрачном ящике, коим является любой проект с открытым исходным кодом, в том числе и Joomla, то мы можем видеть все процессы, которые в нем происходят. Все точки обработки данных. Можем легко понять причину того или иного результата, получаемого на выходе.

Так что же в итоге лучше с точки зрения безопасности: черный или прозрачный ящик? Первый ответ, который приходит в голову: конечно черный. Ведь незнание процессов обработки данных значительно усложняет взлом. Да, это так, но далеко не всегда. Если закрытый код писал действительно хороший программист, а затем он проходил тестирование, то вероятность взлома крайне мала. Проблема в том, что такой код в основном пишут только сотрудники крупных корпораций, например, Яндекс, Google, Mail.ru, Вконтакте и.т.д. Уровень сотрудников в таких компаниях обычно очень высокий, как и их зарплата. А теперь давайте подумаем, кто пишет сайты для малого и среднего бизнеса? Поверьте мне, далеко не гении программного кода. Зачастую, они допускают элементарные уязвимости, которые в состоянии обнаружить даже автоматические боты, что уж говорить, если за сайт возьмется хакер. Кроме того, закрытый код расслабляет. Зачем программисту писать код качественно, если его все равно никто не увидит?

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

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

Подбор пароля

Самая простейшая атака на любой сайт – подбор пароля администратора простым перебором. Если вы используете простой пароль на админку, то ждите беды. Как это происходит? Адрес административной панели Joomla широко известен: site.ru/administrator. Также известно, что стандартный логин администратора: admin. Посылаем по этому адресу робота, который будет день и ночь пытаться авторизоваться, используя распространенные пароли и словари, и рано или поздно, пароль будет подобран.

Как защититься от такой атаки?  Изменить адрес админки, логин пользователя, использовать сложный пароль, установить защиту от роботов (капчу) в виде кода с картинки. Подробнее об этом я расскажу в отдельной статье.

Социальная инженерия

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

social engeneering

Второе чуть сложнее, но в общем случае выражается нарушением следующих правил:

  • не давайте пароли к сайту людям, которым не доверяете;
  • с достаточной регулярностью меняйте пароли;
  • не ведитесь на звонки и электронные сообщения, в которых запрашивается пароль или требуется перейти по ссылке для его восстановления;
  • всегда проверяйте адрес сайта в адресной строке перед тем, как ввести пароль;
  • используйте на рабочем и домашнем компьютерах хороший антивирус, с обновленными базами;
  • не работайте на компьютере с правами администратора;
  • не храните на компьютере в открытом виде пароли к сайту.

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

Специализированные атаки(XSS, SQL-инъекция и т.д.)

В эту группу можно отнести атаки в возможности совершения которых виноваты разработчики сайтов и расширений. Возникают подобные атаки обычно из-за недостаточной фильтрации пользовательских данных передаваемых на сервер. Теперь простым языком. Предположим, сайт позволяет пользователям размещать объявления. Это происходит следующим образом: пользователь регистрируется, заполняет форму объявления, объявление появляется на сайте. Атака происходит на этапе заполнения формы объявления. Обычно для таких форм используются текстовые поля, содержимое которых затем и показывается на сайте. Но что будет, если злоумышленник добавит в такое поле не только текст, но и ссылку на вредоносный скрипт? Объявление будет показано на сайте и посетителям, просматривающим его, будет загружаться вирус, ну или будет происходить другое вредоносное воздействие.

Чтобы такого не происходило, данные, загружаемые пользователями на сайт, должны проходить жесткую фильтрацию, исключающую возможность загрузить что-либо, кроме того, что предполагается. Решаться эта задача должна разработчиками на этапе создания расширения, но все мы люди и ошибки не являются редкостью.  Для Joomla существуют специализированные расширения, проверяющие все формы и другие уязвимые места самостоятельно. О них речь пойдет в отдельной статье.

DOS и DDOS атаки

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

Иногда все бывает гораздо проще. На сайт заходит «особо одаренный» человек, который решает создать его копию для личного пользования или других целей. Не представляя себе, как вообще работает сайт, этот человек нагугливает программу, которая обещает скачать сайт целиком. Он устанавливает ее и запускает, натравливая на нужный ему сайт. Что делает программа? Она работает, как и индексирующие роботы поисковых систем: заходит на страницу, скачивает ее, переходит по всем внутренним ссылкам на другие страницы, скачивает их, с тех страниц переходит на следующие и.т.д.  При этом получается некое подобие DOS-атаки, при которой большое количество запросов идет с одного адреса. Сайт не успевает обрабатывать их и становится недоступен, либо хостер отключает сайт за превышение нагрузки. Подобные вещи происходили и с wedal.ru. Защита тут очень простая. Считаем количество запросов с одного и того же IP-адреса за определенное время (например, 5 мин) и если оно превышает допустимое значение, блокируем этот адрес. К примеру, если за 5 минут с одного адреса поступило более 100 запросов, то заносим этот адрес в список заблокированных и доступ к сайту с него приостанавливается.

Уязвимости сервера

Часто случается, что во взломе сайта не виноват ни движок ни владелец. Уязвимость может быть найдена на сервере хостера, у которого расположен сайт. Этот случай является довольно частым, особенно когда используется малоизвествный дешевый хостинг. С одной стороны, качество специалистов на нем оставляет желать лучшего, с другой – для хакера это лакомый кусок, взлом которого может дать доступ сразу к сотням сайтов хостера.

Обезопасить сайт от подобных уязвимостей довольно просто: пользуйтесь услугами только проверенных крупных хостеров.

На этом все. Есть и другие виды атак, менее распространенные. Но они будут использоваться в тех случаях, когда ваш сайт представляет для хакера реальный интерес и он решит заняться им лично. Этот случай не частый, поскольку на 95% сайтов Интернета нет ничего, что могло бы интересовать хакеров столь сильно, чтобы они пытались взламывать сайт вручную. Если же сайт приносит действительно большую прибыль и является костью в горле конкурентов, то не грех заказать профессиональный аудит в компании, занимающейся безопасностью.

Об авторе
Wedal
(Виталий). Веб-разработчик полного цикла (Full Stack). Создатель и автор сайта Wedal.ru.
Основной профиль – создание сайтов и расширений на CMS Joomla.
Добавить комментарий

Комментарии  
5
Спасибо, статья полезная, но надо углублять.
Не так давно ломанули один мой сайт, где логин/пароль были admin/1234 :D Юмор в том, что такую простую связку я использовал из-за того, что сайтик был размещен в укромном месте, закрыт для индексации и предназначался только лишь для тестовых целей. Короче, во все .PHP файлы был подписан некий зашифрованный base64 код. Разбираться не стал, потер все нафиг без малейших сожалений.
0
Спасибо! с нетерпением жду продолжения с конкретными методами защиты!
0
Поддерживаю, статья обзорная, хотелось бы подробнее о методах защиты. Думаю, у каждого есть страшилки о взломе его сайтов, так что тема очень актуальна.
0
Придерживаюсь почти всем рекомендациям. Хорошая статья, жду подробного описания о защите.
0
Виталий, спасибо! Очень актуальная тема. Всё это известно, но для аппетита к следующим статьям в самый раз :-) Жду продолжения темы.
0
Присоединюсь к мольбам о продолжении темы и хочу спросить: расскажи пожалуйста, как именно ты обезопасился от скачивания сайта.
0
Кто-то поставил мне минус, видимо я должен пояснить для тех, кто приезжает сюда на бронетехнике. Есть программы типа Offline explorer, которые умеют скачивать сайты целиком. В процессе скачивания создаётся ТАКОЕ кол-во запросов, что иногда даже некоторые выделенные серваки начинают стонать. А если они в этот момент уже под нагрузкой... Не смотря на минусы вопрос мой остаётся актуальным. Ув. Wedal, поделитесь пожалуйста опытом! Я знаю, что он у вас есть :)
0
И как же я пропустил такую статью, вроде бы и на сайт ваш подписан... Начало хорошее, ждем продолжения так сказать с практическими приемами. :-) Хотя на некоторые сайты я уже ставил кое какую защиту, но в основном все было связано со скрытием админки, правельными правами на папки, логином и id админа и тому подобное. А вот как уберечь сайт например от скачивания это интересно.
0
Уважаемый, Виталий!!
Подскажите,а то уже не знаю, где искать.
В текстовых файлах Джумла (Контакты, Доставка и Оплата, Приветствие на главной странице), стал появляться вредоносный код,который переделывает текст на данных страницах в знаки "??".
Т.е. на главное странице был текст: Добро пожаловать!! Переделывает в: ????? ??????????!!
Перезалил поверх файлы Джумла, не помогло. Так же прицеплена Virtumart.
Джумла 1.5.22
0
Даниил, возможно, это не вредоносный код, а просто вы сохранили какие то файлы(языковые?) в неправильной кодировке. Кодировка должна быть UTF8 без BOM.
0
Спасибо за разъяснение... у меня сайтик один пользуется большим спросом и имеет много конкурентов. Теперь я понял отчего вешается сайт с запросами.

По поводу этой фразы в DOS-атаках можно подробнее?

Цитирую Wedal:

Считаем количество запросов с одного и того же IP-адреса за определенное время (например, 5 мин) и если оно превышает допустимое значение, блокируем этот адрес. К примеру, если за 5 минут с одного адреса поступило более 100 запросов, то заносим этот адрес в список заблокированных и доступ к сайту с него приостанавливается.


Как поставить фильтр?
1
mistershadow, ответил на форуме.
0
И вот замечены большой наплыв атак на Джумлу, сотни сайтов страдают от атак, сами хостеры начинают закрывать админки на время подбора паролей.
0
У меня один образовательный сайт с посещаемостью 1,5 тыщи летом и женский сайт 300 посещений. Долбят уже 3 недели. Админка скрыта, пароль сложный. В .htaccess к админке заблокированы все ip. Уже не хожу в админку. Хостер вопит, что нагрузка запредельная. По логам лезут каждый день с разных ip. Забанила все ip, посещаемость упала еще в 2 раза. Что делать? Ума не приложу.
0
Эльвира, мои самые первые методы такие:
- использовать защиту от флуда - есть в sh404sef. Рекомендую.
- "скрыта админка" - бывает по разному. Эффективнее всего закрыть к ней доступ через .htaccess + .htpassword в админской директории.
- сменить хостера на хорошего )
- если J! 1.5.x - СРОЧНО МЕНЯТЬ на новую!!!

Кто добавит ?
0
Эльвира и Magnum79, действительно сейчас на нескольких сайтах настроил дополнительно .htpassword на админскую директорию, т.е. чтобы войти в админку нужно теперь 2 раза пароль вводить (разные). Если ещё заморочиться, то дополнительно сделать доступ только с одного IP, но мне лично это не удобно, т.к. IP динамически получаю и это не вариант, разве что подсеть разрешать. Joomla однозначно 2.5 или 3.
Также интересно, может быть можно как-то замаскировать Joomla, чтобы боты не могли её определить, но думаю это либо не реально, либо затратно очень.
0
"Замаскировать J!" - это мне напоминает, как в детстсве закрыл глаза и кажется, что тебя нет :) Поможет только от хацкеров подобного возраста :lol:
0
Magnum79, вовсе не обязательно. Дело в том, что большинство ботов работает именно примитивно. Используются самые простейшие определители CMS. Тот же тэг Generator. Это связано с тем, что для ботов важна именно массовость. Если человек хотя бы немного позаботился о безопасности своего сайта, то зачем тратить на такой сайт время и ресурсы? Ведь проще найти в Интернете еще сто таких же незащищенных.
Другое дело - если за сайт хакер взялся лично. Тут уж да - не поможет.
0
Не вижу в этом никакой фантастики.
Другое дело, нужно знать по каким признакам боты вычисляют J-сайты. Также я не говорил что это просто. Только вот что-то сомневаюсь что у хакеров времени сильно больше чем у нас с вами, поэтому, подозреваю что они не делали детальный "портрет" J!, а ограничились наличием каких-то категорий и файлов. Либо есть бот который очень грубо оценивает, а другой детально (так ресурсов значительно меньше нужно для сканирования).
И, конечно, нужно оценивать затраты/выгоду при таких действиях.
0
админы, юзайте компонент фаервола для защиты от различных атак rsfirewall и плагин для смены адреса админки jSecure Authentication. всё GNU
0
Какая-то вода сплошная для "домохозяек", где SQL-инъекции и прочее? Перебором паролей сейчас никто не ломает.
2
Антон, перебором паролей еще как ломают. Так, что хостинги отключают сайты из-за нагрузки на стандартную страницу входа в админку. Говорю, основываясь на личном опыте и опыте заказчиков.
SQL-инъекции - это вам уже на Habr. Я все-таки стараюсь писать общедоступные статьи, реализовать примеры из которых смогут НЕпрограммисты. Инъекции - это уже совсем другой уровень.
0
Заблокировал с помощью .htaccess доступ в директорию /administrator для всех айпишников кроме своего - проблема с подбором решена радикально, хотя у меня и так логины-пароли такие что невозможно подобрать. А SQL-инъекции и прочее легко блокируются плагином jHackGuard, мог бы написать о нём в статье. Мне несколько раз заражали и ломали сайты, так что знаю не по наслышке. Однажды лечил знакомому интернет-магазин от вируса который фактически парализовал ему сайт, гадость сидела в неприметном файлике "картинке" с расширением PNG, обнаружил его пытаясь скачать с хостинга архив с резервной копией, Avast сразу показал где тварь засела.
0
Пол года бьюсь с заразой. Вычищу, а через неделю снова вирусня.
По логам - много post запросов к
200 POST /libraries/cms/table/contenttype.php - HTTP/1.0 http:///libraries/cms/table/contenttype.php Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26
200 POST /modules/mod_search/helper.php - HTTP/1.0 http:///modules/mod_search/helper.php Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0
200 POST /libraries/legacy/log/logexception.php - HTTP/1.0 http:///libraries/legacy/log/logexception.php Mozilla/5.0 (X11; U; Linux i686; en-US) U2/1.0.0 UCBrowser/9.3.1.344
200 POST /libraries/cms/ucm/ucm.php - HTTP/1.0 http:///libraries/cms/ucm/ucm.php Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0

Самопроизвольно появляются шифрованные файлы, рассылающие спам. Админка закрыта через CPanel. Без авторизации не открыть.
0
Алексей, пробовали по инструкции из этой статьи: http://wedal.ru/uroki-joomla/kak-vylechit-zarazhennyj-sajt-na-joomla-ot-virusov-10-shagov.html ?