Date: Tue, 31 Jul 2001 07:27:43 -0500 From: Mike Meyer <mwm@mired.org> To: "Ted Mittelstaedt" <tedm@toybox.placo.com> Cc: <questions@FreeBSD.ORG> Subject: RE: URGENT - Seems like i've been hacked... what to do now? Message-ID: <15206.42047.35149.695150@guru.mired.org> In-Reply-To: <005f01c119a1$6b005ee0$1401a8c0@tedm.placo.com> References: <15205.18337.148080.887001@guru.mired.org> <005f01c119a1$6b005ee0$1401a8c0@tedm.placo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ted Mittelstaedt <tedm@toybox.placo.com> types: > >If I happen > >> to get called in to the company to do something, I'm not going to find a > >> convenient system that's got an SSH client installed, although all of the > >> systems have Windows Telnet on them. > >Been there, done that. Putty is free, available over the network, and > >takes just a few minutes to install. > > Except that with the customers I've dealt with the second I install anything > on a customer system I will end up getting 3 calls over the subsequent 2 weeks > from the customer complaining that I "broke" their system by installing > something on it. Of course the problem would not be the installation of > Putty, but you can't convince a fool with a head of stone of that. That would probably stop me, but my customers don't seem to be that stoneheaded. That might be related to my pretty much refusing to have anything to do with actually supporting Windows. If I'm generating calls for their IT department - well, I probably asked their IT department and got told they wouldn't support so I should install it myself. > > SSH is > >freely available for most boxes with CPUs, has almost no cost, and > >significantly reduces the risk associated with sending passwords over > >the network. > > And in hostile networks you need to have them. For example, I'd avoid doing > anything unencrypted over a college dormotory network, you just know that > there's a dozen wannabies running sniffers on that. But in internal corporate > networks they have ways of dealing with smart asses that think they are going > to sniff the administrators passwords that are far more effective than SSH. That's certainly true - I'm much more lax about security behind a firewall I trust. I thought we were talking about machines that were being access from the internet - which I consider to be a hostile network. > >This is a stupid thing from a security perspective, but has absolutely > >nothing to do with either the cost of installing ssh, or the risks it > >helps reduce. ssh reduces the risks associated with sending passwords > >around the network. That the machines are trivialy stolen doesn't > >change either that risk or the costs associated with installing > >ssh. While you might spend less on other security measures because one > >specific one is poor, neglecting them is a bad idea. > If ONE security measure is deliberately forced to be insecure, then your > better off from a political standpoint to simply declare the server totally > insecure and don't even bother with spending time to support security measures > on it. Otherwise all you do is give a security blanket to the users to make > them feel safe that actually provides no real security. Well, I can understand the argument, but I don't agree with it. Opening up a machine to people who don't have physical access to it just because there's no physical security is foolish. Did you actually go through with this and not bother with setting a root password on the machines? > To do the security thing right it's either an all or nothing proposition. Now you're contradicting yourself. Earlier, you said: Security is all about weighing risks. which I agree with. You weigh the risks, and decide whether or not the worst risks outweigh the costs of eliminating them. > Either you lock the entire thing down, disable Telnet and only run SSH, > physically secure it and control access to it and to the network, That's not "all". That's what I consider "minimal security for a machine exposed to a hostile network." "All" means you put the machine in a faraday cage, and don't allow anyone in the cage without a security clearance and a physical search. If you've got to expose a machine to the network, you use ssh to encrypt the challenge-response from a system that uses a physical tool to generate the response, so that breaking in over the network involves having the users password *and* their response generator. > or you just consider the system already compromised and make sure > that there's nothing of value on it. Doing a half-assed job like > your advocating to where you secure some things and not others just > leaves gaping holes and a false sense of security. The same thing could be said about the half-assed job that you're advocating. Both statements are have equal validity - none. The problem is that you're not weighing the risks, you're simply assuming that all risks have an equal weight. This is an invalid assumption, so the conclusions isn't valid. > >You wouldn't set > >the machines to not have a root password just because they have poor > >physical security. > This is just annother example of what I'm talking about. A FreeBSD system > with an unaged root password that has poor physical security is IDENTICAL to a > FreeBSD system that has no root password. Without physical security anyone > can come by and reboot the system into single user mode and reset the root > password to their own password in just a few minutes. This is only true if physical access to the machine is as cheap for the attacker as a telnet connection to the machine. That's not true even if the machine is sitting on blocks on the front lawn. The cost of physically getting to the machine is higher than the cost of a telnet connection. Putting it behind a locked door - even if a simple physical B&E will get you to the machine - raises the stakes considerably. While I can't evaluate the case you described, the cost of installing ssh and disabling telnet, or at least blocking internet access to telnet, is nearly the same as setting a root password. Since a security system is only as good as the weakest element, it may be that the physical security at the site was the weakest link even if everyones used telnet to access the machines from the internet. That doesn't seem very likely, though. > >> Anyway, the DCMA is just waiting for a court test in front of the Supreme > >> Court and it will happen eventually and the law will be tossed out and > >> that will be that. > >You give the US legal system more credit than I do. While I certainly > >hope it gets tossed out, I wouldn't bet on it. > I would - but I wouldn't bet on it being tossed out _soon_. The legal system > takes years to digest things. The war on drug abuse has been going on for over 30 years, and the large organizations profiting from it are breaking the law. In the war on cryptography abuse, the organizations profiting from it aren't breaking the law. I'd bet on it lasting longer. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. 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?15206.42047.35149.695150>
