BOSTON (05/23/2000) - Week 11: Pat plugs a back door with a four-port Ethernet card and wastes a day off debuggingOur purchasing agent's office is four doors down from mine, so I can clearly see all the deliveries made to his door. With my binoculars I can even read the labels on the boxes.
Right now, I can clearly see two stacked boxes with the words "Nokia IP 440" painted on all sides. These babies, which combine high-performance IP routing with a complete implementation of Checkpoint Software Technologies Ltd.'s FireWall-1 enterprise security suite, would give me expansion capabilities to burn.
I feel myself getting up out of my seat and walking toward them, ignoring my boss, who asks me to step into her office as I walk by. I finally reach the boxes, and the shipping label says, "To: Pat Rabbinsky." Well they spelled my name wrong, but who cares? I just got what I have wanted for the past two months.
Only a Dream
RRRIIINGG! My alarm clock goes off. It was just another fantasy about having all the budget I need to buy anything I want.
I really wanted those Nokia 440s, but, alas, it wasn't meant to be. As I have mentioned before, we run FireWall-1 Version 4.0, but one of our remote sites was getting a T1 and it connects back to us via three 56K bit/sec. dedicated circuits. My problem is that the T1 it uses to connect to the Internet runs through a Raptor firewall from Rockville, Md.-based Axent Technologies Inc. I don't know much about the firewall and have no control over it. This creates a back-door security hole I need to fix, pronto.
Well, being the budgetary hero that I am, I searched the Web and found that Milpitas, California-based Adaptec Inc. manufactures a four-port Ethernet network interface card called the Quartet64. It would let me create a fourth port on our existing firewall through which we can run their 56K-bps circuits, establishing the same level of security for traffic coming from the remote site's Internet connection as coming from ours.
Less Expensive Fix
I figured, "What the heck." At $500 each, I could buy just two - one for the firewall and one for the lab firewall. At this point, I had already done my testing and the card worked great in the lab environment, so now it was time to put that bad boy in the real firewall.
Now, being the lazy admin that I am, I didn't want to have to rebuild our firewall from scratch with the policy and all of our objects (ports, workstations, networks and users). So I copied them from the old firewall and installed them, along with FireWall-1, Windows NT and more, on a new firewall.
Then I went in on a Sunday and subbed out the old firewall with the new one.
Even after some tweaking, I could get out of our network to the Internet, but nothing could get back in, and I couldn't get to our DMZ, a separate network separated from our core intranet. Weird - had I done something wrong? Of course I had. I checked my IP addresses and subnets on all the ports on the network interface card, and yes, I had left a very important digit off the subnet mask, which steers traffic to and from the DMZ. OK, reboot and try again. Still nothing could get in, but I could get out.
I called my boss at home and asked her what she thought might be the problem.
After doing a series of trace routes to see what packets were getting where in the network and pinging to see what parts of the network were alive, we still didn't know why we couldn't receive packets from the outside.
At this point, I went ahead and put our network back on the old firewall. Then, for some reason, all our workstations that use network address translation couldn't get out. We decided to just wait till Monday to fix it. When I arrived on Monday, everything was working just fine. Weird. I chalked it up to FM (freaking magic) and hoped I could come up with a reason next week, when I'll try again to replace the firewall.
If you remember from a couple of weeks ago, the last administrator couldn't get our virtual private network (VPN) to work because there was no license installed on the firewall. We paid for one, but our reseller didn't give us the license. We had to go through a lot of hassle to figure this out, and the vendor, Internet Security System Inc., was little help in figuring this out. On top of that, you have to go through an arduous process to get the license key.
Well, we have it installed, and my boss asked me within what time frame I could install the necessary access rules on the VPN so we could start testing it.
I said at least two weeks, four at the longest. First, I needed to plan my strategy for the VPN. I didn't want to begin testing without planning how to manage what could be a huge job of managing the database of users' access rights, passwords and other things. If I have to manually add and delete users and passwords, without being able to pass the job along to the help desk, then I have just created a nightmare administration job for myself.
I was hoping to handle the VPN administration with a Shiva LANRover D56 dial-up access switch I bought two years ago, along with the Shiva Access Manager (SAM) 4.5 software from Intel Network Systems Inc. in Bedford, Massachusetts, formerly Shiva Corp. The salesman said that if I ever get into VPN, the SAM had a Radius server built into it, which I could use as a middleman to centrally manage access rights not only for the LANRover, but also for our Windows NT domain controllers and our VPN. Pretty slick actually. Now, if I can just get FireWall-1 to act as a proxy for the Radius server and then get the Radius server to act as a proxy to the NT domain, I'm all set.
For now, though, I will just create one user on the firewall and work my way up from that point. It's extremely important when testing anything to try the smallest and least amount of functionality or features first, then work your way up to where you want to be. This way, as you add more complexity to a project and it fails, you should be able to troubleshoot it easily.
Sounds good in theory, huh? Anyway, until next week.