Port Panic

Today was one of those days. The network was down when I got to work, so even before my first cup of coffee I was fielding “I can’t..” and “It doesn’t…” We’ve been having some issues with one of our older 3com switches and that was my first thought. I did a reboot of that switch but that didn’t clear things up. It did bring back internet but my fileserver was still offline (ping-able) but nobody could connect. I did a reboot of that server and while I was waiting for it to come back up I had a look at the last vulnerability scan for our AD/DNS server. This scan is done by eEye software’s Blink which is built on the highly regarded Retina vulnerability scanner.  I hadn’t checked the scan results for a while (bad me, I know… but at least I AM  scanning. Are you??) And the thing that immediately caught my attention was a HUGE number of open UDP ports. (in the thousands!!) The port numbers range from 49157 to 65529.

Immediately I’m thinking I’ve either been hacked or someone has set up some P2P on our network. I was pretty sure it wasn’t someone internal so I immediately went into intrusion event management mode. Checking logs, current firewall traffic, A/V scans and then a bunch of malware scans. Blink is has a good set of tools for this and it was coming up empty. I went to my next line of defense which is good old Spybot. Again the system came up clean.  I also used a tool from eSet (makers of NOD32 A/V) called SysInspector. This is a useful utility I found on a sans.org diary posting. Nothing out of the ordinary there either. Lastly, I did a scan with RootKit Revealer from sysinternals err Microsoft. Again, nothing.

I should point out that by this time everything is working fine for all my users. You might be thinking that by this time, I’m feeling a bit better about things. Nope. In fact I’m even more worried as I’ve got a ton of open UDP ports and I can’t find a reason why. My next move is to create a custom rule for the Blink software firewall, blocking the open UDP ports and log the results. All of a sudden, the Blink service goes to 100% cpu and I’m getting a -lot- of denied log entries for all of these various ports. Each of these ports seems to be trying to contact a different external IP. Now I’m thinking I’m really screwed. Someone is operating some kind of server on my -clean- system!

But then… I get a call. “I just lost my internet”, then another. Then -I- can’t browse to some sites. Hmmm. DNS? I did an ipconfig /flushdns /registerdns on my workstation and now I have no name resolution. Ok. It’s DNS related for sure. I go back to my AD/DNS server and remove my newly created rule repeat the ipconfig and viola… the internets are back.

So, I did a google search for UDP 49157 to 65529 and didn’t really turn up anything. But I did finally come up with a mention of them being part of the dynamic or emphemeral port range. Once I found that out I found the wikipedia entry which gave my the entire range of these ports (49152–65535). With that and a quick search, I was finally led to an article on TechTarget which has an explanation.

“This security update also introduces a new default for DNS port settings for Windows Server 2000 and Windows Server 2003 — dynamic default socket port ranges have changed from 1025 through 5000, to the new range of 49152 through 65535. We encourage you to review the firewall settings in your environment to ensure that traffic between servers in the dynamic port range of 49152 through 65535 is allowed. Windows Vista and Windows Server 2008 already have the default port range of 49152 to 65535. For additional information, please review the MS08-037 bulletin.”

Lightbulb moment. All those open ports are supposed to be there. They are the ports which are used by the new DNS patch to avoid the DNS cache vulnerability of July 2008.  Sigh. I probably could have stopped after rebooting the fileserver (oh, about 6 hours ago)

I don’t feel that it was a wasted day for a couple of reasons. Firstly, like most other short handed IT folks, I never make the time to do incident response simulations. This was a good -simulation-. Secondly, I’m pretty confident that my various levels of security, patching and updating are doing their jobs. Lastly, I’m happy to report a clean bill of health for my server room.

It’s too late for that cup of coffee, but it’s just the right time for a drink,


Creating a System DSN with Coldfusion

If you read my last post, you know I’m working with an old Foxpro DB. One of the problems I’ve encountered is that the software I’m trying to interface with  (UPS Connect) takes the current day’s data and archives it into folders based on the month. It has a folder structure similar to this

ups root>



  • S100108.dbf
  • S100208.dbf
  • S100308.dbf etc

Now it’s not a problem that the individual days are in separate dbf files as the Foxpro driver takes care of that as long as we have a system DSN set up.  However, since every month needs a new system dsn (to connect to the month’s folder) I needed a way to pro grammatically create system DSN’s via coldfusion. Turns out it is pretty simple if you have access to the cfregistry tag.

(Standard warning about fiddling with the registry… back up before doing any of this and I’m not responsible for any damage however caused yada yada)

Run the following code it will create the system dsn for you. (I didn’t test it but it’s possible that cfservice needs to be running under admin permissions)

<!— create the new system DSN name.
For simplicity it will also be the key location and the file location
UPS Connect archives files in mmmyy format
<cfset newDSN = left(MONTHASSTRING(datepart(“m”,now())), 3) & right(year(now()),2)>

<!— Create a New Key —>
VALUE=”#newDSN#”    >

<!— Create String values for the System DSN under that key —>
VALUE=”No”    >

VALUE=”Machine”    >

VALUE=”C:\WINDOWS\system32\vfpodbc.dll”    >

VALUE=”No”    >

VALUE=”No”    >

VALUE=”\\\ups\Oct08″    >

VALUE=”SystemDSN for Oct08″    >

VALUE=”DBF”    >

This sets all the correct settings for the UPS system DSN.

For my purposes, I don’t need to keep connections to last month’s folder so there’s no reason to keep the old system DSN. Fortunately, there is an easy way to get rid of old registry entries such as system DSN’s.

<!— once in new month find last months mmmyy by using dateadd -1—>

<cfset oldDSN = left(MONTHASSTRING(datepart(“m”,dateadd(“m”,-1,now()))), 3) & right(year(now()),2)>


Add the delete code to the create new code, run it all via cfschedule on the first day of each month and you’d need no user intervention to maintain your ever changing System DNS’s

NOTE: This code does NOT create the datasource for coldfusion, only the system DSN so we can set up the datasource via the CF ODBC Socket. For that we have to either set it up with CFAdmin or since we want to automate the process, use the admin API. Check my next post for that step.

Coldfusion 8 & Foxpro Datasources

I’ve just spent the last 2 days trying to get a CF8 datasource connection to a FoxPro dbf table. FoxPro?? Some of you might have to look that up. Basically it’s an antiquated database system based on dBase (some more of you may have to look that up). Each table in a FP db is contained in a separate file


unlike most recent db’s which have all the tables contained in a single file



As you might expect, trying to get a brand new app like CF8 and an antique like FP to communicate is a bit like trying to put a saddle on a Ferrari; you can do it but it’s not pretty.

This current project involves getting UPS tracking numbers out of the UPS Connect software which is (you guessed it) FoxPro based. The software has the ability to export tracking number to a csv but it’s a manual process and I don’t want my users to be doing this. It’s also not appropriate as I need the tracking numbers as soon as they are created and batch processing just won’t cut it.

My initial approach was to try and set up a MSSQL linked server using the FP table but after almost a day I gave up. I was able to create the linked server but any time I tried to open the table I received an error

OLE DB error trace [Non-interface error: CoCreate of DSO for MSDASQL returned 0x80040154].
Msg 7302, Level 16, State 1, Line 1
Could not create an instance of OLE DB provider ‘MSDASQL’.

According to several posts this is likely a permissions problem. Based on my reading I set the Connect folder full permissions to everyone, I restarted both MSSQL and SQLAgent services logged on as admin, created TMP and TEMP environment variables on the SQL server machine…and probably some things I have forgotten about but to no avail.

Being under some time pressure I decided to set up the CF datasource using the ODBC socket. I had initially decided not to go that route as I didn’t install ODBC Server components when I did the CF8 install. If you choose not to install there’s no easy way to add it later (ie: via add/remove programs) You either have to do a complete uninstall/reinstall or use the procedure outlined in http://kb.adobe.com/selfservice/viewContent.do?externalId=kb402637&sliceId=1 which is actually a work around for a bug in the CF8 installer.

There is a bug in the install script of CF8 (earlier versions at least) which will prevent the install of the ODBC server software. This occurs if you opted to install the ODBC server but didn’t install the documentation (which you should never do on a production machine).

Follow the procedure under “Download procedure” making sure to change the line


If you don’t you will get an error The current user is not authorized to invoke this method.

Check to see  you’ve got the ODBC Server services up and running by Start > Run > services.msc

The next step depends on whether the FoxPro file is located on the CFServer machine or on a network share. In most cases the file will be on a share but if not you can skip this bit. If not we need to set up CF in a particular way so we can set up the Datasource.

Because CFServer service is installed by default to run under LocalSystem, CF will have no access to network resources. People often encounter this when trying to use cffile, cfexecute, cfdirectory or any of the verity tools. The solution is to set up the CFService to run under a “network user”.  More on that in a bit.

Running as LocalSystem is not normally an issue when setting up a connection to something like MSSQL or MySQL. The driver handles the connection and it doesn’t matter what context the service is running under. However, with FoxPro, you are making a different kind of connection; one that requires file level permissions to access the table, just as you would need with cffile et. al. I haven’t tested it but I expect this would be the case with any file over ODBC such as Access or Excel.

To set up the Coldfusion Server service do the following:

  1. Create a standard user in Active Directory (call it CFService)
  2. Select a very strong password and Set Password To Never Expire
  3. Right Click on the directory you want CF to have access to
  4. Select Properties > Security Tab
  5. Click Add
  6. Enter CFService in the box and click OK
  7. Click CFService in the Group Or User Name Window
  8. Check the appropriate permissions (usually Read & Execute, List Folder Contents and Read))
  9. Click Apply and OK
  10. Open services.msc as admininstrator (either logged on or use RunAS)
  11. Right Click Coldfusion 8 ApplicationServer > Properties  and select LogOn Tab
  12. Check This Account and enter the user name as yourDomain\CFService
  13. Enter CFService password twice
  14. Click OK
  15. Restart Coldfusion 8 Application Server service

Now this gets you to the point where you can use cffile et. al on network resources (provided you give CFService access to those dirs) however there’s still more to do to get a Datasource set up in CFAdmin

We now need to set up a System DSN using the MS ODBC Administrator.  Start Menu > Run > ODBCAD32 when logged on as administrator or Administrative tools > Datasources (ODBC) using RunAS

UPDATE: Check out the comments for info on 64bit windows systems and 32 bit ODBC drivers (like VFP)

Click the System DSN tab and Click ADD

Scroll through the list of drivers until you find Microsoft Visual FoxPro Driver (*If it is not listed you can get it here http://msdn.microsoft.com/en-us/vfoxpro/bb190233.aspx You may need to restart your system after installing and at minimum you will need to reopen the ODBC Administrator.). Select it and Click Finish. Enter the Data Source Name (description is optional) For my situation (UPS Connect) I used Free Table Directory.  To select the path make sure you use a UNC path and not a mapped drive. I created a share on the target machine with the Connect software called ups so my path is


I did see some references to Fetch data In background (click the Options button) causing problems with earlier versions of CF so I unchecked it. Click OK and you should have a new System DSN set up.

You can now (finally) fire up CFAdmin to add your new Fox Pro datasource. On the Data Sources page, Enter your desired DSN and select ODBC Socket as the driver and click add.

Select your newly created ODBC DSN from the drop down.  Leave the username as system and password blank. (the Foxpro tables are not pwd protected)

Click Show Advanced Settings and enter the following in the Connection String box

Driver={Microsoft Visual FoxPro Driver}; SourceType=DBF; SourceDB={pathToDB}; Exclusive=No;

or in my case

Driver={Microsoft Visual FoxPro Driver}; SourceType=DBF; SourceDB=\\\UPS; Exclusive=No;

You can now verify your datasource and all is seemingly ready to go.

if you run the following query

<cfquery name=”test” datasource =”upstracking”>
select * from shipnday
<cfdump var=”#test#”>

you get an error

Error Executing Database Query. [Macromedia][SequeLink JDBC Driver][ODBC Socket][Microsoft][ODBC Visual FoxPro Driver]File ‘shipnday.dbf’ does not exist.

Turns out that you also need to change the Coldfusion 8 ODBC Server Log On credentials to  that of an account other than LocalSystem (ie: our CFService “user”) Make the changes in the Log On tab as you did above for the Application Server service and restart the ODBC Server service and viola… Tracking numbers from a foxpro database on a network share!

Note that in the query you don’t use the dbf extension even though that’s the name of the table/file. The driver takes care of this for us (I assume)

Whew… That was a long post (especially for a first one) but it represents a couple of days work and I decided to put it up here for others (and in fact for myself since I’ve got to do this all over again on the production server when I’ve finished developing this current project)