Remove X-powered by ASP.NET version and IIS version from HTTP response header of IIS webservers

Hackers are using footprinting techniques to collect as much information about a target network. By simply telnetting a webserver, sensitive information such as servername, server type, operating systems and application running can be disclosed. For example, tools such as httprecon, ID serve and NMAP can perform such tasks.

After obtaining information about version of applications, the hacker will know whether the applications have the latest patches or not. If the latter is true, all the vulnerabilities that are not yet patched could be potentially be exploited by the hacker. Therefore it is important not to reveal such information on webservers.

The following details how to remove X-powered by ASP.NET version and IIS version from HTTP response header of IIS webservers.

Generally, when a client browser requests a Web page, IIS returns a response with a Hypertext Transfer Protocol (HTTP) header. HTTP response headers are name and value pairs that contain information about the requested page. These include the HTTP version, date, and content type.

You can create or modify HTTP headers to pass special information in responses to clients. For example, You could create a custom header named “authors” that might contain the names of content authors. Or you might create a Content-Language header to describe the natural languages used in the body of your Web page, and provide several language-country/region values such as en-US (United States English), en-CA (Canadian English), and en-GB (British English).

If you create a custom HTTP response header at the Web server level, all Web sites, Web applications, virtual directories, and files inherit the header unless you override the header at a child level. Likewise, Web applications and virtual directories inherit headers from the Web site level, and files inherit headers from the Web application or virtual directory level. You can remove an inherited header so that it is not passed in a response, and restore the header later if it is required.

Note: To view HTTP response headers, You need to install the browser add -ons. Browser add-ons can be downloaded from the internet.

Steps to remove server name from HTTP Header:

Download and install the latest version of urlsacn tool (version 3.1) from the following link

32-Bit (x86): http://www.microsoft.com/downloads/details.aspx?FamilyID=ee41818f-3363-4e24-9940-321603531989

64-Bit (x64): http://www.microsoft.com/downloads/details.aspx?FamilyID=361e5598-c1bd-46b8-b3e7-3980e8bdf0de

1.Double-click the MSI file to begin the installation process.

2.Review the agreement in the UrlScan Installer Package End User Agreement and then click Yes to accept the agreement and continue. If you click No, the installer will close.

3.When the installer completes, a dialog box stating that UrlScan has been successfully installed will be displayed.

4.Click Finish to close the installer.

Verify whether the installer is configured correctly:

1.Installs the UrlScan.dll and UrlScan.ini files in the %windir%\system32\inetsrv\UrlScan directory. If UrlScan is already installed on the computer, the UrlScan.ini file is updated with any new settings that are not present in the current configuration file.

2.Adds UrlScan as a global filter to IIS.

3.Creates a %windir%\system32\inetsrv\UrlScan\Logs directory.

4.We can configure UrlScan's operation by setting options in the UrlScan.ini file. This file should reside in the same directory as UrlScan.dll, and it contains the sections and options that are listed below.

Note: UrlScan 3.0 added change notifications for the UrlScan.ini file, so it is no longer necessary to restart IIS after updating your UrlScan.ini file.

The [Options] section of a UrlScan.ini file contains a list of name/value pairs that define the general behavior for UrlScan. A few of the settings enable or disable other sections in the UrlScan.ini file.

Set Remote server header Allowed values are 0 or 1. The default value for RemoveServerHeader is 0.

If set to 1, UrlScan will remove the server header on all responses, and the value of AlternateServerName will be ignored.

If set to 0, IIS will return the default server header on all responses.

Note: This feature is only available if UrlScan is installed on IIS 4.0 or later.

Remove X-powered header from HTTP header:

IIS 7:

1.From the Internet information console, Click on server name in the left pane.

2.Click on HTTP response header.

3.Now Click on X-Powered  Asp.net version HTTP header and click remove in the top right panel.

IIS 6:

1.Right click on web site, and click properties.

2.Click on HTTP header.

3.Now under custom HTTP header, click on X-powered ASP.NET version.

4.Click Remove on the right pane.

Read More

Microsoft Enterprise Threat Detection (ETD)

ETD-Hosted is a managed security service used to detect security related incidents and vulnerabilities within your environment that other sensors may have missed, providing unique insight into their global impact. There’s a range of 25,000 till 250,000 endpoints/hosts which can monitored (include physical and virtual laptops, desktops, and servers, etc.). The service leverages a number of data feeds emanating from or instrumented within your environment and a suite of detection tools run by Microsoft to detect security incidents.Using a combination of machine analytics, proprietary telemetry sources, and dedicated human analysis, the service is uniquely positioned to continually monitor for advanced attacks in the rapidly-evolving modern threat environment. Analysts leverage unique Microsoft technologies and assets to provide you with unparalleled insight into your environment and enhanced detection capabilities. Working with you as a technical advisor and extension of your security team, Microsoft use world-class technologies, Windows internals, and global telemetry sources to establish the use of the infrastructure as a sensor, determining if your network is compromised, under attack, vulnerable, and/or non-compliant.

Microsoft will monitor data and provide alerts based on Microsoft’s Cyber Threat Intelligence (CTI) platform, which is a global telemetry system with advanced data mining capabilities. This platform leverages the vast network of global sensors owned and operated by Microsoft as part of multiple antimalware programs at Microsoft that enable Microsoft to become aware of potential threats.

How the Offering Works

Microsoft will work with you to configure your clients to send native Windows telemetry events to one or more ETD collectors deployed on your network. This can all be performed through Active Directory and there is no software to deploy to clients. These collectors will forward events to our cloud-based ETD Analysis Center where our analysts will use enhanced heuristics to analyze the data and work with you to provide actionable information. The analysis is focused on detecting attacks, vulnerable systems, persistent malware, and corporate policy violations.

The analysts also query Microsoft’s vast global telemetry and threat intelligence sources to monitor and analyze your environment, providing you with a deeper understanding of activity emanating from your environment and threats facing your environment. Data from the Microsoft Active Protection System (MAPS), our global antimalware telemetry system, is combined with indicators from Microsoft’s Digital Crimes Unit (DCU) and other internal threat intelligence sources, to provide you with actionable intelligence.

The service also leverages output from your existing Advanced Threat Analytics (ATA) and Defender Advanced Threat Protection (D-ATP) implementations, if available. Your ATA center is configured to send data to ETD analysts for additional investigation and cross-correlation with ETD data feeds. By providing ETD analysts access to your D-ATP tenant, detection capabilities for Windows 10 endpoints is increased as well.

The Offering consists of weekly, monthly and/or quarterly summative reports on findings and threat profiles of your organization, as well as “out of band” alerting for critical threats such as an on-going attack or serious vulnerability.

Subscription Components and Pricing

• ETD Hosted is provided as an annual fixed-fee subscription service. Included in this subscription are:

• Architectural guidance on deploying ETD Collectors and enabling telemetry collection through Active Directory

• License to install as many ETD Collectors as required for the duration of the subscription

• Detailed weekly, monthly or quarterly summative reporting on findings and threat profiles of your organization

• Out-of-band reporting on immediate threats and active attacks once detected

ETD Hosted subscription pricing does not include the cost of the collector hardware or required collector Windows operating system licenses. It does not include the licensing, deployment, and configuration of Advanced Threat Analytics (ATA) and/or Windows Defender ATP (D-ATP). Pricing varies based on the number of Windows endpoints within the organization and the frequency of summative reporting.

Potential Benefits:

• Enhanced detection and situational awareness, leveraging best in class detection technologies
• Analysis of threats using Microsoft global telemetry and threat intelligence sources with a focus on your environment
• Improved detection of
• Zero-day vulnerabilities
• Malware undetected by antivirus
• Systems missing security patches
• Suspicious web traffic

Sample Alert

 

Source: Microsoft

Read More

Prevent Spoofing Email Attack – Steps to Implement SPF, DKIM and DMARC on O365

1 – Implement SPF

An SPF TXT record is a DNS record that helps prevent spoofing and phishing by verifying the domain name from which email messages are sent. SPF validates the origin of email messages by verifying the IP address of the sender against the alleged owner of the sending domain

Requirements for your SPF TXT record and Office 365

If you set up mail when you set up Office 365, you already created an SPF TXT record that identifies the Microsoft messaging servers as a legitimate source of mail for your domain. This record probably looks like this:

v=spf1 include:spf.protection.outlook.com –all

If you have a hybrid deployment (that is, you have some mailboxes on-premises and some hosted in Office 365), or if you’re an Exchange Online Protection (EOP) standalone customer (that is, your organization uses EOP to protect your on-premises mailboxes), you should add the outbound IP address for each of your on-premises edge mail servers to the SPF TXT record in DNS.

A typical SPF TXT record for Office 365 has the following syntax:

v=spf1 [<ip4>|<ip6>:<IP address>] [include:<domain name>] <enforcement rule>

For example, let's say that your domain contoso.com uses Office 365. You add an SPF TXT record that lists the Office 365 messaging servers as legitimate mail servers for your domain. When the receiving messaging server gets a message from joe@contoso.com, the server looks up the SPF TXT record for contoso.com and finds out whether the message is valid. If the receiving server finds out that the message comes from a server other than the Office 365 messaging servers listed in the SPF record, the receiving mail server can choose to reject the message as spam.

Also, if your domain does not have an SPF TXT record, some receiving servers may reject the message outright. This is because the receiving server cannot validate that the messages come from an authorized messaging server.

Example: SPF TXT record for multiple outbound on-premises mail servers and Office 365

In case you are only using Office 365 for outbound emails, you should only have the recommended TXT record:

v=spf1 include:spf.protection.outlook.com –all (the SPF defined for your organization is: v=spf1 include:spf.protection.outlook.com~all)

If you have multiple outbound mail servers, include the IP address for each mail server in the TXT record and separate each IP address with a space followed by an “ip4:” statement. For example:

v=spf1 ip4:192.168.0.1 ip4:192.168.0.2 ip4:192.168.0.3 include:spf.protection.outlook.com ~all

If you know all of the authorized IP addresses, they should be added using the –all (Fail) qualifier. If you’re not sure that you have the complete list of IP addresses then you should use the ~all (SoftFail) qualifier.

In case you are sending messages smarthosted through Office 365 or even if you have a Hybrid environment and you are sending emails to a different Office 365 organization, you will have to add the on-premise IP address in your SPF record AND spf.protection.outlook.com.

https://blogs.technet.microsoft.com/eopinsights/2015/08/14/o365-and-spf/

Once you have formed your SPF TXT record, you need to update the record in DNS.

If an SPF TXT record exists, instead of adding a new record, you need to update the existing record.

If you already have an SPF record, you should append the new Office 365 values to it, rather than create a new one. You can verify/test the syntax of the SPF with 3 tools : https://support.office.microsoft.com/en-us/article/Tools-you-can-use-to-validate-SPF-records-for-your-domain-92a43f6a-4651-455a-a1cc-300684bedcfa?ui=en-US&rs=en-US&ad=US .

SPF is designed to help prevent spoofing, but there are spoofing techniques that SPF cannot protect against. In order to protect against these, once you have set up SPF, you should also configure DKIM and DMARC for Office 365. To get started, see Use DKIM to validate outbound email sent from your domain in Office 365.

2 - Implement DKIM

For more information, please see the link :

https://blogs.msdn.microsoft.com/tzink/2015/10/08/manually-hooking-up-dkim-signing-in-office-365/

https://technet.microsoft.com/en-us/library/mt695945(v=exchg.150)#SetUpDKIMO365

Here’s how to enable DKIM signing for your domain if it is hosted in Office 365 (Exchange Online Protection).

The <domainGUID> is the same as the <domainGUID> in the customized MX record for yourdomain that appears before mail.protection.outlook.com. For example, for a domain contoso.com:  

contoso.com.    3600  IN  MX   5 contoso-com.mail.protection.outlook.com.

The <initialDomain> is the same one that you signed up with for Office 365. For example, contoso.com may have signed up with contoso.onmicrosoft.com. Therefore, the two CNAMEs that contoso.com would publish are the following:

Host name:                  selector1._domainkey
Points to address or value: selector1-contoso-com._domainkey.contoso.onmicrosoft.com
TTL:                        3600 

Host name:                  selector2._domainkey
Points to address or value: selector2-contoso-com._domainkey.contoso.onmicrosoft.com
TTL:                        3600 

In the above, the host name does not contain the full FQDN of the domain you are provisioning. You could explicitly include the full thing, that is, instead of Host name selector1._domainkey, you could put selector1._domainkey.<domain>.

Note : For each other domain you have provisioned with Exchange Online, you will need to enable DKIM signing for it. 

For example, if your initial domain is contoso.onmicrosoft.com and you have provisioned contoso.com and fabrikam.com, you will need to provision 4 CNAMEs (two for each domain). The two CNAMEs are so that we can perform automatic DKIM key rotation for you. You need to do this for each domain that you use to send email. DKIM signing does not inherit DKIM settings for other domains that you have provisioned for your organization. For a company trying to DKIM-sign contoso.com and fabrikam.com, you’d have four additional DNS records that look like this: 

selector1._domainkey.contoso.com IN CNAME selector1-contoso-com._domainkey.contoso.onmicrosoft.com
selector2._domainkey.contoso.com IN CNAME selector2-contoso-com._domainkey.contoso.onmicrosoft.com

selector1._domainkey.fabrikam.com IN CNAME selector1-fabrikam-com._domainkey.contoso.onmicrosoft.com
selector2._domainkey.fabrikam.com IN CNAME selector2-fabrikam-com._domainkey.contoso.onmicrosoft.com

Second, you need to enable DKIM-signing for the domain within the service. You can do this in the EAC by going to protection > dkim and clicking Enable for each domain you own.

Alternatively, if you use Powershell:

New-DkimSigningConfig –DomainName <domain> –Enabled $true

3 – Implement DMARC to Prevent Spoofing

https://blogs.msdn.microsoft.com/tzink/2014/12/03/using-dmarc-in-office-365/

https://blogs.technet.microsoft.com/eopinsights/2015/09/18/block-spoofing-in-office-365/

https://blogs.office.com/2015/01/20/enhanced-email-protection-dkim-dmarc-office-365/

Once you have SPF and DKIM properly configured, you may choose to start using DMARC. Configuration of DMARC involves the creation of a DNS TXT record to advise recipients of what to do with DMARC failures and where to send the DMARC reports.

You’ll likely want to start with an action of “none” meaning that you just want to monitor emails not but take any action. Even if you can’t get to the point where you configure an action of “quarantine” or “reject”, you can still use DMARC to help mitigate phishing attempts.

After determining the action type, you will probably want to use a third-party service to help analyze the DMARC reports. Your published DMARC record will tell recipients that support DMARC to email reports to the address specified in the DNS record. These reports will arrive as a compressed attachment containing an XML file. There are a number of services that can assist with analyzing DMARC reports, some that are free, some that are paid and many that have 30-day trials. For my low-volume testing, I used “dmarcian” but there are a number of others listed at “dmarc.org“. These services will usually provide you two email addresses to publish: one for the aggregate reports and one for failure reports.

Now it’s time to publish your DMARC record. This record is a TXT record but instead of being at the root like your SPF, the record will have a host name of “_dmarc”. Some DNS providers do not support hostnames that begin with an underscore in which case you may need to switch DNS providers if you want to configure DMARC.

A typical DMARC record might look this this:

Host: _dmarc
TXT Value: "v=DMARC1; p=none; pct=100; rua=mailto:dmarc_aggr@dmarcservice.com; ruf=mailto:dmarc_fail@dmarcservice.com;"

- You should replace mailto:dmarc_aggr@dmarcservice.com/ mailto:dmarc_fail@dmarcservice.com with your email address, or you can create an address created especially for reports . 

Again, you should use one of the validation sites like “MxToolbox” to check your published DMARC record.

EOP more-or-less follows the DMARC specification for outbound messages. If a message is outbound from EOP and fails DMARC, then if the action is p=quarantine it will be routed through the High Risk outbound IP pool. However, if the message fails DMARC and the action is p=reject, the message will be rejected. There is no override for outbound email.

If you publish a DMARC reject policy (not p=quarantine, and not p=none), no other customer in Office 365 can spoof your domain because they will not be able to pass SPF or DKIM for your domain when relaying a message outbound through the service.

However, if you do publish a DMARC reject policy but don’t have all of your email authenticated, some of it may be marked as spam for inbound email (as described above), or it will be rejected if you do not publish SPF and try to relay it outbound through the service.

Many companies publish p=none because they are unsure about how much email they may lose by publishing a more restrictive DMARC policy. Microsoft, for example, is not yet in a position to publish p=reject because email sent to other third parties like Gmail, Yahoo, AOL, and so forth may discard important email if it does. Your company may be in the same position.

If you set up DMARC records, you can create an ETR that marks messages as spam for spoofed messages of your company that fail DMARC.

This means that all spoofed email of your domain into Office 365 will be marked as spam, but anywhere else – at Gmail, Yahoo, AOL – will not be marked as spam (at least not due to DMARC). Some legitimate email may be marked as spam, but to get around this either ensure that the email is authenticated by updating SPF records or signing it with DKIM; or, add a safe sender or ETR allow rule for the sender

You should still properly authenticate your email because it reduces false positives and it shrinks the list of exceptions. If you publish p=reject you will no longer need this rule.

Read More