If passwords are at fault and sshd was the service that was comprimised then get rid of the passwords and use RSA challenge-response authentication.
Unfortunately, I believe that that's already the case, and has been for as long as I've been a Debian developer. I believe what really happened is that somebody's home account or something was compromised, and they did the stupid passwordless ssh key thing (instructions for which are even on the Debian devel web site!). Even if they didn't use passwordless keys, rootkits with tty-loggers make it pretty easy to sniff a key's password if it's typed over the network.
Don't offer services that can be used to administer system to the public internet.
This is simply not an option for Debian or a large number of other self-hosting open source projects. The Debian sysadmin team has people located all over the world. Additionally, while you may consider sshd to be a service used only by sysadmins, that's certainly not the case in the Debian project. There are a number of machines that are accessable to all Debian developers for various reasons. These all run sshd, which is very likely the entry vector used by the attacker, if it was indeed a compromised password that allowed their entry.
That may be true, but you can bet if I were to ask my ISP for three "extra" IPv6 addresses they'd whack up my monthly bill. With NAT they never have to know.
Yes, and this kind of thing has actually seen some discussion within the IETF IPv6 working group. IPv6 changes that aspect of the ISP business model, but they have absolutely no excuse for not offering larger netblocks. Hopefully the markets will figure this kind of thing out, and consumers will start demanding larger netblocks. That will be especially likely if we avoid creating some kind of NAT workalike for IPv6!
Oh, and another point. A lot of people seem to like NAT because it allows somebody to buy a cheap little Linksys box, plug it in, and start networking. The thing is, you can do all that in IPv6 without NAT, and there's no reason that such an IPv6 device can't offer the same kind of limited access that's we've grown accustomed to with IPv4 NAT boxes.
Get this through your head: NAT != firewall
In case you missed that, let me say it again: NAT != firewall
NAT was not designed for security. It was designed to delay the end of the world until IPv6 could come and save it (OK, that's a bit of a parabole...sue me).
Firewalls are just as (in-)effective in a NAT-free environment. NAT is just as (in-)effective in a firewall-free environment. By exchanging NAT for IPv6, you aren't "giving up" any functionality, you're gaining it, and giving up a nasty kludge that never should have been invented.
Linux is only considered more secure than windows because it has less attacks. Not to mention the script kiddies don't bother to learn Linux, they learn Windows which is on their systems at school, work, home, at the library, at kinkos, at their friends houses.... etc...
This crap got modded up??? I felt sure when I first saw the comment that it would it -1 at mach 3. Especially in light of articles like this one.
Not only that, but if you think about it, blaster and slammer and all those thing... They were only single "attacks", writen presumably by one single person. The nature of the insecurities is what allowed these worms to be as disruptive as they were. You imply with your post that the security of a system is inversely proportional to the scale of the deployment of that system. I'd love to see some evidence of that.
The thing is, it was a LOCAL exploit. That means the bad guy had an account.
That's by no means a valid assumption. Consider a remote non-root exploit coupled with a local root exploit. Not that uncommon. Figure that at this point, most network services don't run as root, and you can fairly easily envision a situation in which such a series of compromises might have lead to this situation.
Part of what you need in a security system is a guarantee that a communications session will be encrypted. Without that guarantee, you can not trust the connection. Opportunistic IPsec does not provide you with any guarantee that communication with a given host is encrypted. If possible, it will be, but it just as well may not.
One must understand the rationale for developing opportunistic encryption. It is not to provide for secure communication. It exists to clog the spooks' sniffers with as much unusable data as possible. There is a distinction there. Yes, for the purposes of the data contained within that IPsec payload the result is the same, but users would be absolutely insane to switch from ssh to telnet+opportunistic IPsec and expect the same level of protection.
IPsec in general is a very different story, and something that I use extensively in production.
So you changed your mind? A few lines up you say it's because of SFU (a suite of *applications* which were distributed for *years* without any IP-issues already), now all of the sudden you think they will port "Unix code" to Windows?
Changed my mind? I have been entirely consistant in what I've said. A license for the Unix source code does not merely cover the Unix kernel. It includes core utilities and libraries. Microsoft licensed this code to port to Windows. I've made no claims to the contarary, and have provided evidence (which you convenently chose to completely ignore in your reply) to back that up. For the record a previous slashdot story linked to this Linux Business Week article. You should read it. Since you probably won't, I'll include this quote from the article: "...if we didn't have any actual use for the license, it absolutely would not have happened. The fact that the license would make it easier to enhance future versions of Services for Unix was a deciding factor."
Oh sure. The line "valid reason why Microsoft would have bought a license for the Unix source code" thus trying to indicate that SCO owns "the Unix source code" is FUD in a pure form. SCO owns parts of a very outdated source (over 10 years old) which is mostly (in the form of BSD) in the public domain anyway.
First of all, the BSD code is not in the public domain. Second of all, I never claimed to support SCO's claim to own the Unix source. Whether they do or not is debatable, apparently, and I hope Novell turns out to be right. What is not in question, though, is that SCO definitely does have the sole rights to license the source to SystemV. Third, your claim that SystemV code and BSD code are (mostly) the same is complete nonsense. BSD was forced to remove all the SystemV code as a result of the USL lawsuit. There is no SystemV code in BSD. (That's not to say that there's no BSD code in SystemV, although the terms of the settlement of the USL lawsuit specifically stated that no more BSD code would be incorporated into SysV than was already there at the time of the settlement.)
Microsoft is not funding SCOs attack against Linux. A Unix source license would pay for SCO's lawyers for what, an hour two worth of work? It takes a fairly large team of high priced lawyers to attack IBM, and this does not come cheap. A single Unix source license is not particularly significant here.
This product has been around for 5+ years. If it had SysV code, MS wouldn't have waited this long to buy a licence -- they would have sued by SCO long ago.
Perhaps, but they did just release a new version. Perhaps they licensed the code for it? Or for the next version. Who knows. It's certainly a possibility, and honestly, I believe it's more likely that they bought the license for this or a similar product than it is that they simply wanted to fund somebody else's legal battle against Linux. A previous slashdot article would seem to back my theory up, and in fact mentions Services for Unix directly.
I hate to rain on your FUD-parade, but programming and/or offering Unix applications doesn't require a license from SCO. You know that just as well as I do.
Do you honestly think Microsoft wrote all their own libraries and Unix tools? They claim that Services for Unix (which runs on Windows not on Unix) includes 300 Unix utilities and 1900 Unix API calls. It makes perfect sense that they would license the code for those utilities and libraries from SCO.
You insult my intelligence by posting such nonsense.
Insults are not necessary. I don't believe you understand the situation. You made it very clear above that you believe that Services for Unix runs on Unix, which betrays your ignorance.
Even Microsoft itself has admitted that the license itself wasn't really the reason for the purchase, they have stated that they wanted to "support" SCO because they treat that valuable IP the right way.
So better check with your local MSFT-representative to get your FUD inline with the official partyline from Redmond.
Again, before resorting to insults, I think you need to get yourself a clue. I am spouting no Microsoft party line FUD or anything along those lines. I do not run Microsoft software on any of my machines, and am a Free Software developer. I am merely stating that there is absolutely a valid reason why Microsoft would have bought a license for the Unix source code: To port it to Windows. You, on the other hand, are merely an ignorant troll.
(Conspiracy theorists are no doubt convinced that there's GPL code in it as well. Maybe they're right, who knows?)
Before somebody out there calls me an idiot or worse, let me reply to my own comment and say that I've since noticed that yes, Services for Unix definitely does include GPL code. In binary and source form, per the license.
That's right. Microsoft actually ships GPL code and complies with the license.
Given the fact that Microsoft is financing SCO's anti-Linux crusade (or do you really believe that they pay millions for a license they don't need?), I can't agree with you.
They do need the license. Microsoft has a product called "Services for Unix", which is basically something along the same lines as Cygwin. This undoubtedly has SysV code in it, and most likely BSD code as well. This is why they licensed the code from SCO.
(Conspiracy theorists are no doubt convinced that there's GPL code in it as well. Maybe they're right, who knows?)
Exim has the same bad monolithic setuid-root style design as sendmail and even more useless (for the majority of people) features.
Hold on just a second:
mail 145 0.0 0.2 6288 276 ? S Mar05 1:09/usr/sbin/exim -bd -q30m
Yes, the daemon needs to be root initially, but it drops root privilages ASAP and does not, in fact run as root (unless you're insane and configure it to do so). Yes, it is a monolithic design, which may turn you off, but a remote exim exploit is not an automatic remote root exploit.
Personally, I like Exim a lot, and I haven't even upgraded to version 4 yet. Just be glad you have a choice of MTAs and aren't stuck with sendmail, as was the case not too long ago. (Though to be fair, sendmail is getting significantly better!)
I recently spent a lot of money on a 9700 Pro, which is currently sitting atop my machine, useless. The reason? ATI won't release a driver that works with xfree 4.3.0, and after several mails told me to just keep an eye on their site for updates. I know there are open source drivers (2d only) for the card, but those gave me really nasty rasterline flashes whenever the card did anything - so were next to useless.
It's your own damn fault, really. I recently bought an ATI AllInWonder 8500, which has kickass fully Open Source Linux drivers. I bought this card because some quick research revealed two things: 1. Its 3d performance is more than enough for my needs and 2. Quality drivers are available. Quality drivers will be available for your 9700 Pro, but maybe not for some time.
Personally, I'm not a bit upset with the way ATI handles their Linux users. I much prefer it to NVidia's binary only crap. While the full programming specs may not always be available for the latest and greatest ATI cards, they are available for stuff that's not far behind (http://dri.sourceforge.net/ indicates that Radeon cards up to the 9200 are supported.) Not only are the drivers available, but because the specs are there, the drivers can be ported to any platform, not just those that some commercial interest feels is worth its money. NVidia won't release PowerPC Linux drivers, so I'm stuck doing software OpenGL on my G4. If the G4 had a Radeon I would not have this issue.
ATI really should be commended for making the necessary info available to the DRI and XFree86 developers to write quality open source drivers.
Slashdot seems to have a short attention span, so I doubt anybody will actually read this post, but here goes...
The big question is - Is it compatible? and will FreeS/WAN evolve to use the IPSEC implementation.
Yup, it's compatible. I've already tested the 2.5 IPsec implementation against freeswan 1.9x. No problems there. Linux IPsec uses the KAME racoon and setkey programs for IKE, which are well tested against freeswan. IKE is the hard part, and when people complain about IPsec interoperability, that's what they usually are complaining about. When that works, it's pretty easy to get AH/ESP working.
Freeswan's IKE implementation (pluto) could probably be ported to the Linux IPsec stack. In fact, the USAGI project (www.linux-ipv6.org) already uses a modified pluto for their IKE implementation, and much of the USAGI IPsec code seems to what's going into the Linux tree.
I don't see why so many people at/. cheer Gov't getting involved in the spam problem. I have been using CRM-114 and SpamAssassin for several months and the result is: it works. I get something like 4-5 times as much spam as non-spam, and *VERY* rarely does a spam message find its way into my inbox now.
That doesn't do anything at all to stop spammers. Even if all that spam wound up in your inbox, you'd never give a penny to any of the people who sent it. Neither would 99% of the other recipients. Spammers know that, but it doesn't matter to them because it costs so little to send the spam. So basically, who cares if you use SpamAssassin and CRM114? The spammers sure don't.
PS: I know people might say, but what about the economic cost of spam, blah blah blah. Read the slides. If no one ever gets spam, people will stop sending it, and the economic cost goes away.
Until filters can guarantee 0 false positives, they can't be deployed at a lot of sites.
I hate having to resort to legislation to stop spam, but I really don't think filters will ever solve the problem. Maybe they'll hide most of the symtoms as far as you're concerned, but the spam still wastes bandwidth and now wastes even more CPU cycles since you have to process all your incoming mail so heavily to try and identify it. That's theft of service, and it needs to be stopped.
I'm not even sure there is a truly complete IPv6 implementation.
Of course there is. All free OSes have very good IPv6 support, as do WinXP, Solaris, and probably other commercial operating systems. I think MacOS X Jaguar supports it too.
The iputils packages in Linux give you ping6, tracepath6, and traceroute6; similar tools exist for all other OSes that I've ever used. Hell, the WinXP ping can speak IPv6.
See a post I made the other day about some services I run over IPv6. Namely web, ftp, and rsync.
All the basic tools you need support IPv6. Some of the more advanced stuff like mobile IPv6 and anycast are still at various fairly early stages of development, but you probably won't notice their absense any time soon.
It does read like propaganda, but I have to wonder about the target audience of Government Executive Magazine. I don't think it reaches the type of people you'd like to influence with propaganda...
Who knows. The story was certainly amusing, in any case.
Mommy, when I grow up, I want to be a cyber investigator! I'm going to start practicing my cyber jargon now so one day I might get to break down a hacker's door and yank him off his keyboard.
I wonder if the feds will let the author sell that story as the screenplay to Hackers 2.
Man, I can't believe how many people are saying this... Un-verifiable certificates are a bad thing! Yes, the allow you to encrypt your traffic, so you can communicate in such a way that an evesdropper can't sniff your traffic, but they can easily defeat your security with a man-in-the-middle attack. You need a well developed web of trust or a trusted 3rd party to verify the identity of the party to whom you're communicating.
You folks probably don't verify the SSH host key when you log in to a new system, either, do you?
I never understood and still don't get why people get their panties all in a bunch about a few emails from businesses that they have to read through and delete or whatever.
And what do you say to the ISPs whose mail servers fall over due to the load imposed by spam attacks?
What do you say to those who have to pay for Internet access based on the amount of data they transfer? They certainly never asked for the spam that's costing them money.
And you certainly can't claim that relay raping is anything but network abuse.
Spam is not welcome. I never asked for it. My having a mailbox is not an open invitation for unsolicited commercial email.
Now I can add a compromised md5sum to my rootkit which uses values from this site.
Come on. This is a database of known good md5 checksums. It's not a database of known good output from some program. md5sum is no less vulnerable to rootkits than any other program on the system, but that hardly makes this a useless database.
Umm, what does "secure and hardened" have to do with backups? From my experience, secure and hardened is often counter to backups. Every additional copy of the data you have is an additional security concern.
That said, people are currently working on restoring the machine now, and the rough ETA is given as tomorrow. So backups are not an issue.
Slashdot Mirror
Unfortunately, I believe that that's already the case, and has been for as long as I've been a Debian developer. I believe what really happened is that somebody's home account or something was compromised, and they did the stupid passwordless ssh key thing (instructions for which are even on the Debian devel web site!). Even if they didn't use passwordless keys, rootkits with tty-loggers make it pretty easy to sniff a key's password if it's typed over the network.
noah
This is simply not an option for Debian or a large number of other self-hosting open source projects. The Debian sysadmin team has people located all over the world. Additionally, while you may consider sshd to be a service used only by sysadmins, that's certainly not the case in the Debian project. There are a number of machines that are accessable to all Debian developers for various reasons. These all run sshd, which is very likely the entry vector used by the attacker, if it was indeed a compromised password that allowed their entry.
noah
Yes, and this kind of thing has actually seen some discussion within the IETF IPv6 working group. IPv6 changes that aspect of the ISP business model, but they have absolutely no excuse for not offering larger netblocks. Hopefully the markets will figure this kind of thing out, and consumers will start demanding larger netblocks. That will be especially likely if we avoid creating some kind of NAT workalike for IPv6!
Oh, and another point. A lot of people seem to like NAT because it allows somebody to buy a cheap little Linksys box, plug it in, and start networking. The thing is, you can do all that in IPv6 without NAT, and there's no reason that such an IPv6 device can't offer the same kind of limited access that's we've grown accustomed to with IPv4 NAT boxes.
noah
NAT != firewall
In case you missed that, let me say it again:
NAT != firewall
NAT was not designed for security. It was designed to delay the end of the world until IPv6 could come and save it (OK, that's a bit of a parabole...sue me).
Firewalls are just as (in-)effective in a NAT-free environment. NAT is just as (in-)effective in a firewall-free environment. By exchanging NAT for IPv6, you aren't "giving up" any functionality, you're gaining it, and giving up a nasty kludge that never should have been invented.
It's time for NAT to die a long overdue death.
noah
This crap got modded up??? I felt sure when I first saw the comment that it would it -1 at mach 3. Especially in light of articles like this one.
Not only that, but if you think about it, blaster and slammer and all those thing... They were only single "attacks", writen presumably by one single person. The nature of the insecurities is what allowed these worms to be as disruptive as they were. You imply with your post that the security of a system is inversely proportional to the scale of the deployment of that system. I'd love to see some evidence of that.
noah
You're right. In fact, it's good enough that taco would probably lift the 120 char limit just to let it through!
noah
That's by no means a valid assumption. Consider a remote non-root exploit coupled with a local root exploit. Not that uncommon. Figure that at this point, most network services don't run as root, and you can fairly easily envision a situation in which such a series of compromises might have lead to this situation.
noah
One must understand the rationale for developing opportunistic encryption. It is not to provide for secure communication. It exists to clog the spooks' sniffers with as much unusable data as possible. There is a distinction there. Yes, for the purposes of the data contained within that IPsec payload the result is the same, but users would be absolutely insane to switch from ssh to telnet+opportunistic IPsec and expect the same level of protection.
IPsec in general is a very different story, and something that I use extensively in production.
noah
Changed my mind? I have been entirely consistant in what I've said. A license for the Unix source code does not merely cover the Unix kernel. It includes core utilities and libraries. Microsoft licensed this code to port to Windows. I've made no claims to the contarary, and have provided evidence (which you convenently chose to completely ignore in your reply) to back that up. For the record a previous slashdot story linked to this Linux Business Week article. You should read it. Since you probably won't, I'll include this quote from the article: "...if we didn't have any actual use for the license, it absolutely would not have happened. The fact that the license would make it easier to enhance future versions of Services for Unix was a deciding factor."
Oh sure. The line "valid reason why Microsoft would have bought a license for the Unix source code" thus trying to indicate that SCO owns "the Unix source code" is FUD in a pure form. SCO owns parts of a very outdated source (over 10 years old) which is mostly (in the form of BSD) in the public domain anyway.
First of all, the BSD code is not in the public domain. Second of all, I never claimed to support SCO's claim to own the Unix source. Whether they do or not is debatable, apparently, and I hope Novell turns out to be right. What is not in question, though, is that SCO definitely does have the sole rights to license the source to SystemV. Third, your claim that SystemV code and BSD code are (mostly) the same is complete nonsense. BSD was forced to remove all the SystemV code as a result of the USL lawsuit. There is no SystemV code in BSD. (That's not to say that there's no BSD code in SystemV, although the terms of the settlement of the USL lawsuit specifically stated that no more BSD code would be incorporated into SysV than was already there at the time of the settlement.)
Microsoft is not funding SCOs attack against Linux. A Unix source license would pay for SCO's lawyers for what, an hour two worth of work? It takes a fairly large team of high priced lawyers to attack IBM, and this does not come cheap. A single Unix source license is not particularly significant here.
noah
Perhaps, but they did just release a new version. Perhaps they licensed the code for it? Or for the next version. Who knows. It's certainly a possibility, and honestly, I believe it's more likely that they bought the license for this or a similar product than it is that they simply wanted to fund somebody else's legal battle against Linux. A previous slashdot article would seem to back my theory up, and in fact mentions Services for Unix directly.
noah
Do you honestly think Microsoft wrote all their own libraries and Unix tools? They claim that Services for Unix (which runs on Windows not on Unix) includes 300 Unix utilities and 1900 Unix API calls. It makes perfect sense that they would license the code for those utilities and libraries from SCO.
You insult my intelligence by posting such nonsense.
Insults are not necessary. I don't believe you understand the situation. You made it very clear above that you believe that Services for Unix runs on Unix, which betrays your ignorance.
Even Microsoft itself has admitted that the license itself wasn't really the reason for the purchase, they have stated that they wanted to "support" SCO because they treat that valuable IP the right way.
I do not believe that is the case. Care to provide a reference?
So better check with your local MSFT-representative to get your FUD inline with the official partyline from Redmond.
Again, before resorting to insults, I think you need to get yourself a clue. I am spouting no Microsoft party line FUD or anything along those lines. I do not run Microsoft software on any of my machines, and am a Free Software developer. I am merely stating that there is absolutely a valid reason why Microsoft would have bought a license for the Unix source code: To port it to Windows. You, on the other hand, are merely an ignorant troll.
noah
Before somebody out there calls me an idiot or worse, let me reply to my own comment and say that I've since noticed that yes, Services for Unix definitely does include GPL code. In binary and source form, per the license.
That's right. Microsoft actually ships GPL code and complies with the license.
noah
They do need the license. Microsoft has a product called "Services for Unix", which is basically something along the same lines as Cygwin. This undoubtedly has SysV code in it, and most likely BSD code as well. This is why they licensed the code from SCO.
(Conspiracy theorists are no doubt convinced that there's GPL code in it as well. Maybe they're right, who knows?)
noah
Hold on just a second:
Yes, the daemon needs to be root initially, but it drops root privilages ASAP and does not, in fact run as root (unless you're insane and configure it to do so). Yes, it is a monolithic design, which may turn you off, but a remote exim exploit is not an automatic remote root exploit.
Personally, I like Exim a lot, and I haven't even upgraded to version 4 yet. Just be glad you have a choice of MTAs and aren't stuck with sendmail, as was the case not too long ago. (Though to be fair, sendmail is getting significantly better!)
noah
It's your own damn fault, really. I recently bought an ATI AllInWonder 8500, which has kickass fully Open Source Linux drivers. I bought this card because some quick research revealed two things: 1. Its 3d performance is more than enough for my needs and 2. Quality drivers are available. Quality drivers will be available for your 9700 Pro, but maybe not for some time.
Personally, I'm not a bit upset with the way ATI handles their Linux users. I much prefer it to NVidia's binary only crap. While the full programming specs may not always be available for the latest and greatest ATI cards, they are available for stuff that's not far behind (http://dri.sourceforge.net/ indicates that Radeon cards up to the 9200 are supported.) Not only are the drivers available, but because the specs are there, the drivers can be ported to any platform, not just those that some commercial interest feels is worth its money. NVidia won't release PowerPC Linux drivers, so I'm stuck doing software OpenGL on my G4. If the G4 had a Radeon I would not have this issue.
ATI really should be commended for making the necessary info available to the DRI and XFree86 developers to write quality open source drivers.
noah
The big question is - Is it compatible? and will FreeS/WAN evolve to use the IPSEC implementation.
Yup, it's compatible. I've already tested the 2.5 IPsec implementation against freeswan 1.9x. No problems there. Linux IPsec uses the KAME racoon and setkey programs for IKE, which are well tested against freeswan. IKE is the hard part, and when people complain about IPsec interoperability, that's what they usually are complaining about. When that works, it's pretty easy to get AH/ESP working.
Freeswan's IKE implementation (pluto) could probably be ported to the Linux IPsec stack. In fact, the USAGI project (www.linux-ipv6.org) already uses a modified pluto for their IKE implementation, and much of the USAGI IPsec code seems to what's going into the Linux tree.
noah
I'm changing the text on the plaque on my office door tomorrow. I love it.
noah
That doesn't do anything at all to stop spammers. Even if all that spam wound up in your inbox, you'd never give a penny to any of the people who sent it. Neither would 99% of the other recipients. Spammers know that, but it doesn't matter to them because it costs so little to send the spam. So basically, who cares if you use SpamAssassin and CRM114? The spammers sure don't.
PS: I know people might say, but what about the economic cost of spam, blah blah blah. Read the slides. If no one ever gets spam, people will stop sending it, and the economic cost goes away.
Until filters can guarantee 0 false positives, they can't be deployed at a lot of sites.
I hate having to resort to legislation to stop spam, but I really don't think filters will ever solve the problem. Maybe they'll hide most of the symtoms as far as you're concerned, but the spam still wastes bandwidth and now wastes even more CPU cycles since you have to process all your incoming mail so heavily to try and identify it. That's theft of service, and it needs to be stopped.
noah
Of course there is. All free OSes have very good IPv6 support, as do WinXP, Solaris, and probably other commercial operating systems. I think MacOS X Jaguar supports it too.
The iputils packages in Linux give you ping6, tracepath6, and traceroute6; similar tools exist for all other OSes that I've ever used. Hell, the WinXP ping can speak IPv6.
See a post I made the other day about some services I run over IPv6. Namely web, ftp, and rsync.
All the basic tools you need support IPv6. Some of the more advanced stuff like mobile IPv6 and anycast are still at various fairly early stages of development, but you probably won't notice their absense any time soon.
noah
Who knows. The story was certainly amusing, in any case.
noah
I wonder if the feds will let the author sell that story as the screenplay to Hackers 2.
noah
Man, I can't believe how many people are saying this... Un-verifiable certificates are a bad thing! Yes, the allow you to encrypt your traffic, so you can communicate in such a way that an evesdropper can't sniff your traffic, but they can easily defeat your security with a man-in-the-middle attack. You need a well developed web of trust or a trusted 3rd party to verify the identity of the party to whom you're communicating.
You folks probably don't verify the SSH host key when you log in to a new system, either, do you?
noah
And what do you say to the ISPs whose mail servers fall over due to the load imposed by spam attacks?
What do you say to those who have to pay for Internet access based on the amount of data they transfer? They certainly never asked for the spam that's costing them money.
And you certainly can't claim that relay raping is anything but network abuse.
Spam is not welcome. I never asked for it. My having a mailbox is not an open invitation for unsolicited commercial email.
noah
Come on. This is a database of known good md5 checksums. It's not a database of known good output from some program. md5sum is no less vulnerable to rootkits than any other program on the system, but that hardly makes this a useless database.
noah
That said, people are currently working on restoring the machine now, and the rough ETA is given as tomorrow. So backups are not an issue.
noah