Application Firewall

Skype for Business MDM Binding

Highlights

  • Intercepting, inspecting and validating all anonymous in the DMZ
  • Rewriting requests by session termination
  • Blocking malicious requests from entering the DMZ
  • Protocol Level Sanitization
  • Application data validation in DMZ including meeting ID
    Device pre-authentication

SkypeShield offers an innovative solution for securing guest and anonymous requests entering corporate networks.

The Problem

As part of the Skype for Business (Lync) topology, requests are sent anonymously to the Skype for Business front server in the corporate network without having been authenticated or inspected. Allowing these requests, which might contain malicious code, pass through DMZ firewalls without control represents a serious and immediate security risk that must be addressed.

The most common example is the case of an external guest who wishes to join a meeting. In this case, an anonymous request is sent directly to the internal server. This request does not require a valid meeting ID or authentication in order to pass into the network server.

Another example is approaching anonymous services in the process of authentication, but still before the authentication occurs.

Common attacks take advantage of known and unknown vulnerabilities in the network protocols to execute operations that are not approved by design. Some of the techniques used generate or modify valid requests with data that looks valid, but maliciously alters the server’s behavior.

Common malicious requests exploit the servers at the protocol level, before the request reaches the application service.

The Solution

SkypeShield’s new application firewall offers a solution for such security vulnerabilities by intercepting all anonymous Skype for Business traffic in the DMZ and validating them before allowing them to enter the domain network.

The application firewall has three main parts:

  • Request Rewrite – session termination in the DMZ and rewrite of the request to be sent into the domain
  • Protocol Level Sanitization – inspecting the traffic to validate the structure of the traffic as expected by the protocol
  • Application Level Inspection – validating that the data content matches what is expected by the server
  • Device Pre-authentication – performing device validation before allowing any request to enter the domain

Request Rewrite

The most effective way to make sure no malicious code is injected into a request is to rewrite the request on the firewall layer. Doing this will eliminate the risk of most protocol and application level attacks as it will not allow the original request to enter the domain.

The application firewall performs session termination of the request and creates a new request with the same parameters built as expected by the server schema. This concept blocks, by design, any extra code injected into the original request.

Protocol Level Sanitization

The application firewall protects the internal servers by performing a wide set of sanitized filtering operations detecting malicious requests and blocking them from passing to the DMZ.

Some sanitization examples include request schema structure validation such as the number of parameters, their length and type, headers inspection, including number of headers of each type, and header values.

Application Level Inspection

The application level protection handles attack vectors exploiting vulnerabilities at the application level.

Attackers may modify expected data and inject malicious exploit code that can change the behavior of the server application or stored user data.

The application level firewall verifies that the data sent is in a correct format and has the expected value. It will verify the value with the server, using a different thread, before allowing the request to go through. So, for example, in the case of a guest joining a meeting, it will verify that the meeting ID is of a valid length and content and that it exists as a valid meeting at the time sent. In this case, an attacker will not receive access to any resources of the Skype for Business Web App page or Web ticket service.

Device Pre-authentication

This module verifies that the device is registered before allowing any request to go through into the domain both at the pre-authentication stage as anonymous and also at the authentication stage reaching the active directory. This design also adds an important measure against account lockout. In the case of an attacker sending only a valid username without knowing the password, he would fail to reach the active directory without using a valid device. This module also handles pre-authenticated requests reaching the front-end servers which are anonymous, such as topology-related requests until the device is approved.

By combining the three protection layers with other security layers, SkypeShield offers full protection for anonymous requests.

They include the following services:

  •  Guest meeting access
  •  Auto discovery
  •  Lync discovery requests
  •  Dial-in services
  •  Web Ticket services