This article offers general best practices & guidance to help you secure your InstantForum community.
We recognize communities are often a valuable target for attackers and have invested heavily to ensure our software is as secure as possible. InstantForum follows many security best practices to help protect against common attacks such as XSS, SQL Injection, CSRF & session hijacking,. InstantForum also uses proven standard authentication mechanisms and supports ASp.NET forms authentication, windows authentication (with our Active Directory module) & the newer ASP.NET Identity / OWIN middleware based authentication,
There are a few deployment options beyond our control that may help you further secure your InstantForum installation. This article should help you ensure your InstantForum installation is as secure as possible.
Change the Default Admin Credentials
It's extremely important after you've installed InstantForum for the first time you reset the default administrator credentials. We would strongly suggest using a complex password for your administrator account.
Consider SSL / TLS for your installation
To secure all communication between your clients and server we would suggest using a SSL certificate for your installation whenever possible. InstantForum fully supports SSL, We use relative paths for all external resources (CSS / JS) ensuring external content is served over the same protocol as the requested page.
To force all links within InstantForum to use SSL if a user visits a non SSL version of your installation we would suggest hard coding the SSL version of your URL within your InstantForum database. Please follow the steps below to hard code your application URL...
- Visit the InstantForum Admin CP
- Click General Settings on the Left
- Locate the Application URL text box on the General Settings page
- Provide the full absolute URL to your installation ensuring you use https within the Application URL textbox. For example "https://www.yourdomain.com/community/".
If your force all traffic over HTTPS you should also set requireSSL="true" within your InstantForum web.config as shown below...
<forms name="InstantASP" requireSSL="true" cookieless="UseCookies" loginUrl="Logon.aspx" protection="All" slidingExpiration="true" path="/" />
Consider SSL / TLS for your SMTP server
To secure all communicate between InstantForum and your SMTP server we would suggest enabling SSL / TLS for SMTP whenever possible. For further information on how to enable SSL for your SMTP server please refer to Configuring Outbound InstantForum Emails.
Login Via Email Over Username
InstantForum allows you to choose which detail alongside a password a user must provide during the login process From the InstantForum Admin CP > Manage Settings > Login & Registration Settings page locate the "Login Using" drop down list and you will notice you can choose from either Email Address or Username. This lets you set as an administrator how users login. For example a user can enter a email address & password or a username & password to authenticate within InstantForum.
For external public installations we would strongly suggest you use the Email Address option for user authentication. A users email address is never displayed to other users whilst a users username is displayed to other users.
We provide the ability to login using your username mainly for internal / private installations or installations that are integrated into our InstantForum Active Directory Module. As the username is displayed publicly within the forum we would not suggest using the username for login unless you can control access to your InstantForum installation.
Minimize Attack Surface
If's good practice to minimize the possible vectors attackers could use. For example we would suggest disabling features such as PHP or FTP on your web server. PHP is not needed for InstantForum and if enabled this has it's own set of security risks.
If you need to enable FTP for access to your InstantForum installation we would strongly suggest using SFTP and leveraging a IP white list for connections to your FTP site.
IIS Modules / Handler Mappings
This again minimizes the attack surface. Consider disabling any custom or 3rd party handler mappings within IIS that are not related to serving ASP.NET content or static resources.
Install only the IIS modules you need
IIS 8 is composed of more than 40 modules, which allow you to add modules you need and remove any modules you don’t need. If you install only the modules you need, you reduce the surface area that is exposed to potential attacks.
Periodically remove unused or unwanted modules and handlers.
Look for modules and handlers that you no longer use and remove them from your IIS installation. Strive to keep your IIS surface area as small as possible.
Optionally provide private feedback to help us improve this article...
Thank you for your feedback!