Disabling Anonymous Outbound Access in ISA Server 2000


Disabling Anonymous Access in ISA Server 2000



By Thomas W Shinder M.D.


A frequent recommendation I give on the ISA Server firewall newsgroups, Web boards and mailing list is to disable anonymous access. Most other firewalls that are unable to control outbound access on a Windows domain user/group basis, or they allow you to control outbound access via RADIUS authentication for a small handful of protocols. ISA Server firewalls allow you to control outbound access to the Internet for all protocols and all Internet sites.


Most firewalls allow you to control outbound access to the Web Proxy protocols: HTTP, HTTPS (SSL). HTTP-tunneled FTP and Gopher (if anyone cares about Gopher J ). They support these “Web protocols” using either basic authentication or RADIUS authentication. These firewalls allow you to use basic authentication to authenticate to the user database maintained on the firewall itself. RADIUS authentication allows the firewall to authenticate against the Active Directory user database. Some firewalls with integrated VPN features support RADIUS authentication for VPN connections too.


RADIUS authentication allows non-ISA Server firewalls to use the Active Directory database to authenticate users. This is a real boon because if you can’t leverage the Active Directory for user authentication, you need to manually mirror your Active Directory user names and passwords into the non-ISA firewall’s user database. This is a hassle and definitely increases the administrative overhead.


However, the biggest limitation with non-ISA firewalls is that they do not support authentication for all protocols and applications that are used to access the Internet. The non-ISA firewall must have preconfigured support for the protocol in question and all user applications must be configured to use the non-ISA firewall’s proxy service for user authentication. The most common example of this is the SOCKS proxy service. SOCKS version 5 proxies support user authentication, some even through RADIUS, but the application must be designed to support SOCKS 5 and then you must configure the application to use your SOCKS 5 services.


Get the Book!


How ISA Server Authenticates Outbound Connection Requests


ISA Server firewalls don’t suffer from this limitation. You can run any application and any TCP or UDP based protocol and the ISA Server firewall will be able to authenticate the user. ISA Server firewalls are able to do this in two ways:



  • Web Proxy clients send credentials to the Web Proxy service


The ISA Server firewall’s Web Proxy service is a CERN compliant Web proxy server. Like all other Web Proxy servers in the world, client browsers must be configured to use the Web Proxy service. The browser client is configured to forward HTTP and SSL requests to either the name or the IP address of the internal interface of the ISA Server, TCP port 8080.


The Web Proxy client does not automatically send user credentials to the Web Proxy service. The initial connection attempt is anonymous (anonymous meaning that no credentials are send along with the request). If the ISA Server firewall’s Web Proxy service allows outbound HTTP, HTTPS, HTTP-tunneled FTP or Gopher to be sent anonymously, then the connection request is allowed and the forwarded to the Internet server.


If the ISA Server firewall’s Web Proxy service is configured to require authentication, then the Web Proxy service denies the anonymous request and requests credentials from the Web Proxy client. The Web Proxy client sends credentials only after the Web Proxy service asks for them.


The Web Proxy client sends credentials to the Web Proxy service. The Web Proxy service authenticates the user and then determines if the user has permission to access the protocol or site. No permission, no access. If permission is granted the request is forwarded to the Internet server.



Note:
This is why you see anonymous requests in your Web Proxy log even when you have removed all anonymous access rules. The initial anonymous request is always recorded in the Web Proxy log.



  • Firewall clients send credentials to the Firewall service


The Firewall client is a machine that has the Firewall client software installed. Only Windows-based computers can use the Firewall client. Non-Windows computers must use the SecureNAT client configuration and suffer the limitations. There are many advantages to using the Firewall client software and all Windows clients should be configured as Firewall clients.


The Firewall client software works transparently in the background to intercept all TCP and UDP requests sent by the Firewall client computer to non-LAT hosts. The Firewall client software then “remotes” these requests to the internal interface of the ISA Server firewall.


The term “remote” is somewhat obscure, but it essentially means that the Firewall client is not dependent on your routing infrastructure to the same extent as the SecureNAT client. Unlike the situation with the SecureNAT client, where all your routers must be configured to forward Internet-bound requests to the internal interface of the ISA Server firewall, the Firewall client can be configured with any default gateway setting you like. You do not need to make any changes in how the routers on your network are configured as long as they know the route to the Internet interface of the ISA Server firewall.


The Firewall client software sends the TCP or UDP request directly to the IP address of the internal interface of the ISA Server firewall. The only requirement is that the Firewall client machines know the route to the network ID the ISA Server firewall’s interface is located on.


Credentials are always sent with requests “remoted” to the ISA Server firewall’s Firewall service. Network applications do not need to be designed to use the Firewall service. Applications are completely unaware of the Firewall client and the firewall. You don’t have to configure the applications to use the ISA Server firewall. The connection, the sending of user credentials, and the access control all happens automatically in the background. This is in stark contrast to the many configuration steps and requirements of a SOCKS proxy based firewall solution.


Now you know that both Web Proxy and Firewall clients can send credentials for user authentication at the ISA Server firewall. The next step is to disable anonymous access.


Get the New Book!


Disabling Anonymous Outbound Access


There are several ways you can disable anonymous access. However, this is the way I prefer to do it:



  • Do not enable the Ask unauthenticated users for identification option
  • Remove all anonymous access Site and Content Rules

  • The Ask unauthenticated users for identification option appears in the Properties dialog box of the Outbound Web Requests listener.



    1. Open the ISA Management console. Right click on your server name and click the Properties command.
    2. In the server’s Properties dialog box, click on the Outgoing Web Requests tab.
    3. On the Outgoing Web Requests tab, remove the checkmark from the Ask unauthenticated users for identification checkbox.



    1. Click Apply. Select the option to automatically restart the Web Proxy service and click OK.
    2. Click OK in the server’s Properties dialog box.

    The next step is to remove all anonymous access rules. An anonymous access rule is either a Protocol Rule or a Site and Content Rule that does not require authentication, either user authentication or IP address authentication, for access. The easiest way to prevent anonymous authentication is to change the configuration of the default Site and Content Rule.


    Note:
    A default Site and Content Rule is created on standalone ISA Server firewalls. No default Site and Content Rule is created when you install ISA Server firewalls in enterprise mode. You’ll have create you own Site and Content Rule when using enterprise mode.


    Perform the following steps to change the default Site and Content Rule:



    1. Open the ISA Management console, expand your server name and then expand the Access Policy node.
    2. Click on the Site and Content Rules node. In the right pane of the console, double click on the Allow Rule Site and Content Rule.
    3. In the Allow Rule Properties dialog box, click on the Applies To tab. The default setting is Any request. Select the Users and groups specified below option. Click the Add button and select a group.


    In this example I’ve selected the Domain Users group. You may not want to allow all domain users access to all sites and content. In that case, you may want to use a different group, such as the firewall administrators group J .


    Click Apply and then click OK.




    1. The changes will take place in a few moments. The amount of time required depends on how busy the firewall is at the time.

    If this is the only Site and Content Rule you have in place, all outbound requests to all sites will require that users are members of the group you configured in the rule. No anonymous requests will be allowed outbound. You will certainly want to add more Site and Content Rules to allow or deny access to other users or groups.


    Get the New Book!


    One problematic situation is outbound access for servers. Servers typically don’t, and should not, have logged on users. The firewall client should not be installed on servers, since servers don’t have logged on users. The solution to this problem is to create a Site and Content Rule that your servers can use. Computer accounts can’t be assigned permissions to Site and Content Rules, so you’ll need to create a client address set that includes the IP addresses of your servers. Then create a Site and Content Rule that servers can use to reach the sites they require access to.


    For example, I typically create a Site and Content Rule for all servers that need to access the Internet. These include:



  • Published FTP Servers
  • SMTP Servers
  • Any server that needs to download fixes (SUS servers, SMTP relays that need to download antivirus updates, etc.)
  • DNS servers that use either forwarder or recursion for Internet Host name resolution
  • Any other server that needs to make a primary, outbound connection

  • You almost never need to create a Site and Content Rule to support Published Servers. When the Published Server (using either Web or Server Publishing Rules) responds to an inbound request, that response is automatically allowed. You do not need to create a Site and Content Rule to allow the Published server to respond.


    However, in cases of “complex” protocols, you may need to create a Site and Content Rule to allow that server to respond. Why? The reason is these complex protocols need to initiate secondary connections, which represent new connection requests.


    The classic example is standard (PORT) mode FTP. The standard mode FTP server needs to create a new connection to the FTP client when sending data. This new connection is not part of the established control channel session that is already established between the FTP client and FTP server. A published FTP server needs to create a new outbound connection; the outbound connection requires a Site and Content Rule that allows it access to all sites.



    Note:
    For a comprehensive review of the FTP protocol and how it challenges firewall security, please see Stefaan Pouseele’s article
    How the FTP protocol Challenges Firewall Security.


    Get the Book!


    Conclusion


    It’s easy to disable anonymous outbound access. Just remove all anonymous access rules. In this article you learned about how ISA Server firewalls control outbound access. Both the Web Proxy client and Firewall client configurations support user/group based outbound access control. For servers that do not have logged on users, you can configure client address sets with the IP addresses of the servers that require outbound access. This allows machines without logged on users to access the Internet while at the same time preventing anonymous access.


    Most important of all, you now understand what I mean by “disabling all anonymous access rules”!


    hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=2;t=010118 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom

    About The Author

    Leave a Comment

    Your email address will not be published. Required fields are marked *

    This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

    Scroll to Top