Security Ripcord

This will show the capture of ping requests to a specific host. This information will be captured using tshark to a pcap file. This pcap file will be edited to cut out the ping reply packets. This file will then be used to replay the ping requests and receive responses.

This should be the first step to many similar replays.

Run tshark to capture

[user@localhost tshark]$ sudo /usr/sbin/tshark -i eth0 -w ping_default.pcap
Password:
Running as user “root” and group “root”. This could be dangerous.
Capturing on eth0
8
[user@localhost tshark]$

Ping remote host

[user@localhost tshark]$ ping -c 4 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.422 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=0.339 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.243 ms
64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=0.334 ms

— 192.168.2.1 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 0.243/0.334/0.422/0.065 ms
[user@localhost tshark]$

Read pcap file with tshark

[user@localhost tshark]$ sudo /usr/sbin/tshark -r ping_default.pcap
Running as user “root” and group “root”. This could be dangerous.
1 0.000000 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
2 0.000370 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
3 1.000509 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
4 1.000783 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
5 2.001345 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
6 2.001524 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
7 3.001984 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
8 3.002263 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
[user@localhost tshark]$

Rip out only the wanted packets

[user@localhost tshark]$ ls
ping_default.pcap
[user@localhost tshark]$ sudo /usr/sbin/editcap ping_default.pcap ping_requests.pcap 1 3 5 7
Password:
Add_Selected: 1
Not inclusive … 1
Add_Selected: 3
Not inclusive … 3
Add_Selected: 5
Not inclusive … 5
Add_Selected: 7
Not inclusive … 7
[user@localhost tshark]$ ll
total 16
-rw——- 1 root root 936 2008-05-17 23:33 ping_default.pcap
-rw-r–r– 1 root root 480 2008-05-17 23:35 ping_requests.pcap
[user@localhost tshark]$

Read pcap file with tshark

[user@localhost tshark]$ sudo /usr/sbin/tshark -r ping_requests.pcap
Running as user “root” and group “root”. This could be dangerous.
1 0.000000 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
2 1.000413 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
3 2.001154 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
4 3.001893 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
[user@localhost tshark]$

I am not sure why that happened. Grap the right packets with editcap.

[user@localhost tshark]$ sudo /usr/sbin/editcap ping_default.pcap ping_requests.pcap 2 4 6 8
Add_Selected: 2
Not inclusive … 2
Add_Selected: 4
Not inclusive … 4
Add_Selected: 6
Not inclusive … 6
Add_Selected: 8
Not inclusive … 8
[user@localhost tshark]$

Read pcap file with tshark

[user@localhost tshark]$ sudo /usr/sbin/tshark -r ping_requests.pcap
Running as user “root” and group “root”. This could be dangerous.
1 0.000000 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
2 1.000509 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
3 2.001345 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
4 3.001984 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
[user@localhost tshark]$

Replay with TcpReplay

[user@localhost tshark]$ sudo tcpreplay –intf1=eth0 ping_requests.pcap
sending out eth0
processing file: ping_requests.pcap
Actual: 4 packets (392 bytes) sent in 3.10 seconds
Rated: 130.2 bps, 0.00 Mbps/sec, 1.33 pps

Statistics for network device: eth0
Attempted packets: 4
Successful packets: 4
Failed packets: 0
Retried packets: 0
[user@localhost tshark]$

Capture replay with tshark

[userr@localhost tshark]$ sudo /usr/sbin/tshark -i eth0 -w ping_replay.pcap
Running as user “root” and group “root”. This could be dangerous.
Capturing on eth0
8
(process:8719): CaptureChild-INFO (recursed): Signal: Stop capture
aborting…
tshark: Child capture process died: Abort
[user@localhost tshark]$

Review what happened with tshark

[user@localhost tshark]$ sudo /usr/sbin/tshark -r ping_replay.pcap
Running as user “root” and group “root”. This could be dangerous.
1 0.000000 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
2 0.000332 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
3 1.001619 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
4 1.001905 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
5 2.002310 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
6 2.002494 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
7 3.003997 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
8 3.004201 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
[user@localhost tshark]$

Go forth and do good things,

Don C. Weber

There is an interesting conversation in the Security Catalyst Community with the title “vmware bridge vs. NAT“. It started as a discussion about developers utilizing VMware for development on their local machines. The initial issue was whether to allow the developers to configure their systems so that the guest communicated through the host via NAT or to require that all guests be assigned an IP address on the network.

The thread has already gone through a spiral of recommendations and additional questions. I will not hash those out here. But what I found interesting is that this all comes back to a question of policy. The current policy, at this company, “stats [sic] that no workstation should route traffic.” One respondent pointed out that although the implementation of VMware might be a concern, perhaps the problem is actually the way that the policy has been written.

The way that policy is written should never get in the way of the desired goal for which the policy has been instated. What I mean by that is that the requirement that ‘no workstation should route traffic’ is a means, and not a goal. What you probably want is that no workstation should be able to connect networks in a way that they were not designed to.

Very sage advice.

All of this brings the risk of unauthorized network extension to the forefront. What I mean by network extension is any hardware or software configuration that permits other systems to utilize the network. What I mean by unauthorized is anything that has not gone through the proper approval channels to be placed on the network. We see examples of this all the time in most work places. Somebody attaches a network hub or switch so that they can have a desktop and a laptop. Another person bridges their network interfaces through their handy-dandy Microsoft XP configuration capabilities. And the one that everybody knows best, wireless, wireless, wireless. All of these scenarios can increase the risk to any environment. Not only do you have unauthorized systems on the network, but there is no telling how they have been configured, what software and hardware has been installed, or what the administrative passwords may be. Just to name a few.

So, how do we combat the extension of our network. Well, at my last job at the university, they started with (yup, you guessed it) policy. And despite a few rough encounters that occurred while confiscating equipment, I believe that they handled it quite well. First they started with an over-arching policy to start the control effort. (I have changed a few of the position and department titles to be more universal and understandable.)

All University data, video, wireless, and voice telephone network connectivity, including but not limited to active data net-attached lines, hubs, switches, telephones, wireless and extenders, must be approved by the Chief Technology Officer. Such connectivity must be coordinated and supervised by IT Department. Any installation not approved may be disconnected.

Next they developed policies with more detail that provided the users with information about the policy’s scope, applicability, terms, implementation, and consequences. They made it very clear that ownership and operation of the campus’ network would be handled by a specific department and that all approvals for connectivity would have to be processed by that department. They provided very clear wording to ensure that all users understood that this included any instances where the network was extended.

All hardware and software configured to extend or re-transmit the university network and telecommunications infrastructure, including all wireless technologies, must be approved by the Chief Technology Officer prior to acquisition and deployment. All systems, devices, and software capable of extending this infrastructure must adhere to configuration standards developed and maintained by the IT Department.

Finally, they very specifically stated what would occur if the policy was violated and the devices extending the network were located.

Any device, system, or software found in violation of this procedure may be confiscated and temporarily stored by the Chief Technology Officer or a representative of the office.

Of course these are all just snippets from several policies that combine into a proactive security stance for the University. But I believe they state very clearly the organization’s stance on network extension and may help those of you who have not considered these types of policies.

Now, where does this all get us with the original issue of permitting NATed VMware instances. I believe that it leaves it open to interpretation. It allows the IT personnel, developers, and Chief Technology Officer to negotiate an agreement by looking at the risks and implementing controls. The policies are flexible enough to permitted this type of configuration with prior approval, while also empowering the IT department should a high risk situation arise.

Go forth and do good things,

Don C. Weber

SCC, policy, management, university, security, Security Ripcord, network extension