Seems like it did mostly the same thing?
Slashdot videos: Now with more Slashdot!
until it begins to wear down your brain and you get Alzheimer's at 30
Good point. I don't think we understand enough about the electrical operation of the brain to be jumping for this. If I had to make a comparison, we can turn up the clock rate on an oscillator, but it doesn't mean that the device relying on the clock can handle it without some strange, sudden and premature failure.
I have been close to this case for various reasons, but this dude's exploits were only detected after the card brands detected massive fraud. The Secret Service might have authorized breaches, but I am sure the Secret Service didn't authorize CC fraud or divulging cardholder data to random people for them to commit fraud.
Fake it? Not in the last five years!
unless you know of some BGP peers that refuse the standard peering protocol, 1) they are required to only listen to routes from known surrounding peers, 2) will not be listening to what's being advertised by your router unless you have instructed them ahead of time what AS you manage and what prefixes you will be advertising to them.
No. Period, fucking no. Most BGP sessions run between customers and carriers are still basically allowing whatever. Even the big boys basically don't care what you advertise. It would cause too many problems to go and begin filtering, so only regions that seem to have routing DBs (RIPE region) are even remotely participating in this. For the most part, thats a few places here and there, but the carriers will let you do what you want.
Don't believe the hype: BGP is still as weak in public IP as it ever has been. The difference is that if you do decide to hijack someone else's prefixes (don't even include bogons, because the carriers will probably let you advertise those!), everyone will know and you will get your upstream looking at you.
> my provider uses 10.* addresses there therefore I had to change the
> addressing scheme on my LAN because
Why did you chose 10.x.x.x for your LAN in the first place ? I doubt that you are planning to connect 16,777,216 machines to your LAN
Guide lines are to use:
192.168.X.X if you need 65,536 IP addresses or less
172.16.X.X-172.31.X.X if you need between 65,536 and 1,048,576 IP addresses
10.X.X.X if you need between 1,048,576 and 16,777,216 IP addresses
Routing is slightly faster with more bits in your netmask. Although I do not think that you will notice a difference especially nowadays. I think this was one of the reasons for these guidelines. Following the guide lines also ease connectivity to bigger nated networks, your provider in your case.
We're in the era of VLSM. Please stop spreading this nonsense of classful addressing.
You see, once upon a time, HP left their network gear alone. Cisco and HP weren't much of competitors. Then, one day, after firing a CEO, HP decided that they should try to push the product line.
In the mean time, Cisco wasn't worried. But Cisco also had this "strategic alliance" with EDS, complete with multiple teams related to the account. One day, EDS got sold to HP. HP is pushing its product on EDS customers.
Cisco has the money to do this. Ever since around 2003, they have made sure to keep a good amount of cash on hand to finance their own endeavors. Yes, HP offers a lifetime warranty on their products but for anything more than access switches, I wouldn't use them.
Cisco has people like me and I'm far from alone.
I'm very picky about where I accept employment from and I CHOSE to work at Cisco even though I despise Northern California. For whatever it's worth.
I'm with you. Worked for Cisco because well, they do take the opportunities to foray outside of the core in routing/switching. The talent there is incredibly diverse and includes people who do know way more the just network gear
Fact is, in today's network world, if all you know is networks, you hit a ceiling pretty quickly. None of the folks I worked with were just focused on routing and switching. Almost everyone I knew in Customer Advocacy (Cisco Services) had at least 4 years of experience in something not solely "network" related. Look at the Unity product (its a voicemail system). Incredibly complex on the back end. Folks really have to understand their server operations just to get by.
One of the final projects I worked on before leaving was a virtualization project for CA lab ops. In less than a year, the org went from spending a ton of dosh on individual servers to run tests to less than 10% of the original figure. No one really knew what they were getting into when they did it, but the knowledge base in the company is so huge that you could always find someone to help with a problem
That said, I really don't think this foray into servers is any bigger of a challenge than what Cisco has taken on before.
Do they have an obligation to disclose it to the customers? Probably. Would most customers mind this? Probably not. The average user would just like to be able to access their website unimpeded by "scavenger" class traffic.
Remember folks, most people really are not affected by policies like this. The people that are affected by these are not the sort that an ISP really wants to keep as customers anyway. Its a fact of life and, the reality stands, the only thing that makes it sleazy is the lack of transparency.
If we want networks that will be able to support the full gamete of voice, video, and data at affordable rates, we are going to have to accept QoS as a fact of life. If you have little more than a basic knowledge of how these applications wreck havoc in a network, I'd suggest running a simulation. (I do this for a living, so its not so hard to see). If you can't tell me why voice requires priority queueing versus web traffic that can handle best effort treatment, you probably don't understand the issue beyond an oversimplified argument that all traffic is "equal". Folks, it isn't. Traffic behaviors and needs make traffic unequal. QoS/Traffic Management/Traffic Engineering is necessary in today's oversubscribed environments to ensure that we can still access resources such as HTTP, SSH, VoIP, Video, and not be overrun by folks who crank up torrents, spew spam, and let worms run rampant from unsecured machines.
"The software contains serious design flaws that have led directly to specific vulnerabilities that attackers could exploit to affect election outcomes," read the University of California at Berkeley report, commissioned by the California Secretary of State as part of a two-month "top-to-bottom" review of electronic voting systems certified for use in California. The assessment of Diebold's source code revealed an attacker needs only limited access to compromise an election."
Link to Original Source