Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 16 Jan 2000 06:55:46 -0600 (CST)
From:      Igor Roshchin <igor@physics.uiuc.edu>
To:        aunty@comcen.com.au (aunty)
Cc:        freebsd-security@FreeBSD.ORG
Subject:   Re: Disallow remote login by regular user.
Message-ID:  <200001161255.GAA19043@alecto.physics.uiuc.edu>
In-Reply-To: <20000116214058.D14280@comcen.com.au> from "aunty" at "Jan 16, 2000  9:40:58 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
> On Fri, Jan 14, 2000 at 01:32:22PM -0500, Nathan Dorfman wrote:
> > On Thu, Jan 13, 2000 at 08:45:20PM -0500, Crist J. Clark wrote:
> > > Nicholas Brawn wrote,
> > > > Hi folks. I'm trying to ocnfigure my system so that I can disallow a
> > > > particular user account from being able to login remotely, and forcing
> > > > users to su to the account instead. How may I configure this?
> > > > 
> > > > PS. Users may be using anything from telnet to ssh to login to the system,
> > > > so I need something that works across the board.
> > > 
> > > For anything that is going to call login(1), you can use
> > > /etc/login.access(5). That pretty much eliminates stuff like telnet,
> > > rlogin, and console logins. For SSH, look at the 'AllowUsers' and
> > > 'DenyUsers' keywords for the sshd_conf file on the sshd(8)
> > > manpage. And of course, if ftp(1) is an issue, there is /etc/ftpusers
> > > as described in ftpd(8).
> > 
> > You can make sshd use login(1). Set UseLogin to yes in sshd_config. This
> > is (at least sounds like) a good idea just so that login.access(5) and
> > login.conf(5) have their effect.
> 
> I have a slightly similar requirement, an authentication server which
> must carry another machine's password files, but where no logins of any
> kind are allowed, except root on console and one user from one IP.
> 
> Telnet and ftp are turned off, ssh is heavily restricted when active, and
> login.access is there as a backup in case someone "improves" inetd.conf
> from the console, a real possibility. (Yeah, I know, but moving faeces
> to higher ground is the reality I have to live with sometimes.)
> 
> Shells aren't much help. Of course I can't alter the password file, and
> someone might change installed shells or /etc/shells in the future
> without realising the security implications. I've seen this happen in
> the past.
> 
> The ftpusers file isn't much help in this case. I'd have to enter and
> maintain thousands of usernames or hundreds of groups. All I can think
> of as an additional ftp precaution is a cron job to find and delete ftpd.
> 
> I'm also thinking about having a permanent /var/run/nologin file.
> Have I missed any other good tricks, particularly for ftp?
> 
> -- 
> 

I realize that everybody might have local rather weird situation.
However, it sounds like you have some problems which are not related
to the _system_ administration, but just to the _personnel_ administration.
I mean that you are trying protect your machine from somebody else,
changing its configuration  (modification of /etc/shells, /etc/inetd.conf)..

System can not be made fool-proof from one who has root-priveleges. :)

Let me through in one more stone in this pile of solutions.
Unless I missed it, nobody has mentioned it yet.

One can configure tcpd (tcpwrappers) - "hosts.deny" (hosts.allow) file
to disallow any external access from any host via any protocol,
while allowing connections from specific hosts via specific protocols.

While this does not do any per user access limitations, it still
can help you or other folks asking earlier in armoring their boxes.

Hope, this helps...

Igor


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001161255.GAA19043>