Some non .Net Applications like the ones written in classic ASP are required to be debugged in Visual Studio. Since these are not hosted on IIS Express, but on IIS, you need to identify the worker process running your machine or the Server and attach the w3wp.exe with the Debug tool in Visual Studio.
Enable Debugging under IIS classic ASP section as shown below:
Under the Debug menu in Visual Studio, select “Attach to Process”:
There may be multiple worker processes running on the machine depending on how many applications are running under IIS. Match the right one with the correct ProcessID.
Add the debug points in your Asp file and hit the required Page in the browser.
When it comes to managing your website traffic, one of the things to consider is the availability of your website.
IIS has a idle time-out property that is by default set to 20 minutes. This means that if no request comes for your site for 20 minutes of inactivity, IIS would kill the worker process to free-up resources. This means the memory utilised by loading of classes, session etc. This can be helpful when multiple websites may be hosted on the Server and is resource crunched.
You’ll find the below settings under the AppPool advanced settings:
So, when the next request comes to your site to access something e.g. Login page, IIS Server would again need to initialize the Worker process and load the required resources to serve that request. The first request will be slow to respond to the user because of all the initialization time required. You need to think in these terms that how much traffic usually comes to your site. If your website requires high availability, then you should consider setting the idle time-out to 0 in the App Pool settings. Or if high availability isn’t a concern, you can think for how many minutes you’d usually require your application to be available depending on the traffic.
There have been studies regarding the make or break for websites because of their initial load time. So, please be careful about this setting. Internet facing websites usually require high availability. For Intranet websites, you can think of some number of minutes based on the usage.
Open IIS Manager on your Web Server and Select the Website for which you want to customize your logging fields. The changes can also be done at the Server level but that depends on the requirement.
Double-click on Logging icon.
Click on Select fields to select or remove any fields that you want in your IIS logs.
To add any custom field, click on the Add Field button as shown below and add the required header. The below example shows how you can get the Client IP information from the X-Forwarded-For Header (XFF) when the Website is hosted on a Server in a Load Balanced environment. The source of this information is in the Request header. The new log file will have an “_x” suffix to it’s name after modification.
The Logs directory shown above is where your Log files are saved. To identify the file name, check the Website ID under Sites on the left pane. The Log file name format will be “W3SVC<ID>”.
Click on Apply on the Actions Pane on the right to apply the changes.
The HTTP protocol by itself is clear text, meaning that any data that is transmitted via HTTP can be captured and the contents viewed. To keep data private and prevent it from being intercepted, HTTP is often tunnelled through either Secure Sockets Layer (SSL) or Transport Layer Security (TLS). When either of these encryption standards are used, it is referred to as HTTPS.
HTTP Strict Transport Security (HSTS) is an optional response header that can be configured on the server to instruct the browser to only communicate via HTTPS. This will be enforced by the browser even if the user requests a HTTP resource on the same server.
Cyber-criminals will often attempt to compromise sensitive information passed from the client to the server using HTTP. This can be conducted via various Man-in-The-Middle (MiTM) attacks or through network packet captures.
Security Scanners would recommend to using adding a response header HTTP Strict-Transport-Security or HSTS when the application is using Https.
Depending on the framework being used the implementation methods will vary, however it is advised that the Strict-Transport-Security header be configured on the server. One of the options for this header is max-age, which is a representation (in milliseconds) determining the time in which the client’s browser will adhere to the header policy. The browser will memorize the HSTS policy for the period specified in max-age directive. Within this period, if an user tries to visit the same website but types http:// or omits the scheme at all, the browser will automatically turn the insecure link to the secure one (https://) and make an HTTPS connection to the server. Depending on the environment and the application this time period could be from as low as minutes to as long as days.
Enabling includeSubDomains attribute of the element of the root domain further enhances the coverage of the HSTS policy to all its subdomains. HSTS has a separate mechanism to preload a list of registered domains to the browser out of the box.
It is also usually recommended to redirect all http traffic to https. I’ve written another post on how to do that.
To add the HSTS Header, follow the steps below:
Open IIS manager.
Select your site.
Open HTTP Response Headers option.
Click on Add in the Actions section.
In the Add Custom HTTP Response Header dialog, add the following values:
Value: max-age=31536000; includeSubDomains; preload
Or directly in web.config as below under system.webServer: