Mixed links

Via /dev/random: the story of a fictitious penetration testing. Very interesting, eager to read the rest.

From Kim Cameron's Identity blog: Leaving a comment (with CardSpace / IdentityCards). The first time you do this it takes a whopping 11 steps! I fail to see how this is better than current systems or OpenID. (I'm talking about the user experience - from a security point of view Identity Cards are clearly superior to the old username/password type authentication).

Via devnet's bookmarks: Lifehacker: Top 10 Ways to Get Cables Under Control.

From the Pythian group: Performance tuning: HugePages in Linux. Very interesting read. Machines with very much RAM (16/32GB) are getting pretty mainstream in the enterprise and design solutions from 20 years ago (ie 4kb pages) are not very ideal these days.

From Matt Cutts's blog: a fun email. Similar to my experience some time back. What I find funny is the type of questions people post, even though the comment form clearly states that:

Got a webmaster-related question or suggestion that is not directly related to the topic of this entry? Instead of posting it here, your best bet is our official Google forum linked from http://www.google.com/webmasters/

From the MNIN Security Blog: two interesting posts - Recovering CoreFlood Binaries with Volatility and Locating Hidden Clampi DLLs (VAD-style). This just reinforces my opinion that there are many tricks you can play with the OS which can render investigate tools unusable. The moral: once the attacker ran code on your machine it is not your machine anymore (rule 1 of computer security). Also, generic tools won't do you any good if you want to investigate targeted attacks...

From Didier Stevens: Shoulder Surfing a Malicious PDF Author - cool. It is always fun to follow the digital trail.

From GNU Citizen comes a cool paper: Universal Website Hijacking by Exploiting Firewall Content Filtering Features. It boils down to the following:

Some filtering solutions (they discuss SonicWall in the paper) replace some webpages on the fly with "This website is blocked" type of text. In vulnerable systems you can inject javascript in the page (because it doesn't encode the URL for example). Now, the browser doesn't know that the message isn't coming from the original site - since the replacing is done on the fly in the request/response stream, so it will consider that it comes from the same domain, effectively circumventing the same origin policy. The final part of the puzzle is the fact that you can predictably trigger this filtering by including the f-word in the URL for example.