1

For a few days, we are getting the following logs on our firewall (Vigor2926ac, up-to-date firmware)

The traffic suggests that it comes from Google / Microsoft datacenters, but that's a bit odd that they are running port scans against us.

xxx.xxx.xxx.xxx was where our public IP address was listed, so we've cut it out of the logs.

Is this something that we should be concerned about? What can we do about it? Can we somehow find the real source IP where these requests are coming from and get them blocked?

We already have geofenced our IP with only certain countries that need access. So the major countries where this type of traffic comes from are already blocked.

It's not that they generate currently a lot of traffic, because we are able to work, but sometimes a VPN connection is dropped.

2023/04/25 17:57:29 -- [DOS][Block][port_scan][8.8.8.8:53->xxx.xxx.xxx.xxx:38699][UDP][HLen=20, TLen=237]
2023/04/25 17:57:34 -- [DOS][Block][port_scan][8.8.8.8:53->xxx.xxx.xxx.xxx:41072][UDP][HLen=20, TLen=237]
2023/04/25 17:57:40 -- [DOS][Block][port_scan][8.8.8.8:53->xxx.xxx.xxx.xxx:60870][UDP][HLen=20, TLen=237]
2023/04/25 17:57:45 -- [DOS][Block][port_scan][8.8.8.8:53->xxx.xxx.xxx.xxx:49476][UDP][HLen=20, TLen=237]
2023/04/25 17:57:52 -- [DOS][Block][port_scan][8.8.8.8:53->xxx.xxx.xxx.xxx:59071][UDP][HLen=20, TLen=268]
2023/04/25 17:58:00 -- [DOS][Block][port_scan][8.8.8.8:53->xxx.xxx.xxx.xxx:35807][UDP][HLen=20, TLen=237]
2023/04/25 17:58:15 -- [DOS][Block][port_scan][8.8.8.8:53->xxx.xxx.xxx.xxx:40567][UDP][HLen=20, TLen=237]
2023/04/25 17:58:30 -- [DOS][Block][port_scan][8.8.8.8:53->xxx.xxx.xxx.xxx:57154][UDP][HLen=20, TLen=237]
....
2023/04/25 20:43:12 -- [DOS][Block][port_scan][142.250.179.138:443->xxx.xxx.xxx.xxx:63552][UDP][HLen=20, TLen=1278]
2023/04/25 20:43:12 -- [DOS][Block][port_scan][142.250.179.138:443->xxx.xxx.xxx.xxx:63552][UDP][HLen=20, TLen=1278]
2023/04/25 20:43:14 -- [DOS][Block][port_scan][142.250.179.138:443->xxx.xxx.xxx.xxx:63552][UDP][HLen=20, TLen=1278]
2023/04/25 20:43:15 -- [DOS][Block][port_scan][142.250.179.138:443->xxx.xxx.xxx.xxx:63552][UDP][HLen=20, TLen=1278]
2023/04/25 20:43:15 -- [DOS][Block][port_scan][142.250.179.138:443->xxx.xxx.xxx.xxx:63042][UDP][HLen=20, TLen=1278]
2023/04/25 20:43:15 -- [DOS][Block][port_scan][142.250.179.138:443->xxx.xxx.xxx.xxx:63042][UDP][HLen=20, TLen=845]
2023/04/25 20:43:15 -- [DOS][Block][port_scan][142.250.179.138:443->xxx.xxx.xxx.xxx:63042][UDP][HLen=20, TLen=201]
2023/04/25 20:43:15 -- [DOS][Block][port_scan][142.250.179.138:443->xxx.xxx.xxx.xxx:63042][UDP][HLen=20, TLen=52]
....

2023/04/25 20:38:09 -- [DOS][Block][port_scan][195.130.130.3:53->xxx.xxx.xxx.xxx:33185][UDP][HLen=20, TLen=215]
2023/04/25 20:38:09 -- [DOS][Block][port_scan][195.130.130.3:53->xxx.xxx.xxx.xxx:54435][UDP][HLen=20, TLen=155]
2023/04/25 20:38:10 -- [DOS][Block][port_scan][195.130.130.3:53->xxx.xxx.xxx.xxx:60303][UDP][HLen=20, TLen=179]
2023/04/25 20:38:10 -- [DOS][Block][port_scan][8.8.8.8:53->xxx.xxx.xxx.xxx:60303][UDP][HLen=20, TLen=175]
2023/04/25 20:38:11 -- [DOS][Block][port_scan][195.130.130.3:53->xxx.xxx.xxx.xxx:60303][UDP][HLen=20, TLen=179]
2023/04/25 20:38:11 -- [DOS][Block][port_scan][195.130.130.3:53->xxx.xxx.xxx.xxx:33185][UDP][HLen=20, TLen=215]
2023/04/25 20:38:11 -- [DOS][Block][port_scan][8.8.8.8:53->xxx.xxx.xxx.xxx:33185][UDP][HLen=20, TLen=215]
2023/04/25 20:38:13 -- [DOS][Block][port_scan][195.130.130.3:53->xxx.xxx.xxx.xxx:60303][UDP][HLen=20, TLen=179]
Improve this question
3
  • There is no indication that the IP or domain is spoofed.
    – schroeder ♦
    Commented Apr 26, 2023 at 7:47
  • There is nothing you can do about stopping traffic that should normally be allowed. So, Prevention is not where you have control unless you find that you can tighten your firewall rules. You can ensure that you are Protected from the effects of such scans and be resilient to the fact that you are open to the Internet, and all that entails.
    – schroeder ♦
    Commented Apr 26, 2023 at 7:51
  • 1
    You say that the device is up-to-date, but it is now end-of-life and not receiving any new fixes: draytek.com/products/vigor2926/#models The last update was released in March, which is pretty recent, but you should consider replacing the hardware.
    – schroeder ♦
    Commented Apr 27, 2023 at 8:03

1 Answer 1

Reset to default
1

This is an incomplete answer, but:

It's possible that you sent traffic to those IP addresses, they responded, and then your firewall lied and said their responses were a "port scan" and blocked them.

If so, what you should do is try to stop blocking legitimate traffic and breaking your applications!

Port 53 is used by DNS. 8.8.8.8 is the popular Google Public DNS resolver (which you might have configured your devices to use, or Google applications/devices may be ignoring your network settings and using it anyway). Looking at its reverse DNS, 195.130.130.3 seems to be a resolver operated by Telenet.

Port 443 is used for HTTPS. Traditionally it always used TCP, but more recently it can use UDP with HTTP/3. 142.250.179.138 seems to be a Google IP in Amsterdam (IATA airport code "ams"). It's probably a web server for one of their websites (or many of their websites).

Maybe someone spoofed your IP and sent traffic to those IP addresses and your firewall correctly blocked it. Maybe you sent traffic to those IP addresses and your firewall incorrectly blocked it. Maybe it's a combination of the two!

There can be relatively good reasons for a connection-tracking firewall to block "real" traffic. If it just rebooted, it won't know about older connections. If it's overloaded, it might forget some connections. Firewalls eventually forget about idle connections. (And UDP doesn't even have actual connections, so it's inherently kind of a guess.)

I'm not sure what the next steps for investigating further are. You could figure out which of your devices/applications use those DNS servers. You could monitor your traffic and see if your DNS queries (and HTTP/3 sessions) match up with firewall log entries.

If your firewall is causing problems with DNS and HTTP/3, it could be causing problems with your VPN too, but without more information, that's layering speculation on top of speculation.

Improve this answer
1
  • 1
    The next step is to verify the logs to rule out false positives. And since this router is pretty basic, the chance that the classification rules are not tuned well is high.
    – schroeder ♦
    Commented Apr 27, 2023 at 8:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .