Summary

Because FlexNet Manager can run on a wide range of IIS versions and with varied configurations, the on-premises installation process performs only a minimal functional configuration for IIS. This means that you should ensure that the configuration is adequately secure for your environment, as discussed below. (This article does not apply to customers subscribing to our SaaS implementations of FlexNet Manager Suite.)

Synopsis

Ensuring that the IIS configuration on your FlexNet Manager application server is appropriately secure is, of course, the responsibility of the local system administrator. This article includes several specific issues to consider, and provides detailed guidelines to help you:

• Verify that Cache-control: no-store is present
• Ensure that Set-Cookie has Secure attribute set, and the most specific domain and path possible
• Disable TRACE methods on server.

Discussion

Tip: This article applies to the “application server” where FlexNet Manager Suite is installed. If you have a multi-server implementation, these changes apply to your “web application server”, which presents the web-based user interface handled by your web browser. 

Security of the web interface to FlexNet Manager Suite is important. Improper configuration can leak information from FlexNet Manager Suite to unauthorized employees within your organization, or worse. Consider the following principles as foundational.

Use HTTPS

For optimum security, production environments of FlexNet Manager should be configured to use HTTPS endpoints. To do otherwise significantly reduces security. It may be convenient to set up an initial deployment to an HTTP endpoint, but any such installation tests should be closed off and replaced with HTTPS endpoints before FlexNet Manager is exposed to users. The use of HTTPS is not enforced at installation time, because some installations may be for test environments. Since the HTTPS protocol is not set by default, you’ll need to modify your IIS configuration to configure it. This article does not cover the process of configuring IIS to use the TLS protocol with HTTPS endpoints. If you are seeking information about configuring HTTPS support, be sure to search for guides relating to your specific IIS version, as instructions given on the Internet are typically version-dependent.

Avoid Co-Hosting in IIS

Installing FlexNet Manager as the sole application in IIS reliably mitigates several risks related to IIS vulnerabilities and cookie paths. It’s therefore considered best practice to dedicate your application server exclusively to FlexNet Manager (optionally co-hosting a FlexNet inventory beacon if required), and not to install any other applications on the same server.

It is, of course, technically possible to co-host FlexNet Manager in IIS along with other applications, but this potentially reduces the security of FlexNet Manager and possibly of the other co-hosted applications too.

If you really must co-host with other applications, you can somewhat reduce the risk profile by ensuring that FlexNet Manager has its own sub-domain or sub-path. (It is not enough to rely on FlexNet Manager being isolated in its built-in sub-paths, such as ‘Suite’.) Without a unique sub-domain or sub-path, it is not possible to properly restrict FlexNet Manager cookies to the FlexNet Manager application alone. (More about this in the discussion of Cookie Security below.)

IIS Header Configuration

The IIS server is responsible for generating some HTTP headers that are relevant to security. Installation of FlexNet Manager does not set these, because a particular value may not be appropriate for every configuration.

Therefore, you may need to add configuration options to the IIS configuration files, particularly Web.config (the configuration file supplied with FlexNet Manager that contains settings related to IIS), so that the correct headers and cookie settings are generated by IIS. Suggestions on how this configuration might be performed are included in the Implementation section below.

Cookie Security

There are several attributes that should be set for FlexNet Manager cookies to avoid potential security risks:

• Domain – The FlexNet Manager installation process sets this to the path entered during configuration. It should not need any alteration, unless you are moving FlexNet Manager within IIS.

Tip: Many guides suggest that eliding Domain entirely and using a __Host- prefix is the most secure approach. However, this approach is not available, because FlexNet Manager sets Domain attributes on cookies by default. If you avoid co-hosting, or use a sub-domain or sub-path, security should be comparable to using a __Host- prefix.

• Path – After installation of FlexNet Manager, this is set to “/” by default. Some penetration testers have suggested that it would be more secure if it were set to “/Suite”. However, this is not possible. FlexNet Manager uses multiple sub-paths from its web-root, and using /Suite would break them. That is why, in co-hosted scenarios, using a sub-path or sub-domain is necessary (making the default path value more specific increases security only on co-hosted installations). If you must co-host FlexNet Manager with other applications in IIS, you should ensure either:
  • That FlexNet Manager is in a unique sub-domain of its own, and that this full sub-domain is configured in the Domain attribute, or
  • That FlexNet Manager is configured in a unique sub-path within the domain, and that sub-path is present in the cookie Path.
• Same-Site=Strict – This restricts the cookie to the website of origin.

Tip: In practice, FlexNet Manager uses tokens to provide protection against cross-site request forgery (CSRF), so this is more a case of defense in depth than an essential security measure.

Setting Same-Site=Strict is a way of restricting request origins. This may not work for all configurations, but if it can work for yours, you should take advantage of it. Be aware that versions of Microsoft Internet Explorer prior to version 8 do not support it. If your configuration or use-cases are not appropriate for use with Same-Site=Strict, you may still be able to use Same-Site=Lax, which is weaker, but still an improvement over not setting the Same-Site attribute at all.

• HttpOnly – After installation of FlexNet Manager, this will be set correctly by default. If you add any cookies of your own on the same server, it may be appropriate to set this attribute on them.
• Secure – This ensures that the cookie will only be sent over HTTPS connections, and will not be exposed if you accidentally allow connecting to an HTTP endpoint.

Other HTML Headers

The following header attributes are important to check, to see whether they need additional IIS configuration:

• The cache-control header is relevant to security, and should be configured to have the no-store value set.
• Some security test tools insist on having private, max-age=0, or s-maxage=0 set. Even though specifying these values is meaningless once no-store is specified, you may need to set them just to satisfy your test rigs.

Your testing may find that these values are not set if you are using an old version of FlexNet Manager, or if IIS was configured to rewrite them. In this case, the problem can be corrected in IIS.

Disable the TRACE Method at the Server Level

If your IIS installation has the TRACE HTTP method enabled, malicious JavaScript code may be able to leverage TRACE requests to access HttpOnly cookies. This is (now) mostly blocked at the browser level, but various exploits, and tools like curl, still allow it to be sent. It is safest to disable it at the server level. This article contains some background information: https://www.owasp.org/index.php/Cross_Site_Tracing

Implementation

IIS is a flexible product, and there are various ways in which you can configure it to add headers, rewrite headers, rewrite cookies, or otherwise modify its responses. The “correct” way to implement the above mechanisms will depend on your exact requirements, other aspects of the IIS installation, and your IIS version. Remember, the changes described here all relate to the server that is your application server (for a single-server implementation of FlexNet Manager Suite) or your web application server (for a multi-server implementation).

When FlexNet Manager has been installed on a clean server (with nothing else co-installed), FlexNet Manager is typically installed as the Default Web Site, with 11 applications below it (such as Suite and inventory-beacons). In this case, you may be able to tighten security generally by making most changes at the level of the parent web site, relying on inheritance to pass these settings to the child applications. If your environment is less tidy, you may need to apply the hardening settings to each of the 11 applications in turn. In the following processes, the phrase “FNMS site” should be interpreted appropriately for your particular approach – as the web site used for FlexNet Manager if you can work at that level, or each child application in turn if you must work at the lower level.

As always, you may make many of the appropriate changes either by:

• Using the IIS user interface, or
• Editing the appropriate config file in your preferred flat text editor (indeed, some changes can be made only by this method).

For this reason, some of the following processes outline both these approaches.

If you need to edit the Web.config file(s) directly, some understanding of the following structure and file locations will help. Clearly, if you are tightening security, you need to pay attention to all of these:

As IIS configuration is a popular topic, plentiful information is available from Microsoft, and from other sources, on how to perform the underlying tasks.

To Disable Trace Method:

Do either of the following on your [web] application server:

1. In the IIS Manager interface:
   1. Select the FNMS site (reminder: see comments under Implementation above).
   2. In the IIS section, double-click Request Filtering.
   3. Navigate to the HTTP Verbs tab.
   4. Right-click in the table, and from the drop-down menu, select Deny Verb.
   5. Add TRACE as the verb to deny, and click OK to close the dialog.
2. Open the matching config file in a flat text editor (to find the matching config file, right-click your working node in IIS and select Explore):
   1. Locate the webServer node in the file.
   2. Insert the following new XML elements inside it:

      <security>
          <requestFiltering>
              <verbs>
                  <add verb="TRACE" allowed="false" />
              </verbs>
          </requestFiltering>
      </security>
      

   3. Save your changes. IIS is monitoring the configuration file, and the changes take effect when it services the next web page request.

If you are working at the level of the child applications, loop back and repeat for the next one.

To Add Cache-Control and Other Response Headers

Do either of the following on your [web] application server:

1. In the IIS Manager interface:
   1. Select the FNMS site.
   2. In the IIS section, double-click the HTTP Response Header
   3. Right-click (for example, in the Name column), and from the drop-down menu, select Add.
   4. In the Name field, enter the name of the header, such as Cache-Control.
   5. In the Value field, enter the value for this header, in this case no-store.

   Tip: If you also wish to satisfy your test rigs with other values considered mandatory, combine them in a comma-separated list, even though they are redundant:
   no-store, private, max-age=0, s-maxage=0

2. In the web.config file for the (current) FNMS site on your [web] application server, locate the system.webServer node, and insert the following (again, make the value a comma-separated list if you need to), saving your changes when done:

   <httpProtocol>
       <customHeaders>
           <add name="Cache-control" value="no-store" />
       </customHeaders>
   </httpProtocol>
   

If you are working at the level of the child applications, loop back and repeat for the next one.

Mark Cookies as Secure

Adding the Secure attribute to cookies cannot be achieved through the IIS interface, so that editing the web.config file(s) is required. There are two different approaches, based on your installed version of IIS (in the IIS interface, see Help > About Internet Information Services).

For IIS versions before 7.5

1. In the web.config file for your [web] application server, insert the following:

   <configuration>
     <system.web>
       <authentication mode="Forms">
         <!-- Force secure connections for Forms Authentication -->
         <forms requireSSL="true" />
       </authentication>
     </system.web>
   </configuration>
   

2. Save and test your changes. When you are testing cookies, you may not see attributes change if you already have local cookies – first, clear the cookie store so that cookies will be refreshed.

For IIS version 7.5 and later

The simple declaration in the previous procedure will be accepted if entered in later versions of IIS, but does not do anything in those versions. Instead, a ‘rewrite’ approach is required. Careful testing and validation of rewrite results are strongly recommended.

1. In the web.config file for your [web] application server, insert the following:

   <system.webServer>
           <rewrite>
               <outboundRules>
                   <rule name="Use secure cookies" preCondition="Unsecured cookie">
                   <match serverVariable="RESPONSE_Set_Cookie" pattern=".*" negate="false" />
                   <action type="Rewrite" value="{R:0}; secure" />
               </rule>
               <preConditions>
                   <preCondition name="Unsecured cookie">
                       <add input="{RESPONSE_Set_Cookie}" pattern="." />
                       <add input="{RESPONSE_Set_Cookie}" pattern="; secure" negate="true" />
                   </preCondition>
               </preConditions>
           </outboundRules>
       </rewrite>
   </system.webServer>
   

2. Save, clear your cookie store, and carefully test your changes.

Mark Cookies with ‘Same-Site=strict’

Depending on your installed versions of .Net, IIS and FlexNet Manager Suite, you may have a few possible methods for setting the SameSite attribute of cookies to ‘strict’. The following rewrite rule should work in most cases.

1. In the web.config file for your [web] application server, insert the following:

   <system.webServer>
           <rewrite>
               <outboundRules>
                   <rule name="Use SameSite cookies" preCondition="Not SameSite cookie">
                       <match serverVariable="RESPONSE_Set_Cookie" pattern=".*" negate="false" />
                       <action type="Rewrite" value="{R:0}; SameSite=strict" />
                       <conditions>
                       </conditions>
               </rule>
               <preConditions>
                   <preCondition name="Not SameSite cookie">
                       <add input="{RESPONSE_Set_Cookie}" pattern="." />
                       <add input="{RESPONSE_Set_Cookie}" pattern="; SameSite=strict" negate="true" />
                   </preCondition>
               </preConditions>
           </outboundRules>
       </rewrite>
   </system.webServer>
   

2. Save, clear your cookie store, and carefully test your changes.

Rewriting the Cookie Path

If you wish to configure the cookie path, such that the cookie header is returned only when the requested URL includes the specified path (or sub-directories thereof), you can use a similar rewrite method. For example, if you have configured FlexNet Manager in a unique sub-path within the domain, you should ensure that the sub-path is present in the cookie Path attribute. This rewrite method achieves that result, switching the path from the default root (/) to /foo (substitute your own value appropriately).

1. In the web.config file for your [web] application server, insert the following:

   <configuration>
       <system.webServer>
           <rewrite>
               <outboundRules>
                   <rule name="Replace Cookie Path">
                       <match serverVariable="RESPONSE_Set_Cookie" pattern="^(.*; path=/)(.*)$" />
                       <conditions />
                       <action type="Rewrite" value="{R:1}foo{R:2}" />
                   </rule>
               </outboundRules>
           </rewrite>
       </system.webServer>
   </configuration>
   

2. Save, clear your cookie store, and carefully test your changes.

Additional Information

You can find Microsoft documentation on using rewrite rules to modify headers here: https://docs.microsoft.com/en-us/iis/extensions/url-rewrite-module/url-rewrite-module-20-configuration-reference#Setting_Response_Headers

There are many recommendations for IIS security that are not specific to FlexNet Manager Suite:

• Don’t enable modules you do not need
• Ensure IIS is patched and up-to-date
• Apply dynamic IP restriction
• Locate the Inetpub folder in a directory hierarchy different from your system installation
• Ensure appropriate logging configuration
• Use penetration testing tools and services to verify installation security.

These are generic good practices, not specific to FlexNet Manager Suite in any way, and are well-described elsewhere.

This article is by no means a complete guide to IIS configuration, and you should consult other sources to ensure that your configuration is appropriate to the needs of your organization.