[arch-security] strange netstat connections after having opened Firefox

[Elmar Stellnberger]

Hi Remi,

   Thanks for your quick response; I should have known. How long are the 
connections kept open by the kernel after the user program has exited 
(they acutally kept to be there for several, several minutes until I 
rebooted*; and Firefox was definitely not killed but closed normally)?
Could it be that the connections did not go away for so long because I 
had unplugged the network cable in response to the enduringly high 
CPU/FAN activity some time after closing the browser?
   There may be an explanation for the high fan activity too as I forgot 
to disable baloo (KDE autoindexing). I still wonder why no nice load was 
indicated the respective KDE widget and still about the load since my 
home  directory here is almost empty (just 4x mp4, 1x mkv, 2x txt); or 
does anyone know whether baloo indexes videos? Or may there have been 
another cause for the enduringly long FAN activity?

Thanks,
Elmar

written on: Linux AmiloXi3650 4.2.5-1-ARCH #1 SMP PREEMPT Tue Oct 27 
08:13:28 CET 2015 x86_64 GNU/Linux

* I am used to connections being still visible for a few seconds but not 
for minutes ...


Am 2015-12-04 um 18:02 schrieb Remi Gacogne:
> Hi Elmar,
>
>> tcp        0      0 192.168.100.101:50056   5.196.185.225:80 TIME_WAIT   -
>> tcp        0      0 192.168.100.101:35860   92.92.207.51:80 TIME_WAIT   -
>> tcp        0      0 192.168.100.101:40912   195.154.59.140:80 TIME_WAIT   -
>> tcp        0      0 192.168.100.101:58746   178.63.62.19:80 TIME_WAIT   -
>> tcp        0      0 192.168.100.101:40482   52.32.86.111:443 TIME_WAIT   -
>> tcp        0      0 192.168.100.101:43256   46.4.37.89:80 TIME_WAIT   -
>
> These connections are in TIME_WAIT, indicating that the connection has
> been closed by your host but are kept alive by the kernel for the
> duration of the TIME_WAIT interval to be properly handle any TCP still
> in-flight somewhere, see [1] for more details. The fact that the
> connections have no associated program is because the TIME_WAIT state is
> handled by the kernel, and from the application point of view, they do
> not exist anymore.
> You can see that the connections were to TCP/80 and TCP/443, so very
> likely caused by Firefox connecting to HTTP/HTTPS servers before you
> closed it.
>
> You'll be fine.
>
>
> [1]:
> https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Protocol_operation
>
>