How to Configure SfB Application Firewall?

Owned by Agat Support
Last updated: Apr 06, 2022 by Avi J. Levin (Unlicensed)

The application level protection handles attack vectors exploiting vulnerabilities at the application level.
Attackers may modify sent 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 an expected value.
It verifies the value with the server prior to allowing the request through. For example, in the case of a guest joining a meeting, it will verify that the meeting ID is of a valid length 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.

By combining the three protection layers with other security layers, SphereShield offers full protection for anonymous requests.
This includes the following services:

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

The Problem

As part of the Skype for Business usual operations, 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 traffic reaching anonymous services as part of an authentication process, but before the authentication is concluded.
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 to 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

SphereShield’s 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 four main parts:

  •  Request Rewrite – Session termination in the DMZ and rewrite of the request to be sent to the domain
  • Protocol Level Sanitization – inspecting the traffic to validate the structure of the traffic as expected by the protocol.
  •  Application Level Inspection – validating 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 schemas structure validation such as the number of parameters, their length and type, request methods, header inspection, including the number of headers of each type, and header values.

Application level Inspection

Verifies the application server is willing to receive the request.

Application Firewall Settings

In order to get to the Application Firewall Settings, login to the Admin Portal Admin area → Settings → Application firewall, or by using the following URL: /admin/settings?category=application_firewall_settings


Meeting protection

The Meeting Protection feature provides protection from malicious attempts to get into the meeting page by using fake or expired meeting IDs.


Meeting protection - If set to 'Yes', enables Meeting protection.

Base meeting URL - The meeting URL which is used to access the meetings of your organization, for example: skype.company.com/meet. If you have more than one base meeting URL, separate them by using | , for example : Skype.comany.com/meet|Skype2.comapny.com.

Maximum meeting ID length - The maximum length of your meeting ID, usually 8.

Monitoring mode - If set to 'Yes', will only log potential malicious attempts but will not block them, if set to 'No', the Application Firewall will block these attempts.

Sanitization

The Sanitization feature provides protection from malicious requests and injections and gives us the ability to block or monitor those.


Incoming traffic sanitization - If set to 'Yes', enables traffic sanitization.

Monitoring mode -  If set to 'Yes', will only log potential malicious requests, but will not block them. If set to 'No', the Application Firewall will block these requests.


Application Firewall Access Rules

Enables whitelisting/blacklisting of specific requests.

Host regular expression - Enter the Host name to be checked (I.E.- dialin.company.com)

URL regular expression - Enter a regular expression to be matched to (I.E - /dialin).

Enable Application Firewall rule - Choose if to enable this rule (Yes/No).

Application Firewall rule action - Choose the type of action to be done when a request matching the rule has been detected (Allow Only/Block).