You are not logged in.
wireshark and ss -tunarp told me that my machine has been connecting to http://92k.de and https://92k.de - the purpose of that tcp-connection remains unclear.
sudo watch ss -tunarp
usually shows which process (including pid) is making the connection, but is sparing this information when it comes to the peer address 92k.de.
I blocked the traffic with iptables for now.
However, I'd like to get to the bottom of this.
Last edited by klapauzius (2019-09-22 10:34:36)
Offline
Well, after blocking TCP traffic to this domain, several daemons try to reach it via UDP now.
edit: sorry, that's bullshit, I put 92k.de in /etc/hosts and let it point to 0.0.0.0, therefore
ss -tunaRp
resolved 0.0.0.0 as 92k.de, so I erased the entry since IPTABLES should do the trick...
Last edited by klapauzius (2019-09-22 10:02:12)
Offline
Hetzner Online GmbH, serverfarm.
Nmap scan report for 92k.de (95.216.99.37)
Host is up (0.048s latency).
Other addresses for 92k.de (not scanned): 2a01:4f9:2b:1245::2
Not shown: 991 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
135/tcp filtered msrpc
139/tcp filtered netbios-ssn
443/tcp open https
445/tcp filtered microsoft-ds
873/tcp open rsync
4000/tcp open remoteanything
9001/tcp open tor-orport
Offline
nope, my machine is trying to reach port 80 and port 443
after blocking the IP of 92k.de, PACMAN can't reach the archmirrors anymore. 92k.de is not an arch-mirror, at least not in my mirror-files...
btw, tor.service is disabled and not running on my machine
REFLECTOR reaches the archmirrors, though
Last edited by klapauzius (2019-09-22 09:43:02)
Offline
ok, updated the mirrorlist, pacman works again
Offline
solved it myself, sorry for molesting the community, and thanks to seth for the hint...
92k.de is a FQDN pointing to the same IP where an arch-mirror is hosted, It's contacted by an update-script on my machine every 10 seconds. I have changed the intervall to 30 minutes now.
watch 'ss -tunarp'
doesn't show which process is doing that, because it usually picks up the connection in TIME-WAIT state.
Further reading for those who like to
https://serverfault.com/questions/23385 … ys-netstat
https://vincent.bernat.ch/en/blog/2014- … tate-linux
I have tried to catch the pid of the process opening the connection by
lsof | rg port-number
but due to the short-living nature of these connections this information obviously is lost in time and space forever.
Last edited by klapauzius (2019-09-22 11:11:55)
Offline