Sunday, December 31, 2006
To fill in the gaps, here's a few bits:
- While the message ID for email is unique, it may or may not be random. It may be worthwhile to know more about the systems handling the mail you're investigating. (Hint: Message ID's generated by Sendmail are based on process number and time of day.)
- In addition to NetBIOS (for Unix systems, use nbtscan), it's likely to be worthwhile to run other tools, like Nmap, to get a better idea of the services running on a machine. This is an act of last resort though as accessing a suspect system may foul any legal proceedings. Then again, if the system is out of your reach...
In any case, it's been five years since the book was published. I expect that it will be updated shortly (I hope).
Saturday, December 30, 2006
Friday, December 29, 2006
Please be careful in handling the list, there's likely to be innocent bystanders in there also. At the moment, I don't have time to do the research.
Thursday, December 28, 2006
Monday, December 25, 2006
Note: for anyone attempting to download the plugin, the link on the page is incorrect. The code actually resides here.
Sunday, December 24, 2006
Associated with this, the index page of the wiki was overly large, especially after I've been adding various extensions.
In any case, I was able to figure out how to increase the PHP memory limit for MediaWiki from within the code itself. Wiki entry is here.
I've also moved the index to it's own page and have added a couple extensions to the wiki which track changes. See them here.
Friday, December 22, 2006
Credit goes to Count at 757 for pointing me to the (for now, tentative) fix of adding the following near the top of LocalSettings.php and index.php:
That's it! Please let me know if this doesn't fix it or causes other problems.
Wiki entry here.
Thursday, December 21, 2006
Wednesday, December 20, 2006
It appears that I may have to resort to HaloScan or similar if I want to reinstate commenting...
Monday, December 18, 2006
For those using the older CGI-based joatblog, this should be the last visible post. Everyone should update their readers/subscriptions to the following new URLs:
|Direct link to the blog:||http://www.757.org/~joat/ or http://www.757.org/~joat/index.php|
I will be generating the blog on my home machine and periodically pushing it out to the server. It'll improve my relations with the other server tennants, allow me to mess with embedded PHP, and the shorter/simpler URLs should make the guys at CyberSpeak happier too. Heck, it needed consolidation anyways.
Sunday, December 17, 2006
I guess it would help to have an organized project to rely on. Something like Bleeding Edge's black-hole DNS project. Mix in a little policy-based routing (IP and port redirects that are invisible to users) and your troublemakers get quite frustrated. If you manage a network, I recommend looking at this.
Side note: what you use as a DNS server will determine how well you can scale the project. Windows DNS handles 21K domains poorly. Linux doesn't fare much better. (They do work but overload easily.) FreeBSD variants a bit better. The one that I recommend as a DNS server for heavy uses is BSDi (the commercial one). Wind River purchased BSDi and discontinued the product some time in 2003. It's still a very stable platform if you have the license.
Side note: Wind River has purchased and discontinued at least one other OS. They're also the parent to VxWorks, which is that annoying OS in the newer 54G's. Would it suprise you that they've also been a partner to Redhat?
Friday, December 15, 2006
Still won't prevent me from putting the Squeezebox on my wishlist though. (heh)
Thursday, December 14, 2006
Saturday, December 9, 2006
In any case, I now have a very nice web front-end to SageTV with an especially nice (customizeable) show schedule interface.
Notes and screenshots here.
Next up, I want to play with SlimServer. For some reason they say that it doesn't work with the MediaMVP interface for SageTV, but it's supposed to work with the MVPMC firmware. I have hopes. Mebbe I'll have to come up with a way to select which firmware the MVP loads.
Friday, December 8, 2006
Thursday, December 7, 2006
Tuesday, December 5, 2006
The one thing that is hidden (left out) by the documentation is how to start the program: java -jar DVArchive.jar.
Monday, December 4, 2006
As a break, I got the MediaMVP interface to SageTV up and running via a WRT54G which I configured as a client (notes). It works great. It's even able to grab the dongle.bin file (that file name is not required) via the wireless network. No skips, network dropouts or stutters as yet, even with live TV. My two biggest annoyances with the product so far is: 1) I don't yet have sufficient hard drive space to let it run full time (it can eat up space quickly) and 2) it means that there's yet another remote control to lose in the cushions of my favorite chair. On the other hand, it allows me to take down the video sender and the remote control repeaters that were causing so much interference with the network to begin with.
I still plan on playing with MythTV and MVPMC.
Friday, December 1, 2006
Tuesday, November 28, 2006
Monday, November 27, 2006
He asks, "How weak have we become if we can't even tolerate temperatures up to, let's say, 30 centigrade?". My response is it's probably pretty weak if we can't tolerate a little cold, say 21 C?
It irks me because I'm from much further north and I'm quite comfortable in a server room kept at 13 C. I'm used to winter in Buffalo (snow depths measured in feet) and Chicago (sub-sub-zero wind chills). I actually suffer at 25 C.
My secondary response is to tell Harold to bring a jacket if he ever visits me. I won't visit him as there's only so much clothing I'm allowed (by law) to remove in public.
Oh, sorry: here's rough equivalents: 30C ~ 86F, 25C ~ 77F, 13C ~ 55F, 21C ~ 70F.
Sunday, November 26, 2006
Saturday, November 25, 2006
Friday, November 24, 2006
What you're seeing is the traffic generated by my running "iwlist eth1 scanning" on the AP, over and over and over. Doing so revealed that the light noise between channels 10 and 13 isn't actually my neighbor's network. Rather, it's two neighbors' networks on channel 11. There was also another neighbor's network on channel 9 (weird choice).
I really need to get outside and map the neighborhood. I especially need figure out how much interference the video sender will cause if I leave it running on channe 4 (around channel 11 for 802.11 traffic).
Note to self: copy these pics into the wiki.
Thursday, November 23, 2006
What you're seeing is a capture of the signals from each of the channels on my Grandtech AVW-1000 Video Sender that I use to send audio/video into the back of the house. The interesting part is channel 1 which obviously fails to conform to FCC interference regs. (It's an old piece of equipment though). The bad news is that I'm going to have to rethink my spectrum management now that I can "see" it.
Wednesday, November 22, 2006
Tuesday, November 21, 2006
The light noise scattered between 10 and 13 is actually a wireless network belonging to a neighbor, a few house up the street. I have no idea what that narrow band of signal between channel 8 and 9 is. Josh Wright had pointed out a similar band during a recent talk and indicated that it was a wireless camera. Maybe that's the case here too.
Do you see it? (Hint: look at the body but not the text.)
I've got a growing collection of messages in which someone has gone to the trouble of adding little colored threads. It is not a picture as the text is normal. Though the threads are included as part of a graphic, they are inline. If I resize the window, no scrollbars appear (unless there's too much text).
This is too weird. Anyone have any ideas on what it is?
Monday, November 20, 2006
I've been playing with it for the last half hour after spending the first half hour building the software (didn't really take that long to build but I had to chase down a few libraries) and eating dinner.
In any case, over the next few days I'll post snapshots of various types of traffic.
Sunday, November 19, 2006
Various vaguely-related questions about Mr. Balmer's comments:
- Why does this sound oddly familiar? (Okay, it's a leading question.)
- Does this have anything to do with the sudden reversion to that truly horrible TCP/IP stack in the new version?
- Do people yet realize that a covenant means that they won't sue but there's nothing to keep the originator from calling you a pirate, a thief, or worse?
- Does Mr. Ballmer believe that the only way his company can profit is to keep the communities alienated? (There is a not-small population that lives in both. I'm one of them.)
I hereby call for Mr. Ballmer to list the misappropriated intellectual property used in Linux so it can be removed and we can get on with life. (Who needs yet another court case where the claim is that Linus or one of his fanatics stole from so-and-so?) (It's been four years and we still don't know what was stolen from SCO.)
Call me a pessimist but I think that PJ and crew are going to have enough material to keep them busy for a decade or more.
Oh, and before I get beat up for being anti-MS, remember that I usually don't criticize the OS. Rather, it's the company's marketing tactics that I am vocal about.
When does it stop? One pont to keep in mind is that the same tactics used against the open source community are readily adapted to the shareware and freeware programmers on both sides of the fence. Once a company decides that lawsuits are a legitimate (in their view) source of revenue, they will eventually strong-arm anyone they think is profiting (financially or otherwise) without "paying tribute" (MS's phrase, not mine). It might also be called "vig".
Saturday, November 18, 2006
The caption reads: "So where do I deploy my firewall now?"
My answer is: "You don't. You're screwed." And because each of those entities at the edge are likely to have similar looking networks, you're screwed.
The decentralized border discussion has irked me for years because it makes some very bad assumptions concerning trust. Not trust in people, but in their behavior. Just about anyone that has worked network security for any large firm will tell you that people tend to drift towards practices which require the least activity on their part. In other words, people tend to procrastinate and some are downright lazy. Unless you can guarantee that each of those border entities conform to the letter and intent of your security policies, you're screwed.
Your corporate network should reach farther than you can walk in 15 minutes and should only have users whose connection to your internal network can be terminated without a lawyer. The guy who has the power to hire and fire should also be within a 15 minute walk of your office (his pace, not yours).
Decentralized security (the transparent border) has been a rationalization used to spend less money on security and to justify the convenience of teleworking with minimal spending.
External people need access to a service or data set? Good. Stick that service in a DMZ and restrict who can access that. Even better, give them a laptop configured so that it is only capable of connecting to your DMZ. Block your internal users from accessing the DMZ too. If you have to supply access from between the internal network and the DMZ, use an application proxy and limit what can go through where, when (yes time limits) and how.
The only company whose network diagram should look like the picture above is one who gives away network access for free and doesn't require passwords. (In other words, they have no service or data set, only connectivity.)
Yeah, we're going to need identity-based security to be able to use IPv6, but that technology isn't available yet. And don't go pushing NAC at me. That only works when you own the network from end to end (i.e., it's centralized security and won't work with a decentralized network).
Gunnary writes that security models must mirror the changes in business and technology or it's going to be broken. I think he's over-simplified the issue. While the company's "mission" may change greatly (moving from selling sneakers to MP3 players), the reason that the network is there changes little (provide word processing and access to the database).
Decentralized security only works when your users cannot exert changes in any part of the network or even on their local system. If any one of them can connect their node to any other network then there's going to be trouble (ask CNN to tell the story about their senior management and the Welchia worm). If they can connect to yours and the other at the same time, you're screwed.
Here's a hint: if you have a firewall like what Gunnar describes, with thousands of open ports, then your security domain is too big and your security policy is too generic. They should both be broken into communities of interest and protected as separate entities.
Don't believe me? Go interview any Fortune 500 company. I'm willing to bet they partition off specific pieces of the network from their own users, not to mention the rest of the world.
Friday, November 17, 2006
Thursday, November 16, 2006
Update: It's on the newstands! Ethan's project is on page 151. Ironically, the cover has a pinball machine on the front of it which is what he's toying with now. For those that don't know, Ethan is the one who stood up RockTheSkillCrane.com.
Wednesday, November 15, 2006
Tuesday, November 14, 2006
Monday, November 13, 2006
Sunday, November 12, 2006
Saturday, November 11, 2006
Also, would Stephanie Micheneau please review the need for response e-mails for detected infections? MyDoom forges source addresses and I do not run networked systems susceptable to W32 viruses. So please stop yelling at me... (heh)
- You're only buying basic capability. The ability to view those Hak5 or Digital Life vidcasts requires the purchase of additional plugins.
- Archos has a really crappy interface for obtaining those downloads. The font on my product key didn't readily indicate the difference in similar characters so I typed in "O" when I should have typed in "0" (see?). The interface isn't written to self correct.
- The interface has some serious logic issues. Using the activation code with a mistyped product key burns the activation code at the same time that it spits back an error code about the product key. In other words, you can't then fix the product key and legitimately use the activiation key with the good product key.
- The interface has no way to fix the above. Customer support's fix for this is to refund your purchase (something that takes a number of business days to occur).
- The interface is a piece of shit because it's just a digital front end to a manual process. I re-ordered the plugin at 1:45 today and they still haven't forwarded the purchase to processing (the site does have a tracking capability). Now that it's after "business hours", I have to wait until Monday to get this fixed. Needless to say, I'm on the road again, starting Sunday.
Really, a $20 purchase shouldn't be this much of a headache. If it's not fixed first thing on Monday, I'm considering siccing my wife on 'em. (heh)
Wednesday, November 8, 2006
One thing about monopolies. You can usually treat your customers as poorly as you can get away with, without the PUC stepping in. However, you can go too far. Point in case...
My wife ordered two DVR's from Cox Cable and even offered to pick them up at the local store. No, no, Cox insists on overnight shipping.
Three days later they're setting on our porch when we get home from work. One of them is missing it's power cord. After forty-five minutes of being on hold, we determine the other (obviously a refurb) can only display the schedule (no video).
One phone call later, we discover that they can't be shipped back, we have to take them in to the local store. This means that I either have to take a day off or burn a Saturday morning to visit the store.
Two days later, I'm standing outside the local store, waiting for it to open. Unfortunately, other people knew I was going to be there so they decided that they had to show their solidarity by also standing in line. Ahead of me.
Two hours later, I'm at the counter, explaining to the problem with the box to the guy behind the counter. He explains that due to a mix up at the warehouse, he cannot replace my box at this time and asks if I would like to schedule a visit to my house. A few questions later, I discover that I would be charged for this visit.
Five minutes later, I leave the store (with a receipt for the box I just turned in) with a promise that we would be called when a new box is available.
After a few stops at the local gas station, burger joint and shopping center, I arrive home to realize that I hadn't called my wife (when I left the store) to tell her "How The Cable Company Was Going To Fix Her DVR".
Fifteen minutes later, she's extracted a refund for the money paid for the service-so-far, a credit for $20, and a promise that the next available DVR would be shipped to the house. (Have I said that I am in awe of my wife sometimes?)
Five minutes later, I realize that the phrase "ship overnight" was used. (Have I mentioned that sometimes I'm a little slow on the uptake?)
Of course, three days later we arrive home to find that the delivery guy had left the box on the front porch again (we've asked them not to do that).
Ninety seconds later, we place the box on the dining table and open it to discover that the device delivered was a cable converter, not a DVR.
A split second later, I'm able to actually see the large capital letters as they pass through my wife's lips:AUGH!! (I think I know where Charles M. Shultz got the idea.)
Ten seconds later, my wife has dialed the phone to customer support. After the obligatory waiting period, during which the not-really-soothing hold-music is interrupted a number of times by your-business-is-important-to-us-please-hold messages, my wife has determined that: there are no DVR's available at this time as the ones available are reserved for people already on the list for replacement, there's been another mix up at the warehouse, we still don't want to schedule a visit, there's actually no supervisor on duty in the call center at the moment, the operator is unable to understand why my wife is angry, and, ooh!, a supervisor just walked in.
Two minutes later, my wife has a promise that someone will drive out to the house (from the only store in town) to hand deliver the DVR. (Have I said that I sometimes fear my wife?) Whether or not the device actually shows up remains to be seen. I'm not concerned about it though. In situations like this, I never am. It's always handled by my awesome/fearsome/loving wife who used to supervise customer support for a large Japanese conglomerate.
I will admit that I find these snafu's funny much, much earlier than she does. (I think that it's funny now.)
My advice to Cox: 1) Fire the guy in the warehouse (or the programmer that wrote the excuse generator). 2) Tell the poor schmuck who's delivering the box to smile and back away... 3) ...slowly... 4) ... from my wife. The dog only bites. 5) For lessons learned, write down that there exists an Ol' Girl Network (that didn't come out right but you get the idea), somewhat of a NANOG for current and former supervisors of customer service centers, where members have met at conferences, made friends, and know all of the office phone numbers and some of the home phone numbers of many of the OGN members. I doubt The Kevin Bacon Game works here (there's not that much separation) and, for me, "reach out and touch someone" has taken on a different meaning.
Uh, I did indicate that my wife can be scary sometimes?
Hint for those that still don't get it: my wife makes our Halloween costumes with a collection of t-shirts, cans of black and red spray paint, and whatever vehicle happens to be parked in the driveway. (We go as "road kill".) (The trick is to spray the tire as the vehicle is rolling.)
Update: The box was delivered. I discovered: he has a wife too, there really was a mix up at the warehouse (grain of salt needed here but...), and you can catch cold after getting extremely soggy, standing in the front yard, in the dark, in the rain, talking about your wife.
Tuesday, November 7, 2006
Monday, November 6, 2006
Sunday, November 5, 2006
Saturday, November 4, 2006
Friday, November 3, 2006
Thursday, November 2, 2006
Wednesday, November 1, 2006
Tuesday, October 31, 2006
Note: NTIA is to national government as FCC is to general public. The common point between the two is the State Department.
Monday, October 30, 2006
Sunday, October 29, 2006
Saturday, October 28, 2006
Friday, October 27, 2006
Hey, it could happen! Nice slogan though: "Security isn't thin"
Thursday, October 26, 2006
In any case, here are my notes about the tool and, to start, code to push the info into a MySQL database. Like most of the rest of the wiki, it's unfinished work but it should give at least a couple of you a good place to start from.
I'll add more as I redevelop it or re-discover old copies. I guess there can be such a thing as too many backups...
Tuesday, October 24, 2006
In any case, I'm going to try a slightly different approach.
The short version: I will when I feel like it.
The slightly longer version: I will blog when I have something to write about. The format will not likely change, I'll still point out interesting things and, on occasion, vent about some boneheaded stunt.
I just want it to feel less like work.
If someone else wants to join in by adding in their own entries here, give me a yell. We can work something out. (I do have a few guidelines though.)
Thursday, October 19, 2006
Consolidation of resources can be a good thing. It allows for easier management and cheaper operations.
However, past a certain point, it can also be a bad (or very bad) thing. Consolidation of resources without taking into account operations like security or unique organizational requirements (e.g., specific data sets) is poor practice. While collections of smaller (and diverse) systems are more expensive to manage, the overall operation is more flexible and much more tolerant of failure.
Think of it this way --> over the length of your lifetime, which do you think you'd be more tolerant of: 100 paper cuts or 1 accident with a guillotine?
Wednesday, October 18, 2006
There are a serious number of flaws in the logic and I get the impression that he's paraphrasing to justify his logic.
Tuesday, October 17, 2006
File this one under "shooting one's self in the foot"...
Monday, October 16, 2006
Thursday, October 12, 2006
Saturday, October 7, 2006
Thursday, October 5, 2006
Wednesday, October 4, 2006
Tuesday, October 3, 2006
Monday, October 2, 2006
So now I'm torn. Is ZDNet's article on suicide hackers completely silly because the attack is so far-fetched (the attacker doesn't get matyrdom because he doesn't die) or is it likely to occur and succedd for the same reasoning?
Sunday, October 1, 2006
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
Sunday, September 24, 2006
While some of those are legitimate, many are not. I wonder how much trouble Google has defending their trademark.
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?
Thursday, August 31, 2006
Wednesday, August 30, 2006
Tuesday, August 29, 2006
I'm also surprised that a fight didn't ensue...
"He's running Ubuntu!"
"No he's not! He's got Windows XP!"
"You're both idiots! He's got a Mac!"
It's funny, even if it turns out to be fake, though I like this version better.
Monday, August 28, 2006
First Cox blocks my e-mail forwarding from the 757 account because someone complained that email@example.com was in the "From" address. It tooks weeks of arguing with the helpdesk and the abuse desk to get it unblocked.
Then they reblock it by turning on their spam filters, which I had expressly asked that they not do. This caused me to have to set up encrypted mail on two sites and I have no option on a third.
This on top of the near-constant ARP storms and the period loss of carrier on the cable modem. How much do I pay for this?
Sunday, August 27, 2006
- Instant Messaging Worms, Analysis and Countermeasures (slides)
- Self-Stopping Worms (slides)
- Scalable Internet Threat Monitoring
- A Self-Learning Worm Using Importance Scanning (slides)
- On the Effectiveness of Automatic Patching (slides)
- An Analysis of the Witty Outbreak: Exploiting Underlying Structure for Detailed Reconstructions of an Internet-scale Event
- Worm Evolution Tracking via Timing Analysis (slides)
- The Limits of Global Scanning Worm Detectors in the Presence of Background Noise (slides)
- Defending Against Hitlist Worms Using Network Address Space Randomization (slides)
- Host-Based Detection of Worms Through Peer-to-Peer Cooperation (slides)
- The Detection of RCS Worm Epidemics (slides)
Saturday, August 26, 2006
Friday, August 25, 2006
Thursday, August 24, 2006
Wednesday, August 23, 2006
Tuesday, August 22, 2006
It's that simple in that, for any business network, you need to do just that: keep a record. It's not that simple in that, for most business networks, it's not mandatory to keep a record. Personally, I don't recommend using a log book as it doesn't allow for the inclusion of external documents.
If your company lives by paper record, you should be keeping a set of folders, one for each system. Entries should be made via a set of forms (incident, maintenance, configuration change, etc.) that can be dated and signed by personnel concerned with the specific evolution. For some of the entries, management should sign.
If you take the electronic path, I recommend a Wiki or even just a set of folders in a directory on a stand-alone system (not networked!). The same idea for blank form follows: keep a set of templates handy that you can cut-and-paste from.
In either case, you want to limit the access to the logs. If they're paper-based, keep them in under lock and key. If they're electronic, restrict access and don't network the system. File or file system encryption might be useful (if not time consuming). Side note: backups are your friend.
The entire point of the exercise is to produce a legally useable record. It's a benefit for the company in that it can be used to display due care (compliance). It's a benefit for you in that it becomes a reference for keeping track of who did what to when and when. It is valuable to anyone that follows you after you've moved on, so that they don't have to repeat your mistakes (yes, you should include them too) and it'll minimize having to figure out if you did or didn't perform a specific action on a machine.
I used the phrases "mandatory" and "due care" above to denote that there are now a number of laws (GLB, SarBox, FISMA, HIPAA, etc.) in existance that require due diligence (having policy/practices/protections in place) and due care (recording the exercise of due diligence). Most of those laws (if not all) don't care how you perform these functions, just that you have them. If you (as an organization) use a well-recognized set of practices (e.g., ISO 17799), so much the better. You'll use less time having to defend them, should you end up in court.
Monday, August 21, 2006
I'm also experimenting with the Bloglines Blogroll for those same feeds. I've tacked it up over on the left and have re-enabled the Blogrolling.com blogroll for comparison.
Update: Wow, for the half-hour or so, that was horrible. Adding 348 lines to an already crowded panel caused the new blogroll to stick off of the bottom of the page for a long distance. For now, I'll leave the Blogrolling.com list on the left and the Bloglines list on the right, though it still sticks off the bottom of the page.
I promise that it'll get better as I resort the Bloglines subscriptions into folders and limit what folders can be seen.
Then again, maybe I'll just move the thing to its own page. That is a lot of links messing up the page. What do you think?
Sunday, August 20, 2006
Saturday, August 19, 2006
One thing that I've discovered: the DC area has a serious lack of book stores. I've got to drive into Alexandria from Herndon to find one? Geesh!
Thursday, August 17, 2006
BTW, What is the record for shortest thread preceeding Godwin's Law? This one is going to be close.
Wednesday, August 16, 2006
"It's not a 'right' to fly and carry whatever you like," notes David Gregory, a Dallas-based travel coordinator and former airline employee, in one of nearly 200 posts in response to a recent item on USA Today.com's Today in the Sky blog about the threat to the carry-on culture.
"Just think how wonderfully blissful it would be not to have a single carry-on aboard a plane," Gregory adds.
"I say ban all carry-on luggage. It's about time! And if you are so important that you cannot be away from your computer for a day, do us a favor and stay at your office."
Figure it out yet? How about the system admin who states that he wished there were no users on the network?
I bet Mr. Gregory runs a very successful travel business. (heh)
Tuesday, August 15, 2006
If you read the fine print in just about any TOS or contract, the account is property of the system owner and the user is allowed access to the system at the discretion of the system owner. Account termination usually can occur without warning, justification or appeal. The account (and often any data within) remains the property of the system owner. In this case, eBay.
If I were eBay, I'd be investigating the application of "accessing a system without permission" as it relates to the private investigation company.
Monday, August 14, 2006
Sunday, August 13, 2006
Saturday, August 12, 2006
Friday, August 11, 2006
Thursday, August 10, 2006
In any case, this is one of those tools that you need to know how to use if you're going to analyze traffic (though I seem to remember it not handling broken packets well).
Wednesday, August 9, 2006
Tuesday, August 8, 2006
Monday, August 7, 2006
Sunday, August 6, 2006
As far as dangers go, this doesn't rate high on my list.
Saturday, August 5, 2006
Friday, August 4, 2006
Thursday, August 3, 2006
Wednesday, August 2, 2006
Tuesday, August 1, 2006
Monday, July 31, 2006
Two reader responses later and it appeared that we were headed deep into religious war territory. While asking why MS can't keep up in the patching process may have been a bit of a troll, it is a legitimate question. (Hint: pointing out that other browsers' patches have contained problems is legitimate only if MS has never released buggy patches for IE. Otherwise, it's poor logic and tends to make the discussion smell of dead horse.)
I will attempt to answer the question here though.
The answer doesn't lie within the politics of the vulnerability researchers or the "evil intentions" of any of the parties involved. It actually lies within "the process" and the previous coding decisions (e.g., the browser is part of the OS) at MS. Because the code base is much, much larger and because changes within browser code will effect "things" outside of the browser, the distance between "start" and "finish" for MS patches is much longer.
Other browsers have more coders, less code, and fewer OS hooks. Thus the patching process occurs quicker. Simple. It's futile for MS to attempt to keep up and counterproductive to make allusions to the motives of vulnerability researchers. The responsible disclosure "discussion" should have gone away years ago.
I hereby apologize to IronYuppie for troll-baiting. I do tend to like saying "the emporer has no clothes" when it comes to the marketing and public relations departments at MS. Neither one (IMHO) does the company justice in the long run.
Sunday, July 30, 2006
In the two days since the semester's end, I've managed to re-install a content manager and have started work on the "wl" pages in the wiki. I still owe work on the Kismet/Perl pages and a whole slew of stuff for friends. Not to mention a slowly growing collection of wireless toys that I haven't been able to touch in the last 8 weeks.
In any case, I rec'd an "A" and an "A-" (blew two questions on the test). I can relax for a few weeks before the process starts over, though I'm likely to scale it back to only 1 class. (I need the sleep!)
Saturday, July 29, 2006
Thursday, July 27, 2006
Note: it now forwards to the default www.microsoft.com page.
Interesting return from "view source" from http://preview.microsoft.com/en/us/default.aspx if anyone cares to look at it. You might want to take a look at the JS files also.
It's not an argument that the site only works with IE. If it's AJAX, it should work with other browsers. I wondering if if I unravel that code, will I think exclusion is intentional?
Wednesday, July 26, 2006
The other thing to keep in mind is privatized means "for profit".
Tuesday, July 25, 2006
Monday, July 24, 2006
Saturday, July 22, 2006
Friday, July 21, 2006
From: Automatic Email Delivery Software
Subject: [SPAM] ERROR
Date: Fri, 30 Jun 2006 23:28:24 +0300 (16:28 EDT)
Your message was undeliverable due to the following reason(s):
Your message could not be delivered because the destination server was unreachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configuration parameters.
Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now.
Your message was not delivered within 7 days:
Mail server 184.108.40.206 is not responding.
The following recipients did not receive this message:
Please reply to firstname.lastname@example.org
if you feel this message to be in error.
Looks normal, right? The "trick" lies in the attachment. It has a "scr" file extension.
This prompted me to look at the header. Sure enough, my ISP received the message from 220.127.116.11. Even though the IP claimed to be cox.net (told the SMTP server "helo cox.net"), a reverse lookup on the IP returns "primalch.static.otenet.gr". A whois lookup confirms this.
So add the following to things not to do: "Don't open attachments from error messages." I'll look at the attachment this weekend.
Thursday, July 20, 2006
Wednesday, July 19, 2006
And ABC wonders why people have a tendancy to skip commercials when they able to.
I also worry that this will become yet another vector for infection and exploit. Oh, and shame on you, Vonage, for encouraging the mess by funding it (in part).
Tuesday, July 18, 2006
Monday, July 17, 2006
Sunday, July 16, 2006
Lest "Strider Search Defender" sound too anti-Blogger/BlogSpot (they're the same organization), let's keep in mind that it happens on any blog/wiki site that allows for unmediated commenting, including MSN sites. As an experiment, visit Spaces.MSN.com and type your favorite comment spam topic in the search box (the Spaces search, not the web search).
In short, people who live in glass houses really shouldn't throw rocks. It is a nice project though. More power to the analysts, less power to the marketers!
Saturday, July 15, 2006
The question that people should be asking is: if Firefox and Opera can keep up with applying fixes, why can't IE?
For those of us that have to eat antacid while waiting for the vulnerabilities to be patched: for many of the vulnerabilities, the work-around is "turn off ActiveX".
Friday, July 14, 2006
Here's one: it's a good idea to keep current by reading a few of the mailing lists listed here. I recommend Incidents, Daily Dave, and Bugtraq. Not listed, but also recommended, are the Snort and NANOG mailing lists.
Thursday, July 13, 2006
McAfee doesn't make a BSDi-based scanner you say? Okay, but they had one for Linux and BSDi had something known as LDP and you only had to import one missing library from Linux.
This is one of those things that you need to do to monitor your metrics. Another example would be to stick a Linux box running RRD to the side of your Exchange box to monitor the mail system via its SNMP hooks. If it generates numbers (usually over time), it's probably a good idea to graph it and monitor it. A quick look at a graph will usually tell you much the same thing that an hour or so of log reading will.
Wednesday, July 12, 2006
smbclient must be installed suid root...
If you use "chmod a+s /usr/bin/smbmount", then the system complains that there shouldn't be any binaries suid root.
One work-around is to start the program via "sudo smb4k". Of course, you should have already configured sudo to allow your user to execute that command.
Tuesday, July 11, 2006
Of course, the first knee-jerk countermeasure for this is "block ICMP". While the majority of that protocol should already be blocked (for other reasons), the obvious countermeasure may not always be the best. In other words, blocking ports/protocols because they can be abused will lead to the firewall blocking everything. A better approach is to configure your firewall for "normal" operation and then monitor what you allow to pass for anomalies.
What the article demonstrates is the embedding of one protocol within another. It's the reason why various programs are difficult to block at Layer 3 (IP addresses) or Layer 4 (Ports/Protocols).
Some programs (e.g., instant messengers, P2P) are adaptive and can use a number of addresses, ports or transport protocols.
While all firewalls (okay, most) filter IP protocols 6 (TCP) and 17 (UDP), they are often configured to pass others. Many will pass at least some subset of protocol 1 (ICMP) and one or more other routing protocols. Most are not useful for covert channels as, if a network is implemented correctly, the protocols are blocked further upstream. Others are. ICMP is often used for tunneling because certain types of ICMP packets will pass through the firewall and the packets can carry a decent sized payload.
This is why, contrary to what the firewall and IDS vendors tell you, the job of network security is largely a reactive job. The majority of your problems will be internal and you need to face the fact that a few of your users know more than you, don't believe they'll get caught, and have more "access" than you realize.
What you have going for you is human nature (the second option in that last sentence). People who don't believe they'll get caught won't remain "in the background". They'll usually try gradually more daring (and noisier) things.
The most effective countermeasure is monitoring your metrics (especially the most boring ones!) for anomalies, reading your log files, and spot-checking content for normal shape, size, and lifespan. The majority of corporate users (if not all of them) are granted the minimal access needed to perform their job. The content they generate should be boring as hell (HTTP on port 80, SMTP on 25, very small ICMP packets, etc.) Your job includes having to watch for the non-standard stuff (odd flags turned on, non-standard packet sizes, "noise" on port 25 or 80, etc.).
Oh! And make it a point to track down the small stuff too (though you may not always have the time). They'll often lead to the larger "stuff" and may also indicate other problems (misconfiguration) within the network.