Category Archives: Security

Microsoft Teams – Deploy Information barrier policies for your organization.

Microsoft Teams, Security February 23, 2020 Leave a comment

A year ago Microsoft released the information barrier policies as another security enhancement feature in Microsoft Teams. With this new component it helps the organization to enforce policies which prevents the communication between specific group of people. This is primarily helpful and beneficial for the organizations who are into manufacturing and production units where they would need to adhere certain industry standards and guidelines usually to avoid conflicts of interest.

Before we actually move into deploying the information barrier policies segmentation of the users needs to be done.Ideally the business requirement which falls into compliance category to prevent communications between groups of users in Microsoft Teams. For example a person from Marketing Team cannot make a call,send instant messages or share his desktop to Research department. It can be vice versa or its is only one direction. All the sets of users needs to be identified because this contributes to the number of the segments that we are going to create for this policy to prevent the communication between them.

There are three key elements involved in creating the information barrier policy:

1) Segment the users in your organization.
2) Define Information barrier policies.
3) Apply the information barrier policies.

Below prerequisite needs to be met for creating the information barrier policies:

1) Users must have any one of the following license assigned – Microsoft 365 E5,Office 365 E5,Office 365 Advanced Compliance or Microsoft 365 E5 Information Protection and Compliance.

2) Enable scoped directory search for Microsoft Teams

Scoped directory search can be easily enabled from the teams admin center with the below toggle switch.

3) Turn on the Auditing on the audit log search page in Security and Compliance center. This is required for troubleshooting Information barriers policies. If we do not see them turned on then it is already enabled.

4) No address book policy should be enabled if we need this feature. Because Information barriers are based on address book policies and if we have them it might create a conflict and start working based on the configured address book policy.

5) Grant Admin consent for information barriers in Microsoft Teams.

Login-AzureRmAccount 
$appId="bcf62038-e005-436d-b970-2a472f8c1982" 
$sp=Get-AzureRmADServicePrincipal -ServicePrincipalName $appId
if ($sp -eq $null) { New-AzureRmADServicePrincipal -ApplicationId $appId }
Start-Process  "https://login.microsoftonline.com/common/adminconsent?client_id=$appId"

Once we run the above command global admin with the required privilege needs to grant admin consent to the information barrier processor app. This helps information barriers from removing persons from chat sessions where they are not supposed to be in them.

6) Ensure that the required data user attributes are populated in the user attribute fields which is required to identify and apply the information barrier policy.

In our example we’ve chosen 2 ideal candidates and populated the department attribute value which will be used for segmentation.

Now we need to segment users which means “Block” policies prevent sales group from communicating with research group.

In order to accomplish this task we need to connect to office365 security and compliance powershell module

In our example we can take two groups marketing and research where they both shouldn’t communicate with each other.

New-OrganizationSegment -Name "Marketing" -UserGroupFilter "Department -eq 'marketing'"

The above example creates a segment of users who are only from marketing department.

In our case we need to create one more segment of users where they belong to research team

New-OrganizationSegment -Name "research" -UserGroupFilter "Department -eq 'research'"

Now we have created the segment the information barrier policies needs to be created. Now we have to keep few things very clear in mind while applying the information barrier policies. For instance two policies cannot be applied to one segment of users. It is always advisable to make this information barrier policy to inactive status once they are created. Later we can edit this and apply for all users.

When we block communication between two segments in our case marketing and research we need to define two policies. A very important point to note is that each policy blocks communication one way only.

New-InformationBarrierPolicy -Name "Marketing-Research" -AssignedSegment "Research" -SegmentsBlocked "Marketing" -State Inactive

Now we need to create another policy to block the marketing department to communicate with research.

Activate the information barrier policy

Set-InformationBarrierPolicy -Identity GUID -State Active

We can verify the information barrier policies that we have created to ensure they have the correct values as per our requirement.

Now we need to start the information barrier policies with the below command

Start-InformationBarrierPoliciesApplication

As per the information we’ve received in the above command we need to wait for a while until the deployment gets completed in our tenant and will be successful once the status becomes completed.

Testing the information barrier policy to applied recipient.

Now logged in as Vijay Raghavan user from Marketing Team while attempting to search for Clen Richard from Research he gets an empty result.

However he is able to lookup for other users.

The users who are applied in this policy will not be able to add the blocked users in any of their teams as well.

The same thing happens for the other user Clen Richard on attempting to talk to the user from Marketing Team.

Subsequently the information barriers adds a great value to any organization to uphold the communication compliance with few easy steps from the office 365 security ad compliance center and consistently utilize Microsoft Teams.As of now information barriers apply to Microsoft Teams chats and channels only.

Microsoft Teams – Utilize the AzureADMSGroupLifecyclePolicy command to manage the teams group life cycle

Microsoft Teams, Security February 16, 2020 Leave a comment

With the Azure active directory powershell commandlets, we could control the lifecycle of office365 groups.Ideally when any office365 group is created for an action of creating a team in the backend it creates the azure ad group.With the Azure commandlets we have options to control the lifecycle of the office365 groups automatically.

Let’s say we ‘ve created Team for a partner project which completes in 1 year time period, we have got an option to expire this team in 1 year time during the team creation.This keeps the access reviews of the Microsoft Teams intact and ensures that only required persons have access to the company corporate data.

The default setting is unlimited days as it should be for most of the scenarios.

Firstly we need to connect to azuread module from the powershell. Since we do not have any group life cycle policy the value remains empty.

Below example creates a a new groupLifecyclePolicy. This policy can be applied to targeted set of office 365 groups.

New-AzureADMSGroupLifecyclePolicy -GroupLifetimeInDays 99 -ManagedGroupTypes "groupid" -AlternateNotificationEmails "sathish@ezcloudinfo.com"

The managed group type parameter provides us the option to choose how we can manage the groups in our environment. Keeping the value “None” will create the policy but will not be applied to any groups. Specifying them “All” will apply this policy to all Office 365 groups. “Selected” will provide us the option to choose specific Office 365 groups.

To test this we can try to apply this policy to single group Teams-Partners. This group was created as an action of creating a team in Microsoft Teams.


In order to apply to a group we have to run the below command by specifying the group ID.

Get-AzureADMSGroupLifecyclePolicy -Id "admsgroupid" | Add-AzureADMSLifecyclePolicyGroup -GroupId "ID"

If we need to apply this to a group of ID’s which were reviewed and require to set expiry we can apply them from a input csv.

$policy = "mentionthepolicyID"
#keep the groupid as the input value in the csv
$365group = import-csv ".\365group.csv" 
Foreach ($group in $groups) {
Add-AzureADMSLifecyclePolicyGroup -Id $policy -groupId $group.objectId}

We can run this on a periodic interval after performing access review on the Office 365 groups.There is also an option to notify the group owner on a particular period of time to review if they still require this group to be in the system. Keeping this option will remind the owner of the group who created the team to decide if they require to provide access to the users and external parties if the guest users are added to them.

We can then verify if it is applied for a group by using the commandlet Get-AzureADMSLifeCyclePolicyGroup by specifying the group id. This will return the output of to which AzureADMSgroup it have been assigned. We do have an option to extend the grouplifetime to our desired interval.

There are few organizations where the Office 365 group and teams group creation is provided as self service to users to increase the Office 365 adoption rate.In those cases the admin can review the groups created once in a month and apply the expiration policy for them.

This option will be better for the admins to create the expiry of the groups as per the company security policy.If we are doing a periodic review we can also use a input CSV for the selected groups and can apply the policy to these selected groups.

Microsoft Teams – Notify security administrator when a new team is created by the end users

Microsoft Teams, Security February 13, 2020 Comments: 3

Microsoft Teams is being used as a most preferred method of communication platform by many organizations. By default in office 365 the group creation is enabled for end users which will allow them to create public and private groups. Few organizations are having the group creation disabled on the organization level for larger scale companies and have users request for creating the teams using a request form which will run through a automation process in the background with help of azure automation accounts ,Microsoft flow or few other mechanisms.

But few organizations are really interested in allowing the users to create the Office 365 groups once their workloads are migrated to office 365. This is primarily to increase the adoption rate of Office 365 workloads Microsoft Teams and SharePoint online.

We have more options available in Office 365 cloud app security. By leveraging these options we can better secure the Office 365 suite of products which in turn controls the Data loss prevention, security compliance, information governance and threat management for the entire organization.

Through Cloud App Security –

Navigate to Cloud App Security – https://portal.cloudappsecurity.com

Select and create Activity Policy

Do not choose any policy templates – select policy severity – category as per classification – Have selected compliance in below example.

Choose the acton single activity – activity type – equals – Team Created.

There is another alternative to create the policy as below by choosing the teams app. Going with this approach provide us more options like to get notified when teamsettingchanged,cut/copy item. adding a channel, changing a channel settings and when a team is deleted. There are lot of other actions which can be added based on our requirement.

Choose the severity and specify the email notification alert with no action.

The security administrators responsible for viewing this new group creation alerts can be added over here.

Further governance actions can be specified. We have an option to notify user and cc additional user with custom message.

The custom message can be added over here. There is an option to add a hyperlink as well.

When a new team is created by the end user the specified email address is notified.

We get more information on the cloud app security alerts.

We can use cloud app security for other activities in office 365 applications as well to notify the security administrators or the SOC team, so that they will be able to monitor the events which are categorized as non-compliance in Office 365 organization according to their security guidelines.

Thanks & Regards

Sathish Veerapandian

Review and Remove inactive guest users from Microsoft Teams through Identity Governance – Access reviews

Microsoft Teams, Security January 31, 2020 Leave a comment

When an office 365 group is created, we have options to collaborate with public partner accounts .As a result of this People outside organization can see and have access to office365 public groups contents when they are been invited as guests.

When we have allowed the end users to create the office 365 groups and invite the external partners to collaborate,over a period of time the groups left unattended without the access reviews. There is a high possibility of an user having access to the sensitive documents which they don’t need them anymore.

In order to alleviate these security issues , we can influence the Microsoft Azure Identity Governance – Access reviews

With the access reviews created for office365 groups , we can let the group owners review their office 365 public group guests present on them and take necessary action based on the requirement.

In order to create access review navigate to azure portal – Identity Governance – Access reviews – Click on access review – Select New access review.

Now we can create them with name ,description , start date and frequency of how often the access reviews needs to take place for the office365 groups.

We can set the number of times, end date and the scope to guest users only. And target the external groups which have the guest users added. Probably this part needs to be reviewed periodically and add the new groups in this list.

Furthermore we have the options to customize the reviewers who will be the reviewers of this access review task.

Upon completion we have the action to choose – Remove,Approve or take recommendations.

Finally we have few options which is present in the advanced settings. Once the customization is done as per the requirement we can start the review.

Once the schedule is triggered as per the configuration the reviewers get an email with the timeline.

Once clicked on review the user gets the guest user details and the options to take action based on the business requirement.

The reviewer gets an option to type the comment and take the necessarily action.

We have the review results section where we have an option to download the access review tasks and save them for ISO audit compliance which will help during the ISO Audit Evaluation cycles.

This is usual in most of the organizations when the guest accounts are provided access to the business sensitive content. Ultimately its the group owner’s responsibility to periodically review them and take necessary actions.

There is lot more to get benefited with Identity Governance access reviews. The above method will help us in evaluating and having right access only to the required individuals in Office 365 Groups.

Regards

Sathish Veerapandian

Microsoft Teams – Enable data loss prevention,ATP safe attachments,retention of files and conversations

Microsoft Teams, Retention Policies, Security December 17, 2019 Leave a comment

Security is considered one of the success factor for any implementations.With Office 365 security and compliance there are lot of options to enforce the security across Office 365 suite of products.We can enforce DLP on Microsoft Teams based on our requirement. ATP can be turned on for all file upload activities in Microsoft Teams. The best part is that now we do have option to enable retention as lesser as 1 day in Microsoft teams channel messages and chats.

Microsoft Data Loss Prevention have been protecting sensitive information across all Office365 platforms. The easiest part is that we already have more custom built-in templates which will be easier for us to create,test,evaluate the results and finally create one for the production.

DLP Policy in Teams:

To create a dedicated DLP policy for Teams navigate to security and compliance center – Create a new policy.

In our example we are creating a new policy which will block the sharing of PAN card number via teams channels and chats.

In locations tab ensure that we are selecting teams chat and channel messages if the location is going to be only teams. If we need on all locations then we can keep them all enabled.

Under policy settings we do have lot of prebuilt templates which is super simple for us to just select and apply. In our case we are just selecting Block Indian PAN CARD number not to be shared via teams channels and chat messages.

Now we’ve created the teams data loss prevention policies and its time for us to test the created policy.

Have just logged into my test account and attempted to send a PAN Card to my account. The moment the PAN card is shared it is immediately blocked from the DLP policy.

And from the recipient end received the following message and the message is not delivered since it matches our DLP policy.

With the DLP policy we will be able to secure our sensitive information in Teams Channels and chat conversations.

Enable safe attachments on Teams Channels and chats :

Enabling ATP on Teams is pretty straight forward.

We need to navigate to protection security center – threat management – policy – select safe attachments.

All we need to do is to just select turn on ATP for SharePoint, One Drive and Microsoft Teams.

Once the policy is enabled and when somebody attempts to share an infected file the file is blocked but still present in the library, however no one will have the ability to open them from their side.

Files are scanned asynchronously, through a process that uses sharing and guest activity events along with smart heuristics and threat signals to identify malicious files.

To review the quarantined files we can go to threat management – review – select view quarantined files

Enable Retention in Microsoft Teams channels and chat conversations:

By default teams conversations and files are retained forever. With the new retention policy introduced in Microsoft teams channels and chats now admins have the option to customize the retention and delete the data forever if it is considered as liability according to the company retention policy.

In-order to create retention policies navigate to security center – select information governance – select retention – click create

Have created once dedicated policy for Teams Retention.

Now we choose the retention settings as per our requirement. The good part is that we do have the option now to retain the content lesser to even 1 day time.

Now we need to create a new retention policy for Microsoft Teams. If we try to edit the old retention policy there wouldn’t be an option to include Team Channel Messages and Chats , since these locations were on-boarded recently in the retention policy scopes.

Once selected based on the retention period all the Teams channel messages and chats are retained.

If end users delete their Teams messages, these messages are still preserved and available for search through eDiscovery for particular years based on the retention period set in the policy.

In order to recover a deleted file from channels – navigate to the channels – files tab – select open in sharepoint

Now after clicking on open in SharePoint – navigate to recycle bin and we could see the deleted file present.

We do have the same restore option like what we see in SharePoint sites.

With all the new security enhancement and retention channels enabled in Microsoft Teams it makes more convenient better communication platform for all users in the enterprise environment.

Microsoft Teams – Enforce Multifactor Authentication on guest accounts

Azure, Microsoft Teams, Security December 9, 2019 Comments: 8

Post the ignite sessions last month on Microsoft Teams, we have enhancements on security perspective that can be enabled which adds extra protection in any organization.

Inviting the external guest users to the teams channel have been a welcoming option for all of us which increases the communication between them and surges the productivity. However, there are few security guidelines that needs to be followed to ensure that our data is always secure even when they are shared outside the boundary. For instance, a guest account getting compromised where he is a member of a finance team will become a major security incident in any organization.

This article outlines the steps that can be carried over to enhance the security on Microsoft Teams guest accounts by enforcing the multi factor authentication.

Below are the steps to enforce the MFA on guest accounts:

First create a dynamic distribution group and target the guest account

Login to Azure AD Tenant with Admin privilege’s- Go to Groups – Create new group – make them security – membership type make them dynamic.

Now we need to add a dynamic query where the property is usertype  and the value is guest.

Once done populate the rule syntax and save them.

After some time now, we could see that the populated guest users in our Azure AD tenant will become the members of this group. Since it’s a dynamic query all the new upcoming accounts will be getting occupied automatically.

Create conditional access policy for guest accounts:

Now we need to create a conditional access policy for the Microsoft Teams guest accounts.

Navigate to enterprise applications – click on conditional access.

Now we need to target the dynamic group on this conditional access policy.

In cloud apps select Microsoft Teams , also better to select Sharepoint online which will enforce MFA for these Sharepoint guest users as well.

In conditions we are selecting only the locations. Further it can be manipulated based on the business prerequisite.

In the access control we are selecting only require MFA and the IT policy.

Now we have the MFA enforced on the guest accounts and we will see the action of this configuration from the invited user.

Experience of the guest users enforced with MFA:

In order to simulate this behavior , we are just adding one guest user a teams channel

Post after that the invited user receives  a welcome email and this is usual behavior for any invited Azure AD guest user accounts.

When clicking to login the user will be prompted to register and enroll in MFA.

User will be prompted to enter the mobile number in the invited tenant for MFA and needs to complete the initial authentication process.

If we have enabled the IT policy user will be prompted to read and accept the IT policy.

Finally the user is logged in with the guest account and able to participate on the invited team through a secured way of authentication.

With very nominal steps through the conditional access it creates a overall better security for Microsoft Teams.

Configure Exchange Online to reject emails that fail DMARC validation with organizations having policy of reject

DMARC, Office 365, Security October 8, 2019 Comments: 2

By default Office 365 DMARC validation for internet emails that fails for policy P=Reject will make the email to land in junk folder of the recipient mailbox. Microsoft 365 will treat DMARC policies of quarantine and reject in the same way, which means that if the sender’s DMARC policy is set to reject or quarantine, the emails that fail DMARC will be sent to the junk folder of the recipient mailbox which is by design as of now and can be found in the Microsoft Article.

Microsoft believes that the main agenda of doing this is to ensure that any legitimate emails which misses in DMARC alignment shouldn’t be lost and its better either to quarantine them or to get them delivered recipient’s junk mail folder. There are few cases wherein few organizations would still need the DMARC policy to be stringent due to their security regulations.

Microsoft validates DMARC and overrides the failure with a header value for a domain whose DMARC TXT record has a policy of p=reject oreject. Instead of deleting or rejecting the message, Office 365 marks the message as spam.

To test it further we are publishing SPF, DKIM and DMARC record for the domain ezcloudinfo.com as below:

SPF record: Adding only Exchange online as authorized sender.

DKIM Record: Having the Signing key only for office 365

DMARC Record: Having strict policy of P=reject

For a successful email from a legitimate sender where it has passed spf, dkim & dmarc we see the below value for DMARC.

dmarc=pass action=none

Now we are triggering an email from a registered mailchimp account for ezcloudinfo.com where we do not have the SPF and DKIM records added in our DNS records.

The email from mailchimp from sender address sathish@ezcloudinfo.com gets landed in junk email.

We can see the header value of above email and the DMARC validation is failed.

WorkAround:

A workaround can be accomplished by creating a Transport Rule to reject the emails that fails with the DMARC validation.

Create a Transport Rule:

Include the below value oreject or action=oreject or dmarc=fail in the message header include option.

Reject the message with the custom status code.

Now if we send a test email after this transport rule from an unauthorized sender the email will be rejected and could see the below NDR message.

So after this transport rule any spoof emails that are coming from a domain that is DMARC protected will not be delivered to the spam folder. They will all be rejected and never reach the recipient.This workaround can be beneficial for organizations where they need to strictly adhere with the RFC standard.

Thanks & Regards

Sathish Veerapandian

Enable Azure AD Password Protection for On Premise Windows server Active Directory

Azure, Security December 17, 2018 Leave a comment

In this article we will have a look at enabling Azure AD password protection policy in On Premise Active Directory Server.

By Default this feature is enabled for cloud only users with a basic filter of Azure AD password protection with global banned password list.However if we still require Azure AD password protection with custom banned password list for Cloud only users then we would need to have at-least Azure AD Basic License the default value is below.

We have below options in password protection policies:

Lockout Threshold:
How many failed sign-ins are allowed on an account before its first lockout. If the first sign-in after a lockout also fails, the account locks out again.

Lockout Duration in Seconds:
The minimum length in seconds of each lockout. If an account locks repeatedly, this duration increases.

Enforce custom list:
When enabled, the words in the list below are used in the banned password system to prevent easy-to-guess passwords.

Custom banned password list:
A list of words, one per line, to prevent your users from using in their passwords. You should include words specific to your organization, such as your products, trademarks, industries, local cities and towns, and local sports teams. Your list can contain up to 1000 words. These are case insensitive, and common character substitutions (o for 0, etc) are automatically considered.

Enable Password protection on active directory:
If set to Yes, password protection is turned on for Active Directory domain controllers when the appropriate agent is installed. 

Mode:
If set to Enforce, users will be prevented from setting banned passwords and the attempt will be logged. If set to Audit, the attempt will only be logged.

The Visual representation of how this process works is beautifully shown below from Microsoft technet Source 

Below are the prerequisites for enabling the password protection on Active Directory:

  1. For enabling this service on On Premise Active Directory it requires an Azure AD premium license.
  2. A proxy service agent needs to be installed on a member server running windows server 2012 R2 or later.
  3. Domain controllers where the Azure AD password protection DC agent service will be installed must be running Windows Server 2012 or later.  
  4. All servers running the azure AD components must be fully patched in-order to have Universal C runtime installed.
  5. Network connectivity must be present between the Azure AD proxy server and one domain controller running Azure agent Service.
  6. An Azure AD global administrator account is required to register and consume this service for On Premise AD in Azure AD.
  7. A local domain admin privilege account is required to register windows server AD with Azure AD.
  8. Domain running the DC agent service must use the DFSR replication type  for SysVol Replication.
  9. Azure AD password protection proxy service server must have access to the below Microsoft Protection Endpoints.

https://login.microsoftonline.com  –  For Handling the Authentication Requests.

https://enterpriseregistration.windows.net – Azure AD password protection functionality

       

Download the 2 agents from link – https://www.microsoft.com/en-us/download/details.aspx?id=57071

After download we will have 3 installers as below.

Azure AD Password Protection Proxy Service – It acts as a proxy agent which will forward outgoing requests from domain controllers to Azure AD and incoming requests from Azure AD to the on premise domain controller.

DC Agent password filter dll – Will receive all the password validation requests and forward them to the main component running in onpremise Domain Controller which is Azure AD password protection DC agent.

Azure AD password protection DC agent- Receives the password validation request from the filter agent and processes them with the currently present local password policy and returns the validation response Pass/Fail. This core services queries the Azure AD password protection proxy service to check and download the new versions of password policy.

First step we need to install the proxy agent on a member server which in the same domain. 

Once installation is completed Import the Module –

Import-Module AzureADPasswordProtection

Register the Proxy Agent – 

$tenantAdminCreds = Get-Credential
Register-AzureADPasswordProtectionProxy -AzureCredential $tenantAdminCreds

Enter the Domain Admin Credentials

Later Enter the Azure Global Admin Credentials

Later Register  the  Active Directory Forest –

Register-AzureADPasswordProtectionForest 

On a successful registration we will be getting the below event log on the Azure AD password protection Proxy Server.

$tenantAdminCreds = Get-Credential
Register-AzureADPasswordProtectionForest -AzureCredential $tenantAdminCreds

Register the Proxy configuration on a static Port-

Below command can be run to make the proxy service communication and DC Agent Service to run on a static specific port. This option is preferred to keep a static single port communication from this proxy service server and the Domain Controller and not to have IP to IP communication between them.

Set-AzureADPasswordProtectionProxyConfiguration –StaticPort 135

Install the DC agent on the Domain Controller. After the installation is complete only a restart is required and no further configuration is required at this stage.

After this login to Azure AD and enabled the password protection on Windows server Active Directory. Always strictly recommended to start only in Audit mode to understand the current password security and user compliance from the logs.

Once enforced in audit mode we get the below confirmation message in Azure Password protection DC Agent Event logs.

We can verify the password protection agent settings by below commands

Get-AzureAdPasswordProtectionDCAgent | FL

Get-AzureADPasswordProtectionSummaryReport -DomainController DCHostName

Its always better to start this operation by only keeping them in Audit mode since it will create a major impact in the environment without proper end user awareness about enforcing this password policy change.

Also we can monitor the logs in event viewer in below location

A user resetting the password with the compliant characters will get a successful log as below 

If there was a non-complaint password reset by a help-desk operator it would be logged in the audit mode and mention it did not meet the compliant standards.

When the same password is provided to end user and when the end user resets them with non-compliant values then those entries also will be logged in the event viewer.

A Successful password policy update from Azure AD can be seen below from the Azure AD password protection proxy server.

We can also see that a separate Container is created in ADSI Edit and can see 2 certificates folder created with thumbprint name.

Important Notes:

  1. As a best practice its not recommended to  go with enforce mode initially since the end users will have tough time adopting the password policy immediately.
  2. Once the audit mode is enabled better to circulate email floaters about the upcoming password policy change which will create better awareness.
  3. The custom banned password policy is capable of having 1000 entries. We can gradually increase the value which will make this roll out  in  a smoother way.
  4. If we are updating the global banned password in the azure portal they are pushed down to the on premise agents in a polling interval of 1 hour time period.
  5. To Register-AzureADPasswordProtectionForest cmdlet to succeed at least one Windows Server 2012 or later domain controller must be available in the proxy server’s domain.

Disable RC4 and SSLV3 encryption for applications

Security August 4, 2016 Leave a comment

Once any web application is deployed its always recommended to perform a thorough security testing to identify if there are any security risks.

In this article im just sharing my experience to disable RC4 and SSLV3 for applications hosted on Windows Servers.

We can use the below URL site to test the server configuration for HTTPS protocol
https://www.ssllabs.com/ – that will test your server’s configuration for the HTTPS protocol

Why RC4 needs to be disabled ?

RC4 should not be used, due to crypto-analytical attacks.
It’s been more than 25 years since Ron Rivest invented his RC4 stream cipher but still being used by legacy clients and browsers.

How RC4 Encryption Works:

A ciphersuite consists of a key exchange algorithm, an encryption method and an integrity protection method.
RC4 is a stream cipher, so it encrypts plaintext by mixing it with a series of random bytes used to encrypt it. But, the bytes used to encrypt the plaintext aren’t really as random as they should be, at least at the beginning of the process.

That makes it possible for an attacker to figure out the plaintext of an encrypted message with access to enough TLS requests. The problem is that there are biases in the keystream, making life easier for an attacker.

Why its not Disabled by default on Windows Server 2008 R2, 2012 R2 ?

Unfortunately, servers default configuration tends to support backward compatibility  as well over security.
They are enabled by default only for supporting older versions of browsers and operating systems.
Basically we need to disable this on apps running Windows Server 2008 R2 , 2012 R2 and IIS.

Preventive Measures for RC4 Attack:

As a security its always recommend to use TLS 1.2 or above. So its better to disable them and support only the latest type of encryption.

Disable Ciphers by adding the below registry entries on the server hosting the application.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128]
“Enabled”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]
“Enabled”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]
“Enabled”=dword:00000000

Disable SSLv3:

A Small history on SSL

SSLv1 was never publicly released.
SSLv2 was quickly found to be insecure.
SSLv3 was created, and, together with the newer TLSv1/1.1/1.2, it is still currently being used to secure the transport layer of the Internet.

Weakness of SSL V3:

Last year Google Engineers found the major loophole in SSLV3 with an exploitation technique known as POODLE Attack.
This is a plaintext recovery attack that focuses on HTTP headers and exploits a weakness in the SSLv3 protocol when used with block ciphers.
Its a protocol vulnerability attack.
So now its recommended to disable the SSLV3 on server side.
Preventive Measures for SSLV3 Attack:
Disable SSL V3 by adding the below registry entries on the server hosting the application.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client]
“DisabledByDefault”=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]
“Enabled”=dword:0000000
Always advisable to have encryption of more than TLS 1.2.

Note:
1) If you have this security enabled on the reverse proxy application through which your services are published, then the session for those connections will be terminated there itself.
But still its better to have this disabled on all the applications which are serving the clients.
2) Its very important to note that before disabling this type of connections we need to make sure that the application is not serving any clients with this encryption.If at all its found we need to make that application to work on TLS1.2 or later.

Thanks & Regards
Sathish Veerapandian
MVP – Office Servers and Services

%d bloggers like this: