Puppy Linux Discussion Forum

tcpdump - available via gslapt uses a syntax like

tcpdump -i wlan0 -s 65536 -w somefile

to monitor interface wlan0 in my case, writing the details to 'somefile'

If you proxy or use ssh to access internet/web pages then traffic flow/timings (big data) can still potentially identify what traffic flowed to where. A DNS name -> IP request pretty much indicates where from and to what destination a request is about to be made, snapshot that web page and you often have a copy of the clear-text, capture the data flow packets and given two out of clear-text, key, encrypted data you can easily deduce the third. Monitor packet flows/timing and you can often associate where the initial request was made from and data/content delivered to.

So even without knowing actual content a lot of information can be gleamed. One way to obscure that is to have tcpdump running and capturing data, that is then forwarded on, and simply dumped to /dev/null at the target/server. More often the final destination is the one with the largest amount of packet flows to it, and with the latest timestamps, so by forwarding the suggested final point is not your IP, but some other IP elsewhere.

That does mean a double-up of bandwidth, as each packet received is in effect having another packet being sent out again, but does obscure things from big-data/traffic analysis (a.k.a the likes of google analytics). You don't have to forward the actual/same packets, any data will do, even /dev/urandom, just the same or ideally slightly more, and at times close to but a little later than when the packets were received.

Example, I ssh into hashbang (HB) from my laptop (LT) and run elinks to view web pages. Traffic analysis indicates requests originating from HB, content returned to HB, but similar numbers of packets also flowing through ssh to LT at around the same time. Pretty conclusive from where and to what web site LT was accessing. If however there was also a similar amount again of packets flowing from LT to HB then ??? Analysis suggests in that case that LT might be being used as a proxy/jump-leg, and where the timings indicate that the last timepoint was for delivery to HB ... suggestive that the actual origination and recipient was HB based.

My untested thinking is along the lines of

tcpdump -i wlan0 dst port 22 and inbound -w somefile

as we don't want to capture all packets when we're also sending out packets ... perpetual loop.
And where 'somefile' is a file/folder located on hashbang via sshfs

mkdir /mnt/hb
sshfs user@hashbang:/home/userid/somefolder /mnt/hb
tcpdump -i wlan0 dst port 22 and inbound -w /mnt/hb/somefile
and where on HB ln -s /dev/null /home/userid/somefolder/somefile

Worked - when I revised the tcpdump line to

tcpdump -u -i wlan0 tcp and dst host 192.168.1.5 and inbound -w /mnt/trash/trash

-u = unbuffered
-i interface (usually wlan0 for wireless, eth0 for hard wired)
dst host <lan ip> of your laptop
inbound = inbound traffic only
-w ... where written to which in my case is a mounted sshfs folder to hashbang and where on hashbang I previously created a ~/trash folder and within that created a trash file ...
ln -s /dev/null trash
and on the laptop I created a /mnt/trash folder and sshfs mounted
sshfs userid@hashbang:/home/userid/trash /mnt/trash

As validation I first used a regular file on hashbang (rather than a sym link to /dev/null (bottomless pit)) and as ssh traffic flowed so that filesize grew indicating that as inbound to laptop ssh traffic (via hashbang) arose so around equal amounts of data also flowed in the opposite direction.

Visibility of the number of packets and timing, such as by my ISP, would be inclined to consider that as my laptop being used as a bounce/jump leg rather than the request originator and final data delivery endpoint.

Somewhat reminds me of how the military used to keep communications lines running at 100% capacity all of the time to avoid otherwise giving away clues of movements/activities simply from the increase/decline in the amount of noise/activity.

Sidelining, this might be of interest

https://www.netburner.com/learn/the-sec ... wireshark/

A year old article about how to view encrypted SSL/TLS data using Wireshark. When tunnelled through ssh however where ssh keys have already been previously established that door is firmly slammed shut.

rufwoof wrote: Fri Apr 15, 2022 8:00 pm

Sidelining, this might be of interest

https://www.netburner.com/learn/the-sec ... wireshark/

A year old article about how to view encrypted SSL/TLS data using Wireshark.[...]

Thanks for this reference. Admittedly I read this article rather quickly so I could have missed some important point. However, it says you need to tell Wireshark your secrets upfront before Wireshark can show the decrypted data.