[arch-security] strange netstat connections after having opened Firefox
The following number of connections was returned by netstat -atupn while Firefox was already closed and killall-ed to show that it really had sucessfully closed itself before (It was open only for short mainly in order to reboot my router.): Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name 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 - udp 0 0 192.168.100.101:59824 193.170.62.252:123 ESTABLISHED 328/ntpd: ntp engin udp 0 0 192.168.100.101:40120 80.64.132.152:123 ESTABLISHED 328/ntpd: ntp engin udp 0 0 0.0.0.0:68 0.0.0.0:* 304/dhcpcd There should not be any unnamed daemon opening up such connections under Arch Linux when netstat -atupn is run as root, right? (At least I have installed none; I already know from previous netstats that Arch is very strict with its default configuration in this regard.) What has made me look was a 100% CPU load indicated by my CPU fan but actually not by the KDE GUI (sorry, forgot to run top and do similar things). The 100% 'fan' load remained after unplugging the cable; as well as the connections shown by netstat. I would believe that it is not an attack by an US-service because usually with similar incidents no such connection list is returned by netstat. Perhaps anyone can be helpful with that? Elmar
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_operati...
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_operati...
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_operati...
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
Note that Firefox makes a good number of network requests whenever it starts, unless you have modified it not to do so. These include: Heartbeat https://wiki.mozilla.org/Advocacy/heartbeat Google's safe browsing, malware, and phishing protection https://www.privacytools.io/#about_config And various Akamai servers to check for add-on updates. That's all that I can remember off the top of my head, but do not expect Firefox to not make network requests simply because you have not navigated to any websites.
Thanks for the provided material and info, Jonathan; Unfortunately I can not prevent Firefox entirely from connecting to apparently random web addresses once I open it; not even with the settings (malware, phishing) you have recommended me to try; not even with disabling all addons. Three servers that were contacted while/upon an about:blank invocation:
nslookup 178.255.83.1 1.83.255.178.in-addr.arpa name = ocsp.comodoca.com.
nslookup 194.187.168.99 ** server can't find 99.168.187.194.in-addr.arpa: NXDOMAIN
nslookup 194.187.168.106 ** server can't find 106.168.187.194.in-addr.arpa: NXDOMAIN
Annoying; isn`t it? I`d simply wish a more trustworthy OSS browser. In the meanwhile I have also tried to find about the servers in the 100% CPU load netstat list; however I could not find much useful information except two of the servers being Arch mirrors. I would have believed the phising and malware protection services to be publicly known mirrors, Google services or anything similar. I mean it must not connect to any unknown service randomly.
for i in 5.196.185.225 92.92.207.51 195.154.59.140 178.63.62.19 52.32.86.111 46.4.37.89; do nslookup $i 2>&1; done | grep name 225.185.196.5.in-addr.arpa name = arch.tamcore.eu. (French arch mirror, likely a relict of installing cups related software before using Firefox) 51.207.92.92.in-addr.arpa name = 51.207.92.92.rev.sfr.net. (no direct web search results, except for the term SFR) 140.59.154.195.in-addr.arpa name = ns1.polymorf.fr. (polymorf.fr hosts some web pages about FreeBSD, never visited**) 19.62.63.178.in-addr.arpa name = pseudoform.org. (German arch mirror, likely a relict of installing cups) 111.86.32.52.in-addr.arpa name = ec2-52-32-86-111.us-west-2.compute.amazonaws.com. (Firefox can not access this site*) 89.37.4.46.in-addr.arpa name = web.pluto.js-webcoding.de. (no web searching results on this address)
* similar site: Info ec2-50-18-20-244.us-west-1.compute.amazonaws.com Alexa Rank: 154 Title: ec2-50-18-20-244.us-west-1.compute.amazonaws.com Description: ec2-50-18-20-244.us-west-1.compute.amazonaws.com visitors, seo, traffic and competition. Website located in United States. Hosted in Seattle. With ip 50.18.20.244. World rank is 154. Visits per day: 1,575,330 Daily Ads Revenue: $18,888.6 Creation Date: No info Domain Age: N/A Ip: 50.18.20.244 Last update: 10-02-2013 00:55:59 (2 years ago) ** according to http://urlmetriques.co/www.polymorf.fr SFR (an orphan acronym of Société française du radiotéléphone [4]) is a French telecommunications company that provides voice, video, data, and Internet ... (my internet connection starts at the "3" (drei) provider for Austria) Am 2015-12-04 um 20:10 schrieb Jonathan Roemer:
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
Note that Firefox makes a good number of network requests whenever it starts, unless you have modified it not to do so. These include:
Heartbeat https://wiki.mozilla.org/Advocacy/heartbeat
Google's safe browsing, malware, and phishing protection https://www.privacytools.io/#about_config
And various Akamai servers to check for add-on updates.
That's all that I can remember off the top of my head, but do not expect Firefox to not make network requests simply because you have not navigated to any websites.
On 12/04/2015 10:58 PM, Elmar Stellnberger wrote:
Unfortunately I can not prevent Firefox entirely from connecting to apparently random web addresses once I open it; not even with the settings (malware, phishing) you have recommended me to try; not even with disabling all addons. Three servers that were contacted while/upon an about:blank invocation:
Are you sure those connections come from Firefox? Some IPs are Arch mirrors, it could be established by pacman or another Arch package manager.
nslookup 178.255.83.1 1.83.255.178.in-addr.arpa name = ocsp.comodoca.com.
This is an OCSP server, to check whether a X.509 (SSL/TLS) certificate has been revoked.
nslookup 194.187.168.99 nslookup 194.187.168.106
This range belongs to qwant, a search engine. It could simply be firefox looking to refresh the search engines information.
Annoying; isn`t it? I`d simply wish a more trustworthy OSS browser.
The thing is, you need to understand that a lot of connections are made to do very simple things like opening a single HTTPS page. DNS queries, check for browsers update, OCSP checks, CRLs fetching, anti-phishing / malwares blacklist updates, and so on.. I am not saying you should not be looking what is done by your browser, that's certainly good to keep an eye on it, but it will be time consuming :) Don't forget resource pre-fetching, bookmarks update.. I would advise you to use a fresh firefox profile to minimize false positives.
ok; fine to know Remi; then there was already everything good with the configuration Jonathan had recommended me! (Qwant will have been there because of the search machine status bar) However what I would find really interesting are the remaining servers that there was a connection to when the '100% CPU fan' bug hit my machine. I really did nothing at all when it heated up that much; - and the desktop search should not have caused that, I would at least believe. Elmar P.S.: By the way which name server did you use for reverse lookup, Remi? 208.67.222.222 (OpenDNS server) did not do that for me in case of the Qwant search engine; even sites like ping.eu do not succeed in the reverse lookup of the 194.187.168.xx addresses. Am 2015-12-04 um 21:32 schrieb Remi Gacogne:
On 12/04/2015 10:58 PM, Elmar Stellnberger wrote:
Unfortunately I can not prevent Firefox entirely from connecting to apparently random web addresses once I open it; not even with the settings (malware, phishing) you have recommended me to try; not even with disabling all addons. Three servers that were contacted while/upon an about:blank invocation:
Are you sure those connections come from Firefox? Some IPs are Arch mirrors, it could be established by pacman or another Arch package manager.
nslookup 178.255.83.1 1.83.255.178.in-addr.arpa name = ocsp.comodoca.com.
This is an OCSP server, to check whether a X.509 (SSL/TLS) certificate has been revoked.
nslookup 194.187.168.99 nslookup 194.187.168.106
This range belongs to qwant, a search engine. It could simply be firefox looking to refresh the search engines information.
Annoying; isn`t it? I`d simply wish a more trustworthy OSS browser.
The thing is, you need to understand that a lot of connections are made to do very simple things like opening a single HTTPS page. DNS queries, check for browsers update, OCSP checks, CRLs fetching, anti-phishing / malwares blacklist updates, and so on.. I am not saying you should not be looking what is done by your browser, that's certainly good to keep an eye on it, but it will be time consuming :) Don't forget resource pre-fetching, bookmarks update.. I would advise you to use a fresh firefox profile to minimize false positives.
You can figure out who owns IP addresses using `whois`. I assume that's what was used. CPU fan speed is a bad measure of CPU usage; try `top`, `htop`, etc. If you value privacy, you should consider using your own recursive resolver. On 12/04/2015 05:46 PM, Elmar Stellnberger wrote:
ok; fine to know Remi; then there was already everything good with the configuration Jonathan had recommended me! (Qwant will have been there because of the search machine status bar)
However what I would find really interesting are the remaining servers that there was a connection to when the '100% CPU fan' bug hit my machine. I really did nothing at all when it heated up that much; - and the desktop search should not have caused that, I would at least believe.
Elmar
P.S.: By the way which name server did you use for reverse lookup, Remi? 208.67.222.222 (OpenDNS server) did not do that for me in case of the Qwant search engine; even sites like ping.eu do not succeed in the reverse lookup of the 194.187.168.xx addresses.
Whois; why have I not thought about it at once! ---- 92.92.207.51 --- inetnum: 92.92.0.0 - 92.95.255.255 netname: SFR-USER-DATA descr: Pool for mobile data users descr: Dynamic IP country: FR ---- 195.154.59.140 ---- inetnum: 195.154.48.0 - 195.154.63.255 netname: ISDNET-4 descr: Tiscali France Backbone country: FR ---- 52.32.86.111 ---- NetRange: 52.32.0.0 - 52.63.255.255 CIDR: 52.32.0.0/11 NetName: AT-88-Z NetHandle: NET-52-32-0-0-1 Parent: NET52 (NET-52-0-0-0-0) NetType: Direct Allocation OriginAS: Organization: Amazon Technologies Inc. (AT-88-Z) ---- 46.4.37.89 ---- inetnum: 46.4.37.64 - 46.4.37.127 netname: HETZNER-RZ13 descr: Hetzner Online AG descr: Datacenter 13 country: DE So from my point there is still something to be said: * What malware prevention service would connect to the IP of a !!mobile device??!! - none! * What has Amazon Technologies Inc. to do with all of that? - nothing! * sometimes the kraken can also sit in a datacenter or a backbone and this is known -> I had just opened the page of the router in my LAN and nothing else. Last but not least the most unerring sign that something went wrong was in my mind the enduringly long and high CPU fan load (though it is a pity that I did not have a closer look at least by system utilities). It NEVER occurs with a Xi3650 unless it is put under 100% CPU load for pretty much time! Sincerely, Elmar Am 2015-12-04 um 21:59 schrieb mal:
You can figure out who owns IP addresses using `whois`. I assume that's what was used.
CPU fan speed is a bad measure of CPU usage; try `top`, `htop`, etc.
If you value privacy, you should consider using your own recursive resolver.
On 12/04/2015 05:46 PM, Elmar Stellnberger wrote:
ok; fine to know Remi; then there was already everything good with the configuration Jonathan had recommended me! (Qwant will have been there because of the search machine status bar)
However what I would find really interesting are the remaining servers that there was a connection to when the '100% CPU fan' bug hit my machine. I really did nothing at all when it heated up that much; - and the desktop search should not have caused that, I would at least believe.
Elmar
P.S.: By the way which name server did you use for reverse lookup, Remi? 208.67.222.222 (OpenDNS server) did not do that for me in case of the Qwant search engine; even sites like ping.eu do not succeed in the reverse lookup of the 194.187.168.xx addresses.
On 12/05/2015 12:26 AM, Elmar Stellnberger wrote:
[...]
Is it possible, that your mailserver has some time issues? On my machine, it is currently 2015-12-04, 21:52:05 UTC. My timezone is UTC+1, so 2015-12-05, 12:26 is definitely in the future. There are two other such mails: - today, 21:58 UTC - today, 22:46 UTC Or is my mailserver or client somehow responsible for this strange time discrepancy? It is shown by both Icedove and Mutt.
* What malware prevention service would connect to the IP of a !!mobile device??!! - none!
You are assuming that this whois lookup is reliable, which it very frequently is not. IP space is bought and sold all the time, and whois data may not be updated to reflect this.
* What has Amazon Technologies Inc. to do with all of that? - nothing!
AWS
I had just opened the page of the router in my LAN and nothing else.
enduringly long and high CPU fan load
There is absolutely no basis for your conclusion that these two things are related. You need real troubleshooting information here. As mentioned by myself and others, Firefox, and possibly other applications, may be making these connections as well. All of those suggested tiles, favicons, OCSP responder servers, and other resources have to be loaded from somewhere, and these are opt-out within Firefox, not opt-in.
On 04.12.2015 23:31, Jonathan Roemer wrote:
* What malware prevention service would connect to the IP of a !!mobile device??!! - none!
You are assuming that this whois lookup is reliable, which it very frequently is not. IP space is bought and sold all the time, and whois data may not be updated to reflect this.
A wrong entry in whois? According to my knowledge there should not be any 'wrong' entries in whois as every IP/domain is associated with a timespan and a real world address which is tested to be valid by the domain registrar; f.i. the whois data I provide for my own domain elstel.org was checked from time to time; stating wrong data would lead to the withdrawal of my domain. Can you show me any current and valid examples of wrong/outdated whois entries *?
* What has Amazon Technologies Inc. to do with all of that? - nothing!
AWS
Wikipedia: In 2013 it became public knowledge that AWS (Amazon Web Services) has received a big work order directly from the CIA. I do not want to be overduely paranoid but this does not appear to be one of the most trustworthy places in the net.
As mentioned by myself and others, Firefox, and possibly other applications, may be making these connections as well. All of those suggested tiles, favicons, OCSP responder servers, and other resources have to be loaded from somewhere, and these are opt-out within Firefox, not opt-in.
be it as it is; I can not examine every incident in detail; nonetheless I know that from previous incidents that unnatural high and long CPU load can point to intrusions. * I will have to confess that it would be possible to state a wrong address for the whois records without anyone obtaining knowledge about that soon. Nonetheless such an incident would even more point to some abnormal/ illegeal activity. Likely registrars do not have sufficient rights or access to citizen data in order to verify each entry. more important: IP and domains are regularely reassigned and transferred but then so immediately is the whois data on completion of such transfers; otherwise your resources are still 'in transfer' which means that there is no way to access / get hold of them.
Hello Elmar, Sorry when I sound offensive but I really think that everything possible has been said. This mailinglist has a daily-business todo and was not designed for discussions. Please use the official archlinux forum[1], the archlinux-general mailinglist[2] or one of the archlinux channels in freenode[3] for it. Furthermore I think that the problem is maybe more netstat or firefox specific. Maybe you ask the developers of both tools as well. This mailinglist's main task is to inform subscribers about newest vulnerabilities. Please do not reply on this mail. So we can get back to our daily business. I hope you can understand my complaint. There are a lot better channels to discuss this stuff. Thank you very much and best regards, Chris [1] bbs.archlinux.org [2] arch-general@archlinux.org [3] irc.freenode.org (#archlinux,#archlinux-security)
On 5 December 2015 at 14:01, Christian Rebischke <Chris.Rebischke@archlinux.org> wrote:
This mailinglist has a daily-business todo and was not designed for discussions. [...]
The list name however says "Discussion about security issues in Arch Linux and its packages". That being said, I understand what you mean and agree with it.
[...] This mailinglist's main task is to inform subscribers about newest vulnerabilities.
So, could perhaps the list be split into two: one list for security-related discussions and one---moderated or even "read-only"---strictly for security announcements? For example, FreeBSD has these: freebsd-security: Security issues [members-only posting] freebsd-security-notifications: Moderated Security Notifications [moderated, low volume] The rationale is probably obvious. On one hand, people indeed expect a list used for security announcements to be used _only_ for this. Some might, for example, have set filters that mark such messages as urgent, display nagging pop ups, etc. On the other hand, the plain old e-mail still has value as a media for discussions. For example, it's not very practical to digitally sign forum postings, and IRC is a wholly different type of communication that might not always be appropriate. Cheers, Luchesar P.S. Slightly off-topic: my sincerest gratitude to everyone behind the security announcements! You're doing a great job, and this is not just empty words.
On 12/05/2015 10:32 AM, Elmar Stellnberger wrote:
* What has Amazon Technologies Inc. to do with all of that? - nothing!
AWS
Wikipedia: In 2013 it became public knowledge that AWS (Amazon Web Services) has received a big work order directly from the CIA. I do not want to be overduely paranoid but this does not appear to be one of the most trustworthy places in the net.
If you're not ok with connecting to AWS you will have a hard time surfing the modern web ... Vänligen, Aron Widforss
On Fri, Dec 04, 2015 at 08:55:21PM +0100, Elmar Stellnberger wrote:
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)?
I think, sockets in TIME_WAIT state exist by default about 4min (by the standard), but I not really sure. Read /usr/lib/modules/4.3.0-1-ARCH/build/Documentation/networking/ip-sysctl.txt for parameters that control this behavior (install linux-docs package). But I'd say just get over this "issue". About Firefox opening connection, look at browser.newtabpage.directory.* keys in about:config that contain a set of addresses that FF checks by default on startup to enable that live-tile new tab experience. I'm sure there are other controls there...
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?
No.
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?
There are tons of reasons why FF or KDE can cause high CPu usage and FAN activity, but non of them are security-related... HTH, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
participants (9)
-
Aron Widforss
-
Christian Rebischke
-
Elmar Stellnberger
-
Jonathan Roemer
-
Leonid Isaev
-
Luchesar V. ILIEV
-
mal
-
Remi Gacogne
-
respiranto