Скрытая угроза: веб-атаки 24x7
Обычно про безопасность и защиту сайтов владельцы и вебмастера задумываются слишком поздно, когда уже возникают видимые и очевидные проблемы: сайт перенаправляет посетителей на рекламные и вредоносные ресурсы, блокируется хостером за спам/фишинг/вредоносную активность, забанен в поисковой системе. То есть когда хакер уже взломал сайт, закрепился на нем и начал генерировать вредную “полезную” нагрузку. Но это происходит не внезапно и не случайно. Процессу взлома всегда предшествует серия атак, которая проводится хакерами или их ботами с целью разведки: обнаружения уязвимостей или скрытых данных, которые можно использовать для взлома и получения несанкционированного доступа к веб-ресурсу. Данные атаки внешне не заметны, поэтому сайтовладельцы в большинстве случаев пребывают в неведении о том, что их ресурсу что-то угрожает (мало кто из них регулярно анализирует логи веб-сервера или пользуется специализированными решениями для детектирования веб-угроз).
Кроме того, значительно снижает бдительность еще и пара заблуждений:
1. “Кому я нужен?”
2. Сайты взламывают только по заказу конкурентов.
Сторонники первого утверждения не считают свой ресурс хоть сколько-то важным и интересным для хакера; приверженцы теории про исключительный “взлом по заказу” считают, что их сайту ничто не угрожает, поскольку ресурс новый/непопулярный/региональный, а бизнес — вне конкуренции. И первые, и вторые пребывают в опасном неведении до тех пор, пока сайт не оказывается взломанным, после чего идет серия удивлений и безуспешных попыток найти виновника инцидента.
Как обстоит дело c безопасностью сайтов в реальности?
Вопреки бытующему мнению о том, что активно атакуют только популярные, посещаемые ресурсы, любой сайт, который появился в поисковой выдаче, в соцсетях или каталогах сайтов (то есть стал публичным), подвергается хакерским атакам. Подавляющее большинство атак на сайты является “нецелевыми” или “обезличенными”, поскольку злоумышленник не ставит задачей взломать конкретный сайт. Его цель – собрать как можно большую базу ресурсов, уязвимых к определенным видам атак, чтобы затем провести взлом или их компрометацию автоматизированными средствами в течение нескольких секунд. Так хакеры собирают себе армии ботов, площадки для хостинга вредоносных скриптов, фишинговых страниц и спам-рассылок. Плохим парням все равно, насколько популярен сайт, какая у него аудитория и тематика, насколько он важен для бизнеса. Сайт представляет ценность только как ресурс хостинга, где есть возможность разместить “зловреды” или с которого можно провести целевую атаку на какой-то определенный веб-ресурс.
Стоимость взлома сайта настолько ничтожна, что не выдерживает никакой конкуренции в сравнении с абузоустойчивыми хостингами, которыми пользовались хакеры несколько лет назад. То есть сейчас им дешевле взломать сотню сайтов на уязвимой Joomla или Wordpress и использовать их для рассылки спама, чем арендовать и настраивать для тех же целей виртуальный сервер.
С каждым годом инструментальные средства для “разведки”, эксплуатации уязвимостей и, в конечном счете, взлома сайта становятся дешевле и доступнее (не секрет, что большинство хакерских утилит можно скачать на форумах и блогах, а видеоинструкцию посмотреть на YouTube). Поэтому число нецелевых атак на сайты, и, как следствие, вероятность взлома, растет чуть ли не в геометрической прогрессии. Если раньше владельцы сайтов и веб-мастера могли рассчитывать на большую долю везения и проблема взлома часто обходила их стороной, то сейчас защитить ресурс от взлома поможет только осведомленность и внимание владельца/подрядчиков к вопросам информационной безопасности. В этой статье мы осветим несколько важных моментов, о которых следует знать всем, кто поддерживает свои сайты или ресурсы клиента.
Чтобы не быть голословным, приведем пример того, как хакер может быстро находить жертв для нецелевого взлома, не прибегая даже к специализированным средствам. Ему достаточно воспользоваться поисковой системой Google и специальной базой запросов, которая называется Google Hacking Database. Данная база содержит перечень запросов (“дорков”) для поиска сайтов, уязвимых к определенным типам атак или содержащих незащищенные файлы с паролями, резервными копиями сайта, адресами закрытых разделов и т.п.
Предположим, хакеру нужно получить доступ к резервным копиям базы данных сайта на Wordpress. Он вводит в поисковую строку “дорк” (не пытайтесь повторить это дома!). И получает список сайтов, на которых администратор забыл закрыть доступ к каталогу uploads с резервными копиями базы данных (а это случается очень часто).
Из дампов хакер может извлечь много полезной для взлома информации. Например, логин администратора и хэш пароля, который расшифровывается специальными сервисами за считанные секунды. Так хакеры получают административный доступ к сайтам, а дальше могут загружать вредоносные скрипты, оставлять закладки, взламывать соседние сайты на аккаунте и т.п.
Весь процесс взлома занимает пару минут, а автоматизированные средства, которыми располагают хакеры, осуществляют за то же время сотни, если не тысячи взломов.
Для того чтобы искать жертв, хакерские боты постоянно “простукивают” сайты, попадающие в поисковую выборку по определенным “доркам”. Поэтому если сайт доступен в поисковой выдаче, то несколько раз в сутки к нему обязательно “постучатся” и проверят, не содержит ли он какую-то уязвимость, через которую его можно взломать, не открыт ли у него доступ к служебным файлам (резервным копиям, дампам базы данных, файлам настроек и т.п.). Одни боты собирают информацию, другие ее эксплуатируют. Естественно, вручную с тысячами сайтов уже не работают, все делается на автомате.
Что делать в данной ситуации рядовому веб-мастеру и владельцу малого бизнеса?
Важно принять тот факт, что сами атаки на сайт невозможно остановить и с ними бесполезно бороться (разве что полностью запретить индексацию сайта поисковиками, не размещать на него ссылок и закрыть от публичного просмотра — что, согласитесь, странно). Но нецелевые атаки можно сделать максимально безопасными для сайта. Для этого потребуется сделать следующее:
1. Принять и осознать факт постоянного сканирования / атак на сайт, здраво оценить риски и последствия (взлом, компрометация доступов, доступ к конфиденциальной информации и т.п.).
2. Выполнить аудит безопасности сайта: просканировать на уязвимости, проверить настройки, файловую систему и базу данных. Это можно сделать самостоятельно или с привлечением соответствующих специалистов.
3. Внедрить технические меры защиты сайта от взлома: обновить CMS и плагины, выполнить “цементирование” сайта, разместить сайт за файерволлом (подключить к сервису облачного WAF и защиты от DDOS), установить мониторинг сайта.
4. Разработать политику безопасности при администрировании и поддержке сайта — организационные меры, которые повысят безопасность ресурса.
5. Постоянно помнить о том, что безопасность — это процесс, а не разовые меры, и она не бывает удобной.
Хорошая новость в том, что для защиты от нецелевых атак, которые составляют по нашим оценкам порядка 95%, достаточно внедрить хотя бы даже часть технических мер, и это уже существенно снизит риск взлома. Главное, чтобы ваш сайт не был «среднестатистическим». То есть даже небольшое внимание к вопросу информационной безопасности сайта сделает его более защищенным от агрессивного интернета.
Статья предоставлена по материалам SEOnews.
Источник: http://prozhector.ru/publications/vypusk-83/skrytaya-ugroza-veb-ataki-24x7/
Дайджест новых статей по интернет-маркетингу на ваш email
Новые статьи и публикации
- 2024-03-13 » Стратегии SEO на 2024 год
- 2024-03-13 » Как использовать анимацию с помощью JavaScript-библиотеки GSAP
- 2024-03-13 » Использование GSAP 3 для веб-анимации
- 2024-03-13 » Cогласование топографической съёмки с эксплуатирующими организациями
- 2024-02-19 » Теряются лиды? Как настроить сквозную аналитику
- 2024-02-17 » Мерч и IT: на что обратить внимание в 2024 году
- 2024-02-16 » Копируем с RSync: основные примеры синхронизации файлов
- 2024-02-15 » Лучшие noCode AI платформы для создания диалоговых ботов
- 2024-02-14 » Факторы ранжирования Google 2024 — исследование Semrush
- 2024-02-12 » Перенос сайта на другой хостинг
- 2024-02-05 » В России сформирован реестр хостинг-провайдеров
- 2024-02-04 » Использование SSH для подключения к удаленному серверу Ubuntu
- 2024-02-03 » Подключаемся к серверу за NAT при помощи туннеля SSH. Простая и понятная инструкция
- 2024-02-02 » Настройка CI/CD для Gitlab-репозитория: схемы и гайд по шагам
- 2024-02-01 » GitLab CI Pipeline. Запуск сценария через SSH на удаленном сервере
- 2024-01-29 » Introduction to GitLab’s CI/CD for Continuous Deployments
- 2024-01-26 » Настройка GitLab CI/CD
- 2024-01-25 » Установка shell gitlab runner
- 2024-01-25 » Установка и регистрация gitlab-runner в docker контейнере
- 2024-01-25 » Переменные Gitlab-Ci
- 2024-01-25 » Настройка CI/CD в GitLab для синхронизации проекта с веб-серверами
- 2024-01-25 » Копирование файлов scp
- 2024-01-18 » Современная обработка ошибок в PHP
- 2024-01-18 » Пример шаблона проектирования MVC в PHP
- 2024-01-18 » Мифический человеко-DevOps
- 2023-12-28 » Google подвел итоги 2023 года в поиске
- 2023-12-28 » 5 ошибок отдела продаж, из-за которых вы теряете клиентов
- 2023-12-28 » Американский суд признал монополию Google на рынках дистрибуции Android-приложений
- 2023-12-28 » Хостинг-провайдер GoDaddy перестанет оказывать услуги пользователям из России
- 2023-12-28 » ТОП-5 методов юзабилити-исследований. Разбор слабых и сильных сторон
Чтобы вырастить плодоносящий сайт - его полезно регулярно поливать и удобрять с помощью рекламы и оптимизации Компания "RedLine" |
Мы создаем сайты, которые работают! Профессионально обслуживаем и продвигаем их , а также по всей России и ближнему зарубежью с 2006 года!
Как мы работаем
Заявка
Позвоните или оставьте заявку на сайте.
Консультация
Обсуждаем что именно Вам нужно и помогаем определить как это лучше сделать!
Договор
Заключаем договор на оказание услуг, в котором прописаны условия и обязанности обеих сторон.
Выполнение работ
Непосредственно оказание требующихся услуг и работ по вашему заданию.
Поддержка
Сдача выполненых работ, последующие корректировки и поддержка при необходимости.