At 11/9/2001 11:27 AM -0500, you wrote: > > > > > > By some sources, over 80% of attacks, thefts, sabotages, etc. are > internal. > > > >I'm a statistician by training and my education says that most such >statistics are BULL! Actually they are quite meaningless as a >generalization.
Mark Twain said: "There are three kinds of lies: lies, damned lies, and statistics." I won't go into the obvious implications for statisticians <grin>, but I do feel that YMMV can be taken a little too far, and in fact used to manipulate the truth. Secondly, you should be careful to question or understand someone well before judging their statements. Thirdly, I don't give a damn what your education says; I will, however, respect *your* opinion despite finding it not-fully-thought-out. Note that I included "attacks, thefts, sabotages, etc." implying that I was lumping a great deal of problems into a single category. I stand by that statement (despite my academic training in finance, statistics, and mathematical probability modeling). Example 1: Often customer lists are stolen by an employee leaving for another company, along with price lists, costing information, and other valuable information. Direct damage? None. Indirect damage? Immense. Solvable by ssh? No. Internal attack/theft/etc.? Hell yes. Example 2: When everyone has access to files, and one blithering idiot clicks on a virus which infects the entire company and brings down the server, a great deal of money can be lost. Solvable by ssh? No. Internally caused? Yes. I'm not going to bother going on, but I'll also note that many exploits can only be used by people who already have local access, who then get elevated privileges. Victims of social engineering, people who share passwords with family so they get free Internet access at home, there are thousands of ways in which internal factors cause loss, damage, destruction, or denial of service. There are not that many ways in which outsiders can do this, although there are more of them trying. Result? Studies by PwC, KPMG, McKinsey, Accenture (née Andersen Consulting), and many many others hold that the "large majority" (there, you happier?) of damage and losses is caused by internal factors. >E.g. if the local environment is such that everyone has read access to >each others' files anyway, then password stealing locally is probably not >going to be attributed a high probability, but even in that environment, >external threats will be regarded as being much more likely and the >effects much more damaging. Really? The value of that information and how it could be sold, stolen, altered, erased (erroneously or otherwise) seems to have escaped you. Anytime you have a difference between the perception of value between two people for the same factor, the potential for misconduct rises. I've seen small businesses crumble when the secretary sold confidential information to someone else. Read your Shakespeare: you are always most vulnerable to those nearest you. > > > By my own consulting practices, a *huge* percentage of problems are > > > internally-caused. > > > >Maybe so, in the type of environments you consult in! Kindly present a scenario we can discuss in which internal factors should be disregarded as a potential source of problems or loss. >And in those environments, where the company's secrets are all online >and industrial espionage might have enormous consequences, it might pay >to be careful, even approaching paranoia. Paranoia is the unjustified belief that someone is "out to get you." In today's world, with Nimda and Code Red and crackers galore and script kiddies at 3-for-a-dollar and virii and industrial espionage and God-knows-what-else... in that world, anyone with any real secrets can be SURE that someone, somewhere, wants to break into their systems and damage/steal their data for some reason. >However, in the majority of environments that I install, local problems >are of almost no consequence. Really? Again, I'd be happy to discuss specifics. Your cases, your examples. I'll show you that locals can and do cause problems, even if unwittingly. Come on... you never had an idiot do "format c:/" before? > As I said, YMMV. Within reason, yes. >In my opinion, we should try to use ssh whenever possible. We can >take to carrying a floppy with putty on it, for example, so that >if we get caught at a PC without an ssh client, we can still use >ssh. Agreed. > However, if it is not possible at that moment, then, instead of >letting it keep work from being done, we might be able to proceed with >the telnet or ftp and then we should be responsible for changing >the password as soon as possible (using a secure connection of course). 1. I've seen machines hacked within 10 minutes of being put online. 2. All my machines with SSH also run Webmin, so I can get to them and run my ssh session from any computer, anywhere on Earth, having just a browser. *Those* come standard out of the box pretty much anywhere. >Or, like I said, in some local environments, you might not have to care. Sooner or later you will have to care. I've also seen small networks (including mine, several times) in which someone installed a password sniffer (twice external, three times internal) but where the constant use of ssh, ssh tunnels for ftp, sftp, and rsync over ssh prevented the bastard from getting any more information. One machine hacked, 9 servers intact. >If you anticipate having to use ftp on an open wire, why not first set >your password to something you might not mind being captured! :-) I mind anything being captured. Someone can install a keypress monitor on my account in seconds, then when I change the password he still has the new one. What's your point? >Then, change it as soon as possible after using it. You keep saying "as soon as possible". What (in seconds, minutes, hours, or days) do you consider an acceptable period of time? >Then, you have minimized the exposure. No. Minimizing is reducing to a minimum (pardon the obviousness). You have rendered your account totally vulnerable for only a short period of time, which is less dangerous than leaving it open for more time. But minimized exposure? Not even close. >Because it is NOT THERE OUT OF THE BOX on most of the desktop boxen out >there (from Mr. Bill and Co.). See my note on Webmin above. I've created at least four different solutions for customers to get secure access to boxen without resorting to telnet; you just need to be a little more creative. > > > Heck, on my internal network SSH is much *easier*. I set up the right > keys, > > > and now I type one password when logging in then get access to > everything, > > > properly authenticated, transparently. > >Yes, you're lucky. Ah, a statistician who believes in luck? >But do you have a mixture of Win95, Win98, NT, Macintosh, and >Linux boxes on your LAN? I often do. I have not found it easier >in that case. You have not thought about it enough. So far, Webmin is my favorite way around this problem, and I've used it on Win9x, NT/2K, Mac, Linux, Solaris, and OS/2. No need to control any box but the one to which I want access, no need for anything on the client other than a browser. >Yes, but why stand on your head if you don't have to? My point is that, in this case, it is my professional judgment that you have to. If you're an airport manager this month, why increase the hassle for passengers if you don't have to? Because your perception is that the risk justifies the precautions. Same reasoning exactly. >If telnet is there >out of the box, but ssh is not, then it might amount to standing on your >head to get ssh there if all you needed was to quickly check on something >that was time crucial. Way the risks against the rewards. Nothing is so "time crucial" that it justifies my risking the total loss of a server or network for a minimum of four hours of downtime while I do a full format, reinstall, and restore in the unlikely case it's hacked. <weighing...> Nope, not worth it. The case you're presenting shows carelessness and ill-preparedness on the part of the network administrator, forcing him/her to accept hugely-increased risks to correct a situation not properly planned for. >And it might be appropriate where you work. It's appropriate in my *house*, where my sister once visited and infected my wife's computer with some virus from some stupid email, which then ripped my network to shreds and trashed my (then) Windows server, formatting the entire box. I am not today aware of any environment where I wouldn't take the time and effort to set it up right the first time. >However, my observation of 25 years in the IT support business leaves me >with the feeling that policies are often crafted by... Idiots, definitely. Often, at least. But still, you'll find that even non-fascist, non-condescending, non-lazy admins guard information very tightly, as they are responsible for the safety and integrity of a company asset that only becomes more valuable with time. Still, you should be ashamed of yourself, criticizing generalizations and then using such statements to argue your point. It's even worse when you recognize you're doing it! >Now, maybe there are environments where a high degree of paranoia is >appropriate and maybe from experience in that environment, users can NOT >be trusted for some things, Extreme example: my neighbor's wife cannot be trusted with any of his financial information. Why? She clicks on email attachments. There is a computer in the house from which she can see anything she likes, so secrecy and human trust are not the issue. But *her* computer is forbidden to have anything on it. Fascist, untrusting, lazy? No, careful and considering the local environment. >I also think it's important to help users be as productive as possible, and >delaying work until putty or something is installed is not always the most >productive approach. When is it that workers *need* a shell in which to do work, but they find themselves in an environment where no secure shell is available? I find this scenario downright unrealistic. Jerry, I understand what you're saying... I just really think you need to put more time and thought into this. The risks today--at home, at work, at school--are high enough that telnet has ceased to be a viable option for the real world, IMHO. Should you choose to disagree, fine. But the arguments you have presented here are insufficient to make a case for telnet being OK, even in a "closed" environment. -- Rodolfo J. Paiz [EMAIL PROTECTED] _______________________________________________ Redhat-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-list
