Month: July 2008

  • Brilliant article with x-Hannaford CIO

    StorefrontBacktalk has a short but brilliant article with the former CIO, Bill Homa, of Hannaford grocery chain who suffered a major breach of credit card data:

    http://storefrontbacktalk.com/story/071108homa

    There are three particular points that stand out:

    1. That Microsoft is still so hole ridden as to put your company at additional risk.
    2. That PCI is still not sufficiently strong.
    3. That a security posture based only on perimeter defense is ultimately fallacious.

    In my experience PCI (also called CISP or PCI DSS) while certainly better than nothing, is still well below what is necessary to protect customer confidential data. Furthermore certain components of the credit card processing stream require less than ideal levels of encryption (I’m being generous here), providing simplified points of collection and attack for hackers (to note, there are plans to improve this).

    In regards to depending on “perimeter defense”, this quote particularly stands out:

    Most retailers have the philosophy of keeping people out of their network. It’s impossible to keep people out of your network. There are bad people out there. How do I limit the damage they can do? If you don’t do that, they’ll have free reign to do whatever they want.

    However I hardly think this mentality is limited to retailers. In my discussions with numerous peers in the computing industry, many shops, large and small, retail or non-retail are inflicted with this mentality. In fact I would consider it pervasive – “keep the intruders out and you’ll be ok.”

    But the honest truth is you can never keep them out and like a game of chess, everyday some new hole is found to subvert your external protections. Nor for that matter should you really trust your own employees, which are ultimately one of the largest sources of data compromise, and they are on the inside.

    The answer is “defense in depth“, with layers of security, some strong, some weaker, some on perimeter, some on the host, some in the software tools themselves, but the sum total providing sufficient security for the value of the asset(s) being protected (based on “risk analysis“).

    Until corporations start thinking this way, we can expect to see breaches like Hannaford’s continue for some time.


  • How to disable “dumprep.exe”

    If you’ve ever had a program spontaneously self destruct in Windows XP and/or you did a forced kill from the task manager for a “Not responding” application, you may have found it takes forever for things to come back to normal and meanwhile your drive is being banged on like crazy. Worse things usually drag to a halt.

    The culprit? “dumprep.exe”, a Windows built in that prepares a log file to send to Microsoft to report the “issue”, even if you don’t want to report the issue (like they’re going to read it anyway?).

    Fortunately it’s easily disabled:

    • Go to “Control Panel” (classic mode).
    • Double click on “System”, which will bring up the “System Properties” panel.
    • Select the “Advanced” tab.
    • Click the “Error Reporting” button near the bottom.
    • Choose the radio “Disable error reporting”.
    • Click “OK” to all the windows until you’re out.

    Done – “dumprep.exe” is disabled. If you ever have an actual issue to report to Microsoft, you can reverse these steps to turn it on again. The default is kind of dumb really as there’s no way Microsoft could ever keep up with all the output from their (bug laden) OS.


  • WPA versus WPA2?

    So what’s the difference?

    Not much or a lot depending on your opinion. WPA uses TKIP for key management, whereas WPA2 uses AES-CCMP. Usually depending on how the AP has been set up, you can use either (TKIP or AES-CCMP) interchangeably, thus using WPA or WPA2 as needed. Many older devices like those running Windows Mobile 5, only support WPA with TKIP, while WPA2 is now required for Wi-Fi Alliance‘s “WiFi CERTIFIED” moniker.

    This is a pretty rough overview, however in the end the general consensus is WPA2 is more secure due in part to it’s use of the government/industry preferred AES protocol for key protection. However WPA is probably sufficient for the vast majority of uses and is infinitely better than using WEP protocol. WEP really is only useful for keeping your average neighbor off your network – any mildly serious attacker will be able to compromise a WEP based wireless network.

    As long as I’m on the subject, hiding your SSID is also basically a useless joke as there are so many tools to sniff them even when not set to “broadcast”. Either use WPA(2) or further encapsulate your traffic over a VPN connection. Still, in general as an extra layer of protection, you ought to disable “broadcast SSID“, though because of the way the protocol works the benefit is honestly nearly nil. Still, “layered security” is the way to go.


  • WPA resources

    When researching using WPA on Ciscos I ran into a lot of useful URLs as resources. If you’re in the same bind, you may find them helpful too:

    Not a pretty list, but still good to put somewhere!


  • What is 802.1x?

    If you’re investigating things like enterprise WPA and/or NAC based network control you’ll probably run into the fact that it uses 802.1x protocol. So what is 802.1x?

    Basically the long and short of it is IEEE 802.1x is just a protocol to pass EAP over wired/wireless LANs. EAP on the other hand is just a protocol to take the AP/RAS/switch/router out of the stream of authentication. It is a way of tunneling the authentication request to a Radius server and let the two figure out the authentication without the AP/RAS/switch/router having to handle it.

    A good primer on the subject is here:

    http://www.networkworld.com/research/2002/0506whatisit.html

    Incidentally the user unfriendly term “supplicant” will often come up. Much as it sounds like something fancy, it isn’t. In most regards it just means the client you’re trying to connect to the network, however more officially it’s the process(es) on the client taking care of the 802.1x authentication. The client runs the supplicant to authenticate, to quote:

    The wireless node that requests authentication is often called Supplicant, although it is more correct to say that the wireless node contains a Supplicant. The Supplicant is responsible for responding to Authenticator data that will establish its credentials. The same goes for the access point; the Authenticator is not the access point. Rather, the access point contains an Authenticator. The Authenticator does not even need to be in the access point; it can be an external component.

    So ultimately the “supplicant” is really a program running on the client. Also see:

    http://tldp.org/HOWTO/html_single/8021X-HOWTO

    which also is a useful document.

    As a final note, often the EAP passed in the 802.1x conversation is encapsulated in what’s called “PEAP” (yes, all of the acronyms are a pain!). Essentially PEAP is a public key based method of encrypting the EAP payload via SSL/TLS, thus protecting the authentication from prying eyes.


  • If using WPA-PSK, use a long key!

    If you must use WPA-PSK (meaning WPA with a pre-shared key, rather than WPA using 802.1x authentication via Radius), make sure your key is sufficiently long. Ideally 20 characters or more.

    To quote:

    Robert Moskowitz’s article, “Weakness in Passphrase Choice in WPA Interface,” describes a theoretical attack on WPA passwords. The tools WPA-psk-bf, CoWPAtty and WEP Crack are implementations of this attack and have demonstrated the ability to break WPA-PSK keys that are 20 characters or fewer. The Aircrack tool suite operates in an active or passive mode to gather the data required to launch these attacks. In passive mode, the Aircrack tools capture the four-packet authentication handshake between an AP and client. The handshake is then processed through a WPA breaking tool for an offline brute-force attack. If the attacker has not captured the handshake, the Aircrack tools active mode will force a disassociation and reassociation.

    For more see this article:

    http://www.chips.navy.mil/archives/05_jul/web%20pages/Wireless_networks.htm

    which gives a fairly comprehensive overview of the challenges here.


  • Disabling Firefox Resume From Crash

    Though to many it’s handy, personally I find Firefox‘s “Resume from Crash” function, well, annoying.  This function makes it so that if Firefox is killed prematurely that the next time you start it you get an (annoying) popup that asks you if you want to restore the previous state/page(s) that Firefox was viewing.

    I can understand the advantage, particularly if Firefox is crashing a lot, but for me it’s stable and 99% of the time when it’s been killed prematurely it’s because I wanted/expected it to. Even when it isn’t expected, 99% of those times I don’t really care that I lost what I was viewing. So, for 1/100th of a 1/100th of a chance of being useful, it isn’t worth it. Particularly since any time you reboot with Firefox up, it’s going to pop this up the next time you run it.

    Fortunately it’s easy to disable. Simply:

    • Bring up Firefox.
    • Enter “about:config” as a destination URL and go to it.
    • If it warns about the end of the world coming if you touch the configs, say “Ok” and move on.
    • Search for the key “browser.sessionstore.resume_from_crash“. By default this will be set to “true”.
    • Double click on this line. This should switch it from “true” to “false” and should also turn the line to bold.

    Done. You probably want to close the browser or browse to another URL to prevent accidentally messing with anymore items in “about:config”.

    More on “browser.sessionstore.resume_from_crash“, can be found here:

    http://kb.mozillazine.org/Browser.sessionstore.resume_from_crash

    mozillaZine probably being the definitive source of Mozilla project documentation.


  • ICANN to end (finally) domain tasting/kiting

    Domain “tasting” and “kiting“, which are where companies (often registrars) use a loophole in the domain purchase cancellation policy to hold domains without paying for them, are finally heading toward an end. Using “tasting” and “kiting” techniques a huge number of domains that otherwise would be available are held by corporations who essentially “squat” on the domains and collect click through advertising revenue.  The technique is ultimately highly profitable and easily pays for the the difficulties of managing huge swaths of essentially stolen domains.

    Unfortunately those huge swaths of stolen domains are subsiquently not available for general registration for legitimate users. Furthermore since these false registrants currently hold the domain, they can essentially offer them for ransom, even though they don’t actually own them.

    ICANN is now adding fees, though relatively low, that will make it cost prohibitive to kite the domains – no longer can the specious registrants get a full refund. The net effect should be to put an end to the tasting/kiting schemes.

    For those of us who need domains for legitimate uses, corporate or otherwise, this is great news.

    More can be found here.


  • My LinkedIn profile

    Of all the networking sites, LinkedIn appears to be about the most useful. Here’s the link to my personal profile:

    http://www.linkedin.com/in/mattfahrner

    Not that there is that much there to see about me.


  • Forget the stores…

    If you’re looking for a new laptop, clearly the place to go is the airport!

    Over 637,000 served!


  • Custom Google RedHat Kickstart List search engine

    Michael DeHaan at RedHat has created a custom Google “search engine” to search the RedHat Kickstart List archives (the RedHat mailing list “kickstart-list@redhat.com“). It looks pretty handy to not have to use other perhaps more painful tools (or get too much noise):

    http://www.google.com/coop/cse?cx=016811804524159694721%3A1h7btspnxtu

    This whole idea of custom Google Search Engines (which appears to be in “beta” right now) is pretty cool. More on that can be found here:

    http://www.google.com/coop/cse

    Definitely will have to try to create a few of my own…