FRAMINGHAM (04/18/2000) - Week 6: Pat messes up his own log files, wasting time he doesn't have. So what else is new?
Peekaboo, I see you! I have a crazy little program running in my lab called ScanIP 2.0. Some sick person wrote an application that will scan an Internet Protocol range and then map any shareable device a computer has open - hard drives, CD-ROMs, printers and more. Just think - some kid with nothing better to do can sit down at a PC with cable modem access or a Digital Subscriber Line, open a window to your PC and delete any file he sees, copy any document you have or move your Quicken files or e-mail messages and hold them for ransom.
I was going to spend my time this week in my lab trying everything I learned in the firewall class I took last week, but it seemed like everyone needed me every minute of every day.
What, No Command Line?
I was trying to write a little .bat file that would run commands on the firewall using the AT scheduler in the Windows NT Resource Kit. Our logs of firewall activity are around 200MB to 300MB, and it takes a lifetime to open them and manipulate the data. The documentation that comes with Check Point Software Technologies Ltd.'s FireWall-1 is really good and detailed, but of course it doesn't give you real-world examples. I grew up in Windows. Granted, I learned Basic in the third grade, but I haven't really worked in or learned my way around a command-line environment. I did a search on www.securityportal.com (a great site for FireWall-1 and also a wonderful search engine) and found a couple of sample scripts that people had posted. I plowed through them.
I wanted to switch the logs to a different directory, delete the old logs and then use the export feature so I could later import the data into Microsoft Access or any SQL database for massaging. The problem is that when you type "fw logswitch (name)" in FireWall-1 it will take the current log and name it "whatever-you-called-it *.log," but it keeps the old data in the buffer. It then continues to build on it, so you have to stop the service and delete the logs in the \\fw\log directory.
The aim was to create and export a file with only the latest information I wanted to analyze. Don't worry - when you type "fwstart," it will create new logs, giving you a fresh start. When I wrote the part of the batch file where I wanted to delete the old logs, I wrote "del /q *.*" That deletes all the files, no questions asked.
That wasn't good, because I wiped out the files I wanted as well as those I didn't want. That happened because I had the batch file in the \\winnt\fw\bin, where the rest of the firewall executables and batch files are located. After I ran the batch file up, it successfully switched the logs and then deleted all the executables and batch files in the \\winnt\fw\bin directory instead of the \\winnt\fw\log directory. Duh!
Needless to say, I was quite upset with myself. By this time, it was 5:15 p.m. and I had tickets to the symphony, so I figured I would reinstall again later.
The next day I spent an hour trying to uninstall FireWall-1 and reinstall it, but it kept saying the license was wrong, so I reformatted the hard drive, reinstalled Windows, installed Windows NT Service Packs 3 through 5 and then installed FireWall-1 and Service Packs 3 through 5 for FireWall-1.
About four and a half hours and 27 reboots later (this is Windows NT, remember) I was back where I was the day before. I still haven't gotten the batch job scripted, but I did make a copy of the \\winnt\fw\bin directory just in case I mess it up again.
This leads me into my next topic: policies. I wrote a password policy along with a document on how to select a good password. I scoured the Internet for other people's policies and couldn't find one. There are books out there for $500 that tell you how to write a security policy and books that start at $5,000 that contain actual policies. It seems that some sharing of knowledge would be helpful. If you have a security policy that you think I or others could use as a template, please e-mail me at firstname.lastname@example.org.
Mystery in the DMZ
I had a strange thing happen on Wednesday. At about 2 p.m., Web sites started timing out for no particular reason. Our team tried to ping nodes within our network. We got great responses, so we moved to the demilitarized zone between our LAN and the Internet, where our Web servers sit, and began testing our Web sites. We didn't find any problems there, either. Then we plugged a laptop into the four-port hub between our router and firewall. Again, no problems. So we opened up about seven command prompts and pinged away at three Web sites and about three routers deep into our Internet service provider.
I then opened up NeoTrace from NeoWorx Ltd. to continuously check the latency, or delays, on the path. We found that a router that was the first hop outside our Internet provider was having the problem, but employees at our provider said they found nothing wrong.
As you can see, being a security administrator can be time-consuming and tedious. You have to learn how to manage your time and projects. Sometimes I have to lock my door so I won't be disturbed or go to the lab so I can read a chapter of one of the great security books I purchased. Right now, I'm reading Windows NT Security Handbook by Tom Sheldon (McGraw-Hill, 1996) and TCP/IP With Windows NT Illustrated by Teresa Bisaillon and Brad Werner (McGraw-Hill, 1997).
The latter is a wonderful, well-illustrated view of TCP/IP. And by the way, the best computer-related book I've seen so far is Hacking Exposed (McGraw-Hill, 1999) by InfoWorld's Stuart McClure and Joel Scambray.
Next week, I'll tell you whether I ever got that simple log-switching .bat file to work. I'll also tell you about working with Plano, Texas-based Entrust Technologies Inc. to see whether its public-key infrastructure products will meet the needs of my "small" textiles firm.
Until then, remember this: Give less access to your network and more service to your clients.