-
Notifications
You must be signed in to change notification settings - Fork 111
Description
Is this a security vulnerability?
No
Issue
While debugging into a different problem on Gorouter, we stumbled over seemingly random messages like these:
read tcp 127.0.0.1:26057->127.0.0.1:19244: read: connection reset by peer
as we were digging further we concluded that gorouter would talk to itself on a random port that it uses for re-injecting route service requests into itself, i.e. accept client request -> look up target route -> realize there is a route service for that route -> send a new request to self where the target URL replaced with route service URL
We find it to be very confusing in the logs that gorouter uses a random local port and would like to suggest to use a well-defined port instead.
Affected Versions
All
Context
The random port is selected in the RouteServicesServer where it is then stored in the RouteServiceRoundTripper for future round trips.
Steps to Reproduce
- Push an app
- Push a custom route service
- Register the route service for the app's route
- Curl the app's URL
- Log on to gorouter
- Run
netstat -pant | grep 127
Expected result
There should be a connection from 127.0.0.1:< random port > to 127.0.0.1:< well-defined port >
Current result
There is a connection from 127.0.0.1:< random port > to 127.0.0.1:< random other port >
Possible Fix
- We should agree on a port (e.g. 7070)
- The port should not clash with random local ports (i.e. outside gorouter's local port range, similar to 8080)
- BTW the default port range is actually 1024-65535 which is potentially dangerous as it allows port 8080 to be used which clashes with the health check port. We may consider using
net.ipv4.ip_local_reserved_portsto protect those ports from being used by Linux. - The port should be present as a constant in gorouter code and documented wherever necessary
Additional Context
If there are strong reasons why the port must be random, please let me know in the discussion of this issue.