People point the finger at the US or Israel, but until we find out for sure, it wouldn't be farfetched that someone else did it who didn't like Iran or the West and would love to see the powers duke it out and change the balance of power in the Middle East.
A couple scenarios:
There is bad blood between Sunnis and Shiites. It could be that someone who didn't like Shiites, nor the West could have done this in hopes of mutual annihilation.
Russia and China would gain because Iran might ask either power to station there for protection, in return for oil rights. Faking a US/Israel attack would gain both of those countries a critical foothold in the region, not to mention oil.
Another country in the ME wouldn't mind oil prices permanently rising with the loss of Iranian oil fields if a protracted conflict happened.
A group of anti oil people in the US with an ability far better than the skiddie level could have done this.
It might not even be politically motivated. There are a lot of antisocial people out there who would love to "watch the world burn".
Don't underestimate Iran. Iran has some very skilled people, and their main university, IUST has actually written some significant parts of the Linux kernel (IIRC, SMP code in the late 1990s.)
If you want to see Iran not be a threat, make the illusion of an enemy about to take over their soil evaporate. With this gone, the hard-liners will have to keep order through fear, and eventually what might happen there would be like what happened in Eastern European countries in the 1990s after the Soviet bloc collapsed -- a good chance of a moderate Islamic republic being formed, a country more interested in rebuilding Persia of old as opposed to blind hatred and fanaticism. The hard-liners exist because they use other countries' saber rattling of why they have to be in power as opposed to moderates.
As for Internet infrastructure, Iran's is arguably the best in the Middle East except for Israel's (and possibly UAE's). So, they are not a backwater by any means.
Don't forget that it takes resources to get this stuff done. V1 may be easily accomplished by pretty much anyone with the ability to pop firecrackers, but by the time one climbs up the chain past v4, it is requiring the knowledge of a demolition expert, and supply chains to move the mines (by the time they get to v4, they are not IEDs; they are pretty much mines.) Even though it doesn't take that much in electronics, it does take a lot of sophistication.
The result regardless is fewer mines on the roads. This is means an objective was accomplished.
Even worse, it may be going to 15% soon in a lot places. For older engines that don't have the ability to change timing for dealing with this, this will suck, not to mention the voided warranties of engines which are warranties to work with no more than 10% alcohol.
If one takes ethanol (or E85), this is a good solution -- less MPG, but better HP. Its downside is that oil needs to be changed more often because water dissolves in it, creating an acid. This is also why the service guide tells you to run a tank of pure unleaded every 3000-7000 miles.
However, here in the US, we don't have sugar cane whose by-product can be turned into booze for the car, and the effect of using corn means that food prices go higher since it is an either or unlike sugar cane -- corn goes to be processed for ethanol, or it gets made into food.
If there is some type of crop that can be grown for its main function, but have lots of sugar that can be fermented/distilled into ethanol, this would be ideal -- people eat, cars get filled up.
On a long term scale, what would be interesting is a way to pull CO2 directly from the air, mix it with water (best bet is desalinated so it does not interfere with water needs) and start making crude oil this way ready for refining and reuse. Nuclear power has enough density per square foot, so one could combine a nuke plant, a desalination plant, and a CO2 remover in one area, and get crude in quantities that are usable for fuel or for plastics. To boot, it would be a crude oil free of mercury, sulphur, or other possible toxic metals.
Salting provides effective protection when combined with a number of rounds. Ideally, the client should do a number of rounds, then hand the 256 bit hash over to the server which will toss in the salt and do a few rounds. The reason for this is that trying to brute force guess a typeable password will become difficult. An additional bonus is that a client trying to guess a user's password is slowed down by an authentication mechanism before the guess goes to the machine.
What would be ideal is a standard authentication library set that a lot of people scrutinize for errors which is intended at large web sites to keep track of users. Something that makes it easy for programmers to store user information the right way (passwords hashed with a salt and a number of rounds, all other user info encrypted somehow.)
Person "A" is very capable and does a great job coding. He works from home.
Person "B" is horrible. He doesn't know a "==" from a "=". However, he is good at playing the managers and getting tee times with them.
The PHB will not look at the sterling record of the guy who isn't present. Instead he will end up giving a raise/promotion to the guy who is in the office, even though the guy present in the office adds little of value to the company.
Just being there is part of the battle, and without a physical presence, it is tougher to nail down promotions, raises, or even keep your job.
Compared to what our parents were doing in the 1970s and 1980s, there is a big difference to what they had for buying power and what people have today. At a decent income in the 1970s, one person in the household could easily afford a good house, a decent car, and be able to provide for a family. Presently, it takes two incomes to be able to provide for a family, assuming a house reasonably near the city in an area safe to raise kids.
Or take a car analogy. In the 1990s, a college grad would make $40-45k a year starting out. A 4x4 Suburban would run about $30k new. These days, a college grad gets approximately the same starting salary ($47k on average.) These days, the SUV has doubled in price. A house that sold for 100,000 now sells for 250,000.
Don't forget that we have a lot more parasitic expenses than people before us. The time/money wasted on commutes because cities refuse to work on expanding critical roads. Our parents did not have Internet access, cellular bills, nor the cost of upkeep for computers as part of their budget.
So, even though outward appearances show one thing, in reality the quality of life that people have is a lot less than pops or gramps who worked in the steel mill, but was more than able to afford a nice house in a good part of town.
It will only get worse -- in the days of previous generations, medical expenses were annoying, but rarely would spell out financial doom. These days, one serious injury can mean a bankruptcy and complete loss of a person's nest egg. The days of our descendants having it better than we did are gone.
For home E-mail, if you are a student with MSDNAA access, you might try Exchange. For one of my domains, I use dyndns and a SMTP provider (so my outgoing mail doesn't get spamcanned for being from a dynamic IP range.)
Believe it or not, Exchange has decent incoming spam controls built in, and MS updates those pretty often. I've been using it at home as a replacement for a POP/IMAP server for a long time, and it happily works with either protocol (both regular and SSL/TLS protected)
I also use it because if one of my smartphones gets stolen, I can do a remote wipe.
Of course OWA in E2010 is head and shoulders above most Webmail interfaces, and because if configured correctly, it only goes through the SSL server, the only thing a third party can do is cause packets to drop, or try to spoof the SSL key.
The downside: Backing up Exchange isn't as easy as copying/var/spool/mail off. In fact, backing up/restoring Exchange just plain sucks. Luckily, corrupted mailboxes do not happen that often. Exchange also requires AD, so taking the time for setting this up is a lot longer than just setting up a Linux box with sendmail, Zimbra, and dovecot.
I highly recommend using a smart host for outgoing E-mail. Most ISPs either block outgoing 25, and even if it gets out, places will see that the mail came from a dynamic address pool and likely spamcan it. You can use your ISP's E-mail server sometimes, and if that doesn't work, there are places which will allow you to send mail from their SMTP servers for a fee.
Here is what I'd do if I wanted to run an E-mail server at home:
First, get a service like DynDNS.com that you can set MX records and easy tools to update your DNS pointers to your current IP address.
Second, either use your ISP's SMTP server, or use a third party's to relay from, preferably one that has a good reputation. This way, even though you have your own E-mail server, your outgoing mail's reputation is scored a lot higher because it went through a known good system.
Third, get an SSL key for the server. This way, if later on you wanted to add Webmail like Zimbra or OWA, it would be easy. I'd not have anything running on port 80, and just have everything run via https. This way, people probing for Web servers won't find that, and you can set up additional client security on the secure port (perhaps even requiring client certificates.)
Don't forget the security ramifications about having this -- make sure to have a good DMZ.
Why just mail? I'd also have my file server and backup server in there as well. This way, not just my E-mail is protected, but backups of all my PCs, as well as archived files.
Another scenario is Google being bought out, selling gmail to someone else, or going out of business. This doesn't seem possible right now, but it might happen, as climates change in the industry. This means that the E-mail files are still there, but the SLAs signed are null and void. So the next company down the line could easily sell that info to anyone who wants or even create a large torrent archive for anyone to download.
What really is needed are regulations on how E-mail is stored, and the regulations will still hold even if the provider changes hands, goes out of businesses and the assets picked up from a liquidation sale, or the company just wants to shut down its doors. It is like bank records -- banks can change hands, but it doesn't mean that they can publish all the balances of their users on their public website.
Whenever any security program is talked about of having a FBI/CIA/NSA/Illuminati back door on it, an agency who puts in a backdoor has two really big problems:
The first: If one agency knows about it, a blackhat will find it, and use it in a wholesale compromising spree that will result in a backlash that completely discredits the software and anyone related to it. Once an encryption product hits the snake oil bin, it never will be trusted again.
The second: If the backdoor *does* exist, isn't found by people, then when should it be used? $AGENCY tipping their hand and revealing info that was protect with $SECURITY_TOOL will cause people to behave like #1 and that tool will be in the shitcan of history.
On the OS level, if compromise gets rampant enough, eventually nations will make their own OS and build in a hypervisor so their citizens can use Windows in a contained environment. Red Flag Linux was a start, but lost steam. However, if people realize mainstream operating systems are compromised from the install on, countries will start rolling their own operating systems vetted by their own intel agencies to ensure that their domestic assets are locked down.
For a BSD to have a backdoor, the person writing the code for it would have to be extremely good, and no hints made that it existed could ever be made out, lest an alert sysadmin sees his IDS going off with oddball traffic and then sees his boxes get compromised.
My take: This doesn't affect my trust in the operating system. In fact, further scrutiny of the source code is always a good thing for an OSS product.
Instead of depending on apps in the cloud, why not just continue to have standard applications just be able to save in an offsite space? I can do this on Macs with the iDrive, Windows with Box.net, on Linux with FUSE and boxfs or other items. Cloud apps are great if one doesn't have a local copy of OOo or Word handy, but the most optimal placement for the app is the local desktop, or at worst, a server on the LAN.
There is also the fact that you are forced to use the latest version of a Web application. Sometimes a previous version of an application works better, or has a feature that isn't in the latest version (such as being able to save multiple revisions of a document in the same file in Office 2003/2007, but not in 2010). A feature disappears that you need, you are SOL with Web apps.
There is "progress". Just like the "progress" that was XDMCP from a serial signal.
Cloud apps are just one step higher on the stack. Where terminal hardware was all but completely controlled by the term server and X-stations were just graphics displays with keyboards attached, Javastations had their own mini-OS and libraries. Cloud apps are just one more level up, where the client provides the hardware, OS, Web browser, and add-ons.
Other than moving to the application layer, it is just the same old, same old except with the new buzzwords to get the PHBs to sign the blank checks.
The old Wizardry games on the Apple ][ would add a pseudo-random number of asterisks when typing in a character password. This way, if someone saw 8 asterisks, it could be a 2 character password, or longer. Since it was the same number of characters, one could use that to doublecheck if they had the right password typed as well.
Smarter security systems also follow this lead. So, "******" may not be "hunter2", but "1234".
Stuff like that is inexcusable. Basic stuff like doing a salt (128 bit minimum, 256 bits recommended), appending it to the password the user types in, then running both through a SHA-256 blender for a good number of rounds [1] is SOP for anything to be taken seriously these days.
Why do people keep forgetting the need for salts in password storage? Even the old BSD and SVR4 UNIX variants had salts and computation rounds in the old crypt (3) password storage before the days of/etc/shadow. It is a lot tougher to guess a password when one can't just use a precomputed rainbow table.
[1]: This can vary on the system. TrueCrypt uses 1000 rounds, iOS 4 uses 10,000 rounds. Preferably a number of rounds that doesn't add significant load to the server, but is good enough to slow down brute force attempts. One idea might just be to have the client do the password obtaining and send a decrypted token so the server doesn't have to waste CPU cycles.
An alternative is to use a throwaway OpenID account. However, why let people be able to get tracking data from one account with multiple sites? Might as well have a different, throwaway ID for every site, just because of the stupidity of having to register to see a print view or leave comments, and the registration process almost always demands a lot of personal information that isn't relevant. Why do websites demand addresses (and bother trying to check them), other than just trying to get more stuff to sell. In those cases, I just give them the address of USENET Central Administration [1] and continue on.
Depends... if the machine had to do some virtual memory paging, it might be spending time waiting for the data to get under the HDD head as opposed to deciding the fate of humanity.
This is why you always put your Skynet systems on tier 2 or tier 3 storage. Tier 1 flash storage just lets it decide that humanity has to go a lot faster.
I can sum it up by a phrase said to me by many PHBs that ignore basic security:
"Security has no ROI".
Until this attitude gets changed by laws with actual teeth, expect to continue to see more of "xxx hacked, millions of people's data exposed" stories.
Two laws are needed: The first is obvious -- follow due diligent security practices or be shut down. A restaurant that doesn't pass health inspections gets shut down. Same with a store in a mall without a sales and use tax permit.
It doesn't take much brainpower to turn on hard disk encryption to protect from theft. BitLocker, TrueCrypt, or PGP are no brainers. All mainstream Linux distros support encryption. AIX supports encryption both in the filesystem, and on the hardware itself. The EMC CLARiiON supports encryption on a LUN basis. Solaris supports encryption in ZFS. Every enterprise backup system has encryption built in, and the latest generation of tape drives have it in hardware. There is no excuse for physical data loss.
Network security isn't that difficult either. It doesn't take many brain cells to have a decent IDS/IPS, use VLANs to isolate machines from each other, so database connections are only accessible by machines that need access,
Web security is doable too. If a Web server only needs a subset of what a database has, create a view and lock the webserver to that view so it can't see anything other than the tables handed to it. If there is really sensitive data, have multiple hosts on separate VLANs, so the juicy stuff is separate from what isn't.
Document security isn't tough, although it limits where documents can be viewed and can be F/OSS hostile. Microsoft's RMS is a decent solution so a Word document that ends up walking off won't be viewable outside the company. Another way to keep documents secure is to use Citrix and keep the critical stuff on a terminal server. This takes care of accidental loss/distribution of documents. Deliberate screenshot snapping, or even people sneaking a camera in is a HR or even a law enforcement issue, not a technical one, and no DRM is going to stop someone dedicated enough unless a business wants to strip search everyone entering and leaving.
Of course, this means a SMB doesn't have to be 100% secure, but they need to at least follow the same precautions as a cafe does when preparing food so their patrons don't come down with a case of food poisoning. There are so many tools and appliances for doing this, it isn't that difficult.
Basic computer security isn't rocket science, but because it doesn't earn businesses money, it ends up being given lip service in a lot of forms and that's it.
The second law is also obvious -- expiration dates on data, and this means expired as in -gone-. Not stored in plaintext on an archive tape in offline storage. Not stored in the cloud where a rogue admin at the cloud site can slurp off the data to sell. The data is expired as in deleted, or cryptographically expired where the key is deleted and the data is rendered inaccessible.
The ideal solution is probably a network appliance using transparent proxying and multiple levels of blacklisting with multiple levels of ad-blocking:
The first level is a whitelist, as a number of websites use third party ad spewers to handle CAPTCHAs. The second would be an IP level blacklist with an immediate drop of packets, so a connection doesn't hang, but returns unreachable. The third level would be a database of URLs to remove. The fourth would be updatable heuristics -- zapping potentially malicious/malformed files in transit, be it.swf files, Java executables, HTML, CSS, or whatever. The fifth would be heuristics related to the Web site visited. If a user is browsing a mainstream site, it should not be asking for connections to dodgy sites in Elbonia unless the user was clicking on an explicit link.
Of course, none of this is bulletproof, but stopping the ads before they hit the machine will go much farther than the current technique of AV which is intercepting IO calls and scans (neither do nothing against this generation of malware.)
You don't want a license requirement. You really don't. What will happen is that a "license" for access to an open, unfettered device like a standard PC would be harder to get than a class 3 automatic weapons license for a pistol in NYC, DC, or SF. Someone with connections and a rich family would have it. Everyone else would end up with completely locked down desktops with F/OSS being a happy memory.
Instead, what we need is to focus on programs and research in this security arena. Some examples come to mind:
1: Sandboxie functionality on all platforms, where all writes are redirected, essentially a BSD jail, but with the ability for users to save files outside of it. When the browser is closed, everything that the user has not selected to keep gets wiped.
2: Kicking developers in the rear who do not provide adequate security. If one writes for Windows, their code needs to run under DEP, support ASLR, and use a least privilege model (see DropMyRights source for how to do this right.) This isn't hard -- almost all UNIX programs have been doing this for decades. We shouldn't see the lessons learned by sendmail have to be retaught over and over.
3: Backups. Ideally it would be nice to have a separate machine store backups and have both push and pull abilities, so the stored can't be tampered with once saved off. For the most part, backup technology is still in the 1970s. It would be nice to have an OS independent format that can replace tar, support block level deduplication, compression and encryption, have cryptographic signing capabilities, support ECC so data can be rebuilt if damaged, support filesystem extensions, and be able to be used on tape, DVDs, BD media, files, or raw hard disks, support snapshots, and be usable for not just bare metal restores (restoring the filesystems, but the ODM/Registry/NetInfo/System State), but machine cloning. This way, if a box gets compromised, it can be snapshotted for forensic reasons, then PXE booted and restored (if the time of the compromise is definitely known), or just reinstalled with the data being restored (if the time of the compromise is unknown).
4: PGP/gpg built into the OS, with an OS-protected area for cryptographic keys. Everyone on the Internet doesn't really need a license, but they do need a private key to start a WOT. PGP's WOT should not just cover other users, but it would be good to have functionality to mark repositories as trusted as well.
5: A move to signed repositories. Ideally, the only time one needs to download and execute an installer directly is if it is custom code, or the machine is not kept online for security reasons.
6: Built in TPM chips that ship disabled/turned off, but can be turned on by the user. TPMs are a double edged sword, but would be instrumental in protecting the OS in case the MBR or boot sector get modified by malware. Used right, it would go a long way in protecting the core parts of the OS.
If they "just" put in a kill switch, we would get off lucky. An attack that knocks a major credit card processing company off the Internet (and thus keeps people from being able to do transactions) would get Congress to be cranking out bills in record time. Think USAPATRIOT act, where Congresspeople had to sign the law or be considered weak on terrorism.
Instead, what we would see if "anti-cyberterrorism" treaties being passed with the same wording as ACTA, but because it is for "national security", it would get people signing without a second thought.
End result: Bye-bye Internet, hello Compuserve v2.0. We have a deal after 9PM -- only $5.00/hour while viewing our premiere Web pages ($9.99 an hour if viewing other content) , receiving E-mails is only 99 cents per message, and sending is only $1.99 per message. Don't forget to visit the new CB channel while you are at it.
This analogy can't be better. To boot, the guy gets mad when you ignore him.
I'd take the guy trying to rub a filthy newspaper on a windshield over the ad guys though. At least the squeegee guy gets too belligerent, he will get taken down. Ad companies can be as aggressive as they want without fear of reprisal.
Slashdot Mirror
People point the finger at the US or Israel, but until we find out for sure, it wouldn't be farfetched that someone else did it who didn't like Iran or the West and would love to see the powers duke it out and change the balance of power in the Middle East.
A couple scenarios:
There is bad blood between Sunnis and Shiites. It could be that someone who didn't like Shiites, nor the West could have done this in hopes of mutual annihilation.
Russia and China would gain because Iran might ask either power to station there for protection, in return for oil rights. Faking a US/Israel attack would gain both of those countries a critical foothold in the region, not to mention oil.
Another country in the ME wouldn't mind oil prices permanently rising with the loss of Iranian oil fields if a protracted conflict happened.
A group of anti oil people in the US with an ability far better than the skiddie level could have done this.
It might not even be politically motivated. There are a lot of antisocial people out there who would love to "watch the world burn".
Don't underestimate Iran. Iran has some very skilled people, and their main university, IUST has actually written some significant parts of the Linux kernel (IIRC, SMP code in the late 1990s.)
If you want to see Iran not be a threat, make the illusion of an enemy about to take over their soil evaporate. With this gone, the hard-liners will have to keep order through fear, and eventually what might happen there would be like what happened in Eastern European countries in the 1990s after the Soviet bloc collapsed -- a good chance of a moderate Islamic republic being formed, a country more interested in rebuilding Persia of old as opposed to blind hatred and fanaticism. The hard-liners exist because they use other countries' saber rattling of why they have to be in power as opposed to moderates.
As for Internet infrastructure, Iran's is arguably the best in the Middle East except for Israel's (and possibly UAE's). So, they are not a backwater by any means.
Don't forget that it takes resources to get this stuff done. V1 may be easily accomplished by pretty much anyone with the ability to pop firecrackers, but by the time one climbs up the chain past v4, it is requiring the knowledge of a demolition expert, and supply chains to move the mines (by the time they get to v4, they are not IEDs; they are pretty much mines.) Even though it doesn't take that much in electronics, it does take a lot of sophistication.
The result regardless is fewer mines on the roads. This is means an objective was accomplished.
Even worse, it may be going to 15% soon in a lot places. For older engines that don't have the ability to change timing for dealing with this, this will suck, not to mention the voided warranties of engines which are warranties to work with no more than 10% alcohol.
If one takes ethanol (or E85), this is a good solution -- less MPG, but better HP. Its downside is that oil needs to be changed more often because water dissolves in it, creating an acid. This is also why the service guide tells you to run a tank of pure unleaded every 3000-7000 miles.
However, here in the US, we don't have sugar cane whose by-product can be turned into booze for the car, and the effect of using corn means that food prices go higher since it is an either or unlike sugar cane -- corn goes to be processed for ethanol, or it gets made into food.
If there is some type of crop that can be grown for its main function, but have lots of sugar that can be fermented/distilled into ethanol, this would be ideal -- people eat, cars get filled up.
On a long term scale, what would be interesting is a way to pull CO2 directly from the air, mix it with water (best bet is desalinated so it does not interfere with water needs) and start making crude oil this way ready for refining and reuse. Nuclear power has enough density per square foot, so one could combine a nuke plant, a desalination plant, and a CO2 remover in one area, and get crude in quantities that are usable for fuel or for plastics. To boot, it would be a crude oil free of mercury, sulphur, or other possible toxic metals.
The more info they collect, the more they can sell to advertisers. This is why so many blog places demand so much info.
Salting provides effective protection when combined with a number of rounds. Ideally, the client should do a number of rounds, then hand the 256 bit hash over to the server which will toss in the salt and do a few rounds. The reason for this is that trying to brute force guess a typeable password will become difficult. An additional bonus is that a client trying to guess a user's password is slowed down by an authentication mechanism before the guess goes to the machine.
What would be ideal is a standard authentication library set that a lot of people scrutinize for errors which is intended at large web sites to keep track of users. Something that makes it easy for programmers to store user information the right way (passwords hashed with a salt and a number of rounds, all other user info encrypted somehow.)
I've also seen people stung that way:
Person "A" is very capable and does a great job coding. He works from home.
Person "B" is horrible. He doesn't know a "==" from a "=". However, he is good at playing the managers and getting tee times with them.
The PHB will not look at the sterling record of the guy who isn't present. Instead he will end up giving a raise/promotion to the guy who is in the office, even though the guy present in the office adds little of value to the company.
Just being there is part of the battle, and without a physical presence, it is tougher to nail down promotions, raises, or even keep your job.
Compared to what our parents were doing in the 1970s and 1980s, there is a big difference to what they had for buying power and what people have today. At a decent income in the 1970s, one person in the household could easily afford a good house, a decent car, and be able to provide for a family. Presently, it takes two incomes to be able to provide for a family, assuming a house reasonably near the city in an area safe to raise kids.
Or take a car analogy. In the 1990s, a college grad would make $40-45k a year starting out. A 4x4 Suburban would run about $30k new. These days, a college grad gets approximately the same starting salary ($47k on average.) These days, the SUV has doubled in price. A house that sold for 100,000 now sells for 250,000.
Don't forget that we have a lot more parasitic expenses than people before us. The time/money wasted on commutes because cities refuse to work on expanding critical roads. Our parents did not have Internet access, cellular bills, nor the cost of upkeep for computers as part of their budget.
So, even though outward appearances show one thing, in reality the quality of life that people have is a lot less than pops or gramps who worked in the steel mill, but was more than able to afford a nice house in a good part of town.
It will only get worse -- in the days of previous generations, medical expenses were annoying, but rarely would spell out financial doom. These days, one serious injury can mean a bankruptcy and complete loss of a person's nest egg. The days of our descendants having it better than we did are gone.
For home E-mail, if you are a student with MSDNAA access, you might try Exchange. For one of my domains, I use dyndns and a SMTP provider (so my outgoing mail doesn't get spamcanned for being from a dynamic IP range.)
Believe it or not, Exchange has decent incoming spam controls built in, and MS updates those pretty often. I've been using it at home as a replacement for a POP/IMAP server for a long time, and it happily works with either protocol (both regular and SSL/TLS protected)
I also use it because if one of my smartphones gets stolen, I can do a remote wipe.
Of course OWA in E2010 is head and shoulders above most Webmail interfaces, and because if configured correctly, it only goes through the SSL server, the only thing a third party can do is cause packets to drop, or try to spoof the SSL key.
The downside: Backing up Exchange isn't as easy as copying /var/spool/mail off. In fact, backing up/restoring Exchange just plain sucks. Luckily, corrupted mailboxes do not happen that often. Exchange also requires AD, so taking the time for setting this up is a lot longer than just setting up a Linux box with sendmail, Zimbra, and dovecot.
I highly recommend using a smart host for outgoing E-mail. Most ISPs either block outgoing 25, and even if it gets out, places will see that the mail came from a dynamic address pool and likely spamcan it. You can use your ISP's E-mail server sometimes, and if that doesn't work, there are places which will allow you to send mail from their SMTP servers for a fee.
Here is what I'd do if I wanted to run an E-mail server at home:
First, get a service like DynDNS.com that you can set MX records and easy tools to update your DNS pointers to your current IP address.
Second, either use your ISP's SMTP server, or use a third party's to relay from, preferably one that has a good reputation. This way, even though you have your own E-mail server, your outgoing mail's reputation is scored a lot higher because it went through a known good system.
Third, get an SSL key for the server. This way, if later on you wanted to add Webmail like Zimbra or OWA, it would be easy. I'd not have anything running on port 80, and just have everything run via https. This way, people probing for Web servers won't find that, and you can set up additional client security on the secure port (perhaps even requiring client certificates.)
Don't forget the security ramifications about having this -- make sure to have a good DMZ.
Why just mail? I'd also have my file server and backup server in there as well. This way, not just my E-mail is protected, but backups of all my PCs, as well as archived files.
Another scenario is Google being bought out, selling gmail to someone else, or going out of business. This doesn't seem possible right now, but it might happen, as climates change in the industry. This means that the E-mail files are still there, but the SLAs signed are null and void. So the next company down the line could easily sell that info to anyone who wants or even create a large torrent archive for anyone to download.
What really is needed are regulations on how E-mail is stored, and the regulations will still hold even if the provider changes hands, goes out of businesses and the assets picked up from a liquidation sale, or the company just wants to shut down its doors. It is like bank records -- banks can change hands, but it doesn't mean that they can publish all the balances of their users on their public website.
Whenever any security program is talked about of having a FBI/CIA/NSA/Illuminati back door on it, an agency who puts in a backdoor has two really big problems:
The first: If one agency knows about it, a blackhat will find it, and use it in a wholesale compromising spree that will result in a backlash that completely discredits the software and anyone related to it. Once an encryption product hits the snake oil bin, it never will be trusted again.
The second: If the backdoor *does* exist, isn't found by people, then when should it be used? $AGENCY tipping their hand and revealing info that was protect with $SECURITY_TOOL will cause people to behave like #1 and that tool will be in the shitcan of history.
On the OS level, if compromise gets rampant enough, eventually nations will make their own OS and build in a hypervisor so their citizens can use Windows in a contained environment. Red Flag Linux was a start, but lost steam. However, if people realize mainstream operating systems are compromised from the install on, countries will start rolling their own operating systems vetted by their own intel agencies to ensure that their domestic assets are locked down.
For a BSD to have a backdoor, the person writing the code for it would have to be extremely good, and no hints made that it existed could ever be made out, lest an alert sysadmin sees his IDS going off with oddball traffic and then sees his boxes get compromised.
My take: This doesn't affect my trust in the operating system. In fact, further scrutiny of the source code is always a good thing for an OSS product.
Instead of depending on apps in the cloud, why not just continue to have standard applications just be able to save in an offsite space? I can do this on Macs with the iDrive, Windows with Box.net, on Linux with FUSE and boxfs or other items. Cloud apps are great if one doesn't have a local copy of OOo or Word handy, but the most optimal placement for the app is the local desktop, or at worst, a server on the LAN.
There is also the fact that you are forced to use the latest version of a Web application. Sometimes a previous version of an application works better, or has a feature that isn't in the latest version (such as being able to save multiple revisions of a document in the same file in Office 2003/2007, but not in 2010). A feature disappears that you need, you are SOL with Web apps.
There is "progress". Just like the "progress" that was XDMCP from a serial signal.
Cloud apps are just one step higher on the stack. Where terminal hardware was all but completely controlled by the term server and X-stations were just graphics displays with keyboards attached, Javastations had their own mini-OS and libraries. Cloud apps are just one more level up, where the client provides the hardware, OS, Web browser, and add-ons.
Other than moving to the application layer, it is just the same old, same old except with the new buzzwords to get the PHBs to sign the blank checks.
The old Wizardry games on the Apple ][ would add a pseudo-random number of asterisks when typing in a character password. This way, if someone saw 8 asterisks, it could be a 2 character password, or longer. Since it was the same number of characters, one could use that to doublecheck if they had the right password typed as well.
Smarter security systems also follow this lead. So, "******" may not be "hunter2", but "1234".
Stuff like that is inexcusable. Basic stuff like doing a salt (128 bit minimum, 256 bits recommended), appending it to the password the user types in, then running both through a SHA-256 blender for a good number of rounds [1] is SOP for anything to be taken seriously these days.
Why do people keep forgetting the need for salts in password storage? Even the old BSD and SVR4 UNIX variants had salts and computation rounds in the old crypt (3) password storage before the days of /etc/shadow. It is a lot tougher to guess a password when one can't just use a precomputed rainbow table.
[1]: This can vary on the system. TrueCrypt uses 1000 rounds, iOS 4 uses 10,000 rounds. Preferably a number of rounds that doesn't add significant load to the server, but is good enough to slow down brute force attempts. One idea might just be to have the client do the password obtaining and send a decrypted token so the server doesn't have to waste CPU cycles.
An alternative is to use a throwaway OpenID account. However, why let people be able to get tracking data from one account with multiple sites? Might as well have a different, throwaway ID for every site, just because of the stupidity of having to register to see a print view or leave comments, and the registration process almost always demands a lot of personal information that isn't relevant. Why do websites demand addresses (and bother trying to check them), other than just trying to get more stuff to sell. In those cases, I just give them the address of USENET Central Administration [1] and continue on.
[1]: 1060 W Addison Street to be exact.
Depends... if the machine had to do some virtual memory paging, it might be spending time waiting for the data to get under the HDD head as opposed to deciding the fate of humanity.
This is why you always put your Skynet systems on tier 2 or tier 3 storage. Tier 1 flash storage just lets it decide that humanity has to go a lot faster.
I can sum it up by a phrase said to me by many PHBs that ignore basic security:
"Security has no ROI".
Until this attitude gets changed by laws with actual teeth, expect to continue to see more of "xxx hacked, millions of people's data exposed" stories.
Two laws are needed: The first is obvious -- follow due diligent security practices or be shut down. A restaurant that doesn't pass health inspections gets shut down. Same with a store in a mall without a sales and use tax permit.
It doesn't take much brainpower to turn on hard disk encryption to protect from theft. BitLocker, TrueCrypt, or PGP are no brainers. All mainstream Linux distros support encryption. AIX supports encryption both in the filesystem, and on the hardware itself. The EMC CLARiiON supports encryption on a LUN basis. Solaris supports encryption in ZFS. Every enterprise backup system has encryption built in, and the latest generation of tape drives have it in hardware. There is no excuse for physical data loss.
Network security isn't that difficult either. It doesn't take many brain cells to have a decent IDS/IPS, use VLANs to isolate machines from each other, so database connections are only accessible by machines that need access,
Web security is doable too. If a Web server only needs a subset of what a database has, create a view and lock the webserver to that view so it can't see anything other than the tables handed to it. If there is really sensitive data, have multiple hosts on separate VLANs, so the juicy stuff is separate from what isn't.
Document security isn't tough, although it limits where documents can be viewed and can be F/OSS hostile. Microsoft's RMS is a decent solution so a Word document that ends up walking off won't be viewable outside the company. Another way to keep documents secure is to use Citrix and keep the critical stuff on a terminal server. This takes care of accidental loss/distribution of documents. Deliberate screenshot snapping, or even people sneaking a camera in is a HR or even a law enforcement issue, not a technical one, and no DRM is going to stop someone dedicated enough unless a business wants to strip search everyone entering and leaving.
Of course, this means a SMB doesn't have to be 100% secure, but they need to at least follow the same precautions as a cafe does when preparing food so their patrons don't come down with a case of food poisoning. There are so many tools and appliances for doing this, it isn't that difficult.
Basic computer security isn't rocket science, but because it doesn't earn businesses money, it ends up being given lip service in a lot of forms and that's it.
The second law is also obvious -- expiration dates on data, and this means expired as in -gone-. Not stored in plaintext on an archive tape in offline storage. Not stored in the cloud where a rogue admin at the cloud site can slurp off the data to sell. The data is expired as in deleted, or cryptographically expired where the key is deleted and the data is rendered inaccessible.
The ideal solution is probably a network appliance using transparent proxying and multiple levels of blacklisting with multiple levels of ad-blocking:
The first level is a whitelist, as a number of websites use third party ad spewers to handle CAPTCHAs. .swf files, Java executables, HTML, CSS, or whatever.
The second would be an IP level blacklist with an immediate drop of packets, so a connection doesn't hang, but returns unreachable.
The third level would be a database of URLs to remove.
The fourth would be updatable heuristics -- zapping potentially malicious/malformed files in transit, be it
The fifth would be heuristics related to the Web site visited. If a user is browsing a mainstream site, it should not be asking for connections to dodgy sites in Elbonia unless the user was clicking on an explicit link.
Of course, none of this is bulletproof, but stopping the ads before they hit the machine will go much farther than the current technique of AV which is intercepting IO calls and scans (neither do nothing against this generation of malware.)
You don't want a license requirement. You really don't. What will happen is that a "license" for access to an open, unfettered device like a standard PC would be harder to get than a class 3 automatic weapons license for a pistol in NYC, DC, or SF. Someone with connections and a rich family would have it. Everyone else would end up with completely locked down desktops with F/OSS being a happy memory.
Instead, what we need is to focus on programs and research in this security arena. Some examples come to mind:
1: Sandboxie functionality on all platforms, where all writes are redirected, essentially a BSD jail, but with the ability for users to save files outside of it. When the browser is closed, everything that the user has not selected to keep gets wiped.
2: Kicking developers in the rear who do not provide adequate security. If one writes for Windows, their code needs to run under DEP, support ASLR, and use a least privilege model (see DropMyRights source for how to do this right.) This isn't hard -- almost all UNIX programs have been doing this for decades. We shouldn't see the lessons learned by sendmail have to be retaught over and over.
3: Backups. Ideally it would be nice to have a separate machine store backups and have both push and pull abilities, so the stored can't be tampered with once saved off. For the most part, backup technology is still in the 1970s. It would be nice to have an OS independent format that can replace tar, support block level deduplication, compression and encryption, have cryptographic signing capabilities, support ECC so data can be rebuilt if damaged, support filesystem extensions, and be able to be used on tape, DVDs, BD media, files, or raw hard disks, support snapshots, and be usable for not just bare metal restores (restoring the filesystems, but the ODM/Registry/NetInfo/System State), but machine cloning. This way, if a box gets compromised, it can be snapshotted for forensic reasons, then PXE booted and restored (if the time of the compromise is definitely known), or just reinstalled with the data being restored (if the time of the compromise is unknown).
4: PGP/gpg built into the OS, with an OS-protected area for cryptographic keys. Everyone on the Internet doesn't really need a license, but they do need a private key to start a WOT. PGP's WOT should not just cover other users, but it would be good to have functionality to mark repositories as trusted as well.
5: A move to signed repositories. Ideally, the only time one needs to download and execute an installer directly is if it is custom code, or the machine is not kept online for security reasons.
6: Built in TPM chips that ship disabled/turned off, but can be turned on by the user. TPMs are a double edged sword, but would be instrumental in protecting the OS in case the MBR or boot sector get modified by malware. Used right, it would go a long way in protecting the core parts of the OS.
If they "just" put in a kill switch, we would get off lucky. An attack that knocks a major credit card processing company off the Internet (and thus keeps people from being able to do transactions) would get Congress to be cranking out bills in record time. Think USAPATRIOT act, where Congresspeople had to sign the law or be considered weak on terrorism.
Instead, what we would see if "anti-cyberterrorism" treaties being passed with the same wording as ACTA, but because it is for "national security", it would get people signing without a second thought.
End result: Bye-bye Internet, hello Compuserve v2.0. We have a deal after 9PM -- only $5.00/hour while viewing our premiere Web pages ($9.99 an hour if viewing other content) , receiving E-mails is only 99 cents per message, and sending is only $1.99 per message. Don't forget to visit the new CB channel while you are at it.
This analogy can't be better. To boot, the guy gets mad when you ignore him.
I'd take the guy trying to rub a filthy newspaper on a windshield over the ad guys though. At least the squeegee guy gets too belligerent, he will get taken down. Ad companies can be as aggressive as they want without fear of reprisal.