FRAMINGHAM (03/20/2000) - Week 2: Avoiding a Swiss cheese firewall by limiting open ports and getting a real nice lunch with the boss.
Well, I quit my job because I felt I didn't get anything done. Just kidding (of course), but it is a completely different work environment from my previous position as a network analyst/administrator.
I mean, I can count on one hand the things I've gotten done in the past week:
1) I added myself to the firewall so I don't have to go around the proxy server; 2) learned Microsoft Project to plan all my projects; 3) added an IP address and specified the port needed for a user to access the firewall of a company with which we need to do EDI transactions; 4) was taken out for a very nice lunch by my boss; and 5) read e-mail after e-mail from all the lists I signed up for and then set up filter rules so they all go into one folder. That way, it will be easier for me to read them later.
Oops! Almost forgot - I signed up for a class on Check Point Software Technologies Ltd.'s FireWall-1 and registered for the SANS Institute 2000 security conference. Quite an exciting week, huh? I am really trying hard to decide how to begin. There is so much work to do that I could easily start one project, then another and not get back to the first until four months later.
We're Safe - We Think
Our team had a meeting Wednesday - our first meeting together. We decided that we will meet every Wednesday so we can bring up any changes that are going to be made to any of the servers or the network during the regular weekly maintenance period each Sunday from 2 to 11 p.m. We also decided that we will create an intranet site for our IT department to keep everyone in it informed.
There's a general feeling around here that we're pretty safe. We have a very low external profile as a company and as a dot-com, and the threat of an external attack is less likely as a result of our safeguards and an attack would take a very long time to engineer. We'll see how true that turns out to be.
My plan (I think) is to study the security audit done by a Big Five firm six months ago and form a strategy from that to present to the director of network services. At the same time, I will be building my lab with a test environment to mirror our production environment. This will include a direct link to the Internet and a copy of FireWall-1 for me to mess with before I apply changes to the real firewall. There is also the possibility of placing an NT box and a Linux box on a hub outside the firewall, just to see what kind of hits our network is taking.
There are some wonderful documents written by Lance Spitzner on building your NT box for FireWall-1, as well as other security how-tos, such as auditing the failed or rejected packets from FW1, among others. I found them at www.enteract.com/lspitz/pubs.html. I will be building the lab next weekend, and I will let you know how I configure my firewall and any challenges that I come across. A major task is to build a real-time intrusion-detection system for our internal network.
Trust the Techies
The products I will be testing include Internet Security Systems Inc.'s RealSecure and Network Ice Corp.'s IcePac product lines. One of the things I look for in a company is not whether it has the best product but whether my company already buys from it, so we can lower our overall purchase price of its products, which in turn lowers our total cost of ownership.
Another important factor is customer support. I'm a huge believer in talking with the technical support people at a company before I buy from them. Salesmen will always be nice and tell you what you want to hear, but it's the technical support staff that will let you know the true limitations and selling points of the product.
Another issue is that a plant manager wants to receive e-mail via his new laptop through an Internet service provider when he's off-site. He can't access the corporate Exchange server from the Internet for two reasons: first, because his mailbox resides on our remote mail server in Cleveland and not on the main mail server in Denver, and second, because as a remote site on our internal frame-relay circuit, it's not addressable or viewable from the Internet.
Because his mailbox resides on a remote internal Exchange server, I will have to translate the remote mail server address by taking the internal IP address of the mail server and giving it a legal address from one of our internal networks.
I will add a rule to the firewall in Denver allowing access to that address from the Internet. By default, Exchange randomly assigns the Exchange remote site services to high-numbered UDP ports at random. Instead of opening all those ports, we want to limit the number of ports that are opened and, thus, the number of holes in our firewall. So we will have made the changes in the registry of the remote site to point to the ports we specify and will then create a group object reflecting the assigned ports on our firewall.
Any inbound IP packets destined for the remote mail server using the specified ports will be allowed through, and everything else will be dropped. Now, in FW1, you have to add the address to a local.arp file and stop and restart the firewall daemon so it will see the entry you just made. We will also have to add an entry to the cached route table.
Next week, I have a meeting planned to discuss deploying modem pooling for our dial-out users so we can get rid of all the desktop modems on our campus to eliminate a possible back door for hackers . I have created a global group on NT for the software and dial-out access rights to better centralize planning and administration of dial-up users and their rights. I plan to use the help desk for troubleshooting, since I am only one person and the help desk has 10 people.