The #1 unofficial ISA Server resource site

ISAserver.org Newsletter of June 2003

Sponsored by: Rainfinity & GFi Software Ltd.
ISAserver.org Newsletter
June, 2003

In this issue: Welcome to the Isaserver.org newsletter! Each month we will bring you interesting and helpful information on ISA Server. We want to know what all *you* are interested in hearing about. Please send your suggestions for future newsletter content to: tshinder@isaserver.org

Special Offer for ISA Customers from Rainfinity:

Try the first integrated internet connection and firewall high availability solution for Microsoft ISA Server-- Free for 30 days!

Rainfinity enables ISA Server to handle multiple external interfaces and brings fault tolerance to your ISA Server gateway to avoid business continuity disruptions and save you thousands of dollars per year! Download RainConnect and RainWall--each designed for Microsoft ISA Server today! http://www.rainfinity.com/products/downloads.html



1. Site Updates & other

By Stephen Chetcuti

The last few weeks saw the launch of yet another site in the Internet Software Marketing network; ServerFiles.com: check out the site whenever you require server software, with software categories ranging from 'Intrusion Detection' to 'Email Servers', and with reviews and ratings on most products! The site will be continuously updated with new listings so make ServerFiles.com your first stop when looking for a software solution that's right for your network.

This month's newsletter feature by Tom covers 'Top Ten ISA Server Firewall Errors', check it out below!

Keep an eye out for a new section soon to be launched on ISAserver.org called 'ISA Server Services', within the section you will find links to all ISA related service providers, including various training institutions, support providers, consultants etc... Email us today at info@isaserver.org if you'd like a free listing for your company within the services directory.

Best Regards,
Stephen Chetcuti

2. ISA Server and Beyond Book and ISA Server and Beyond Seminars Now Available

By Thomas W Shinder

ISA Server and Beyond is now available! ! We've included tons of stuff on DMZs, firewall chaining, hierarchical Web caching (Web Proxy chaining), SSL bridging, SSL publishing, OWA, Secure IMAP4/SMTP/POP3 publishing, and publishing services on the ISA Server itself! Most of this stuff isn't described anywhere else. If you're ready to take ISA Server 2000 to the next level, then this is a book you must have.

Click here to order ISA Server and Beyond from Amazon.com today!

Are you wrestling with ISA Server? Need to get your head around what makes ISA Server tick? If so, consider my one-day seminar on ISA Server. I'll bring meaning to inbound and outbound access, ISA Server client types, Web and Server Publishing, and VPN Servers and VPN Gateways. I guarantee you'll learn something new and maybe even have fun along the way. The next seminar is May 9th here in Dallas, Texas. Click HERE for more info and I hope to see you there!

 

Click here to Order your
copy today

Special Offer for ISA Customers from Rainfinity:

Try the first integrated internet connection and firewall high availability solution for Microsoft ISA Server-- Free for 30 days!

Rainfinity enables ISA Server to handle multiple external interfaces and brings fault tolerance to your ISA Server gateway to avoid business continuity disruptions and save you thousands of dollars per year! Download RainConnect and RainWall--each designed for Microsoft ISA Server today! http://www.rainfinity.com/products/downloads.html


3. Top Ten ISA Server Firewall Errors

By Thomas W Shinder, M.D.

Last week I had the opportunity to talk to some of the best firewall administrators and designers in the world. One of the main topics of discussion was how ISA Server is deployed as a firewall. It became clear to all of us that while ISA Server is an ideal firewall for both small and large businesses, there were certain things about how ISA Server is deployed that detracted from the very high level of security an enterprise firewall like ISA Server could provide. 

These discussions inspired me to come up with a “top ten” list of mistakes ISA Server firewall administrators make when deploying the firewall. This top ten list isn’t drawn from detailed survey data or content analysis from the ISAServer.org forums and mailing list. These top ten errors represent impressions I’ve gained from reading nearly 100,000 ISA Server related posts in the last two and a half years.

This list isn’t in order of how bad the mistakes are or how often they happen. They represent a combination of the most common and most dangerous mistakes ISA Server firewall administrators make.

  1. Co-locating Mail and Web servers on the firewall

There’s just no way around this one. You can’t put mission critical services on a firewall. First, if there is a network attack from the outside, the firewall is the first device to feel the pain. If the firewall is compromised, the mail and Web services are compromised with it. When you put mail and Web services on the firewall you completely lose the ability to exercise “defense in depth” because you’ve removed the “depth”.

You also increase the probability that your network defenses will be compromised because each service running on the firewall represents another portal of attack. Another way of thinking of this is that you’ve significantly increased the “attack service”. It’s a lot easier to drop a bomb somewhere on a football field than it is to get that bomb on top of a single house. You’ve increased the attack surface on your firewall to the size of a football field when you put mail and Web services on the firewall.

  1. Disabling packet filtering

Where do you start when things don’t work? Suppose you’ve installed the firewall and created some Protocol Rules and Site and Content Rules and nothing works. Now what? The first thing many ISA Server firewall administrators do is disable packet filtering and create “all open” Site and Content and Protocol Rules. The assumption is that if you create this type of wide open configuration you can safely rule out firewall issues as the source of the problem.

The problem with this approach is that packet filtering protects you from Internet intruders. Once packet filtering is turned off, all listening ports on the external interface of the firewall are open. The only time you should turn off packet filtering is when you’re far away from the Internet and other untrusted networks. There are just too many ISA Server firewall administrators with horror stories about how they were hacked while they were installing ISA Server when the external interface was connected to Internet.

  1. Running client applications on the firewall

The firewall is not a workstation. PIX administrators don’t run Outlook Express on the PIX box. Nokia administrators don’t run Internet Explorer on their boxes. Norton Enterprise firewall administrators don’t run Kaaza on their devices and Netscreen admins don’t run MSN Messenger on their firewalls. The reason why they don’t do this is because they know the firewall isn’t a workstation. The firewall is a security device, and you don’t run well-known security risks on the security devices.

  1. Allowing file sharing application through the firewall

Do I need to say more about this? Why does any firewall administrator ever ask how to allow Kaaza, Morpheus, or whatever warez application happens to be popular at the time through the firewall? That’s like asking the FBI how to sneak guns into airports! It’s that insane. The purpose of the firewall is to protect your network. When you allow file sharing applications on your internal network, you are inviting attack from worms, viruses, Trojans and other dangerous applications and code.

The exception to this might be admins who run ISP networks. In this case, you have to give your customers what they want, but you should never allow these applications on your internal network laying outside of the public network that serves your ISP clients.

  1. Allowing Instant Messenger communications through the firewall

Instant Messengers can be very useful when all the IM hosts are contained within the private network. The problems come arise when you allow users to connect to other users on external, untrusted networks. You can’t control file transfers that take place within the IM channel. While you can use Site and Content Rules to control the types of content users can access, and what sites the users can access when they use the Web browser, mail client and FTP clients, its very difficult to control all the IP addresses that IM clients connect to.

Firewall best practices really do demand that you block instant messenger applications from your network. The only exception to this is if you have added layer 7 protection against instant messengers by using a plug in like the Akonix IM (http://www.akonix.com/) whacking application filter.

  1. Misconfiguring the LAT

LAT misconfiguration can lead to some disastrous results. The LAT (Local Address Table) defines the ISA Server’s trusted networks. All IP addresses in the LAT are considered trusted addresses and packets received from LAT hosts are not exposed to firewall policy.

Many neophyte ISA Server firewall admins will put the external interface into the LAT in order to get a recalcitrant application through the firewall. What would happen if an intruder were able to get to a host on the network ID on the directly connected public network? The ISA Server will consider that a trusted host and allow complete access to the ISA Server and through the ISA Server, access to the internal network. Not good.

  1. Using the firewall as a unihomed Web Proxy server

You paid for a firewall and you got a good firewall with exceptional layer 7 inspection skills. So what do you do with it? You deploy it like Proxy Server 2.0. What’s up with that? Yes, I understand if you have a yearly license contract for an existing Checkpoint installation, but in that case create a back to back firewall installation and create a DMZ between the firewalls.  If you don’t use the ISA Server firewall as a firewall, you lose out on the granular inbound and outbound access control is provides that the Checkpoint box could never provide.

  1. Misconfiguring DNS settings on the firewall interfaces

The primary cause of poor performance is misconfigured DNS settings on the ISA Server firewall interfaces. Unless you’re using the ISA Server as a SOHO firewall (which it wasn’t designed to be), then you have a DNS server on the internal network that can resolve Internet host names. You should configure the internal interface of the ISA Server to use your internal DNS server as its only DNS server. If you have more than one DNS server on the internal network that can resolve Internet host names, then list them all. Make sure these DNS servers can also provide the information required for the ISA Server firewall to access a domain controller. The internal interface should also be on the top of the interface list.

  1. Using deny rules instead of using least privilege

Your ISA Server firewall is all about inbound and outbound access control. Packet filtering prevents external intruders from access your network, but you also need to control what internal users are accessing on external networks. That means you need to know what protocols your business requires and let only those protocols through the firewall. Too many times ISA Server firewall admins create an “all open” Protocol Rule and install the Firewall client on the internal network clients with the goal of reducing the number of support calls. This strategy does reduce the number of support calls relating to outbound access issues. That is, until the time when the network is compromised by some protocol that your business didn’t need, but an AOL’er brought into the internal network.

Don’t create “all open” Site and Content and Protocol Rules and then try to prevent access to select applications or sites using deny rules. Instead, create Protocol Rules that allow access and Site and Content Rules that allow access. Remember that users only have access to Protocols and Sites that are explicitly allowed (assuming that you’ve disabled or reconfigured the default Site and Content Rule on standalone ISA Server firewalls). There is no need to create deny rules unless you have users that belong to multiple groups and you need to deny that user access to a protocol or site that he would otherwise have access to by virtue of another rule.

  1. Using a mix of firewalls

Here’s one that I formerly felt was a good policy. The philosophy was that if an intruder broke through the front end firewall, they would have to start all over again with the back end firewall because that back end firewall was from a different vendor. It certainly sounds good and looks good on paper, but how valid are the underlying assumptions? Very few properly configured firewalls are compromised. The overwhelming majority of intrusions are due to misconfigured firewalls. Firewalls are complex products and the proper configuration of a firewall is a complex subject. You significantly increase the probability of error when you introduce firewalls from two different vendors into the mix. Therefore, best practice is to use two ISA Server firewalls instead of an ISA Server and a 3rd party firewall.

The best example of the problems introduced with multiple firewalls is seen when you try to create VPN gateway links between sites. Microsoft made the decision to support PPTP and L2TP/IPSec in both VPN server and VPN gateway mode. The reason for using L2TP was to make interoperability easier, as there were standardization issues with creating pure IPSec VPN tunnels. The problem is that other firewall/VPN vendors have decided to implement pure IPSec tunnel mode for VPN gateways. The ISA Server firewall doesn’t support pure IPSec tunnel mode for VPN gateway to gateway links, so you need ISA Servers on each end to make things work.

Conclusion

Don’t feel bad if you’re guilty of one of these top ten mistakes. I’ve made some of them and I know other great firewall admins who have make the same mistakes too! The goal, as always, is to learn from our mistakes and not make them again. Do you think there’s a big ISA Server firewall mistake out there that I haven’t listed here? Let me know! Write to tshinder@isaserver.org and I’ll include your comments in next month’s newsletter. Also, stay tuned for next months newsletter, as I may have some very exciting news to share with you. Thanks!!! –Tom..

Downloads content checking & anti-virus for ISA Server with GFI DownloadSecurity!

GFI DownloadSecurity for ISA Server enables you to assert control over what files your users download from HTTP & FTP sites. Downloaded files are content checked for viruses, malicious content and objectionable material, and can be quarantined based on file type and which user downloaded them. GFI DownloadSecurity handles the security risk of file downloads without resorting to blocking all file downloads at firewall level! Blocking of file downloads is an unpopular policy, and results in your having to temporarily open ports/file types for users, resulting in additional administration and potential security holes.

Click here to download your free trial!



4. ISAServer.org Learning Zone articles of Interest


We have a great group of articles in the Learning Zone that will help you get a handle on your most difficult configuration issues. Here are just a few of the newer and more interesting articles:

5. KB Articles of the Month


Here are some interesting and useful ISA Server related Q articles posted by Microsoft in the last month:

6. Post of the Month!


Many people have had problems with getting McAfee, VirusScan, NetShield and GroupShield automatic updating to work correctly on and behind ISA Server. Richard Parsons comes to the rescue with a fine step by step that any ISA Server admin can use:

class=712301121-15042003>"First create a Protocal rule and give it a name,
1)Custom Protocol
2)FTP Download only
3)Schedule = Always
4)Apply to "Any Request"

And save the new Rule. Next Create 2 new Packet Filters as follows:

Filter 1
1)Name: "Allow Connections to Ftp nai.com"
2)Description: As you wish
3)Filter Type "Custom"
4)Protocol "TCP"
5)Direction "Outbound"
6)Local Ports "All Ports"
7)Remote Ports "Fixed Port 21"
8)Applies to "Default IP Address's on External Interfaces"
9)Remote IP "All Machines"

And Save. Now for the second packet filter for the data channel:

Filter 2
1)Name: "Allow Connections to Ftp nai.com"
2)Description: As you wish
3)Filter Type "Custom"
4)Protocol "TCP"
5)Direction "Inbound"
6)Local Ports "All Ports"
7)Remote Ports "Fixed Port 20"
8)Applies to "Default IP Address's on External Interfaces"
9)Remote IP "All Machines"

And Save. Configure Mcafee product you wish to update in the Mcafee update properties box, to use your ISA server eg. <server name> port <8080>.And Bingo! Hope this helps. --Rick Parsons"

class=712301121-15042003>Thanks Rick!

Special Offer for ISA Customers from Rainfinity:

Try the first integrated internet connection and firewall high availability solution for Microsoft ISA Server-- Free for 30 days!

Rainfinity enables ISA Server to handle multiple external interfaces and brings fault tolerance to your ISA Server gateway to avoid business continuity disruptions and save you thousands of dollars per year! Download RainConnect and RainWall--each designed for Microsoft ISA Server today! http://www.rainfinity.com/products/downloads.html



7. ISA Server Links of the Month


ISA Server works great with Windows Server 2003 machines. However, it doesn't work great out of the box. There are several fixes you must apply before ISA Server what its supposed to do. You'll need both ISA Server Service Pack 1 and a special update package. You can find those fixes at:

http://www.microsoft.com/ISAServer/TechInfo/Deployment/WindowsServer2003.asp

Many of you have been asking about regionalized versions of ISA Server Feature Pack 1. If you've been waiting for French, German, Japanese or Spanish versions, your wait is over! Head on over to the link below and get the one you need:

http://www.microsoft.com/isaserver/featurepack1/howtogetfp1.asp

Finally, I highly recommend that you pick up the NetBIOS Protocol Definition delete tool. There no reason to allow outbound access to NetBIOS resources. This tool will prevent you from being a victim of a number of NetBIOS worms that have been hitting the Internet and private networks in the last year:

http://support.microsoft.com/default.aspx?scid=kb;en-us;816996 

8. Ask Dr. Tom


QUESTION: I’m trying to publish an SSL Web site on the internal network behind the ISA Server. My ISA Server has an external interface with a public address on the DMZ, and this DMZ is behind a PIX. The PIX is doing packet filtering and I’m allowing all TCP 443 into the ISA Server. The link has to be SSL all the way from the client to the Web server on the internal network. I think I can get this to work, but can you give me the “big picture” of what’s going on? Thanks!

ANSWER:

The major advantage ISA Server has over other firewalls is its layer 7 sophistication. SSL to SSL bridging is the best example of how ISA Server leverages this superior layer 7 awareness. Most firewalls perform the same function as Server Publishing Rules: you map TCP 443 to a particular host on your internal network. Your firewall has no idea what is going through TCP 443 because the data is encrypted in the SSL “tunnel”. This is why the PIX and similar devices act like simple packet filtering routers when it comes to SSL publishing.

When you use ISA Server Web Publishing Rules, the external client creates an SSL link to the external interface IP address of the ISA Server. The ISA Server decrypts the SSL packets and examines them for unwanted commands, characters or files, depending on your configuration. After the ISA Server’s Web Proxy service examines the HTTP message, it reencrypts it and forwards it to the SSL server on the internal network via a second SSL link. The SSL server on the internal network sends the answers back to the ISA Server via the second SSL link. The ISA Server again decrypts the messages, examines them, then reencrypts and forwards the response to the client on the external network that made the initial request. The ISA Server always knows what’s going on inside the SSL communication, unlike other firewalls that merrily pass the SSL data between client and server.

SSL to SSL bridging provides almost ‘end to end’ encryption. I say almost because the ISA Server decrypts the packets at the ISA Server machine itself to inspect them before it reencrypts and forwards them.

            Make sure all of your certificates are issued from the same CA, or from CAs in the same hierarchy of trust. In general, if you’re not running an e-commerce site, you can use the Microsoft Certificate Server to issue your certificates from either an Enterprise or standalone CA.

            SSL clients (machines running the Web browser) need the CA certificate of the CA granting the Web site certificate in their Trusted Root Certification Authorities Node; they don’t require a user or machine certificate just to create an SSL link. The ISA Server needs a Web site certificate, and that Web site certificate is bound to the Incoming Web Requests listener that accepts the request. The ISA Server also needs the CA certificate of the certificate granting CA in its Trusted Root Certificate Authorities node (for the machine account). Finally (or perhaps firstly), the Web site on the internal network needs a Web site certificate. It’s this Web site certificate that’s exported (along with its private key), and then imported into the ISA Server’s machine certificate store. The details are in ISA Server and Beyond and also in numerous articles over at www.isaserver.org/shinder.

            The most common problem administrators new to Web Publishing run into is the “common name” or “subject” in the certificate. When you request a certificate for the Web site, make sure that you include the actual FQDN that external users will use to access the site. For example, if external users will type in http://www.mysslserver.com/ to access the published SSL Web site, then you must include http://www.myssslserver.com/ as the “common name” in your Web site certificate request.
 

Special Offer for ISA Customers from Rainfinity:

Try the first integrated internet connection and firewall high availability solution for Microsoft ISA Server-- Free for 30 days!

Rainfinity enables ISA Server to handle multiple external interfaces and brings fault tolerance to your ISA Server gateway to avoid business continuity disruptions and save you thousands of dollars per year! Download RainConnect and RainWall--each designed for Microsoft ISA Server today! http://www.rainfinity.com/products/downloads.html


Visit the Subscription Management section to unsubscribe.
ISAserver.org is in no way affiliated with Microsoft Corp.
For sponsorship information, contact us at advertising@isaserver.org.
Copyright © ISAserver.org 2003. All rights reserved.