Date: Thu, 25 Mar 1999 13:00:27 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Mike Thompson <miket@dnai.com> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Kerberos vs SSH Message-ID: <199903252100.NAA02706@apollo.backplane.com> References: <Pine.GSO.4.10.9903251409300.17330-100000@primrose.isrc.qut.edu.au> <4.1.19990325021717.0097e980@mail.dnai.com> <4.1.19990325120933.00ad08d0@mail.dnai.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:Matthew,
:
:In case you or anyone cares, here is the security scheme that
:I am developing for a web site application across a number of
:FreeBSD servers based on the information I have gathered in
:this thread.
It's always interesting to hear how people deal with security
issues.
:The design of our web application is to have a number of cooperating
:servers that communicate securely among themselves for management
:purposes -- generally calling Perl/shell scripts through ssh to
:accomplish a specific task. All servers would also be directly
:...
:
:To protect against such a penetration I intend to bind ssh to a
:reserved IP address (192.168.xxx.xxx) that each server will run
:behind a router (protecting against packet leakage). SSH logins
:on the servers Internet exposed IP address will not be permitted.
:Furthermore, each server will run IPFW (FreeBSD is great) to
:strictly limit what type of traffic can connect to a server from
:the Internet. Finally, we would not permit remote root ssh
:access because our web application runs completely in user
:space. Access only to the application user account is needed.
SSH can also be configured to run a specific program - you
can allow ssh access but you do not have to allow the client
machine to get a shell.
For example, if the purpose of the SSH link is to provide a
secure channel between two perl scripts, you can configure sshd
on the remote machine to run a specific perl script rather
then allow the client to specify the script.
You can then layer additional security within the protocol
that the scripts talk to each other with, on top of the ssh
security.
You do this using the 'command' option in the authorized_keys file.
For example:
from="lander.backplane.com" command="/etc/adm/dodumps" 1024 35 230489234...
This is very cool because you can use different keypairs for different
command sets, and it enhances security somewhat by not giving the client
access to a shell.
:Please feel free to comment on this security scheme. Any holes
:that people might find now will certainly save me development
:time and grief in the future.
Just remember the old axiom: Firewalls are like IT manager 's
teddy bears: They give the higher-ups warm fuzzy feelings
despite the fact that they don't actually *do* anything :-)
Let me give you an example. And I hope Cisco ( and others )
have fixed this by now because it's been a known problem for
a *long* time. Many years. Many firewalls fail to filter packets
when you fragment a packet header. Think about it. <GRIN>.
:Thanks again for everyone's help. I am certainly glad that
:I convinced my partners months ago to use FreeBSD for this
:project rather than that OS that is grabbing all the hype.
:
:Mike Thompson
-Matt
Matthew Dillon
<dillon@backplane.com>
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?199903252100.NAA02706>