Date: Sat, 23 Mar 2002 08:43:27 -0800 From: Benjamin Krueger <benjamin@macguire.net> To: Courtney Thomas <ccthomas@flash.net> Cc: freebsd-questions@freebsd.org Subject: Maintaining Access Control Lists (was: So long and thanks for all the fish) Message-ID: <20020323084327.A354@rain.macguire.net> In-Reply-To: <3C9C84CF.2090300@flash.net>; from ccthomas@flash.net on Sat, Mar 23, 2002 at 08:36:15AM -0500 References: <F61GQUEYvZmDvHbYxPo0000a6bd@hotmail.com> <20020323002608.B20699@rain.macguire.net> <3C9C84CF.2090300@flash.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> Benjamin Krueger wrote: > > * Charles Burns (burnscharlesn@hotmail.com) [020322 23:30]: > > > >>>SSH has BIG security problems.. Ive been cracked ONCE - the week I ran SSH > >>>- an not since I pulled it out.. and i got slammed for sayin that too.. > >>> > >>>So the moral is - if it smells like a fish, it probably is. > >>> > >>A play on words for OpenBSD's mascot? :-) > >> > >>Thinking about it, are there really any compelling reasons to use SSH for > >>most tasks (like command shells) when the likelyhood of being packet sniffed > >>is (in most environments) far lower than the likelyhood of a serious > >>security flaw popping up in SSH, which happens occasionally? Other than one > >>recent bug, Telnet has a better record and is likely to have less holes > >>found down the road because it is so much simpler (and FAR easier to setup > >>properly!) > > > > Ever read the telnet client's source? Nothing simple about that. Hell, there's > > an elementary buffer overflow in the code to grok user input. I haven't > > submitted a PR yet (bad ben), but while you mention it, if anyone has the telnet > > client set suid, please unset it. =) > > > > Telnet's history is long and fraught with holes, just like any software. The > > moral of the story is not to give up software because it has a hole, but to > > manage that software intelligently. For instance, if ssh has bugs to wrinkle > > out, use an ACL. An ssh daemon that can't be reach can't be exploited. * Courtney Thomas (ccthomas@flash.net) [020323 07:18]: > Please advise on implementing an ACL for not only ssh but > "anyArbitrary" program ? > > Appreciatively, > Courtney Well, the most obvious way is to maintain ACLs for all of your applications using IPFW or IPFilter. That has the advantage of central configuration for every single network app. Barring that, network daemons that run out of inetd can use tcp wrappers (the /etc/hosts.allow system). This has a flexible system for configuring access to various daemons from the network, however has the unfortunate achilles heel of being entirely dependant on inetd to pick up traffic for it and spawn a new instance of the daemon to run it. I've heard reports of tcpserver of qmail fame doing the same thing, and even with some speed gains, but I'm not a big fan of the author or his works. hosts_options(5) for more information. For ssh specifically, you can use the built in sshd access control mechanisms. This has the bonus of allowing you control on the user level, as well as on the network level. You can specify certain users or groups who do and do not have access to perform certain things with the ssh daemon. sshd(8) for more information. -- Benjamin Krueger "Life is far too important a thing ever to talk seriously about." - Oscar Wilde (1854 - 1900) ---------------------------------------------------------------- Send mail w/ subject 'send public key' or query for (0x251A4B18) Fingerprint = A642 F299 C1C1 C828 F186 A851 CFF0 7711 251A 4B18 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020323084327.A354>