Сценарий: скрытие устройства CPE на пути прохождения трафика с помощью расширенных правил межсетевого экрана

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

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

Исходное состояние

Топология сети

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

• Два хоста A и B подключены к устройству CPE.
• Интерфейсы eth1 и eth2 на устройстве CPE находятся в одной зоне.
• Межсетевые экраны на хостах A и B настроены на пропуск трафика ICMP.
• С хоста A выполняется трассировка маршрута до хоста B с помощью traceroute:

  tracert -d 10.123.2.11

  Результат:

  1 10.123.1.1

  2 10.123.2.11

  Интерпретация результата:

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

• Анализ сетевого трафика на CPE для протокола ICMP между хостами A и B с помощью команды tcpdump -i any net 10.123.0.0/16 показывает следующее:

  eth1 In IP 10.123.1.11 > 10.123.2.11: ICMP echo request, id 1, seq 102, length 72

  eth1 Out ARP, Request who-has 10.123.1.11 tell 10.123.1.1, length 28

  eth1 In ARP, Reply 10.123.1.11 is-at bc:24:11:0a:91:06 (oui Unknown), length 28

  eth1 Out IP 10.123.1.1 > 10.123.1.11: ICMP time exceeded in-transit, length 100

  eth1 In IP 10.123.1.11 > 10.123.2.11: ICMP echo request, id 1, seq 103, length 72

  eth1 Out IP 10.123.1.1 > 10.123.1.11: ICMP time exceeded in-transit, length 100

  eth1 In IP 10.123.1.11 > 10.123.2.11: ICMP echo request, id 1, seq 104, length 72

  eth1 Out IP 10.123.1.1 > 10.123.1.11: ICMP time exceeded in-transit, length 100

  eth1 In IP 10.123.1.11 > 10.123.2.11: ICMP echo request, id 1, seq 105, length 72

  eth2 Out ARP, Request who-has 10.123.2.11 tell 10.123.2.1, length 28

  eth2 In ARP, Reply 10.123.2.11 is-at bc:24:11:59:58:b7 (oui Unknown), length 28

  eth2 Out IP 10.123.1.11 > 10.123.2.11: ICMP echo request, id 1, seq 105, length 72

  eth2 In IP 10.123.2.11 > 10.123.1.11: ICMP echo reply, id 1, seq 105, length 72

  eth1 Out IP 10.123.2.11 > 10.123.1.11: ICMP echo reply, id 1, seq 105, length 72

  eth1 In IP 10.123.1.11 > 10.123.2.11: ICMP echo request, id 1, seq 106, length 72

  eth2 Out IP 10.123.1.11 > 10.123.2.11: ICMP echo request, id 1, seq 106, length 72

  eth2 In IP 10.123.2.11 > 10.123.1.11: ICMP echo reply, id 1, seq 106, length 72

  eth1 Out IP 10.123.2.11 > 10.123.1.11: ICMP echo reply, id 1, seq 106, length 72

  eth1 In IP 10.123.1.11 > 10.123.2.11: ICMP echo request, id 1, seq 107, length 72

  eth2 Out IP 10.123.1.11 > 10.123.2.11: ICMP echo request, id 1, seq 107, length 72

  eth2 In IP 10.123.2.11 > 10.123.1.11: ICMP echo reply, id 1, seq 107, length 72

  eth1 Out IP 10.123.2.11 > 10.123.1.11: ICMP echo reply, id 1, seq 107, length 72

  Интерпретация:

Таким образом, сценарий скрытия устройства CPE от обнаружения в сети состоит из следующих шагов:

1. Скрытие CPE из вывода traceroute
   1. Создайте на устройстве CPE расширенное правило, которое блокирует генерируемые на CPE исходящие сообщения ICMP Time-Exceeded, когда CPE получает IP-пакет с TTL=1:

   

   Создание расширенного правила для блокировки сообщений ICMP Time-Exceeded 1

   

   Создание расширенного правила для блокировки сообщений ICMP Time-Exceeded 2

   Созданное расширенное правило соответствует следующей команде в формате iptables:

   iptables -t filter -I OUTPUT -p icmp --icmp-type 11 -j DROP -m comment --comment "#ADV Name: block-ICMP-type11"

   Аналогичное правило в формате iptables при выводе iptables -L выглядит следующим образом:

   Chain OUTPUT (policy ACCEPT)

   target prot opt source destination

   DROP icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 11 /* #ADV Name: block-ICMP-type11 */

   1. Проверьте трассировку маршрута от хоста A до хоста B:

      На хосте A выполните трассировку маршрута до хоста B:

      tracert -d 10.123.2.11

      Результат:

      1 Request timed out

      2 10.123.2.11

      Интерпретация результата:

      Traceroute отправляет эхо-запросы ICMP с растущим TTL. Сообщение ICMP type 11 (Time-Exceeded) генерируется маршрутизатором, но блокируется расширенным правилом межсетевого экрана, поэтому не появляется в трассировке. После последовательного увеличения хостом A значения TTL оно становится достаточным, чтобы запрос достиг хоста B по адресу 10.123.2.11, который отвечает обычным сообщением Echo Reply. Это единственное сообщение, которое в итоге видно в дампе.

2. Блокировка ответов CPE на ICMP Request
   1. Создайте на устройстве CPE расширенное правило, которое отбрасывает ICMP-пакеты, предназначенные устройству CPE:

   

   Создание расширенного правила для отбрасывания ICMP-пакетов на CPE (1)

   

   Создание расширенного правила для отбрасывания ICMP-пакетов на CPE (2)

   Созданное расширенное правило соответствует следующей команде в формате iptables:

   iptables -t filter -I INPUT -p icmp -d 10.123.1.1 --icmp-type 8 -j DROP -m comment --comment "#ADV Name: block-ICMP-type8-to-CPE"

   Аналогичное правило в формате iptables при выводе iptables -L выглядит следующим образом:

   1. Проверьте работу правила, выполнив на хосте А ping до адреса CPE на eth1:

      ping 10.123.1.1

      Результат:

      Request timed out

3. Скрытие CPE из пути прохождения трафика с помощью манипуляций с TTL

   Вам необходимо создать расширенное правило, которое увеличивает TTL для сообщений ICMP Type 8 (Echo Request) на 1 до того, как маршрутизатор уменьшит это значение на 1. Для этого правило необходимо добавить в цепочку PREROUTING таблицы MANGLE.

   1. Создайте на устройстве CPE расширенное правило, которое увеличивает TTL на 1:

   

   Создание расширенного правила для увеличения TTL (1)

   

   Создание расширенного правила для увеличения TTL (2)

   Созданное расширенное правило соответствует следующей команде в формате iptables:

   iptables -t mangle -A PREROUTING -p icmp --icmp-type 8 -j TTL --ttl-inc 1 -m comment --comment "#ADV Name: inc-TTL-for-ICMP-Echo-Request"

   1. Выполняем на Хосте А traceroute до Хоста B.

      tracert -d 10.123.2.11

      Результат:

      1 10.123.2.11

      Как это правило отражается на трассировке маршрутов между двумя хостами, подключенными к CPE:

   Шаг	Что происходит без правила	Что происходит с правилом
   1. Хост A отправляет пакет с TTL = 1 (первый хоп)	CPE получает пакет, уменьшает TTL до 0, отбрасывает пакет и генерирует ICMP Time‑Exceeded (type 11), который возвращается к А. Хост A видит CPE как первый hop.	В цепочке PREROUTING TTL увеличивается до  2. Затем ядро CPE уменьшает его до  1. Пакет не отбрасывается, CPE пересылает его дальше. Поэтому ICMP Time‑Exceeded не генерируется и первый хоп (CPE) не появляется в выводе.
   2. Пакет поступает на конечный хост (хост B)		Пакет приходит к хосту B с TTL = 1. Здесь TTL будет уменьшен до  0 и хост B сгенерирует сообщение ICMP Time‑Exceeded. Хост B будет показан как первый хоп в traceroute.
   3. Последующие шаги traceroute	На этом шаге TTL увеличивается до 2, CPE снижает его до 1. Хост B снижает TTL до 0, отбрасывает пакет, генерирует сообщение ICMP Time‑Exceeded. Хост B будет показан как второй хоп в traceroute.

   Созданное действует только для пакетов ICMP type 8 (Echo Request). Если traceroute или аналогичное средство трассировки маршрутов будет использовать UDP-пакеты, первый хоп все равно будет виден. Чтобы скрыть маршрутизатор от трассировки маршрутов с использованием UDP-пакетов, необходимо создать аналогичное правило для протокола UDP.

4. Скрытие информации о производителе устройства CPE за счет назначения LAN-интерфейсам устройства MAC-адресов из диапазона LAA

   Чтобы пользователи локальной сети не смогли получать информацию о производителе устройства CPE через изучение стандартных MAC-адресов его LAN-интерфейсов, вам необходимо переназначить интерфейсам MAC-адреса из диапазона LAA (англ. Locally Administered Address, локально администрируемый адрес). MAC-адрес считается локально администрируемым, если второй наименьший значащий бит (англ. second least significant bit) в его первом октете равняется 1. Пример:

   06:1A:2B:3C:4D:5E

   06 → 0000 0110

   Чтобы скрыть информации о производителе устройства CPE:

   1. Проверьте, что стандартный MAC-адрес устройства CPE содержит информацию о производителе:
      1. Выполните ping с хоста B на адрес шлюза (интерфейс CPE eth2 с IP-адресом 10.123.2.1).
      2. Проанализируйте посланный на CPE трафик ICMP с помощью WireShark:

   

   Анализ трафика в Wireshark: для MAC-адреса назначения отображается информация о производителе устройства CPE

   В поле Destination MAC-адрес интерфейса eth2 устройства CPE отображается с префиксом производителя ProxmoxServe_. Этот префикс соответствует стандартным MAC-адресам, присваиваемым по умолчанию виртуальным машинам в среде виртуализации Proxmox. Благодаря этому можно выяснить, что устройство CPE запущено в виде виртуальной машины в Proxmox. Таким образом, приложение WireShark смогло определить префикс производителя по стандартному MAC-адресу.

   1. Присвойте LAN-интерфейсу устройства CPE в сторону хоста B (eth2) MAC-адрес из диапазона LLA:

   

   Присвоение LAN-интерфейсу устройства MAC-адреса из диапазона LLA

   1. Убедитесь, что стандартный MAC-адрес устройства CPE не содержит информацию о производителе:
      1. Повторно выполните ping с хоста B на адрес шлюза (интерфейс CPE eth2 с IP-адресом 10.123.2.1).
      2. Проанализируйте посланный на CPE трафик ICMP с помощью WireShark:

   

   Анализ трафика в Wireshark: информация о производителе устройства CPE не отображается

   Теперь в поле Destination MAC-адрес интерфейса eth2 устройства CPE отображается в исходном виде и не указывает на среду виртуализации или производителя сетевого оборудования.