Hi,

I would also be interested in an answer to this question.

In my case DNN is running under the Application Pool account, eg. IIS AppPool\DnnAppPool. When I run the security advisor, I get the warning above, e.g. for the root of the system drive (C:\ - Read:Y, Write:Y, Create:Y, Delete:N).

When I use Windows Explorer to check the effective permissions of the user IIS AppPool\DnnAppPool for the root folder of C:, I get red Xs for all permissions - which I interpret as nothing is allowed.

Anyway, if read, create and write would be allowed, but delete would be forbidden, I should find some leftovers from the test, as I guess the test should try to create a file (with a success result), and then try to delete it (with an error). But then the file should be there, but I cant see anything...

Confusion...

Happy DNNing!
Michael

 

Michael,

Instead of creating a file, couldn't DNN just be reading the permissions for the directories? 

Zyxian

Could be, I haven't inspected the source code yet. But the permissions in Windows Explorer give no results for that folder, that is what confuses me a bit...

Happy DNNing!
Michael

Posted By Michael Tobisch on 12 Dec 2019 06:16 AM

Hi,

I would also be interested in an answer to this question.

In my case DNN is running under the Application Pool account, eg. IIS AppPool\DnnAppPool. When I run the security advisor, I get the warning above, e.g. for the root of the system drive (C:\ - Read:Y, Write:Y, Create:Y, Delete:N).

When I use Windows Explorer to check the effective permissions of the user IIS AppPool\DnnAppPool for the root folder of C:, I get red Xs for all permissions - which I interpret as nothing is allowed.

Anyway, if read, create and write would be allowed, but delete would be forbidden, I should find some leftovers from the test, as I guess the test should try to create a file (with a success result), and then try to delete it (with an error). But then the file should be there, but I cant see anything...

Confusion...

Happy DNNing!
Michael

 

The test does not really write files, it reads what .net reports.
The AppPool user is also a user in windows and most of these acccess warning are because the "Users group" has access.
I did create a testpage some years ago, that does try to write and in many cases the security analyser was right.

But there's a big diffrence between windows server and windows 10 professional.
I was not able to reproduce the results of my the tests on my local machine, on win 2012.
Win 2012 blocked a lot more access than professional.

 

 

Timo and me spend at least a day on this issue last year I think?

Well - are there any recipes on how to get rid of these warnings? (I don't care for Windows 10, but at least for Windows Server 2012+).

I tried once to revoke rights mentioned in the security advisor with the effect that nothing did work anymore (as eg writes to temp folders were forbidden, and this was because of inheritance).

So what exactly has to be done?

Happy DNNing!
Michael

A setup for my Blog post, feel free to comment :-)

Securing your IIS website

First of all this is about Windows Server NTFS security and any .net website, not specifically for DNN security. The “security issue” described below will be the same for any IIS website, not only for DNN.

I think I was not alone in the assumption that using Apppool identities for an IIS website would make sure that even when a site is hacked, the hacker cannot access anything outside the folder containing the website.

This should be the major advantage over using a general user account like NETWORKUSER or IUSR.

The first time I installed the DNN security analyzer it reported potential access to all kind of folders.As most of us I thought, the analyzer was wrong.

After some research I found out that the DNN Security Analyzer is correct.

I created a simple aspx page that actually tries to write outside the website folder and it succeeded.
But there are also differences between a desktop and server.
On the desktop I was even able to start an executable, on the server this failed, so there are security differences between the two.
 

My conclusion

I concluded that on a default Windows server (2012) setup, only using Apppool users is not enough to prevent access outside the website’s folder.

The reason for this is that your Apppool user, although a “virtual user” is still a Windows User and thus part of the “Users” group.

The Users Group by default has Read and Execute NTFS rights, which is why DNN reports access to other folders.

This means that when you want to make sure a website (being hacked or even as a DNN host user) cannot access other folders, you have to remove the NTFS rights for the “User group” on the drive or folder your site resides in.

Even when you place your site on a separate drive you will see that there’s some access to the C: drive.

Apparently this is “by design” (MS) as the Apppool user needs access to some folder on the C drive (for temp files etc). We tried removing / deny the Users group rights on the C drives root in a Virtual Machine, but that crashed the sites. (this seems to have changed in Win 2016)
 

Setting NTFS Rights.

Please make sure you do exactly what is described below and make a backup as it’s quite easy to lock yourself out or crash your website.

I will use “Root” for the root folder or the drive where the website is located.

This can be either the Inetpub folder on C: or in my example the D:\ drive.

 

Preparations.

1.    Make a backup of your machine as you could lock yourself out if you make a mistake or forget something.
2.    Use a dedicated Apppool user for your website
3.    Make sure the Apppool user has Modify rights on the folder where the websites file reside.

 

Anonymous authentication:

By default IIS serves static files IUSR user.

You need to change that or you will end up with a site without images and style sheets

1.    In IIS manager, under IIS > Authentication
2.    Select “Anonymous Authentication” and click edit on the right
3.    Select “Apppool Identity”
4.    Click OK

NTFS Rights for databases:

When your database files are placed in the same folder structure as the files of the website, you need to set NTFS rights for those too, if not, you can skip this step.

You need to give the process SQL server runs with (On my machine  MSSQL$SQLEXPRESS) at least read rights to the Database folder.

Although MSSQL sets the NTFS rights when it attaches a database, it does need initial read rights to see the Database to attach. Before this change it relied on the Users group having read rights, but you are going to remove them.

1.    Give the MSSQL user read rights to the “root”.
2.    Go to the actual folder the DB files are located and give the MSSQL user Modify rights on the files. (These have been overwritten by inheriting the rights on the root)

Other users Rights

3.    Make sure Administrators have at least modify rights.
4.    Make sure “everyone” is not listed, if it is, remove the Group.
5.    Remove the Rights for the Users group on the “root”.
6.    Test your website and make sure it’s running correctly.

There are a few things to take into account after removing the “Users” group NTFS rights from the “Root”.

1.    Your backup script / program might rely on this for access, so you should check your backups.
2.    Make sure there are no other process that rely on the access though the “Users” group NTFS rights.
3.    You should repeat this for any other extra partition / drive on your machine, especially backup drives, to avoid a hacker being able to access your backups.

Looks about right. In my situation I tried a lot of setups that all failed one way on the other, as you mention backup programs, etc. What really allowed me to get it right was removing inheritance on the folder that contained all the individual subfolders for each site/client.

When doing so (and when doing other stuff that need to rewrite metadata on all childrens) it may appear to take forever, but do not interupt it or you will end up with inconsistent settings all over the place, be patient and let that process finish :)

Posted By Timo Breumelhof on 19 Dec 2019 03:34 AM

A setup for my Blog post, feel free to comment :-)

Securing your IIS website

First of all this is about Windows Server NTFS security and any .net website, not specifically for DNN security. The “security issue” described below will be the same for any IIS website, not only for DNN.

I think I was not alone in the assumption that using Apppool identities for an IIS website would make sure that even when a site is hacked, the hacker cannot access anything outside the folder containing the website.

This should be the major advantage over using a general user account like NETWORKUSER or IUSR.

The first time I installed the DNN security analyzer it reported potential access to all kind of folders.As most of us I thought, the analyzer was wrong.

After some research I found out that the DNN Security Analyzer is correct.

I created a simple aspx page that actually tries to write outside the website folder and it succeeded.
But there are also differences between a desktop and server.
On the desktop I was even able to start an executable, on the server this failed, so there are security differences between the two.
 

My conclusion

I concluded that on a default Windows server (2012) setup, only using Apppool users is not enough to prevent access outside the website’s folder.

The reason for this is that your Apppool user, although a “virtual user” is still a Windows User and thus part of the “Users” group.

The Users Group by default has Read and Execute NTFS rights, which is why DNN reports access to other folders.

This means that when you want to make sure a website (being hacked or even as a DNN host user) cannot access other folders, you have to remove the NTFS rights for the “User group” on the drive or folder your site resides in.

Even when you place your site on a separate drive you will see that there’s some access to the C: drive.

Apparently this is “by design” (MS) as the Apppool user needs access to some folder on the C drive (for temp files etc). We tried removing / deny the Users group rights on the C drives root in a Virtual Machine, but that crashed the sites. (this seems to have changed in Win 2016)
 

Setting NTFS Rights.

Please make sure you do exactly what is described below and make a backup as it’s quite easy to lock yourself out or crash your website.

I will use “Root” for the root folder or the drive where the website is located.

This can be either the Inetpub folder on C: or in my example the D:\ drive.

 

Preparations.

1.    Make a backup of your machine as you could lock yourself out if you make a mistake or forget something.
2.    Use a dedicated Apppool user for your website
3.    Make sure the Apppool user has Modify rights on the folder where the websites file reside.

 

Anonymous authentication:

By default IIS serves static files IUSR user.

You need to change that or you will end up with a site without images and style sheets

1.    In IIS manager, under IIS > Authentication
2.    Select “Anonymous Authentication” and click edit on the right
3.    Select “Apppool Identity”
4.    Click OK

NTFS Rights for databases:

When your database files are placed in the same folder structure as the files of the website, you need to set NTFS rights for those too, if not, you can skip this step.

You need to give the process SQL server runs with (On my machine  MSSQL$SQLEXPRESS) at least read rights to the Database folder.

Although MSSQL sets the NTFS rights when it attaches a database, it does need initial read rights to see the Database to attach. Before this change it relied on the Users group having read rights, but you are going to remove them.

1.    Give the MSSQL user read rights to the “root”.
2.    Go to the actual folder the DB files are located and give the MSSQL user Modify rights on the files. (These have been overwritten by inheriting the rights on the root)

Other users Rights

3.    Make sure Administrators have at least modify rights.
4.    Make sure “everyone” is not listed, if it is, remove the Group.
5.    Remove the Rights for the Users group on the “root”.
6.    Test your website and make sure it’s running correctly.

There are a few things to take into account after removing the “Users” group NTFS rights from the “Root”.

1.    Your backup script / program might rely on this for access, so you should check your backups.
2.    Make sure there are no other process that rely on the access though the “Users” group NTFS rights.
3.    You should repeat this for any other extra partition / drive on your machine, especially backup drives, to avoid a hacker being able to access your backups.

Is this also possible with windows server 2016 ?