Archive for June, 2005
Well I finally gave in and bought a Treo 650. I’d been waiting, and was terribly disappointed when Verizon released it wothout EVDO, but even still it’s rather nice. Data speeds aren’t great, and it’ll take me a little while to get used to this tiny keyboard, but it’s a vast improvement over SMS from my cheap Audiovox.
Saw this post about a “10 step approach to a secure server” and decided to sort through old courseware I’d written and filter through my bookmarks to provide readers with a fairly comprehensive list of resources for hardening a Linux box (regardless of flavor/distribution/vendor/purpose).
Bearing in mind that there are probably several hundreds of websites and whitepapers that talk to this topic, I’ve tried my best to filter the wheat from the chaff, leaving only those resources that I believe are valuable and offer some unique insight, perspective or technique…
I will also try to keep this page up-to-date by adding new resources as I find them.
Apparently someone had plenty of time to try to login, and was not deterred by repeated login failure. That set me on a course to find a solution that was simple, effective and enough of a barrier to the attacker that they would move on out of frustration, or simply be denied enough that they would find easier targets.
That search led me to find DenyHosts, a simple and elegant solution that works with a minimal configuration effort and is small, quick and clean. The ease of installation and operation make this an effective solution to annoying SSH attackers, and one that you should consider if you are using SSH services.
DenyHosts then processes the sshd server log (typically, this is /var/log/secure, /var/log/auth.log, etc) and determines which hosts have unsuccessfully attempted to gain access to the ssh server. Additionally, it notes the user and whether or not that user is valid (eg. has a system account) or invalid (eg. does not have a system account).
When DenyHosts determines that a given host has attempted a configurable number of attempts (this is known as the deny_threshold), DenyHosts will add that host to the /etc/hosts.deny file. This will prevent that host from contacting your sshd server again.
Also, DenyHosts will note any successful logins that occurred by a host that has exceeded the deny_threshold. These are known as suspicious logins and should be investigated further by the system admin.
Two researchers from the Institute for Cryptology and IT-Security have generated PostScript files with identical MD5-sums but entirely different (but meaningful!) content.
Ok, so this really is a pretty amazing demonstration of MD5 collision, as it uses two PostScript files (both available for download) which render two vastly different documents but both produce the same MD5 hash. Scary.
In this example, however, note that the files used are PostScript files, and as one commenter at Schneier’s page suggests:
The drawback of this attack is that the proof of bad intent lies within both documents. That is your “evil” content exists within the “innocent” document and vice versa, so that if the documented is opened in a text editor you can realize what is going on.
The overview by Magnus Daum and Stefan Lucks is very good and I highly recommend that you pull down their example files and see this firsthand.
Ran across an interesting idea for a self destructing server that essentially entails auto-burning a CD and rebooting to securely wipe the drives on a server containing sensitive information:
“My idea is to keep a blank CD-R in the drive of the server at all times. On [a] hard disk there is an ISO file that is written to the CD-R on demand and then the server is rebooted. The server will ignore the blank CD-R during reboots until it is written with a valid image. The contents of the ISO needs to be a boot loader and kernel, like Grub and Linux plus a file system with a wipe program. The wipe program is started once the kernel is booted and it iterates through the collection of hard drives, which the kernel found during the boot process, and writes over them with a pattern.”
So “The World’s Biggest Hacker,” purportedly responsible for “the biggest military computer hack of all time” (says Paul McNulty, US Attorney for the Eastern District of Virginia), is now out on bail:
Gary McKinnon, the man accused by US authorities of perpetrating the “biggest military computer hack of all time”, was released on bail of £5,000 by Bow Street magistrates yesterday evening.
The British programmer is accused of causing $700,000 worth of damage by illegally accessing 58 computers at Nasa, the US army, US navy, Department of Defense and the US Air Force. If convicted he faces 70 years in jail and a fine of up to $250,000.
McKinnon, who operated under the pseudonym ‘Solo’, claims that he accessed the systems to search for evidence that the US government had information on UFOs that was being covered up.
So, I think this is really funny. Maybe it’s because of I’ve never heard of the guy, nor do I know anyone who has, or maybe it’s just because the headlines are so ridiculous. Techdirt’s Mike had a few excellent comments:
What’s Next? The World’s Fattest Hacker?:
The tech news is filled with headlines today about the “world’s biggest hacker” who has apparently been caught in London. Of course, whenever you read sensationalistic headlines claiming some extreme, it should make you wonder. Like some others, my first impression was that, perhaps, this was the world’s fattest hacker. Otherwise, how do you judge exactly the world’s “biggest” hacker?
…the “biggest” part seems to come from the “damage” estimates, which tend to be about as accurate as BSA estimates on “lost revenue” from copied software. Often these estimates come from a combination of the value of the data that might have been compromised plus the cost of patching up the system that should have been secure in the first place.
It just doesn’t add up, “$1 billion” in damages by breaking into the “most secure computers at the Pentagon and NASA”. For starters, how are we calculating damages, and how confident should the American public feel if one guy in his late thirties can break into the “most secure computers at the Pentagon and NASA” by scanning “tens of thousands of computers on US military networks from his home PC, looking for machines that might be exposed due to flaws in the Windows operating system”. Later in the article, “Many of the computers he broke into were protected by easy-to-guess passwords, investigators said.”
Hmmm… as a taxpayer, my first question is this: “Why are the most secure machines at the Pentagon and NASA connected to (likely unpatched) Microsoft Windows machines with easy-to-guess passwords? How do we know he’s the ”biggest“? Is there a list somewhere, did we just ask a random sample of script kiddies who they thought was ”the biggest“?