How to Secure a Site in IIS

Reading Time: 6 minutes

When investigating site infections or defacing on a Windows Servers, the most common root cause is poor file security or poor configuration choices when it comes to how IIS should access file content.  The easiest way to prevent this is to start with a secure site.

Setting up a website in IIS is exceedingly easy, but several of the default settings are not optimum when it comes to security or ease of management.  Further, some practices that used to be considered necessary or standards are no longer or were never necessary, to begin with. As such, we recommend that you follow these steps to set up a website to ensure that it is set up correctly and securely. And while some of these setting or permission changes may seem nitpicky, they go a long way on systems that host multiple domains or multiple tenants as they prevent any cross-site file access.

 

Add the Site to IIS

To add a website in IIS (Internet Information Services),  open up the IIS manager, right-click on Sites, and select Add Website.When adding a site to IIS, we typically recommend using the domain name as the “Site name” for easy identification.  Next, under “Physical path”, you will need to supply the path to where your website content is located or use the “” to navigate to and select the folder.  Configuration options under “Connect as…” and “Test Settings…” do not need to be modified.

When it comes to configuring site bindings, popular belief suggests that you should select a specific IP from the “IP address” drop dropdown; however, that is based on out of date practices typically in relation to how SSLs used to require dedicated IPs.  This is no longer necessary and can actually cause issues when getting into any eplicated or highly available configuration, so it is best to leave IP addresses set to All Unassigned and type the domain name you plan to host in the “Host name” field. Do note that you can only supply one value here; additional host names can be added after creating the site by right-clicking on the site and going to Bindings.  Further, depending on your needs, you may opt to select “https” instead of “http”. To host a site with an SSL, please visit our article on the subject after setting up the site to add an SSL and configure it.

 

Set the Anonymous User

Technically that is all you need to do to set up a site in IIS; however, the site may or may not work, and the security settings on the site are not optimum. The next step in securing your site is to configure the IIS user that will access your files. To do this, you will need to change the associated Anonymous user and make a few security changes on the website’s content folder.

In IIS, select your new site on the left, in the main window double click on Authentication, select Anonymous Authentication, and then click “Edit…” on the right action bar.

 

What is IUSR in IIS?

By default, a new site in IIS utilizes the IUSR account for accessing files.  This account is a built-in shared account typically used by IIS to access file content. This means that it will use the application pool’s identity (user) to access file content.

It may be okay to leave this configured if you only plan on hosting one domain; however, when it comes to hosting multiple domains, this is not secure as it would then be possible for any site using the same account to access files from another site.  As such, and as a standard practice, we recommend switching away from using the IUSR account for sites, and instead selecting “Application pool identity” and clicking OK. Alternately, you could manually create a user on the system for each site; however, then you need to manage credentials for an additional user, need to configure permissions for two users (the anonymous user and the application pool user) and possible complications with password complexity and rotation requirements your server or organization may have.

There is nothing further you need to configure in IIS in terms of security; however, for reference, let’s take a look at the application pool settings really quick.  To check the settings on the application pool, in IIS, select Application Pools on the left menu, select the application pool for the site you created (typically the same name as the name of the site), and then click “Advanced Settings…” on the right action bar.

In here, the related setting is the identity, which by default is “ApplicationPoolIdentity”.  This means to access file content, IIS and the associated application pool will use a hidden, dynamic user based off the name of the application pool to access files.  This user has no associated password, can only be used by IIS, and only has access to files specifically granted to it. As such, it removes the requirement of managing system users and credentials.

 

Set Folder Permissions in IIS

Now, as mentioned, the “ApplicationPoolIdentity” user has very few permissions, so the next and last step is to ensure that the website files have proper security settings set on them. Browse through your file system and find the folder where you plan on hosting your site’s files. Right-click on the folder and go to properties. In the properties interface, select the Security tab.

By default, there are a number of security permissions set up on the folder that are unnecessary and potentially insecure (there may be more than shown here).  To best secure a site, we recommend removing all but the “SYSTEM” and “Administrators” groups and adding the “ApplicationPoolIdentity” user (and possibly any other user you may require, such as an FTP user); however, to do this, you will need to disable inheritance.  To do this, click on “Advanced”, then click on “Disable inheritance”.

 

Here you will get a popup asking if you want to copy the current settings or start with no settings.  Either option can work; however, it is easier to copy the current settings and then remove the unnecessary permissions.  So select “ConvertConcert inherited permissions into explicit permission on this object” and then click OK.

At this point, to remove the unnecessary permissions, click Edit and remove everything other than the “SYSTEM” and “Administrators” groups.  Next, you need to add the “ApplicationPoolIdentity” user to this folder. To do this, click “Add…”. Now, depending on your server configuration, you may get a pop-up asking for you to authenticate to an active directory domain.  Simply click the cancel button a few times until you get the Select Users of Groups screen shown below.

On this screen, you will want to make sure that the “Location” selected is your computer.  If it is not, click “Locations…” and select your computer (should be at the top; you may also need to click cancel on some authentication windows here as well).

The “ApplicationPoolIdentity” user is a hidden user, so it is not possible to search for this user.  As such, you will have to type the username to add it. The username you will need to type is “IIS AppPool\<applicationpoolname>“.  Please see the following example and fill yours out accordingly:

Once you type the user name, click OK.  Now that you’ve added the user, which is by default only granted read permissions, you will want to verify your security settings look similar to the following image, and then click OK.

And with that, you’re done and have a secure site ready to be viewed by the masses without needing to fear that hackers will deface it.

 

Securing within Powershell

As a bonus, if you’re looking to get your fingers wet with some Powershell, the steps covered in this article can also be accomplished on a Windows Server 2012 or newer server through Powershell.  Simply fill out the first two variables with your domain name and the path to your content, and then run the rest of the PowerShell commands to set up the site in IIS and configure folder permissions.

[String]$Domain = ‘<domain_Name>’

[String]$Root = ‘<path_to_your_content>’

Import-Module WebAdministration

#Create App pool & Website
New-WebAppPool -Name $Domain
New-Website -Name $Domain -HostHeader $Domain -PhysicalPath $Root -ApplicationPool $Domain
Set-WebConfigurationProperty -Filter system.webServer/security/authentication/anonymousAuthentication -Location $Domain -PSPath MACHINE/WEBROOT/APPHOST -Name userName -Value ''

#Optionally add www. Binding
New-WebBinding -Name $Domain -HostHeader www.$Domain -ErrorAction

#Remove inheritance (copy)
$ACL = Get-ACL $Root
$ACL.SetAccessRuleProtection($True,$True) | Out-Null
$ACL.Access | ?{ !(($_.IdentityReference -eq 'NT AUTHORITY\SYSTEM') -or ($_.IdentityReference -eq 'BUILTIN\Administrators')) } | %{ $ACL.RemoveAccessRule( $_ ) } | Out-Null
$ACL | Set-ACL

#Add IIS user permissions
$ACL = Get-ACL $Root
$acl.SetAccessRuleProtection($False, $True)
$Rule = New-Object System.Security.AccessControl.FileSystemAccessRule("IIS AppPool\$Domain", "ReadAndExecute", "ContainerInherit, ObjectInherit", "None", "Allow")
$acl.AddAccessRule($Rule)
$acl | Set-Acl

Additional Notes: In some cases, sites may need additional write or modify permissions on specific files or folders for file uploads, cache files, or other content.  It is important that you do not apply modified permissions to the entire site. Instead, modify specific directories or files as needed. To apply these settings, go to the file or folder that needs modification, right-click on it, and select Properties.  Switch to the Security tab and click Edit. In there, select the user that has the name of the website (liquidweb.com in my example above), select modify under the Allow column, and then click OK. This will give the ApplicationPoolIdentity and IIS the ability to write to or modify the file(s) or folder(s).

Still need additional protection for your Liquid Web server?  Our Server Protection packages provides a suite of security tools especially for Windows servers.  You’ll get routine vulnerability scans, hardened server configurations, anti-Virus and even malware cleanup, should your site get hacked. Don’t wait another vunerable minute, check out how we can protect you.

 

Malicious Activity Detector (MAD) for Windows

Reading Time: 3 minutes

One of the simplest goals of server security is keeping administrator credentials private. There is no better way to achieve this than through strict firewall rules that only allows specific IPs to authenticate. However, there are some situations where it is necessary to open a login prompt to the broader Internet. In this case, the only thing barring anonymous internet users from unauthorized access is your password. The stronger your password, the better off you are, but even the most cryptic passwords can be guessed given enough tries.

Malicious Activity Detector (MAD) helps protect you in these instances. It functions by monitoring login attempts to several services, and if it detects malicious activity, it applies a temporary block on that IP. If more attempts come in, the block continues to last longer. This method is exceptionally effective in preventing a successful brute-force attack while limiting the number of system resources expended.

 

Installation of MAD

Depending on the configuration and age of your server, you may already have it installed. Check the installation status by looking for an item in your Start Menu shown below.

Installing Liquid Web's Malicious Activity Detector for Windows tightens security for you server.

The program path is C:\Program Files (x86)\Liquid Web\MAD\MADGUI.exe

You may also check if “MAD.exe” is running from your Task Manager. If you don’t see it there, please Contact Support so that we may get it up and running for you. Once running,  we can move on to the configuration.

Note:
MAD will be installed on all Windows servers by default in the future.

 

Configuring MAD

MAD’s default settings offer protection for the most vulnerable services, and extra configuration is not required. That said, you may find yourself wanting to change its behavior, and we’re happy to give you the tools you need.

Let’s start with the most common change you may want to make: whitelisting and blacklisting. Opening the MAD Configure utility will get you on the right page. From here, you only need to choose the radio button for the list you want to modify, enter the IP, and click the button. You can remove entries in either list by right-clicking. This page also allows you to start or restart the service, but you shouldn’t need to use those functions.

The List tab easily let's you add in blacklisted or whitelisted IPs.

The next page is where most options are located. All of the service scanners list three choices for each: Enabled/Disabled, BlockThreshold, and Retention.

Our Malicious Activity Detector allows you to adjust settings for maximum security.

Enabled/Disabled -You may want to disable scanners for services that you do not have installed, but it is generally recommended to leave all options enabled due to minimal performance cost.

BlockThreshold – This setting controls how many ‘strikes’ it takes to be blocked. These are set fairly high by default to avoid affecting legitimate users, but you may want to lower the threshold to increase MAD’s sensitivity.

Retention -This refers to the size of the window that MAD looks at to determine if a user has met the BlockThreshold in seconds. By default, this is set to 300 (five minutes).

Example:
Set your BlockThreshold to 10 and your Retention to 300. If 9 failed attempts occurred at 12:00 and a failed attempt occurs before 12:05 it will be blocked. By 12:06 you will be in a new period and will be able to attempt 9 more times before being blocked.

PermaBlock – Sometimes robots can’t take the hint after being temporarily blocked several times in a row. The PermaBlock list remedies this situation. By default the retention period is 2 hours, this scanner checks for IPs that have been temp blocked five times (or your custom BlockThreshold). If it gets a hit, it does as the name implies and adds it to your blacklist, where it is managed much like manual entries.

AuditPolicy – This setting determines if MAD is allowed to edit your login event auditing policy. Disabling AuditPolicy is not recommended and may prevent MAD from working as intended.

TempBlockTimeout -When a block is triggered on one of the scanners the offending IP address will be blocked for this amount of time. Measured in seconds with a default setting of 900 (15 minutes).

 

Reviewing MAD Logs

MAD creates logs of all of the actions that it takes. It is good practice to review them regularly to see what has been going on. For example, if a certain service seems to be getting attacked more often than others you may want to consider hardening your firewall rules or MAD’s configuration itself.

Our Malicious Activity Detector keeps logs of anyone attempting to connect to your Windows server.

MAD also creates events in Windows Event Viewer under the ‘Applications and Services Logs’ folder. These events are most helpful for long-term investigation, as the folder will hold historical data for quite some time.

MAD also creates Events for long-term investigation, as the folder will hold historical data.

MAD for Windows is an excellent tool in your security arsenal, but a proactive plan is always better than a reactive one. We recommend utilizing Windows Firewall to ensure that only things that must be publicly accessible are. For further reading on security visit some of our other articles:

Security for Remote Desktop
Best Practices for Your Firewall

Malware – How to Detect and Remove

Reading Time: 2 minutes

Maldet, a free popular malware scanning software for Linux servers, can be used to scan an entire server for potentially malicious files. Properly configured and monitored, it can even be used to disable or fully remove malware when it is detected. However, the removal of files should only be configured once you are certain no false positives will be picked up in the scans.

 

How to Install Maldet

To Install Maldet on your linux server copy and paste the following into the command lines. Maldet will then be pre-scheduled to run daily.

pushd /usr/local/src/
rm -vrf /usr/local/src/maldetect-*
rm -vrf /usr/local/src/linux-malware-detect*
wget http://www.rfxn.com/downloads/maldetect-current.tar.gz
tar -zxvf maldetect-current.tar.gz
cd maldetect-*
sh ./install.sh
maldet --update-ver
#sed patch - commands added to address current problem with maldet overriding values in the conf file
sed -i 's/quarantine_hits=\"1\"/quarantine_hits=\"0\"/' /usr/local/maldetect/conf.maldet
sed -i 's/quarantine_clean=\"1\"/quarantine_clean=\"0\"/' /usr/local/maldetect/conf.maldet
sed -i 's/email_alert=\"1\"/email_alert=\"0\"/' /usr/local/maldetect/conf.maldet
sed -i 's/email_addr=\"you@domain.com\"/email_addr=\"\"/' /usr/local/maldetect/conf.maldet
#end sed patch
maldet --update
if [ -e /usr/local/cpanel/3rdparty/bin/clamscan ] then
ln -s /usr/local/cpanel/3rdparty/bin/clamscan /usr/bin/clamscan
ln -s /usr/local/cpanel/3rdparty/bin/freshclam /usr/bin/freshclam
if [ ! -d /var/lib/clamav ] then mkdir /var/lib/clamav
fi
ln -s /usr/local/cpanel/3rdparty/share/clamav/main.cld /var/lib/clamav/main.cld
ln -s /usr/local/cpanel/3rdparty/share/clamav/daily.cld /var/lib/clamav/daily.cld
ln -s /usr/local/cpanel/3rdparty/share/clamav/bytecode.cld /var/lib/clamav/bytecode.cld
else
echo -e "\n\e[31mClamAV does not appear to be installed through cPanel.\nThe ClamAV definitions will not be used.\e[39m\n"
fi
Popd

Scanning for Malware

Once you have completed the installation you will want to configure the scanning process. The configuration for maldet is located /usr/local/maldetect/conf.maldet. You will want to open the file with your favorite text editor such as vim or nano:

vim /usr/local/maldetect/conf.maldet
Once you are editing the file you will want to add your email address between the “ “ on the line email_addr=,  like so email_addr=“myemail@mydomain.tld”

You can also set up the scan to quarantine the malicious files it finds by changing the line quarantine_hits= from “0” to “1”, it should look like quarantine_hits=“1”. I would advise against this option as it can pick up legitimate code mistakenly. If the scan does mistakenly place a legitimate file into quarantine, you will need to move it back into place by using the following command template, replacing SCANID with the proper scan ID reported by maldet:

Maldet --restore {SCANID}
Once you have run the scan with quarantines for some time and you are confident that no safe files are being picked up, you may want to turn on removal of quarantined files in the same configuration /usr/local/maldetect/conf.maldet at the line quarantine_clean= from “0” to “1” , it should look like quarantine_clean=”1”. I would personally avoid this configuration option as it can always pick up new edits mistakenly and destroy your hard work.

Looking for pre-configured protection for servers and websites? Check out our wide security offerings that are sure to fit any of your security concerns!