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

[Elmar Stellnberger]

The only web page I have opened today with this machine is in deed the 
page of my router (http://192.168.100.1:80) as confirmed by 'visited 
pages'. Could the remote web addresses which we saw in the netstats 
belong to anything queried by some Firefox extension (the extensions 
updating message box of Firefox did not appear on this launch):
* AdBlock Plus
* Extended DNSSEC Validator
* FireFTP
* Flagfox

Perhaps I will try it with reverse DNS resolution as I still find the 
described occurences somehow of concern...

P.S.: The time for which closed connections are visible via netstats has 
definitely increased since elder kernel versions which I would believe 
to be a good thing.


Am 2015-12-04 um 20:55 schrieb 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
>>
>>
>>