Защита сети по сценарию (часть 1) — программная защита хостов Windows от сетевых атак

Введение

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

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

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

Человек посередине

В качестве примера того, как вы можете создать свои собственные бесплатные инструменты безопасности для борьбы с неприятной ошибкой сетевой безопасности, мы рассмотрим так называемую атаку отравления кэша ARP «Человек посередине». Отравление кэша ARP — одна из старейших уязвимостей в локальных сетях Ethernet, которая восходит к самым истокам протокола почти 30 лет назад. Это обсуждалось во многих местах, в том числе в отличной серии статей Криса Сандерса на дочернем сайте этой публикации WindowsSecurity.com.

Напоминаем, что все Ethernet-устройства поддерживают таблицу сопоставления логического (IP-адреса) и физического (аппаратного) адреса, которая называется ARP-кэшем. Это сопоставление настолько важно для работы локальных сетей Ethernet, что оно по существу работает в режиме рептильного мозга, непосредственно в сетевом стеке, практически без контроля со стороны остальной операционной системы. Проблема в том, что протокол ARP чрезвычайно прост (есть только два типа пакетов: запрос и ответ) и никогда не разрабатывался с учетом требований безопасности. Многие реализации протокола, включая сетевой стек ОС Windows, будут вслепую обновлять кэш ARP при получении пакета ответа ARP, такого как тот, который показан на этом снимке Wireshark:

Рис. 1. Снимок Wireshark, показывающий пакет ответа ARP

После получения этого конкретного пакета многие хосты автоматически обновят свой ARP-кэш, указав MAC-адреса и IP-адреса отправителя. Проблема в том, что хотя информация о Цели в этом пакете гарантированно правдива (а как иначе мы могли бы ее получить?), ничто не гарантирует, что информация об отправителе является законной. Протокол ARP никогда не включал механизм аутентификации (сравните его с DNS, другим протоколом сопоставления имен, который также начал свою жизнь как доверчивый наиф, но теперь включает в себя надежные средства безопасности, такие как DNSSec). Один или оба IP-адреса и MAC-адреса отправителя могут быть подделаны.

В данном конкретном случае пакет был сгенерирован известным инструментом безопасности/хакерства Ettercap, который подделал IP-адрес, но использовал действительный адрес Ethernet. Цель этого состояла в том, чтобы замаскироваться под другой хост уровня 3 и перенаправить сетевой трафик ничего не подозревающего ПК на машину, которой он не принадлежал по праву. Эта атака перенаправления известна как отравление кэша ARP.

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

Защита от отравления кэша MITM ARP

Существует множество способов защиты от отравления кэша ARP. Во-первых, не все хостовые операционные системы принимают незапрашиваемые ответы ARP. Из моих собственных тестов Ubuntu Linux и MacOS игнорируют ответный пакет выше, если они сами не отправили предыдущий запрос ARP. Во-вторых, в контролируемых средах LAN коммутаторы можно запрограммировать на игнорирование или отказ от передачи ответов ARP, которые не соответствуют определенным критериям (в мире Cisco это известно как динамическая проверка ARP). В-третьих, некоторые брандмауэры на уровне хоста обеспечивают отслеживание состояния и, следовательно, возможность отклонять незапрошенные ответы ARP (в частности, встроенный брандмауэр Windows этого не делает). В-четвертых, могут помочь различные сторонние инструменты обнаружения вторжений. И в-пятых, статические записи ARP могут использоваться для определенных критических ресурсов (статические записи не могут быть перезаписаны динамическими ответами ARP).

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

Это означает, что большинство атак MITM ARP Cache Poisoning можно победить, если защитить только запись ARP для шлюза по умолчанию.

Мы рассмотрим два способа создания статической записи ARP для шлюза по умолчанию: один в средах, которые мы контролируем, а другой — в сетях, которые мы не контролируем. В обоих случаях мы будем выполнять работу во время загрузки программно, используя бесплатную встроенную среду сценариев PowerShell от Microsoft.

Настройка статической записи ARP через конфигурационный файл

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

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

Мы будем вести централизованный список сопоставлений IP-MAC для шлюзов организации по умолчанию и хранить его в общедоступной общей папке, например \admsrvscripts. Необходимо обновить только один файл, чтобы любые изменения стали доступны мгновенно. Вот пример файла конфигурации:

Последние версии Windows не позволяют использовать старую команду «arp –s» для добавления статических записей ARP, предпочитая вместо этого современную команду netsh.exe. Сначала мы воспользуемся некоторыми приемами инструментария управления Windows (WMI), чтобы извлечь информацию, которая нам понадобится в качестве аргументов для netsh.exe, объединим ее с информацией файла конфигурации и, наконец, вручную создадим и выполним команду netsh для добавления статического ARP. вход. (Обратите внимание, что мы используем аргумент «store=active». Это делает запись ARP статической только для текущей загрузки, а не постоянной для всех загрузок. Это конструктивный выбор, позволяющий нам сохранить некоторую гибкость, но при этом обеспечивающий безопасность. статического ARP.)

Вот скрипт PowerShell, который делает свое дело:

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

Рисунок 2. Запуск скрипта запуска PowerShell через групповую политику

В данном случае я использую пакетный файл для запуска PowerShell, так как вы не можете запустить его напрямую как сценарий запуска в более старых версиях Windows. Я также использую локальный каталог сценариев (c:adminscripts) как для того, чтобы избежать потенциальных проблем с выполнением PowerShell вне общего сетевого ресурса, так и для того, чтобы предвидеть пример 2, где ПК может даже не находиться в корпоративной локальной сети.

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

Рисунок 3: Интерактивная демонстрация настройки статической записи ARP для шлюза по умолчанию

Динамический подход к статическим записям ARP

Хотя описанное выше работает нормально, оно требует некоторых затрат на управление и не принимает во внимание распространенный случай загрузки мобильных устройств в неуправляемых локальных сетях, таких как точки доступа Wi-Fi, сети других организаций, отели и т. д. Возможно, риск Атака MITM в таких случаях даже сильнее, но как защититься от атаки, если нет возможности заранее узнать IP-шлюз по умолчанию?

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

Один из самых популярных сетевых хакерских инструментов, Ettercap, имеет ряд параметров для настройки механизма отравления кэша MITM ARP. По умолчанию он сначала отправляет 5 быстрых поддельных пакетов «ответа» ARP с интервалом в одну секунду, а затем сокращается до одного каждые 10 секунд. Эти значения контролируются, соответственно, параметрами конфигурации Ettercap arp_poison_warm_up и arp_poison_delay. Эти параметры можно сделать более агрессивными, но это увеличивает риск обнаружения системами обнаружения вторжений. Вот как выглядит атака в Wireshark (обратите внимание на временные интервалы между пакетами):

Рисунок 4: Атака Ettercap MITM ARP с отравлением глазами Wireshark

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

1. получить список шлюзов по умолчанию
2. очистить для них все существующие записи таблицы ARP
3. немедленно отправить один пакет ping на шлюз, чтобы принудительно выполнить новый поиск ARP
4. предположим, что динамическое сопоставление ARP, созданное на шаге 3, допустимо, и перепишите его как статическую запись ARP.

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

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

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

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