Agreed. This is the completely logical selling point for this worldwide, especially the BIOS and kernel level features of it. The overal design is actually quite clever, I really recommend reading up on its internals.
The problems with its potential misuse are social and legal, not technological. For example, the ownership of the keys and the difficulties of getting signed keys for loading open source OS's are going to be really, really fun to manage.
This kind of blocking is not for business accounts. Business accounts can buy static IP addresses and get a different class of firewall configuration, no problem, they are paying for that class of different service. It's for the home users, and the home users can generally use SMTP auth if they need to send through their business mail sever, no problem.
It is NAT'ed. So are most other ISP's these days. That's part of the problem: the sending IP address for zombied machines is part of the NAT'ed address space, and is not externally accessible so that they can receive the bounce messages.
Interestingly, AOL itself is publishing SPF information that messages forged to look like they come from aol.com can be easily blocked. It's the zombies that forge messages to look like they come from you, or me, or every other ISP in the world and get sent from address spaces from other ISP's that generate such such grief.
One interesting filter approach is to assume that for any "MAIL FROM" address, the alleged domain actually does publish SPF records that use its reverse DNS and its real A record for that domain and its real MX records. Anything else is assumed to be forged, and an SPF record of "?all" is faked and used to process the mail, helping to generate powerful negative. This helps filter zombie and spam email quite a lot.
In short, for any domain that does not publish SPF records, assume that they publish simple ones and filter accordingly. It's a very good indicator of forged email that can be processed right at the mail server and puts a big dent in zombie and email worm traffic.
The previous configuration can be used only if the IP address hasn't been re-assigned to another host. Checking for that is built into the DHCP protocol.
How to handle an expired DHCP lease is another problem, and whether to consistently re-issue the same IP for the same host if it is left active and a new DHCP lease is needed after the old one expires is another problem. And what to do if another DHCP server is handliing the same domain is a bit of an adventure.
AOL, at least, uses NAT. For those who don't know, this means that all their internal IP addresses start with a non-routed IP address like 10.*, and that that only a small number of their servers have externally accessible IP addresses such as their web servers and mail servers and routers. This protects their customers from external traffic, and makes their network a lot safer to administer, and is just like when your ISP gives you one external IP address and you run a lot of home machines behind a NAT'ed router. So you, at home, can reach out to other addresses but they can't reach back in so easily.
People who want to run their own services, like web servers and honest to god mail servers, would need to spring for a business account and a static IP. And the rest of us have a huge address space that AOL can assign as it wishes to provide static internal IP addresses for internal routing.
Most ISP's do this now: getting a big range of externally accessible IP addresses is currently very expensive, and not many ISP 's bother to do it.
You want to live in my apartment building? Then you can use the front door. You want a key to the back door, so you can take deliveries for the business you run out of your apartment? Then you can pay office rates instead of apartment rates and be in the office building, not the apartment, because supporting your needs for traffic costs me as a landlord mor.
It's that simple. The building managers, or in this case the ISP's, have too much trash being dumped outside the back door by lazy tenants, so they are insistiing people use the front door. Get over it, or pay the money for a statifc IP address and opened up firewalls so you can run your own SMTP server and be held responsible for it.
Not at all. The traffic to the third party hosting service can go over port 587, as documented by the RFC's, or can be tunneled over port 80, or can be sent over lots of other fascinating means.
It's the random, unauthenticated, untraced outbound email that is the problem. Specified traffic to a designated 3rd party host is no problem if that 3rd party has the remotest clue.
Unfortunately, email is often forwarded or passed along by innocent SMTP servers, and decoding the forwarding or the original source is a nightmare to do. The source ISP has already demonstrated their incompetence at preventing the spam or the email worm: there's no hint that slapping the innocent intermediate carriers will help the situation.
For now, use SPF. Let the ISP's themselves define what hosts are allowed to send email from those hosts, or protending to be from those domains. It doesn't block the forged "From:" lines, but blocks the forged "MAIL FROM" lines to prevent faking mail from other people, which has been a big problem for spam filters and for email worm filters. This requires filtering to occur at the first point of injecting the SMTP message, but it's very helpful for blocking forged email.
Add a strong negative spam score for any mail whose "From:" data doesn't match its "MAIL FROM" data, and you have a very powerful filter that's easy to implement.
It will inconvenience a big number of CEO's, CFO's, and other people who literally cannot be bothered to learn how their laptops work and want all their email to look like it is from their work account no matter where they are.
Blocking port 25 is a reasonable approach for most ISP's, since the large majority of email is now spam and email worms. Blocking port 25 puts a big dent in the worm traffic, since the outgoing traffic will hit the mail server of the ISP responsible for the infected customer. It also puts a big dent in the zombie traffic, which whips around most blacklists and burdens a lot of ISP's with maintaining huge and problematic blacklist of all DSL/cable/dialup IP addresses they can find.
A better solution is SPF. Not thw Microsoft DomainKeys or SenderID solution, but the pure DNS solution that says "this domain publishes a text record that says mail claiming to be from this domain must actually come from permitted IP addresses". It's cute, it's lightweight, it needs people to use the filtering to really have an effect. Check it out at http://spf.pobox.com./
Not possible. These thieves were informed quite some time ago that the code was GPL code, with documentation. You can't pretend your software was stolen by a shady programmer when the evidence is in your face that way, any more than you can pretend you didn't mean to drive drunk when the airbag drives your beer bottle into your eye.
You worked for IBM Global Services, right? They're real champions at burning out anyone even vaguely competent. I have a friend still recovering from a long stint working for them.
Spam, defined as "unsolicited bulk communications" is not illegal. That would require a change in the laws concerning email, something like the junk fax laws that have already withstood constitutional challenges.
What's illegal is email fraud, such as lying about where the email comes from. Since the ISP's have no responsibility to block spam from their own networks, and since there is no civil penalty that can be pursued directly by the spam victims, there is effectively no way to prosecute spam for anybody but John Ashcroft even if it is illegal under the CANSPAM laws, and he's a bit busy pursuing dirty pictures and ignoring criminal mistreatment of US prisoners.
The developers, reputation, and customers of RedHat are not GPL'ed, only the source code. They'd take time to rebuild, and RedHat is one of the more populer OS's because it's very friendly to developers.
You hit upon a key point. No crack monkey web designer in their right mind these days uses binary.cgi. They use things like PHP or Tomcat or, if they need a very powerful scriptiing language, Python and Perl to do the server side as part of their setups (with appropriate security settings). In other cases, they use these tools to access back end data bases.
Given that so little heavy duty web content is done via binary.cgi's now, basing a performance review on speed of.cgi performance them is like basing a restaurant review on the crunchiness of the breadsticks. The cheap place has crunchier breadsticks because they've been sitting out all day....
If the information helps make clear that the Iraqi Invasion is not working to pacify the Iraqis and is in fact leading to more terrorism against Americans than has occurred since Pearl Harbor, then it may save a lot more lives to reveal how ineffective the guard efforts there. And this report makes it quite clear, especially some of the formerly classified bits.
I've certainly heard of murdererers in the US who claimed that they helped the victim, especially crooked police who gunned down innocent people or gunned people down for non-criminal but irritating acts such as helping poor people vote, then pretended to help the victims. I've even heard of cases where the officer pretending to help spent the time finishing the murder or planting evidence on the victim, as they or their partner shooed back any potential witnesses out of immediate sight range.
I'm not saying this is what happened here: the report looks like that of a tragic accident, but there is plenty of extremely embarassing detail in the report about the serious failures of US guard personnel to control the guerrilla attacks of the Iraqui natives, and about the devastating effectiveness of their suicide tactics coupled with the simple advantage of being natives indistinguishable from non-combatants.
Reading the report gives an extremely poor view of the American ability to control the countryside.
Fortunately, in the Linux and real OS world, it's pretty easy to turn off the ability for users to arbitrarily mount USB drives, floppies, or CD drives. This matters a lot in companies with highly valuable corporate information that is easily taken electronically: security companies, the music and video industry, stock traders, etc.
Many of those sites do block the SMTP port 25 for outgoing email, not just for security but to prevent virus infected Windows machines from spewing email from inside the firewall. A few also block the encrypted SMTP port 587 to block authenticated email, and a few also block the POP and IMAP and their encrypted ports as well to keep employees from reading offsite email during work time, which can really suck away worktime if not kept under control.
Of course, a sensible user policy would be more sensible, just as using a cell phone 8 hours a day at work for non-business traffic is usually a sign that someone is not doing their job.
Ahh, yes, the legal advice of an 3l33t hack3r who would rather leave his previous victims vulnerable to the next 3l33t hack3r who might not be as gentle and non-destructive.
In such a situation, touch *nothing* on their network that involves changing anything. Get a competent lawyer to go over the situation with you, one that works for you, not the school. Prepare a detailed report on the problems at both the technical level, and a separate report on the policy issues that led to the situation, and make a clear separation between them. Ask the school's administrators who should get these reports, and definitely try to get class credit for them. Heck, if they're good, ignore the credit and get a consulting fee and recommendations on your transcript that you helped the school fix these.
Ahh, yes, the legal advice of an 3l33t hack3r who would rather leave his previous victims vulnerable to the next 3l33t hack3r who might not be as gentle and non-destructive.
In such a situation, touch *nothing* on their network that involves changing anything. Get a competent lawyer to go over the situation with you, one that works for you, not the school. Prepare a detailed report on the problems at both the technical level, and a separate report on the policy issues that led to the situation, and make a clear separation between them. Ask the school's administrators who should get these reports, and definitely try to get class credit for them. Heck, if they're good, ignore the credit and get a consulting fee and recommendations on your transcript that you helped the school fix these.
Notifying the victim of the holes so that they can be fixed is the difference between a hacker, who likes to fix things and help others fix them to demonstrate their power over the world, and a cracker who likes to break things to demonstrate power over victims.
CSmastermind? It sounds like you have some talent. Have fun with it, use it well, and only do damage when it's morally justified. (If you see email threatening to seriously kill someone, leak it.)
Look again. Many employee contracts specifically permit the monitoring of all communications from corporate users, including telephone and email. Even where state law prohibits unannounced phone monitoring, the log of when you called what numbers is available to the company.
So if you're calling your potential jobs from your company paid corporate phone, driving there in your corporate car, and printing resumes on the corporate printer, expect some real trouble if your old company notices.
Whether email deserves the same protection is a good question. The issue wouldn't even come up if any of the technically good email encryption schemes were ever permitted to gain acceptance, but that's been its own mess trying to develop over the years.
Actually, I find Slashdot to be useful. I get occasional technical announcements that would be tough to gather elsewhere, and I get a chance to vent on very technical political matters in a venue where people have some idea what I'm talking about and will constructively comment or correct it if necessary.
It's actually fairly educational, although filtering out the debris of 3l33t l0z3rz and of corporate shills lying to protect their company reputations is part of its maintenance cost.
Considering that NT's kernel, which is the core of XP and 2003, was basically stolen by David Cutler from DEC and originally was David's code written for the Alpha, it's not shocking that Windows can finally support 64-bit. It's quite embarassing that it took them this long, since the kernel was originally written for the 64-bit Alpha CPU.
Yes, most of the streaming and ad content and certainly the DNS is Akamai based. Those are the 3 key services designed to take down your servers. The fact that Akamai won't run them on Windows, since it's painful to administer remotely and nearly impossible to secure, is an endless source of embarassment to Microsoft.
Slashdot Mirror
No, what will happen is that big companies will have large patent vaults with reams of patents they will can use to punish anyone who dares sue them.
Wait, Microsoft already does that and is trying to extend it by turning everything into XML....
Agreed. This is the completely logical selling point for this worldwide, especially the BIOS and kernel level features of it. The overal design is actually quite clever, I really recommend reading up on its internals. The problems with its potential misuse are social and legal, not technological. For example, the ownership of the keys and the difficulties of getting signed keys for loading open source OS's are going to be really, really fun to manage.
If Fair Use applies, there was no infringement. Keep your terms clear when you write this stuff: what you are describing is an "alleged" infringement.
Until the hard drive, boot kernel, DVD drive, and keyboard are locked down with the DRM system, yes.
This kind of blocking is not for business accounts. Business accounts can buy static IP addresses and get a different class of firewall configuration, no problem, they are paying for that class of different service. It's for the home users, and the home users can generally use SMTP auth if they need to send through their business mail sever, no problem.
It is NAT'ed. So are most other ISP's these days. That's part of the problem: the sending IP address for zombied machines is part of the NAT'ed address space, and is not externally accessible so that they can receive the bounce messages. Interestingly, AOL itself is publishing SPF information that messages forged to look like they come from aol.com can be easily blocked. It's the zombies that forge messages to look like they come from you, or me, or every other ISP in the world and get sent from address spaces from other ISP's that generate such such grief. One interesting filter approach is to assume that for any "MAIL FROM" address, the alleged domain actually does publish SPF records that use its reverse DNS and its real A record for that domain and its real MX records. Anything else is assumed to be forged, and an SPF record of "?all" is faked and used to process the mail, helping to generate powerful negative. This helps filter zombie and spam email quite a lot. In short, for any domain that does not publish SPF records, assume that they publish simple ones and filter accordingly. It's a very good indicator of forged email that can be processed right at the mail server and puts a big dent in zombie and email worm traffic.
The previous configuration can be used only if the IP address hasn't been re-assigned to another host. Checking for that is built into the DHCP protocol. How to handle an expired DHCP lease is another problem, and whether to consistently re-issue the same IP for the same host if it is left active and a new DHCP lease is needed after the old one expires is another problem. And what to do if another DHCP server is handliing the same domain is a bit of an adventure.
AOL, at least, uses NAT. For those who don't know, this means that all their internal IP addresses start with a non-routed IP address like 10.*, and that that only a small number of their servers have externally accessible IP addresses such as their web servers and mail servers and routers. This protects their customers from external traffic, and makes their network a lot safer to administer, and is just like when your ISP gives you one external IP address and you run a lot of home machines behind a NAT'ed router. So you, at home, can reach out to other addresses but they can't reach back in so easily. People who want to run their own services, like web servers and honest to god mail servers, would need to spring for a business account and a static IP. And the rest of us have a huge address space that AOL can assign as it wishes to provide static internal IP addresses for internal routing. Most ISP's do this now: getting a big range of externally accessible IP addresses is currently very expensive, and not many ISP 's bother to do it.
You want to live in my apartment building? Then you can use the front door. You want a key to the back door, so you can take deliveries for the business you run out of your apartment? Then you can pay office rates instead of apartment rates and be in the office building, not the apartment, because supporting your needs for traffic costs me as a landlord mor.
It's that simple. The building managers, or in this case the ISP's, have too much trash being dumped outside the back door by lazy tenants, so they are insistiing people use the front door. Get over it, or pay the money for a statifc IP address and opened up firewalls so you can run your own SMTP server and be held responsible for it.
Not at all. The traffic to the third party hosting service can go over port 587, as documented by the RFC's, or can be tunneled over port 80, or can be sent over lots of other fascinating means. It's the random, unauthenticated, untraced outbound email that is the problem. Specified traffic to a designated 3rd party host is no problem if that 3rd party has the remotest clue.
Unfortunately, email is often forwarded or passed along by innocent SMTP servers, and decoding the forwarding or the original source is a nightmare to do. The source ISP has already demonstrated their incompetence at preventing the spam or the email worm: there's no hint that slapping the innocent intermediate carriers will help the situation. For now, use SPF. Let the ISP's themselves define what hosts are allowed to send email from those hosts, or protending to be from those domains. It doesn't block the forged "From:" lines, but blocks the forged "MAIL FROM" lines to prevent faking mail from other people, which has been a big problem for spam filters and for email worm filters. This requires filtering to occur at the first point of injecting the SMTP message, but it's very helpful for blocking forged email. Add a strong negative spam score for any mail whose "From:" data doesn't match its "MAIL FROM" data, and you have a very powerful filter that's easy to implement.
It will inconvenience a big number of CEO's, CFO's, and other people who literally cannot be bothered to learn how their laptops work and want all their email to look like it is from their work account no matter where they are.
Blocking port 25 is a reasonable approach for most ISP's, since the large majority of email is now spam and email worms. Blocking port 25 puts a big dent in the worm traffic, since the outgoing traffic will hit the mail server of the ISP responsible for the infected customer. It also puts a big dent in the zombie traffic, which whips around most blacklists and burdens a lot of ISP's with maintaining huge and problematic blacklist of all DSL/cable/dialup IP addresses they can find.
A better solution is SPF. Not thw Microsoft DomainKeys or SenderID solution, but the pure DNS solution that says "this domain publishes a text record that says mail claiming to be from this domain must actually come from permitted IP addresses". It's cute, it's lightweight, it needs people to use the filtering to really have an effect. Check it out at http://spf.pobox.com./
Not possible. These thieves were informed quite some time ago that the code was GPL code, with documentation. You can't pretend your software was stolen by a shady programmer when the evidence is in your face that way, any more than you can pretend you didn't mean to drive drunk when the airbag drives your beer bottle into your eye.
You worked for IBM Global Services, right? They're real champions at burning out anyone even vaguely competent. I have a friend still recovering from a long stint working for them.
Spam, defined as "unsolicited bulk communications" is not illegal. That would require a change in the laws concerning email, something like the junk fax laws that have already withstood constitutional challenges.
What's illegal is email fraud, such as lying about where the email comes from. Since the ISP's have no responsibility to block spam from their own networks, and since there is no civil penalty that can be pursued directly by the spam victims, there is effectively no way to prosecute spam for anybody but John Ashcroft even if it is illegal under the CANSPAM laws, and he's a bit busy pursuing dirty pictures and ignoring criminal mistreatment of US prisoners.
The developers, reputation, and customers of RedHat are not GPL'ed, only the source code. They'd take time to rebuild, and RedHat is one of the more populer OS's because it's very friendly to developers.
it would be a blow.
You hit upon a key point. No crack monkey web designer in their right mind these days uses binary .cgi. They use things like PHP or Tomcat or, if they need a very powerful scriptiing language, Python and Perl to do the server side as part of their setups (with appropriate security settings). In other cases, they use these tools to access back end data bases.
.cgi's now, basing a performance review on speed of .cgi performance them is like basing a restaurant review on the crunchiness of the breadsticks. The cheap place has crunchier breadsticks because they've been sitting out all day....
Given that so little heavy duty web content is done via binary
If the information helps make clear that the Iraqi Invasion is not working to pacify the Iraqis and is in fact leading to more terrorism against Americans than has occurred since Pearl Harbor, then it may save a lot more lives to reveal how ineffective the guard efforts there. And this report makes it quite clear, especially some of the formerly classified bits.
I've certainly heard of murdererers in the US who claimed that they helped the victim, especially crooked police who gunned down innocent people or gunned people down for non-criminal but irritating acts such as helping poor people vote, then pretended to help the victims. I've even heard of cases where the officer pretending to help spent the time finishing the murder or planting evidence on the victim, as they or their partner shooed back any potential witnesses out of immediate sight range.
I'm not saying this is what happened here: the report looks like that of a tragic accident, but there is plenty of extremely embarassing detail in the report about the serious failures of US guard personnel to control the guerrilla attacks of the Iraqui natives, and about the devastating effectiveness of their suicide tactics coupled with the simple advantage of being natives indistinguishable from non-combatants.
Reading the report gives an extremely poor view of the American ability to control the countryside.
Fortunately, in the Linux and real OS world, it's pretty easy to turn off the ability for users to arbitrarily mount USB drives, floppies, or CD drives. This matters a lot in companies with highly valuable corporate information that is easily taken electronically: security companies, the music and video industry, stock traders, etc. Many of those sites do block the SMTP port 25 for outgoing email, not just for security but to prevent virus infected Windows machines from spewing email from inside the firewall. A few also block the encrypted SMTP port 587 to block authenticated email, and a few also block the POP and IMAP and their encrypted ports as well to keep employees from reading offsite email during work time, which can really suck away worktime if not kept under control. Of course, a sensible user policy would be more sensible, just as using a cell phone 8 hours a day at work for non-business traffic is usually a sign that someone is not doing their job.
Ahh, yes, the legal advice of an 3l33t hack3r who would rather leave his previous victims vulnerable to the next 3l33t hack3r who might not be as gentle and non-destructive. In such a situation, touch *nothing* on their network that involves changing anything. Get a competent lawyer to go over the situation with you, one that works for you, not the school. Prepare a detailed report on the problems at both the technical level, and a separate report on the policy issues that led to the situation, and make a clear separation between them. Ask the school's administrators who should get these reports, and definitely try to get class credit for them. Heck, if they're good, ignore the credit and get a consulting fee and recommendations on your transcript that you helped the school fix these. Ahh, yes, the legal advice of an 3l33t hack3r who would rather leave his previous victims vulnerable to the next 3l33t hack3r who might not be as gentle and non-destructive. In such a situation, touch *nothing* on their network that involves changing anything. Get a competent lawyer to go over the situation with you, one that works for you, not the school. Prepare a detailed report on the problems at both the technical level, and a separate report on the policy issues that led to the situation, and make a clear separation between them. Ask the school's administrators who should get these reports, and definitely try to get class credit for them. Heck, if they're good, ignore the credit and get a consulting fee and recommendations on your transcript that you helped the school fix these. Notifying the victim of the holes so that they can be fixed is the difference between a hacker, who likes to fix things and help others fix them to demonstrate their power over the world, and a cracker who likes to break things to demonstrate power over victims. CSmastermind? It sounds like you have some talent. Have fun with it, use it well, and only do damage when it's morally justified. (If you see email threatening to seriously kill someone, leak it.)
Look again. Many employee contracts specifically permit the monitoring of all communications from corporate users, including telephone and email. Even where state law prohibits unannounced phone monitoring, the log of when you called what numbers is available to the company. So if you're calling your potential jobs from your company paid corporate phone, driving there in your corporate car, and printing resumes on the corporate printer, expect some real trouble if your old company notices. Whether email deserves the same protection is a good question. The issue wouldn't even come up if any of the technically good email encryption schemes were ever permitted to gain acceptance, but that's been its own mess trying to develop over the years.
Actually, I find Slashdot to be useful. I get occasional technical announcements that would be tough to gather elsewhere, and I get a chance to vent on very technical political matters in a venue where people have some idea what I'm talking about and will constructively comment or correct it if necessary.
It's actually fairly educational, although filtering out the debris of 3l33t l0z3rz and of corporate shills lying to protect their company reputations is part of its maintenance cost.
Considering that NT's kernel, which is the core of XP and 2003, was basically stolen by David Cutler from DEC and originally was David's code written for the Alpha, it's not shocking that Windows can finally support 64-bit. It's quite embarassing that it took them this long, since the kernel was originally written for the 64-bit Alpha CPU.
Yes, most of the streaming and ad content and certainly the DNS is Akamai based. Those are the 3 key services designed to take down your servers. The fact that Akamai won't run them on Windows, since it's painful to administer remotely and nearly impossible to secure, is an endless source of embarassment to Microsoft.