From owner-freebsd-security Thu Mar 25 13: 0:48 1999 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id E0A2C14D03 for ; Thu, 25 Mar 1999 13:00:47 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA02706; Thu, 25 Mar 1999 13:00:27 -0800 (PST) (envelope-from dillon) Date: Thu, 25 Mar 1999 13:00:27 -0800 (PST) From: Matthew Dillon Message-Id: <199903252100.NAA02706@apollo.backplane.com> To: Mike Thompson Cc: freebsd-security@FreeBSD.ORG Subject: Re: Kerberos vs SSH References: <4.1.19990325021717.0097e980@mail.dnai.com> <4.1.19990325120933.00ad08d0@mail.dnai.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :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. . :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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message