I had a partner call me the other day and ask if Cireson had a “Hardening Guide” for our SCSM Self-Service and Analyst portals.
This is not a frequent request as it is usually only government or Defence industries that lock down their system to this extent. So it was no surprise that we had never been asked this question before. After much back and forth we were able to put together a hardening guide for our portal and I thought I would share with you all what that looks like and how to achieve it for the rare occasion that this level of security is required.
Some Basic IIS Hardening Details
Within IIS it is possible to restrict the type of file extensions that can be executed within IIS and also what “Verbs” (Core IIS Code commands) that are allowed to be called.
This reduces the exposure of what type of code can be executed and therefore reduces the ability of an attacker to execute malicious code. It is never possible to remove all possible attack surfaces from any internet server as it must execute some code or the web page would never be rendered! Instead, hardening IIS is about just reducing the types of code that can be executed so we are only concerned with what we need and not with surplus to requirement code types.
IIS allows us to do this by restricting the file extensions of the type of code we want to allow.
This is done in the “Request Filtering” section of our website within IIS.
This allows us to filter by file extension, URL, Verbs, headers and several more.
For the purpose of this article we are going to be very generic and only allow specific extensions to be run. In a higher security model it may be required to block anything outside of very specific file names, dates, URL’s etc. but in my opinion, if you need to lock down your web server that far, then it shouldn’t be on the web. 🙂
The file Extension tab shows a bunch of pre-defined file extensions and if they are allowed or blocked. One other setting that is not shown on the main screen is the File Name Extension settings.
This has some generic rules like “Allow unlisted file extensions” which is turned on by default. This basically says, if the file extension has not been specifically blocked then let it run.
You can see where this can be a bad thing….
Basic Hardening Rules
The rules can be administered from the IIS GUI or directly from the configuration files within the web page.
Using the GUI, our first requirement is to disable unlisted file extensions from running. This is as simple as unchecking the checkbox within the “Edit Request Filtering Settings” screen inside the IIS website we are editing.
After this, we need to add the following list of extensions as allowed extensions.
Yes, there is an extension of just .
This is to allow pages without any extension whatsoever to run. This is common as the IIS server will render the code in back ground and the present the page with no extension. NOTE: This is not the same as *.* that will allow ALL extensions to run, this simply allows pages with no extension to be shown.
All these settings are stored within the Web.config file on the file system and that gives advanced admins a faster way to do this than via the GUI.
Using the Web.config file, open the file in a XML editor of choice (Notepad or Notepad++ for example) and search for the <Security> section with the file.
Replace the default settings with the following section.
<requestLimits maxAllowedContentLength=”1073741824″ />
<add fileExtension=”.” allowed=”true” />
<add fileExtension=”.js” allowed=”true” />
<add fileExtension=”.svg” allowed=”true” />
<add fileExtension=”.css” allowed=”true” />
<add fileExtension=”.ttf” allowed=”true” />
<add fileExtension=”.png” allowed=”true” />
<add fileExtension=”.gif” allowed=”true” />
<add fileExtension=”.woff” allowed=”true” />
<add fileExtension=”.html” allowed=”true” />
And that’s it.
So if you ever come across the requirement to “Harden” your web pages, this should help you.
I had a rather interesting question the other day about hiding unwanted types of search form the Cireson Portals page search feature located at the top of the Cireson Portal.
The user was trying to remove the option for Knowledge Management as they are not currently using it within their environment.
At first the solution seems easy and that is to find the element in CSS and set it to hidden for that Index.
However, as it turns out, the list items are generate at build time and depending on if you are an analyst or an end user the index value of the list item will change. Hiding Knowledge Management for Analysts hides Service Catalog for End Users or hiding Knowledge Management for End Users hides Work Items for analysts.
So how do we fix this with CSS?
Answer? We don’t….. We use Java Script instead.
By copying the following code in to the Custom.js file located int he Custom Space of the Cireson portal (Default location: C:\inetpub\CiresonPortal\CustomSpace)
/* Hide knowledge articles from all users, based on static “Knowledge Base” text. */
This code looks for the dropdown menu that contains a list item labeled “Knowledge Base” it will hide the list item.
By changing out the text in bold with the list name you wish to hide (Work Items or Request Offerings) you can hide these menu items too.
The end result, the search item list no longer has Knowledge Base available to search on.