 | |  |
|
| |
June 3rd, 2008 @ 7:35 am
Last week, I attended the Sonicwall Roadshow in Atlanta for a look at their E-Class firewalls and other products. I’m looking to implement a new firewall solution in the very near future and have pretty much narrowed it down to the Sonicwall E-Class boxes or Cisco. Here’s a few random thoughts about the Sonicwall products:
- The integration with Active Directory and ability to apply firewall rules and policies to users is really cool. As far as I’m aware, the Cisco ASA doesn’t do this. The example they showed was rate limiting YouTube to 30kbps for a group of users. It has a coolness factor to it, but, is it practical? Am I really going to rate limit YouTube for specific users? Most likely not.
- I really like the application level inspection and filtering. Their example was searching for an embedded watermark in a confidential document and preventing it from leaving the network. Examples included looking for it in SMTP and FTP traffic as well as HTTP uploads. I could definitely see a use for this in some businesses. In our environment, it’s not really useful.
- I’m still not a huge fan of their big confusing web interface - althought I will say it has been improved. I’m sure some users prefer the GUI, but I’d much rather have an easy to use command line
- We recently phased out our Sonicwall wireless solution in favor of Xirrus WiFi arrays. The biggest problem we had with the Sonicwall access points is once you got several clients connected, clients would randomly get disconnected and RF strength would fluctuate. I observed the exact same thing happening on the presenter’s laptop at the roadshow. I saw the “Now Connected” dialog pop up 3 times during a 30 minute or so presentation - exact same problem we had. This is not really related to the firewall itself, but thought it was worth mentioning.
- Their VPN client is nice, but there are better VPN clients on the market. We current use Cisco VPN and I am very happy with it.
- It’s expensive - way more than than the Cisco, which is the opposite of what I expected.
The E-Class/NSA series boxes are a huge improvement over the previous generation firewalls. But, comparing it’s features to our needs, and looking at the cost/performance/features ratio, I’m just not convinced it’s right for our environment. Anyone have any further thoughts?
May 16th, 2008 @ 5:53 pm
We worked for a while yesterday to get Bob’s Windows Mobile phone to sync with Exchange (Bob just joined our IT team - welcome Bob!). Without much luck. Bob is our first user with Windows Mobile. Everyone else uses Blackberry devices.
We use an ISA 2006 server in the DMZ with RADIUS authentication as a front-end server to Exchange. I initially added the Microsoft-Server-ActiveSync virtual directory to the list of paths in the existing ISA rule. We got errors about not having the correct privileges to do ActiveSync, which we obviously did have. After messing with this for a little while, I realized I needed to create a separate rule for the ActiveSync path and place it above my OWA redirect rule. I have a rule that allows the user to type in just http://webmail.jfbc.org and get automatically redirected to https://webmail.jfbc.org/owa. It seems that this rule was also redirecting the ActiveSync directory. Here’s what the “Correct” setup looks like in ISA server:

Apparently, that wasn’t the only issue. Next problem: It kept complaining about an incorrect username or password. Obviously, the username and password were correct. Some monitoring in ISA server revealed the authentication didn’t seem to be happening. All of the requests were marked as “anonymous.”
You won’t believe how simple this was. On the handheld, there are 3 boxes: username, password, and domain. We run split DNS, with JFBC.ORG as the internal domain name, so that’s what we entered. Turns out that ISA server wants the NETBIOS name instead, which is simply JFBC. It’s amazing how something so simple can create such a big issue.
May 8th, 2008 @ 1:11 am
I just noticed that Windows XP Service Pack 3 is available on WSUS. I don’t dare approve it for install without some major, heavy-duty testing, but I’m glad to see it finally available. Hundreds of patches have been released since SP2 and installing them all on a new system build is painful. SP3 will include all of those previous pages.
There are also a couple of new features included. Network Access Protection is now supported for connections to Windows 2008 servers with NAP enabled. There has also been some IP Stack hardening added, similar to the hardened IP stack in Vista.
Once I get a couple of other projects wrapped up, I’ll do some testing and hopefully get SP3 rolled out in the near future.
May 6th, 2008 @ 1:05 pm
I’ve been evaluating our current firewall situation and came to the following conclusion: We have too many products from too many vendors costing too much money and causing too many headaches.
Currently, we use a Watchguard Firebox X700 for our internal network and DMZ. It’s fine when it works, but gets flaky sometimes. It will randomly stop passing FTP traffic, or you add a new rule and it won’t actually work until you reboot. Overall, I’m not impressed.
Inside the Watchguard sites a Barracuda Web Filter. I like this box - it works great and causes very few issues. They do silly stuff sometimes like adding Northpoint.org to the “Spam” category, but, overall, I’m happy.
For our public network, there is a Sonicwall Pro 3060 running Sonicwall’s own content filtering service. The Sonicwall is a nice box, but has it’s issues with occasionally locking up and other weird stuff. I’ve used them in the past and came to the conclusion that it’s a great small office firewall, but really not an enterprise-class solution. The yearly support cost plus the yearly content filter license gets expensive too.
For VPN, we use a Cisco ASA 5510. This replaced the Watchguard VPN (with is absolutely horrible) and provides VPN access for laptops and a few remote sites (5505’s at the remote sites). I love the ASA firewalls. They are rock solid on both stability and performance and, in my opinion, easier to configure. This is definitely a keeper. Ironically, of the three boxes, the Cisco has the lowest yearly support cost.
I’m sure there were good reasons for implementing each product at the time, but everything but the Cisco was here before my time, so I don’t know all the details.
In putting it all together, this is what I’m seeing:
- We’re paying for subscriptions to two different content filtering services - one for the internal network and one for the public network.
- We have support contracts with 3 different vendors.
- There are some stability problems.
- Learning curve involved with multiple products.
Most of those contracts are up for some renewal, so now is the time for change. My thought is to get another ASA 5510 use it’s multiple interfaces to attach the internet network, the DMZ, and the wireless to one firewall. Then, hang the Barracuda Web Filter off another interface and redirect all outbound http traffic to it via WCCP.
It seems almost two simple. Once firewall for all the network segments, one content filter for everything, one less piece of hardware, more stability. It just makes sense all around. If anyone has an thoughts on this, I’d love to hear them.
May 3rd, 2008 @ 8:19 pm
Tony made an interesting comment on my Remote Access Post from a few days ago. He has a good point, and I think it’s worth visiting. We do we give remote access to and from what computers. Is it a good idea to allow them access from their personal computers? I have had the same thought, and that is the primary reason I’m not already doing it. Here’s a few thoughts:
Generally, only a user with a church supplied laptop would be given VPN rights. If the user has been granted the right to log in via VPN, though, can I really control what machine they do it from? I really can’t. All they need is the Cisco VPN client and a few configuration details, so, in theory, a tech-savy user could access the VPN from any computer.
- Is it any different from a rogue computer being physically plugged into the network? No, it’s really not. Now, random machines being attached to the network is definitely not something I promote or desire. But, it would take very extreme measures and a lot of expense to stop it. 802.1x is a possibility, but, beyond that, it would require some sort of centralized MAC Address based authentication. This exists from a few vendors, but isn’t cheap. Bottom line is, it’s not easy or cheap to keep rogue machines out completely.
- Putting costs and implementation issues aside, what impact would it have on ministry to implement the above? Are there legitimate reasons for someone to attach a “rogue” machine to the network? In general, no, but there are some exceptions.
- We live in an increasingly “connected” and mobile society. Ministry is no exception. Increasingly, being on the cutting edge of technology is a requirement of our ministry. It is absolutely critical that we enable our staff to perform their duties without being physically present in the office.
So, with the above in mind, I’ve placed a greater focus on keeping our internal defenses in line. Here’s a few actions I’ve taken or plan to take:
- Windows firewall is enabled on all workstations via group policy and no programs are allowed to create exceptions. There are only a handful of ports allowed.
- This is a no-brainer, but centrally managed anti-virus is in place on all internal machines.
- SMTP is not allowed outbound from anywhere on the network, with the exception of our exchange servers. This limits the scope of damage should a machine with a mass-mailing worm show up on the network.
- Access to network file shares is very carefully controlled. User accounts do not have access to anything they do not specifically needs to access for their job function.
After putting a lot of thought into it, I’ve come to the conclusion that the benefits to allowing VPN access outweigh the potential negative impact of not allowing it. I would rather allow limited access via other methods of possible, which is why I’m exploring Terminal Services Web Access combined with RemoteApp. But, if for some reason the Terminal Services solution does not work out, I believe VPN is an acceptable fall-back.
|
| |
 | |  |
|
|
|