On 13/12/2023 18:36, Ralph Corderoy wrote:
Hi Tim,
This was about 12 minutes ago
That shows a local TCP port 56946 talking to remote port 80 on
185.151.30.148. I can also talk to that remote port.
$ curl -sSvghttp://185.151.30.148; echo
* Trying 185.151.30.148:80...
* TCP_NODELAY set
* Connected to 185.151.30.148 (185.151.30.148) port 80 (#0)
> GET / HTTP/1.1
> Host: 185.151.30.148
> User-Agent: curl/7.65.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200
< cache-control: no-cache
< content-length: 9
< content-type: text/plain
< x-via: LHR2
<
* Connection #0 to host 185.151.30.148 left intact
It works!
$
It does not mean the remote end initiated the TCP connection and being
port 80, the standard HTTP port, this is unlikely. The local port 56946
is a typical port number for an outgoing connection where the port
number does not matter. I don't know how well ufw, which is designed to
protect the machine from the outside world, can help in stopping TCP
connections which originate from within the machine.
Investigate what processes are talking to the remote IP address at the
time of the packets.
sudo -i ss -p dst 66.39.101.110
This did not return anything
If it's a browser then check if there are service workers running or
tabs updating a page.
Nor did this, but I took it further closing down every program that
running, one at a time and checking with wiresharkto see if the
connection was still running. This went on for sometime until the last
program I stopped was my VPN and thus the connection stopped. I rebooted
we out opening anything other than what normally starts upon reboot,
still running. Stopped the VPN from running at startup, rebooted and
checked wireshark and nothing. Is this the expected actions of a Private
VPN?? Regards Tim H
--
Next meeting: Online, Jitsi, Tuesday, 2024-01-02 20:00
Check to whom you are replying
Meetings, mailing list, IRC, ... http://dorset.lug.org.uk
New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
