Новости

В виду последних новостей о полном уходе Microsoft из РФ, а также прекращения ими обновлений на территории РФ, многие предприятия задумались о безопасности и стабильности своей инфраструктуры ИТ, так как без регулярных обновлений операционная система с течением времени становится сильнее подвержена вредоносному ПО. Также, нельзя забывать о потенциальной, хоть и маловероятной, ситуации, когда корпорация Microsoft распространит на все сервера или рабочие станции, расположенные на территории РФ, пакет обновления, который ограничит использование целевой операционной системы, её части или ПО, или в крайне неблагоприятном варианте и вовсе превратит сервер или пользовательский компьютер «в тыкву».
Такая потенциальная угроза несёт в себе огромные риски для предприятия, вплоть до временной полной остановки.
А так как любая операционная система — это прежде всего фундамент и экосистема программного обеспечения и пакетов, разработанных для неё, то снисходительно смотреть на серьёзность сложившейся ситуации — более чем опрометчиво.
Тем предприятиям, у которых в бизнес-процессы вплетены такие продукты, как Autocad, Photoshop, Illustrator, Компас, ГрандСмета и т.д., вариантов перейти на аналоги под Linux на данный момент практически нет, кроме как «костылить» прослойку в виде wine.
Однако фирмам работающим в сфере розничных и оптовых продаж, где основными являются 1С, MS SQL, MS Office, браузеры, криптопровайдеры и плагины для браузеров, существуют решения для операционных систем Linux.
Для этого всего лишь (сарказм) нужно инсталлировать на сервера ОС Linux, и накатить на них сервер 1с, сервер СУБД, например, PostgreSQL, и дело в шляпе. Однако, по факту, полная миграция — дело затратное, кропотливое и требует адаптации со стороны пользователей (и, как правило, тут всегда встречается мощное сопротивление).
Но других вариантов не осталось.
Если вашему предприятию необходимо переехать на Linux и открытое ПО, обращайтесь. Мы будем рады помочь.

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

1. Общие аспекты безопасности Ipv6

1.1. Является ли IPv6 более безопасным, чем IPv4?

Нет! И данный вопрос по сути некорректен, поскольку он может касаться, по крайней мере, двух разных вопросов:

• Являются ли протоколы IPv6 (по спецификациям) более безопасными, чем их аналоги IPv4, или,

• Являются ли развертывания IPv6 более безопасными, чем их аналоги IPv4

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

• Зрелость спецификаций протокола
• Срок реализации
• Опыт работы специалиста с протоколами
• Поддержка и инструментарий

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

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

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

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

1.2. Моя сеть только для IPv4. Нужно ли беспокоиться о безопасности IPv6?
Скорее всего, Ваша сеть имеет двойной стек, а не только IPv4. Следовательно, независимо от того, имеет ли ваша сеть глобальное подключение IPv6 или нет, большинство узлов в Вашей сети поддерживают IPv6. А значит эти узлы уже могут использовать IPv6 для локального трафика. И, мало того, они могут непреднамеренно использовать IPv6 для нелокального трафика, если злоумышленник сломает защиту (если она есть) Вашего пограничного узла и разрешит глобальное подключение IPv6 к Вашей сети. IPv6, также, может привести к утечке трафика VPN, если используются реализации VPN без соответствующей поддержки IPv6. Можете изучить [RFC7123] и [RFC7359] для получения дополнительной информации.

1.3. Стоит ли ожидать увеличения использования IPsec с IPv6?
Нет. В прежних спецификациях IPv6 [RFC4294] требовалось, чтобы все узлы включали поддержку IPsec. Это вместе с преполагаемой способностью использовать собственный IPsec в сетях IPv6 (которые обычно ограничиваются в сетях IPv4 с помощью NAT), возможно, привело к ожиданию того, что использование IPsec станет широко распространенным.

Тем не мение,

• В конечном итоге IETF стандартизировал туннелирование IPsec через UDP (см. [RFC3948]), устраняя барьер развертывания IPsec в сетях IPv4.

• Требование поддержки IPsec не подразумевает необходимость его фактического использования. И, в любом случае, такое требование было формально снято в последующих редакциях спецификаций IPv6 (см. [RFC6434]). (Кстати, до сих пор, в Интренете публикуются, а по существу копируют друг друга, статьи, в которых говорится, что IPSec — это обязательный атрибут IPv6).

• IPsec использует заголовки расширений, которые обычно приводят к отлупу пакетов при использовании в «диком» Интернете (см. [RFC7872]).

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

2.Оценка безопасности IPv6
2.1. Какие инструменты оценки безопасности я могу использовать для оценки моих сетей и устройств?
Есть, как минимум, три бесплатных набора инструментов с открытым исходным кодом для IPv6:

• SI6 Networks’ IPv6 Toolkit [SI6-Toolkit]
• The Hacker’s Choice IPv6 Attack Toolkit [THC-IPv6]
• Chiron [Chiron]

2.2. Можно ли заняться сканированием сетей IPv6?
Это зависимо. Сканирование адресов IPv4 обычно выполняется методом «brute force», поскольку пространство поиска довольно мало (256 адресов в /24, 65536 адресов в /16 и т. д.). С другой стороны, стандартные подсети IPv6 — это /64, что приводит к тому, что адресное пространство становится настолько большим, что становится невозможным сканирование с помощью брутфорса. Однако существует эмпирическое доказательство того, что адреса узлов IPv6 могут следовать определенным шаблонам:

• Узлы инфраструктуры (маршрутизаторы, серверы и т. д.) обычно используют предсказуемые адреса, такие как «младшие байты» (2001: db8 :: 1, 2001: db8 :: 2 и т. д.)
• Клиентские узлы (ноутбуки, рабочие станции и т. д.) обычно используют случайные адреса.

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

2.3. Как мне провести разведку сети IPv6?
Если целью является локальная подсеть, следующие методы оказались эффективными:

• Многоадресные (мультикаст) тесты (эхо-сигнал ICMPv6 и специально созданные тестовые пакеты, которые вызывают сообщения об ошибках ICMPv6).
• Многоадресные DNS (mDNS) запросы.

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

• Сканирование адресов на основе шаблонов
• DNS зоны передачи
• Обратные сопоставления DNS
• Структура прозрачности сертификата
• Поисковые системы

Вы можете найти больше информации об этих и других методах в [RFC7707] и [IPV6-RECON].

2.4. Можно ли выполнять атаки по отслеживанию хоста (host-tracking) в IPv6?
Это зависимо. Отслеживание хоста относится к корреляции сетевой активности по мере перемещения хостов по сетям. Традиционные адреса SLAAC требовали, чтобы узлы встраивали свои MAC-адреса в идентификатор интерфейса IPv6, что очень упрощало отслеживание хоста IPv6. Временные адреса (см. [RFC4941]) смягчают часть проблемы, предоставляя рандомизированные адреса, которые могут использоваться для (клиент-подобных) исходящих соединений, в то время, как адреса со стабильной конфиденциальностью ([RFC7217]) заменяют традиционные адреса SLAAC, так что проблема устранена (см. [RFC8064]).

Со временем реализации продвигались к реализации как временных (RFC4941), так и адресов со стабильной конфиденциальностью или stable-privacy addresses (RFC7217). Однако вы должны проверить поддержку этих стандартов в вашей операционной системе. Пожалуйста, ознакомьтесь с [RFC7721].

2.5. Имеет ли смысл использовать непредсказуемые адреса (например, RFC7217) для серверов?
Существует неявный компромисс между легко запоминаемыми предсказуемыми адресами и трудно сканируемыми непредсказуемыми адресами. Обычно администратор должен проанализировать связанные компромиссы и удобство для каждого сетевого сценария.

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

2.6. Как я могу ограничить исследование (разведку) моей сети со стороны злоумышленника на основе обратного сопоставления DNS?
Один из вариантов — настроить обратное сопоставление DNS только для систем, которым это требуется — в основном, для агентов почтовой пересылки (MTA). Другой вариант — если ваше программное обеспечение DNS поддерживает это — настроить обратные сопоставления с подстановочными знаками, чтобы каждое возможное доменное имя для обратных сопоставлений содержало действительную запись PTR.

3.Безопасность первого прыжка (First-Hop)
3.1. Стоит ли беспокоиться о разрешении адресов и атаках с автоматической настройкой?
Эти атаки должны вызывать столько же беспокойства, что и атаки ARP и DHCP из мира IPv4, то есть атаки Neighbor Discovery и автоматической настройки являются IPv6-эквивалентами атак на основе ARP и DHCP из мира IPv4. Если атаки ARP / DHCP являются проблемой для вашей сети IPv4, то их аналоги IPv6 также должны быть проблемой для ваших сетей IPv6.

Типичные меры защиты от атак Neighbor Discovery и автоматической настройки аналогичны существующим мерам защиты для этих атак в версии IPv4. Например, RA-Guard [RFC6104] [RFC6105] и DHCPv6-Shield / DHCPv6-Guard [RFC7610] являются IPv6-эквивалентом DHCP-snooping.

3.2. Каковы различия между SLAAC и DHCPv6 с точки зрения регистрации адресов?
Когда DHCPv6 используется для настройки адреса, сервер DHCPv6 обычно ведет журнал аренды адресов IPv6. Это означает, что в случае, если хост скомпрометирован (например, вредоносным ПО), и такое поведение обнаруживается, достаточно просто сопоставить вредоносную активность с зараженным узлом.

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

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

3.3. Эффективны ли RA-Guard и DHCPv6-Guard / Shield для защиты от атак с автоматической настройкой?
Многие реализации этих механизмов можно легко обойти с помощью заголовков расширения IPv6 (см. [RFC7113]. В некоторых случаях угрозы могут быть уменьшены путем отбрасывания пакетов, которые содержат «неопределенный транспорт» (на языке Cisco).

Пожалуйста, ознакомьтесь с [SI6-RA6] для получения информации о том, как дать оценку вашей реализации RA-Guard, и [CISCO-FHS] для получения подробной информации о том, как избежать угроз внедрением Cisco RA-Guard.

3.4. Следует ли мне рассмотреть возможность развертывания Secure Neighbor Discovery (SEND) в моей сети?
Нет. На момент написания этой статьи практически нет поддержки SEND ни в каких популярных операционных системах. Таким образом, независимо от других соображений, в настоящее время невозможно развернуть SEND.

3.5. Что такое атаки по исчерпанию кэша соседей (NCE) и как их можно смягчить?
Атаки NCE направлены на создание произвольно большого количества записей в кеше, чтобы больше не было возможности создавать новые валидные записи и, следовательно, приводить к отказу в обслуживании (DoS). NCE также может быть побочным эффектом сканирования адресов, когда маршрутизатор создает одну запись для каждого из целевых адресов, что в конечном итоге приводит к исчерпанию Neighbor Cache. В зависимости от каждой конкретной реализации NCE может привести к тому, что целевое устройство перестанет отвечать на запросы, произойдет сбой или перегрузка.

Одной из мер, основанных на реализации, является ограничение количества записей в Neighbor Cache в состоянии «INCOMPLETE». С другой стороны, оперативное смягчение для атак NCE на узлы, соединенные двухточечными ссылками, заключается в принудительном введении искусственного ограничения на максимальное количество записей в кэше соседей путем использования длинных префиксов (например, /127) [RFC6164].

Пожалуйста, ознакомьтесь с [RFC6583] и [ND-INDEF] для получения дополнительной информации.

4.Межсетевые экраны и архитектуры безопасности
4.1. Вызвает ли IPv6 переход от парадигмы безопасности, ориентированной на сеть, к парадигме безопасности, ориентированной на хост?
Нет, хотя вопрос довольно двоякий. Парадигма безопасности сетей IPv4 на самом деле не «ориентирована на сеть»: например, брандмауэры на основе хоста являются обычным явлением и обычно используются вместе с сетевыми брандмауэрами. Сети IPv6, скорее всего, будут следовать той же гибридной парадигме.

4.2. Будут ли все мои системы доступны в общедоступном Интернете IPv6, если я разверну IPv6?
Не обязательно. Хотя практически все сети IPv6, скорее всего, будут использовать глобальное адресное пространство, это не обязательно означает глобальную достижимость. Например, межсетевые экраны IPv6 могут быть развернуты в той же точке топологии сети, где сети IPv4 в настоящее время используют устройство NAT. Такой брандмауэр IPv6 может применять политику фильтрации «разрешать только исходящую связь», что приводит к тому же воздействию на хост, что и в сетях IPv4.

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

4.3. В мире IPv4 я обычно помещаю в черный список адреса IPv4 в ответ на злонамеренную деятельность. Какую гранулярность я должен использовать при внесении в черный список адресов IPv6?
Хосты IPv6 обычно могут настраивать любое произвольное количество адресов IPv6 в своей локальной подсети /64. В случае злонамеренной активности вы должны внести в черный список как минимум всю подсеть /64, от адреса хоста которой вы обнаружили вредоносную активность.

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

4.4. Мои системы/сети блокируют фрагменты IPv6 по соображениям безопасности. Это безопасная практика?
Это зависит. Удаление фрагментов IPv6 безопасно только при соблюдении двух условий:

• Вы используете только протоколы, которые могут избежать фрагментации — например, TCP с обнаружением Path-MTU
• Вы также блокируете сообщения об ошибках ICMPv6 «Packet Too Big» (PTB), в которых объявляются значения MTU размером менее 1280 байт.

Протоколы на основе UDP могут опираться на фрагментацию, и, таким образом, обычно не рекомендуется блокировать фрагментированный трафик, когда такие протоколы используются. Другие протоколы, такие как TCP, могут полностью избегать использования фрагментации посредством таких механизмов, как обнаружение Path-MTU (см. [RFC1981]).

Сообщения об ошибках «Packet Too Big» ICMPv6 могут инициировать использование фрагментации, когда они объявляют MTU размером менее 1280 байтов. Поэтому, если фрагменты IPv6 отброшены, но сообщения об ошибках ICMPv6 Packet Too Big, объявляющие MTU, меньший, чем 1280 байт, не отброшены, злоумышленник может использовать такие сообщения об ошибках ICMPv6, чтобы вызвать фрагментацию, так что результирующие фрагменты будут отброшены, что приведет к DoS.

Генерация фрагментов IPv6 в ответ на сообщения PTB ICMPv6 устарела в пересмотренной спецификации IPv6 [RFC8200], и, таким образом, в конечном итоге все реализации устранят эту функцию и связанную с ней уязвимость. Однако вы можете использовать устаревшую реализацию, которая по-прежнему реализует уязвимое поведение. Пожалуйста, к [RFC8021] для более подробной информации.

Примечание: вышеупомянутое смягчение подразумевает возможность фильтрации сообщений об ошибках PTB ICMPv6 на основе их поля «MTU».

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

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

[IPV6-EHS-F] содержит рекомендации по фильтрации пакетов IPv6, содержащих заголовки расширения на транзитных маршрутизаторах. Кроме того, он содержит оценку безопасности всех стандартизированных заголовков и опций расширения IPv6, а также анализ любых потенциальных проблем взаимодействия, возникающих в результате фильтрации таких пакетов.

4.6. Как я должен оценивать свои сети и устройства с точки зрения использования заголовков расширений, чтобы применить меры безопасности?
Большинство инструментариев безопасности IPv6 предоставляют поддержку для создания атакующих пакетов с произвольными заголовками расширения IPv6. Например, [SI6-RA6] объясняет использование заголовков расширения с пакетами объявления маршрутизатора.

4.7. Я использую сеть с двумя стеками. Какие соображения я должен иметь для политики фильтрации пакетов?
В общем, политики безопасности для протоколов IPv6 должны совпадать с политиками протоколов IPv4. К сожалению, многие сети настроены не так в этом отношении. Пожалуйста, смотрите [IPV6-POL] для дальнейшего изучения.

4.8. В моих системах используются как временные (RFC4941), так и стабильные (RFC7217) адреса. Как мне реализовать брандмауэр IPv6?
Разрешить исходящие соединения с любого адреса, но входящие соединения только со статическими (например, [RFC7217]) адресами. Таким образом, адреса, которые становятся доступными (таких как просмотр веб-страниц), не могут быть использованы внешними системами для подключения назад или сканирования адресов к вашим внутренним узлам.

4.9. Как временные адреса могут влиять на мои ACL?
Временные адреса, как следует из их названия, меняются со временем. В результате списки ACL, предназначенные для узлов, которые используют временные адреса, обычно не будут работать, если они указаны как один адрес IPv6 или группа адресов.

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

• Укажите ACL для каждого префикса (например, /64)
• Отключите временные адреса на необходимых узлах
• Примените ACL на статических адресах и настройте узлы таким образом, чтобы статические адреса были предпочтительнее временных адресов для доступа к услуге/приложению, описанному в ACL.

5. Ресурсы
5.1. Существуют ли какие-либо правила безопасности для IPv6?
[OPSEC-V6] содержит общие соображения по эксплуатационной безопасности IPv6, тогда как [RFC7381] содержит рекомендации по развертыванию на предприятии.

5.2. Какие форумы я могу использовать для обсуждения безопасности IPv6?
Следующие списки рассылки могут использоваться для обсуждения вопросов безопасности IPv6:

• IPv6 Hackers [IPV6-HACKERS]
• IPv6 Operators Forum [IPV6-OPS]
• IETF OPSEC WG [OPSEC-WG]
• IETF V6OPS WG [V6OPS-WG]

Кроме того, большинство региональных интернет-реестров (RIR) используют списки рассылки, которые фокусируются на IPv6 и / или сетевой безопасности.