locks keep lawful people out...    

The Security Skeptic

Dave Piscitello's Security Weblog

Skeptic (sceptic): a person inclined to question or doubt accepted opinions.

Web www.corecom.com The Security Skeptic
Fri, 31 Mar 2006 00:00:00 00, 515
Domain Name Census Information?

Dennis Forbes has written and entertaining article describing the current distribution of domain registrations, based on 2nd level label lengths. Dennis explains how all the 2-, 3-, and 4- letter labels are reserved, registered and hoarded by speculators, and the majority of these are "taken" because they are treasured acronyms. Forbes' web host (yafla.com) is itself a concession to acronym exhaustion and an emerging enthusiasm for longer acronyms: yafla = yet another five letter acronym :-).

The article is informative as well and provides statistics and graphs that offer some insights into how society has evolved as it searches for domain names. See In Search of Domain Names.

Archived at http://www.securityskeptic.com/arc20060301.htm#BlogID515 by Dave Piscitello  

Wed, 22 Mar 2006 00:00:00 00, 514
Order now!

I'm excited to announce that Understanding Voice over IP Security, by Alan Johnston and David Piscitello, will be available April 2006. Order now from Amazon.com and Artech House.

Table of Contents:


Introduction to Cryptography.

VoIP Systems.

Internet Threats and Attacks.

Internet Security Architectures.

Security Protocols.

General Client and Server Security Principles.


Signaling Security.

Media Security.


PSTN Gateway.

Spam and Spit.


Understanding Voice over IP Security, available April 2006

Archived at http://www.securityskeptic.com/arc20060301.htm#BlogID514 by Dave Piscitello  

Thu, 16 Mar 2006 00:00:00 00, 512
Windows Firewall Log Viewers and Analyzers

Windows Firewall may not be the most fully-featured personal firewall, but this alone shouldn't prevent you from disregarding it entirely. Clearly, using Windows Firewall is better than using no firewall at all. But in a previous article, I described how many organizations disable personal firewalls on PCs connected to internal (trusted) LANs, and that this practice leaves computers vulnerable to malicious code that distributes itself using anonymous file shares and common LAN applications. So I'll reiterate my earlier claim that using Windows Firewalls on non-mobile systems in trusted LAN environments is an inexpensive way to improve your organization's security baseline.

Windows Firewall does support logging, and I'll of course argue that every PC with WF enabled should turn on logging. I've recently come across two freeware utilities that complement WF nicely. XP Firewall Log Reader is a no-frills log viewer. This very basic utility opens WF's pfirewall.log and displays it in a non-resizeable window. This utility might prove useful to help desk staff in large and small businesses. Imagine a user places a trouble call, claiming he can't access an application. Help desk staff asks the user, "launch XP Firewall Log Reader, scroll down to the date and time he experienced problems, look for the word DROP, and tell me what number is in the column called DST-Port..." You just may save the time you'd spend visiting the user's office, right?

FireLogXP1.3 is a more ambitious utility: FireLogXP actually analyzes your WF Log. The top pane of FireLogXP's window summarizes connections between source and destination IP pairs. Highlight a summary line in the top pane and the bottom pane summarizes the connections between the pair you highlighted according to port accessed. This feature that makes this an interesting utility is that each summary of ports accessed identifies both the standard port application (http/80, dns/53, ...) *and* a list of possible malware that are known to use the port. So while the conventional use of UDP Port 53 is DNS, FireLogXP will also inform you that ADM worm, li0n, MscanWorm and MuSka52 malware have been known to use this port as well. If you right click on a selected line in the lower pane, FireLogXP pops up a "What is port X"? prompt. Left-click on the prompt and the program opens a browser page to the Internet Storm Center (e.g., http://isc.incidents.org/port_details.php?port=53), where you can learn a great deal more about the ways this port is used and abused. FireLogXP is more of a power tool than XP Firewall Log Reader, and IT staff ought to consider including it in their own security toolkit. But home power users who are keen on learning Internet Security will find this utility to be an enormously helpful application as well.

Archived at http://www.securityskeptic.com/arc20060301.htm#BlogID512 by Dave Piscitello  

Tue, 14 Mar 2006 00:00:00 00, 513
Block ad-serving cookies in both IE and Firefox

As I investigated various ways to block ad-serving cookies and spy/adware, I discovered two Firefox extensions that do an incredible job of blocking annoying and potentially harmful cookies. Like Eric Howes' IE-SPYAD for Internet Explorer, the Firefox extensions, when used in tandem, not only block cookie installs, but ad delivery as well. I wrote WatchGuard Wire item describing these safe surfing features. Visit Block ad-serving cookies in both IE and Firefox.

Archived at http://www.securityskeptic.com/arc20060301.htm#BlogID513 by Dave Piscitello  

Fri, 10 Mar 2006 00:00:00 00, 511
Firewall Policy life cycle management

A recent posting to a firewall mail list asked the question, "How do large organizations manage firewall rule sets? Specifically, how do they determine when to remove a policy that is no longer required?" This firewall administrator is always being asked to open access for new applications, but is rarely informed when an application is deprecated and the associated access policy can be removed. Sound familiar?

I mulled this over for a while. Organizations that implement security according to a regularly maintained security policy should never encounter this situation. Requests to add access are reviewed and if approved, recorded in the policy. For example, the security policy team meets in June 1994, reviews a request, and agrees that access to gopher service is permitted. The team notifies the firewall admin to open port 70/TCP. Time marches on. Everyone who used gopher has retired or expired.

In March 2006, the twenty-somethings who now comprise the security policy team review the policy. Everyone in the meeting says, "what the heck is gopher?" They agree to remove gopher access, revise and post the policy, and notify the firewall admin to remove the firewall rule and block access to gopher servers. Who wants a double shot mocha no fat?

OK, it's an interesting bed time story, but in the all too common world of policy-challenged organizations, the story is quite different. And so a more practical question to ask might be, "How do security admins of large organizations know when to remove an access rule from a firewall config?"

When firewall configuration is not policy-driven, admins can rely on what they see in logs. This gives me the opportunity to campaign once more for logging allowed traffic. If you know what traffic is allowed and you log all allowed traffic, then you can monitor what is actually being used and to what extent. Review your logs. When was the last time you saw outbound traffic on port 70/TCP on your network? December 2003? Now you can follow this simple rule of thumb: if you see diminishing to little traffic for a given application, ask management (and employees) whether a business need still exists. If no one speaks up to justify continued access, close the port and as my colleague and friend Fred Avolio says, "wait for the phone to ring, and ask for a business case".

Yeah, I know. This is too easy.

Archived at http://www.securityskeptic.com/arc20060301.htm#BlogID511 by Dave Piscitello  

Wed, 08 Mar 2006 00:00:00 00, 510
Blocking cookies at an http proxy

I just completed an article for Watchguard about using an http proxy to strip ad-serving cookies. Legally, not every ad-serving or behavior tracking cookie is spyware. Why not? Spyware installs without your notice and consent. Every browser provides ways to opt-out or refuse cookies, so cookies do not qualify as spyware *unless* they collect personally idenfitying information. Of course, now that legislation makes a clear distinction, the giant ad-serving companies have begun offering opt-out mechanisms and those that don't collect PII go to court to force antispyware software vendors to remove them from adware blacklists.

The legislation is flawed. Cookies collect lots of information that cannot be categorized as PII but are potentially harmful to you and your business, and potentially useful to an attacker (add'l reading).

For the Watchguard column, I did a small study of 3rd party cookies that pass the "it's not spyware" criteria. From the cookie caches of a half-dozen PCs in my office, I identified a sampling of two dozen ad-serving cookies. I reviewed the privacy policies of the ad-serving companies and concluded that 20 of the 24 collected information I was not willing to share. In some cases, the cookie collected topology information; in others, the cookie collected exceedingly detailed accounts of web behavior. Call me paranoid. I don't want undisclosed third parties gathering this sort of information, even in an aggregated and anonymous manner. Behavior-tracking is just too Orwellian for me.

It's too hard to maintain "ad-serving cookies that are not spyware but annoying nonetheless" block lists at the browser level. Instead, I added proxy stripping actions on my FireboxX and blacklisted the 20 companies that may not be spyware to my Republican Congress but they are to me.

It's absolutely amazing how many cookies I'm stripping; in fact, if I watch my realtime event monitor, it's actually quite funny (or pathetic). And for what it's worth, stripping third party cookies doesn't appear to interfere with anyone's "web experience":-)

The cookie problem won't disappear. Cookies have been overused and overloaded, and first party or "site" cookies are unfortunately an integral part of many web user's experiences. If everyone blocks third party cookies, the behavior-tracking companies will obfuscate their cookies and make them indistinguishable from site cookies, or they'll sell services and software.

Archived at http://www.securityskeptic.com/arc20060301.htm#BlogID510 by Dave Piscitello  

Fri, 03 Mar 2006 00:00:00 00, 509
Service Review: Stamps.com

Stamps.com is one of several Internet postage services I have been tempted to try. When I finally did give in to temptation, I decided to hedge my investment with a 30-day trial subscription. Stamps.com's Windows application installs cleanly, works fine, and is reasonably intuitive. Stamps.com sends you a starter kit so you can print stickie-backed stamps and shipping labels. Stamps and labels come in sheets. You provide the application with a serial number imprinted on a sheet and it remembers which stamp/labels have been printed from the sheet to simplify printing. You can also print a stamp on an envelope along with return and recipient addresses. You can add your company logo as well.

I am pleased with what Stamps.com provides. I think they could provide much much more:

  • Currently, there's no way to print a stamp on a pre-addressed envelope or an envelope with a transparent pane. I asked Customer Support about this and they simply echoed my complaint: "Thank you for your inquiry. Currently, there's no way to print a stamp on a pre-addressed envelopes. You must use the print stamps on pre-formatted sheets option". This is annoying for three reasons: you must purchase the sheets, you have to enter the recipient address, and you have to purchase envelopes. If Stamps.com chose to do so, they could easily modify the user interface to include a check box to "print stamp on envelope without return/recipient address". This would of course alter the company's revenue model which must be partly based on selling pre-formatted sheets of blank stamps. But riddle me this: If I have to buy sheets of blank stamps AND pay a monthly fee, why am I not simply purchasing rolls of stamps from USPS.com?

  • In this age of micropayments, why can't Stamps.com offer a graduated monthly subscription service? I've always hesitated using metered postage service because I don't mail that many packages and envelopes. In fact, the $15/month subscription fee just about doubles my postage costs. This isn't all that much to pay for the convenience factor, and I may be able to justify doubling the cost of postage for convenience's sake, but so many other potential customers won't. How hard would it be for Stamps.com to offer a casual/consumer rate, small business rate, and enterprise rate? Look at my numbers. As a casual snail mail sender, I must accept a 100% markup, whereas a small business operator or frequent eBay seller is probably absorbing between 5%-20%. If Stamps.com were to create a graduated monthly fee based on the actual monthly postage fees, I imagine they'd lure enough consumers to their service to more than justify the additional accounting and invoicing complexities.

Stamps.com should take lessons from financial institutions. Banks know how to grow mass markets for new services. Offer it free at first, wait until the service is deemed essential to the majority of the market, then impose a small surcharge. Increase the surcharge over time so that it remains tolerable to the majority of customers.

Will I keep Stamps.com? I depends on whether my experiments to print stamps without purchasing pre-formatted labels are successful:-O

Archived at http://www.securityskeptic.com/arc20060301.htm#BlogID509 by Dave Piscitello  

Thu, 02 Mar 2006 00:00:00 00, 508
Status of "Understanding Voice over IP Security"

Artech House is accepting orders for the VoIP security book I co-authored with Alan Johnston. You can read the preview material and order an advanced copy at a discount here..

The ISBN is 1-59693-050-0.


Archived at http://www.securityskeptic.com/arc20060301.htm#BlogID508 by Dave Piscitello