" /> UrlBlogGrey: October 2006 Archives

« September 2006 | Main | November 2006 »

October 21, 2006

Our Disaster Kits

I've posted photos on Flickr of the disaster kits that I assembled for Natalie & I. Many people would be afraid to admit to having such kits, but I think that such attitudes do nobody a service. It's important to share information about what should go into a kit.

Here's the go-bag that I keep in the trunk of my car. It's got enough water to last me at least a day, but is currently missing food items. Food is a real priority since my cognitive abilities vanish in the absence of food. I'm apt to be the "Best Equipped Idiot on Earth" if I forget to include food!

Go-Bag Component of Disaster Kit

Also, here are the supplies included in the household disaster kit. These items are stored in an 18-quart plastic bin, such as the kind you might find for $5 at home stores. It's important that the container be water-resistant, portable, and sturdy.

Household Disaster Kit (Tools & Supplies)

Disaster Preparedness in the San Francisco Bay Area

For the last couple weeks, I've been assembling supplies for our home disaster preparedness kit. I've never had such a kit before, and I now realize that I was pushing my luck by doing so. Earthquakes are the most eminent threat in the San Francisco Bay Area: they occur with little or no warning, they destroy structures and interrupt public services over a wide area, and can play havoc with the construction techniques employed in many parts of the Bay Area (liquefaction is a major risk in the Alameda area where parts of the Bay were reclaimed using fill). Other disasters can occur, of course, but few are as likely and hazardous as earthquakes.

Before purchasing items for the kit, I performed a lot of research on-line. This was a good idea since it made me aware of issues I would have otherwise ignored. I made a lot of purchases through on-line retailers like Amazon.com to keep the cost of the kit low. Here is a list of considerations that I found interesting:

  • Water service may be disrupted or unsafe, so it won't be possible to rinse off plates and eating utensils. Instead, keep some paper plates, plastic cups (red party cups!), and plastic utensils in the kit. They can be used and disposed of without using water.
  • Earthquakes can occur in any weather, so prepare for the worst weather in your area. Your home may be uninhabitable, so that could mean being kept outside in rain or extreme heat. Include rain ponchos and sunscreen in the kit to address these possibilities.
  • Because an earthquake doesn't wait for you to get home, you should include some basic supplies in your car and/or at work. This has been referred to as a "car-kit" or "go-bag", and should consist of:


    • battery-powered radio

    • flashlight

    • batteries for both

    • pocket knife

    • dust masks

    • some food & water

    • maps of the local area

    • heavy gloves

    • rescue blanket

    • rain poncho


  • Include food and a leash for your dog or cat since they'll need to get through the ordeal, too
  • Store as much cash as you might take out for a long weekend. ATMs and card readers don't function well without power, so having cash will put you at an advantage.

I've found some excellent resources on the web for assembling a disaster kit:

Also, here are some blogs addressing the need for a disaster kit:


I find it disturbing that so many government agencies - local and federal - have put so much effort into creating websites that target those with access to a computer and the Internet. I can't say I've seen any of the information available on the FEMA website elsewhere. People without access to this information in advance will be the most devastated from a disaster. I think this information should be more widely disseminated, perhaps by mail or some other widespread channel.

October 7, 2006

Running Multiple 'dnsmasq' Processes

I recently added a second Linksys WRT54G(L) to my home network with the purpose of creating an isolated wireless network using WEP encryption. I wanted to issue hosts in the secure network (lan1) Internet Protocol (IP) address in a different range than hosts in WEP network (lan2). This just helps to emphasize the isolation since the networks are actually kept separate by the hardware.

The OpenWRT firmware uses the dnsmasq program as a caching name-server and DHCP server. It's has a small memory and filesystem footprint, and contains a feature-set perfect for most residential networks. I wanted to continue using dnsmasq as DHCP server for both networks. This meant configuring dnsmasq to issue IPs on two networks, or run two separate dnsmasq processes configured to issue IPs on a specific network.

First, I consulted the web-site for dnsmasq. The Man page indicated some options of interest:

-a, --listen-address=

    "Listen on the given IP address(es)."
-z
    "Setting this option also enables multiple instances of dnsmasq which provide DHCP service to run in the same machine."
-l, --dhcp-leasefile=
    "Use the specified file to store DHCP lease information."
I decided to go the route of running two separate dnsmasq processes. Here are the steps I took:
  • Copy the initialization script (S50dnsmasq) for dnsmasq so that two processes at boot. I created two scripts (S50dnsmasq-lan1, S50dnsmasq-lan2).

    root@OpenWrt:/etc/init.d# ls   
    S05nvram         S50dnsmasq-lan1  S50inadyn        rcS
    S10boot          S50dnsmasq-lan2  S50telnet
    S40network       S50dropbear      S60cron
    S45firewall      S50httpd         S99done
  • I then modified the scripts to cause each dnsmasq process to listen on a different network interface (customize "iface" variable). I also added options to the "args" variable to allow multiple dnsmasq processes and listen on a specific interface.

    root@OpenWrt:/etc/init.d# more S50dnsmasq-lan1
    #!/bin/sh
    
    # The following is to automatically configure the DHCP settings
    # based on nvram settings. Feel free to replace all this crap
    # with a simple "dnsmasq" and manage everything via the
    # /etc/dnsmasq.conf config file
    
    # DHCP interface (lan, wan, wifi -- any ifup *)
    iface=lan1
    ifname=$(nvram get ${iface}_ifname)
    
    udhcpc -n -q -R -s /bin/true -i $ifname >&- || {
      # no existing DHCP server?
    
      # calculate settings
      ipaddr=$(nvram get ${iface}_ipaddr)
      netmask=$(nvram get ${iface}_netmask)
      start=$(nvram get dhcp_start)
      start=$((network+${start:-100}))
      num=$(nvram get dhcp_num)
      num=$((start+${num:-150}))
      eval $(ipcalc $ipaddr $netmask $start $num)
      leases=/tmp/leases-${iface}
      
      # and pass the args via the commandline
      # (because trying to edit the config from here is crazy)
      args="--listen-address=$ipaddr --bind-interfaces --dhcp-leasefile=$leases -F $START,$END,$NETMASK,12h"
    }
    
    # ignore requests from wan interface
    wanproto=$(nvram get wan_proto)
    [ -z "$wanproto" -o "$wanproto" = "none" ] || args="${args} -I $(nvram get wan_ifname)"
  • Make sure that the scripts are executable (chmod +x S50dnsmasq-lan1).
  • Restart the router and check the processes:

    root@OpenWrt:/etc/init.d# ps -eax | grep dnsmasq
      444 nobody      416 S   dnsmasq --listen-address=192.168.1.1 --bind-interface
      460 nobody      396 S   dnsmasq --listen-address=192.168.2.1 --bind-interface

That's it! You should now have two DHCP & DNS servers running on separate network interfaces.

October 4, 2006

Chaining Wireless Access Points for Compartmentalized Security

I hope to be getting a Nintendo DS handheld soon, which has got me totally excited! The DS is equipped with an 802.11B (11 Mbps) network adapter, and is capable of using WEP encryption when connecting to an access point. It's great that the DS can use wifi, but it sucks that it uses such outdated standards. Our home network currently uses 802.11G (54 Mbps) and the more-robust WPA encryption standard.

WPA and WEP are mutually exclusive, as they ought to be. WEP has been proven breakable through methods like packet-injection. A network is only as strong as its weakest link, which in this case is WEP. So, placing the WEP and WPA clients on separate networks is required in order to preserve the security of WPA clients. I'd rather not compromise the security of the other devices (laptops, printer server, Linux box) for the sake of a Nintendo handheld.

So, I need to create two separate wireless networks: one using WEP, and the other using WPA. This requires me to purchase an additional wireless access point. I've been using a Linksys WRT54GS for the last 2.5 years, and would like to continue using it if possible. I run the Open Source OpenWRT firmware on my Linksys WRT54GS and have been very pleased with it's configurability, performance, and security. The current WRT54GS models do not support using firmware like OpenWRT, so I'll need to purchase a WRT54GL ("L" is for Linux).

The network currently looks like this:


|- WiFi clients (WPA)
Internet (WAN) --- (WAN Port) Linksys WRT54GS ---|
|- Ethernet switch

After adding the WRT54GL, the network will look like:

                                                 |- 802.11b (WEP)
Internet (WAN) --- (WAN Port) Linksys WRT54GL ---|                                                   |- 802.11G (WPA)  
                                                 |- Ethernet switch -- (WAN Port) Linksys WRT54GS ---|
                                                                                                     |- (Ethernet switch)

I must either disable the bridge between the 802.11B Virtual LAN (VLAN) and the Ethernet switch on WRT54GL, or I must keep the Network Address Translation (NAT) firewall active on the WRT54GS. This is to ensure that clients on the 802.11B network cannot access any hosts on the secure 802.11G network. I think that disabling the bridge will yield the best performance since it eliminates the need to double-NAT Internet traffic heading to the secure 802.11G network, yet keep the secure and non-secure networks separate.

I'll try to post a follow-up with the configuration changes once I put the network into action.