search

rickparrish / fTelnet

fTelnet: An HTML5 WebSocket client
GNU Affero General Public License v3.0
70 stars 38 forks source link

Recording the correct IP Address #3

Closed ptaylor2 closed 6 years ago

ptaylor2 commented 8 years ago

When the client is connecting to the my ftelnet proxy server is recording the incorrect client IP Address. Ftelnet is recording my static IP Address and not recording the real Client IP Address.

Is there any way to correct this issue?

rickparrish commented 8 years ago

I'm not 100% sure what you're saying, but I'm guessing you have fTelnet connecting to your own instance of fTelnetProxy, and then fTelnetProxy connecting to your BBS. And in your BBS log files you're seeing your own IP address instead of the IP address of the user who is connecting.

If that's right, then that's expected behaviour. The user connects to fTelnetProxy, which will see the user's real IP address. But then fTelnetProxy connects to your BBS, so that's why your BBS sees your own IP address.

I'm not a networking expert, but I don't believe there is any way around that. The best you can do is use something like I implemented in my last commit, where the BBS can send the telnet command "DO SEND-LOCATION" (not literally that text), and then fTelnet will reply back with the client's IP address.

ptaylor2 commented 8 years ago

Rick

All the socket library files include the function of getting the clients IP address and the port number on the clients.

On Monday, February 29, 2016, rickparrish notifications@github.com wrote:

I'm not 100% sure what you're saying, but I'm guessing you have fTelnet connecting to your own instance of fTelnetProxy, and then fTelnetProxy connecting to your BBS. And in your BBS log files you're seeing your own IP address instead of the IP address of the user who is connecting.

If that's right, then that's expected behaviour. The user connects to fTelnetProxy, which will see the user's real IP address. But then fTelnetProxy connects to your BBS, so that's why your BBS sees your own IP address.

I'm not a networking expert, but I don't believe there is any way around that. The best you can do is use something like I implemented in my last commit, where the BBS can send the telnet command "DO SEND-LOCATION" (not literally that text), and then fTelnet will reply back with the client's IP address.

— Reply to this email directly or view it on GitHub https://github.com/rickparrish/fTelnet/issues/3#issuecomment-190320337.

rickparrish commented 8 years ago

Sorry, not sure what you're referring to.

tracker1 commented 8 years ago

@rickparrish I think he means that the BBS is showing CLIENT_IP, but that is showing his server's IP, not the actual client IP address.

@ptaylor2 unfortunately, that is what a proxy does, and it isn't setup to pass through your actual IP, it isn't part of telnet or rlogin as protocols. It MIGHT be possible to do a WHOIS-style lookup, but that would be a lot of work, and some BBS software wouldn't readily support it in the box.. synchronet would be an easy enough extension afaik.

rickparrish commented 8 years ago

@tracker1 Yeah that's what I was assuming. So there are two telnet options that can help with this:

RFC946: TERMINAL LOCATION NUMBER is specifically for transmitting the client's IP address, but it only supports sending a 64bit integer (32bits for IP, 32bits for terminal number), so it only supports IPv4.

RFC779: SEND-LOCATION is not specifically meant for transmitting an IP address, but since it supports sending an arbitrary length ASCII string there's no reason it can't be used to send either an IPv4 or IPv6 address. For this reason it's the better of the two options.

I implemented both options in fTelnet a couple months ago, so a server that wants to know the client's real IP address can use either option to get it. Of course since it's the client sending the information it's no more trustworthy than say HTTP headers like HTTP_USER_AGENT or HTTP_REFERER.

Ideally fTelnetProxy would intercept the option request and answer instead, since it can supply the guaranteed-to-be-correct IP, but I'll leave that for someone else who is more worried about rogue clients lying about their IP.