Date: Thu, 25 Mar 1999 12:11:59 -0800 From: Mike Thompson <miket@dnai.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Kerberos vs SSH Message-ID: <4.1.19990325120933.00ad08d0@mail.dnai.com> In-Reply-To: <199903251828.KAA00857@apollo.backplane.com> References: <Pine.GSO.4.10.9903251409300.17330-100000@primrose.isrc.qut.edu.au> <4.1.19990325021717.0097e980@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. 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 connected to the Internet running the Apache web server running our application. This implies that each server both issue and receive ssh commands and a private key must be stored on the issuing ssh server. This might seem a little dangerous considering the server is directly connected to the Internet. If a private key from one server were compromised (such as getting access to it from the Apache web server) a hacker could potentially gain entry into every other server (as Matthew Dillon pointed out). 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. To gain manual entrance to an application server for admin purposes we will first have to ssh into a well protected admin server from the Internet and then ssh again to a specific application server through the reserved IP address range. We must make certain that a compromise of a private key from an application server does not allow entry into our admin server. The only way that I can see to make this even more secure would be to run two NICs on each server so secured IP packets are never co-mingled with Internet IP packets, even behind a router. However, this is something that we would not like to do because it doubles the cost of our network hardware and increases complexity. The cost per server (both hardware and software) is a critical factor in whether our business succeeds. 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. 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 At 10:28 AM 3/25/99 -0800, Matthew Dillon wrote: >:Matthew, >: >:Another quick question. Under the configuration described below >:can one system issue an ssh command from a script to another system >:without having to include a password? We have automated scripts >:that will run nightly that will run on one server and execute commands >:on other servers using ssh. Suppling such a password to the >:Kerberos kinit application before using ssh in such a script will be >:problematic. I assume this is why you mentioned your use of the >:"authorized_keys" files for limited purposes? Any other suggestions? >: >:Mike Thompson > > You can always use ssh's authorized_keys mechanism, in which a user ( or > root ) on one machine gives root on another machine access via a keypair. > Typically, in order for this to work from cron, you cannot put a password > on the private key, so the administrative machine from which the ssh is > issued must be secure. > > People sometimes forget that in a typical setup, if someone steals the > private key from machine A for which machine B has entered the public > key in its authorized_keys file, that person can use it to ssh to > machine B from anywhere. With ssh, you have to use the > 'from="fulldomainname"' option *IN* the authorized_keys file to ensure > that the key authenticates *AND* that it is coming from a specific client. > e.g. > > # authorized_keys file > # > from="apollo.backplane.com" 1024 37 8123412340... > > -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?4.1.19990325120933.00ad08d0>