Re: Re: Has anyone received one of these?
By: Bradley D. Thornton to Todd Yatzook on Thu Sep 05 2019 01:18 pm
On 09-08-19 22:02, Bradley D. Thornton wrote to Tony Langdon <=-
So for now I've got port 23 open for telnet and port 22 open (running
Mystic's SSHD). I'm glad that I didn't have to install and run another
OpenSSHD and figure out how to pass that through or if it could be
done. Like I inferred, although perhaps not clearly enough, I already have
SSHD listening on another, non-standard port for regular user
access to the host, i.e., there are two SSH daemons listening now,
Mystic on 22 and OpenSSH on another :)
Yep I run 3 SSH daemons here:
OpenSSH on port 22 all IPs
Mystic on port 222 on selected IPs
Synchronet on port 222 on a different set of selected IPs.
:)
Hm... If I want to also run a Syncrhonet instance I could just bind it to a different IP, but Is it possible to share the filebase between the two internally? I suppose I could do it with a symlink. I had thought about doing it on another machine and then just making it available via an NFS mount on the
private network. I'll need to ponder that later.
Thanks for bringing that up!
I start mis as root. Actually, since that part of testing is over now,
I start it as the non-priv'd user who owns the dir with a sudo - one of
the use cases where I believe in using sudo ;) For that, I don't add
the user to the sudo group, because any breakouts could afford a script
kiddie to wreak havoc with impunity, so the user running "mis" (Not mystic)
is only allowed to run mis.
Using sudo is still "running as root".
Well.... Okay ;) Yes it is, but I'll address that below.
I try to avoid letting non-privileged users run daemon's on privileged
lower ports, but with some software, do sometimes. This isn't one of
those
times ;)
Umm, why? Back in the old days, there were lots of users (as in actual
people with individual UNIX accounts) and only one sysadmin. In that
environment, it makes sense not to allow non root users to bind privileged
ports - you wouldn't want a user taking over the SMTP port, for example.
Today it's more common to have Linux boxes with only one actual (human) user
- the sysadmin, and any "users" are simply accounts to isolate processes
from one another. Allowing these users to run a specific application that
can bind privileged ports means they don't have to start the application as
root, with a (very) small increased potential for a root compromise, if a
flaw can be triggered before it drops privileges.
Actually, and I do understand what you're saying, but with respect to SMTP specifically, and I know I gave an example of Bind as well, there are [once] common use cases for allowing a user to do that.
For example, I have users that manage their own email users for their domains as well as the DNS for those particular zones the users have. Bind picks up the
zonefiles for that user's domains from their say, ~/dns/sld.tld.db file. The user is free to add and delete whatever records they need to, and up the serial
for their zonefile, but they still need a way to HUP named, ergo, visudo:
joeuser ALL=(ALL:ALL) NOPASSWD: /sbin/reload-dns.sh
where reload-dns.sh is chmod'd 644
#!/bin/sh
# reload-dns.sh
/etc/rc.d/rcnamed reload
Or some version of kill -HUP named, etc.
The same to hash the include of sendmail.cf in their ~ tree.
I know the thang nowadays is to sudo command for everything from the one person
who is the admin on their own machine, but that's so freakin' redundant and unneccesary it just drives me nuts - even when I read it in Howtos. Yes, I get the idea, and this didn't come into common usage until Windows folks starting coming over the UNIX and Ubuntu really popularized it. In that Windows world, there isn't really an 'su -' per se', so what 'should' normally be a non-priv'd
user is dropped into the Local Administrator or Domain Administrator group to administer machines on the network and have SSO convenience - that's just never
been the way it was done in UNIX - su to root, and get back out after you do root stuff.
Effectively, 'sudo command' is the same, but all that typing just drives me nuts. I know when I want to do root stuff and I know when to ^d back out. I understand why it's been popularized in recent years not to do it that way but.... an explitive came to mind so my rant should stop there lol.
The first thing I had to get my head around when I started in the MCSE program when it was first launched was coming to terms with being a regular user and a god user at the same time - that's just freakin' wrong. Microsoft has never had
an su equivalent, with the semi exception of being able to choose running certain things as Administrator - like powershell, etc. There I go again. Apologies.
Back to the security of it, if someone were to break out into the system, by allowing the user only a single root command, and effectively only commit a DOS, in this case.
In the rare cases where I would allow a non-priv'd user to start a job that could bind to a lower port, I would first make sure that user has no shell, maybe /bin/false or whatever, in /etc/passwd, so for them to start that service
they would (root would, actually):
su jouser -s $SHELL -lc "
/path/to/command
/some/other/command
/bind/daemon/to_port:123
"
And this would be required:
#CapabilityBoundingSet=CAP_NET_BIND_SERVICE #AmbientCapabilities=CAP_NET_BIND_SERVICE
Now, that begs another question. If someone breaks out of Mystic...
that's always a concern, so what SSH implementation does Mystic use? I ask
because I want to know how confident I should be that port 22
(Mystic's SSHD) is as secure as OpenSSH is on the host.
I'm not sure tbh.
Here's what I got from a quick port scan. Not much info, which is good actually.
PORT STATE SERVICE VERSION
22/tcp open ssh APC AOS cryptlib sshd (protocol 2.0)
23/tcp open telnet
| fingerprint-strings:
| GenericLines:
| [8;25;80t
| [1;25r
| [1;1H
| [1;1H
| [?1000h
| Mystic BBS v1.12 A43 for Linux Node 1
| Copyright (C) 1997-2019 By James Coyle
| Detecting terminal emulation:
| [6nASCII detected.
| Ascii (No Color)
| Ansi (Color)
| Graphics Mode ->
| NULL, tn3270:
| [8;25;80t
| [1;25r
| [1;1H
| [1;1H
| [?1000h
| Mystic BBS v1.12 A43 for Linux Node 1
| Copyright (C) 1997-2019 By James Coyle
|_ Detecting terminal emulation:
Thanks for your feedback Tony!
--- SBBSecho 3.09-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)