Generally, yes it's not worth the time or the effort. However, if you're serious about taking advantage of your old drives, I'd suggest using RAID on top of LVM. LVM will allow you to group drives of different sizes together to form a logical volume. You can then use software RAID to ensure data integrity. Over time, as drives fail, you can replace failed drives with new ones and rebuild the failed logical volume. A simple Samba server should suffice for your file sharing needs.
If you're on a company network and you want to have a network performing okay while bittorrent clients are present on it, you'll need DPI.
That's complete nonsense. Bittorrent and other peer to peer networks are definitely bandwidth intensive, but you don't need DPI to maintain performance on a network. A properly configured QoS should be more than enough to balance things out. Simply prioritizing the outbound data by source address alone would ensure that anyone trying to perform bandwidth intensive tasks gets their fair share. IP protocols were designed to deal with bandwidth restrictions but also to use as much as possible. It's therefore possible that a few HTTP downloads could congest an entire network in the same way a bittorrent client does. This is becoming even more common with modern browsers which use multiple connections to try and retrieve data faster from remote servers.
The only thing DPI provides is the ability to restrict access to specific protocols based solely on packet content. If encryption is used, DPI is useless as it cannot differentiate between the traffic. The end result is a never ending war between software developers and network administrators. The final outcome has yet to be decided.
You and the author of the article both seem to be missing one important aspect of password hashing. You're never supposed to apply a particular hashing algorithm directly to a password. Instead the user's password should be combined with some salt(random data) and then hashed. The resulting hash can still be brute forced, but any resulting hashes can't be used as collisions for other stored hashes as they require a different known salt to be used. In other words, while it took the author 49 minutes he only had to compute 6^n number of hashes where n is the number of possible characters per position (lowercase, uppercase, numeric?). If each hashed password had a different known salt appended, he would have had to compute 14 * 6^n number of hashes. This is an order of magnitude larger than the original time. Of course, this only applies if the salt is known. If the salt is unknown during the brute-force it's practically impossible to discover the original password.
Sadly it seems a lot of people still think $10,000 is a briefcase full of cash. Lets break it down shall we.. Assuming they used standard US bills we get the following:
$10,000 = $100 x 100 bills = 1 stack of 100, $100 bills
$10,000 = $50 x 200 bills = 2 stacks of 100, $50 bills
$10,000 = $20 x 500 bills = 5 stacks of 100, $20 bills
$10,000 = $10 x 1000 bills = 10 stacks of 100, $10 bills
$10,000 = $5 x 2000 bills = 20 stacks of 100, $5 bills
$10,000 = $1 x 10000 bills = 100 stacks of 100, $1 bills
At 0:14 when they open the case you can clearly see several stacks marked as $100, some as $50, and some as $5. If the briefcase truly has $10,000 in it, the stacks marked with $100 bills must be filled with something other than $100 bills as a single stack would equal the amount the briefcase was said to hold. Given the variety of bills in the case, it appears they went to a lot of trouble to convince us that they gave away $10,000 USD. The reality is they probably didn't, and that the entire thing was just as staged as the briefcase full of cash.
I completely agree. Remove the word "lawful" from all sections and I'll be much more supportive of their efforts. If all content and application communications were protected under the First Amendment then word "lawful' would only serve to restrict that right in the future by designating specific things as "unlawful". The last thing we need is government overview of what applications or content are considered "lawful".
I thought gasoline taxes already accounted for this sort of thing. That is the more you drive your car the more tax you pay in taxes. If you're one of those idiots that must drive an 8mpg SUV then you undoubtedly pay more in taxes than someone who drives a midsized or compact car. Is this fair? I think so.
This may be true for the moment, but now that someone is actually capitalizing on jailbroken iphones, Apple's attempts to completely restrict people from installing what they want on their devices could be construed as anti-competitive behavior by a judge. That is, if they were to secure all flaws in the phone's operating system via an update and not provide people with the availability to install software from a competing vendor, Apple could face some serious fines for effectively trying to eliminate the competition.
If this ever winds up in court, Apple might try to argue that jailbroken iphones are against the DMCA. The competing store however might argue that it was done for "compatibility" purposes, which last I recall was allowed under current copyright laws. In the end if something like this does ever happen, it'll definitely be a case worth paying attention to.
PBS had a great 1 hour segment on this not too long ago. Their segment covered the rapid decline in albatrosses due to offspring being fed the plastic from the pacific. I haven't been able to find the complete coverage of the segment I saw on my local PBS station, but I have managed to locate part of it here titled: World's Oceans Face Problem of Plastic Pollution
Sure, install Bind/Named or any other free DNS server and do the look-ups yourself. Having your own DNS server dramatically improves look-up times. It also prevents the unfortunate situation where you're unable to resolve any sites simply because your ISP's DNS servers have failed.
This may not actually help. In the cases where I've noticed filtering being applied, I still experienced connection timeouts after filtering out TCP reset packets at both ends of the connection. This is an indication that some blocking is done after the reset has been sent. In the case of UDP, the carrier would simply drop any suspected P2P packets and the connection would eventually timeout.
Since UDP is not a guaranteed network protocol, the strain from having to implement packet ordering and retransmissions for every connection and every application would become very processor intensive if implemented on a per application basis. TCP was designed specifically for this purpose and provides a central system for performing these services. The abuse it has been receiving lately by network carriers shouldn't be taken lightly.
Some people have been defending Comcast based on the amount it would cost them to upgrade their network and provide their current customer base with unlimited network bandwidth as advertised. If cost were really an issue, their overall profit would not be nearly as high as stated in their annual and quarterly earnings reports at http://www.cmcsk.com/phoenix.zhtml?c=118591&p=irol-earnings
Based on these reports Comcast has had plenty revenue to spare which could have been spent on upgrading their network for quite some time. Instead, they choose to throttle their network users in order to increase company profits and earnings per share for their stockholders.
Even though most of the affected servers have been patched, DNS is still broken. The patches thus far only make it slightly harder to exploit. Before the patches, you had a 1/(2^16) chance of guessing the sequence number. With the patches the likelihood of guessing the correct combination of port and sequence number has decreased to approximately 1/(2^32). Given there were reports that were reports of successful attacks in as little as 10 seconds, the patches only increase the time needed to approximately 10 minutes. With a fast enough internet connection, a successful attack could still take only minutes to succeed. DNSSEC or some other alternative may be the only way to avoid this issue completely.
I'm not familiar with the specifics of how DNSSec works, but public keys are usually exchanged during the initial stages of the conversation. For example, Bob might start the conversation by telling Alice his public key and ask that she send him her's. At this point, Alice has two options. She could just tell Bob her public key, or she could encrypt her public key with Bob's public key. The second option is slightly more secure, since anyone listening to the conversation would only have heard Bob's public key.
The only issue with public/private keys is that it is susceptible to a man in the middle attack. As soon as Bob announces his public key, anyone pretending to be Alice could reply with their public key. This is what key signing is supposed to solve.
The issue isn't so much as identifying who you are communicating with as much as it is ensuring that you're only communicating with one remote host. All the current DNS vulnerabilities exploit the fact that a third party can easily forge a response.
Encryption via public and private keys is the most effective way to currently ensure that you are actually communicating with a single remote host. The way it works is as follows:
If Bob wants to talk to Alice, Bob encrypts his message with Alice's public key. Alice decodes Bob's message with her private key and encrypts the response with Bob's public key. Bob can then decode Alice's response with his private key.
If Bob needs to ensure that he is indeed speaking to Alice, he can request Alice to encrypt all messages with her private key before encrypting them with his public key. Bob can then be assured the message came from Alice if he is able to decrypt it using his private key and Alice's public key.
Though Mallory could obtain Bob's and Alice's public keys, Mallory will be unable to decode any of the messages being sent since she does not know Bob's nor Alice's private keys. Mallory will therefore be unable decode the message or forge an appropriate response.
OK, so everyone is downloading the latest version of Firefox today to help beat the world record. I, like many of you, contributed my fair share by downloading a copy for Windows. But where is the official download count?
IANAL but this sounds a lot like Product Tying which is illegal under US antitrust laws. According to the Wikipedia article, you must show proof of the following conditions in order to be considered as tying:
two separate products or services are involved; (Check)
* Apple's iPhone
* AT&T Phone Service
the purchase of the tying product is conditioned on the additional purchase of the tied product; (Check)
* The purchase of an iPhone is conditional on signing a contract for AT&T phone service.
the seller has sufficient market power in the market for the tying product; (Check)
* AT&T is one among a few phone providers for which the iPhone could be used and contains a substantial portion of that market
a not insubstantial amount of interstate commerce in the tied product market is affected. (Check)
* AT&T is a national cell phone service provider who can directly impact the success of other national providers which are otherwise capable of using the iPhone on their network
I suspect you've never heard of deep packet inspection. Just because you use port 80 doesn't mean it won't be throttled. If they determine you are not using the HTTP protocol then there is a high probability that it will be throttled.
when I had a single 56k dial-up connection that was shared among four computers congestion was the norm. In such an environment, even viewing a single web page often filled the available bandwidth. This made browsing from multiple computers at the same time nearly impossible. To counteract the issue, I implemented a single SFQ QOS on my router and within minutes after turning it on, the congestion was well under control.
Congestion primarily occurs due to more data being sent than can be received during a specified amount of time. Consequently this often results in unnecessary retransmissions of data and increased congestion. By dropping data which would otherwise be duplicated during a retransmission, congestion is relieved and the flow is normalized.
One must therefore ask, why have they not implemented a QOS at the locations where congestion is known to occur?
Quoting the summary, ISPs "... have everything to lose and nothing to gain by not seeing that the content is being properly protected...." Or to put it another way, ISPs have everything to lose and nothing to gain by NOT filtering content.
Last I knew, an ISP could not be held accountable for the actions of their users so long as they remained unbiased according to the actions their users. It is for this very reason that the MPAA and RIAA do not target ISP's for aiding users in illegally obtaining copyrighted material.
However, as soon as an ISP begins to filter content across its network they are no longer an unbiased third party observer and may then be liable for aiding their users in illegally obtaining copyrighted materials whenever their content filtering system fails to protect the rights of the copyright owners. Furthermore, ISPs who do filter content may become targets if their content filtering system interferes with other legitimate protocols.
It seems to me that ISPs have everything to lose and nothing to gain by filtering content.
Slashdot Mirror
Generally, yes it's not worth the time or the effort. However, if you're serious about taking advantage of your old drives, I'd suggest using RAID on top of LVM. LVM will allow you to group drives of different sizes together to form a logical volume. You can then use software RAID to ensure data integrity. Over time, as drives fail, you can replace failed drives with new ones and rebuild the failed logical volume. A simple Samba server should suffice for your file sharing needs.
If you're on a company network and you want to have a network performing okay while bittorrent clients are present on it, you'll need DPI.
That's complete nonsense. Bittorrent and other peer to peer networks are definitely bandwidth intensive, but you don't need DPI to maintain performance on a network. A properly configured QoS should be more than enough to balance things out. Simply prioritizing the outbound data by source address alone would ensure that anyone trying to perform bandwidth intensive tasks gets their fair share. IP protocols were designed to deal with bandwidth restrictions but also to use as much as possible. It's therefore possible that a few HTTP downloads could congest an entire network in the same way a bittorrent client does. This is becoming even more common with modern browsers which use multiple connections to try and retrieve data faster from remote servers.
The only thing DPI provides is the ability to restrict access to specific protocols based solely on packet content. If encryption is used, DPI is useless as it cannot differentiate between the traffic. The end result is a never ending war between software developers and network administrators. The final outcome has yet to be decided.
You and the author of the article both seem to be missing one important aspect of password hashing. You're never supposed to apply a particular hashing algorithm directly to a password. Instead the user's password should be combined with some salt(random data) and then hashed. The resulting hash can still be brute forced, but any resulting hashes can't be used as collisions for other stored hashes as they require a different known salt to be used. In other words, while it took the author 49 minutes he only had to compute 6^n number of hashes where n is the number of possible characters per position (lowercase, uppercase, numeric?). If each hashed password had a different known salt appended, he would have had to compute 14 * 6^n number of hashes. This is an order of magnitude larger than the original time. Of course, this only applies if the salt is known. If the salt is unknown during the brute-force it's practically impossible to discover the original password.
Sadly it seems a lot of people still think $10,000 is a briefcase full of cash. Lets break it down shall we.. Assuming they used standard US bills we get the following:
At 0:14 when they open the case you can clearly see several stacks marked as $100, some as $50, and some as $5. If the briefcase truly has $10,000 in it, the stacks marked with $100 bills must be filled with something other than $100 bills as a single stack would equal the amount the briefcase was said to hold. Given the variety of bills in the case, it appears they went to a lot of trouble to convince us that they gave away $10,000 USD. The reality is they probably didn't, and that the entire thing was just as staged as the briefcase full of cash.
I completely agree. Remove the word "lawful" from all sections and I'll be much more supportive of their efforts. If all content and application communications were protected under the First Amendment then word "lawful' would only serve to restrict that right in the future by designating specific things as "unlawful". The last thing we need is government overview of what applications or content are considered "lawful".
I thought gasoline taxes already accounted for this sort of thing. That is the more you drive your car the more tax you pay in taxes. If you're one of those idiots that must drive an 8mpg SUV then you undoubtedly pay more in taxes than someone who drives a midsized or compact car. Is this fair? I think so.
This may be true for the moment, but now that someone is actually capitalizing on jailbroken iphones, Apple's attempts to completely restrict people from installing what they want on their devices could be construed as anti-competitive behavior by a judge. That is, if they were to secure all flaws in the phone's operating system via an update and not provide people with the availability to install software from a competing vendor, Apple could face some serious fines for effectively trying to eliminate the competition.
If this ever winds up in court, Apple might try to argue that jailbroken iphones are against the DMCA. The competing store however might argue that it was done for "compatibility" purposes, which last I recall was allowed under current copyright laws. In the end if something like this does ever happen, it'll definitely be a case worth paying attention to.
PBS had a great 1 hour segment on this not too long ago. Their segment covered the rapid decline in albatrosses due to offspring being fed the plastic from the pacific. I haven't been able to find the complete coverage of the segment I saw on my local PBS station, but I have managed to locate part of it here titled: World's Oceans Face Problem of Plastic Pollution
Landesk is one such solution.. Unless of course you need something to monitor software installed on non-Windows machines...
For all those interested, Scientific American has the story.
Something tells me he hasn't heard of the mysterious black smoke.
Sure, install Bind/Named or any other free DNS server and do the look-ups yourself. Having your own DNS server dramatically improves look-up times. It also prevents the unfortunate situation where you're unable to resolve any sites simply because your ISP's DNS servers have failed.
This may not actually help. In the cases where I've noticed filtering being applied, I still experienced connection timeouts after filtering out TCP reset packets at both ends of the connection. This is an indication that some blocking is done after the reset has been sent. In the case of UDP, the carrier would simply drop any suspected P2P packets and the connection would eventually timeout.
Since UDP is not a guaranteed network protocol, the strain from having to implement packet ordering and retransmissions for every connection and every application would become very processor intensive if implemented on a per application basis. TCP was designed specifically for this purpose and provides a central system for performing these services. The abuse it has been receiving lately by network carriers shouldn't be taken lightly.
Some people have been defending Comcast based on the amount it would cost them to upgrade their network and provide their current customer base with unlimited network bandwidth as advertised. If cost were really an issue, their overall profit would not be nearly as high as stated in their annual and quarterly earnings reports at http://www.cmcsk.com/phoenix.zhtml?c=118591&p=irol-earnings
Based on these reports Comcast has had plenty revenue to spare which could have been spent on upgrading their network for quite some time. Instead, they choose to throttle their network users in order to increase company profits and earnings per share for their stockholders.
Even though most of the affected servers have been patched, DNS is still broken. The patches thus far only make it slightly harder to exploit. Before the patches, you had a 1/(2^16) chance of guessing the sequence number. With the patches the likelihood of guessing the correct combination of port and sequence number has decreased to approximately 1/(2^32). Given there were reports that were reports of successful attacks in as little as 10 seconds, the patches only increase the time needed to approximately 10 minutes. With a fast enough internet connection, a successful attack could still take only minutes to succeed. DNSSEC or some other alternative may be the only way to avoid this issue completely.
I'm not familiar with the specifics of how DNSSec works, but public keys are usually exchanged during the initial stages of the conversation. For example, Bob might start the conversation by telling Alice his public key and ask that she send him her's. At this point, Alice has two options. She could just tell Bob her public key, or she could encrypt her public key with Bob's public key. The second option is slightly more secure, since anyone listening to the conversation would only have heard Bob's public key.
The only issue with public/private keys is that it is susceptible to a man in the middle attack. As soon as Bob announces his public key, anyone pretending to be Alice could reply with their public key. This is what key signing is supposed to solve.
The issue isn't so much as identifying who you are communicating with as much as it is ensuring that you're only communicating with one remote host. All the current DNS vulnerabilities exploit the fact that a third party can easily forge a response.
Encryption via public and private keys is the most effective way to currently ensure that you are actually communicating with a single remote host. The way it works is as follows:
If Bob wants to talk to Alice, Bob encrypts his message with Alice's public key. Alice decodes Bob's message with her private key and encrypts the response with Bob's public key. Bob can then decode Alice's response with his private key.
If Bob needs to ensure that he is indeed speaking to Alice, he can request Alice to encrypt all messages with her private key before encrypting them with his public key. Bob can then be assured the message came from Alice if he is able to decrypt it using his private key and Alice's public key.
Though Mallory could obtain Bob's and Alice's public keys, Mallory will be unable to decode any of the messages being sent since she does not know Bob's nor Alice's private keys. Mallory will therefore be unable decode the message or forge an appropriate response.
My ICQ number is 5318008. Feel free to chat.
Thanks. Moderators mod parent up, very informative.
OK, so everyone is downloading the latest version of Firefox today to help beat the world record. I, like many of you, contributed my fair share by downloading a copy for Windows. But where is the official download count?
* Apple's iPhone
* AT&T Phone Service
* The purchase of an iPhone is conditional on signing a contract for AT&T phone service.
* AT&T is one among a few phone providers for which the iPhone could be used and contains a substantial portion of that market
* AT&T is a national cell phone service provider who can directly impact the success of other national providers which are otherwise capable of using the iPhone on their network
I suspect you've never heard of deep packet inspection. Just because you use port 80 doesn't mean it won't be throttled. If they determine you are not using the HTTP protocol then there is a high probability that it will be throttled.
when I had a single 56k dial-up connection that was shared among four computers congestion was the norm. In such an environment, even viewing a single web page often filled the available bandwidth. This made browsing from multiple computers at the same time nearly impossible. To counteract the issue, I implemented a single SFQ QOS on my router and within minutes after turning it on, the congestion was well under control.
Congestion primarily occurs due to more data being sent than can be received during a specified amount of time. Consequently this often results in unnecessary retransmissions of data and increased congestion. By dropping data which would otherwise be duplicated during a retransmission, congestion is relieved and the flow is normalized.
One must therefore ask, why have they not implemented a QOS at the locations where congestion is known to occur?
please move along.
Quoting the summary, ISPs "... have everything to lose and nothing to gain by not seeing that the content is being properly protected ...." Or to put it another way, ISPs have everything to lose and nothing to gain by NOT filtering content.
Last I knew, an ISP could not be held accountable for the actions of their users so long as they remained unbiased according to the actions their users. It is for this very reason that the MPAA and RIAA do not target ISP's for aiding users in illegally obtaining copyrighted material.
However, as soon as an ISP begins to filter content across its network they are no longer an unbiased third party observer and may then be liable for aiding their users in illegally obtaining copyrighted materials whenever their content filtering system fails to protect the rights of the copyright owners. Furthermore, ISPs who do filter content may become targets if their content filtering system interferes with other legitimate protocols.
It seems to me that ISPs have everything to lose and nothing to gain by filtering content.