Daidai 3 Posted July 11, 2022 Share Posted July 11, 2022 (edited) My router has been hammering by an IP 0.0.0.0 and . Is there a way to escape from them, or find out who is behind this 0.0.0.0 ? Thanks in advance. Edited July 11, 2022 by Daidai Link to comment Share on other sites More sharing options...
Administrators Marcos 5,273 Posted July 11, 2022 Administrators Share Posted July 11, 2022 The address 0.0.0.0 is a non-routable meta-address used to designate an invalid, unknown or non-applicable target. Please be more specific as to what attacks you mean. Do you see attacks from 89.248.16.0/24 in your router's log? Link to comment Share on other sites More sharing options...
Daidai 3 Posted July 11, 2022 Author Share Posted July 11, 2022 No! please don't type the numbers, please use the picture I provided, I don't want to alert that IP owner and attack my router more! My router says is doing a TCP SYN flood hundreds of time per day! 0.0.0.0 is performing a fraggle attack to destination 255.255.255.255 at port 68. Link to comment Share on other sites More sharing options...
itman 1,748 Posted July 11, 2022 Share Posted July 11, 2022 (edited) Your "mixing apples and oranges" in this posting. You mention a fraggle attack. This attack is described as: Quote Fraggle A Fraggle attack is very similar to the Smurf attack, except that it uses the User Datagram Protocol (UDP) rather than the more common Transmission Control Protocol (TCP). It is less common than Smurf attacks. Both Fraggle and Smurf attacks, are starting to become outdated and are commonly stopped by most modern routers and firewalls. Fraggle attacks can usually be blocked by simply blocking ports 7 (Echo port) and port 19 (another commonly used Fraggle exploitable port) in your router/firewall. https://www.speedguide.net/articles/how-to-stop-denial-of-service-dos-attacks-3316 Additional ref. here: https://www.okta.com/identity-101/fraggle-attack/ Next, you mention a TCP sync flood attack but reference port 68. Ports 67,68 are only used by IPv4 DHCP initialization processing using the UDP protocol. Therefore, a TCP sync flood attack against port 68 would be highly doubtful. Assuming you are using an ISP provided router/gateway, do a hard reset of it which will reset it back to ISP initialized values. If the router/gateway admin GUI interface is not password protected, create a strong password for it. Note that many routers/gateways use a default password of admin which is easily guessed by an external based hacker. Otherwise, change the existing password to another new strong password. As far as what a strong password is: Quote CHARACTERISTICS OF STRONG PASSWORDS At least 12 characters - the more characters, the better A mixture of both uppercase and lowercase letters A mixture of letters and numbers Inclusion of at least one special character, e.g., ! @ # ? ] Note: do not use < or > in your password, as both can cause problems in Web browsers However, use of < or > is acceptable for a router/gateway password. Also, avoid using your resident city name, birth date, etc. as part of the password. The more random the characters used, the stronger the password. An example of a strong router/gateway password: >B3gB!<^RZ$WJ-gF Edited July 11, 2022 by itman Link to comment Share on other sites More sharing options...
Daidai 3 Posted July 11, 2022 Author Share Posted July 11, 2022 Sorry for the confusion, 1. is doing a TCP SYN flood at random ports. 2. 0.0.0.0 is doing a fraggle attack to destination 255.255.255.255 at port 68. (I just type what the router tells) 3. I did reset the router, changed default adminstration login password. I am confident it is a strong password. Link to comment Share on other sites More sharing options...
Daidai 3 Posted July 11, 2022 Author Share Posted July 11, 2022 (edited) I forgot to ask, how come the attacker's address is 0.0.0.0 ? Please help, I don't want my network got breached again. Edited July 11, 2022 by Daidai Link to comment Share on other sites More sharing options...
itman 1,748 Posted July 11, 2022 Share Posted July 11, 2022 (edited) 31 minutes ago, Daidai said: I forgot to ask, how come the attacker's address is 0.0.0.0 ? Quote On Client Computers PCs and other client devices normally show an address of 0.0.0.0 when not connected to a TCP/IP network. A device might give itself this address by default whenever it is offline. It might also be automatically assigned by DHCP in the case of address assignment failures. When set with this address, a device cannot communicate with any other devices on that network. 0.0.0.0 can also theoretically be set as a device's subnet mask rather than its IP address. However, a subnet mask with this value has no practical purpose. Both the IP address and network mask are typically assigned 0.0.0.0 on a client. Depending on the way it's used, firewall or router software might use 0.0.0.0 to indicate that every IP address should be blocked (or allowed). https://www.lifewire.com/four-zero-ip-address-818384 Since you reference port 68, it appears what I underlined above is applicable in your case. Not out of consideration here is there might be a hardware or firmware issue with your router. Edited July 11, 2022 by itman Link to comment Share on other sites More sharing options...
itman 1,748 Posted July 11, 2022 Share Posted July 11, 2022 (edited) 5 hours ago, Daidai said: 0.0.0.0 is doing a fraggle attack to destination 255.255.255.255 at port 68. (I just type what the router tells) Note that the above would be valid if the destination port was 67; refer to the following: Quote When the lease expires and the client still cannot reach the DHCP server by unicast, the DHCP client will unconfigure the current IP address, and then will start the DHCP request process from the beginning, using broadcasts so the packets will be addressed 0.0.0.0:68 -> 255.255.255.255:67 Next, note the following: Quote Almost any dhcp traffic from or to external sources can be considered highly suspicious and likely represents an attack.Action: Firewall port 68 inbound and outbound where possible. DHCP traffic should not go beyond subnets, unless a dhcp relay is in use and then only the DHCP relay's traffic should be allowed. Most clients send DHCP requests as from the IP address 255.255.255.255 to the address 0.0.0.0 (in most cases they do not have an IP address currently). https://kb.eventtracker.com/evtpass/evtPages/PortNo_68_bootpclient_56538.asp I can't help but think this is related to your obsession in blocking Eset connections to Google DNS servers and changes you made to Eset default firewall rules to accomplish this. Edited July 11, 2022 by itman Link to comment Share on other sites More sharing options...
ESET Insiders cutting_edgetech 25 Posted July 12, 2022 ESET Insiders Share Posted July 12, 2022 When using proxies it is possible to spoof the last address that is forwarded to the destination IP address. They could be spoofing the last address so that it shows 0.0.0.0. It helps mask the attacker's exit node, making it more difficult to block the attacker's address. It still may be possible to see the attackers exit node address with a good packet sniffer like Wireshark. Link to comment Share on other sites More sharing options...
Daidai 3 Posted July 12, 2022 Author Share Posted July 12, 2022 8 hours ago, cutting_edgetech said: When using proxies it is possible to spoof the last address that is forwarded to the destination IP address. They could be spoofing the last address so that it shows 0.0.0.0. It helps mask the attacker's exit node, making it more difficult to block the attacker's address. It still may be possible to see the attackers exit node address with a good packet sniffer like Wireshark. Thanks, I will try and see. Link to comment Share on other sites More sharing options...
Daidai 3 Posted July 12, 2022 Author Share Posted July 12, 2022 11 hours ago, itman said: Note that the above would be valid if the destination port was 67; refer to the following: Next, note the following: https://kb.eventtracker.com/evtpass/evtPages/PortNo_68_bootpclient_56538.asp I can't help but think this is related to your obsession in blocking Eset connections to Google DNS servers and changes you made to Eset default firewall rules to accomplish this. This happens even no device is connected to the router, so it is not related to ESET firewall. Link to comment Share on other sites More sharing options...
itman 1,748 Posted July 12, 2022 Share Posted July 12, 2022 16 hours ago, itman said: 0.0.0.0 is doing a fraggle attack to destination 255.255.255.255 at port 68. (I just type what the router tells) Every instance I found of this activity on the Internet resolved to being a false positive caused by the user's ISP. Contact your ISP about this activity. Link to comment Share on other sites More sharing options...
Recommended Posts