Bug #5838
closed
Diagnostics-->Traceroute can cause DoS on web console
0%
Description
Running a traceroute with an IP address will cause a DoS on the web console, and is then no longer accessible. Internet browsing continues to work.
I know a user is not supposed to do this, but some input validation should be put in place to mitigate this possible issue. SSH'ing into firewall and rebooting resolves the issue.
Steps to reproduce:
1. Diagnostics-->Traceroute
2. Put an IP address in hostname box and click Traceroute button
3. Web admin console will become unresponsive and unrecoverable until a reboot (from my testing)
Updated by Marco Novielli almost 10 years ago
Sorry, traceroute definitely works with IP address. Got confused with DNS lookup for a second.
I had 18 selected for maximum number of hops and when I did a traceroute of an IP address it took forever, and made the web console unresponsive. So although my original description may not be accurate this could still cause an issue. You should be able to cancel the traceroute, and not have it hang up the web console until it is complete I will do a bit more testing once I do more testing.
Updated by Marco Novielli almost 10 years ago
Just reread my last sentence - I think I need some rest.
Either way, I can definitely reproduce the issue. Steps to reproduce:
1. Diagnostics-->Traceroute
2. Enter an unused IP address within your subnet into the hostname box and click Traceroute button
3. Web admin console will become unresponsive for a few minutes but seems to recover after nginx throws an error.
Updated by Marco Novielli almost 10 years ago
Having a high number of hops such as 18 is also key to seeing the issue.
Eventually, NGINX error comes up with "504 Gateway Time-out". Then a minute later, the web console recovers.
Interestingly, ping does not cause this issue and you can easily navigate to another menu, I assume cancelling the ping process. I wonder if the same can apply to traceroute.
Updated by Chris Buechler almost 10 years ago
- Status changed from New to Not a Bug
- Target version deleted (
2.3)
subject issue doesn't exist as claimed. You can find long-running traceroute commands, like trying to traceroute to a local IP that doesn't exist with 18 hops (why would you ever want to traceroute to something local anyway..much less with 18 hops). When that times out, a minute or two later, it responds again.
I bumped the fastcgi timeout in nginx to be comparable to 2.2.x and earlier versions, so it doesn't give you a 504 unless it's > 180 seconds.