Capturing Packets on a Linux Server

Use the command:

tcpdump | grep isakmp

This displays all packets passing through the tcp/ip stack on the linux server, pipes the output to the “grep” command, and ends up only displaying packets which are related to “isakmp”, the key exchange when attempting to establish an IPSEC PSK VPN connection.  Use other strings after ‘grep’ to find other types of packets.  Or, leave off the pipe and grep if you want to drink from a firehose. 🙂

Posted via email from Aaron Johnstone

Reverse PTR Troubleshooting

If you administer a mail server, do you know if your reverse PTR (‘pointer’, aka Reverse DNS) record is set up correctly?  If you don’t know, then probably not.  It’s not one of those things that happens ‘automagically’ when you run through the Exchange 2000/2003/2007, Sendmail or <insert name of any other mail-handling software> installation process.

One way you can tell if your reverse PTR is NOT set up correctly is if you regularly have delayed our bounced email when sending messages to,, or  Those are some of the higher profile domains which do reverse lookups on connecting mail servers.  And they are not very forgiving.  If your PTR record is not set up correctly, they and others will delay or reject messages from your mail server IP address.

So, let me give a quick overview of how the reverse lookup process works in the context of sending an email, and what you can do to make sure your PTR exists and is correct.

When you send an email:

  1. Your mail client submits a message to the server; if it is for a non-local address, your server puts it in the outbound SMTP queue.  Let’s say your email address, the source, is it’s going to   For the purpose of this post, I’ll assume you are not using a smarthost.
  2. Your server performs a DNS query to find the MX records for  It gets a response like ‘’
  3. Your server resolves the MX record to its IP address, which we will say is
  4. The SMTP service on your server then makes a connection to on TCP port 25.  For our example, the WAN IP address of your mail server will be
  5. SMTP then ‘introduces itself’ (using EHLO or HELO) and provides the receiving server with its name.  THIS is something that was probably configured during the installation of your mail server, and is typically or something similar.  So, at this point, the receiving mail server,, sees an incoming SMTP connection from a server at claiming to be  How does the server at know that the sending mail server is really who it says it is?  That is where the reverse lookup comes into play.
  6. The receiving server at takes the connecting IP address,, and does a reverse lookup on it.  A reverse lookup is a DNS query that is looking for a specific type of record, called a PTR.  It is called a reverse PTR because, during the DNS query process, an IP address is resolved to a name.
  7. The reverse DNS lookup on results in a response that is (hopefully) “”.  Notice that the response matches what the sending server said that it was in the introduction in step 5.  This is ideal.
  8. Next, the destination server takes that response and does a regular forward lookup on it.  So it just finds the ‘A’ record for  That query should return an IP address that matches the source IP, in our case
  9. At this point, the reverse lookup process is complete.  The receiving mail server is satisfied that the sending server is who it says it is and allows the connection to proceed.  The destination server may actually allow the sending server to specify the source and destination email addresses before performing the reverse lookup; this depends on how the server was set up by the administrator.

Now, how can you make sure reverse lookups done on your mail server IP address go as smoothly as outlined above?

Gather the following information:

  • Find out how your mail server is introducing itself when it is connecting to other mail servers.  This is a setting in the SMTP server properties (‘Send Connector’ in Exchange 2007) and is likely going to be ‘’ or something like that.  Again, it was probably set when Exchange (or other mail-handling software) was installed.  More technically, this is the name being given along with the EHLO or HELO command when your server connects to another mail server.
  • Look up the current IP address associated with the name you found in the item above.  If you looked on your Exchange server send connector and found that it was set to use, just ping that address and see what IP address you get.  Depending on how your internal DNS is set up on your network, you may get an internal address when doing this.  You need to know the external IP address that is given in response to a query for the name, so you may have to do this step from a computer outside your network.
  • Find out the WAN IP address that your mail server is using to send email.  One fairly reliable way to do this is just to get on your mail server and go to  Another way would be to look at the NAT rules on your firewall to see what address traffic from your mail server is being translated to on the outside.
  • Look up the current reverse PTR record for your mail server IP address.  A couple of websites that I use for that are MXtoolbox and ZoneEdit.  Often, the result you get here will be the default for your ISP, and may look like this:  That is bad.

Armed with this information, you can now determine whether you are in good shape, or if you need to take action.

Verify everything is Ok or fix the problem:

  1. Does the WAN IP of your mail server already have a valid reverse PTR record that matches your domain?  Or, does it look like my example,  Typically, the most difficult thing to get changed is the reverse PTR record.  These are usually controlled and created/changed by your ISP (Time Warner Cable, AT&T, Comcast, etc.).  There are different ways to request that a reverse PTR be set or changed depending on the provider.  It can be as simple as sending an email to (for Time Warner), to having to sacrifice your first-born child (for AT&T).  Just kidding, although for some reason, AT&T has made it exceptionally difficult in the past to get a reverse PTR set up.  I’ve had to go so far as to have AT&T host the DNS records for my domain in order to have them host a simple reverse PTR record for me.  Bottom line, go to your provider and ask for the process to create or change a reverse PTR record, and go from there.  All administrative overhead aside, the technical information they will need to set it up will be the WAN IP address of your mail server and what you want the record response to be.  In our example case, we would have provided them with as the WAN IP and told them that we wanted the reverse PTR for that IP to be “” (without the quotes).
  2. When you ping your EHLO address,, does the IP that is resolved match the WAN IP address of your mail server?  If not, you can fix this in a couple of ways.  Either change the ‘A’ record for to be the IP address of your mail server, or change the WAN IP address of your mail server.  Obviously, you should be careful when changing DNS records or IP addresses.  Make sure you get someone else in your IT group involved for a sanity check so you can make sure you are not going to be causing some other problem trying to fix this one!
  3. Is your SMTP server EHLO address set to a valid external DNS name?  In our example, I used  However, I have seen mail servers configured to use ‘sbserver.domainname.local’, which is not a valid DNS name on the Internet.  In this case, you will have to set your EHLO address to something similar to the example; something that likely matches your domain name.

That’s it!  If you went through all this and your reverse PTR was already in good shape, great!  If not, then I hope that this helped you to find your way.  It was painful for me when I learned this, because I did it the hard way.  Thanks for reading.

Posted via email from Aaron Johnstone

How to Recover Your Firefox Master Password

From Lifehacker:

How to Recover Your Firefox Master Password

If you’re using Firefox’s built-in password management, you should also be using its master password feature to protect your saved passwords from prying eyes. But what happens if you lose your master password?

Since the master password prevents anyone from accessing your saved passwords, you’re out of luck if you lose your master password—that is, you can’t access any of your saved credentials without it.

That’s where the free, open source tool FireMaster comes in. FireMaster is a command line tool designed specifically to recover your master password from Firefox. Here’s how to use it:

  1. Download FireMaster and extract it to a folder on your desktop.
  2. Open a command prompt. (Shortcut: Hit Win+R, type cmd, then hit Enter.)
  3. At the command prompt, change the FireMaster folder to your active directory. The quickest way to do this is to type cd , then drag and drop the FireMaster folder from your Desktop onto the command prompt—which will automatically fill in the path to that folder. Then just hit Enter.
  4. Construct your FireMaster crack command. FireMaster supports a lot of different options, but you can speed up the process if you can narrow down a few points to customize your password cracking. For example, if you know you’ve only used alphabet characters (a through z), adding the following to your command can speed up a brute force attack significantly: -c "abcdefghijklmnopqrstuvwxyz" For the purpose of testing and providing an example, I wanted to see how long it would take for FireMaster to crack a password containing only letters (a through z) that I knew was exactly six characters long. The resulting command looks like this:

FireMaster.exe -b -q -l 6 -c "abcdefghijklmnopqrstuvwxyz" -p "??????" %appdata%\Mozilla\Firefox\Profiles\1sq2zzh2.default

As you can see, I’m telling FireMaster to try a brute force crack on a 6-character master password using only the letters a through z. (You should read through the usage information to get a better idea of what options you’ve got for customizing the process to what you know about your password to speed things up.)

In the last part of the command, I’m pointing FireMaster to my Firefox profile folder, where the key3.db file exists (this is the file that contains the encrypted password information). The last folder in that path will differ for you, but everything up to that folder (i.e., %appdata%\Mozilla\Firefox\Profiles\ will get you most of the way there. (If you only have one Firefox profile, you should just see one folder inside Profiles; use that folder.)

  1. After you’ve constructed your command, just hit Enter to get cracking. Using the command constructed above, FireMaster took roughly 23 minutes to crack my Firefox password. If I didn’t know how long the password was, it would take significantly longer (you can offer a minimum and maximum password size to help narrow things down a little further). That said, it clearly wasn’t all that difficult to crack my password given all I knew about it. It gets much harder the more secure your password is (think unusual characters and long passwords).

Posted via email from Aaron Johnstone

Virtual Machine Performance Tweaks

Came across this in a TechTarget article:

Easy Mistake 1: Virtual machine screensavers
Screensavers are an absolute requirement for desktops in the hallways of our brick-and-mortar offices. They ensure that a user who walks away from his computer returns to one that has been secured against prying eyes. Screensavers can also provide protection in data centers. If screensavers on servers activate and lock the console after a few minutes of inactivity, they can protect that environment from an intruder who gains physical access.

But screensavers are a quiet consumer of processor resources. No matter how insignificant that screensaver seems, the processor power required to draw the pipes crawling across the screen or to scroll your favorite company slogan consume a percentage points of overall processor power. While that might not seem like much, consolidated virtual environments might have 10 or 15 virtual machines (VMs) running on a single virtual host. These percentage points add up when they are multiplied by the number of VMs. Even worse, if your environment uses hosted desktops through a virtual desktop implementation, this practice likely costs even more.

So turn them off. Remember that many environments enforce screensavers through group policies, which may mean an exclusion from existing group and corporate security policies.

Easy Mistake 2: Managing from the console
This second mistake is one of my favorites, because it is common among IT administrators everywhere. Do you manage your infrastructure components by remoting and logging into their individual servers? Do you run the Exchange Management Console from your Exchange server? Do you check domain name server (DNS) settings from the server’s console? Do you manage Active Directory by remoting your domain controllers?

If you are, stop.

As with screensavers, this practice is a big no-no in virtualized environments because of the level of resources required to create and maintain an instance of the Explorer shell. Just logging into a virtual machine is hard on that VM’s processor utilization. The process of creating a shell for the console can spike processor utilization during the login and logout process. Actually using any of the consoles on that server further consumes valuable resources. Logging in and accomplishing activity on your VMs’ desktops increases the amount of memory they consume.

Microsoft provides the Remote Systems Administration Toolkit, PowerShell and VBScript, as well as many other tools for efficient virtual machine management. All these lightweight tools require much less VM capacity than a traditional login. So use them, and avoid wasting processing power and memory like an amateur.

Easy Mistake 3: Antivirus and anti-malware scanning of VM disk files
Your corporate security policy might not allow for the exclusion of Virtual Hard Disk or Virtual Machine Disk Format (VMDK) files from antivirus and anti-malware scans. But be aware that the real-time scans of such products can substantially reduce the overall performance of these files — and, thus, their virtual machines. Since a VM’s processing is highly dependent on its disk subsystem, any extra activities that slow down that process slow it down as well.

That’s not to say that VM disk files shouldn’t be subject to security scanning. Scheduled scans of such files can ensure that they don’t get infected, without the processing overhead of real-time scans. Also, some of today’s more advanced scanning products are beginning to incorporate virtualization awareness to reduce their overall impact. If your security policy will allow it — or if you can bribe your security officer to look the other way — definitely consider excluding these files from your real-time scans.

Easy Mistake 4: Windows Server’s power options
At conferences around the country, I’ve encountered the final mistake repeatedly. The default power option of Windows Server 2008 upon installation is set to "Balanced." Of the three options available — Balanced, Power Saver and High-Performance — this is the second of the three in terms of overall system performance. You might save a few dollars on energy, but at the cost of wasting some of the server’s processing power. Resetting the radio button to the high-performance option has a noticeable effect on how well VMs will perform.

Group policy is probably the easiest way to do so. If you create a new policy and navigate to "Computer Configuration > Policies > Administrative Templates > System > Power Management," look for the policy called "Select an Active Power Plan." Configuring this policy across your server infrastructure ensures that you always run with highest performance.

Posted via email from Aaron Johnstone