Без мониторинга конечных точек сегодня уже не получится в полной мере обеспечить безопасность и вовремя обнаруживать факты компрометации инфраструктуры. Джентельменский набор сетевой мониторинг, антивирус и стандартный аудит на конечных точках уже не позволяет противодействовать не только серьезным группировкам, но даже злоумышленникам с низким уровнем подготовки. Почему? Рассмотрим на конкретных примерах.


Кадр из мультфильма Жил-был пес

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

индикаторы компрометации (хеши, IP-адреса и доменные имена) часто бывают одноразовыми, так как их изменение не представляет труда для злоумышленника, особенно в случае с APT;

атакующие применяют в работе легитимные исполняемые файлы, штатные средства ОС и т. д.;

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

на практике часто встречается ВПО, которое не детектируется ни антивирусом, ни сетевыми сигнатурами;

с ростом инфраструктуры становится проблематично вовремя обновлять сигнатуры и лицензии.

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

Мониторинг конечных точек существенно расширяет возможности по выявлению и предотвращению атак: он позволяет перейти от детектирования хешей, IP и доменов к детектированию хостовых артефактов, инструментов и TTP (да-да, той самой пирамиды боли).

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

DLL Hijacking
Living off the land
Использование Mimikatz

Дополнительный мониторинг конечных точек можно организовать с помощью встроенных в ОС средств (расширенный аудит), бесплатных утилит (например, Sysmon) и коммерческих решений (продукты класса EDR). Рассмотрим, какие достоинства и недостатки имеют эти подходы на примерах детектирования различных вариаций упомянутых выше техник.

Расширенный аудит. Windows Event Logging

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

При грамотной настройке мы закрываем некоторые пробелы стандартного подхода и видим:

факты запуска процессов вместе с командной строкой;

запускаемые PowerShell-скрипты в декодированном виде (Script block logging);

частично работу с файлами и реестром;

активность, связанную с учетными записями (создание/удаление пользователей и так далее).

У нас появляется возможность детектировать новые техники:

некоторые варианты DLL hijacking по созданию файлов с определенными путями;

использование LOLBin и Mimikatz по паттернам в командной строке.

При этом у злоумышленника все еще есть возможность избежать обнаружения. В случае с LOLBin это может быть копирование файла в другую папку под другим именем и обфусцирование командной строки. А Mimikatz можно перекомпилировать с измененными командами и строками, что не позволит обнаруживать его использование по командной строке. Также не будут видны варианты, когда на машину помещается легитимный бинарный файл, подверженный DLL hijacking.

Код Mimikatz с измененными строками

Настроить аудит Windows можно на любой системе без предустановки стороннего ПО, но есть и существенные недостатки:

1. Неудобная и плохо масштабируемая настройка.
Пример: чтобы поставить на мониторинг определенную ветку реестра, для нее нужно отдельно настроить ACL. Сам факт того, что нужно проводить какие-то действия, на практике выливается в проблемы и задержки по времени, особенно в случае крупных инфраструктур. Если это делается для расширения мониторинга (например, для детектирования какого-нибудь способа UAC Bypass), то время не играет критической роли. Но если такая необходимость возникает во время инцидента, это затрудняет процесс реагирования.

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

3. Простота противодействия.
Даже злоумышленники с низкой квалификацией знают, как скрываться от стандартного аудита. Вопрос только в том, насколько эффективно и незаметно они это сделают.

Примеры техник:

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

Приостановка потоков службы аудита с последующим выполнением вредоносных действий или удалением событий (например, с помощью инструмента github.com/QAX-A-Team/EventCleaner).

Сокрытие событий с помощью нарушения структуры соответствующего файла .evtx (http://personeltest.ru/aways/github.com/fox-it/danderspritz-evtx).

Временное перенаправление событий в отдельный файл. О такой технике мы писали в предыдущей статье.

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

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

Сходство Sysmon и EDR

Sysmon не является полноценным EDR-решением, так как в нем нет возможности выполнять активные действия на системе. Но механизм сбора событий точно такой же, как и в коммерческих EDR: работает он на двух технологиях обратных вызовах ядра и ETW. Подробно описывать их не будем рассмотрим только, как появляются события и кто инициатор их создания.



Обратные вызовы ядра. Например, PcreateProcessNotifyRoutine, PcreateThreadNotifyRoutine.
Где и как вызываются эти и другие обратные вызовы, можно увидеть в соответствующих функциях ядра. Пример вызова callbackов при создании процесса приведен ниже:



Цикл вызова callbackов в CreateProcessW -> NtCreateUserProcess -> PspInsertThread.
То есть вызывает эти callbackи поток родительского процесса, вызвавший CreateProcess.

Event Tracing Windows (ETW).
В части появления событий ETW работает похожим образом. Снова рассмотрим пример с созданием процесса. При вызове CreateProcessW поток родительского процесса выполняет следующие действия (упрощенная схема):

CreateProcessW (kernel32.dll)
NtCreateUserProcess (ntdll.dll, переход в режим ядра)
NtCreateUserProcess (ntoskrnl.exe, далее работа в режиме ядра)
PspInsertThread (здесь вызываются и callbackи)
EtwTraceProcess
EtwpPsProvTraceProcess
EtwWrite

Таким образом, поток родительского процесса является прямым инициатором создания события ETW. Примерно таким же образом работает запись остальных событий, например, сетевых. Ниже приведен пример создания событий, связанных с сетевой активностью:

Функция ядра EtwpNetProvTraceNetwork

Из всего вышесказанного следует два вывода:

1) И Sysmon, и EDR использует для сбора событий только встроенные возможности Windows, что обеспечивает надежность работы.

2) Злоумышленник может использовать методы сокрытия, которые будут применимы и к Sysmon, и к EDR. Обратные вызовы ядра можно снять в памяти ядра с помощью подписанного драйвера. А зная описанный механизм регистрации событий, можно понять, почему Sysmon и некоторые EDR не могут обнаружить определенные техники инжектирования в процесс (например, с помощью APC) или PPID spoofing.

Sysmon

Использование Sysmon позволяет расширить возможности стандартного аудита. События при этом записываются в отдельный журнал. Некоторые примеры информации, которой нет в аудите Windows, но есть в Sysmon:

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

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

1) копирование LOLBin под другим именем можно выявлять по соответствию полей OriginalFileName, Image и Hashes из события создания процесса;

2) можно детектировать загрузку неподписанных библиотек, что в некоторых случаях позволяет обнаружить DLL hijacking;

3) есть потенциальная возможность выявлять Mimikatz с помощью вышеупомянутых методов или по событию ProcessAccess к процессу lsass.exe.

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

При этом нужно учитывать следующие моменты:

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

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

Внимание со стороны ИБ-сообщества. Так как утилита является бесплатной и общедоступной, сообщество уделяет ей большое внимание. В открытом доступе есть различные варианты конфигурационных файлов, множество правил для Sysmon и тематических статей. Такое внимание работает и в обратную сторону: известны слабые места утилиты, и опытный злоумышленник знает, как остаться незамеченным.

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

Endpoint Detection & Response

С ростом размера и критичности инфраструктуры недостатки Sysmon становятся существенными. Качественные EDR имеют несколько преимуществ (специфические для конкретных продуктов возможности описывать не будем):

1) Расширенный набор регистрируемых событий
Здесь все зависит от конкретного продукта. Например, встречается логирование всего интерактивного ввода в командную строку, что позволяет детектировать техники, которые не видно ни с аудитом Windows, ни с Sysmon.

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

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

2) Централизованное управление и настройка
В большой инфраструктуре возможность централизованной проверки состояния и изменения настроек агента играет критическую роль. Без нее реагирование может затягиваться на часы, а то и на дни.

3) Самодостаточность
В большинстве случаев EDR это самостоятельный продукт со своим интерфейсом, который может использоваться не только в связке с другими инструментами, но и отдельно.

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

4) Возможность активного реагирования
Во время реагирования на инцидент необходимость выполнить какие-либо действия на множестве систем практически всегда становится проблемой.

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

работать с файлами и реестром
блокировать сетевые соединения
завершать процессы
сканировать yara-правилами
собирать артефакты для последующего анализа (например, образ памяти)
автоматизация всего вышеуказанного в той или иной степени
и многое другое.

Так как класс продуктов EDR изначально создавался для обеспечения хостового мониторинга и реагирования, недостатков у таких решений в этой области существенно меньше. Здесь все зависит от возможностей конкретного продукта. Не обходится и без слепых зон, например, отсутствует возможность углубленного анализа сетевой активности (проблема, которая успешно решается продуктами NTA/NDR).

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

Автор: Аскер Джамирзе, старший инженер технического расследования отдела расследования инцидентов JSOC CERT

Я никогда не пользовался Dr. Web. Я понятия не имею, как он устроен. Но это не помешало мне написать для него ряд автотестов (и лишь лень не позволила мне написать ещё сотню других):

1. Тест на установку Dr. Web;
2. Тест на ограничение доступа к съемным устройствам (флешкам);
3. Тест на разграничение доступа к каталогу между программами;
4. Тест на разграничение доступа к каталогу между пользователями системы (родительский контроль).

Такие и многие другие тесты можно клепать как горячие пирожки, и не только применительно к Dr. Web, и не только применительно к антивирусам. В этой статье я расскажу, как это сделать.

Подготовка

Для тестов нам понадобится виртуалка с Windows на борту. Я подготовил её вручную, выполнив на ней следующие манипуляции:

1. Собственно, установил Windows 10 Pro x64;
2. Во время установки создал основного пользователя "testo" в паролем "1111";
3. Включил автологин для этого пользователя;

Для автоматизации тестов я буду использовать платформу Testo. Что это такое и как этим пользоваться можно почитать здесь. Нам же сейчас требуется импортировать готовую виртуалку в автотесты. Сделать это очень просто:

Здесь предполагается, что /path/to/win10.qcow2 это путь к диску той виртуалки, которую я подготовил вручную. На этом подготовка заканчивается, и начинается экшен.

Тест 1 Устанавливаем Dr. Web!

Для начала надо решить вопрос с переносом дистрибутива Dr. Web на виртуальную машину. Сделать это можно (например) с помощью флешки:

Всё, что нам надо сделать это положить установщик Dr. Web в папочку ${DR_WEB_DIR} (точное значение этого параметра мы будем задавать при запуске testo). А Testo само позаботится о том, чтобы этот инсталлятор оказался на флешке.

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

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

Всё, копирование успешно завершено! Теперь можно закрыть окно с флешкой и вытащить её:

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

Завершаем наш тест перезагрузкой. И в конце не забудем проверить, что после перезагрузки на рабочем столе появилась иконка с Dr. Web:

Отличная работа! Мы автоматизировали установку антивируса Dr. Web! Давайте немного передохнём и посмотрим, как это выглядит в динамике:

Переходим к тестированию фич.

Тест 2 Ограничение доступа к флешкам

Первая фича по списку ограничение доступа к флешкам. Для этого спланируем довольно прямолинейный тест:

1. Попробуем вставить флешку и создать там пустой файл должно получиться. Вытащим флешку;
2. Включим блокировку съемных устройств в Dr. Web Security Center;
3. Ещё раз вставим флешку и попробуем удалить созданный файл. Действие должно быть заблокировано.

Создадим себе новую флешку, вставим её в Windows и попробуем создать папку. Что может быть проще?

Создаём новый текстовый файл через контекстное меню проводника:

Отключаем флешку, делаем это безопасно:

Теперь мы убедились, что с флешкой работать можно, а значит можно приступать к её блокировке в центре безопасности Dr. Web. Для этого сначала надо открыть центр безопасности:

Можем заметить, что для открытия любого приложения в Windows нужно выполнить фактически одинаковые действия (кликнуть на строку поиска, дождаться появления окна с популярными приложениями, вбить имя интересующего приложения, дождаться, когда оно появится в списке и, наконец, нажать Enter). Поэтому эту группу действий можно выделить в макрос open_app, в который в качестве параметра будет передаваться имя открываемого приложения:

Этот макрос нам ещё пригодится.

Первое, что мы сделаем, открыв центр безопасности Dr. Web включим возможность вносить изменения:

Теперь немного покликаем по менюшкам и зайдем в меню "Configure device access rules". В этом меню поставим галочку в пункте "Block removable media".

Попробуем открыть флешку теперь:

Вот так потихоньку-полегоньку мы и написали первый тест с тестированием вполне осязаемой фичи в Dr. Web. Настало время передохнуть и помедитировать, глядя на результаты наших трудов:

Тест 3 Разграничение доступа к каталогу между программами

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

1. Установим на ОС стороннюю программу, для которой чуть позже добавим исключение при доступе к защищаемой папке. Сегодня сторонняя программа дня файловый менеджер FreeCommander;
2. Создаем папку с файликом, которую будем защищать всеми силами;
3. Откроем центр безопасности Dr. Web и включим там защиту этой папки;
4. Настроим исключение для FreeCommander;
5. Попробуем удалить файл из защищаемой папки обычным способом (через проводник Windows). Не должно получиться;
6. Попробуем удалить файлик через FreeCommander. Должно получиться.

Ух, много работы. Быстрее начнём быстрее закончим.

Пункт первый, установка FreeCommander не сильно отличается от установки Dr.Web. Обычная рутина: вставили флешку, запустили инсталлятор и так далее. Пропустим это и перейдём сразу к интересному.

Для работы с Dr. Web создадим новый тест dr_web_restrict_program, который будет полагаться на результат работы предыдущего теста win10_install_freecommander.

Начнём тест с создания папки Protected на рабочем столе:

Заходим в папку Protected и создаём там файл my_file.txt, который будет играть роль защищаемого файла:

Ох, надо было бы тоже оформить это в виде макроса, ну да ладно ...

Отлично, теперь надо включить защиту папки. Идём знакомой дорожкой и открываем Dr. Web, не забываем включить режим изменений. После чего переходим в меню "Data Loss Prevention".

Немного поработаем мышкой и добавим нашу папку Protected в список защищаемых:

Ну а теперь надо настроить исключение по доступу к папке для FreeCommander. Ещё немного работы мышкой:

Теперь аккуратно закрываем все окна и пробуем удалить файл "my_file.txt" стандартным способом:

Но ничего не получилось значит Dr. Web действительно отработал! Половина теста позади, но нам ещё надо проверить, что будет работать исключение для FreeCommander. Для этого открываем FreeCommander и переходим в папку Protected:

Ну и попробуем удалить файл my_file.txt:

Исключение для FreeCommander работает!

Отличная работа! Большой и сложный тесткейс и всё автоматизировано. Немного расслабона:

Тест 4 Родительский контроль

Этот последний на сегодня тесткейс мы построим следующим образом:

1. Создадим нового пользователя MySuperUser;
2. Залогинимся под этим пользователем;
3. Создадим файл my_file.txt от имени нового пользователя;
4. Откроем центр безопасности Dr. Web и включим родительский контроль для этого файла;
5. В родительском контроле ограничим права пользователя MySuperUser на им же созданный файл;
6. Попробуем прочитать и удалить файл my_file.txt от имени MySuperUser и посмотрим на результат.

Я не буду приводить здесь сценарий теста. Он строится по тому же принципу, что и предыдущие тесты: активно работаем мышкой и клавиатурой. При этом нам не важно, что мы автоматизируем хоть Dr.Web, хоть создание нового пользователя в Windows. Но давайте всё же посмотрим, как будем выглядеть прогон такого теста:

Заключение

Исходники всех тестов Вы можете посмотреть здесь

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

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

Вот и пришло время подвести итоги конкурса, который мы объявили 21 августа в посте, посвященном анонсу Acronis True Image 2021. Под катом имена победителей, а также еще немного информации о продукте и о потребностях в защите для персональных пользователей.



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

Свой путь к российским пользователям

Сразу несколько хабровчан отметили, что ATI нельзя купить на глобальном сайте, если вы из России. И это чистая правда, потому что разработкой и локализацией Acronis True Image в России занимается ООО Акронис Инфозащита. Это российская компания, которая адаптирует технологии защиты данных и поддерживает продукт для российских пользователей. Версия Acronis True Image 2021 для российского рынка будет доступна осенью

С антивирусом?

В состав Acronis True Image входит антивирусная защита, но это не отдельный продукт, а встроенный в решение движок, который дополняет систему защиты данных. Возможность перехвата вирусов, шифровальщиков и других видов вредоносного ПО помогает не допустить незаметной порчи данных и удаления резервных копий, а также помогает автоматически восстановить оригинальные файлы в случае их повреждения.

Внедрение дополнительной защиты в продукт стало результатом реализации концепции SAPAS, включающей в себя 5 векторов киберзащиты безопасность, доступность, приватность, аутентичность и защищенность данных (SAPAS Safety, Accessibility, Privacy, Authenticity, Security). Таким образом удается дополнительно обезопасить информацию пользователей от порчи или утраты.



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

Победители!

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

• s37 рассказал о том, как важно наличие бэкапа для систем видеонаблюдения, и как можно упустить подозреваемого в краже, если не сохранить вовремя данные с дисков в надежное место
• shin_g поведал трогательную историю о потере игровых сейвов в далеком 2004 году. Наличие бэкапа, но не регулярного привело недавно к потере xls-таблицы c домашним бюджетом и историей покупок за несколько лет, а также библиотеки iTunes, в которой уже были отмечены в избранное более половины из ~10000 треков.
• wmgeek рассказал о том, как злой шифровальщик прятался в установщике взломанного ПО Acronis. В результате были зашифрованы документы пользователя, и он стал загружать только лицензионное ПО.
• CaptainFlint отметил, что важно не только иметь бэкапы, но и хранить их достаточно долгое время. Он бэкапил почтовую базу в Backblaze, но после крэша компьютера узнал, что часть диска была испорчена раньше, чем упала вся система. Но время хранения старых версий в базовом тарифе сервиса составляло всего один месяц, и часть писем оказалась безвозвратно утеряна. Буду апгрейдить тариф до годового срока хранения.
• sukhe рассказал студенческую историю с отключением электричества в аудитории рубильником.
• wyp4ik признался, что факапов с данными было много, но больше всего ему запомнилась атака трояна-шифровальщик Dharma на большую контору, состоящую из микропредприятийю. В итоге было зашифровано 5 сетевых папок разных микропредприятий и для некоторых сотрудников были потеряны файлы за 5 лет работы некоторых сотрудников. При этом для тех ПК, на которых стоял Acronis, все кончилось благополучно.
• drWhy поделился опытом сложностей организации ручного резервного копирования в офисных условиях
• ByashaCat рассказал об атаке почтового шифровальщика, а также об отсутствии денег у подростка на нормальный антивирус и вредоносное ПО в торрентах

Мы обещали наградить троих лучших, но нам, увы, не удалось выбрать их из 8 претендентов. Поэтому общим собранием было принято решение наградить всех! Так что стучитесь в личку, дорогие победители! Мы пришлем вам ключ от продукта.

Я Владислав Чернов специалист по кибербезопасности компании Creative Motion Development. Обеспечение контроля за безопасностью сайтов наша ежедневная рутина и мы порой забываем, что очевидные для нас вещи для многих не очевидны. В этой статье, я расскажу о мерах, которые стоит предпринять, для повышения безопасности вашего сайта.

Хакеры атакуют не менее 50 000 веб-сайтов каждый день. Это тревожные цифры, учитывая, что почти каждый бизнес присутствует в Интернете. Атаки нацелены на все предприятия, включая малые и средние предприятия около 43% атак нацелены на малые предприятия. Веб-сайты содержат много конфиденциальной информации, в том числе личные данные, такие как адреса электронной почты, имена, дата рождения, номера кредитных карт и т. Д. Сегодня защита конфиденциальности информации закреплена в большинстве нормативных актов о соответствии информации. Принятие передовых методов обеспечения безопасности веб-сайтов это шаг к соблюдению этих правил. Таким образом, компаниям необходимо понимать основные методы повышения безопасности своих веб-сайтов. Перед этим важно сначала понять угрозы и риски для доступности, целостности и конфиденциальности веб-сайта.

Общие риски безопасности веб-сайтов

DDoS-атаки

DDoS-атаки одна из самых распространенных угроз безопасности веб-сайтов. В ходе атак хакеры перегружают трафик целевого веб-сайта поддельными IP-адресами. Атаки не позволяют обычным пользователям получить доступ к ресурсам веб-сайта, отказывая им в доступе. Например, Банк Испании подвергся DDoS-атаке в 2018 году. В результате этого веб-сайт банка был отключен от сети, что не позволило пользователям получить доступ к онлайн-сервисам.

Вредоносные программы и вирусы

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

Спам

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

Регистрация домена WHOIS

Все владельцы веб-сайтов должны зарегистрировать свои веб-сайты в определенном домене. Домены требуют от владельцев предоставить некоторую личную информацию для идентификации. Информация регистрируется в базах данных WHOIS. В дополнение к личной информации владельцы веб-сайтов должны предоставить другие типы информации, такие как серверы имен URL-адресов, связанные с веб-сайтом. Хакеры или инсайдеры могут использовать предоставленную информацию для отслеживания местоположения сервера, используемого для хранения информации веб-сайта. После обнаружения сервер можно использовать в качестве шлюза для доступа к веб-серверу и его взлома.

Черные списки сайтов поисковой системы

Некоторые поисковые системы, такие как Google, Bing и другие, заносят в черный список веб-сайты, на которых отсутствуют надлежащие меры безопасности. Таким образом, попадание в черный список не означает угрозы безопасности. Вместо этого сайт работает хуже при оптимизации поисковых систем и может даже не отображаться в результатах поиска. Это серьезно влияет на услуги, предоставляемые через веб-сайт. Например, бизнес, полагающийся на свой веб-сайт для продажи товаров и услуг через электронную коммерцию, может столкнуться с более низкими продажами и сокращением трафика, если он находится в черном списке. Недавний опрос показал, что рейтинг SEO по крайней мере 74% атакованных веб-сайтов подвергается негативному воздействию. Таким образом, предприятиям необходимо внедрять передовые методы обеспечения безопасности веб-сайтов, чтобы защитить их рейтинг в поисковых системах.

Лучшие методы повышения безопасности веб-сайтов

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

Использование протоколов HTTPS

Протокол HTTPS должен быть приоритетом для всех владельцев сайтов. Это не только жизненно важно для обеспечения безопасной связи между веб-сервером и клиентом, но также улучшает базовый стандарт безопасности для всех веб-сайтов. Во-первых, он убеждает пользователей, что все коммуникации, осуществляемые через веб-сайт, безопасны. Протокол HTTPS по сути сообщает посетителям веб-сайта, что информация, которую они запрашивают или просматривают с веб-сервера, не может быть перехвачена или изменена третьими лицами. Во-вторых, веб-браузеры, такие как Google Chrome, идентифицируют и отмечают все веб-сайты, на которых отсутствуют протоколы безопасности HTTPS. Каждый раз, когда посетитель заходит на сайт, он получает уведомление о том, что он небезопасен. Некоторые посетители не захотят продолжать пользоваться услугами веб-сайта, помеченного как небезопасный. Это может оттолкнуть новых посетителей от посещения сайта, что приведет к снижению интерактивного взаимодействия с клиентами.

Кроме того, безопасность HTTPS не позволяет хакерам получить доступ к любому из кодов, используемых для разработки веб-сайта. Злоумышленники иногда изменяют код веб-сайта без защиты HTTP, чтобы отслеживать и получать доступ ко всей информации, которую посетители предоставляют при взаимодействии с веб-сайтом. Информация может включать личные данные, такие как данные кредитной карты, пароли и имена пользователей, а также дату рождения. Что еще более важно, протокол HTTPS позволяет веб-сайту повысить свой рейтинг SEO. Поисковая система, такая как Google, использует меры безопасности HTTP, чтобы вознаграждать веб-сайты более высоким ранжированием в результатах поиска.

Организация может дополнить меры безопасности HTTPS, использовав сертификат Secure Socket Layer (SSL). Безопасность SSL шифрует все коммуникации между сервером и пользователем веб-сайта. Таким образом, он не мешает хакерам распространять вредоносное ПО или проводить атаки. Вместо этого он шифрует информацию, чтобы гарантировать ее недоступность в случае успешной атаки. Благодаря реализации безопасности SSL пользовательские данные остаются защищенными от атак, таких как атаки типа человек посередине (MITM). Сертификаты SSL особенно необходимы для веб-сайтов, обрабатывающих большое количество личных данных, таких как платформы электронной коммерции. Однако все компании должны защищать свои веб-сайты с помощью сертификатов HTTPS и SSL, независимо от услуг, которые они предоставляют через сайты.

Частые обновления программного обеспечения

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

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

Достаточное управление паролями

Невозможно переоценить необходимость принятия эффективных решений для управления паролями. Несмотря на то, что пароли являются самым простым способом обеспечения безопасности веб-сайта, они также представляют наибольший риск для безопасности, если ими не управлять должным образом. Исследование, которое показало, что 25% созданных паролей можно взломать менее чем за три секунды, открывает глаза на то, почему владельцы веб-сайтов должны серьезно относиться к своей практике управления паролями. Любой человек с базовыми навыками может использовать хакерские инструменты, такие как John the Ripper, для взлома пароля. Имея это в виду, какие рекомендуемые методы защиты паролей могут позволить компании повысить безопасность своего веб-сайта?

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

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

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

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

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

Адекватные меры контроля доступа

Контроль доступа является неотъемлемой частью успеха любой программы безопасности. То же самое касается защиты веб-сайтов. Компании, управляющие веб-сайтом, должны определить права доступа для разных пользователей, которые могут получить доступ к сайту. Необходимость в строгом контроле доступа возникает из-за того, что человеческая деятельность является основной причиной кибератак. Недавнее исследование показало, что 95% кибератак происходят по вине человека, что подтверждает это утверждение. Сотрудники с разрешениями на доступ к определенным областям веб-сайта могут совершать ошибки, которые приводят к разрушительным атакам. Чтобы устранить риски, владельцам веб-сайтов необходимо развернуть надежные механизмы контроля доступа.

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

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

Изменение настроек конфигурации по умолчанию

Изменение настроек безопасности по умолчанию это метод обеспечения безопасности, который многие компании обычно игнорируют. Как упоминалось ранее, кибер-злоумышленники стали создавать ботов, предназначенных для автоматического сканирования уязвимых веб-сайтов. Боты также используются для сканирования веб-сайтов, использующих программные инструменты, содержащие параметры безопасности конфигурации по умолчанию. Дело в том, что настройки по умолчанию могут не обеспечивать безопасность и защиту, необходимые для удовлетворения уникальных потребностей данной среды. В результате программы, использующие настройки по умолчанию, очень уязвимы для атак. Злоумышленники могут использовать ботов для идентификации веб-сайтов с одинаковыми настройками по умолчанию, чтобы их можно было использовать с помощью одного и того же вируса или вредоносного ПО. После развертывания веб-сайта компании должны изменить настройки по умолчанию, например, для управления контентом. Некоторые из параметров, которые следует изменить, включают, помимо прочего:

• Пользовательские элементы управления
• Права доступа к файлам
• Настройки комментариев
• Информационная видимость

Частые резервные копии веб-сайтов

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

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

Непрерывный мониторинг

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

Ниже приведены некоторые из важнейших признаков, указывающих на проблемы с безопасностью веб-сайтов, которые необходимо решить:

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

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

Развертывание межсетевых экранов

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

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

Создание плана сетевой безопасности

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

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

1. Сбор информации по основным вопросам безопасности
2. Планирование процесса противодействия
3. Выполнение плана по обнаружению уязвимостей, если таковые имеются
4. Документируйте результаты
5. Устраните выявленные уязвимости, исправив надлежащим образом
6. Проверить безопасность сайта