Honest:
If you do not know if your UCS is visible by public Internet you should shut it down and step back from configuring server services as long as you know what to do!
Helpful:
Do ip a sh. If you see a public IP your UCS is direclty attached. In this case go to 1.
I’m sorry I don’t understand English well and I didn’t understand your question.
Of course my server does not have a public IP address (its ip 192.168.0.43) it is connected to a box in router mode.
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether c8:1f:66:1f:90:db brd ff:ff:ff:ff:ff:ff
inet 192.168.0.43/24 brd 192.168.0.255 scope global dynamic enp2s0
valid_lft 43138sec preferred_lft 43138sec
inet6 2a01:e0a:31d:5dc0:ca1f:66ff:fe1f:90db/64 scope global dynamic mngtmpaddr
valid_lft 86070sec preferred_lft 86070sec
inet6 fe80::ca1f:66ff:fe1f:90db/64 scope link
valid_lft forever preferred_lft forever
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:8e:ec:b3:b4 brd ff:ff:ff:ff:ff:ff
inet 172.17.42.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
inet6 fe80::42:8eff:feec:b3b4/64 scope link
valid_lft forever preferred_lft forever
4: br-3c8ac50931f3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:9f:b3:08:ef brd ff:ff:ff:ff:ff:ff
inet 172.18.0.1/16 brd 172.18.255.255 scope global br-3c8ac50931f3
valid_lft forever preferred_lft forever
6: vetha0f314d@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
link/ether 4a:94:8b:cb:6e:c2 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::4894:8bff:fecb:6ec2/64 scope link
for arp
Adresse TypeMap AdresseMat Indicateurs Iface
192.168.0.1 ether b8:27:eb:a8:07:bd C enp2s0
192.168.0.4 ether 18:66:da:2e:9b:25 C enp2s0
192.168.0.5 (incomplete) enp2s0
172.17.0.1 ether 02:42:ac:11:00:01 C docker0
192.168.0.13 ether 9c:4e:36:7d:27:a4 C enp2s0
192.168.0.254 ether 70:fc:8f:68:19:48 C enp2s0
and nmap
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
53/tcp open domain
80/tcp open http
88/tcp open kerberos-sec
110/tcp open pop3
111/tcp open rpcbind
135/tcp open msrpc
139/tcp open netbios-ssn
143/tcp open imap
389/tcp open ldap
443/tcp open https
445/tcp open microsoft-ds
464/tcp open kpasswd5
465/tcp open smtps
587/tcp open submission
636/tcp open ldapssl
749/tcp open kerberos-adm
993/tcp open imaps
995/tcp open pop3s
2049/tcp open nfs
3268/tcp open globalcatLDAP
3269/tcp open globalcatLDAPssl
5432/tcp open postgresql
5666/tcp open nrpe
6669/tcp open irc
Nmap done: 1 IP address (1 host up) scanned in 59.56 seconds
If the log really indicates a client with a update request to your UCS it is an issue with your router!
Again, can you do a portsscan of your public IP adress to see which ports are open there? The ports you have posted should be open, but only locally.
Good luck!
[Edit] sometimes DNS servers send additional information to a requesting client (bind in your case). Perhaps you have configured unreliable nameservers? What does ucr dump| grep nameserv say?
ok thanks for your help, but it’s strange because I’ve been configured like this for years and apart from attempted connections on the ssh port I was spared.
My server is in a DMZ, I will take it out of there and redirect the ports one by one for ssh, http, https, smtp …
At least port 53 (DNS) is now filtered- so this was open. And I assume it should not.
But still looks like your DNS gets these packages.
Now it is getting a little bit more complicated. To see whatever sends to the DNS port which causes bind to show these messages I would you a packet filter. You should be good with tcpdump: tcpdump -i enp2s0 port 53
It might be a bunch of packages flowing in. You might need to filter them accordingly. You might write the output to a pcap-file and use Wireshark to read it later. Good luck!
Now it is your task to figure out why this happens. Might be a misconfiguration from your router. Or your PiHole. Or both.
See pihole related link about pizzaseo.
And they all say the same as I did initially: You have (or had) DNS visible to public. It might be forwarded to UCS or to PiHole. But both is bad. Might be your PiHole forwards it to UCS? I dunno.
There is not much I can do here for you- it is a simple configuration issue. It is not immediately related to UCS. Again: Check 1. in one of my above posts!