Русский
Русский
English
Авторизация
Ip-адрес
Восстановление пароля
Регистрация
Статистика
Реклама

Защита

Snort или Suricata. Часть 3 защищаем офисную сеть

24.06.2020 18:08:11 | Автор: admin
В предыдущей статье мы рассказали, как запустить стабильную версию Suricata в Ubuntu 18.04 LTS. Настроить IDS на одном узле и подключить бесплатные наборы правил довольно несложно. Сегодня мы разберемся, как с помощью установленной на виртуальном сервере Suricata защитить корпоративную сеть он наиболее распространенных видов атак. Для этого нам понадобится VDS на Linux с двумя вычислительными ядрами. Объем оперативной памяти зависит от нагрузки: кому-то хватит и 2 ГБ, а для более серьезных задач может потребоваться 4 или даже 6. Плюс виртуальной машины в возможности экспериментов: можно начать с минимальной конфигурации и наращивать ресурсы по мере необходимости.

фото: Reuters

Объединяем сети


Вынос IDS на виртуальную машину в первую очередь может понадобиться для тестов. Если вы никогда не имели дела с подобными решениями, бросаться заказывать физическое железо и менять архитектуру сети не стоит. Лучше обкатать систему безопасно и без лишних затрат, чтобы определить потребности в вычислительных ресурсах. Важно понимать, что весь корпоративный трафик при этом придется пропустить через единственный внешний узел: для подключения локальной сети (или нескольких сетей) к VDS с установленной IDS Suricata можно использовать SoftEther простой в настройке кроссплатформенный сервер VPN, обеспечивающий надежное шифрование. Офисное подключение к интернету может не иметь реального IP, потому его лучше поднять на VPS. В репозитории Ubuntu готовых пакетов нет, ПО придется качать либо с сайта проекта, либо из внешнего репозитория на сервисе Launchpad (если вы ему доверяете):

sudo add-apt-repository ppa:paskal-07/softethervpnsudo apt-get update

Посмотреть список доступных пакетов можно с помощью следующей команды:

apt-cache search softether



Нам понадобится softether-vpnserver (сервер в тестовой конфигурации запущен на VDS), а также softether-vpncmd утилиты командной строки для его настройки.

sudo apt-get install softether-vpnserver softether-vpncmd

Для настройки сервера используется специальная утилита командной строки:

sudo vpncmd



Подробно рассказывать о настройке мы не будем: процедура довольно несложная, она хорошо описана в многочисленных публикациях и непосредственно к теме статьи не относится. Если вкратце, после запуска vpncmd нужно выбрать пункт 1, чтобы перейти в консоль управления сервером. Для этого необходимо ввести имя localhost и нажать enter вместо ввода имени хаба. В консоли задается администраторский пароль командой serverpasswordset, удаляется виртуальный хаб DEFAULT (команда hubdelete) и создается новый с именем Suricata_VPN, а также задается его пароль (команда hubcreate). Дальше нужно перейти в управляющую консоль нового хаба с помощью команды hub Suricata_VPN, чтобы создать группу и пользователя с помощью команд groupcreate и usercreate. Пользовательский пароль задается с помощью userpasswordset.

SoftEther поддерживает два режима передачи трафика: SecureNAT и Local Bridge. Первый представляет собой фирменную технологию построения виртуальной частной сети с собственным NAT и DHCP. SecureNAT не требует TUN/TAP, а также настройки Netfilter или другого файрвола. Маршрутизация не затрагивает ядра системы, а все процессы виртуализированы и работают на любом VPS/VDS вне зависимости от использующегося гипервизора. Это приводит к повышенной нагрузке на процессор и снижению скорости по сравнению с режимом Local Bridge, соединяющим виртуальный хаб SoftEther с физическим сетевым адаптером или устройством TAP.

Настройка в этом случае усложняется, поскольку маршрутизация происходит на уровне ядра при помощи Netfilter. Наши VDS построены на Hyper-V, поэтому на последнем шаге мы создаем локальный мост и активируем устройство TAP командой bridgecreate Suricate_VPN -device:suricate_vpn -tap:yes. После выхода из консоли управления хабом мы увидим в системе новый сетевой интерфейс, которому еще не присвоен IP:

ifconfig



Дальше придется включить маршрутизацию пакетов между интерфейсами (ip forward), если она неактивна:

sudo nano /etc/sysctl.conf

Раскомментировать следующую строку:

net.ipv4.ip_forward = 1

Сохраняем изменения в файле, выходим из редактора и применяем их с помощью следующей команды:

sudo sysctl -p

Дальше нам нужно определить для виртуальной сети подсеть с фиктивными IP (например, 10.0.10.0/24) и присвоить адрес интерфейсу:

sudo ifconfig tap_suricata_vp 10.0.10.1/24

Потом потребуется прописать правила Netfilter.

1. При необходимости разрешить входящие пакеты на прослушиваемые порты (фирменный протокол SoftEther использует HTTPS и порт 443)

sudo iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPTsudo iptables -A INPUT -p tcp -m tcp --dport 992 -j ACCEPTsudo iptables -A INPUT -p tcp -m tcp --dport 1194 -j ACCEPTsudo iptables -A INPUT -p udp -m udp --dport 1194 -j ACCEPTsudo iptables -A INPUT -p tcp -m tcp --dport 5555 -j ACCEPT

2. Настраиваем NAT из подсети 10.0.10.0/24 на основной IP сервера

sudo iptables -t nat -A POSTROUTING -s 10.0.10.0/24 -j SNAT --to-source 45.132.17.140

3. Разрешаем проходящие пакеты из подсети 10.0.10.0/24

sudo iptables -A FORWARD -s 10.0.10.0/24 -j ACCEPT

4. Разрешаем проходящие пакеты для уже установленных соединений

sudo iptables -A FORWARD -p all -m state --state ESTABLISHED,RELATED -j ACCEPT

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

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

netstat -ap |grep vpnserver



Поскольку наш тестовый роутер тоже работает под Ubuntu, установим на нем из внешнего репозитория пакеты softether-vpnclient и softether-vpncmd, чтобы воспользоваться фирменным протоколом. Нужно будет запустить клиент:

sudo vpnclient start

Для настройки используем утилиту vpncmd, выбрав localhost в качестве машины, на которой запущен vpnclient. Все команды делаются в консоли: потребуется создать виртуальный интерфейс (NicCreate) и учетную запись (AccountCreate).

В некоторых случаях необходимо задать способ аутентификации с помощью команд AccountAnonymousSet, AccountPasswordSet, AccountCertSet и AccountSecureCertSet. Поскольку мы не используем DHCP, адрес для виртуального адаптера задается вручную.

Кроме того нам потребуется включить ip forward (параметр net.ipv4.ip_forward=1 в файле /etc/sysctl.conf) и настроить статические маршруты. При необходимости на VDS с Suricata можно настроить проброс портов для использования установленных в локальной сети сервисов. На этом объединение сетей можно считать законченным.

Выглядеть предлагаемая нами конфигурация будет примерно так:



Настраиваем Suricata


В предыдущей статье мы рассказывали о двух режимах работы IDS: через очередь NFQUEUE (режим NFQ) и через zero copy (режим AF_PACKET). Второй требует наличия двух интерфейсов, но отличается более высоким быстродействием мы будем использовать именно его. Параметр задан по умолчанию в /etc/default/suricata. Также нам понадобится отредактировать раздел vars в /etc/suricata/suricata.yaml, прописав там виртуальную подсеть в качестве домашней.



Для перезапуска IDS используем команду:

systemctl restart suricata

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

Моделируем атаки


Сценариев боевого применения внешнего сервиса IDS может быть несколько:

Защита от атак DDoS (основное предназначение)

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

Защита от внешних атак других типов

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

Защита от внутренних злоумышленников

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

Для начала создадим еще один тестовый атакующий VPS, а на роутере локальной сети поднимем Apache с конфигурацией по умолчанию, после чего пробросим на него 80-й порт с сервера IDS. Дальше будем имитировать атаку DDoS с атакующего узла. Для этого скачаем с GitHub, скомпилируем и запустим на атакующем узле небольшую программу xerxes (может потребоваться установка пакета gcc):

git clone https://github.com/Soldie/xerxes-DDos-zanyarjamal-C.gitcd xerxes-DDos-zanyarjamal-C/gcc xerxes.c -o xerxes./xerxes 45.132.17.140 80

Результат ее работы оказался следующим:



Suricata отсекает злодея, а страница Apache по умолчанию открывается, несмотря на нашу импровизированную атаку и довольно дохлый канал офисной (на самом деле домашней) сети. Для более серьезных задач стоит использовать Metasploit Framework. Он предназначен для проведения тестов на проникновение и позволяет имитировать самые разные атаки. Инструкция по установке доступна на сайте проекта. После инсталляции потребуется обновление:

sudo msfupdate

Для тестирования запускаем msfconsole.



К сожалению, в последних версиях фреймворка отсутствует возможность автоматического взлома, поэтому эксплоиты придется перебирать вручную и запускать с помощью команды use. Для начала стоит определить открытые на атакуемой машине порты, например, с помощью nmap (в нашем случае его вполне заменит netstat на атакуемом узле), а потом подобрать и использовать подходящие модули Metasploit.

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



Подробнее..
Категории: Блог компании ruvds.com , Информационная безопасность , Системное администрирование , Хостинг , Suricata , Защита

Кибербезопасность и пандемия 5 главных угроз для бизнеса

23.06.2020 10:15:03 | Автор: admin


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

Киберпреступники во время пандемии развили бешеную активность. Так, в начале июня заместитель председателя Совета безопасности РФ Дмитрий Медведев рассказал о росте киберпреступности в РФ на 85%. За последние несколько месяцев количество случаев таких преступлений превысило 80 тысяч. Более половины квалифицируется как тяжкие и особо тяжкие. Но что стало причиной такой активности киберпреступников?

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

Отсутствие надежных инструментов для защиты


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

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

Преступники используют обычные инструменты вроде фишинга, зловредного ПО и т.п. Здесь ничего нового. Но используется все это во много крат активнее, чем раньше. По данным Trend Micro, количество вредоносных URL, связанных с COVID-19, всего за два месяца увеличилось на порядок.



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



Ситуация достигла критического уровня, так что Агентство кибербезопасности и защиты инфраструктурыСША (CISA) выпустило ряд рекомендаций, в которых сказано: Киберпреступники могут воспользоваться всеобщим беспокойством по поводу COVID-19 и пустить в ход фишинговые атаки и дезинформацию пользователей.

Несвоевременное обнаружение кибератак и запоздалая реакция


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

Далеко не всегда весь спектр корпоративных ИБ-инструментов доступен сотрудникам, которые работают из дома. Соответственно, выявление кибератак усложняется, равно, как и своевременная реакция на них. И киберпреступники совершают больше успешных атак, чем раньше. Успешные атаки совершаются и на государственные организации. Так, по сообщению Bloomberg, на прошлой неделе кибератаке подверглось и Министерство здравоохранения и социальных служб США.

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

Работа из небезопасных мест


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

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

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

Массовые увольнения


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

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

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

Кроме того, люди, стремясь сэкономить, ищут недорогие или и вовсе бесплатные предложения разных компаний. Пример бесплатная подписка на видеосервисы или онлайн-курсы. Киберпреступники и здесь проявили себя. Так, весной началась рассылка сообщений в Facebook Messenger о бесплатном доступе к Netflix Premium на 2 месяца. Пользователи, которые получали и открывали его, невольно делились с мошенниками данными доступа к Facebook, а также рассылали это сообщение своим контактам. И это лишь один пример, на самом деле, их тысячи.

Возвращение в офисы




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

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

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

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

В качестве примера удачного решения можно привести кейс Акционерного Банка Трастбанк (ЧАБ Трастбанк), это один из крупнейших банков Республики Узбекистан. Еще до пандемии банк организовал VPN-каналы для связи с 12 удаленными филиалами на базе шлюзов Zyxel. После введения режима самоизоляции в стране эта инфраструктура стала использоваться для организации удаленного доступа для сотрудников.

Тимур Джумабаев, директор департамента безопасности банка прокомментировал ситуацию: С Zyxel мы реализовали наши цели: приобрели качественный продукт и при этом не переплатили. Как банк мы любим считать наши деньги. Отдельное спасибо за то, что в условиях всемирной пандемии коронавируса почти весь состав банка переведен на удаленную работу и благодаря межсетевому экрану Zyxel USG1900 и лицензиям для IP SEC VPN, сотрудника банка спокойно работают из дома при помощи программного обеспечения от Zyxel ZyWall SecuExtender.
Подробнее..
Категории: Информационная безопасность , It-инфраструктура , Пандемия , Блог компании zyxel в россии , Кибербезопасность , Защита

Web scraping вашего сайта непрошеные гости и как их встречают

29.07.2020 18:17:33 | Автор: admin
На первом в истории полностью виртуальном мероприятии РИТ++, прошедшем в конце мая, инженер Qrator Labs Георгий Тарасов, рассказал публике про веб-скрейпинг, он же парсинг, популярным языком. Мы решили предоставить вашему вниманию транскрипцию выступления.



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

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

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



Я буду рассказывать о следующем:

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

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

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

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

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

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



Потому что информация стоит денег, а вовремя собранная информация стоит еще больших денег. Именно поэтому скрейпинг является серьезной статьей заработка для большого количества людей. Это популярная тема на фрилансе: зайдите и увидите кучу заказов с просьбой собрать те или иные данные или написать скрейпинговый софт. Также есть коммерческие организации, занимающиеся скрейпингом на заказ или предоставляющие платформы для этой активности, так называемый scraping as a service. Такое многообразие и распространение возможно, в том числе и потому, что скрейпинг сам по себе чем-то нелегальным, предосудительным, не является. С правовой точки зрения к нему очень трудно придраться особенно на текущий момент, мы скоро узнаем почему.



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



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

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

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

Посмотрим на несколько знаковых примеров.



Первым из которых является скрейпинг и копирование чужих объявлений с сайтов, которые предоставляют доступ к таким объявлениям: автомобили, недвижимость, личные вещи. Я в качестве примера выбрал замечательный гараж в Калифорнии. Представьте, что мы натравливаем туда бота, собираем картинку, собираем описание, забираем все контактные данные, и через 5 минут это же объявление у нас висит на другом сайте похожей направленности и, вполне возможно, что выгодная сделка произойдет уже через него.

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



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



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



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

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



Один из примеров из нашей практики у одного из клиентов. Скрейпер пришел на локацию с параметризованным поиском, который является одной из самых тяжелых операций в бэкенде рассматриваемой структуры. Скрейперу понадобилось перебрать достаточно много поисковых запросов, и он из 200 RPS к этой локации сделал почти 700. Это серьезно нагрузило часть инфраструктуры, из-за чего пошла деградация качества сервиса для остальных легитимных пользователей, взлетело время ответа, посыпались 502-е и 503-и ошибки. В общем, скрейпера это ничуть не волновало и он сидел и делал свое дело, пока все остальные судорожно обновляли страничку браузера.

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



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



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



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

Понятно, что в простом кейсе одна хост-машина, студент с ноутбуком, перебирающий Washington Post, будет сделано большое количество запросов с одними и теми же признаками и параметрами. Это будет очень хорошо заметно в логах, если таких запросов будет достаточно много а значит найти и забанить, в данном случае по айпи адресу, легко.

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

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

Ну и есть граничный случай у нас в практике один раз был такой кейс, когда к заказчику пришел скрейпер с большого количества IP-адресов с совершенно разными признаками пользователей за этими адресами, и каждый такой инстанс сделал ровно по одному запросу за контентом. Сделал GET на нужную страничку товара, спарсил ее и ушел и больше ни разу не появлялся. Такие кейсы довольно редки, так как для них нужно задействовать бльшие ресурсы (которые стоят денег) за то же самое время. Но при этом отследить их и понять, что кто-то вообще приходил сюда и скрейпил, становится намного сложнее. Такие инструменты для исследования трафика, как поведенческий анализ построение паттерна поведения конкретного пользователя, сильно усложняются. Ведь как можно делать поведенческий анализ, если нет никакого поведения? Нет истории действий пользователя, он ранее никогда не появлялся и, что интересно, больше с тех пор тоже ни разу не пришел. В таких условиях, если мы не пытаемся на первом же запросе что-то сделать, то он получит свои данные и уйдет, а мы останемся ни с чем задачу по противодействию скрейпингу мы здесь не решили. Поэтому единственная возможность это по первому же запросу догадаться, что пришел не тот, кого мы хотим видеть на сайте, и отдать ему ошибку или другим способом сделать так, чтобы он свои данные не получил.

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



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



И данная категория является, пожалуй, самой популярной и подробно задокументированной. Даже сложно порекомендовать, что конкретно читать, потому что, реально, материала море. Куча книжек написана по этому методу, есть масса статей и публикаций в принципе достаточно потратить 5 / 4 / 3 / 2 минуты (в зависимости от нахальства автора материала), чтобы спарсить свой первый сайт. Это логичный первый шаг для многих, кто начинает в веб-скрейпинге. Starter pack такой деятельности это чаще всего Python, плюс библиотека, которая умеет делать запросы гибко и менять их параметры, типа requests или urllib2. И какой-нибудь HTML-парсер, чаще всего это Beautiful Soup. Также есть вариант использовать либы, которые созданы специально для скрейпинга, такие, как scrapy, которая включает в себя все эти функциональности с удобным интерфейсом.

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



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

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

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

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

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



Сравнение параметров запроса, заголовков, айпи адреса друг с другом и с публично известными позволяет отлавливать самых наглых скрейперов. Простой пример к нам пришел поисковой бот, но только IP у него почему-то не из сети поисковика, а из какого-нибудь облачного провайдера. Даже сам Гугл на странице, описывающей Googlebot, рекомендует делать reverse lookup DNS-записи для того, чтобы убедиться, что данный бот реально пришел с google.com или других валидных ресурсов Гугла.

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

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



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



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



Да, я говорю в первую очередь о headless-браузерах, потому что этот инструмент, изначально создававшийся для тестирования и Q&A, оказался идеально подходящим для задач веб-скрейпинга на текущий момент.



Не будем вдаваться в подробности по headless-браузерам, я думаю, что большинство слушателей о них и так знает. Оркестраторы, которые автоматизируют работу headless-браузеров, претерпели довольно бодрую эволюцию за последние 10 лет. Сначала, в момент возникновения PhantomJS и первых версий Selenium 2.0 и Selenium WebDriver, работающий под автоматом headless-браузер было совсем не трудно отличить от живого пользователя. Но, с течением времени и появлением таких инструментов, как Puppeteer для headless Chrome и, сейчас, творение господ из Microsoft Playwright, которое делает то же, что и Puppeteer но не только для Хрома, а для всех версий популярных браузеров, они все больше и больше приближают безголовые браузеры к настоящим с точки зрения того, насколько их можно сделать с помощью оркестрации похожими по поведению и по разным признакам и свойствам на браузер здорового человека.



Для того чтобы заниматься распознаванием headlessов на фоне обычных браузеров, за которыми сидят люди, как правило, используются те же самые javascriptовые проверки, но более глубокие, подробные, собирающие тучу параметров. Результат этого сбора отправляют обратно либо в средство защиты, либо на сайт, с которого скрейпер хотел забрать данные. Эту технологию называют fingerprinting, потому что собирается настоящий цифровой отпечаток браузера и девайса, на котором он запущен.

Вещей, на которые смотрят JS-проверки при фингерпринтинге, довольно много их можно разделить на некоторые условные блоки, в каждом из которых копание может продолжаться до плюс бесконечности. Свойств действительно очень много, какие-то из них легко спрятать, какие-то менее легко. И здесь, как и в предыдущем примере, очень многое зависит от того, насколько дотошно скрейпер подошел к задаче сокрытия торчащих хвостов безголовости. Есть свойства объектов в браузере, которые подменяет по умолчанию оркестратор, есть та самая property (navigator.webdriver), которая выставляется в headlessах, но при этом ее нет в обычных браузерах. Ее можно спрятать, попытку спрятать можно задетектировать, проверив определенные методы то что проверяет эти проверки, тоже можно спрятать и подсовывать фальшивый output функциям, которые распечатывают методы, например, и до бесконечности это может длиться.

Другой блок проверок, как правило, отвечает за изучение параметров окна и экрана, которых у headless-браузеров по определению нет: проверка координат, проверка размеров, какой размер у битой картинки, которая не отрисовалась. Есть масса нюансов, которые человек, хорошо знающий устройство браузеров, может предусмотреть и на каждый из них подсунуть правдоподобный (но ненастоящий) вывод, который улетит в проверки fingerprintа на сервер, который будет его анализировать. Например, в случае отрисовки средствами WebGL и Canvas каких-то картинок, 2D и 3D, можно полностью весь вывод взять готовый, подделать, выдать в методе и заставить кого-то поверить в то, что что-то действительно нарисовалось.

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

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

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

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

Маленькое лирическое отступление кому интересно поподробнее почитать про историю и эволюцию проверок, например на безголовость Chrome, есть забавная эпистолярная дуэль двух авторов. Про одного автора я знаю не очень много, а второго зовут Antoine Vastel это молодой человек из Франции, который ведет свой блог о ботах и об их обнаружении, об обфускации проверок и многих других занятных вещах. И вот они со своим визави на протяжении двух лет спорили о том, можно ли задетектить headless Chrome.

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



Значит, мы не будем использовать headless, а будем использовать большие настоящие браузеры, которые рисуют нам окошки и всякие визуальные элементы. Инструменты, такие как Puppeteer и Playwright позволяют вместо headlessа запускать браузеры с отрисованным экраном, считывать user input оттуда, снимать скриншоты и делать многое другое, что недоступно браузерам без визуальной составляющей.



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



А как же CAPTCHA? спросите вы. Ведь OCRом (продвинутую) капчу не решишь без каких-то более сложных вещей. На это есть простой ответ если у нас не получается решать капчу автоматом, почему бы не задействовать человеческий труд? Зачем разделять бота и человека, если можно комбинировать их труд для достижения цели?

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

Понятно, что это тоже стоит копеечку решение капчи закупается оптом. Но если наши данные стоят дороже, чем составят затраты на все эти ухищрения, то, в конце концов, почему бы и нет?

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



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



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

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



Что касается средств защиты, которые применяются против агрессивного скрейпинга, то большинство методов мы уже рассмотрели, говоря про разные категории ботов. Анализ трафика нам поможет от самых простых кейсов, поведенческий анализ поможет отследить такие вещи, как фаззинг (подмена identity) и мультиинстансинг на скриптах. Против более сложных вещей мы будем собирать цифровые отпечатки. И, конечно же, у нас есть CAPTCHA как последний довод королей если мы не смогли хитрого бота как-то поймать на предыдущих вопросах, то, наверное, он споткнется на капче, не правда ли?



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

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



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

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

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

Большое спасибо за внимание!

Подробнее..
Категории: Информационная безопасность , Сетевые технологии , Парсинг , Защита , Web scraping , Ddos , Блог компании qrator labs , Скрейпинг , L7

Перевод Отпечаток браузера что это, как работает, нарушает ли закон и как защититься. Часть 2

14.10.2020 18:14:52 | Автор: admin
image

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

Так что насчет законности сбора отпечатков браузеров?


Мы детально изучили эту тему, но не смогли найти конкретных законов (речь о законодательстве США прим. ред). Если вы можете указать статьи законов, которые регулируют сбор отпечатков браузеров в вашей стране, дайте нам знать, пожалуйста.

Зато в Европейском Союзе действуют законы и директивы (в частности, GDPR и ePrivacy Directive), которые регулируют использование отпечатков браузеров. Это вполне законно, но только в том случае, если организация может доказать необходимость выполнения такой работы.

Кроме того, для использования информации требуется согласие пользователя. Правда, есть два исключения из этого правила:

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

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

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

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

Тест отпечатка своего браузера


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

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


Видите этот список слева? Это далеко не все, остальная часть списка появится по мере прокрутки страницы. Город и регион на скрине не отображаются из-за использования VPN авторами.

Есть и еще несколько сайтов, которые помогают провести тест отпечатка браузера. Это Panopticlick от EFF и AmIUnique, open-source сайт.

Что такое энтропия отпечатка браузера?


Это оценка уникальности отпечатка вашего браузера. Чем выше значение энтропии, тем выше уникальность браузера.

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

Насколько точны эти тесты?


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

Если же говорить об оценке уникальности, то здесь не все так же хорошо, и вот почему:

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

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

Как защититься от сбора отпечатков браузера (простые методы)


Сразу же стоит сказать, что полностью блокировать формирование и сбор отпечатка браузера не получится это базовая технология. Если хотите оградить себя на 100%, нужно просто не пользоваться интернетом.

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

Браузер Firefox с модифицированными настройками

Этот браузер неплох в вопросе защиты пользовательских данных. Недавно разработчики защитили пользователей Firefox от сбора отпечатков третьей стороной.

Но уровень защиты можно повысить. Для этого требуется зайти в настройки браузера, путем ввода в адресной строке about:config. Затем выбираем и меняем следующие опции:

  • webgl.disabled выбираем true.
  • geo.enabled выбираем false.
  • privacy.resistFingerprinting выбираем true. Эта опция дает базовый уровень защиты против сбора отпечатков браузера. Но наиболее эффективна она при выборе и других опций из списка.
  • privacy.firstparty.isolate меняем на true. Эта опция позволяет блокировать cookies от first-party доменов.
  • media.peerconnection.enabled необязательная опция, но, если вы работаете с VPN, ее стоит выбрать. Она дает возможность предотвратить утечку WebRTC и демонстрацию своего IP.

Браузер Brave

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

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


Мы использовали Panopticlick для оценки уровня энтропии. По сравнению с Opera получилось 16.31 бит вместо 17.89. Разница не огромная, но она все же есть.

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

Специализированные расширения для браузера

Расширения щепетильная тема, поскольку они порой повышают уникальность отпечатка браузера. Использовать их или нет выбор пользователя.

Вот что можно рекомендовать:

  • Chameleon модификация значений user-agent. Можно установить периодичность раз в 10 минут, например.
  • Trace защита от разных вариантов сбора отпечатков.
  • User-Agent Switcher делает примерно то же, что и Chameleon.
  • Canvasblocker защита от сбора цифровых отпечатков с canvas.

Используйте лучше одно расширение, а не сразу все.

Tor браузер без Tor Network

На Хабре не нужно объяснять, что такое Tor браузер. По умолчанию он предлагает ряд инструментов для защиты персональных данных:

  • HTTPS везде и всюду.
  • NoScript.
  • Блокирование WebGl.
  • Блокирование canvas image extraction.
  • Изменение версии ОС.
  • Блокирование информации о часовом поясе и настройках языка.
  • Все прочие функции по блокированию инструментов слежки.

Но вот сеть Tor не впечатляет настолько, насколько сам браузер. Вот почему:

  • Работает она медленно. Все потому, что серверов около 6 тыс., а вот пользователей порядка 2 млн.
  • Многие сайты блокируют трафик Tor например, Netflix.
  • Бывают утечки персональной информации, одна из самых серьезных случилась в 2017 году.
  • У Tor странные взаимоотношения с правительством США их можно назвать тесным сотрудничеством. Кроме того, правительство финансово поддерживает Tor.
  • Можно подключиться к ноде злоумышленника.

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

Лучше всего это делать в Notepad++. Открываем его и добавляем в первую вкладку такие строки:

pref(general.config.filename, firefox.cfg);
pref(general.config.obscure_value, 0);


Затем идем в Edit EOL Conversion, выбираем Unix (LF) и сохраняем файл как autoconfig.js в директорию Tor Browser/defaults/pref.

Потом открываем новую вкладку и копируем эти строки:

//
lockPref(network.proxy.type, 0);
lockPref(network.proxy.socks_remote_dns, false);
lockPref(extensions.torlauncher.start_tor, false);


Название файла firefox.cfg, его нужно сохранить в Tor Browser/Browser.

Теперь все готово. После запуска браузер покажет ошибку, но на это можно не обращать внимания.


И да, отключение сети никак не повлияет на отпечаток браузера. Panopticlick показывает уровень энтропии в 10.3 бита, это гораздо меньше, чем с браузером Brave (было 16,31 бит).

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

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

Подробнее..
Категории: Информационная безопасность , Браузеры , Лайфхаки для гиков , Сетевые технологии , Блог компании selectel , Защита , Персональная информация , Отпечаток браузера

В процессоры Intel, AMD и Qualcomm добавят чип безопасности Pluton от Microsoft вместо TPM. Право на ремонт под угрозой?

18.11.2020 20:10:57 | Автор: admin

На днях стало известно о том, что сразу три крупных производителя чипов: Intel, AMD и Qualcomm, планируют встраивать в свои процессоры новый чип безопасности Pluton. Он разрабатывался совместно с корпорацией Microsoft, и в будущем заменит собой используемый в настоящее время модуль TPM. Во всяком случае, о таких перспективах рассказали производители.

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

Что это за чип такой?


О нем день назад Mirosoft детально рассказала в своем блоге.

На текущий день безопасность операционной системы на большинстве ПК зависит от чипа, который называется Trusted Platform Module (TPM). Он является независимым от процессора элементом. В нем хранятся ключи и данные о целостности ОС. Windows работает с TPM уже больше 10 лет, от этого чипа напрямую зависят такие технологии, как Windows Hello и BitLocker.

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


Pluton кардинально изменит ситуацию в сторону усиления защиты. Во-первых, этот чип будет интегрироваться в архитектуру процессора, а во-вторых, он сможет моделировать TPM, полностью заменив собой технологию Trusted Platform Module. К слову, эмуляция TPM дает возможность сохранять совместимость текущих технологий друг с другом, включая все существующие TPM-спецификации и API.

В блоге Microsoft сообщается о том, что в Pluton будут храниться персональные данные, ключи шифрования, ID пользователей и т.п. По словам представителей Microsoft, каким-то образом удалить эти данные из чипа невозможно даже при условии физического доступа злоумышленника к ПК. Pluton получил новую технологию Secure Hardware Cryptography Key (SHACK), которая дает возможность убедиться в том, что ключи шифрования никогда не извлекались из чипа.

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

Откуда взялся Pluton?


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

Сейчас Pluton способен защищать не только от известных атак, но и предотвращать атаки на основе 0-day уязвимостей. Он также совместим с шифрованием Bitlocker и аутентификацией Windows Hello. Да, пока что разработчики заявляют только об ОС Windows что там будет с другими ОС, установленными на системы с чипом, представители Microsoft пока что не поясняют.

Как обновлять прошивку чипа?


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

Такой принцип обновления дает возможность всегда держать прошивку в актуальном состоянии, правда, только при условии подключения к сети, это раз, и два при условии неблокирования самих апдейтов. Многие пользователи ПК блокируют обновления Windows и приложений, желая контролировать свой компьютер и ОС сами.

Когда начнутся внедрение технологии Pluton?


Пока неясно. Но то, что она начнется в скором времени совершенно точно. AMD, Qualcomm и другие производители процессоров подтвердили, что они станут интегрировать Pluton в архитектуру своих чипов. В будущем появится и поддержка Linux, о чем разработчики заявили отдельно. Правда, когда именно, и как это будет работать, пока тоже неясно. Но Microsoft уже использует некоторые продукты на основе Linux в своих системах, где Pluton тоже работает.



Получается, все хорошо, компьютеры станут сверх защищенными?


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

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

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

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

Немного аналогий


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


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

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

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

Подробнее..
Категории: Информационная безопасность , Процессоры , Криптография , Компьютерное железо , Блог компании selectel , Защита , Чипы , Drm , Pluton

Схема Шнорра и её роль в Биткоине

21.12.2020 22:14:07 | Автор: admin

Содержание

  • Историческая справка

  • Суть протокола Шнорра

  • Схема подписи Шнорра

  • Почему подписи Шнорра считаются лучше ECDSA?

Комментарий от автора

Данная статья рассчитана на людей, уже знакомых с основами защиты информации. Если слова "Протокол доказательства знания", "Криптосистема с открытым ключом" не являются для Вас заклинаниями, you're welcome!

Историческая справка

Схема Шнорра была изобретена в 1980 гг. Клаусом-Петером Шнорром. Клаус Шнорр - немецкий криптограф, академик, на тот момент профессор и исследователь Франкфуртского университета. Перед публикациейсамой схемы Клаус Шнорр заморочился с патентами, из-за чего вплоть до 2008 года прямое её использование было затруднительно.

В 2008 году, в том же году, когда Сатоши Накамото представил миру Биткойн, срок действия патента Клауса Шнорра истёк. Даже несмотря на то что подписи Шнорра уже можно было использовать, Сатоши Накамото выбрал для Биткоина ECDSA. Это связано с тем, что схема Шнорра ещё не являлась стандартизированной и широко используемой.

Хоть криптографы зачастую и считают ECDSA неудачным, он до сих пор используется. К слову, DSA, предшественник ECDSA, представлял собой гибрид схем Эль-Гамаля и Шнорра, созданный исключительно для обхода патентов Клауса Шнорра Национальным институтом стандартов и технологий США (NIST). После его появления в рассылке Coderpunks начался, что называется, интеллигентный срач, а Клаус Шнорр стал ещё активнее защищать свои патенты.

Суть протокола Шнорра

Вообще говоря схема Шнорра является одним из вариантов протоколов доказательства с нулевым раскрытием. Доказываем мы то, что для некоторого публичного ключа h, который суть элемент группы с фиксированным порождающим элементом g, известен секрет x такой что g степени x суть у нас публичный ключ h.

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

Первым делом Алиса выбирает случайное число k из подгруппы порядка q, оно должно быть уникально для каждой сессии. Затем Алиса считает I и посылает его Бобу.

Боб также выбирает случайное число из подгруппы и отправляет его обратно Алисе.

Алиса вычисляет s и отправляет его Бобу.

Боб совершает проверку и подтверждает.

A: ~ k \leftarrow \mathbb{Z}_q, I = g \cdot k\\ B: ~ r \leftarrow \mathbb{Z}_q\\ A: ~ s \equiv r \cdot x + k ~ (\text{mod} ~ q)\\ B: ~ g^s \cdot h^{-r} == I

Схема подписи

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

\text{Задана группа} ~ (G, q, g) \\ \text{Gen}(1^n) = x \leftarrow \mathbb{Z}_q; ~ h = g^x; ~ sk = x; ~ pk = h ~~~ (выводим ~ (sk, pk)) \\ \text{Sign}_x(m) = k \leftarrow \mathbb{Z}_q; ~ I = g^k; ~ r \equiv H(I|m); ~ s = r \cdot x + k ~ (выводим ~ (r, s)) \\ \text{Verify}\left( h, m, (r, s) \right) = I \equiv g^s \cdot h^{-r}, ~ H(I|M) == r \\ sk - секретный ~ ключ, ~ pk - публичный ~ ключ

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

Вычисление значения r таким образом (изначальная схема подписи): r \equiv H \left( I | m \right) называется слабым преобразованием Фиата-Шамира, оно НЕ является безопасным. На практике же стоит также добавлять в r ещё и публичный ключ pk. Слабым преобразованием Фиата-Шамира пользовались до 2010-х годов, хотя оно встречается и сейчас, в нём были найдены различные уязвимости, в частности, например, в системе электронного голосования Helios.

Тут public key (pk) - это элемент группы, т.е. его размер невелик и порядка n (на практике всего 33 байта). Отсюда следует, что размер подписи это также 2 числа из группы, т.е. 2n бит (64 байта на практике). Т.е. в сравнении с предыдущими алгоритмами этот на порядки эффективнее.

Схема подписи Шнорра позволяет подписать очень много документов (учитывая, разумеется, уникальность k). В истории были случаи, когда k совпадали в различных документах и это позволяло вскрыть ключ. Таким образом однажды уже взламывали и перепрошивали приставки, в истории Биткоина тоже были подобные случаи.

Почему подписи Шнорра считаются лучше ECDSA?

Чтобы ответить на этот вопрос давайте рассмотрим три основных критерия, по которым мы сравним ECDSA и подписи Шнорра.

  • Безопасность

  • Размер подписи

  • Приватность

Безопасность ECDSA

Вообще говоря, для ECDSA отсутствуют доказательства безопасности для задачи дискретного логарифмирования в группе точек эллиптической кривой при использовании случайного генератора группы, но на самом деле это не основная причина, по которой многие хотят изменить ECDSA на подписи Шнорра. С 2009 года ECDSA на кривой x3+7 достаточно надёжно работает, и если и была обнаружена какая-то критическая уязвимость, то уже давно об этом знали. То есть фактически на данный момент ECDSA и описанной кривой вполне достаточно. Выходит, дело тут немножко в другом.

Давайте рассмотрим размер подписи. Где вообще на находится это значение? У нас есть транзакция:

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

В выходах находится value и scriptPubKey - условия траты монет, то есть по сути условия, которые должны выполняться для того, чтобы монеты были потрачены.

Если транзакцию подписывает один участник, то размер одиночного значения подписи плюс-минус одинаковый для ECDSA и для подписи Шнорра. Но что если мы используем мультиподпись, т.е. транзакцию подписывает несколько человек?

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

Приватность ECDSA

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

Размер подписи ECDSA

Давайте выделим ключевые поля транзакции: это scriptSig , то есть доказательства владения монетами, и scriptPubKey, то есть условия траты монет. Эти поля занимают самое большое место в входах и выходах транзакций. Изначально архитектура подразумевала, что каждый конкретный вход должен содержать значения подписи (то есть когда вы хотите потратить монет с конкретного выхода, вы должны подать на вход значение подписи). В выходе транзакций находится собственно адрес получателя. То есть как мы уже рассматривали в ECDSA, могла произойти такая ситуация, что в одном входе содержалось n значений, в другом m и т.д. Это огромные объёмы данных.

А что же подпись Шнорра?

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

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

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

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

Касательно приватности в подписи Шнорра. Что такое общий открытый ключ? В общем виде это сумма публичных ключей, это наш агрегированный публичный ключ. Значение подписи тоже агрегируется таким же образом, и получаем одно общее значение подписи. Этот публичный ключ соответствует этой подписи. Когда валидатор проверяет такую транзакцию, в выходе транзакции у нас находится ровно один публичный ключ, во входе транзакции находится ровно одно значение подписи. То есть независимо от того, подписал транзакцию один человек или это была мультиподпись, валидатор не замети тэтой разницы. Это положительно влияет на приватность, ведь нельзя соотнести общий открытый ключ с конкретными субъектами.

В итоге

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

Источники

Подробнее..
Категории: Информационная безопасность , Криптография , Криптовалюты , Защита , Биткоин , Криптовалюта , Схема , Протокол , Информации , Ecdsa , Шнорр , Подписи

Возможные способы организации атак на киберфизические системы

28.12.2020 12:07:24 | Автор: admin

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

История инцидентов киберфизической безопасности

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

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

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

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

В 1998 году подросток из Массачусетса стал первым несовершеннолетним в Соединенных Штатах, которому в Федеральном суде было предъявлено обвинение в хакерстве. Годом ранее он ворвался в сеть телефонной компании и вызвал аварию, которая вывела из строя системы Digital loop carrier (DLC) в региональном аэропорту Вустера. Эти системы используются для интеграции передачи голоса и данных с нескольких телефонных линий для цифровой передачи по одному кабелю высокой емкости. Это намного эффективнее, чем иметь сотни линий из каждой части инфраструктуры аэропорта отдельно подключен к диспетчерской вышке, но если DLC отключен, то все связанные с ним коммуникации тоже отключены. Конкретные DLC были доступны для внешних модемов, так что технические специалисты компании могли поддерживать обслуживание удаленно. Подросток определил их телефонные номера и подключился к ним с помощью модема своего персонального компьютера. Затем он отключил передатчик, отвечающий за включение огней взлетно-посадочной полосы, а также связь с диспетчерской вышкой, пожарной службой, Службой безопасности аэропорта и метеорологической службой в течение 6 часов. Хотя отключение не вызвало каких-либо серьезных проблем, Секретная служба США рассматривала инцидент как вопрос национальной безопасности.

В 1999 году трубопровод в Беллингхеме, штат Вашингтон, разорвался из-за замедления системы SCADA, управляющей им [1]. До этого подрядчик нанес внешнее повреждение трубопроводу, устанавливая поперек него водопроводные линии. Из-за этого повреждения и неправильной конфигурации некоторых недавно установленных клапанов давление начало расти. Обычно это обнаруживалось и смягчалось с помощью системы SCADA, но последняя перестала реагировать. Хотя он был настроен на сбор последних данных от удаленных терминальных блоков (RTU) каждые несколько секунд, HMI оператора не будет отображать обновление в течение нескольких минут. Более позднее расследование показало, что в то время системный администратор программировал новые программы. Отчеты по базе данных системы SCADA без предварительного тестирования их в автономном режиме. Еще одна ошибка заключалась в том, что для всех пользователей существовала одна учетная запись входа, и это была учетная запись администратора с настройкой приоритета, которая позволяла назначать ей все доступные вычислительные ресурсы. В результате ошибка программирования может не только непосредственно повлиять на работу системы SCADA, но и поглотить все ее ресурсы. Поскольку он не реагировал, контроллеры не могли управлять насосами удаленно, чтобы вовремя смягчить воздействие повышения давления. Последовавшее за этим возгорание бензина привело к гибели трех человек и нанесло значительный ущерб окружающей среде.

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

В 2000 году произошел подтвержденный инцидент в Австралии, явно связанный со злым умыслом. Сегодня он известен как атака Маручи. Район природной красоты с несколькими водными каналами, парками и примерно 120 000 жителей. В 2000 году его совет только недавно установил комплексную SCADA-инфраструктуру для управления своими 880 километрами канализационных коллекторов и 142 насосными станциями, когда его инженеры начали замечать необычное поведение. О неисправностях оборудования не всегда сообщали вовремя, насосы не реагировали на удаленные команды, а связь с центральным управлением часто терялась. Поначалу считалось, что это временные проблемы новой инфраструктуры, но постепенно она стала разрушаться. Стало очевидно, что здесь, должно быть, есть какое-то человеческое участие. Даже после того, как все программное обеспечение было переустановлено, конфигурация насосов неожиданно менялась таким образом, который мог быть приписан только человеку-пользователю. Подозрения подтвердились, когда инженер, вызванный для расследования, обнаружил неизвестное беспроводное оборудование, подключенное к системе.

Инженер пришел к выводу, что пользователь подключается к насосы с ноутбуком, быстро перемещающиеся от станции к станции. Нападения продолжались два с половиной месяца, пока полиция не остановила мужчину за нарушение правил дорожного движения возле одной из насосных станций и не арестовала его после того, как в его автомобиле было обнаружено подозрительное компьютерное и радиосвязное оборудование. Задержанным оказался Витэк Боден, ранее работавший внештатным подрядчиком в качестве начальника участка по монтажу коммуникационной инфраструктуры проекта Maroochi SCADA. Уйдя в отставку с этого поста, Боден искал работу в Совете графства Маручи, но ему дважды отказывали. Именно тогда начали наблюдать необычное поведение SCADA системы. Имея специальные знания и опыт работы с внешним подрядчиком, Витэк Боден был инсайдером. Он имел доступ к специализированному программному обеспечению, используемому для управления насосами, знал, как подключиться к насосным станциям, и хорошо понимал процедуры, связанные с управлением сточными водами на основе SCADA.Основываясь главным образом на доказательствах, найденных в его ноутбуке, он был приговорен к 2 годам тюремного заключения за то, что вызвал выброс 800 000 литров неочищенных сточных вод в парки, общественные водные пути и территорию отеля.

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

Ещё одна авария Сан-Бруно, Калифорния, в 2010 году. Взрыв трубопровода природного газа, в результате которого погибли восемь человек и еще 60 получили ранения, также частично объяснялся ошибочными и недоступными показаниями давления SCADA. Сбой питания привел к ошибочному сообщению значений низкого давления, что в свою очередь привело к полному открытию регулирующих клапанов и повышению давления в трубопроводе.Системы управления также могут быть затронуты вредоносными программами, и таких примеров в энергетическом секторе предостаточно.

Киберфизические атаки на промышленные системы управления

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

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

С тех пор системы SCADA приняли распределенную архитектуру (второе поколение, рисунок 2), включающую несколько серверов, каждый из которых отвечает за свой аспект системы. Переход от проприетарных протоколов конкретных производителей к открытым протоколам, которые позволяют использовать компоненты COTS(готовые аппаратные и программные технологии открытого типа) способствует смене архитектуры (третье поколение, рисунок 1). Связь системы посредством локальных сетей позволило работать на больших географических территориях и в разнообразных сетевых инфраструктурах, включая глобальные сети и Интернет. В четвертом поколении (рисунок 1) систем SCADA делается упор на взаимосвязанность и взаимодействие различных технологий. Для контроля отображается полноценная сетевая среда устройств, отправляющие отчеты напрямую через Интернет и без необходимости в RTU и человеко-машинных интерфейсах (HMI), которые не ограничены центральным местом, но доступны из любого места через мобильные устройства

Рисунок 1 - Поколения SCADA и их архитектура

Этапы киберфизической атаки

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

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

Источники информации:

  • сайт поставщиков ПО или оборудования поможет узнать оборудование, используемое в киберфизических системах организации;

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

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

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

Социальная инженерия - распространенный механизм разведка киберфизических систем и особенно промышленных системы пробного контроля. Даже самые сильные технические средства защиты могут быть обойдены, если пользователя системы заставить ввести пароли или нажать вредоносную web-ссылку. Конфиденциальную информацию содержат выбрасываемые в мусор ненужные банковские выписки, USB-накопители, черновики проектных предложений, письма и другие материалы (метод dumpster diving). Крайняя форма dumpster diving - это покупка утилизированных копировальных аппаратов организации, чтобы получить их внутренние жесткие диски[2]. Их владельцы часто не протирают их, хотя они содержат отсканированные документы за многие годы.

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

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

Watering Hole - стратегия атаки, при которой злоумышленник наблюдает или угадывает какой веб-сайт посещает конкретная цель часто, а затем внедряет вредоносное ПО на этот веб-сайт [3]. Последствие: несанкционированное получение важной информации, включая учетные данные для входа / пароля, а также передача вредоносного ПО, которое облегчит атаку.

После получения некоторой предварительной информации о цели,злоумышленник пытается расширить эту информацию путем сканирования на предмет конкретных уязвимостей. Три самых популярных инструмента для сканирования сети используются Nmap [4], Несс [5] и Wireshark [6]. В совокупности они могут определить работающую операционную систему у цели, прослушивать сетевой трафик и сканировать на предмет открытых сетевые портов, неправильная конфигурация, пароли по умолчанию и т.п..

Всем пользователям известны такие поисковые системы как Google, Яндекс, Рамблер, Yahoo, Bing и можно перечислять еще множество как отечественных, так и зарубежных поисковиков. Такие поисковые службы ищут в сети веб-страницы, картинки, видео, документы и новости. Но в узких кругах, например служб специализирующихся на разведке, кибербезопасности и кибератаках пользуются Shodan.

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

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

Глушение связи (communication jamming)

Преднамеренное создание помех, затрудняющих прием сигнала. В простейшей форме, когда пользователь A общается с пользователем B по беспроводному каналу, злоумышленник должен находиться поблизости от A или B и передавать достаточно сильный беспроводной сигнал в том же диапазоне частот. Глушители беспроводного сигнала. недорогие и относительно простые в использовании. Блокирование может быть проактивным, и в этом случае злоумышленник блокирует беспроводной канал непрерывно, или реактивным, и в этом случае злоумышленник перехватывает беспроводной канал и блокирует его только при обнаружении законной связи. Данный метод нарушает связь, которое, в свою очередь, может повлиять на физический процесс. Происходит задержка или предотвращение срабатывания физических процессов, требующих беспроводной связи. В зависимости от конструкции системы также возможно неправильное / несанкционированное срабатывание. Например, потеря беспроводной связи с центром управления может вызвать автоматическое действие, такое как переход БПЛА в режим возврата на базу.

Подача команд (command injection)

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

Ввод ложных данных (false data injection)

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

Атака посредника (man-in-the-middle)

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

Рисунок 2 - Атака типа "man-in-the-middle"

Повторная атака (replay attack)

Противник наблюдает и записывает коммуникационную последовательность, чтобы воспроизвести ее позже. При воспроизведении сообщений, содержащих измерения датчиков, это атака обмана, которая влияет на актуальность данных, от которых зависит киберфизическая система. Stuxnet широко использовал такую атаку, чтобы не дать диспетчерам ядерной установки замечать аномальное состояние системы. Если воспроизводится коммуникация, содержащая управляющие команды, такие как close the valve, deliver insulin, unlock the door, повторная атака эффективно позволяет управлять исполнительными механизмами киберфизической системы без необходимости полного понимания того, как каждый сетевой пакет и каждая команда структурирована, в этом и заключается большое преимущество. Это не требует детального знания внутренней работы целевой системы; только наблюдение, что за определенной коммуникационной последовательностью следует конкретное действие. Его недостатком является то, что он не может производить измерение датчика или команду управления, которая не была передана и захвачена ранее.

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

Внедрение кода / модификация прошивки (Code injection/firmware modification)

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

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

Атака несёт нарушение конфиденциальности и целостности. Для хорошо известных атак путем внедрения кода наиболее эффективной защитой является устранение уязвимостей путем исправления соответствующих недостатков конструкции.

Заражение вредоносным ПО (malware infection)

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

Вирусы - это программы-паразиты, которые заражают другие программы вредоносным кодом и активируются только тогда, когда пользователи запускают эти зараженные хост-программы. Они также распространяются только в результате действий человека (например, прикрепляются к электронному письму, передаются по сети, переносятся на USB-накопитель и т. д.).

Черви очень похожи на вирусы, но также могут самовоспроизводиться без вмешательства человека и автоматически заражать другие компьютеры в той же сети. Они могут сделать это, отправив свою копию по электронной почте каждому из списка контактов зараженного компьютера, удаленно, взломав законную сетевую службу, предоставив общий доступ на съемные носители и т. д. Черви часто вызывают серьезные нарушения в физическом пространстве (Stuxnet).

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

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

Сеть ботов (botnet), который они затем могут сдать в аренду другим киберпреступникам. Сеть ботов из примерно 10 000 ботов, которого достаточно, чтобы нарушить работу крупного веб-сайта с помощью атаки типа DoS, можно арендовать всего за 200 долларов в день. [9]

Руткиты - это наборы программных инструментов, которые в основном направлены на сокрытие присутствия злоумышленника, который уже взломал систему.

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

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

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

Отказ в обслуживании (denial of service)

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

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

К 2013 году самая крупная атака уже достигла 400 Гбит / с. Чтобы скрыть свою личность и затруднить защиту, злоумышленники обычно подделывают свой исходный адрес, указывая поддельный адрес в заголовках сетевых пакетов атаки. Как правило, получателю очень сложно установить истинный источник поддельного сетевого пакета. Это становится еще более трудным при атаке отражения, когда боты не отправляют трафик прямо к своей цели. Вместо этого они отправляют запросы на подключение легитимным компьютерам.

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

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

Глушение GPS (GPS Jamming)

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

Чёрная дыра (black hole)

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

Мошеннический узел (Rogue Node)

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

Изоляция сети (Network Isolation)

Сложный тип атак на крупномасштабные киберфизические системы, такие как интеллектуальные сети и системы управления светофорами. Атака направлена на изоляцию определенной физической географической области от сети [10]. Никакого особого подхода не требуется, но один из способов достижения этого - компрометация сетевых узлов, которые окружают целевую область, выборочное отбрасывание или задержка сетевых пакетов от них и к ним. На практике это скоординированная атака черная дыра, при которой цели выбираются в зависимости от физического географического района, который они обслуживают. Злоумышленник должен хорошо знать географическое покрытие сети и координировать атаки на большое количество сетевых узлов. Это потенциальная угроза для интеллектуальной сети, поскольку сильное воздействие может оправдать вложения злоумышленника в детальную разведку сети и выявление уязвимостей, которые могут потребоваться. Атака вызывает нарушение целостности сетевой системы на скомпрометированных узлах и потеря доступности сети. Физическое воздействие атаки то же, что и атака черная дыра, но сосредоточено на датчиках и исполнительных механизмах конкретной географической области

Рассмотрим точки входа для атак на разные системы (таблица 1). Точки входа для атак на системы умного дома описаны в таблице 2.

Таблица 1 - Точки входа для атак систем SCADA

Описание точки входа

Вероятные атаки

Радиосвязь между RTU/PLC и датчики/исполнительные механизмы

Глушение связи, подача команд,ввод ложных данных

RTU / PLC и связь с серверами SCADA

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

Сеть управления, включая серверы SCADA и рабочие места инженеров

Заражение вредоносным ПО, отказ в обслуживании, посредник

Коммуникационный шлюз / канал между системой управления и корпоративной сетью (например, соединение между первичным и вторичным архиватором)

Отказ в обслуживании, введение ложных данных (на основе базы данных)

Корпоративная сеть

Заражение вредоносным ПО, социальная инженерия

Интернет и сети партнеров

Веб-атаки (вредоносное ПО, SQL-инъекции и т. д.), Социальная инженерия

Таблица 2 - Точки входа для атак на системы умного дома

Описание точки входа

Вероятные атаки

Сеть Wi-Fi и маршрутизатор Wi-Fi

Взлом паролей для Wi-Fi роутера, сниффинг пакетов, отказ в обслуживании, мошеннический узел, глушение связи

Приложение для смартфона или ПК для управления через Интернет

Взлом паролей приложений для смартфонов или ПК, вредоносное ПО на смартфоне или ПК

Stuxnet

Хотя компьютерные системы SCADA широко использовались для удаленного мониторинга и управления оборудованием с 1960-х годов, только в последние годы их киберугрозы привлекли значительное внимание. Исследователи склонны сосредотачиваться на конкретных уязвимостях, вносимых Modbus, DNP3 и другими протоколами связи промышленного управления, большинство из которых изначально были разработаны для простоты и эффективности, а не безопасности. Тем не менее, на практике наиболее часто используемые уязвимости имеют мало общего с конкретными протоколами и в значительной степени такие же, как и в обычных компьютерных системах, начиная от программных ошибок и заканчивая неправильными паролями. Разница заключается в последствиях их эксплуатации, поскольку нарушение безопасности может напрямую повлиять на общественную безопасность. Кроме того, обеспечение безопасности системы SCADA может быть очень сложной задачей из-за ее строгого характера в реальном времени, требования к непрерывной доступности, ошибочного представления о том, что устаревшие технологии SCADA по своей сути безопасны просто из-за того, что они не ясны, все чаще используются компоненты COTS и взаимосвязь с другими. сети, такие как корпоративные сети и даже Интернет.

Самым значительным из реальных инцидентов, связанных с промышленными системами управления, была атака Stuxnet на завод по обогащению урана в Натанзе, Иран. Пример исключительно продвинутого вредоносного ПО, нацеленного в первую очередь на причинение физического ущерба, Stuxnet нацелился на определенные типы ПЛК, контролирующих различные аспекты процесса обогащения урана. Ранний вариант Stuxnet, который должен был прекратить работу в 2009 году, был предназначен для предохранительных клапанов; наиболее известный вариант был направлен на повреждение центрифуг путем изменения скорости вращения. Stuxnet использовал украденные цифровые сертификаты, четыре уязвимости нулевого дня и множество инновационных методов, чтобы проникнуть в закрытую сеть ПЛК предприятия. Масштаб воздействия атаки неясен, но влияние на стратегическое мышление, тенденции атак и понимание людьми потенциала киберфизических атак было огромным.

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

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

Механизмы защиты и принципы безопасного проектирования

Большинство семейств механизмов безопасности, разработанных для кибернетической атаки применимы независимо от того, есть ли отрицательное воздействие в физическом пространстве. Тем не менее, есть существенные отличия между обычными компьютерными системами и киберфизическими системами с точки зрения развертывания и эффективности каждого механизма безопасности (таблица 3) [11].

Таблица 3 - Отличия между обычными компьютерными системами и киберфизическими системами

Меры защиты

Обычная компьютерная безопасность

Кибер-физическая безопасность

Аутентификация

В большинстве случаев наиболее практичными являются аутентификация на основе пароля / парольной фразы или токенов.

Биометрия, близость и местоположение

аутентификация может быть особенно подходящей.

Контроль доступа

Большинство подходов сосредоточены в первую очередь на конфиденциальности и целостности.

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

Обнаружения вторжений

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

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

Межсетевой экран

Используется в большинстве компьютерных сетей.

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

Антивредоносное ПО

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

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

Белый список приложений

Все более популярны, но несколько непрактичны, если важна гибкость.

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

Белый список потока

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

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

Криптография

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

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

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

Проверка целостности

Аппаратная аттестация с использованием TPM широко используется на ПК уже несколько лет.

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

Живучесть

Акцент чаще всего делается на избыточном хранении данных и предотвращении повреждения и потери данных.

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

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

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

Библиографический список

1. Ким Зеттер. Отчёт к нулевому дню [электронный ресурс] режим доступа: https://clck.ru/SbttK

2. Dumpster Diving - Security Through Education [электронный ресурс] режим доступа: https://clck.ru/Sc3FU

3. Security Strategies for Hindering Watering Hole Cyber Crime Attack - ScienceDirect [электронный ресурс] режим доступа: https://clck.ru/Sc3GR

4. Nmap: the Network Mapper - Free Security Scanner [электронный ресурс] режим доступа: https://nmap.org/

5. Tenable - The Cyber Exposure Company [электронный ресурс] режим доступа: https://www.tenable.com

6. Wireshark Go Deep. [электронный ресурс] режим доступа: https://www.wireshark.org/

7. Белая шляпа для Shodan. Как легально использовать поисковик по IoT Хакер (xakep.ru) [электронный ресурс] режим доступа: https://xakep.ru/2015/11/25/shodan-howto/

8. Types of Malware | Internet Security Threats | Kaspersky [электронный ресурс] режим доступа: https://www.kaspersky.com.au/resource-center/threats/malware-classifications

9. Distributed Denial-of-Service, DDoS (отказ от обслуживания) [электронный ресурс] режим доступа: https://clck.ru/Sc3L3

10. Shin, D. H., Koo, J., Yang, L., Lin, X., Bagchi, S., and Zhang, J. (2013). Lowcomplexity secure protocols to defend cyber-physical systems against network isolation attacks. In Conference on Communications and Network Security (CNS), pp. 9199, IEEE, October 2013.

11. George Loukas. Cyber-physical attacks: a growing invisible threat. Butterworth-Heinemann (Elsevier), 2015.

Подробнее..
Категории: Информационная безопасность , Интернет вещей , Антивирусная защита , Уязвимости , Scada , Защита , Атаки , Киберфизические системы , Виды атак

Контролируем подрядчиков на ответственном проде внедрение DLP UAM (промшпионаж, логи действий)

29.12.2020 10:06:55 | Автор: admin
Кадр из художественного фильма TWARDOWSKY 2.0

У заказчика есть главная система, через которую он делает продажи всего-всего. К ней имеют доступ подрядчики, которые разрабатывают и дополняют эту систему, а также персонал изнутри. Когда речь про железо, всё достаточно просто: подрядчик приходит в ЦОД, а безопасник из офиса контролирует его по видео. А вот когда речь про разработку, проконтролировать закладки или вынос информации так не выйдет.

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

Собственно, дальше мы начали внедрять систему защиты.

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

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

Что сделали


У заказчика внедрена система DLP (Data Leak Prevention), которая позволяет находить инсайдеров, ну или людей, которые потенциально по незнанию сливают какие-то данные. Она работает примерно по тому же принципу, как работают эвристики антивируса: сравнивают нормальное поведение исполняемых модулей с ненормальным. В данном случае поведение конкретных людей сравнивалось с нормальным, то есть средним по больнице. Это не подходило для нормальной защиты, потому что выявляло только самые простые случаи, плюс давало много ложных тревог: роли-то у людей очень разные.

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

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

Зачем нужна защита такого класса в принципе


Система заказчика, скажем так, too big to fail. Остановка рабочего процесса означает многомиллиардные убытки. Я не шучу, на прод завязаны вещи, которые прямо влияют на несколько сотен тысяч людей в день. Конечно, система задублирована, есть возможность деградации до критичных функций в случае совсем сильных повреждений и так далее. В проде есть работа с банковскими данными, персональными данными и довольно лакомая база для злоумышленников. Соответственно, инсайдер, предположительно, выделял определённый сегмент клиентов и пытался его унести.

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

Окупаются системы такого класса обычно за год. Речь про снижение рисков, а каждый риск имеет некую вероятность реализации за какой-то период (обычно год) и стоимость. Я бы сказал, что эти системы, скорее, гигиеническая вещь, без которых нельзя работать ни на одном проде, где есть что-то важное. Но часто требуется финансовое обоснование, и вот там фигурирует обычно срок в один год. Используется расчёт репутационного ущерба за счёт остановки бизнеса, публикаций в СМИ после этого, штрафов за раскрытие ПДн или банковских данных и так далее.

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

Во многих случаях слив также означает потерю конкурентного преимущества.

Как шло внедрение?


image

DLP была со старта работы системы. После подозрений на инциденты была внедрена система UAM (User Activity Monitoring). По плану она должна была внедряться чуть-чуть позже, когда система достигла бы определённого размера, но из-за ряда активностей безопасники решили ускорить этот процесс. Как оказалось, не зря.

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

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

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

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

Работа идёт со всеми потоками данных. Это почта, веб, USB-носители и так далее.

Решение мы выбрали ObserveIT. Но это решение ушло сейчас из России, поэтому сейчас производится поиск аналогов. А второе решение это StaffCop. DLP InfoWatch.

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

InfoWatch, как и любая DLP, работает с контентом. Скачивается Excel-файл на флешку? Система смотрит по ключевым словам содержание файла. В нашей практике был случай, когда недобросовестный сотрудник одной крупной промышленной компании хотел вынести важные финансовые данные просто переименовав файл и изменив расширение. Его, разумеется, поймали.

На что срабатывает DLP?


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

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

На что срабатывает UAM?


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

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

То есть безопасники видят все данные рабочей станции, даже личные?


Да. Например, если вы покупаете билет в командировку и вводите номер личной кредитки, то вы показываете его ИБ.

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

Скрины из StaffCop.

image
Лог активностей пользователя на своём рабочем месте, где мы можем понять, с какими приложениями пользователь работал, что именно было в этот момент на экране.

image
Скрин экрана пользователя в момент определённого действия.

Для примера скрины из другой UAM-системы Teramind.

image
Скрин поведенческого анализа, где видна прогнозная и ситуационная аналитика, основанная на машинном обучении, регрессионном анализе и алгоритме оценки рисков.

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

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

Как отреагировали люди?


Сотрудники никак особо. Подрядчики легко приняли новые правила игры. Но для них ничего не изменилось, то есть так они были связаны только NDA с заказчиком, так появился ещё и дополнительный способ контроля.
Подробнее..
Категории: Информационная безопасность , Управление проектами , Безопасность , Защита , Блог компании крок , Иб , Dlp , Data leak prevention , Uam , User activity monitoring , Контроль

Перевод Восемь забавных вещей, которые могут с вами произойти, если у вас нет защиты от CSRF-атак

12.04.2021 18:13:34 | Автор: admin

Восемь забавных вещей, которые могут с вами произойти, если у вас нет защиты от CSRF-атак



Введение


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


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


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


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


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


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


1. Сделать слепой произвольный запрос по любому маршруту в качестве пользователя


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


2. Сделать запрос и узнать его продолжительность


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


Однако никто серьезно не защищается от атак по времени, скажем, при поиске. Например, предположим, что у вас есть сайт службы знакомств, а злоумышленник делает запрос через браузер жертвы, скажем, Сары, по маршрутам messages/search?query=kevin%20mitchell и messages/search?query=blurghafest. Если достоверно известно, что первый запрос занимает больше времени, чем второй (причем необязательно намного), может пролиться кровь. Или, как минимум, где-то далеко произойдет неприятность и появится недовольный клиент.


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


3. Заставить пользователя выйти из системы


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


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


4. Заставить пользователя выйти из системы и снова войти


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


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


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


5. Изменить адрес электронной почты пользователя и запросить восстановление пароля


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


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


6. Превратить уязвимость Self-XSS в XSS


CSRF-атака может превратить уязвимость self-XSS, которая является мелкой проблемой, в XSS, которая является огромной проблемой.


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


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


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


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


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


7. Замести следы


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


Если пользователь не обладает по-настоящему глубоким пониманием, он никогда не узнает, откуда пришел этот CSRF-удар.


8. Распространять вредоносное ПО


Позволяет ли ваш сервис пользователям хранить файлы? Многие типы файлов, такие как .docx, pdf, jpeg и другие исторически используются для сокрытия вредоносного ПО из-за багов программ, которые их читают.


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


Заключительные замечания


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

Подробнее..
Категории: Информационная безопасность , Разработка веб-сайтов , Безопасность , Web-разработка , Web , Уязвимости , Защита , Web-программирование , Защита информации , Безопасность веб-приложений , Xss , Блог компании typeable , Csrf

Почему ваш бизнес может быть разрушен

28.04.2021 12:07:29 | Автор: admin

Привет, Хабр!

На связи снова Максим Горшков, специалист по информационной безопасности корпоративного облачного провайдера Cloud4Y. Хочу поднять вопрос о деятельности, результаты которой обычно незаметны, но крайне важны для бизнеса. Я имею в виду кибербезопасность. Будучи следователем по расследованию киберпреступлений в недавнем прошлом, я изрядно насмотрелся на компании, которые пострадали из-за недостаточно серьёзного отношения к информационной безопасности.

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

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

Для российского руководителя мотивы подобного поведения очевидны. Зачем менеджеру платить больше, если и так устраиваются на работу? Зачем нужны сотрудники, которые не приносят деньги? Если условный технический отдел и так что-то делает и вроде как всё работает.

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

Зарождение

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

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

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

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

Причём векторы атак были разные. Далеко не всегда эксплуатировались уязвимости типа EternalBlue, (CVE-2017-0144 с помощью которой широко распространялись шифровальщики WannaCry, Petiya), хотя и они тоже были. Встречался и банальный подброс запоминающих устройств со зловредной программой, получающей удаленный доступ к ПК, например, главного бухгалтера или директора.

Я буду честен, правоохранительная система оптимизирована настолько, что не может достаточно эффективно бороться с киберпреступностью. Так что можно сказать, что киберпреступления угрожают не только бизнесу, но и государству в целом.

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

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

Пережимать гайки тоже не стоит

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

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

Почему так происходит? Потому что в модели директивного управления топ-менеджеров часто не рассматривается вопрос о том, что расходы на безопасность недостаточны или уходят не в том направлении. Условно говоря, собирается совещание, где обсуждаются расходы компании. Коммерческий директор говорит, что ему нужно расширить штат продажников, директор по ИТ говорит, что нужно усилить безопасность. Генеральный директор задает им один вопрос: что получит от этого компания? Первый говорит про деньги, второй про абстрактную безопасность. И решение при распределении средств становится очевидным. Очевидным до того самого времени Ч, когда ущерб от кибератаки превысит выгоду от работы целого отдела маркетологов на несколько лет вперед.

Скажете, опять нагнетаю? В недалеком прошлом с помощью вредоносной программы, внедрённой на сервера атомной электростанции, злоумышленники смогли навредить ядерной программе Ирана. А это, на минуточку, ключевой стратегический объект целой страны. Прошло уже больше 10 лет с того момента. Сейчас злоумышленники действуют ещё хитрее, придумывают новые способы заработка.

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

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

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

Что будет дальше

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

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

Спасибо за внимание.

Что ещё интересного есть в блогеCloud4Y

Частые ошибки в настройках Nginx, из-за которых веб-сервер становится уязвимым

Пароль как крестраж: ещё один способ защитить свои учётные данные

Тим Бернерс-Ли предлагает хранить персональные данные в подах

Подготовка шаблона vApp тестовой среды VMware vCenter + ESXi

Создание группы доступности AlwaysON на основе кластера Failover

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

Подробнее..
Категории: Информационная безопасность , It-компании , Кибербезопасность , Защита , Экономия , Блог компании cloud4y , Взлом , Эффективные менеджеры

Использование и настройка локального API CrowdSec

20.05.2021 14:22:33 | Автор: admin
Если вы впервые видите наши посты, то скажем пару слов о проекте. CrowdSec это инструмент с открытым исходным кодом, который используется для обнаружения и блокировки вредоносных IP-адресов на основе локальных шаблонов поведения. Также возможно подключение бан-листов, причем как локальных, сформированных самостоятельно, так и общих, которые создаются всеми пользователями CrowdSec коллективно. Подробнее вы можете почитать об этом в наших предыдущих статьях.

В версии CrowdSec 1.x реализовал локальный API, к которому может обращаться как клиент приложения, так и пользователь через командную строку, в том числе и на удаленные машины.
Что он умеет?

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

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

Через API можно управлять решениями и сценариями, push-уведомлениями от системы администратору, настраивать оповещения и так далее. Как и должно, API единая точка входа администратора к инфраструктуре системы. В ранних версиях CrowdSec многие вещи, те же баунсеры, настраивались вручную по месту, что было не слишком удобно.

Начинаем пользоваться API


Предположим, что CrowdSec установлен и у вас есть клиент командной строки (CLI). Ваши последующий шаг аутентификация в API.

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

cscli bouncers add BouncerdeTest

После получения ключа вам надо собрать конфиг баунсера:



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

cscli machines add MachinedeTest auto



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



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

cscli lapi register -u <api_url>

После надо проверить, добавилась ли машина на локальном сервере, где у нас развернут API. Сделать это можно следующей строкой:

cscli machines validate MachinedeTest

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



Использование API с баунсерами


Теперь для соединения через API достаточно обычного HTTP-запроса. Этого достаточно для локальной работы. Если же речь идет об удаленных машинах, рекомендуем включить HTTPS.



Что касается вызовов API из баунсера, у вас есть 2 доступных метода:

Режим запроса (getDecisions)

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

Вот как вызвать API (с помощью Curl), чтобы запросить информацию о заблокированном IP:

curl -H "X-Api-Key: e73e3672427ecd8cd9a6487f7e8f4f03" http://localhost:8080/v1/decisions?ip=98.65.32.47

Как видите, мы передаем ключ API и вызываем параметр ?ip, чтобы указать IP-адрес, по которому мы хотим получить информацию.

Возвращаемый ответ мы получим в формате JSON, например:

[{"duration":"2h25m47.212560128s","id":1023,"origin":"cscli","scenario":"manual 'ban' from '939972095cf1459c8b22cc608eff85daEb4yoi2wiTD7Y3fA'","scope":"Ip","type":"ban","value":"1.2.3.4"}]

Вы также можете использовать параметр ?range, чтобы указать диапазон сети, или, если хотите, использовать пару параметров scope+value для запроса информации о конкретном имени пользователя, идентификаторе сеанса и так далее.

curl -H "X-Api-Key: e73e3672427ecd8cd9a6487f7e8f4f03" http://localhost:8080/v1/decisions?scope=username&value=korben

Есть еще один вариант. Это

Потоковый режим (getDecisionsStream)

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

Когда баунсер запущен, вы можете получить активные решения, а также только что удаленные, вызвав API с параметром ?Startup true, например:

curl -s -H "X-Api-Key: e73e3672427ecd8cd9a6487f7e8f4f03" http://localhost:8080/v1/decisions/stream?startup=true

Установив для параметра ?startup значение false вы будете получать только новые решения, полученные после запуска баунсера.

{  "deleted": null,  "new": [    {      "duration": "3h59m57.641708614s",      "id": 2410,      "origin": "cscli",      "scenario": "manual 'ban' from '939972095cf1459c8b22cc608eff85daEb4yoi2wiTD7Y3fA'",      "scope": "Ip",      "type": "ban",      "value": "3.3.3.4"    }  ]}

Если решение не было добавлено, в ответ вернется null:

{  "deleted": null,  "new": null}

Используйте API через Watcher (cscli или агент CrowdSec)


Как упоминалось во введении, вам нужно будет предоставить API идентификатор компьютера и пароль. Использование определенных функций API (POST/DELETE) или (GET) в основном осуществляется через интерфейс командной строки или агент CrowdSec, но ничто не мешает вам работать с ним напрямую.



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

curl -X DELETE "https://localhost:8080/v1/decisions?ip=98.65.32.47" -H "accept: application/json"

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

Для тех, кто хочет начать работу на более глубоком уровне с исходниками, в репозитории CrowdSec на Github есть код, написанный на Go, который показывает, как подключиться и использовать API.



Все методы API доступны здесь.

Итого


Как видите, локальный API CrowdSec довольно легко изучить и начать использовать в связке с баунсерами. Последние написанны на Go и адаптируемы к вашим конкретным потребностям. Готовые баунсеры можно скачать тут. Также нами написаны специальные баунсеры для работы с Nginx, WordPress, HAProxy, iptables, nftables или даже с облачными межсетевыми экранами Amazon (AWS) и Google (Network FW и Cloud Armor). Их исходники также можно найти на Github. Еще у нас есть баунсеры на LUA и PHP.

И, конечно же, всю дополнительную информацию, исходники, полезные ссылки и еще не опубликованные на Хабре мануалы вы можете найти на официальном сайте CrowdSec.
Подробнее..
Категории: Информационная безопасность , Системное администрирование , Сетевые технологии , Api , Защита , Crowdsec , Блог компании crowdsec , Баунсеры , Фильтрация ip , Работа с api , Защита серверов , Защита виртуальных машин

Как начать думать про клиента на этапе разработки, а не адаптировать продукт после

28.05.2021 14:21:34 | Автор: admin
image
На рисунке прототип продукта для Сбербанк Онлайн.

Есть разные методики для исследования и улучшения клиентского опыта (Customer experience, CX). Сегодня расскажем про одну из них дизайн-мышление, и поможет в этом Ирина Баженова эксперт по исследованию клиентского опыта в Сбере.

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

В 2016 году в Сбере началась Agile-трансформация. Тогда же стали активно внедрять методологию дизайн-мышления для проектирования клиентского опыта. Первые годы почти все проекты были направлены не на исследование новых продуктов, а на исправление каких-то особенностей старых. Ну, знаете, типа той, что где карту открывали, в то отделение и идите.
Так что проверено на практике: чем раньше провести исследование и поговорить с клиентом, тем меньше затрат будет дальше на стадии разработки и запуска продукта. И, собственно, именно поэтому есть смысл встраивать процессы по изучению клиентского опыта в саму разработку. Если же задуматься о клиенте, только когда уже есть прототип, то это уже неэффективно потраченные ресурсы.

Немного про методику


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

image

Визуализируют методику так:

image

Разберём пример


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

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

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

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

Шаг 1. Эмпатия


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

  • имущество застраховано / не застраховано;
  • был страховой случай / не было страхового случая и прочее.

В результате получили первые гипотезы.

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

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

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

Шаг 2. Анализ и синтез


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

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

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

Полина боится затопить соседей больше, чем саму себя.

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

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

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

И эта связка удивление + инсайт + потребность дала возможность команде сформулировать фичу.

Шаг 3. Генерация идей


Итак, описанным выше способом мы определили 10 ключевых потребностей клиентов, сгенерили примерно 180 идей и сделали две итерации прототипирования.

Шаг 4. Прототипирование


Создали прототип, то есть взяли листы бумаги А4, разорвали их пополам. Далее команда участников дизайн-мышления объединилась в подгруппы, чтобы рисовать интерфейс экраны приложения с кнопками, как будто клиент хотел оформить Защиту дома.

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

Кстати, в условиях удалёнки все эти этапы также возможно реализовать на интерактивной доске в Miro.com.

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

Шаг 5. Тестирование


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

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

Что получилось?


image
Сбербанк Онлайн Каталог Защита дома.

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

image

После запуска этого продукта в таком виде в Сбербанк Онлайн количество договоров увеличилось на 41 % в июле 2020 года по сравнению с маем 2020-го.

Почему важно проводить исследования в кросс-функциональных командах?


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

Как правильно выбрать время и формат для CX-исследования?


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

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

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

Спасибо Ирине Баженовой, нейрокоучу, лидеру UX-исследований блока Корпоративно-инвестиционный бизнес в Сбере, сертифицированному тренеру и фасилитатору по дизайн-мышлению за интересную историю, материалы и помощь в подготовке статьи.
Подробнее..
Категории: Управление проектами , Разработка , Agile , Управление продуктом , Защита , Cx , Блог компании сбер , Исследование продукта , Жизненный цикл продукта , Дизайн-мышление , Sbergile

Чтобы током не убило. Всё про УЗО

27.12.2020 12:16:52 | Автор: admin

Попробуем снова объять необъятное одним постом? На этот раз рассказ будет про УЗО.

У этого поста есть видеоверсия, для тех, кто любит слушать и смотреть:

Сейчас, в 21 веке, электричество есть практически в каждом доме. И почти каждый гражданин знает, что электричество может убить. Новость о том, что где-то кого-то убило током для нас уже обыденная, и в СМИ об этом пишут только если случай особенный - или убило известную личность, или раздолбайство совсем уж вопиющее. Но в конце XIX - начале XX века каждая смерть от удара током была в центре внимания: электричество было в диковинку. Вот немного заметок, которые попались мне на глаза:

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

Выяснилось, что случаев смерти, когда человек умер от общения с напряжениями менее 50В почти нет. Низкое напряжение (с кучей оговорок) вполне себе безопасно. Кто лизал крону в детстве для определения заряда?) Использование низкого напряжения (12В, 24В, 36В и т.д.) хоть и дает практически полную безопасность, например в бассейне, для повсеместного использования не подходит. Если бы мы жили в альтернативной вселенной, где в домах вместо 230В всего 12В, то чайник бы кушал не 16А тока, а почти 300А, и подключался бы в розетку толстенным кабелем. А все потому что при снижении напряжения придется повышать ток, чтобы мощность прибора оставалась прежней. А большой ток требует толстых кабелей.

Второе важное наблюдение. Ток течет в замкнутой цепи, если Земля часть этой цепи - то человек всегда в опасности. А вот если человека подключить к разным цепям, изолированным друг от друга, например если коснуться одной рукой одного изолированного от земли генератора, а второй - другого изолированного генератора - то ничего не произойдет. Цепь не замкнута - ток не течет.Так появилась гальваническая развязка и развязывающие трансформаторы. Я не настолько стар, чтобы видеть это живьём, но встречал упоминания, о том что в домах устанавливали развязывающий трансформатор с розеткой в санузле, с подписью "для электробритвы". Электробритвой на 220В включенной в эту розетку можно было безопасно пользоваться, касание до проводника под напряжением, даже стоя в заземленной ванной, не могло убить. Правда маленький трансформатор мог потянуть только несколько десятков ватт мощности нагрузки, включение в такую розетку фена или обогревателя просто бы его сожгло. По этому в быту способ не прижился, у вас же нет отдельной комнаты под трансформатор гальванической развязки?)

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

Оказалось, что убивает не напряжение само по себе, а протекающий через тело ток. При токах менее 0,5 мА (светло-зеленая область) человек ничего не чувствует. При токах 0,5-20 мА (темно-зеленая область) ток уже неприятно щиплет, кусает. При токах 20-100 мА (желтая область) уже конкретно трясет, сводит мышцы (руку не отдернешь) и причиняет боль. При токах более 100 мА уже некоторые могут умереть. Из графика можно понять откуда взялась величина 30 мА (зеленая линия) - при токах меньше человек вряд ли умрет и может сам принять меры, если чувствует, что его бьет током. А вот при токах больше - нужно срочно спасать, иначе помрет.

Защита все-таки нужна.

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

Дифференциальный ток - это разница в токах меж двух проводников, например меж фазным, уходящим в нагрузку и нулевым, возвращающимся из нагрузки. Появление ощутимого дифференциального тока в цепи чаще всего ненормально, и лучше отключить цепь, вдруг ток утекает в землю через человека? Это как сравнивать расход теплоносителя в батареи и из батареи отопления. Если в батареи уходит 100 л/мин и возвращается 100 л/мин то система герметична. Если в батареи подается 100 л/мин, а возвращается по какой то причине только 98 л/мин, то 2 литра куда-то вытекает!

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

Поставим себя на место инженеров начала 20 века и попробуем изобрести устройство обнаружения дифференциального тока. Нам нужно обнаружить появление утечки величиной 30 мА, поскольку при меньших утечках, даже если она проходит через человека, особой опасности для жизни нет.

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

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

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

Гениальное в своей простоте и надежности устройство. Правда дешевым оно не получилось - механика все-равно оказалась нежной и капризной, шутка ли - обнаружить 30 мА разницу при номинальном токе 16А, это все равно, что расслышать писк мыши на фоне грохота поезда. Вот так выглядит УЗО электромеханическое:

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

А теперь внимание, важный момент, что будет при коротком замыкании в нагрузке? Ничего! Так как условия для срабатывания нет - разницы токов на входе в УЗО и на выходе из УЗО нет. Провода накалятся до красна, изоляция стечет на пол, а УЗО не отключится, поскольку не имеет защиты от сверхтока. Поэтому УЗО без встроенной защиты от сверхтока ВСЕГДА применяется в паре с автоматическим выключателем или с плавким предохранителем. Путем скрещивания УЗО и автоматических выключателей производители вывели гибрид - АВДТ (автоматический выключатель дифференциального тока), который чаще на жаргоне называют диффавтоматом, такое устройство самодостаточно и наличия дополнительного автоматического выключателя не требует.

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

Для обеспечения селективности, при последовательном соединении УЗО, создали специальные селективные варианты, часто с обозначением S или G в названии. Они имеют встроенную задержку на несколько десятков-сотен миллисекунд. Так, если на вводе в дом стоит селективное УЗО, а на этажном щитке неселективное, то при замыкании напряжения на корпус стиральной машины, сначала сработает неселективное УЗО на этаже, пока селективное дает задержку. Если по окончании задержки дифференциальный ток не исчез - сработает селективное УЗО. Про селективность я писал в посте про предохранители (ССЛКА). Селективность не зависит от номинального порогового дифференциального тока, тоесть при пробое на корпус сработают сразу и УЗО на 30 мА и УЗО на 100 мА, поэтому и пришлось возиться с задержкой.

А теперь, когда стало понятно КАК работает УЗО самое время сказать про заземление, будет ли работать УЗО, если в розетках нет заземляющего контакта? Будет! С той лишь разницей, что если у стиральной машинки будет пробой на корпус в сети с заземлением - УЗО отключится сразу, так как дифференциальный ток будет огромным (уйдет с корпуса в заземляющий проводник). А вот если в сети нет заземления, стиральная машинка будет, как партизан в кустах, стоять с напряжением 230В на корпусе, и УЗО отключится только когда ток будет протекать через человека. Тоесть наличие заземления повышает безопасность, но не является обязательным условием для функционирования УЗО.

Возвращаемся в реальный мир. Почему могут быть ложные срабатывания.

Одна из причин непринятия УЗО электриками старой закалки, являются ложные срабатывания. И ложные срабатывания (при условии, что устройство исправно) могут быть только по одной причине - есть утечка, и она ощутима. А вот причины появления утечек разнообразные:

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

  2. Штатная утечка в оборудовании. Даже в исправном оборудовании есть некоторая величина утечки, причем при переменном токе не нужен непосредственный контакт, достаточно просто, что один из проводников делал длинную петлю вдоль корпуса. Образовавшейся емкостной связи достаточно для протекания небольшого тока. Специальным прибором можно измерить величину фактической утечки в линии со всеми подключенными устройствами. Если прямое измерение не доступно - можно воспользоваться эмпирическим правилом (7.1.83 ПУЭ) - считать что на каждый 1 А потребления тока прибором будет 0,4 мА утечки, а также 10 мкА утечки на каждый метр длины фазного проводника. (Цифры сииильно усредненные, как средняя температура по больнице, но хоть что-то) Желательно, чтобы сумма всех утечек в цепи при штатной работе не превышала 1/3 номинальной величины отключающего дифференциального тока. Ну и как вишенка на торте - если на УЗО написано, что отключающий дифференциальный ток 30 мА, это значит что при 30 мА оно точно отключится. А точно не будет отключаться при половине этого тока - 15 мА. А вот при дифференциальном токе меж этих значений - как повезет. Если у вас стоит УЗО на 30 мА, и в розетки воткнута куча устройств, что суммарные утечки при нормальной эксплуатации составляют 20 мА, то создается ситуация, когда УЗО может самопроизвольно отключиться без видимых причин.

  3. Ошибка монтажа, и где-то (например в одном из подрозетников) присутствует соединение рабочего нейтрального проводника N и заземляющего PE, или они перепутаны.

Противопожарные УЗО? Они все противопожарные!

Если открыть каталог производителей, можно заметить, что УЗО выпускаются на разные дифференциальные токи. Если с причиной выбора тока в 30 мА все понятно, с 10 мА тоже в принципе можно догадаться (еще более чувствительные устройства для более чуткой защиты), то зачем нужны устройства с током 100 мА и даже 300 мА? Человек же при таких токах умрет!

Такие УЗО часто называют "противопожарными", так как в силу большого дифференциального тока защиту человека от поражения электрическим током они обеспечивают слабо, а вот функцию защиты при повреждении изоляции все еще выполняют. Если изоляция будет нарушена и при контакте с другим проводником загорится электрическая дуга, то начнется обугливание изоляции и выделение тепла, что может поджечь горючие материалы вокруг. Если вам "повезет", и ток в дуге будет небольшим, то автоматический выключатель не сработает. А вот выделение тепла и температура могут быть достаточными для пожара. Конечно, потом огонь нарушит изоляцию, произойдет короткое замыкание и автоматический выключатель сработает, только огонь это уже не погасит.

Да будет срач!

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

Но так как большинство читателей ждет от меня конкретного ответа - скажу, что это не важно. Есть требования стандартов, есть требуемые характеристики, и конкурентная цена в конце концов. Поэтому производитель дает ровно то, что от него требуют, а вот как получено желаемое - не так важно. А если производитель рукожоп, то отсутствие электроники автоматически не означает, что изделие выйдет годным. Кроме того, УЗО типа B без добавления электроники изготовить не получилось ни у одного производителя.

Для контроля исправности УЗО на передней панели есть кнопочка "тест", которая замыкая резистором цепь, имитирует появление дифференциального тока. Если УЗО при нажатии на кнопку тест отключилось - то оно исправно. Проверку исправности УЗО производители рекомендуют производить ежемесячно (какие оптимисты!), ну или я реалистично говорю о тесте раз в пол года.

Когда нельзя никому доверять.

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

В виде персонального УЗО для устройства в вилке или в виде коробочки на шнуре. Если покупатель подключит бойлер пластиковыми трубами, корпус не заземлит, то при потере герметичности ТЭНа электричество по воде в трубах и пойдет через человека в заземленную ванну. Такое УЗО защищает конкретно одно устройство, и в некоторых странах существую нормативы, обязывающие добавлять УЗО на некоторые типы устройств. Как вы можете заметить, устройство также содержит кнопочку "тест" для проверки работоспособности защиты.

УЗО или диффавтомат? (ВДТ или АВДТ?)

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

  1. Оно лишает гибкости проектировщиков, например поставить одно УЗО и несколько автоматов или наоборот, несколько УЗО и один автомат.

  2. Оно усложняет поиск неисправности, так как обычно отсутствует индикация и сложно понять, почему оно отключилось (варианты: сработал тепловой расцепитель, электромагнитный расцепитель или электромагнит от дифференциального тока)

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

На мой личный взгляд применение АВДТ оправдано только при апгрейде электрощитка, когда места внутри нет, а дифф. защиту хочется. Тогда можно вынуть автоматические выключатели шириной один модуль и воткнуть АВДТ шириной один модуль, и перекоммутировать провода. Щиток в таком случае расширять не придется. В остальных случаях, по моему мнению, предпочтительнее комбинация УЗО+автоматический выключатель.

Я умер. Почему УЗО не спасло?

УЗО не панацея, но лучше пока ничего не придумали. Если взяться одной рукой за фазный проводник, а второй рукой за нулевой, то для электросети вы будете лишь очередным нагревателем, дифференциальный ток не появится и УЗО не сработает. Также если сунуть палец в патрон лампы - ток потечет через палец, но утечки в землю не будет, УЗО не отключится. Поэтому даже наличие такой защиты не означает, что можно терять бдительность и осторожность. Опытный электрик даже жену не берет одновременно за две груди :)

Резюме

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

  2. УЗО работает вне зависимости от наличия заземления, с той лишь разницей, что без заземления, при пробое на корпус УЗО отключится только когда ток с корпуса сможет утечь в землю через вас.

  3. УЗО не панацея, и можно убиться, взяв в руки провода фазы и ноля. Но вариантов защиты лучше УЗО все равно не придумали.

  4. Электромеханическое или электронное УЗО - не важно. А вот регулярно проверять исправность нажатием кнопки "тест" важно. Использовать реле контроля напряжения тоже очень желательно.

  5. В реальном мире у исправной электропроводки и устройств есть ток утечки, который может вызвать ложное срабатывание УЗО. Если УЗО срабатывает без видимых причин - разбирайтесь с токами утечки.

Расширить и углубить.

Если изложенной в посте информации вам мало (мое уважение!), то вот что стоит почитать:

В.К. Монаков УЗО. Теория и практика Москва, Издательство "Энергосервис", 2007 г.

Книжка шикарная в своей полноте и довольно простом языке изложения. Автор - директор компании АСТРО-УЗО (uzo.ru) - отечественного разработчика и производителя УЗО.

http://www.uzo.ru/books/normative-document/

Выжимка нормативных документов имеющих отношение к УЗО. Там же есть еще один документ заслуживающий внимания (http://www.uzo.ru/books/uzo.pdf)

https://y-kharechko.livejournal.com/

ЖЖ Юрия Харечко, специалиста, автора книг, знатока стандартов. Как человек - весьма неприятный, но в техническом плане мне упрекнуть его не в чем. Если хочется разобраться в хитросплетениях и взаимопротиворечиях стандартов - к нему. И наверняка он увидев мой пост скажет, что я дилетант и не компетентен, поскольку термин УЗО отсутствует в стандартах, и устройство правильно называть....

P.S. Оказывается за время моего отсутствия на хабрахабре и покорения пикабу изменились правила, относительно репостов. Прибыл по приглашению @SLY_G. Если читателям хабрахабра нравится мой контент на околотехническую тематику (все-таки он больше подходил гиктаймс), то я готов приносить сюда некоторые другие мои посты, заслуживающие внимания) Например про предохранители и автоматические выключатели, да и в целом про технику.

Подробнее..
Категории: Научно-популярное , Электроника для начинающих , Защита , Электричество , Узо , Техника безопасности

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru