Saturday, September 30, 2006
Friday, September 29, 2006
Thursday, September 28, 2006
The d*mn connection still drops out periodically but at least I can upload posts and timestamp them quickly.
Wednesday, September 27, 2006
Tuesday, September 26, 2006
Monday, September 25, 2006
Saturday, September 23, 2006
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.
Friday, September 22, 2006
Thursday, September 21, 2006
Wednesday, September 20, 2006
Tuesday, September 19, 2006
Monday, September 18, 2006
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?
Sunday, September 17, 2006
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.
Saturday, September 16, 2006
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.
Friday, September 15, 2006
Thursday, September 14, 2006
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.
Wednesday, September 13, 2006
Monday, September 11, 2006
Side note: McAfee appears to be twisting trackbacks and making them look like comments.
Sunday, September 10, 2006
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.)
Saturday, September 9, 2006
Friday, September 8, 2006
Thursday, September 7, 2006
Wednesday, September 6, 2006
Tuesday, September 5, 2006
Monday, September 4, 2006
Sunday, September 3, 2006
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).
Saturday, September 2, 2006
Friday, September 1, 2006
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):
- Block the port (don't allow it).
- If you can't block it, use an application proxy.
- If you can't use an application proxy, use stateful packet inspection (SPI).
- 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?