Does anybody here get the same ICMP request in their firewall log?
It’s funny because it looks like a reverse DNS IP. And it probably traveled to 3 firewalls, first the CGNAT from Vodafone, then through the Vodafone Station (Does it have an IPv4 firewall when using DS Lite?) and finally to IPFire.
But isn’t there something wrong as multicasts should only be routed in a private network and not a public network?
Do you have Reject rules instead of drop? Those should generate an ICMP response I guess.
EDIT: I did NOT notice you mentioning a multicast. Yes, you are right 224.0.0.1 is not a public address as it falls under the multicast address space (224.0.0.0 to 239.255.255.255), which is used for multicast traffic on local networks and is not routable on the public internet. Within a LAN, it is used to send packets to all devices on the local network segment that are listening to this multicast group address. It is typically utilized by various protocols and services to efficiently send data to multiple recipients over a LAN.
So, my hypothesis is clearly wrong as ICMP messages generated as a response to rejected packets are usually directed back to the sender’s IP address, not to a multicast address like 224.0.0.1. Furthermore I though the source was from your network but 10.0.168.192 is not a private IP. My brain did a double short circuit here.
The Whois lookup shows that the IP address “1.0.168.192” belongs to a range allocated to the “TOT Public Company Limited” in Thailand. This range of IP addresses is designated for dynamic allocation to residential broadband customers. Here’s a breakdown of the significant details:
The IP address is part of a non-portable assignment, meaning it is specifically assigned to TOT’s infrastructure and cannot be transferred to another organization.
Given this information, the IP address “1.0.168.192” is a public IP address (not a private/local IP) assigned dynamically to a residential customer of the TOT service in Thailand.
How did it get to your Vodafone broadcast address?
I just did a traceroute, it traveled a long way:
C:\Windows\System32>tracert 1.0.191.255
Routenverfolgung zu node-cn3.pool-1-0.dynamic.totinternet.net [1.0.191.255]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms ipfire.localdomain [192.168.7.1]
2 2 ms 1 ms 1 ms 192.168.0.1
3 30 ms 20 ms 19 ms ip-081-210-178-120.um21.pools.vodafone-ip.de [81.210.178.120]
4 12 ms 14 ms 10 ms de-dar01a-rd04-ae-0-0.aorta.net [84.116.197.6]
5 52 ms 39 ms 22 ms de-fra04d-rc1-ae-18-0.aorta.net [84.116.197.10]
6 12 ms 9 ms 10 ms 84.116.190.94
7 12 ms 10 ms 11 ms sl-crs1-fra-0-6-3-0.sprintlink.net [80.81.192.121]
8 14 ms 10 ms 13 ms sl-mpe70-fra-be2.sprintlink.net [217.147.96.68]
9 22 ms 21 ms 20 ms sl-mpe70-par-hu0-1-0-1.sprintlink.net [213.206.129.25]
10 98 ms 98 ms 98 ms sl-mst70-ash2-be4146-1000.sprintlink.net [144.232.9.111]
11 102 ms 103 ms 102 ms sl-crs2-dc-be16.sprintlink.net [144.232.3.75]
12 121 ms 119 ms 120 ms sl-crs2-nsh-be7.sprintlink.net [144.232.15.19]
13 134 ms 127 ms 127 ms sl-crs2-kc-be8.sprintlink.net [144.232.22.204]
14 125 ms 127 ms 128 ms sl-crs2-oma-be2.sprintlink.net [144.232.10.207]
15 157 ms 160 ms 159 ms sl-crs2-oro-be7.sprintlink.net [144.232.15.167]
16 163 ms 167 ms 159 ms sl-crs2-stk-be2.sprintlink.net [144.232.15.239]
17 164 ms 159 ms 159 ms sl-crs2-sj-be3.sprintlink.net [144.232.22.178]
18 159 ms 161 ms 159 ms sl-mst51-pa-ae14-0.sprintlink.net [144.232.17.65]
19 162 ms 161 ms 170 ms 144.223.171.98
20 316 ms 316 ms 316 ms 112.174.89.150
21 258 ms 256 ms 257 ms 121.189.2.94
22 271 ms 269 ms 269 ms 61.19.9.121
23 284 ms 286 ms 283 ms 61.19.14.226
24 275 ms 274 ms 274 ms 122.155.232.42
25 273 ms 274 ms 273 ms 203.113.59.129
26 274 ms 275 ms 273 ms 203.113.61.94
27 * * * Zeitüberschreitung der Anforderung.
28 * * * Zeitüberschreitung der Anforderung.
29 * * * Zeitüberschreitung der Anforderung.
30 * * * Zeitüberschreitung der Anforderung.
Ablaufverfolgung beendet.
C:\Windows\System32>tracert 1.0.168.192
Routenverfolgung zu node-81s.pool-1-0.dynamic.totinternet.net [1.0.168.192]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms ipfire.localdomain [192.168.7.1]
2 2 ms 2 ms 1 ms 192.168.0.1
3 12 ms 9 ms 10 ms ip-081-210-178-120.um21.pools.vodafone-ip.de [81.210.178.120]
4 19 ms 21 ms 11 ms de-dar01a-rd04-ae-0-0.aorta.net [84.116.197.6]
5 11 ms 13 ms 10 ms de-fra04d-rc1-ae-18-0.aorta.net [84.116.197.10]
6 11 ms 12 ms 12 ms de-fra04c-ri1-ae15-101.aorta.net [84.116.191.6]
7 11 ms 11 ms 12 ms e0-32.core2.fra1.he.net [184.104.231.45]
8 * * * Zeitüberschreitung der Anforderung.
9 18 ms * * port-channel2.core3.fra2.he.net [72.52.92.70]
10 * * * Zeitüberschreitung der Anforderung.
11 * 302 ms * port-channel6.core2.sin1.he.net [184.105.222.10]
12 163 ms 159 ms 158 ms pacific-internet-pte-ltd.e0-2.switch5.sin1.he.net [74.82.50.54]
13 * * * Zeitüberschreitung der Anforderung.
14 * * * Zeitüberschreitung der Anforderung.
15 193 ms 190 ms 191 ms in-addr.net [180.180.255.96]
16 185 ms 188 ms 186 ms in-addr.net [203.190.251.159]
17 189 ms 184 ms 185 ms 203.113.59.131
18 190 ms 187 ms 186 ms node-16zm.pool-125-24.dynamic.totinternet.net [125.24.217.162]
19 201 ms 200 ms 202 ms 203.113.44.214
20 * * * Zeitüberschreitung der Anforderung.
21 205 ms 205 ms 202 ms node-81s.pool-1-0.dynamic.totinternet.net [1.0.168.192]
Ablaufverfolgung beendet.
Is it possible that the Thai provider is experiencing a DDoS attack facilitated through an NTP amplification tactic? In this scenario, attackers could be using spoofed packets with the source IP set as 1.0.168.192 targeting NTP servers, which then inadvertently multicast ICMP responses throughout the network.
I doubt it, I get the request since IPFire is running beginning of August.
Some information about the company: TOT Public Company Limited - Wikipedia
Either the multicast was really routed through all these routers or somebody in between faked the source address.
But they also faked the Reverse DNS domain “in-addr.arpa” and the IPs belong to TOT:
in-addr.net [203.190.251.159]
in-addr.net [180.180.255.96]
Maybe I am missing (again) your sound reasoning. If an attacker spoofed the SRC IP address using 1.0.168.192, both forward and reverse DNS lookup should be aligned because they would be created by TOT. Would it not?
Any updates? Because I have the same problem, Vodafone internet provider and requests from 1.0.168.192 over icmp on NT Kernel & System.
Smells like RARP. I mean… it’s 192.168.0.1 reversed.