This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
>-----Original Message----- >From: Peter Barada [mailto:pbarada@mail.wm.sps.mot.com] >Sent: 23 August 2001 17:23 >Wow, sounds like someone didn't get their frosted flakes and caffeine >this morning :-) Heh, nahh, I'm just naturally sarcastic. Since this is going well O-T, and since Andy's problem is fixed and he probably isn't interested, I've sent this one to the list only; if you want to talk further on the topic, we should take it to private mail. >'Refusing to allow an outgoing connection from one well defined >machine to one well defined remote server on one specific port >suggests ...' may be fine if you're in a company that has only 5 >employees, but if you work for a larger comanpy(like) mine, it is >impossible to arrange a special connection, because if every one of >the 40000+ engineers whine to the sysadmins that they need a specific >port connection, the whole request system collapses and the network >becomes impossible to administer. Your suggestion that a request to a network admin to provide network facilities, required by a user who needs them to perform his job and who presumably works for the same firm that actually owns the hardware that constitutes the network and that only bought all that hardware in order to provide tools for their employees to do their jobs more effectively with, constitutes "whining" makes me wonder whether the network exists to serve the users, or the users exist to serve the network. If we can't have the tools to do our jobs with because they are regarded as too dangerous, we might as well all go home. Oh, and just how likely do you think that example is anyway? Can you name 40,000 protocols that an engineer could legitimately need to use in their work ? That's 1/3rd of all the ports there could possibly be. If every one of those 40,000 engineers was to make requests for outgoing ports to be opened, odds are that almost all of them would be to one of just a few protocols. In fact, CVS is probably the only one that would crop up more than once or twice. It's a *very* poor sysadmin who blames his users for the failings of his network management and administration systems. Might I suggest that with a very few shell scripts and mail aliases on a *nix system, adding and subtracting users from groups authorised to make some outgoing connections could be pretty much automated, requiring the admin only to make a policy decision the first time a user requests a new port to be opened ? >When the network is that large, you have no choice but to take a seige >mentaility where it is easier to throttle all outside traffic through >a few machines and slam the doors on almost all the ports and enforce >proxies for everything else. That's nearly the only way that you can have >a warm-n-fuzzy feeling about the security of your network. "A warm and fuzzy feeling" is not in any way synonymous with "secure". If you want to be that secure, just unplug the routers and run an entirely isolated network. Adopting a siege mentality is a very poor alternative to actually assessing the risks and benefits of various network services realistically. >So don't berate sysadmins because in the very long run, they may >even have your best interests at heart. So what do you reckon the security risks of opening an outgoing port constitute ? AFAICS, there are three main ones to consider: possibility of corporate secrets leaking out (but then again, do you cryptanalyze all the outgoing email?), possibility of internal network configuration info. that would be useful to hackers leaking out, and possibility of an internal user connecting to an evil remote site that sends them back a buffer overflow instead of valid CVS (in this particular case) data. The first is a social problem that simply cannot be addressed by a technological fix in the first place. The second is more real, although you'll probably have a 10.x.x.x or 192.168.80.x internal network with NAT or SOCKS proxying through the firewall, so nothing but your firewall's IP should be transmitted; and the third is very very unlikely to be the case for the Gnu/Gcc CVS server. Security isn't just about locking everything down tight; it's about evaluating risk. Where's the risk in allowing outgoing CVS? DaveK -- " So far, science's crowning achievement, the Atomic Bomb, has not even been able to alleviate the misery and torture of endless centuries of world poverty." - George Hammond, self-proclaimed discoverer of the scientific proof of god. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |