> modern desktop distros are pretty locked down and don't have lots of > ports > open to the network the way they used to be a few years ago.
Hopefully you're just talking about modern linux desktop distros. Cuz windows and osx are pretty loose about opening things up to the network. I don't know any OS with worse security than OSX. I'll qualify that by saying by default, OSX has no firewall enabled at all, and bonjour happily broadcasts to everyone, "Bonjour, everybody! Here's a list of what services I'm running..." > I agree that most modern distros have lots of unnecessary things > running > (be they a server or desktop distro), but they are all blocked. most > desktop distros do block logins as root. To simply have unnecessary services blocked by the firewall isn't good enough. Typically if somebody's going to leverage a vulnerability to get into your server, they have to string together more than one. For example, if there's some loophole in apache that lets you run some arbitrary file on disk under the "apache" user account ... doesn't do any good unless you find some way to write a file to disk. If somebody finds a vulnerability in a service that you have available... The next thing they'll need to find is another service they can exploit. Perhaps the firewall will block them from doing this as long as they're attacking via the WAN, but if they've already compromised one service, it's pretty likely they'll use that to their advantage, and attempt making apache (or whatever they've compromised) do an attack on some other service via localhost or the LAN, where perhaps your firewall rules are circumvented. The smart thing is not to rely on your firewall to block services you have running, but instead, to disable and ideally remove those services. And an exploit doesn't necessarily have to be in a running service or daemon either. Suppose you've got some library with a flaw in it ... say ... opencv. This is a bad example because it's pretty unlikely that apache would have any binaries linked to opencv ... Well, whatever. Point is, once you've got one exploit, anything is fair game to use as your 2nd, or 3rd exploit. It could be any library, scripting language, command line tool, or anything at all ... as long as it has some vulnerability, and some way to exploit that vulnerability. Start linking things together and you've got varying degrees of control of the remote system, perhaps eventually root. The smart thing is not to assume "there's no way anybody can exploit libopencv." The smart thing is to remove libopencv as long as you know you don't need it. With some variable level of success in compromising somebody's system... you've got a system, belonging to somebody else, that you can use to store and transfer the kiddie porn you've just sold to some pervert. If anybody gets busted, you've covered your tracks. Difficult though it may be to break into somebody's system like this ... the motivation is high. And it does happen. > as for disallowing logins from any user account, if you do that, how > can > you manage the system In most cases, as you mentioned, it's not possible to disable all network login capabilities. But it can be done ... Via serial terminal concentrators ... Via KVM over IP ... Maybe even the server in question is a virtual machine, so you can first login to some other machine and then admin the server in question. All of these could allow you to admin a server remotely, despite having all network login services disabled on the server. The only way to remotely admin the server is to login to some intermediate server, and do something from there. The traffic does not necessarily need to go across the network at all. Even so, that's not really what I was suggesting. I do think most likely you'll want at least some level of ssh enabled. And you can configure it to require RSA keys for authentication instead of password. This is not "disabling all logins" but it is disabling all password logins. > I agree that it's best to not have services installed that aren't > needed, > but nowdays the difference between a 'desktop' and a 'server' is a > matter > of degree, not a matter of kind. > > the desktop and server versions of a distro have the exact same package > management tools on them, the packages have the exact same dependancy > declarations, so really the only difference between the two is the > packages installed by default. I don't believe it's possible to install Ubuntu Desktop without X11, gnome, Bluetooth, cups, ekiga, firefox, openoffice, java, libmono, perl, python, pidgin, or rdesktop. Is it? It may be true the only difference between ubuntu desktop & ubuntu server is a matter of package selection. But to an extent, you don't have control over the package selection. And that's a huge difference. _______________________________________________ Tech mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
