В последнее время я стал замечать, что в комментариях и на форуме появляется много вопросов, связанных с взломом сайтов. Действительно, каждый владелец сайта, в независимости от того, на чем он (сайт) написан, должен знать базовые принципы защиты от хакерских атак. Это позволит сберечь время, нервы, а иногда и деньги.
Основная проблема всех статей, посвященных безопасности сайтов, заключается в их сложности. Многие уязвимости носят сугубо технический характер и их описание, для простого человека, превращается в набор непонятных слов. Эта статья начинает серию по защите Joomla от взлома. Все вопросы безопасности я постараюсь описывать максимально простым и доступным языком. Чтение данной серии будет полезно всем владельцам Joomla-сайтов, а также начинающим разработчикам.
Нельзя защищаться от врага, не зная, какое оружие он использует. Первое, и самое важное, о чем следует узнать – какие существуют виды атак на сайты. Зная, как сайт можно взломать, гораздо проще понять, как его защитить, или в чем уязвимость, если сайт уже взломан. В этой статье я расскажу про основные виды атак, которые могут быть совершены на Joomla-сайт.
Содержание
Особенность безопасности Joomla, как CMS с открытым исходным кодом
Как известно, Joomla является проектом с открытым исходным кодом. Это означает, что код Joomla может просматривать любой желающий. Хорошо это или плохо? Вопрос спорный.
Чтобы понять преимущества и недостатки открытого кода, представим себе два ящика. Черный и прозрачный. Черный ящик представляет собой закрытый код. Если сайт работает на самописной CMS или же просто на PHP, то увидеть его исходный код нельзя. Все, что можно делать – отправлять какое-то входное воздействие и следить за результатом, который будет получен на выходе. Т.е. вы отправляется запрос (например, заполняете форму и отправляете данные), а в ответ получаете результат выполнения (например, данные успешно приняты или ошибка).
Если же говорить о прозрачном ящике, коим является любой проект с открытым исходным кодом, в том числе и Joomla, то мы можем видеть все процессы, которые в нем происходят. Все точки обработки данных. Можем легко понять причину того или иного результата, получаемого на выходе.
Так что же в итоге лучше с точки зрения безопасности: черный или прозрачный ящик? Первый ответ, который приходит в голову: конечно черный. Ведь незнание процессов обработки данных значительно усложняет взлом. Да, это так, но далеко не всегда. Если закрытый код писал действительно хороший программист, а затем он проходил тестирование, то вероятность взлома крайне мала. Проблема в том, что такой код в основном пишут только сотрудники крупных корпораций, например, Яндекс, Google, Mail.ru, Вконтакте и.т.д. Уровень сотрудников в таких компаниях обычно очень высокий, как и их зарплата. А теперь давайте подумаем, кто пишет сайты для малого и среднего бизнеса? Поверьте мне, далеко не гении программного кода. Зачастую, они допускают элементарные уязвимости, которые в состоянии обнаружить даже автоматические боты, что уж говорить, если за сайт возьмется хакер. Кроме того, закрытый код расслабляет. Зачем программисту писать код качественно, если его все равно никто не увидит?
Теперь посмотрим на открытый код. Да, он полностью просматривается, но этот момент носит не только негативную окраску. Если сообщество проекта с открытым кодом велико (как, например, в Joomla), то информация обо всех обнаруженных уязвимостях оперативно сообщается разработчикам и уязвимости закрываются. Так происходит много раз, в результате чего качество кода становится все выше. Таким образом, открытый код, на мой взгляд, предпочтительнее закрытого, но имеет особенности, которые требуется соблюдать. В первую очередь, это регулярное обновление как Joomla, так и ее расширений. Логика следующая: если вышло обновление безопасности, значит, в коде были найдены уязвимости. Если уязвимости были найдены, значит, о них стало известно. Если о них стало известно, значит, в ближайшее время ими кто-то попытается воспользоваться. Если своевременно обновить Joomla и расширения до последних версий, то уязвимости на сайте будут закрыты раньше, чем ими смогут воспользоваться. Т.е. можно спать спокойно.
Своевременное обновление является основной особенностью защиты Joomla. Важно это понимать. Вы можете не разбираться в тонкостях атак, но должны помнить, что заплатки нужно ставить вовремя, иначе ваш сайт не защитить.
Подбор пароля
Самая простейшая атака на любой сайт – подбор пароля администратора простым перебором. Если вы используете простой пароль на админку, то ждите беды. Как это происходит? Адрес административной панели Joomla широко известен: site.ru/administrator. Также известно, что стандартный логин администратора: admin. Посылаем по этому адресу робота, который будет день и ночь пытаться авторизоваться, используя распространенные пароли и словари, и рано или поздно, пароль будет подобран.
Как защититься от такой атаки? Изменить адрес админки, логин пользователя, использовать сложный пароль, установить защиту от роботов (капчу) в виде кода с картинки. Подробнее об этом я расскажу в отдельной статье.
Социальная инженерия
Еще один массовый тип атак, заключающийся в наплевательском отношении к безопасности владельца сайта ли его доверчивости. Первое хорошо демонстрирует вот эта картинка:
Второе чуть сложнее, но в общем случае выражается нарушением следующих правил:
- не давайте пароли к сайту людям, которым не доверяете;
- с достаточной регулярностью меняйте пароли;
- не ведитесь на звонки и электронные сообщения, в которых запрашивается пароль или требуется перейти по ссылке для его восстановления;
- всегда проверяйте адрес сайта в адресной строке перед тем, как ввести пароль;
- используйте на рабочем и домашнем компьютерах хороший антивирус, с обновленными базами;
- не работайте на компьютере с правами администратора;
- не храните на компьютере в открытом виде пароли к сайту.
Социальная инженерия находит уязвимости не в программном продукте, а в человеке, который им пользуется. На самом деле, всегда самым уязвимым местом любого программного продукта будет являться человек. Будьте бдительны!
Специализированные атаки(XSS, SQL-инъекция и т.д.)
В эту группу можно отнести атаки в возможности совершения которых виноваты разработчики сайтов и расширений. Возникают подобные атаки обычно из-за недостаточной фильтрации пользовательских данных передаваемых на сервер. Теперь простым языком. Предположим, сайт позволяет пользователям размещать объявления. Это происходит следующим образом: пользователь регистрируется, заполняет форму объявления, объявление появляется на сайте. Атака происходит на этапе заполнения формы объявления. Обычно для таких форм используются текстовые поля, содержимое которых затем и показывается на сайте. Но что будет, если злоумышленник добавит в такое поле не только текст, но и ссылку на вредоносный скрипт? Объявление будет показано на сайте и посетителям, просматривающим его, будет загружаться вирус, ну или будет происходить другое вредоносное воздействие.
Чтобы такого не происходило, данные, загружаемые пользователями на сайт, должны проходить жесткую фильтрацию, исключающую возможность загрузить что-либо, кроме того, что предполагается. Решаться эта задача должна разработчиками на этапе создания расширения, но все мы люди и ошибки не являются редкостью. Для Joomla существуют специализированные расширения, проверяющие все формы и другие уязвимые места самостоятельно. О них речь пойдет в отдельной статье.
DOS и DDOS атаки
Опасный вид атак, связанный с ограниченными мощностями сервера, на котором размещается сайт. Суть атаки – отправить на сайт одновременно столько запросов, что сервер перестанет справляться с их обработкой и для обычных посетителей сайт станет недоступным. Понятно, что подобные атаки не могут быть постоянными, а длятся некоторое, хотя иногда и продолжительное, время. Обычно DDOS-атаки используются, когда сайт имеет высокую посещаемость и занимает высокие позиции по конкурентным запросам. DDOS-атаки стоят довольно дорого, но и защиты от них практически нет. Проблема в том, что запросы к сайту осуществляются с зараженных компьютеров обычных интернет-пользователей без их ведома. При этом становится очень сложно отделить обычных пользователей, которые зашли на сайт, от запросов атаки.
Иногда все бывает гораздо проще. На сайт заходит «особо одаренный» человек, который решает создать его копию для личного пользования или других целей. Не представляя себе, как вообще работает сайт, этот человек нагугливает программу, которая обещает скачать сайт целиком. Он устанавливает ее и запускает, натравливая на нужный ему сайт. Что делает программа? Она работает, как и индексирующие роботы поисковых систем: заходит на страницу, скачивает ее, переходит по всем внутренним ссылкам на другие страницы, скачивает их, с тех страниц переходит на следующие и.т.д. При этом получается некое подобие DOS-атаки, при которой большое количество запросов идет с одного адреса. Сайт не успевает обрабатывать их и становится недоступен, либо хостер отключает сайт за превышение нагрузки. Подобные вещи происходили и с wedal.ru. Защита тут очень простая. Считаем количество запросов с одного и того же IP-адреса за определенное время (например, 5 мин) и если оно превышает допустимое значение, блокируем этот адрес. К примеру, если за 5 минут с одного адреса поступило более 100 запросов, то заносим этот адрес в список заблокированных и доступ к сайту с него приостанавливается.
Уязвимости сервера
Часто случается, что во взломе сайта не виноват ни движок ни владелец. Уязвимость может быть найдена на сервере хостера, у которого расположен сайт. Этот случай является довольно частым, особенно когда используется малоизвествный дешевый хостинг. С одной стороны, качество специалистов на нем оставляет желать лучшего, с другой – для хакера это лакомый кусок, взлом которого может дать доступ сразу к сотням сайтов хостера.
Обезопасить сайт от подобных уязвимостей довольно просто: пользуйтесь услугами только проверенных крупных хостеров.
На этом все. Есть и другие виды атак, менее распространенные. Но они будут использоваться в тех случаях, когда ваш сайт представляет для хакера реальный интерес и он решит заняться им лично. Этот случай не частый, поскольку на 95% сайтов Интернета нет ничего, что могло бы интересовать хакеров столь сильно, чтобы они пытались взламывать сайт вручную. Если же сайт приносит действительно большую прибыль и является костью в горле конкурентов, то не грех заказать профессиональный аудит в компании, занимающейся безопасностью.
Не так давно ломанули один мой сайт, где логин/пароль были admin/1234 Юмор в том, что такую простую связку я использовал из-за того, что сайтик был размещен в укромном месте, закрыт для индексации и предназначался только лишь для тестовых целей. Короче, во все .PHP файлы был подписан некий зашифрованный base64 код. Разбираться не стал, потер все нафиг без малейших сожалений.
Подскажите,а то уже не знаю, где искать.
В текстовых файлах Джумла (Контакты, Доставка и Оплата, Приветствие на главной странице), стал появляться вредоносный код,который переделывает текст на данных страницах в знаки "??".
Т.е. на главное странице был текст: Добро пожаловать!! Переделывает в: ????? ??????????!!
Перезалил поверх файлы Джумла, не помогло. Так же прицеплена Virtumart.
Джумла 1.5.22
По поводу этой фразы в DOS-атаках можно подробнее?
Как поставить фильтр?
- использовать защиту от флуда - есть в sh404sef. Рекомендую.
- "скрыта админка" - бывает по разному. Эффективнее всего закрыть к ней доступ через .htaccess + .htpassword в админской директории.
- сменить хостера на хорошего )
- если J! 1.5.x - СРОЧНО МЕНЯТЬ на новую!!!
Кто добавит ?
Также интересно, может быть можно как-то замаскировать Joomla, чтобы боты не могли её определить, но думаю это либо не реально, либо затратно очень.
Другое дело - если за сайт хакер взялся лично. Тут уж да - не поможет.
Другое дело, нужно знать по каким признакам боты вычисляют J-сайты. Также я не говорил что это просто. Только вот что-то сомневаюсь что у хакеров времени сильно больше чем у нас с вами, поэтому, подозреваю что они не делали детальный "портрет" J!, а ограничились наличием каких-то категорий и файлов. Либо есть бот который очень грубо оценивает, а другой детально (так ресурсов значительно меньше нужно для сканирования).
И, конечно, нужно оценивать затраты/выгоду при таких действиях.
SQL-инъекции - это вам уже на Habr. Я все-таки стараюсь писать общедоступные статьи, реализовать примеры из которых смогут НЕпрограммисты. Инъекции - это уже совсем другой уровень.
По логам - много 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. Без авторизации не открыть.