Date: Sat, 28 Jun 1997 01:32:54 -0700 (PDT) From: Simon Shapiro <Shimon@i-Connect.Net> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: Bruce Evans <bde@zeta.org.au>, mburgett@cmnsens.zoom.com, freebsd-hackers@FreeBSD.ORG Subject: Re: com console, and h/w flow control... Message-ID: <XFMail.970628013254.Shimon@i-Connect.Net> In-Reply-To: <2772.867484814@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi "Jordan K. Hubbard"; On 28-Jun-97 you wrote: > > Actually, we are building just such system right now. We ridicule > > Slowlaris to no end for their incredible stupidity by having just such > a > > ``feature''. > > > > I am SURE I am missing something in this discussion... > > A good grasp of terminal server security? :-) If it makes you feel better :-)) No, really, I wanted a documented opinion. and there IS a problem to be solved here. > Seriously, I have to wonder at this whole line of inquiry. Let's > forget FreeBSD for a moment and say that I've got the console ports to > all my cisco routers wired up to such a terminal server. Can you > seriously tell me that I'd be in my right mind to let _anyone_ other > than the admin staff be able to log into this particular terminal > server, much less know the phone numbers for it? There's a lot you > can do if you've got a wired-in connection to the serial console of > any ten devices I can name, much less FreeBSD, and you guard that > connectivity just as jealously as you guard the physical security of > the machine or you expect your life to suck. I agree. BTW, guarding the phone number is quite meaningless. Especially when it is on a prefix known to hackers to belong to a telephone switch. This whole discussion (I apologize for the direction shift), is very important to us. We have clusters of Unix boxes that have to be administered remotely. What we want to acomplish is EXACTLY the ability to drop into a debugger and/or boot single-user. A terminal server is a sane and reasonable way to do it. A great majority of security risks can go way if one disables kernel debuggers and/or the ability to boot SU (how do they do that?). Having modem control is vital on these connections, as connection drops must be immedietely followed by SIGHUP to the controlling process. We take care of secure root login by ssh session over TCP/IP. Simon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970628013254.Shimon>