Reverse DNS for a non Class C range

One of the many spam detection techniques certain ISP's and mail servers use today is the ability to get a valid reverse DNS entry for a mail server. The theory is that if the mail server has a reverse DNS entry tied to a legitimate domain then someone actually meant to set it up as an email server and not some random spam-bot. This is a good theory but one that legitimate mail servers sometimes have trouble getting set up right.

Chances are that you are a small to medium size company and that you do not have an entire Class C subnet of public IP's assigned to you. You probably are running your own DNS servers across different physical locations and want to provide maximum reliability and uptime for your network. In this scenario, you have two options:

1. Your ISP is handling reverse DNS entries for your subnet and you need to provide them with what DNS names you want assigned to a particular IP address.

2. You have been delegated authority for your subnet by your ISP and you are responsible for proper reverse DNS entries on your DNS server

A lot of folks do not realize that they have option 2 and usually rely on the ISP to manage your reverse DNS entries. This can cause some support and management headaches so I tend to try to host DNS completely in-house.

When trying to set up a reverse DNS range, it is easy if you have a large subnet of IP's, but what if you just had:

12.233.182.230/224

How would you create this zone?

It is a bit tricky, but you first need a reverse DNS zone of:

224/27.182.233.12.in-addr.arpa

This signifies that the zone is a reverse DNS zone for the 224/27 network which is not a class C. You then create an entry for 230 which would map to:

mail.somecompany.com

And then if you do a nslookup on that IP address you can then be mapped to the proper host name.

Clear as mud? Microsoft has a good article here:

http://support.microsoft.com/kb/174419

Opening firewall ports in VMWare ESX

One of the things that you can do with a Dell PowerEdge server is to install the OpenManage utilities on your VMWare ESX platform which is quite helpful at managing the physical hardware that hosts your VM's. Unfortunately, the installer does not open up the ports inside of ESX automatically so you need to know how to open these ports yourself. From a shell or via the console as root, use the following command:

esxcfg-firewall -o 1311,tcp,in,OpenManageRequest

This command will open TCP port 1311 for inbound requests on the ESX firewall. You can then go to:

https://yourvmserver:1311

And successfully connect to the OpenManage interface.

McAfee Antivirus fallout from yesterday

Yesterday was one of those moments in IT when you are called into action with little to no idea as to what is going on. There is no magic book or class you can take to prepare you for a debacle like what we experienced yesterday. The morning was going fine until I received a report from a user that their machine was going to shut down within 60 seconds because of a DCOM server error on their PC. I didn't think much of it until I got a second report from a different user. I checked BigFix to make sure that nothing was being pushed to the organization that might be causing these issues and found that nothing was getting rolled out. I then went to physically investigate a single PC and immediately saw a McAfee memory error. I shut down our ePolicy Orchestrator server and started trying to deal with the fallout.

The machines that were affected had no services started except for maybe 5, no internet or network access, and no access to the start menu or other GUI functions.

After some quick investigating, I found that the file c:\windows\system32\svchost.exe was 0 bytes and was modified that morning. I concluded that McAfee must have been wiping this file so I did the following:

dir /s svchost.exe

to locate another copy of the svchost.exe file on the machine. I found two located in:

c:\windows\system32\dllcache

c:\windows\servicepackfiles\i386

I copied the file overtop of the 0 byte file, started the Windows Installer service and then uninstalled McAfee. Once rebooted, the machine worked okay. I made some notes and sent them out to our IT team to get them going. This was in place by 10:30am EST after our initial report at 9:57am EST.

Compared to others, we were very fortunate. The speed at which we disabled the updates prevented complete meltdown and affected approximately 240 machines in total. Using faxes, emails, phone calls, some contractors we were able to get 30+ field sites back up and running including two corporate headquarters. No servers were affected and for the folks that we prevented this from happening to were able to continue to work.

Looking back on the events of yesterday, I am pleased at how well everyone worked together and kept their cool. You don't often see that in a time of crisis but the IT department here did a fantastic job.

Obviously we will not be using McAfee anymore after yesterday and I will never recommend anyone using them in the future. How this passed any type of quality assurance testing is beyond me no matter what BS they may come up with in a PR release to try to offload some of the responsibility for this disaster. I have some meetings today to look at other AntiVirus products and am looking forward to not having to go through this again.