Securing SF Admin area

To date, it's been really hard to get any clear solution on how to secure the SF-5.x Admin area for a site published on the Web.

I've tried a number of solutions, but nothing has worked so far, and Telerik have been particularly vague as to how it could be done.

However, I notice that this site (now based on SF-5x) has a secured admin area.

i.e. www.sitefinity.com/sitefinity  returns a 403 access denied.

Would Telerik like to detail how they are doing this ?

I would really like to know the answer to this as well.  

But, one thing I would like to add, is this done through Sitefinity or IIS?

I have been playing around with an idea to use a URL Rewrite Rule to accomplish this, but if Sitefinity already has this capability already built in that would save some time.

Telerik, please let us know what you did to accomplish this task.

Just bumping this again, as I'd quite like to see a blog on how the admin area of this site is being secured.

I know that simple IIS IP white-listing doesn't work (been there tried that) and whenever I have tried to create IIS rewrite rules to secure it, I always end up with the whole site being 401'd, because it seems to clash with other rewrite rules I use.

Leaving the admin login open to the internet makes me *very* nervous.

Hi guys.
I found such great user posts in this forum that though I'd share what we did to secure the admin site (in SF 5.2 on IIS 7).  Here is what worked for us - it may be different for your setup, but you will get a good starting point.

PART A - Using IIS Configuration tool
1. In IIS, expand your site, and highlight the /Sitefinity folder.
2. From the rigth pane, select the "IPv4 Address and Domain Restrictions" feature and restrict to a given list of IP addresses, or to a complete network.  This is to ensure you only "allow" access to these, denying to all the rest.  If you need instructions on how to use this feature, please google for it as there are many well documented article that will give better info that what I could write.
3. Make sure you give "allow" rights to everybody to the folder "/Sitefinity/Public" as there are other files that are necessary for all.
PART B - Using text editor
Once the /Sitefinity folder is restricted, we used fiddler to identify other files that are now giving a 403 error - they are all in the "/Sitefinity/WebsiteTemplates" folder.
1. Make a backup copy of the file : C:\Windows\System32\inetsrv\config\applicationHost.config
2. In a plain text editor, open the above file and go to the end
3. You will find a section that starts with
<location path="yoursiteDomainName/Sitefinity">  This is the section you will complement that you could not do from the GUI.  Here is what you need to add:
 <location path="yourSiteDomainName/Sitefinity/WebsiteTemplates">
  <system.webServer>
   <security>
    <ipSecurity allowUnlisted="true" />
   </security>
  </system.webServer>
 </location>

...in the end, you should have a complete section which ressembles this :
<location path="yourSiteDomainName/Sitefinity">
    <system.webServer>
        <security>
            <ipSecurity allowUnlisted="false">
    <add ipAddress="127.0.0.1" allowed="true" />  <!--Strongly suggested to allow local access to the admin site-->
    <add ipAddress="xxx.xxx.xxx.xxx" allowed="true" /> 
    (...) <!--list of restrictions you made from the GUI -->
   </ipSecurity>
        </security>
    </system.webServer>
</location>
<location path="yourSiteDomainName/Sitefinity/WebsiteTemplates"> <!--Allows access for all to the WebSiteTemplates folder-->
 <system.webServer>
  <security>
   <ipSecurity allowUnlisted="true" />
  </security>
 </system.webServer>
</location>
<location path="yourSiteDomainName/Sitefinity/Public">  <!--Allows access for all to the Public folder-->
 <system.webServer>
  <security>
   <ipSecurity allowUnlisted="true" />
  </security>
 </system.webServer>
</location>

Voilà!
Hope this helps!

Yes. We would like to get an answer to this question from sitefinity team as well.
It is very easy to find out that the website is driven by sitefinity CMS, and knowing that you can get to admin login screen.
We should be able to hide/change the path to Admin area as well as to forbid the access to it. Also, Login page if required should be able to use https protocol as well.

Regards,

@Oliver

Thanks for that, but as you point out, unlike V3, V4/5 is not designed with simple IP white-listing  of the Sitefinity folder in mind, and the overwhelming majority of your solution is dealing with that very limitation.

I'm pretty sure there is a cleaner solution to this, using the IIS URL rewrite module, but I haven't managed to get it working yet. I have existing re-write rules to manage SEO requirements, and when I add in rules to secure the Sitefinity back-end (which should be possible) it 401's the entire site.

However, it would appear that Telerik have it working on this site, so perhaps they could share their solution.

Hi MB.
I am not exactly sure what you mean about v4/5 note being designed for simple IP white-listing. 
The solution I described in this thread works perfectly - or ate least until someone proves me wrong - and it is on a V5 solution. 
Have you tried for yourself to block the SiteFinity folder through IP restriction and then manually add "allow" rules to the file?  Remember to also add an allow rule to the /Sitefinity/Public folder.

If someone else tries my solution, please give us some feedback on the results.

What I mean is that with V3 there were 3 (from memory) files/folders that you specifically blocked with IP whitelisting, and you were done.

Telerik are on record (I can't recall the thread) as saying that IP whitelisting V4/5 is basically impossible, because they use the /Sitefinity folder to route services and handlers.

They are also on record as saying it can be done using the IIS URL rewriter to block the authentication page, but haven't provided an example of that solution.

While I don't doubt your solution, the problem I see with needing to create an exception list for a blanket block on the entire sitefinity folder, is that it's prone to being broken as Telerik add new services, or as your customers re-configure their active modules, etc.

OK - I see now what you mean.
When I asked the tech support, they told me that if I white listed the /Sitefinity folder, I had to move all my CSS and images out of the /app_data/Sitefinity folder because this was linked behind the scene to the /Sitefinity path and it would block these.  This is because you can't get to this fine detail through the GUI.
The fact that you manually add rules to the config file allows you to go around this GUI limitation.  This is how we were able to add "allow" rule to the template folder and make it work.
Again, I don't say that my solution is bullet proof, but in my case, with many widgets and master pages we developped inhouse, it works great.
In doubt, use the GUI to block /Sitefinity, and allow /Sitefinity/Public.  Then manually add the rules to the Template folder (remember that /App_Data/Sitefinity/WebSiteTemplates is converted to http://domain.com/Sitefinity/WebSiteTemplate at runtime).   Then, use a tool such as Fiddler to find out which parts need to be manually added for "allow" rules.  It was dirt simple in our case - maybe on some other setup it will be tedious, but the allow/block rules work well in our case.

If someone finds a better solution, please let us all know - I am open to anything that will make my work easier and keeping my stuff secured :)

BTW, I don't see how rewrite rules could prevent certain people from accessing the secured portion of your site, but would allow others to do so...maybe I am missing something?  Can rewrite rules be based on the requestor's IP?  I haven't played much with rewrite - others in my team took this part :)

Cheers!

@Oliver:

"BTW, I don't see how rewrite rules could prevent certain people from accessing the secured portion of your site, but would allow others to do so...maybe I am missing something?  Can rewrite rules be based on the requestor's IP?"

Yes, you can create a rewrite-map for your IP whitelist, and then apply it to your rewrite rules.

I've done some more work on this, and I seem to have it basically working so far... however, I haven't done any extensive testing and am unsure if this is sufficient to secure admin access. 

Feel free to test it and see if you can improve.

Basically, I created a rewriteMap as my IP WhiteList, and gave each entry the same value of 1

I then run a test for any request of the Sitefinity authentication page, to see if REMOTE_ADDR matches one of the entries in the whitelist map, and actions a 403 if no match, but of course, you could choose to take alternative action, such as redirecting to the site's home page.

Note: Obviously, this assumes that the IIS rewrite module is installed.

Can we create new directory like /NewDirectory instead of /Sitefinity as part of securing backend login ,