This one popped up recently...

Telnet itself isn't a problem as the external port is forwarded straight to the
BBS nodes via haproxy.

However I have the situation the BBS can't natively handle SSH. So my solution has been to have any SSH session open a telnet session to the
haproxy destination.

Somewhere in there, someone has managed an interactive login, and tried to play
around with things. Part of the problem is that the account and password are no secret both are bbs.

The parameters on the telnet session include -E to disable shell escape. And the telnet session is started from within the bash .profile. Aside from mak ing telnet a valid shell and just using that, I'm not sure what else to try. Otherwise I need to find some kind of proxy/converter to go from SSH straight to the telnet port.

Spec


--- SuperBBS v1.17-3 (Eval)
* Origin: <Shoot'n the breeze on The Lower Planes> (21:3/0)

On Sun, 1 Dec 2019 14:45:00 +1100
"Spectre -> All" <0@0.3.21> wrote:

This one popped up recently...

Telnet itself isn't a problem as the external port is forwarded
straight to the BBS nodes via haproxy.

However I have the situation the BBS can't natively handle SSH. So my solution has been to have any SSH session open a telnet session to the haproxy destination.

The easiest solution would be a TLS encrypted telnet connection (haproxy for TLS termination). Unfortunately there are not many telnet clients that support direct TLS.

Somewhere in there, someone has managed an interactive login, and
tried to play around with things. Part of the problem is that the
account and password are no secret both are bbs.

The parameters on the telnet session include -E to disable shell
escape. And the telnet session is started from within the
bash .profile. Aside from mak ing telnet a valid shell and just
using that, I'm not sure what else to try.

Doing this with a user account sounds like a bad idea. There are numerous ways to restrict access, but how do you know that you haven't overlooked something and there is another hole? E.g. enabled port forwards could be harmful too.

I would try this in a restricted container only with a firewall that restricts access to the telnet port.

Otherwise I need to find
some kind of proxy/converter to go from SSH straight to the telnet
port.

This sounds like the best solution. Now we have only to find that proxy ... :)

SSH portal has telnet support, but it looks a little bit like overkill for your
simple use case
https://github.com/moul/sshportal

here is something much more simple https://github.com/eoprede/ssh_to_telnet_proxy

I haven't tried any of it.

---
* Origin: (21:1/151)

Doing this with a user account sounds like a bad idea. There are
numerous ways to restrict access, but how do you know that you
haven't overlooked something and there is another hole? E.g. enabled
port forwards could be harmful too.

I expect in many ways my whole setup is a relatively soft target. I have no way of knowing what I've missed. On the other hand, all of the security issues
I've seen so far relate to username/password issues. And have been able to plug them in that fashion.

I'll check into the proxy's you found. Once again my googlefu has failed :/

Spec


--- SuperBBS v1.17-3 (Eval)
* Origin: <Shoot'n the breeze on The Lower Planes> (21:3/101)

Hello Spectre!

On 01 Dec 2019, Spectre said the following...

The parameters on the telnet session include -E to disable shell escape. And the telnet session is started from within the bash .profile. Aside from mak ing telnet a valid shell and just using that, I'm not sure what else to try. Otherwise I need to find some kind of proxy/converter to go

Could it be that they manage to send a Ctrl-C or Ctrl-Z before the actual telnet command gets invoked?

There is also the possibility for you to use "exec" to replace the
running shell with telnet itself, to avoid any further "manipulations".

Try this before any other command in .profile (I believe variables etc. may
be set above it, also functions may be defined, but no tests/checking for files, actual function calls or running of commands must appear before it):

# disable ^C and ^Z so that we don't get interrupted
trap '' SIGINT SIGTSTP

# then you may add your other stuff here, e.g. your telnet call, or use:

# pass through to BBS, adjust connection details as needed
exec /usr/bin/telnet -8 -E 127.0.0.1 5353

# we should never get here
exit 1

Hope this helps!

Best regards
Zip

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)

Could it be that they manage to send a Ctrl-C or Ctrl-Z before the actual telnet command gets invoked?

I wouldn't have thought so, the only thing in .profile was in fact /usr/bin/telnet. Still what do I know, maybe if they're queueing during load they get first crack.

Thanks for the rest of the pointers, I have both in place. Have to say I'm not
familiar with exec, and I did have an exit on the end just in case, but now it's got the exit value on it.

Spec


*** THE READER V4.50 [freeware]
--- SuperBBS v1.17-3 (Eval)
* Origin: Scrawled in haste at The Lower Planes (21:3/101)

Hello Spectre!

On 02 Dec 2019, Spectre said the following...

/usr/bin/telnet. Still what do I know, maybe if they're queueing during load they get first crack.

My thought exactly. :)

Thanks for the rest of the pointers, I have both in place. Have to say I'm not familiar with exec, and I did have an exit on the end just in case, but now it's got the exit value on it.

Sounds good! :)

Best regards
Zip

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)

Somewhere in there, someone has managed an interactive login, and tried to play around with things. Part of the problem is that the account and password are no secret both are bbs.

Revisiting this... I have a new suspicion, that my vulneratbility is somewhere else in the system, not directly in the telnet/.profile but in the fact that they have a user account to authenticate against. In short as you already pointed out user account = bad idea....

back to investigating https://github.com/eoprede/ssh_to_telnet_proxy I hoped I might get away without this.

Spec


*** THE READER V4.50 [freeware]
--- SuperBBS v1.17-3 (Eval)
* Origin: Scrawled in haste at The Lower Planes (21:3/101)

Otherwise I need to find some kind of proxy/converter to go from SSH straight to the telnet port.

This sounds like the best solution. Now we have only to find that
proxy ... :)

overkill for your simple use case https://github.com/moul/sshportal https://github.com/eoprede/ssh_to_telnet_proxy

Woah blast from the past, but I don't remember seeing this reply before, I'm still using the ssh account with telnet forward. Problems seemed to disappear after taking write permissions from both crontab and home directory. And watching the loadavg script :) Might still check this out though.

Spec


--- SuperBBS v1.17-3 (Eval)
* Origin: < Scrawled in blood at The Lower Planes > (21:3/101)