File carving challenge

For anyone needing practice at recovering deleted files, you might want to try various file carving challenges.

Cryptodox

The CryptoDox site was driven offline by Slashdot so I've added this via a delayed post. CryptoDox has been up for almost a year and has a stated goal of becoming "a free encyclopedia on cryptography and information security." It might be worth keeping an eye on.

Delay

Apologies to anyone who's posted comments this past week. I'm in DC this week and can only get online by running Wi-Fi at just under FCC limits. (This message brought to you by Hawking Technology (their amplifier) and a directional antenna of unknown manufacture.)

The d*mn connection still drops out periodically but at least I can upload posts and timestamp them quickly.

The Forensics Wiki

The Forensics Wiki appears to picked up quite a bit of content since I last visited it. (Can you guess what class Rob is teaching this semester?)

DFRWS

The Digital Forensic Research Workshop has posted various slide sets and notes from last month's workshop.

Online book

The remainder of the chapters for Cracking DES have been added to the online site so now the entire book is available.

Vista

I've managed to download and install the 64-bit version of Vista 5728 in a VM. The inteface looks interesting. I had issues getting it installed but the issues were VMWare related (e.g., network address hijacking) and had nothing to do with Windows.

LURHQ no more

Wow. The name LURHQ won't be used any more. They've merged with SecureWorks and the new company name will be SecureWorks.

In any case, I wish them the best of luck. I first met the LURHQ guys, almost a decade ago, when they were doing remote firewall management for an organization near where I worked. I hope they continue to post their malware analyses.

Read about the merger here.

lsof

If you're doing a live response or just trying to track down an odd binary on your system, lsof is often an invaluable tool.

Heads up!

Would the owner of 210.245.97.8 please check your Liferea client. It's gone berserk again.... (heh)

SSH Attack Analysis

SecurityFocus has an analysis of recent brute force attacks on their SSH honeypot.

Spam

The recent e360 rumble reminded me that I hadn't visited a few sites in awhile. It's always interesting to watch both ends of the ordeal (if you don't mind waiting)(these things take time). In any case, here's one on the front end: Spamhaus and here's one on the backend: the FTC's Commission Actions for 2006 (look for links with the "FTC v. so-and-so" format. (Their archives are here.)

Arrr!

Oh no! Has another year gone by already? Some of my coworkers really enjoy TLAPDay, others have to have it explained to them. Anyone know if Ricky wore the outfit again?

Back

I'm back online at the house. I spent most of Saturday reinstalling OSs and cleaning out the rats nest (my wife's idea) of cabling behind my desk. Believe it or not, I've recovered two Ethernet cables, six coax cables, a 100 foot phone cord, a 30 foot extension cord, a power strip, and a wall-wart power supply for some unknown device.

Admittedly, after reconneting everything it still looks like a rats nest. I had to show my wife what I'd recovered to prove I'd actually accomplished the job. (heh)

I spent Sunday re-installing much-needed apps while dodging snipes from my daughter in-law that she needed to be online, "Right now!!" (In other words, her apps rec'd priority.)

Side note: for those considering the purchase of a dual-core 64-bit system, now that the prices have come way down, there are a few things to consider (I've learned the hard way):

• there's not a lot of 64-bit OSs out yet
• some of your hardware (e.g., Digium TDM400P (rev. J)) won't like your 64 bit OS
• some of your software won't take advantage of the new hardware or the 64 bit OS

The above has lead me to triple boot my system (XP, 64-bit Linux, regular Linux) and consider offloading specific functions to a separate system (e.g., running the house mail and web servces on dedicated NSLU2's). It's also lead me to seriously consider moving some of my day-to-day functions to a dedicated service online (yeah, pay for private email/web services). Given that there are now four adults in my household, three of which use computers heavily (my son shows no interest), is it worthwhile to buy a domain and move our day-to-day needs a private domain on a hosting service? After looking at various offerings, it'd cost us a couple hundred a year and would allow us access to the services from wherever we happen to be.

Has anyone else done this? Is it worthwhile? Do you think that there's a niche market for this?

Merry Halloween!

Never let it be said that Walmart is slow to make a buck. As of today, (maybe earlier) Walmart has their Christmas decorations on sale. They stocking about 2/3 Halloween and 1/3 Christmas. Used to be you didn't see Christmas decorations until sometime after my birthday (next month).

The rest of GoogleMaps

Just noticed that GoogleMaps now goes elsewhere. (Hint: zoom out)
Question: what is out in the middle of what appears to be a man-made body of water, hidden in some trees, at the end of a finger of land, the entrance of which is blocked by a large, fenced-in building which appears to have had the city limits "adapted" so that the entire design is part of Moscow-proper? I don't speak/read Russian and I'm assuming that's what is indicated by:

Update: That site appears to be at the end of a railroad spur, complete with station (to the southwest of the building), looks like it has it's own horse-barn (to the northeast of the building), and is at the end of a canal (from the building off to the north-northwest) that goes nowhere (follow it!). Note: Ignore the "Ekeren, Belguim" part. That's an artifact from the original search.

Botnet Economy

Hopefully we'll see more from Thorsten Holtz, over at the honeyblog, on "The Economics of Botnets" (part 1)(part 2).

Metrics

An incomplete set of thoughts triggered by Gunnar's blog...

Gunnar Peterson blogged about Dan Geer's synopsis of MetriCon. On some points, I disagree with Gunnar and Dan both.

We do have quite a few security metrics. It's just that they're often disguised as other things: router traffic levels, service load graphs, inventories, trouble ticket systems, personnel management systems, etc.

To take of Gunnar's point, "metric" is also a particularly harmful word in that not everyone understands what a metric is. Yes, it is something that is measured over time. (This is where most people's definition stops.) It also includes the processes for interpreting the gathered data. This can be in the form of: overlaying a daily average or an acceptable range, setting trigger points based on sustained levels, setting priorities based on levels of non-compliance, etc.

In other words, it's not just the collection of data. It's also how you use that data (e.g., what decisions you base on the data or what do you calculations control). You also have to decide how you're going to federate that data (single-purpose metrics are rare).

People get into serious trouble making assumptions about security metrics (i.e., "we need them!") without defining "what the job is".

To better design your metrics:

• First, determine what decisions need to be made. If they're management level decisions, they should be very broad and generic. If they're technical level decisions, they should be very specific and rigin.
• Next decide what set of questions relates to each of those decisions. Each question should be simple. Examples include: "how many" or "how often").
• Then determine what temporal data sets are available to answer those questions. (Keep in mind that whatever the data is, it needs to be tracked over time.) This step is often the most difficult as the available data is often outside of the local knowledge base (e.g., in someone else's department or organizations) even though it is often readily available.
• Lastly (and most importantly), train people (or hire 'em) to use those metrics. The majority of metrics already available rot on the vine, ignored by the people who most need them. Your high-level metrics will affect the most people and will likely require the most training and tend to support long-term decisions. Your low-level metrics will be the most technical, will be used by the fewest people, will be the least visible, and will tend to support repetitive high-speed (daily, hourly, etc.) decision.

Online Book

Wi-Fi Toys has started posting chapters from their book online.

Sorry

Apologies for being offline for the better part of a week. I managed to damage the file system on my new desktop system and haven't had the time to rebuild it. Between work and real life, I've had to squeeze in a few hours of sleep and haven't been able to even turn the darn thing on, let alone re-install anything.

Oh! And thanks to the MS OEM system install config, I have to install Windows, resize it, add partitions, and then install the other two OS's. So it's going to take most of a morning. Right now, I'm posting from the local college.

In any case, I'll play catch-up shortly.

BIND

Even with all of the derision and down-your-nose condescension, I still like BIND. It's what I "grew up" with and it's still part of the guts of the Internet (like it or not!). It's one of those nice to know, even if you use something else. So, here is a quick Debuntuhowto for setting up a zone in BIND.

EFS attacks

McAfee's Avert Labs has a piece on "preventing EFS-based attacks" which describes a few steps to prevent your data from being held hostage. Basically, it describes the steps for disabling the encrypted file system capability in your Windows box.

Side note: McAfee appears to be twisting trackbacks and making them look like comments.

DNS overload?

I agree with Dan Kaminsky (and therefore disagree with Paul Mockapetris): Vista will not overload the Internet's DNS architecture.

What it may do, is overload your internal DNS architecutre, if your internal architecture is already running near capacity. It all falls back to architecture planning.

For those that need to "learn by doing": put four emergency spares (tires) on your car and then get out on the interstate and try to drive 500 miles while maintaining the speed limit. (Hint: I-95 works best. The speed limit is 70 in places and you'll quickly earn the enmity of those drives behind.)

Harlan Carvey

Finally got the chance to use a newer version of the Helix disk and noticed that Harlan's First Responder Utility is an option under "Incident Response". It's probably late as heck but: Congrats Harlan!

OpenPGP Card

If anyone has worked with the OpenPGP Card, please let me know.

S4W

I know this violates a standard (don't point to other people's posts without adding content) but I'm a bit short on time and still think it's valuable: Dana Epp has pointed out that Slueth Kit is now available for Windows.

hping2

Here is a tutorial on hping2 basics. For those that don't know, hping allows you to craft and send packets to perform various functions (yeah, for good or evil) that require standard and non-standard packets.

PAI

For those just getting into packet analysis (or those needing practice), PAI might be a good place to start. (Hint: Look in the downloads section.)

Jody's been hacked

Hmmm... Someone has way too much time on his hands. What's the point of defacing blogs like Jody's TryingReallyHard blog? There's no value, it's just mean.

It's the little things

I snagged a Formosa RC107 (pic below) out of the clearance bin this weekend. While I was looking for one with a laser pointer (for presentations), the mark-down on the thing was enough to cause me to grab it. I think that a combination of missing CD, open package and physical size caused whomever was doing the mark-off to label it for $10. (It normally goes for $40 or so.)
In any case, the bad news is that it's not supported under lirc. The good news is that Ben Chadwick has a "Linux replacement" (his words) for the remote control app. Even though his pictures are different than what I'm holding (mine uses a PCMCIA card form factor), I have hopes that his program can be adapted quickly if it doesn't work outright.
Wish me luck.

Update: Just for info, this is sold/rebadged under the following names (AFIK): CompUSA, eDio, Formosa, and Trust.
Update II: Whoever the actual manufacturer is of this thing, they should give their case designer a pay raise. It has the P/N for the battery embedded in the molded platic battery cover (not something I see much, esp. on Chinese-made electronics).

Dumb

Wow. I can't believe I actually didn't know what was causing the "Symbol version dump Module.syms is missing error". (Hint: this is what happens when you try to compile a module against a kernel that hasn't been compiled.)

Firewalls

Fred Avolio's post about "experts" dredged up old memories and pain. It also triggered the need to vent, so here goes...

Building on what Fred listed:

• We rarely agree (especially in groups larger than two).
• We love to argue (though most cannot argue without using a whiteboard or scribbling on numerous pieces of paper).
• Many of us are cynics.
• Most of us have a nickname (though many don't know it). Most are along the lines of "Princess of Darkness" (POD, for short), "Network Nazi", or plain old "asshole" (you're the guy that blocks their IM, remember?).
• Most of what we do, others find tedious or consider "anal retentive".

Regardless of what Gartner and the like say, the various rules for firewalls and firewall policy still haven't changed.

Rules for choosing a path through your firewall (displaying Fred's bullets that we state the obvious and rehash the same old stuff) (and at the risk of starting yet another religious war with various factions):

1. Block the port (don't allow it).
2. If you can't block it, use an application proxy.
3. If you can't use an application proxy, use stateful packet inspection (SPI).
4. If you can't use SPI, use a packet filter (or router ACL).

Rules of thumb for firewalls (in no particular order):

• Filter/block as high as possible in the OSI model (protocol, then state, then port, then IP). Two or more of those at the same time is better.
• Periodically have someone else review your firewall configuration. (e.g., Dump it to paper, give it to one of the techs for weekend "homework".) Then review it yourself. Any unanswered questions at the end of this process is an indication of a problem.
• Don't "filter and forget". Make sure management realizes that adding exceptions to the firewall also adds monitoring requirements. At a minimum, periodic spot checks via net flow and packet capture.
• Keep a record of any changes to the firewall, who needed them, and who authorized them. (Signatures, dates and justifications are valuable!) In other words, don't make changes without authorization and always document them.
• Read your damn logs! Do so on a daily basis! Firewalls (and routers) (and servers) (and IPS/IDS systems) are not plug and play. Waiting to read your logs until there's an overt problem is plain lazy. Big problems start small and build over time.
• Learn effective log file reduction.
• If you're bored, you're working in the wrong field.
• If you're worried about how other people think of you, you're working in the wrong field.
• If you can't function without a budget, you're working in the wrong field.

If you have time on your hands:

• Drag out tcpdump or netflow and take a look at what's crossing your internal network. (Be sure you have permission!) Again, this is another "big problems start small" preventive action.
• Pick a tool and learn the switches. In other words, know your tools. You'd be surprised (or, at least, others will) what you can "glue together" with available tools and a bit of scripting.
• Try and clean your desk. Yeah, you'll never finish the job but some of that stuff has to be thrown out. (Nobody uses ISA NICs any more so why are you keeping them?)
• Write a tool that gathers metrics. Pick a service or node and graph the load on/through that service or node. Learn what "normal" looks like.
• Script the above so that you can display it on a web page in real-time (or near real-time). I've found monitoring the following metrics to be valuable: mail traffic levels, number of viruses captured, traffic levels through specific router interfaces, and web traffic levels.
• Wander through your organization and talk to people. You'd be amazed about the number of problems you can head off via simple conversation. You'd also be amazed on how much PR is generated for "security" if people get to see your face on a daily basis (in semi-social settings) (presentations and company meetings do not count)

Periodically scan your network (again, be sure you have permission) and try to answer one or more of the following:

• Do you know how many workstations are on your network?
• Do you know how many servers are on your network?
• Do you know the MAC address of every node in your network, especially the workstations? (It is possible to grab MAC addresses remotely with MS Windows systems.)
• Do you know what ports should be open on each of your servers?
• What about your workstations?
• Are there any open shares in your network?
• Are there any unauthorized services running in your network?
• Are there any unauthorized systems connected to your network?