Synchronized Windows to Windows Packet Capture

June 13th, 2017 | Garland Joseph

This script is part of a series of scripts that perform packet capture between two endpoints.  In this case, the endpoints are two windows machines.  This script was tested with the “source endpoint” as a Windows 10 machine and the “target endpoint” a Windows 2016 Server machine.   The circular traces are started on each machine and stopped whenever an event is detected.  In this case the event is to monitor a file for a particular string.

Requirements: Wireshark installed on Windows
Caveats: Target endpoint must be Windows Server (Source endpoint can be windows client).

Scenario

Script

<#
################################################################################################

.SYNOPSIS
Author: Garland R.Joseph, garland.joseph@gmail.com, July 2016

Simple Packet capture from windows to windows based on monitoring a file.

.DESCRIPTION

Side-effects
Uses an interim x.x and local_trace.ps1 file, but removes them at end.

.EXAMPLE

w2wcap [ -verbose | -v ] [ -c "capture-file" ] [ -s "seconds" ] [ -u "remote user" ] [ -p "password" ]

-r "remote host" -l "log file" -t "text string" -a "local interface" -b "remote interface"

.PARAMETER v | verbose
Optional.  This option prints additional informational messages during processing.

.PARAMETER c
Optional. This option specifies the name of the capture file.  The default is set to capture.  The script is set to only create 2 files per endpoint and the default size is 512 MB. So the 2 files total will be less than a 1 GB.  You can modify this behavior by changing the FILESIZE and FILECOUNT variables below.  The filenames will look similar to...
capture_00049_20170612214134
capture_00050_20170612215042

.PARAMETER s
Optional. Range is 1 second to 18000 seconds (5 hours) for parsing the log file. The default is 5 seconds. Please examine the process to gauge impact on system resources.  The lower the number, the more system resources are consumed.

.PARAMETER u
Optional. This is the username for the remote user on the target endpoint. You can hard code the value in the script (see the $u=Wireshark line below) or optionally specify the name on the command line.  The account should have 
sufficient privilege to run the tshark command tool for the Wireshark facility. This parameter is optional, but recommended so you don't store the username in a file.

.PARAMETER p
Optional.  This is the password for the remote user.  This parameter is optional, but recommended so you don't store the password in a file.

.PARAMETER r
Required.  This is the hostname or ip address of the target endpoint.

.PARAMETER l
Required.  This is the log file that will be parsed for the string as specified by parameter t.  The traces will stop once a new string specified by parameter t is found in the log file.  The script parses for an initial count so the log file does not have to be "zeroed-out".

.PARAMETER t
Required.  This the text string used in parsing the log file.

.PARAMETER a
Required.  This is the ip address of the local interface on the source
endpoint that "talks" to the target endpoint.

.PARAMETER b
Required.  This is the ip address of the remote interface on the target
endpoint.
###############################################################################################
#>

#
# Setup Command Line Options
#

[CmdletBinding()]

Param (

[string]$c = "capture",

[ValidateRange(1,18000)]
[int]$s = 5,

[string]$u = "Wireshark",
[string]$p = "Pr1nceH1ll",


[Parameter(Mandatory=$True)]
[string]$r,

[Parameter(Mandatory=$True)]
[string]$l,

[Parameter(Mandatory=$True)]
[string]$t,

[Parameter(Mandatory=$True)]
[int]$a,

[Parameter(Mandatory=$False)]
[int]$b
)

If (-Not (Test-Path $l ) ) {
Write-Host "Log file $l does not exist"
exit
}

#
# Default options, can be changed to increase capture file size, count, etc
#


#$FILESIZE=1000 #units or kB, so this means 1 Meg
$FILESIZE=500000 #512 Meg
#$FILESIZE=1000000 #units or kB, so this means 1 Gig

$FILECOUNT=2 #creates a count of FILECOUNT of trace files at most of size FILESIZE

$TSHARK_LOCATION_REMOTE="c:\progra~1\wireshark\tshark"
$TSHARK_LOCATION_LOCAL="c:\progra~1\wireshark\tshark"
$TRACECMD_REMOTE="$TSHARK_LOCATION_REMOTE -b filesize:$FILESIZE -b files:$FILECOUNT -w $c -i $b"
$TRACECMD_LOCAL="$TSHARK_LOCATION_REMOTE -b filesize:$FILESIZE -b files:$FILECOUNT -w $c -i $a"

#
# Set up script block in order to evaluate parameters for remote command
# We use an interim file for asynchronously running the local trace
#

$sb_remote = {
param ($p1,$p2,$p3,$p4,$p5,$p6)
winrs /r:$p1 /u:$p2 /p:$p3 $p4
}

$TRACECMD_LOCAL &gt; ./local_trace.ps1

#
# Start trace on remote host, then on local host
#

Write-Verbose "Starting remote trace with ${TRACECMD_REMOTE}"
Write-Verbose "(winrs /r:$r /u:$u /p:$p $TRACECMD_REMOTE)"
Start-Job -Scriptblock $sb_remote -ArgumentList $r,$u,$p,$TRACECMD_REMOTE

Write-Verbose "Starting local trace with ${TRACECMD_LOCAL}"
Start-Process powershell.exe -ArgumentList "-file ./local_trace.ps1"

#
# Monitor log file
#
#
Write-Verbose "Start of monitoring file $l ever $s seconds for string $t..."
#init counters
Select-string -path "$l" -pattern $t | Measure-object -line | ft -hidetableheaders &gt; x.x ; $old_count = cat x.x | where {$_ -ne ""} | %{$_ -replace '\s+','' }
$new_count=$old_count
#loop until match found
$i=0
while ($new_count -eq $old_count) {
$i++
write-verbose "Iteration: $i, sleeping $s seconds..."
start-sleep -s $s
Write-verbose "Searching $l for $t..."
Select-string -path "$l" -pattern $t | Measure-object -line | ft -hidetableheaders &gt; x.x ; $new_count = cat x.x | where {$_ -ne ""} | %{$_ -replace '\s+','' }
}

#
# At this point, search string has been found, stop traces
#

#remote
taskkill /f /s $r /u $u /p $p /fi "imagename eq tshark*"

#local
taskkill /f /fi "imagename eq tshark*"

Write-Verbose "Traces completed after $i iterations. Examine the set of $FILECOUNT files on each endpoint with file name: $l on both endpoints."

#
# Clean up
#

if (Test-Path "./x.x") { rm "./x.x" }
if (Test-Path "./local_trace.ps1") { rm ./local_trace.ps1 }

exit

Synchronized Windows to Linux Packet Capture

July 5th, 2017 | Garland Joseph

This script is part of a series of scripts that perform packet capture between two endpoints.  In this case, the endpoints are a Unix machine and a windows machine. This script was tested with the “source endpoint” as a Redhat Linux and the “target endpoint” a Windows 2016 Server machine.  

The circular traces are started on each machine and stopped whenever an event is detected on the Unix side.  In this case the event is to monitor a file (i.e., log) for a particular string.

Requirements: Wireshark installed on Windows. OpenSSH installed on Windows. 

Scenario

Unix to Windows Capture Scenario

Script

#Author: Garland R. Joseph, garland.joseph@gmail.com
# Date: May 2017
# u2wcap: See usage below. "Unix to Windows Capture"
#
# This script is offered as is. It is designed to
# run a circular trace using tcpdump on UNIX system
# and wireshark on Windows systems.
#
# You will either have to manually enter the password
# for the root account on the remote system or setup
# ssh keys from promptless access.
#
# The traces will stop once a key string SEARCH_STRING is
# found in LOG_FILE.
#
# Note: Some UNIX systems like LINUX Fedora will
# result in permsission denied when using
# tcpdump -W and -C options and writing to / or /root.
#
# Modify the REM_INTERFACE parameter below to fix the interface number
# on the windows system. Do a tshark -D to determine the interface number.
#
#
# -----

#
# Defaults
#

USAGE="u2wcap [-v] [ -c capture_file ] [ -w secs ] -h remote_host -l log_file -s search_string"
DEBUG=false
SLEEP_TIME="5" #seconds
LOCAL_CAPTURE_FILE="/tmp/capture"
TCPDUMPCMD="tcpdump -C 1 -W 2 -w ${LOCAL_CAPTURE_FILE}"

#
# Options for remote tracing
#

REM_CAP_FILE="capture.windows"
REM_USER="wireshark"
REM_INTERFACE="4"
FILESIZE=1000 #units or kB, so this means 1 Meg
#FILESIZE=500000 #512 Meg
#$FILESIZE=1000000 #units or kB, so this means 1 Gig
FILECOUNT="2" #creates a count of FILECOUNT of trace files at most of size FILESIZE
TSHARK_LOCATION="c:\progra~1\wireshark\tshark"
#TRACECMD="$TSHARK_LOCATION -b filesize:$FILESIZE -b files:$FILECOUNT -w ${REM_CAP_FILE}"
TRACECMD="$TSHARK_LOCATION -b filesize:$FILESIZE -b files:$FILECOUNT -w ${REM_CAP_FILE} -i ${REM_INTERFACE}"


#
# Process command line arguments
#

while getopts ":vc:w:l:s:h:" opts
do
case ${opts} in
v) DEBUG=true ;;
c) CAPTURE_FILE=${OPTARG} ;;
w) SLEEP_TIME=${OPTARG} ;;
s) SEARCH_STRING=${OPTARG} ;;
l) LOG_FILE=${OPTARG} ;;
h) REMOTE_HOST=${OPTARG} ;;
":") echo "Please specify a value for ${OPTARG}" ; exit ;;
\?) echo "${OPTARG} is not a valid switch" ; echo "${USAGE}" ; exit;;
esac
done

#
# Insure required values have been specified, check for existence of
# log file, getops should handle case of no values for -l and -s.
# A sanity check in the event getopts varies per unix
#

if [[ -z ${SEARCH_STRING} || -z ${LOG_FILE} || -z ${REMOTE_HOST} ]]
then
echo ${USAGE}
exit
fi
if ! [[ -f ${LOG_FILE} ]]
then
echo "File ${LOG_FILE} does not exist"
exit
fi

#
# Start trace on remote host
#
$(ssh ${REM_USER}@${REMOTE_HOST} ${TRACECMD})& 2>&1 > /dev/null

#
# Start trace on this host
#

${TCPDUMPCMD} 2>/dev/null 1>/dev/null & LOCAL_PID=$!
${DEBUG} && echo "${0}-I-LOCAL_PID, local pid is ${LOCAL_PID}."

#
# Monitor log file
#

old_count=`grep -c ${SEARCH_STRING} ${LOG_FILE}`
(( new_count=old_count ))
(( i = 0 ))
while (( old_count == new_count ))
do
(( i++ ))
${DEBUG} && echo "${0}-F-SLEEP, sleeping ${SLEEP_TIME}, iternation ${i}."
sleep ${SLEEP_TIME}
new_count=`grep -c ${SEARCH_STRING} ${LOG_FILE}`
done

#
# At this point, search string has been found, stop traces
#

kill ${LOCAL_PID}
ssh ${REM_USER}@${REMOTE_HOST} taskkill /f /fi \"imagename eq tshark*\"

#
# Reminders
#

echo "Consult files ${REM_CAP_FILE} on remote host ${REMOTE_HOST} and ${LOC_CAP_FILE} on local host."

exit

The Silo-d Approach

In my experience, one of the biggest challenges organizations face is the issue of silos. Teams and departments naturally pull in different directions, which can make collaboration difficult. Bridging silos requires understanding the relationships between them. For instance:

  • IT and Accounting: Bridging silos between fundamentally different functions is inherently challenging.
  • Engineering and Operations: These silos, being closer in scope and purpose, are easier to connect.
  • Intra-team silos: Resolving silos within the same team should be straightforward and non-negotiable.

A Lesson from the Past: Show a Willingness to Help or A Little Gas Money goes a Long Way

Here’s a story from my time at GTE Data Services (the technical division of GTE in Temple Terrace, FL). I was promoted to Technical Lead and Manager, supporting the commercial side of GTE, headquartered in Tampa.

One of the first things I did was take my team on a short 30-minute drive to meet our clients face-to-face. We didn’t discuss technical details; instead, we simply asked how we could better assist them and understand their challenges.

When we returned, the director of the data center met us at the door, thrilled. He told us, “They just called and said they’d never seen anything like that.”

What stood out wasn’t any technical solution but our willingness to connect and help. That small gesture of driving over to meet them had far more value than spending hours solving a technical issue.

The Challenge: Recognizing Workable Boundaries

To break down silos, it’s essential to recognize the nature of the boundaries:

  • IT and Accounting: These silos are difficult to bridge and require significant effort and empathy.
  • Engineering and Operations: These are easier to resolve due to shared goals and overlap in workflows.
  • Team-level silos: These must be resolved immediately, as collaboration within a team is foundational.

Resolving Team-Level Silos

The primary issue with team-level silos is that work continuity is disrupted when a siloed team member is unavailable. This creates delays and inefficiencies that can impact the entire team’s productivity.

Challenges

  1. “We’re too busy to share knowledge.”
    Teams often feel they lack the time to document processes or cross-train because of immediate demands.
  2. “If I share my knowledge, I lose my value.”
    Some team members fear losing their importance or unique expertise by sharing information.

Solution

To address these challenges:

  • Mandatory Documentation: Require team members to document fundamental tasks and resolutions for recurring issues. This ensures critical work can continue smoothly in their absence.
  • Define Roles Clearly: While documentation covers routine work, the original team member retains ownership of resolving more complex, technical problems.

Resolving Silos Between IT and Accounting, Engineering and Operations

For bridging silos between distinct functions or departments, I apply a consistent approach to foster collaboration:

  1. Listen First: When contacted by someone outside my team, I focus on understanding their issue. I respond in the same way they reached out, whether through email or a call, to ensure clarity and connection.
  2. Provide Initial Help: If the issue persists, I offer simple, actionable technical documentation to address their need. In most cases, this resolves the problem.
  3. Gauge Commitment: If they reach out again with the same issue, I refer them to the original documentation. At this point, I observe whether they are making a reciprocal effort to solve the problem.
    • If they show progress and commitment to solving the issue, I match their effort by dedicating time to collaborate further.
    • If they repeatedly ask the same questions without demonstrating effort, I step back, as the process requires mutual commitment.

By fostering a willingness to help while expecting accountability, this approach ensures that collaboration is efficient and constructive.

Leadership from Behind

With over 25 years in technology, I’ve managed multiple teams across Fortune 500 companies. While I wasn’t always in an official leadership role, my breadth of experience often positioned me as a subject matter expert across various technical domains.

Navigating corporate environments can be challenging, especially in cultures that emphasize competition over collaboration. Yet, true, sustainable success relies on cooperation. I remember a senior leader once thanked me for always helping my team, but then added, “All you have to do to succeed here is to be better than your peers.” She quickly climbed the corporate ladder, yet the department continued to struggle with the same issues. This led me to adopt a different approach: Leadership from Behind.

My strategy isn’t just about my expertise; it’s also about sharing it. Experience naturally leads to knowledge, but in companies where collaboration is undervalued, fostering this knowledge can be difficult. Nevertheless, I’ve seen my approach yield positive results, even leading to official leadership opportunities.

I aim not only to help colleagues but also to educate them through my experience. Here’s a typical scenario:

“Garland, I was told to reach out to you regarding such and such.”

“How can I help?”

I don’t just troubleshoot or resolve the issue; I document the solution if I haven’t already done so. I believe the most vital skill for an engineer is a commitment to the written word. In today’s world, where texting often replaces in-depth communication, few people take the time to read. Frequently, colleagues return with the same questions, hoping I’ll fix the problem again, but I refer them back to the documentation. (Teach a person to fish, and they’ll eat for a lifetime.)

When I join a new environment, I establish a central repository for all technical documentation, if one doesn’t exist already.


Technical Leadership

In formal leadership roles, I believe a technical leader’s purpose is to educate and empower their team. I begin by setting up communication protocols that define how the team operates. I encourage team members to be versatile, ensuring everyone is familiar with the full spectrum of responsibilities rather than working in silos. This way, the team’s progress doesn’t depend on the availability of a single individual.

By fostering knowledge-sharing and collaboration, I believe we can create resilient teams that are both innovative and prepared to handle any challenge.

Here’s a Good One: Empowering Your Team

While working at IBM, I managed a team of AIX System Administrators with diverse skills and personalities. One standout member was a self-taught programmer—confident, resourceful, and passionate about solving problems. He’d spend his days at work troubleshooting and likely spent many nights honing his skills at home. He was, without a doubt, talented.

Often, he would come into my office to report an issue with the system. I’d typically resolve the problem in about five minutes. This became a routine.

One day, I noticed him walking toward my office, but then he stopped, turned around, and left without saying anything. A few hours later, he returned with a smile on his face and said, “I figured it out.”

Curious, I asked, “What did you figure out?” He showed me the solution and then added, “I wasn’t about to walk in here and have you figure it out in five minutes again.”

That moment was pivotal. It showed he was motivated to stretch his abilities, solve problems independently, and take ownership of his growth. This was precisely the mindset I wanted to cultivate within the team—confidence, persistence, and self-reliance.

Empowering team members doesn’t always require formal training or instruction. Sometimes, giving them the space to rise to challenges is enough to inspire growth and innovation.

Sizing Formula for Packet Capture Flow through an Out of Band Fabric

Caveat: This documentation is part of a larger set of proprietary information I created for a fortune 1000 company. This information is not confidential.

Problem

Non-networking groups are not familiar with show to size packet capture or “streaming capture” devices. Sizing these devices is mathematically a linear system of constraints.

The following set of governing equations were developed for a security team to allow them to correctly size ExtraHop appliances attached to an out-of-band fabric (in turn, attached to the production IP fabric).

Theoretical
pRI = pRO = 10Gbps or 100Gbps
Equations
MMD = DS/eRI = DS x 1 / eRI
Simple Example: Caculating minutes of data on disk

A 100GBdisk, eRI=10Gbps(=758GB/m)

10 Gbps x 60s/m = 600 Gbpm

600 Gbpm x 1GB/8Gb = 75GB/m

MMD = 100GB / 75GB/M = 1.33 minutes