OpenSSL Severe Vulnerability in TLS Heartbeat Extension (CVE-2014-0160)

There is a severe vulnerability in OpenSSL’s implementation of the TLS/DTLS (transport layer security protocols) heartbeat extension (RFC6520). This a serious vulnerability which has been assigned the CVE identifier CVE-2014-0160.

Exploitation may lead to disclosure of memory contents from the server to the client and from the client to the server. An attacker can remotely retrieve sensitive data from memory, including, but not limited to secret keys used for SSL encryption and authentication tokens.

For more information on the attacks see heartbleed.com.

How is Ruby affected?

Ruby is affected when statically compiled against a vulnerable version of OpenSSL through the standard library OpenSSL C extension.

OpenSSL versions 1.0.1 through 1.0.1f (inclusive) are vulnerable to this attack. To verify which version of the OpenSSL library you link to Ruby, use the following:

ruby -v -ropenssl -rfiddle -e 'puts Fiddle::Function.new(Fiddle.dlopen(nil)["SSLeay_version"], [Fiddle::TYPE_INT], Fiddle::TYPE_VOIDP).call(0)'

To verify the version of OpenSSL currently installed with Ruby, use the following:

ruby -ropenssl -e 'puts OpenSSL::OPENSSL_VERSION'

You can verify if your client software or a running service are vulnerable by using emboss’s script.

Use this link :  https://github.com/emboss/heartbeat

Solutions

To upgrade to the latest version of OpenSSL version 1.0.1g or newer, you should check with your current operating system package manager to ensure they provide an up-to-date OpenSSL. You may need to consult with your operating system distributor to verify their version of OpenSSL is patched, regardless of the version number available.

If upgrade is not an option, recompile a patched OpenSSL with the option -DOPENSSL_NO_HEARTBEATS at build time.

With an upgraded OpenSSL, it’s recommended to recompile Ruby to ensure there are no links to a vulnerable version of OpenSSL.

This means updating any tools used to build Ruby such as RVM or ruby-build. If you build Ruby yourself, use the --with-openssl-dir option at compile time to link an upgraded OpenSSL install directory.

$ ./configure --with-openssl-dir=/path/to/openssl
$ make
$ make install

After upgrading OpenSSL and Ruby, it’s important to restart all programs using the vulnerable version.

Many operating system distributions already provide (or will soon be providing) patched versions and rebuilt packages for libraries vulnerable to this attack. It’s important to monitor your operating system distributor to ensure you remain secure.

Heartbleed Bug and OpenSSL: Everything you need to know

Heartbleed Bug has raised eyebrows of all the users across the globe and security advocates have questioned government and social media about their data security. Here’s everything you need to know

 

 

 

in
5 

Deidre Richardson | On 13, Apr 2014

The Heartbleed bug has set the World Wide Web afire this week, with many sites and users rushing to change passwords and protect themselves against what is considered to be the most deadly attack against the Internet in all of its existence. We here at Inferse want to answer the questions you may’ve about Heartbleed, explain the reason behind the Web hysteria, and provide some counsel on what you can do in light of the facts presented here.

OpenSSL: The mother of all vulnerabilities

What is OpenSSL? OpenSSL refers to the name of a 1998 project that was started to encrypt websites and user information across the Web. The “SSL” in “OpenSSL” refers to a Secure Sockets Layer (also known as transport layer security or TLS), and OpenSSL is an open project (meaning any programmer or coder can work on it) that was designed to prevent hackers from retrieving personal data submitted by users to a website (such as a banking, shopping, or digital content website). Eric Young is responsible for the eventual establishment of OpenSSL, seeing that he started what ultimately became SSL software back in the 1990s. OpenSSL is an important undertaking, seeing that, without it, our personal information submitted across every website we hold dear could find its way into the hands of dishonest criminals.

Since OpenSSL is established to prevent hacker theft with internet data, it seems to be an important endeavor; yet and still, you wouldn’t recognize this right away. There are only eleven people currently that work in OpenSSL: 46-year-old British cryptographer Dr. Stephen Henson, volunteer Geoffrey Thorpe, two other British volunteers, a German developer, and a few others. Stephen Henson is the only full-time employee on the OpenSSL project. What started as a project committed to data encryption has now become standard on two-thirds of all websites on the Internet.

No wonder, then, that the OpenSSL vulnerability discovered this week is called “Heartbleed”: as it strikes at the heart of the most data-encrypted entity known to man.

Heartbleed: Is it a simple Programming Error?

What is Heartbleed? Heartbleed is a bug discovered by Codenomicon employees Riku, Antti, and Matti, as well as Google employee Neel Mehta this week. Heartbleed is essentially a programming error that leaves all forms of Internet data open to hackers. It was introduced into the OpenSSL software library by 31-year-old Robin Seggelmann, a Frankfurt, Germany developer who says that it was likely introduced while he was working on OpenSSL bug fixes around twot years ago. “I was working on improving OpenSSL and submitted numerous bug fixes and added new features. In one of the new features, unfortunately, I missed validating a variable containing a length.” The error was also missed by a reviewer responsible for double-checking the code, “so the error made its way from the development branch into the released version,” Seggelmann said.

It’s interesting to think about how a line of code could open a world of crime and identity theft for millions, but it’s true. Sometimes the smallest items in the world can do a lot of damage. Seggelmann denies that he introduced the programming error intentionally, and his testimony is credible. Why would he introduce a massive programming error while optimizing OpenSSL software against bug fixes at the same time?

While the Heartbleed bug seems focused on user data and hackers, it’s also possible that the server could extract personal user data from any client. In other words, with the greater exchange of data between clients, servers, and normal users, data extraction is possible from any of these three mediums. A malicious server can do as much damage as a hacker if the Heartbleed bug is left unchecked. Even if someone patches up the Heartbleed vulnerability at a given site, one can still experience a reverse Heartbleed vulnerability and still be subject to a data encryption attack.

Hackers exploited Heartbleed to gather Private Security Keys

Heartbleed is an error, but it works. This seems to be proven true by two hackers, Fedor Indutny and Ilkka Mattila, who successfully completed Cloudflare’s challenge to hackers to see if anyone could steal the private security keys. Cloudflare claimed that its own researchers tried for two weeks (in vain) to access the private security keys – but one can never underestimate the skills of professional hackers. One of them, Fedor Indutny, posted his victory on Twitter Friday morning for all to see: “Just cracked @CloudFlare’s challenge: cloudflarechallenge.com/heartbleed. I wonder when they’ll update the page.”

Indutny submitted his victory announcement at 4:22:01PST on April 11th, followed by Ilkka Mattila at 5:12:19 PST, less than an hour later. CloudFlare updated its challenge page to include not just these two hackers, but an additional two: Cambridge University Security group member and PhD student Rubin Xu at 4:11:09PST on April 12th, as well as Security researcher Ben Murphy at 7:28:50 PST on the same day.

Since four hackers have now accessed the private security keys and proven CloudFlare wrong about Heartbleed, is this vulnerability as bad as it seems?

Heartbleed: NSA exploited it or not?

To learn about Heartbleed bug is unfortunate; but what may be even more shocking or appalling is that reports suggest the National Security Agency (NSA) was aware of the Heartbleed bug for at least two years but used it to gather intelligence on certain individuals under the government’s watchful eye. This news only adds fuel to the fire of the NSA’s role in spying on the lives of private American citizens. Edward Snowden is the American credited with revealing the NSA’s improper use of American data and personal information in recent months.

The NSA responded to this claim by saying that it reveals all security risks when discovered and exposed: “Reports that NSA or any other part of the government were aware of the so-called Heartbleed vulnerability before April 2014 are wrong. The Federal government wasn’t aware of the recently identified vulnerability in OpenSSL until it was made public in a private sector cybersecurity report…This Administration takes seriously its responsibility to help maintain an open, interoperable, secure and reliable Internet. If the Federal government, including the intelligence community, had discovered this vulnerability prior to last week, it would’ve been disclosed to the community responsible for OpenSSL.”

However, some reports suggest that President Obama has given the permission to National Security Agency to exploit Internet security bugs in some cases.

Countries Reaction over it

The Federal Financial Institutions Examination Council (FFIEC) advised banks earlier this week regarding the Heartbleed bug and provided some steps necessary to ensure that banking website users are protected in the future. Of the steps provided, the FFIEC advised banks to make vendors who use OpenSSL aware of the Heartbleed vulnerability, upgrade systems with patches against Heartbleed, and then test these new upgrades to ensure that they are working properly.

Of the countries around the world reacting to the Heartbleed bug, Canada has been the most vocal. Canada’s Treasury Board issued a statement, telling Canadian officials to “immediately disable public websites that are running unpatched OpenSSL software. This action is being taken as a precautionary measure until the appropriate security patches are in place and tested.”

Websites prone to this error

What websites are prone to the OpenSSL vulnerability? A sufficient list (though by no means exhaustive) consists of the following:

• Yahoo
• AWS
• Box
• Dropbox
• SoundCloud
• OKCupid
• Github
• Minecraft
• IFFT
• Tumblr
• Pinterest
• Instagram
• Facebook
• 500px
• Redtube
• Flickr
• LastPass
• Duckduckgo

You can visit the Kaspersky blog to see if your website or a website in which you’ve an account is affected by the Heartbleed bug. Aside from these, shopping, banking, and other retail sites where you’ve entered and/or stored your personal credit card, debit card information or passwords, geographic address, and so on.

Mobile devices are vulnerable to Heartbleed

When the Heartbleed bug/OpenSSL vulnerability was announced a few days ago, tech analysts and Apple tech writers started blogging about the bug and encouraged users to change their passwords at most of their websites immediately. Fortunately, Apple issued a statement later in the week that should cause OS X and iOS users to breathe a sigh of relief: Apple’s desktop and mobile operating systems aren’t affected by the OpenSSL vulnerability. An Apple representative said “Apple takes security very seriously. IOS and OS X never incorporated the vulnerable software and key Web-based services weren’t affected.”

Google mobile operating system Android is affected by the Heartbleed bug, but only devices running Android 4.1.1 Jelly Bean. Google supplied this information on its Online Security Blog on Wednesday, April 9th: “All versions of Android are immune to CVE-2014-0160 (with the limited exception of Android 4.1.1, patching information for Android 4.1.1 is being distributed to Android partners).” Android devices running 4.1.2 or higher are in the clear. The latest survey as of last month shows that Android 4.1.x is present on 35.3% of all Android devices, although there is little information on how many of these devices are still running Android 4.1.1. Google’s initiative on this matter is important indeed, for the 35% of potentially affected devices.

How to protect yourself from the Heartbleed Bug

What can you do to protect yourself from the Heartbleed bug? As has been recommended, changing your passwords at most if not all sites you use on a regular basis is an excellent idea. At the same time, however, you may change your passwords in vain if the website you use doesn’t install some sort of security patch to prevent possible hacker attacks in the days and months to come.

What you should know for now is that sites such as Yahoo, CloudFlare, Duckduckgo, Reddit, Launchpad, Netflix, Amazon, Paypal, Adobe, CloudFront, and Github have all issued new SSL certificates for their sites – so these sites should be fine. At the same time, it is reported that there are still nearly 500,000 or more SSL certificates from affected websites that have yet to be changed.

At this point, the best advice we can provide is to contact websites in which you’ve ever provided personal information (financial or otherwise) and seek to ask questions about the Heartbleed bug as well as what you can do. Changing your website passwords may be futile at this point, but you should contact your websites and see if or when they intend to issue new SSL certificates. If you hear back and are told that the SSL certificate has been changed, you can then change your usernames and passwords for the sites in question.

As with many things, the most that can be done for now is to either 1) change passwords at affected sites, 2) email websites important to you and inquire about the Heartbleed bug, or 3) sit and wait. I’ve a feeling that many of us will likely change our passwords instead of option number three.

To check for openssl vulnerability

To check for openssl vulnerability
----------------------------------------------

>>> Go to server 

      Type command  openssl version 

      ( Affected version  1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1)

Bear in mind the version of openssl that is vulnerable. 

For versions that is not, do not attempt the upgrade.

Type the command:
  rpm -q --changelog openssl | grep 'CVE-2014-0160'

if the output says,  "fix CVE-2014-0160 - information disclosure in TLS 
heartbeat extension", then no need to attempt for openssl upgrade.
if there is no output, then you need to do   yum upgrade openssl

DO NOT USE THIRDPARTY REPO.  ONLY YUM UPGRADE  << This is important

Then recheck the openssl again as stated above.


Then reset the service SSL certificates.

Use rsync on Linux based servers to move/launch your websites

Tutorial: Use rsync on Linux based servers to move/launch your websites

Project files move around several times during the development process. A standard cycle includes:

1. Development environment – usually someone’s laptop/desktop or a private area of a web server
2. Staging environment – usually on the web but password protected or not indexed by search engines
3. Production/Live environment – this is ultimately where the website resides, usually accessible by a domain name

Sometimes one or more of the environments are on the same computer, but they’re often on different computers.

We like to use source control like git to roll out sites when possible, but whenever we need a quick migration or the clients’ server does not support git but has SSH access, we prefer the trusty rsynccommand.

rsync is synchronizes files across local or remote directories. It works on any Unix based operating systems such as Linux and Mac OS.

Why rsync?

Rsync addresses many common problems:

1. Speed – network to network transfers are much faster than downloading a site to your own computer, then uploading it again to the destination.
2. File and folder permissions – with the right option enabled, rsync keeps your folder permissions after the transfer, helping you avoid “permission denied”
3. Hidden files – rsync will grab hidden files like .htaccess. This often gets missed with other methods.
4. Convenience – you can migrate a site with a single command

What you’ll need:

1. SSH Access
2. rsync installed on both computers (if doing a remote transfer)
3. Good understand of how to navigate Linux file systems

How to use rsync:

The general format is:

rsync [options] [source] [destination]

From my own experience, the following options are best for migrating a site:

• a : archive mode, keeps timestamps and permissions
• z : compresses data during transfer, optional but recommended
• v : verbose mode, will show you progress and tell you where a transfer fails
• r : recursive, grabs all files and folders within a folder

You can combine all of this into a single stringe of “-azvr”

Local transfers:

Let’s say you have site at “dev.domain.com” and you’re ready to copy it over to “domain.com”. Both folders are inside of “/var/www/”, a common location in Linux web servers with multiples domain names. You could use the following:

rsync -azvr /var/www/dev.domain.com /var/www/domain.com

This example uses absolute paths. You can also use relative paths. Assuming we’re in “/var/www/dev.domain.com”:

rsync -azvr . ../domain.com

Remote transfers:

Remote transfers work the same way, but you have to log into the remote host. You could use the following:

rsync -azvr /var/www/dev.domain.com user@host:/var/www/domain.com

Substitute “user@host” with your ssh credentials on the remote server.

Sync remote files to local host:

You can also reverse the direction and grab a copy of remote files to your local server. An example might be copying your production environment back to your development environment on your desktop. Our destination folder will be whatever our current folder is in terminal.

rsync -azvr user@host:/var/www/domain.com .

Exclusions:

rsync has good exclusion handling. Let’s say you want to copy everything except a certain folder:

rsync -azvr --exclude "/folder" . /var/www/domain.com

You can also use multiple exclude options for multiple folders/files:

rsync -azvr --exclude "/folder" --exclude ".htaccess" --exclude "robots.txt". /var/www/domain.com

Minor Upgrade of SmarterStats

The steps for upgrading from an older version of the application vary depending on which version you are upgrading from.

Applies to SmarterStats 8.x
Follow these steps to upgrade to the latest version of SmarterStats if you are upgrading from a previous 8.x release (for example from SmarterStats 8.0 to SmarterStats 8.1):

1. Back up your SmarterStats installation and data.
2. Download the latest automated installer from the SmarterStats Download page.
3. If you are running SmarterStats as an IIS site, stop IIS.
4. Run the SmarterStats installer.
5. During the installation process you will be prompted for the installation path. Installation along the existing file path to keep data and settings. (The default installation location is C:\Program Files\SmarterTools\SmarterStats.)
6. If you are running SmarterStats as an IIS site, restart IIS.

Note: All configuration data and sites are preserved when upgrading from a previous 8.x release.

 

Backwards Compatibility

When downgrading from SmarterStats 8.x (for example, to SmarterStats 6.x or 7.x), some settings will be lost or changed. For this reason, it is very important to create a backup of your SmarterStats installation prior to upgrading to SmarterStats 8.x. (For instructions on backing up SmarterStats, please search for article "How To – Back Up and Restore SmarterStats".)

Major Upgrade of SmarterStats

The steps for upgrading to SmarterStats 8.x from an older version of the application vary depending on which version you are upgrading from. For more information on upgrading from a previous 8.x release refer to the knowledge base article -- Minor Upgrade of SmarterStats.

 

NOTE: When upgrading SmarterStats you may notice a difference in statistics. Please refer to this knowledge base article for more information -- Differences in Reported Numbers Between SmarterStats Versions.

Applies to SmarterStats 8.x

Follow these steps to upgrade to the latest version of SmarterStats if you are upgrading from a previous version (such as 6.x or 7.x):

1. Install the Microsoft .NET 4.0 Framework.
2. Back up your SmarterStats installation and data.
3. Alter the IIS configuration by making a new application pool:
   • In IIS, view the Application Pools listing. Then right-click and select Add Application Pool.
   • In the Name field, type the name of the application pool.
   • In the .NET Version field, select .NET Framework v4.0.30319 from the list.
   • Click OK.
   • Select the SmarterStats website.
   • In the Actions panel, click Basic Settings.
   • Click Select. A list of available application pools will display.
   • Select the application pool that was just created and click OK.
4. Uninstall SmarterStats. All configuration data and sites will be preserved.
5. Download the latest automated installer from the SmarterStats Download page.
6. If you are running SmarterStats as an IIS site, stop IIS.
7. Run the SmarterStats installer.
8. During the installation process you will be prompted for the installation path. Installation along the existing path. (The default installation location is C:\Program Files\SmarterTools\SmarterStats.)
9. If you are running SmarterStats as an IIS site, restart IIS.
10. The Setup Wizard will automatically run. You will need to provide the new license key.

Backwards Compatibility

When downgrading from SmarterStats 8.x (for example, to SmarterStats 6.x or 7.x), some settings will be lost or changed. For this reason, it is very important to create a backup of your SmarterStats installation prior to upgrading to SmarterStats 8.x. (For instructions on backing up SmarterStats, please search thes KB for "How To – Back Up and Restore SmarterStats".)

Set up SmarterStats as an IIS Site (IIS 7.0/7.5)

By default, SmarterStats installs a basic Web server that allows administrators to start using the application immediately after installation. However, SmarterTools recommends moving to a more robust and secure Web server, such as Microsoft IIS.

The instructions for setting up SmarterStats as an IIS site differ slightly depending on whether you are using IIS 6.0 or IIS 7.0.

NOTE: This topic assumes that you are familiar with IIS and how it works. SmarterTools recommends that you use the Web server included with SmarterStats if you are unfamiliar with or uncomfortable using Microsoft IIS.

Applies to All Versions of SmarterStats

This article covers the following:

• Disabling the SmarterStats Web server
• Adding a new application pool for SmarterStats
• Adding SmarterStats to IIS
• Verifying IIS Settings
• Updating DNS
• Testing the site

Disabling the SmarterStats Web Server
These steps will stop and disable the default web server that is included with SmarterStats. This will also have the side-effect of disabling any shortcut for SmarterStats that may be placed on your desktop until you update it with the new URL for the SmarterStats site created in IIS.

1. Click on Start -> Programs -> SmarterTools -> SmarterStats -> Configure SmarterStats Web Server
2. Click on the Stop butto
3. Change the Startup Mode to Disabled
4. Click on the Apply button
5. Click the Close button

NOTE: You can also stop and disable the SmarterStats Web server from within the Services administrative tool if you are more comfortable using the Windows Server admin tool set.

Add an Application Pool
Follow these steps to add an application pool specifically for SmarterStats:

1. Open Internet Information Services (IIS) Manager
2. Right click on Application Pools from the tree view and choose Add Application Pool
3. Name the new application pool SmarterStats, or something similarly easy to identify
4. Set the .Net Framework Version to v4.0.x
5. Set the Application Pools Managed Pipeline to 'Integrated'
6. Make sure "Start application pool immediately" is checked
7. Click OK

Add SmarterStats to IIS
Follow these steps to add SmarterStats to IIS:

1. Open Internet Information Services (IIS) Manager
2. Click on your ServerName, and on the right side, under IIS, double-click ISAPI and CGI Restrictions
3. Verify that ASP.NET v4.0 is allowed (If not, right click on ASP.NET v4.0.x and select Allowed)
4. On the left side of the page, right click on Sites in the tree view and choose Add Website
5. Name the site SmarterStats
6. If you created an Application Pool name other than SmarterStats, click Select and choose the correct Application Pool
7. For the physical path, browse to the SmarterStats -> MRS folder. The default location is C:\Program Files (x86)\SmarterTools\SmarterStats\MRS
8. For Binding, choose an IP address to use for Webmail. If this IP address is shared with another Web site, you will need to use a different port or Host Headers. For more information about using Host headers, refer to the IIS documentation
9. Make sure "Start Web site immediately" is checked
10. Click OK

Verify IIS Settings
Follow these steps to verify the IIS settings. Please read each item carefully.

1. In IIS Manager, click on your ServerName
2. Under IIS, double click ISAPI and CGI Restrictions
3. Verify that ASP .NET v4.0 is allowed. If it is not, right-click on ASP .NET v4.0 and select Allowed
4. In the tree view, click Sites
5. Expand (or double click) the SmarterStats site
6. Click on the App_Themes folder
7. Under IIS, double click HTTP Response Headers
8. Under the Action menus, click Set Common Headers
9. Enable the Expire Web content setting
   • Click After
   • Add 7 for the number of days
10. Click OK
11. Click on Application Pools in the tree view
12. Right click on the SmarterStats application pool and select Advanced Settings
13. Under the Process Model heading, ensure the the Identity is set to the NetworkService account
14. From the Start menu, open Administrative Tools and select Services, then verify that the World Wide Publishing Service is running

For more information, refer to the SmarterStats Online Help.

Set up SmarterStats as an IIS 6.0 Site

By default, SmarterStats installs a basic Web server that allows companies to start using the application immediately after installation. However, SmarterTools recommends moving to a more robust and secure Web server, such as Microsoft IIS.

The instructions for setting up SmarterStats as an IIS site differ slightly depending on whether you are using IIS 6.0 or IIS 7.0. Only the instructions for IIS 6.0 are described below.

NOTE: This topic assumes that you are familiar with IIS and how it works. SmarterTools recommends that you use the Web server included with SmarterStats if you are unfamiliar with or uncomfortable using Microsoft IIS.

Applies to All Versions of SmarterStats

An overview of the instructions are:

1. Disable the SmarerStats Web server
2. Add Application pool
3. Add SmarterStats to IIS
4. Verify IIS Settings
5. Update DNS
6. Test the site

Disable the SmarterStats Web Server
These steps will stop and disable the web server included with SmarterStats. They will also have the side-effect of disabling the shortcut on SmarterStats on your desktop until you update it with the new URL for SmarterStats.

1. Click on Start -> Program Files -> SmarterStats -> Web Server Config.
2. Click on the Stop button.
3. Change the Startup Mode to Disabled.
4. Click on the Apply button.
5. Click the Close button.

Add an Application Pool
Follow these steps to add an application pool:

1. Click on Start -> Control Panel -> Administrative Tools -> Internet Information Services (IIS)Manager.
2. Right click on Application Pools and choose New -> Application Pool.
3. Name the pool SmarterStats (or something equivalent) and click OK.
4. Right click on the application pool that was just created and click Properties.
5. Select the Identity tab.
6. Select Network Service from the drop down list, and click OK.

Change Your File Permissions
These steps will walk you through how to change your file permissions for your SmarterStats website to ensure IIS can read and write to the appropriate files.

1. Navigate to your SmarterStats directory. By default, this is at C:\Program Files\SmarterTools\SmarterStats\. On 64-bit machines, it will be under C:\Program Files (x86)\SmarterTools\SmarterStats\.
2. Right click on the MRS folder and select Properties.
3. Click the Security tab.
4. Click Edit.
5. Click Add.
6. In the textbox, type Network Service and click OK. Note that if your server is connected to a domain, you will need to click the Locations button, and select your server as the location. Windows selects a default location of the domain to add users.
7. Highlight the Network Service user and select Read & execute, List folder contents, and Read, under the Allow column. Ensure no check boxes are selected under the Deny column.
8. Click OK and you will be brought back to the MRS Properties window. Click OK here as well.
9. Open the MRS folder.
10. Right click on the App_Data folder and select Properties.
11. Click the Security tab.
12. Click Edit.
13. Highlight the NETWORK SERVICE user and select Full Control under the Allow column. Ensure no check boxes are selected under the Deny column.
14. Click OK and you will be brought back to the App_Data Properties window. Click OK here as well.

Add SmarterStats to IIS
Follow these steps to add SmarterStats to IIS:

1. Click on Start -> Control Panel -> Administrative Tools -> Internet Information Services (IIS)Manager.
2. Right-click on the web sites tree on the left of the page and choose New -> Web Site.
3. When asked for a description, type SmarterStats.
4. Choose the IP address to use for SmarterStats. If this IP address is shared with another web site, you will need to use a different port or Host Headers. For more information about using Host Headers, refer to the IIS documentation.
5. For the physical path, browse to the SmarterStats\MRS folder. The default location is: C:\Program Files\SmarterTools\SmarterStats\MRS.
6. Leave the "Allow anonymous access to this web site" box checked.
7. When asked what permissions to grant, choose only Read and Run Scripts.
8. Finish the Wizard.

Verify IIS Settings
Follow these steps to verify the IIS settings:

1. If you are using Windows 2003, verify that ASP .NET v4.0.30319 Web Service Extension is set to Allowed in IIS. If you do not see ASP .NET under Web Service Extensions, ensure that ASP .NET is enabled in the Application Server. You can do ths by going to: Control Panel -> Add/Remove Programs -> Windows Components -> Application Server -> Details.
2. Ensure that the default document for the site is Default.aspx (under the Documents tab).
3. For better performance, set HTTP content expiration for 7 days on the App_Themes folder unless you are actively creating a new skin.
4. In Windows 2003, alter application pool’s performance tab to disable the “Shutdown worker process after being idle for,” or change it to a high value, like 240.

Update DNS
If any sites are already set up with SmarterStats, make sure to update their DNS records to point to the new IP address.

Test the site
Open up your browser and type the IP address of the site you just added.

For more information, refer to the Running as an IIS Site section of the SmarterStats Online Help.