FC3 Security

Jeff Kinz jkinz at kinz.org
Thu Mar 10 01:21:44 UTC 2005


On Wed, Mar 09, 2005 at 02:25:31PM -0600, Aleksandar Milivojevic wrote:
> Jeff Kinz wrote:
> > Any IT dept that equates sshd to a server is either not up to snuff
> > technically (and in a really bad way.), or they are being duplicitous.
> > (Thats another word for lying)
> 
> I've heard only one side of the story about that particular IT 
> department (Rick's side), and reacted upon it (probably shouldn't have, 
> at least not without knowing the other side of the story).
> 
> However, for one thing I must agree with the IT department in question. 
>   Allowing unrestricted connections to any service (including SSH) from 
> Internet isn't something that should be allowed.  It isn't really 
> relevant if the machine is server or not.

Yes, Excepting servers whose defined function is to accept any 
connection from anywhere, like Google's port 80.

> Now, definition of server is kind of fuzzy.  

I might have agreed with that statement until I saw Rick Steven's email.

Now I feel that "server" alone always implies server "machine",
a machine whose _primary_ function, is providing services to clients.

It is, as you state below, a choice of definitions, but upon examination
I see that in IT usage "server" always seems to mean a specific machine,
not a process so I'm putting my vote that way (if anyone's counting :))

> If machine is running a service that accepts connections, it might
> be considered a server. All depends on the definition one chooses to
> use. On the other hand, using that definition, each and every Windows
> machine with file&printer sharing enabled is also a server (and my
> guess is that file&printer sharing is commonly used on the university
> type of network).

This is where the issue of distinguishing between a "server" and
"client - server architecture" becomes important.

"Client -  server architecture" describes the relationship between two
processes.  These two processes can even be running on the same machine.
Is a machine where that is happening a "server" or a "client"?
(Ok, its both...?)

> I can kind of see the mentioned IT department as having a point *if* 
> they are the only ones who are administering all those Windows boxes on 
> their network, keep them tightly closed down, with users not able to 
> change any system settings, with BIOS passwords to prevent users from 
> reinstalling machines.  If users have Administrator privileges on those 
> Windows machines, than I can't see any reasoning behind their decision, 
> as long as Rick is not bugging them to troubleshoot his problems.

I agree
> 
> Another thing that puzzles me is, if the network is completely open (as 
> Rick said it is), and they are depending only on Windows XP firewall 
> feature, than what is the difference between Rick's machine and any 
> other host on the Internet?  Sure, somebody can do more effective DoS on 
> local network, but other than that?

Yep.
> 
> BTW, I completely agree with one comment made here.  IT department 
> provides service.  There are no "us" and "them".  In corporate world, we 
> do whatever is needed to support bussiness needs.  IT department in 
> university setting should be the same.  If somebody needs Linux box 
> connected to network to do his work, IT folks shouldn't be in the way 
> "because we are Windows-only shop".  I always considered my job 
> description to be "finding a way to allow people to do their work in 
> most efficient way, while keeping it secure".
> 
> What Rick described is completely opposite attitude that results in 
> restricting people in doing their work, separation to "us" and "them", 
> and inefficient use of resources.

Absolutely.




-- 
"The only system which is truly secure, is one which is switched off
and unplugged, locked in a titanium lined safe, buried in a concrete
bunker, surrounded by nerve gas and very highly paid armed guards. Even
then, I wouldn't stake my life on it" - Gene Spafford 
http://kinz.org
http://www.fedoranews.org
Jeff Kinz, Emergent Research, Hudson, MA.




More information about the fedora-list mailing list