But broadly speaking, a "server" is anything that accepts incoming TCP/IP connections. A Bittorrent client is just as much a "server" as Postfix is.
On the other hand, if by "server-based" you meant to emphasize the client-server nature of most modern email systems, keep in mind that in the early days the very mainframe or workstation that you logged into was usually the same computer handling your email. At its inception, email was just as "P2P" as Bittorrent is today.
FUD? There's no FUD about it: if you use OpenDNS and perform a Google search, your search queries are being proxied through OpenDNS's servers. That's quite a breach of trust because -- unless they've changed something since I last checked -- this proxying of search data isn't exactly advertised to the user in advance. Even if I felt I could absolutely trust OpenDNS with all my data, such covert behavior would still make me uncomfortable.
As for the Google/Dell deal: yeah, it's evil, and the OpenDNS guys are right to bring attention to it. But it's a problem that needs to be solved at the application level, not by mucking around with users' DNS whether they're on an affected Dell or not. It's the wrong place and the wrong approach to solve this problem, and borderline creepy to boot.
I'm not sure why you're so angry with the Anonymous Coward for pointing this out; everything he said was unbiased and factually accurate. If the truth is going to "convince people not to use OpenDNS," then so be it.
May I invite you to read the comment you just replied to, particularly the part where I said:
... especially if those interactions are somehow a function of the signal's frequency.
To reiterate, we still haven't reached the point where we really understand the underlying mechanisms of cancer, not by a long shot. So to pretend that we can preclude cell phones as a potential cause of cancer when some of the empirical evidence suggests that it may be otherwise is absolutely unsound, no matter how unlikely it may seem that we'd be proven wrong on such an assumption.
However, the fact that cell phones do not produce ionizing radiation is in no sense a resounding argument for their safety. We do know that typical phone signals can result in cellular heating, and there may subtle results of this and other weak interactions that we do not yet understand, especially if those interactions are somehow a function of the signal's frequency.
We do not know enough about cellular biology to make the assumption that non-ionizing radiation is inherently safe across all frequencies and power levels, especially if the source of that radiation is a cell phone -- which puts out a fair deal more radio power than the CD players and displays you compare it to, and which is typically operated right next to one's head.
Therefore, we are not justified in categorically tossing out any new research that indicates a potential link between cell phone use and health problems. The question of cell phones and cancer does not yet have enough evidence pointing in either direction to give us a solid conclusion. So just let the scientists be scientists, since raw empirical evidence is the only way we'll ever answer this question in our lifetimes.
Just what we need -- another of the major players in Web content to fall under the News Corporation sphere of influence. As though they don't already do enough harm as it is, with their holdings in the traditional press...
"This is a technological device, and you can't outlaw it !", right ?
I don't know when you imagine Slashdot to have demonstrated an outright opposition to legal bans on technological devices, in general, on account of them being "technological". A nuclear bomb is a "technological device," but I have yet to see an impassioned argument on this site that they should be available for sale in every corner hardware shop.
If you are actually trying to equate banning the use of this particular device in order to actively discriminate against a particular group of people, to placing restrictions on Internet usage at the behest of copyright holders, then you've failed to make your case. This is an annoyance device that targets teenagers; the Internet is a fundamental enabling platform for a innumerable products and services around the world. There is no analogy to be made between the two, no similarity aside from the peripheral fact that both "products" happen to involve electronics.
Minus two points for not managing to cram the phrases "AJAX" or "Web 2.0" into this writeup.
Huh?
AJAX = Any technique for combining the XmlHTTPRequest object (or sometimes just an iframe) with JavaScript and XML methodologies to create a more dynamic web page = buzzword
Web 2.0 = Anything with a smooth logo, whose name is missing some vowels, and that looks like it might possibly be using AJAX methodologies = buzzword
XMPP = A very specific set of protocols, currently being formalized by the IETF, that form the basis for an extensible messaging or presence system and happen to be based on XML = not a buzzword
By the rest of the industrialized world's standards, they all do. Every single one of them.
Of course, Huckabee is the only one who has publicly and plainly stated that he wants to turn the United States down the path to theocracy. But don't let yourself think that the rest of the Republicans' denial of established biological fact -- a stance which, in combination with our already failing school system, can only push this nation even further toward scientific irrelevancy -- has nothing to do with appeasing the religious nuts whose are afraid of what implications evolutionary theory might have on their religious dogma.
The reason we block outbound 25 from dynamic networks that we own is that if we do not, we will inevitably become flooded with complaints about SPAM coming from our network. We know this from experience.
Sure, filtering outgoing TCP port 25 makes a lot of sense (though I like AT&T's particular stance on it, which is to give their more clueful subscribers the right to opt out of such filtering). But you originally said that you filter incoming port 25 due to spam concerns... or was that just a typo?
How is that supposed to stop spam ending up in the user's mailbox, exactly? If the user has a server running on port 25 to receive those messages, then clearly he understands the concept of spam and would presumably have weighed the pros and cons of any such configuration for himself. It seems pretty overbearing that you would presume to protect the user from himself in this fashion.
If you're blocking this particular type of traffic for price/performance reasons, then be upfront about it (although in my naive understanding, I can't imagine that the number of users running their own SMTP servers and yet totally failing to reject spam is so great that the resulting inbound traffic would pose a serious threat to your capacity). Claiming that you're blocking inbound TCP port 25 to protect the users from spam, though -- that just seems disingenuous.
As for filtering incoming spam to users' mailboxes on your own SMTP servers: yeah, you'd pretty much have to be insane not to. There's not much else you can do but to make your best effort at tuning the filters as well as possible to prevent false positives, and then hope for the best...
A more accurate title for this story would be: "User in violation of Cox TOS upset over Cox efforts to enforce TOS."
The problem is that the TOS are bogus, and there's absolutely nothing the customer can do about it. It's not as though we have a half dozen other cable subscribers to choose from and to keep each other honest; aside from the phone company, Cox is the only game in town for many folks. The theoretical benefits and corrective effects of free-market competition do not operate in such an environment.
Seriously, "servers of any type [...] server like functionality"? Congratulations, you've just described anything that accepts an incoming TCP or UDP connection. If I cannot at least SSH and VPN into my home network from abroad, my so-called Internet connection loses 50% of its utility.
I'd love to see somebody with the resources to do so stand up to these guys and sue them for false advertising. If you perform unwanted filtering on the incoming and outgoing access of your users, you're no longer selling a full Internet connection. The most troubling part is that Cox isn't even the worst offender in this regard, not by a long shot.
Observing that the downloader is only required for the purchase of albums, the downloader is most likely there for customer service.
But Amazon MP3 often sells albums for a price less than the sum of their parts; if you can't use the downloader and purchase whole albums, you'll wind up paying a couple dollars more than you otherwise would. So in a sense, the downloader really is a requirement.
Also, the client is a good way to ensure delivery. If you buy a single MP3 file, your browser's MIME settings may attempt to play the MP3 as it downloads, storing the download in a temporary browser cache. Joe Sixpack will think he's been had. The download client prevents this and downloads the file properly, and even automatically importing it into an iTunes library.
Yes, the downloader does those things and it's nice to have this functionality on the supported platforms. But why shouldn't Amazon give users the option to buy whole albums without the downloader's help? They seem comfortable enough delivering single songs by simple HTTP transfer, and other sites sell whole albums that way. It's easy enough to save purchase records in a database (as though they don't do that anyway) and let the user restart a failed download.
Amazon could expand their potential user base without any adverse effects whatsoever on the rest of the operation, simply by dropping the downloader requirement. Just add a tiny "Not running Windows or OS X?" link hidden off to the side, I don't care, as long as it is somehow possible to access the entire store without special software.
It's true that most people run OS X or Windows rather than Linux or Solaris or BSD, so no, Amazon cannot expect a gigantic payoff from fixing this issue -- but since the cost to implement this would presumably be almost zero, for them to choose otherwise seems nuts.
You're right, it goes without saying that iTunes is a far worse offender at this than Amazon MP3.
I guess I should have explained the reason this bugs me so much is that Amazon is just this close [pinches fingertips together] to having the ultimate, cross-platform, web- (well, and some Flash, but mostly web-) based DRM-free music store. If they'd just drop the silly downloader requirement for full-album purchases, then anybody on any platform with a web browser could use the store instantly, no special software required. It'd be absolutely universal if they simply merged that single feature into the main web application.
And this is Amazon we're talking about; you'd think that concocting a decent web interface for downloading albums would be a piece of cake for them, right? Their odd insistence on requiring this downloader almost makes me suspicious that the program is doing something nefarious like scanning your music library and sending statistical data back to the company, but nothing in the program's EULA or its behavior seems to indicate that this is the case.
No, because unlike AllOfMp3 these stores are operating according to U.S. (or similar) law; and more importantly to me, purchases from Amazon MP3, iTunes Plus, et al. result in the artists actually getting paid for their work. (Yes, I know, "the evil record labels don't pay their artists that much anyway, blah blah blah"... but if an artist is in a bad contract, at least it's an arrangement that he or she voluntarily entered into; AllOfMp3, on the other hand, is profiting off these artists' work without any compensation or agreement. If you give a crap about your favorite musicians, you don't buy their stuff from AllOfMp3.)
Quality rate, obscure bands not signed by one of the big corporations, etc.
Amazon MP3's quality is good, better than iTunes but not quite on par with iTunes Plus. Tracks are encoded with LAME 3.97 at a high VBR bitrate (~230 kbps or so?). The collection is still a tiny bit spotty, but growing fast. It certainly has a better selection than iTunes Plus does, by a long shot. All things considered, it's an excellent service.
My biggest pet peeve with Amazon MP3 is that while you can purchase individual songs through the standard Amazon web interface, purchasing whole albums (and thereby receiving the album discount, where applicable) requires the Amazon MP3 Downloader. On the plus side, this program seems well-written, can pause downloads or resume interrupted ones, automatically imports your songs into iTunes or other MP3 players' libraries, and doesn't behave suspiciously. But why should it be necessary? The downloader is currently available for OS X and Windows, and a Linux version is "forthcoming".
You are aware that the DRM-free Amazon MP3 store is already up and running, aren't you? I've bought about four albums' worth of music from it since the store launched months ago. The news here is only that Amazon MP3 will be opening internationally.
That's a lie. I mean, ten years ago, maybe; but IIS today is pretty damn secure by anybody's standards.
Where are all these vulnerabilities that you insist exist in IIS, from any time during the last five years? OSS FUD doesn't smell any better than Microsoft FUD.
Yeah, I think Panaflex is mistaken, or maybe just misspoke. Public keys don't work that way.
To be sure, there is a problem if you have people storing their private keys on the very network of servers you're trying to control access to. But there's no excuse to do that even if you do need to log into these servers from one another, since you can just run ssh-agent on your workstation and forward this local agent over your session with ssh -A. There's still a risk associated with agent forwarding, as outlined in the OpenSSH man pages, but it's a comparatively moderate one.
I'll see your good point, and raise you a pf.conf snippet:
### MACROS AND TABLES SECTION table <wan_bruteforce> persist
### PACKET FILTERING SECTION block in quick on $if_wan inet from <wan_bruteforce> #... pass in on $if_wan inet proto tcp from any to ($if_wan) \ port ssh flags S/SFRA synproxy state \ (max-src-conn-rate 3/30, overload <wan_bruteforce> flush global)
That's how you can block non-massively-distributed password dictionary attacks on the BSDs, anyway. Sadly, the fact that OpenBSD's firewall can perform this task on its own means that we probably won't see this feature worked into OpenSSH itself any time soon -- so on Linux you'll need a third-party script such as DenyHosts, as others have already pointed out.
(And yeah, unlike this PF configuration, DenyHosts lets you synchronize your table with a sort of universal blacklist of blocked hosts, so some might choose to run it on BSD anyway. It sounds like a good idea on paper, but boy does it suck when your home IP address keeps inexplicably winding up on the blacklist due to what turns out to be a single site's massively misconfigured server.)
But I think the most important lesson to be learned here, assuming that this thing does turn out to be an ssh attack, is that allowing single-factor, password-based administrative logins to a highly connected host is never a good idea. If you have the luxury of complete control over the site and its users (or are simply a highly empowered BOFH), disable password-based logins entirely and force the use of ssh public keys:
#/etc/ssh/sshd_config PubkeyAuthentication yes ChallengeResponseAuthentication no PasswordAuthentication no KerberosAuthentication no GSSApiAuthentication no UsePAM no
As a concession, if you want to ensure access without having to carry around an encryption key on a USB dongle, on Linux you can use PAM and libpam-opie to set up secondary access using a dual-factor combination of an S/Key one-time password and your regular login password (S/Key is like Steve Gibson's much-trumpeted "Perfect Paper Passwords" system, which is ingenious in its own right, except that S/Key is designed so that you don't need to keep your secret key stored unencrypted on the very server you're worried about protecting):
#/etc/ssh/sshd_config PubkeyAuthentication yes ChallengeResponseAuthentication yes PasswordAuthentication no KerberosAuthentication no GSSApiAuthentication no UsePAM yes
With the above configuration you can still log in seamlessly using your ssh private key. But if you get stuck somewhere without access to your private key, you just pull your S/Key passwords list out of your pocket and enter the next password in the sequence, as prompted, followed by your login password. This PAM configuration has the nice property that if you enter the correct S/Key password but then an incorrect Unix password, you will be asked for the next one-time password in the sequence before you can continue: so unless your attacker is exceptionally good at plaintext attacks on large cryptographic hashes, a successful brute-force attack becomes impossible.
Wow, this post got a lot longer than I wanted it to... I'm, um, going out to get some fresh air or something.
Nice try, but I don't give a crap about putting Linux in a "bad light". What does bug me is that this is a particularly virulent marketing lie which people keep repeating as though it actually tells us something meaningful; and that, as a result, PHB-types often wind up falling for it.
Since you've suggested that my objection to this press release must be rooted in Open Source fanboy-ism, it seems that you're defending Microsoft's claims as being somehow substantial. Care to make your case?
For the last time, you just can't add up the number of vulnerabilities in separate products from different authors and expect to glean any meaningful information from numerology thereon. This is especially true when contrasting one closed-source product from a vendor with questionable security reporting practices (say, Windows), and an open-source product where every single flaw of any level of significance is public knowledge (say, Ubuntu Linux).
I'm tired of seeing such claims about vulnerability tallies parroted in Slashdot summaries without the least bit of skepticism regarding their relevance. This sort of thing has already been debunked a million times over on this site. Come on, editors, a little quality control would be nice...
In any case, there is currently no unified theory that explains the connection of the spiritual realm ("soul") and physical world. [...] Perhaps some day we will discover more details about the connection between these two realms, but until then the two groups should just get off each others' backs.
There is absolutely no evidence whatsoever that any aspect of the human experience falls outside the real, physical world. This "different realm" you speak of is just metaphysical, pseudo-religious mumbo jumbo. Until someone finds evidence that the entirety of our consciousness cannot be encapsulated in the physical interactions within our minds and bodies -- and certainly, everything that rational, open inquiry has given us so far says that it is -- then we have no reason to even postulate about the existence of other "realms", whatever that's supposed to mean.
Slashdot Mirror
But broadly speaking, a "server" is anything that accepts incoming TCP/IP connections. A Bittorrent client is just as much a "server" as Postfix is.
On the other hand, if by "server-based" you meant to emphasize the client-server nature of most modern email systems, keep in mind that in the early days the very mainframe or workstation that you logged into was usually the same computer handling your email. At its inception, email was just as "P2P" as Bittorrent is today.
FUD? There's no FUD about it: if you use OpenDNS and perform a Google search, your search queries are being proxied through OpenDNS's servers. That's quite a breach of trust because -- unless they've changed something since I last checked -- this proxying of search data isn't exactly advertised to the user in advance. Even if I felt I could absolutely trust OpenDNS with all my data, such covert behavior would still make me uncomfortable.
As for the Google/Dell deal: yeah, it's evil, and the OpenDNS guys are right to bring attention to it. But it's a problem that needs to be solved at the application level, not by mucking around with users' DNS whether they're on an affected Dell or not. It's the wrong place and the wrong approach to solve this problem, and borderline creepy to boot.
I'm not sure why you're so angry with the Anonymous Coward for pointing this out; everything he said was unbiased and factually accurate. If the truth is going to "convince people not to use OpenDNS," then so be it.
May I invite you to read the comment you just replied to, particularly the part where I said:
To reiterate, we still haven't reached the point where we really understand the underlying mechanisms of cancer, not by a long shot. So to pretend that we can preclude cell phones as a potential cause of cancer when some of the empirical evidence suggests that it may be otherwise is absolutely unsound, no matter how unlikely it may seem that we'd be proven wrong on such an assumption.
However, the fact that cell phones do not produce ionizing radiation is in no sense a resounding argument for their safety. We do know that typical phone signals can result in cellular heating, and there may subtle results of this and other weak interactions that we do not yet understand, especially if those interactions are somehow a function of the signal's frequency.
We do not know enough about cellular biology to make the assumption that non-ionizing radiation is inherently safe across all frequencies and power levels, especially if the source of that radiation is a cell phone -- which puts out a fair deal more radio power than the CD players and displays you compare it to, and which is typically operated right next to one's head.
Therefore, we are not justified in categorically tossing out any new research that indicates a potential link between cell phone use and health problems. The question of cell phones and cancer does not yet have enough evidence pointing in either direction to give us a solid conclusion. So just let the scientists be scientists, since raw empirical evidence is the only way we'll ever answer this question in our lifetimes.
Just what we need -- another of the major players in Web content to fall under the News Corporation sphere of influence. As though they don't already do enough harm as it is, with their holdings in the traditional press...
I don't know when you imagine Slashdot to have demonstrated an outright opposition to legal bans on technological devices, in general, on account of them being "technological". A nuclear bomb is a "technological device," but I have yet to see an impassioned argument on this site that they should be available for sale in every corner hardware shop.
If you are actually trying to equate banning the use of this particular device in order to actively discriminate against a particular group of people, to placing restrictions on Internet usage at the behest of copyright holders, then you've failed to make your case. This is an annoyance device that targets teenagers; the Internet is a fundamental enabling platform for a innumerable products and services around the world. There is no analogy to be made between the two, no similarity aside from the peripheral fact that both "products" happen to involve electronics.
Because when you have a brazillion PCs to keep track of, maintaining any semblance of security becomes orders of magnitude more difficult.
Huh?
By the rest of the industrialized world's standards, they all do. Every single one of them.
Of course, Huckabee is the only one who has publicly and plainly stated that he wants to turn the United States down the path to theocracy. But don't let yourself think that the rest of the Republicans' denial of established biological fact -- a stance which, in combination with our already failing school system, can only push this nation even further toward scientific irrelevancy -- has nothing to do with appeasing the religious nuts whose are afraid of what implications evolutionary theory might have on their religious dogma.
Sure, filtering outgoing TCP port 25 makes a lot of sense (though I like AT&T's particular stance on it, which is to give their more clueful subscribers the right to opt out of such filtering). But you originally said that you filter incoming port 25 due to spam concerns... or was that just a typo?
How is that supposed to stop spam ending up in the user's mailbox, exactly? If the user has a server running on port 25 to receive those messages, then clearly he understands the concept of spam and would presumably have weighed the pros and cons of any such configuration for himself. It seems pretty overbearing that you would presume to protect the user from himself in this fashion.
If you're blocking this particular type of traffic for price/performance reasons, then be upfront about it (although in my naive understanding, I can't imagine that the number of users running their own SMTP servers and yet totally failing to reject spam is so great that the resulting inbound traffic would pose a serious threat to your capacity). Claiming that you're blocking inbound TCP port 25 to protect the users from spam, though -- that just seems disingenuous.
As for filtering incoming spam to users' mailboxes on your own SMTP servers: yeah, you'd pretty much have to be insane not to. There's not much else you can do but to make your best effort at tuning the filters as well as possible to prevent false positives, and then hope for the best...
The problem is that the TOS are bogus, and there's absolutely nothing the customer can do about it. It's not as though we have a half dozen other cable subscribers to choose from and to keep each other honest; aside from the phone company, Cox is the only game in town for many folks. The theoretical benefits and corrective effects of free-market competition do not operate in such an environment.
Seriously, "servers of any type [...] server like functionality"? Congratulations, you've just described anything that accepts an incoming TCP or UDP connection. If I cannot at least SSH and VPN into my home network from abroad, my so-called Internet connection loses 50% of its utility.
I'd love to see somebody with the resources to do so stand up to these guys and sue them for false advertising. If you perform unwanted filtering on the incoming and outgoing access of your users, you're no longer selling a full Internet connection. The most troubling part is that Cox isn't even the worst offender in this regard, not by a long shot.
But Amazon MP3 often sells albums for a price less than the sum of their parts; if you can't use the downloader and purchase whole albums, you'll wind up paying a couple dollars more than you otherwise would. So in a sense, the downloader really is a requirement.
Also, the client is a good way to ensure delivery. If you buy a single MP3 file, your browser's MIME settings may attempt to play the MP3 as it downloads, storing the download in a temporary browser cache. Joe Sixpack will think he's been had. The download client prevents this and downloads the file properly, and even automatically importing it into an iTunes library.Yes, the downloader does those things and it's nice to have this functionality on the supported platforms. But why shouldn't Amazon give users the option to buy whole albums without the downloader's help? They seem comfortable enough delivering single songs by simple HTTP transfer, and other sites sell whole albums that way. It's easy enough to save purchase records in a database (as though they don't do that anyway) and let the user restart a failed download.
Amazon could expand their potential user base without any adverse effects whatsoever on the rest of the operation, simply by dropping the downloader requirement. Just add a tiny "Not running Windows or OS X?" link hidden off to the side, I don't care, as long as it is somehow possible to access the entire store without special software.
It's true that most people run OS X or Windows rather than Linux or Solaris or BSD, so no, Amazon cannot expect a gigantic payoff from fixing this issue -- but since the cost to implement this would presumably be almost zero, for them to choose otherwise seems nuts.
You're right, it goes without saying that iTunes is a far worse offender at this than Amazon MP3.
I guess I should have explained the reason this bugs me so much is that Amazon is just this close [pinches fingertips together] to having the ultimate, cross-platform, web- (well, and some Flash, but mostly web-) based DRM-free music store. If they'd just drop the silly downloader requirement for full-album purchases, then anybody on any platform with a web browser could use the store instantly, no special software required. It'd be absolutely universal if they simply merged that single feature into the main web application.
And this is Amazon we're talking about; you'd think that concocting a decent web interface for downloading albums would be a piece of cake for them, right? Their odd insistence on requiring this downloader almost makes me suspicious that the program is doing something nefarious like scanning your music library and sending statistical data back to the company, but nothing in the program's EULA or its behavior seems to indicate that this is the case.
No, because unlike AllOfMp3 these stores are operating according to U.S. (or similar) law; and more importantly to me, purchases from Amazon MP3, iTunes Plus, et al. result in the artists actually getting paid for their work. (Yes, I know, "the evil record labels don't pay their artists that much anyway, blah blah blah"... but if an artist is in a bad contract, at least it's an arrangement that he or she voluntarily entered into; AllOfMp3, on the other hand, is profiting off these artists' work without any compensation or agreement. If you give a crap about your favorite musicians, you don't buy their stuff from AllOfMp3.)
Quality rate, obscure bands not signed by one of the big corporations, etc.Amazon MP3's quality is good, better than iTunes but not quite on par with iTunes Plus. Tracks are encoded with LAME 3.97 at a high VBR bitrate (~230 kbps or so?). The collection is still a tiny bit spotty, but growing fast. It certainly has a better selection than iTunes Plus does, by a long shot. All things considered, it's an excellent service.
My biggest pet peeve with Amazon MP3 is that while you can purchase individual songs through the standard Amazon web interface, purchasing whole albums (and thereby receiving the album discount, where applicable) requires the Amazon MP3 Downloader. On the plus side, this program seems well-written, can pause downloads or resume interrupted ones, automatically imports your songs into iTunes or other MP3 players' libraries, and doesn't behave suspiciously. But why should it be necessary? The downloader is currently available for OS X and Windows, and a Linux version is "forthcoming".
You are aware that the DRM-free Amazon MP3 store is already up and running, aren't you? I've bought about four albums' worth of music from it since the store launched months ago. The news here is only that Amazon MP3 will be opening internationally.
They differ in three ways:
That's a lie. I mean, ten years ago, maybe; but IIS today is pretty damn secure by anybody's standards.
Where are all these vulnerabilities that you insist exist in IIS, from any time during the last five years? OSS FUD doesn't smell any better than Microsoft FUD.
Yeah, I think Panaflex is mistaken, or maybe just misspoke. Public keys don't work that way.
To be sure, there is a problem if you have people storing their private keys on the very network of servers you're trying to control access to. But there's no excuse to do that even if you do need to log into these servers from one another, since you can just run ssh-agent on your workstation and forward this local agent over your session with ssh -A. There's still a risk associated with agent forwarding, as outlined in the OpenSSH man pages, but it's a comparatively moderate one.
In all seriousness though, IIS 6 has a pretty darn good security track record; seemingly better than Apache 2's, even if it is blasphemy for me to say it. I've previously decried the use of raw vulnerability statistics to make comparative claims about different products' security, but I think the fact that such a widely-deployed product as IIS 6 has been found to have only a single remote access vulnerability in the last four years really speaks for itself.
I mean, I'm just a Unix guy who's never had much use for a Windows web server, but that's my $0.02...
lolkit?
rootkitty?
I'll see your good point, and raise you a pf.conf snippet:
That's how you can block non-massively-distributed password dictionary attacks on the BSDs, anyway. Sadly, the fact that OpenBSD's firewall can perform this task on its own means that we probably won't see this feature worked into OpenSSH itself any time soon -- so on Linux you'll need a third-party script such as DenyHosts, as others have already pointed out.
(And yeah, unlike this PF configuration, DenyHosts lets you synchronize your table with a sort of universal blacklist of blocked hosts, so some might choose to run it on BSD anyway. It sounds like a good idea on paper, but boy does it suck when your home IP address keeps inexplicably winding up on the blacklist due to what turns out to be a single site's massively misconfigured server.)
But I think the most important lesson to be learned here, assuming that this thing does turn out to be an ssh attack, is that allowing single-factor, password-based administrative logins to a highly connected host is never a good idea. If you have the luxury of complete control over the site and its users (or are simply a highly empowered BOFH), disable password-based logins entirely and force the use of ssh public keys:
As a concession, if you want to ensure access without having to carry around an encryption key on a USB dongle, on Linux you can use PAM and libpam-opie to set up secondary access using a dual-factor combination of an S/Key one-time password and your regular login password (S/Key is like Steve Gibson's much-trumpeted "Perfect Paper Passwords" system, which is ingenious in its own right, except that S/Key is designed so that you don't need to keep your secret key stored unencrypted on the very server you're worried about protecting):
With the above configuration you can still log in seamlessly using your ssh private key. But if you get stuck somewhere without access to your private key, you just pull your S/Key passwords list out of your pocket and enter the next password in the sequence, as prompted, followed by your login password. This PAM configuration has the nice property that if you enter the correct S/Key password but then an incorrect Unix password, you will be asked for the next one-time password in the sequence before you can continue: so unless your attacker is exceptionally good at plaintext attacks on large cryptographic hashes, a successful brute-force attack becomes impossible.
Wow, this post got a lot longer than I wanted it to... I'm, um, going out to get some fresh air or something.
Nice try, but I don't give a crap about putting Linux in a "bad light". What does bug me is that this is a particularly virulent marketing lie which people keep repeating as though it actually tells us something meaningful; and that, as a result, PHB-types often wind up falling for it.
Since you've suggested that my objection to this press release must be rooted in Open Source fanboy-ism, it seems that you're defending Microsoft's claims as being somehow substantial. Care to make your case?
For the last time, you just can't add up the number of vulnerabilities in separate products from different authors and expect to glean any meaningful information from numerology thereon. This is especially true when contrasting one closed-source product from a vendor with questionable security reporting practices (say, Windows), and an open-source product where every single flaw of any level of significance is public knowledge (say, Ubuntu Linux).
I'm tired of seeing such claims about vulnerability tallies parroted in Slashdot summaries without the least bit of skepticism regarding their relevance. This sort of thing has already been debunked a million times over on this site. Come on, editors, a little quality control would be nice...
There is absolutely no evidence whatsoever that any aspect of the human experience falls outside the real, physical world. This "different realm" you speak of is just metaphysical, pseudo-religious mumbo jumbo. Until someone finds evidence that the entirety of our consciousness cannot be encapsulated in the physical interactions within our minds and bodies -- and certainly, everything that rational, open inquiry has given us so far says that it is -- then we have no reason to even postulate about the existence of other "realms", whatever that's supposed to mean.