Wednesday, November 24, 2010

Thanksgiving and Naikan

Thanksgiving is my favorite holiday for two completely different reasons. Firstly, I'm a big believer in expressing gratitude at every turn of my life. Secondly, the food in our family is amazing! :)

The thing that strikes me most about Thanksgiving is how it reminds me of the importance of living a grateful life. Perhaps you've heard me speak about my friend who works with convicts inside prison walls to help them prepare for life after prison. He has observed that within the walls of prisons, there is an overwhelming sense of entitlement: "I am owed. Society owes me. Someone else made me do the crime. It's not my fault." When he is able to convince the convicts to sincerely express gratitude for whatever they've been given, they start to turn their lives around. During the recent snow emergency in Seattle, it would be very easy (and understandable) to get angry about the weather, the traffic snarls, and the power outages. Most of us probably did get angry! An alternative approach would have been to pause and express gratitude for the things we've been given: a beautiful city in which to live, a train to use for transit instead of a bus, a home waiting for us at the end of our extended commute, family and friends who care about us, and grocery stores stocked with food. We could be living in a war-torn country, under an oppressive military dictatorship, or under the constant threat of disease or starvation. We could be homeless. It's truly a matter of perspective and, upon reflection, we're pretty well off!

Naikan is a Japanese practice of living a life of gratitude. In Naikan, you reflect on the things you've been given by others, the things you've given to others, and the troubles or difficulties you've caused others. The idea is that, in the presence of an abiding sense of gratitude, there's no opportunity for neurotic thought processes to develop. Think back to my friend's work with prisoners and how a change in attitude results in a change in a life. To paraphrase Zig Ziglar, when your thinkin' is stinkin', you need to make a change!
I'm thankful I'm still in business. Many of my competitors have closed their doors within the past couple of years. I'm thankful that you trust me with your email address. I'm thankful for my family and friends and I'm thankful to live on a beautiful planet called Earth.

Happy Thanksgiving!

Saturday, November 20, 2010

Almost done with the Customer Service for I.T. Pros book

I've been working feverishly (okay, as feverishly as I ever work) on finishing the customer service book.  I just keep finding cool stuff to include.  One of my clients was, however, complaining about how one of the customer service for I.T. people books was like 400 pages long.  He observed that there was no way most of his staff would take the time to read it.  Our customer service book is currently at 126 pages, so that seems digestible!  At any rate, we (meaning Paul, my co-author and me) should be done with it in the next few days, then off to the publisher!

Monday, November 15, 2010

Use a hosted email solution or bring it in-house?

I just responded to a post on concerning hosted email solutions vs. in-house solutions.  I feel strongly that the less I have to technically manage, the better job I'll do of providing services to my users.  It's important to distinguish between technical management and executive management.  Executive management is the process of providing oversight of technical services such as email from a business standpoint and technical management is about the process of configuration, patch management, and so on.  The technical management of any server well is a lot of work, but it's especially challenging to manage a mail server well. You have to consider availability, security (including spam filtering), keeping your domain off of email blacklists, mailbox management, backups, and patch management. (Did I forget anything?) You can get shared calendars, messaging, and similar services through Google Apps for Your Domain (GAFYD) or other providers. At $50 per user per year for 40 users, for example, it's much less expensive to use a hosted solution than to invest in the required equipment and devote your time to managing in-house email services.  Using a hosted service frees you from the minutiae of technical management responsibilities and allows you to focus on managing email from an executive oversight perspective.

You must also consider security and control.  For example, if you work in health care or finance, security and privacy and/or regulatory concerns may limit your ability to use a hosted solution.  You may also want to maintain a higher level of control over a particular service than what is allowed by a hosted solution provider.  Another factor to consider in choosing a hosted provider, especially GAFYD, is the issue of data mining.  Data mining is a fact-of-life for anyone using the public Internet.  Providing usage data in aggregate is part of the price we pay for services such as GAFYD.  If you don't like the idea of being "data-mined", don't use services like GAFYD.

Of course, as your organization grows, the cost of the hosted solution will also grow.  At some point, it will probably become more cost effective for you to bring email services in-house.

Friday, November 12, 2010

Setting default environment variables for PowerShell

I'm frustrated right now.  You probably understand.  I've been a command-line junkie since the early days of DOS and I always prefer the bash shell when working with Linux.  PowerShell has been around for several years now, but I've never felt the need to embrace it, which is probably foolish and short-sighted of me, but that's just how I've felt.  I'm working on my new BIND DNS book (shameless book plug:  check out my Amazon author's page and buy lots of my books), which will, of course, include utilities such as whois, host, dig, and other tools that are traditionally the domain of Linux and Unix users.  The reality of the world today is that lots more people use the Windows operating system than Linux or Unix, so there are ports of those tools for Windows users and I need to include them in my book.  I decided, if I was going to include Windows command-line stuff, to go with PowerShell.  It is, after all, supposed to be the latest and the greatest.

I wanted to be able to unzip files at a command-prompt and use utilities like wget, dig, whois, etc.  Of course, if you're working in a command-line environment, you need a zip/unzip utility, so I chose 7-Zip.  I downloaded all of the various tools to a directory (oops, I mean folder) and proceeded to set environment variables so I could use them from any directory (oops, I mean folder) on the computer.  I did the usual stuff which you're probably familiar with:  I went to the System Properties>>Advanced System Settings and clicked the button for Environment Variables.  Then I went to the System variables section and modified the path to include the location of the various utilities, especially 7-Zip.  I rebooted my system and all of the new paths worked in PowerShell except 7-Zip.  I couldn't execute "7z e", for example, to extract the contents of a zipped file.  I rechecked everything to make sure I hadn't fat-fingered anything, and everything was fine.  Still, I kept getting the error "Bad numeric constant: 7".  Huh?  I Googled and discovered that Windows PowerShell doesn't like executables that start with a numeric character!  Huh!  What kind of BS is this???  Oh well, it is what it is and I can't change that, so I decided to create an alias so I could start "7z" with "sz" instead.  Makes sense, right?  I entered the following command in PowerShell:  set-alias sz "c:\program files\7-Zip\7z.exe" and, voila, the alias worked great.  Except for one thing; when I shutdown and restarted PowerShell, the alias went away.  Grrrrr.  Well, I'm new to PowerShell, but there had to be a way to create persistent aliases, right?  Well, yes, but it ain't very easy, thanks to Windows security settings.  You have to add the alias to your profile.  Here's how I got it to work.  First of all, I created the profile.  Here are the steps:
  1. Find out where PowerShell thinks your profile is located with the $profile command.  Mine was located at C:\Users\don\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1.  The WindowsPowerShell directory did not exist, nor did the file Microsoft.PowerShell_profile.ps1, so I had to create both of them.
  2. Use the command "notepad $profile" to open your profile for editing and enter the alias in the file:  set-alias sz "c:\program files\7-Zip\7z.exe"
  3. Save the file.
  4. You would think that would do it, but if you exit and restart PowerShell, you'll get a big fat permissions error saying bad things about scripts and configuration files (\Microsoft.PowerShell_profile.ps1 cannot be loaded because the execution of scripts is disabled on this system.).  Turns out you have to set signing permissions for the configuration file in order to make this work.
  5. Close PowerShell and re-open it as Administrator.
  6. Use the command Get-ExecutionPolicy to see the current execution policy setting.  Mine was set to restricted, which is one of the four values available:  Restricted, AllSigned, RemoteSigned, or Unrestricted
  7. I'm not going to go into the security implications of each of the settings, but you really should  read up on Set-ExecutionPolicy before messing with these settings.  You've been warned.  I then used "Set-ExecutionPolicy RemoteSigned" to modify the script/configuration security settings to allow PowerShell to read the new profile.
  8. I restarted PowerShell and now my alias worked fine.
  9. What a pain-in-the-neck.  I hope this helped you!  Let me know if I overlooked anything.
Oh, in addition to my BIND DNS book on Amazon, check out my BIND DNS workshop at

Tuesday, November 9, 2010

Understanding the Eight Basic Commands on a Cisco ASA Security Appliance

Several years ago, I published the original version of this document in a blog post and in my workshop documentation.  Last spring (2010), Cisco modified the way we configure NAT/PAT on the ASA security appliance.  We now use network object statements as part of the base configuration.  This blog post and associated docs updates the original which, starting with version 8.3(1) of the software image, is no longer valid.

These steps are based on chapter one in my book The Accidental Administrator:  Cisco ASA Security Appliance. I have also created a companion video for these steps, based on ASA software version 8.4.

There are literally thousands of commands and sub-commands available to configure a Cisco ASA security appliance. As you gain knowledge of the appliance, you will use more and more of the commands. Initially, however, there are just a few commands required to configure basic functionality on the appliance. Basic functionality is defined as allowing inside hosts to access outside hosts, but not allowing outside hosts to access the inside hosts. Additionally, management must be allowed from at least one inside host. To enable basic functionality, there are eight basic commands:
  • interface
  • nameif
  • security-level
  • ip address
  • switchport access
  • object network
  • nat
  • route


The interface command identifies either the hardware interface or the Switch Virtual Interface (VLAN interface) that will be configured. Once in interface configuration mode, you can assign physical interfaces to switchports and enable them (turn them on) or you can assign names and security levels to VLAN interfaces.


The nameif command gives the interface a name and assigns a security level. Typical names are outside, inside, or DMZ.


Security levels are numeric values, ranging from 0 to 100, used by the appliance to control traffic flow. Traffic is permitted to flow from interfaces with higher security levels to interfaces with lower security levels, but not the other way. Access-lists must be used to permit traffic to flow from lower security levels to higher security levels. The default security level for an outside interface is 0. For an inside interface, the default security level is 100.

In the following sample configuration, the interface command is first used to name the inside and outside VLAN interfaces, then the DMZ interface is named and a security level of 50 is assigned to it.

ciscoasa(config)# interface vlan1
ciscoasa(config-if)# nameif inside
INFO: Security level for "inside" set to 100 by default.
ciscoasa(config-if)# interface vlan2
ciscoasa(config-if)# nameif outside
INFO: Security level for "outside" set to 0 by default.
ciscoasa(config-if)# interface vlan3
ciscoasa(config-if)# nameif dmz
ciscoasa(config-if)# security-level 50

ip address

The ip address command assigns an IP address to a VLAN interface either statically or by making it a DHCP client. With modern versions of security appliance software, it is not necessary to explicitly configure default subnet masks. If you are using non-standard masks, you must explicitly configure the mask, otherwise, it is not necessary.

In the following sample configuration, an IP address is assigned to VLAN 1, the inside interface:
ciscoasa(config-if)# interface vlan 1
ciscoasa(config-if)# ip address

switchport access

The switchport access command on the ASA 5505 security appliance assigns a physical interface to a logical (VLAN) interface. In the next example, the interface command is used to identify physical interfaces, assign them to switchports on the appliance, and enable them (turn them on). This command is not used on the ASA 55x0 appliances.
ciscoasa(config-if)# interface ethernet 0/0
ciscoasa(config-if)# switchport access vlan 2
ciscoasa(config-if)# no shutdown
ciscoasa(config-if)# interface ethernet 0/1
ciscoasa(config-if)# switchport access vlan 1
ciscoasa(config-if)# no shutdown

object network obj_any

Introduced as part of the NAT/PAT configuration in the spring of 2010, the object network obj_any statement creates an object called “obj_any”. (You do not have to name the object “obj_any”; that is a descriptive name, but you could just as easily name it “Juan”.) The network option states that this particular object will be based on IP addresses. The subnet command states that obj_any will affect any IP address not configured on any other object.
ciscoasa(config-if)#object network obj_any


The nat statement, as shown below, tells the firewall to allow all traffic flowing from the inside to the outside interface to use whatever address is dynamically (DHCP) configured on the outside interface.
ciscoasa(config)#nat (inside,outside) dynamic interface


The route command, in its most basic form, assigns a default route for traffic, typically to an ISP’s router. It can also be used in conjunction with access-lists to send specific types of traffic to specific hosts on specific subnets.

In this sample configuration, the route command is used to configure a default route to the ISP’s router at The two zeroes before the ISP’s router address are shorthand for an IP address of and a mask of The statement outside identifies the interface through which traffic will flow to reach the default route.
ciscoasa(config-if)# route outside 0 0
The above commands create a very basic firewall, however, using a sophisticated device such as a Cisco PIX or ASA security appliance to perform such basic firewall functions is overkill.
Other commands to use include hostname to identify the firewall, telnet or SSH to allow remote administration, DHCPD commands to allow the firewall to assign IP addresses to inside hosts, and static route and access-list commands to allow internal hosts such as DMZ Web servers or DMZ mail servers to be accessible to Internet hosts. Of course, there are many more advanced commands that you will learn later in this book.

Sample Base Configuration

ciscoasa(config)# interface vlan1
ciscoasa(config-if)# nameif inside
INFO: Security level for "inside" set to 100 by default.
ciscoasa(config-if)# interface vlan2
ciscoasa(config-if)# nameif outside
INFO: Security level for "outside" set to 0 by default.
ciscoasa(config-if)# interface ethernet 0/0
ciscoasa(config-if)# switchport access vlan 2
ciscoasa(config-if)# no shutdown
ciscoasa(config-if)# interface ethernet 0/1
ciscoasa(config-if)# switchport access vlan 1
ciscoasa(config-if)# no shutdown
ciscoasa(config-if)# interface vlan 2
ciscoasa(config-if)# ip address
ciscoasa(config-if)# interface vlan 1
ciscoasa(config-if)# ip address
ciscoasa(config-if)# route outside 0 0
ciscoasa(config-if)# object network obj_any
ciscoasa(config-network-object)# subnet
ciscoasa(config)# nat (inside,outside) dynamic interface
ciscoasa(config)# exit
For a nicely formatted PDF free, downloadable version of this document, click here.

Excerpted from The Accidental Administrator: Cisco ASA Security Appliance: A Step-by-Step Configuration Guide by Don R. Crawley, available on and other channels.

Based on the two-day workshop Cisco ASA Training: Two-Day Hands-On Workshop from (