Hi g00r00,

fTelnet has built-in sendlocation functionality to send the connecting IP to Mystic through the wss proxy. Synchronet has this enabled and you're able to see which IPs are connecting. Right now all connections through fTelnet
appear to be 127.0.0.1, which isn't super ideal, though not a huge problem.
I'm curious if you'd be interested in implementing some kind of functionality in mystic to understand this?

Thanks!

--- Mystic BBS v1.12 A46 2020/04/13 (Linux/64)
* Origin: monterey bbs (77:1/128)

not a huge problem. I'm curious if you'd be interested in implementing some kind of functionality in mystic to understand this?

Is it documented somewhere? I'm not familiar with how the actual IP is received from the proxy.

--- Mystic BBS v1.12 A46 2020/04/21 (Windows/64)
* Origin: Sector 7 (77:1/138)

Is it documented somewhere? I'm not familiar with how the actual IP is received from the proxy.

Hi g00r00,

Super raw response here, in a rush to take a meeting sorry for brevity.
Pasting direct from Rick:

There is support for two TELNET negotiation sequences for this purpose (Send Location = 23, Terminal Location Number = 28). If the BBS sends the DO sequence for either of them, then fTelnet will respond back with the user's
IP.

Hope this makes sense :P

--- Mystic BBS v1.12 A46 2020/04/13 (Linux/64)
* Origin: monterey bbs (77:1/128)

Super raw response here, in a rush to take a meeting sorry for brevity.

No worries, I appreciate the help!

There is support for two TELNET negotiation sequences for this purpose (Send Location = 23, Terminal Location Number = 28). If the BBS sends
the DO sequence for either of them, then fTelnet will respond back with the user's IP.

Sounds easy enough. It'll probably be harder for me to setup fTelnet than it will be to make the IP work considering I've never looked at it before.

One thing I worry about though is that terminals could use that to spoof IP addresses in order to bypass an IP block. It'd be nice to determine somehow if the connection was from fTelnet so that it could only acknowledge an IP response from fTelnet. But then the terminal could just spoof that its fTelnet.

I suppose I could only do it if the address is a local IP 127.0.0.1 or :1
or something?

Since Mystic can spawn multiple copies of its terminal servers, I could also make it a toggle in the TELNET server options and then someone could spawn a second telnet server on an off-port just for their fTelnet connections while leaving another TELNET server running on port 23 with that feature disabled.

--- Mystic BBS v1.12 A46 2020/04/21 (Windows/64)
* Origin: Sector 7 (77:1/138)

Sounds easy enough. It'll probably be harder for me to setup fTelnet
than it will be to make the IP work considering I've never looked at it before.

fTelnet has an automagic installer thingie: https://embed-v2.ftelnet.ca -
this could help spin something up quick for testing. Just put it in a webroot and paste the crap in the wizard into your index.html or whatever.

Optionally I could set it up in a vm and share access with you, let me know :)

One thing I worry about though is that terminals could use that to spoof IP addresses in order to bypass an IP block. It'd be nice to determine somehow if the connection was from fTelnet so that it could only acknowledge an IP response from fTelnet. But then the terminal could
just spoof that its fTelnet.

Yeah, the one tricky part is ws: or wss: in the configuration, but honestly that could help here with self-hosted setups. There are a couple ways to
think about this, maybe:
1 - Local ws/wss, which means mystic actually notices the connection coming from 127.0.0.1 in the first place, and
2 - Connection from one of the proxy sites from the wizard (the link pasted above).

My thought process is basically the actual tcp/ip connection will proxy
through something in the whitelist, and then arbitrarily pass an IP. For what it's worth, I'm currently dealing with trying to host my BBS in the web and
I'm losing any sort of IP block filtering from mystic for those connections anyway.

I suppose I could only do it if the address is a local IP 127.0.0.1 or :1 or something?

Yeah, that's what I was thinking. It'll come from one of those or maybe the online telnet guide, or one of the established ftelnet proxies...so sysops
will just have to have those IPs in their whitelist as normal, I guess.

Since Mystic can spawn multiple copies of its terminal servers, I could also make it a toggle in the TELNET server options and then someone
could spawn a second telnet server on an off-port just for their fTelnet connections while leaving another TELNET server running on port 23 with that feature disabled.

Have you given any thought to ws or wss services? That could actually
simplify much of this. I have wss connections on an arbitrary port, and they proxy the connection (and terminate TLS) directly to a telnet node.

Thanks for thinking about this!

--- Mystic BBS v1.12 A46 2020/04/13 (Linux/64)
* Origin: monterey bbs (77:1/128)

Sounds easy enough. It'll probably be harder for me to setup fTelnet than it will be to make the IP work considering I've never looked at before.

fTelnet has an automagic installer thingie: https://embed-v2.ftelnet.ca - this could help spin something up quick for testing. Just put it in a webroot and paste the crap in the wizard into your index.html or
whatever.

I finally got around to testing this, and the code I did does work to get the actual IP!

The challenge now is how to best integrate that into the existing systems? For example, since the IP comes in sometime after the connection via a telnet operation, we're already past the blacklist checking and IP location resolution.

So for now it would just change what is shown for the user's IP within the BBS itself. My concern about IP spoofing still remains too.

If we just blindly accept this IP as fact, then even if we did build in the blacklist IP check, the user could simply spoof a new IP with the telnet negotiation to get around their IP being blocked.

I could probably wait up to 1 second when a telnet connection occurs to see if the IP is received before going through the IP blocking and location stuff. But even then, the client could delay sending it until later to get around that. This may only work on Unix systems too since Windows passes a hot socket to a subprocess, it would use any telnet negotiated options (like echo mode, etc).

Another idea might be that the Telnet Send-location would only be honored if the connection hostname or IP matched a defined value. So if you're running a proxy, all connections should be from the same hostname. If the connection is from that hostname, then only at that time would it honor the send location.

There will need to be a lot of shuffling to make this work with the already in place systems, without opening up an easy to exploit security hole. And the differences between how the Unix and Windows versions work further
complicates it.

--- Mystic BBS v1.12 A46 2020/05/19 (Windows/32)
* Origin: Sector 7 | Mystic WHQ (77:1/138)

I finally got around to testing this, and the code I did does work to
get the actual IP!

Sweet! :) This is excellent news.

The challenge now is how to best integrate that into the existing
systems? For example, since the IP comes in sometime after the
connection via a telnet operation, we're already past the blacklist checking and IP location resolution.

I'll jump a bit further down to what I personally feel is the "best" solution:

Another idea might be that the Telnet Send-location would only be
honored if the connection hostname or IP matched a defined value. So if you're running a proxy, all connections should be from the same
hostname. If the connection is from that hostname, then only at that
time would it honor the send location.

The default config here could be 127.0.0.1 if someone hosts their own wss service...otherwise I don't think there are a ton of fTelnet proxies floating around on the open internet and could be pretty easy to just document
something pointing at the website *shrug*

There will need to be a lot of shuffling to make this work with the already in place systems, without opening up an easy to exploit security hole. And the differences between how the Unix and Windows versions
work further complicates it.

Gotcha. I'm struggling with some IP detection stuff on my board
anyway...maybe it's a linux issue? In any case, even with up-to-date ip2location stuff my location is always some random place, even if the IP is 127.0.0.1. But that's another issue entirely :P I'm just glad this works!

As a data cleanliness nerd, this pleases me haha.

--- Mystic BBS v1.12 A46 2020/04/13 (Linux/64)
* Origin: monterey bbs (77:1/128)

The default config here could be 127.0.0.1 if someone hosts their own wss service...otherwise I don't think there are a ton of fTelnet proxies floating around on the open internet and could be pretty easy to just document something pointing at the website *shrug*

I think I will have to add a "Telnet Proxy Host" to the Servers > General Settings and if a connection is received that matches that value (either hostname or IP) then it will honor a send-location.

The next challenge is the differences between Windows and Linux. With Linux I could wait maybe an extra second on the connection and try to negotiate an IP if its from the Telnet Proxy Host. But on the Windows side, Mystic passes a hot socket to a subprocess, so if I do that then any negotiated telnet stuff will be lost in the transition.

Gotcha. I'm struggling with some IP detection stuff on my board anyway...maybe it's a linux issue? In any case, even with up-to-date ip2location stuff my location is always some random place, even if the

I don't know what to do to reproduce this. I have tried. I made a separate program that does nothing but prints the result of an IP and I've spam ran it to see if there was a different value. Its always the same. There must be something different between your situation and mine that we're missing!

--- Mystic BBS v1.12 A46 2020/05/19 (Windows/32)
* Origin: Sector 7 | Mystic WHQ (77:1/138)

anyway...maybe it's a linux issue? In any case, even with up-to-date ip2location stuff my location is always some random place, even if the
IP is 127.0.0.1. But that's another issue entirely :P I'm just glad this works!

Hey I doubt this is it, but I was trying to get to the bottom of this again briefly tonight and I noticed that I never initialized the country code
result variable.

I don't think this will actually fix it, but its initialized now and I will upload a new build to the prealphas if you are interested in testing it.

I could even make you a demo program that just spits out a country code when you pass it an IP on the command line. Or if you're confident enough to toy around in free pascal I could even send you my code for IPLocation.

--- Mystic BBS v1.12 A46 2020/05/19 (Windows/32)
* Origin: Sector 7 | Mystic WHQ (77:1/138)

Hey I doubt this is it, but I was trying to get to the bottom of this again briefly tonight and I noticed that I never initialized the country code result variable.

Ah, interesting. So you can't repro this in linux?

I don't think this will actually fix it, but its initialized now and I will upload a new build to the prealphas if you are interested in
testing it.

Sweet deal. I'm off to bed (actually writing this from bed hehe) but will
test tomorrow. Thanks!

I could even make you a demo program that just spits out a country code when you pass it an IP on the command line. Or if you're confident
enough to toy around in free pascal I could even send you my code for IPLocation.

I'd be curious to see the freepascal source. I have a login stat screen that spits out the detected country via mystic display code, so I'm able to see it pretty quick. It also logs to mis.log (or nodex.log or whatever, can't remember).

I've tried querying the ip location db with python and testing random IP addresses and it works.

--- Mystic BBS v1.12 A46 2020/04/13 (Linux/64)
* Origin: monterey bbs (77:1/128)

Hey I doubt this is it, but I was trying to get to the bottom of this again briefly tonight and I noticed that I never initialized the coun code result variable.

Ah, interesting. So you can't repro this in linux?

Yeah I've never been able to reproduce it.

I don't think this will actually fix it, but its initialized now and will upload a new build to the prealphas if you are interested in testing it.

Sweet deal. I'm off to bed (actually writing this from bed hehe) but will test tomorrow. Thanks!

Cool deal there is also a "testiploc.zip" which is a Linux/64 binary that allows you to look up IP location from the command line. It has to run in
the root Mystic folder though because it looks for "data/iplocation.bin".

If you still have problems with the latest build, maybe trying that command line utility can help us narrow down where the error comes from. If the command line works well, then its not my IPLocation class and its something with MIS itself.

--- Mystic BBS v1.12 A46 2020/05/19 (Windows/32)
* Origin: Sector 7 | Mystic WHQ (77:1/138)

Ah, interesting. So you can't repro this in linux?

Yeah I've never been able to reproduce it.

I /must/ be using the wrong file downloaded from the iplocation website or something. I can think of no other reason why this is getting botched for me.

Sweet deal. I'm off to bed (actually writing this from bed hehe) but test tomorrow. Thanks!

Cool deal there is also a "testiploc.zip" which is a Linux/64 binary that allows you to look up IP location from the command line. It has to run
in the root Mystic folder though because it looks for "data/iplocation.bin".

Sweet. I'm running slightly behind but I'll give this a shot later today.

Interestingly, 127.0.0.1 throws odd results for country. It doesn't make
sense hehe.

If you still have problems with the latest build, maybe trying that command line utility can help us narrow down where the error comes from. If the command line works well, then its not my IPLocation class and its something with MIS itself.

Cool, I'll report back a bit later. Thanks dude.

--- Mystic BBS v1.12 A46 2020/05/22 (Linux/64)
* Origin: monterey bbs (77:1/128)

Cool deal there is also a "testiploc.zip" which is a Linux/64 binary that allows you to look up IP location from the command line. It has to run
in the root Mystic folder though because it looks for "data/iplocation.bin".

If you still have problems with the latest build, maybe trying that command line utility can help us narrow down where the error comes from. If the command line works well, then its not my IPLocation class and its something with MIS itself.

Confirmed the "testiploc.zip" package works as expected, but MIS is detecting odd country results. 127.0.0.1 reports consistently "-" for country with the test, but mis reports it as "unknown", blank, "United States of America", and
a handful of other random results. Very strange.

My IPV6 address was reported correctly twice as the US, but this could be anomalous. The testiploc binary works 100% of the time.

--- Mystic BBS v1.12 A46 2020/05/22 (Linux/64)
* Origin: monterey bbs (77:1/128)

If you still have problems with the latest build, maybe trying that command line utility can help us narrow down where the error comes fr If the command line works well, then its not my IPLocation class and something with MIS itself.

Confirmed the "testiploc.zip" package works as expected, but MIS is detecting odd country results. 127.0.0.1 reports consistently "-" for country with the test, but mis reports it as "unknown", blank, "United States of America", and a handful of other random results. Very strange.

Thanks for testing this. I will play around with this more tonight if I can and focus only on MIS code and not IPLocation. Hopefully that will help me figure it out.

--- Mystic BBS v1.12 A46 2020/05/19 (Windows/32)
* Origin: Sector 7 | Mystic WHQ (77:1/138)

Confirmed the "testiploc.zip" package works as expected, but MIS is detecting odd country results. 127.0.0.1 reports consistently "-" for country with the test, but mis reports it as "unknown", blank, "United States of America", and a handful of other random results. Very strange.

I think I figured it out and I just put up some new prealphas to test.

I am thinking you have your IP address whitelisted. I think what was happening is that when an IP was whitelisted, Mystic did not do the country lookup and that combined with the earlier thing I mentioned where the variable was initialized correctly could cause some weird results.

Originally Mystic didn't use IPLocation for anything other than country blocking, but now the country is stored in the user editor and there is an MCI code to display it, etc. Because of that I've changed it to always perform
the country lookup even when an IP is whitelisted.

I think this might fix up your issue. The 127.0.0.1 address should always resolve as "Unknown" now since 127.0.0.1 doesn't really have a home, but
other IPs that are whitelisted should show correctly.

--- Mystic BBS v1.12 A46 2020/05/26 (Windows/64)
* Origin: Sector 7 | Mystic WHQ (77:1/138)

I am thinking you have your IP address whitelisted. I think what was happening is that when an IP was whitelisted, Mystic did not do the country lookup and that combined with the earlier thing I mentioned
where the variable was initialized correctly could cause some weird results.

That makes sense. The IPs were always from my house or via fTelnet, in which case they are 127.0.0.1 :P

Originally Mystic didn't use IPLocation for anything other than country blocking, but now the country is stored in the user editor and there is
an MCI code to display it, etc. Because of that I've changed it to
always perform the country lookup even when an IP is whitelisted.

Sweet, I'll give the new prealphas a try tonight and let you know how it
works out over here. I guess since I'm the only person (really) using my BBS
at the moment, I was getting something of a false positive right now.

--- Mystic BBS v1.12 A46 2020/05/22 (Linux/64)
* Origin: monterey bbs (77:1/128)

Sweet, I'll give the new prealphas a try tonight and let you know how it works out over here. I guess since I'm the only person (really) using my BBS at the moment, I was getting something of a false positive right now.

Sounds good let me know how that goes and then we can move onto finishing off the proxy send-location stuff. I just need to decide where I want to put the "proxy whitelist" in the configuration. If it should be a .txt file of IP/hosts or just a single setting in Servers > General Options or maybe just a field in the telnet server settings.

--- Mystic BBS v1.12 A46 2020/05/27 (Windows/64)
* Origin: Sector 7 | Mystic WHQ (77:1/138)

Sounds good let me know how that goes and then we can move onto
finishing off the proxy send-location stuff. I just need to decide
where I want to put the "proxy whitelist" in the configuration. If it should be a .txt file of IP/hosts or just a single setting in Servers > General Options or maybe just a field in the telnet server settings.

Hey, sorry, I'm like 50/50 on whether or not I'm getting fired soon so
haven't had much time for BBS stuff :(

I'll knock this out tomorrow.

As far as the proxy whitelist config...I suspect there's probably one IP for anyone running their own wss proxy, but anyone using the open/public IP would be potentially a few. So basically anywhere it makes sense to throw an array.
I am pretty indifferent since for me it'll always be 127.0.0.1 :)

--- Mystic BBS v1.12 A46 2020/05/22 (Linux/64)
* Origin: monterey bbs (77:1/128)

Hey, sorry, I'm like 50/50 on whether or not I'm getting fired soon so haven't had much time for BBS stuff :(

Oh man sorry to hear that...that sucks. No rush to test this stuff, just give it a shot whenever. We can pick up where we left off whenever you feel like it.

Hope things work out for you.

As far as the proxy whitelist config...I suspect there's probably one IP for anyone running their own wss proxy, but anyone using the open/public IP would be potentially a few. So basically anywhere it makes sense to throw an array. I am pretty indifferent since for me it'll always be 127.0.0.1 :)

Its easiest for me to put a field in Server > Gen Options but it probably makes more sense to put it in the telnet configuration since its only used for telnet. I think a single value will be okay as long as it compares that value to both the IP and hostname of the connection.

--- Mystic BBS v1.12 A46 2020/05/28 (Windows/64)
* Origin: Sector 7 | Mystic WHQ (77:1/138)

Oh man sorry to hear that...that sucks. No rush to test this stuff,
just give it a shot whenever. We can pick up where we left off whenever you feel like it.

So far so good! Correctly detected my IP and my VPN'd IP country locations,
and also is reliably reporting "Unknown" for 127.0.0.1 :)

Thanks for making these changes, much appreciated.

Its easiest for me to put a field in Server > Gen Options but it
probably makes more sense to put it in the telnet configuration since
its only used for telnet. I think a single value will be okay as long
as it compares that value to both the IP and hostname of the connection.

Yeah, agreed that it will likely only be passed through telnet sessions,
since it's something implemented in the initial telnet handshake (or whatever the correct term here is). I think this'll be pretty cool. As a data nerd
that loves metrics, I'm a big fan of things like this.

One interesting consideration would be whether or not we should block IPs
based on country lookup here...my gut says no, if it's coming through
localhost or a trusted proxy IP, we can probably safely assume it's not some Russian botnet trying to hack our box.

--- Mystic BBS v1.12 A46 2020/05/28 (Linux/64)
* Origin: monterey bbs (77:1/128)