Security Configuration

Cloud security breaches are becoming an increasing threat with the unprecedented pace at which Cloud Service Delivery Model is getting adapted by businesses and governments. Although shifting to cloud technologies is affordable and fast, businesses are increasingly vulnerable to security breaches and are ill-equipped to counter the sophisticated security threats that can bring the infrastructure down and expose business critical and sensitive data to threats. Hence, it becomes increasingly important for organizations to have real-time insights into application traffic and have strong security policies and controls in place to counter these attacks.

This diagram shows the major concerns in cloud security-Data Privacy and Data Loss.

_images/image810.png

The Security Policies in A10 Lightning ADC provides you with advanced techniques to control server response, prevent threats, and protect sensitive information. You can configure the application security policies and configurations in A10 Lightning ADC from the Security tab in the Settings page, and the Security Policies tab in a SmartFlow.

Application Layer Data Theft Protection (WAF)

A10 Lightning ADC Web Application Firewall (WAF) is an elastic service for application security with pre-configured rule sets and one-click provisioning. WAF helps defend against malicious activity, web attacks, and application attacks.

Inbound and Outbound Traffic Inspection by WAF

The figure below explains how WAF is deployed in the network traffic to perform inbound and outbound traffic inspection. Some of the attacks detected (For example, malware, web shells, backdoor, and so on) are detected at the response traffic, and the rest of the attacks (For example, application attacks) are detected at the request traffic.

_images/WAF.png

The cloud-specific WAF configured in the Lightning Application Delivery Controller (LADC or LADCs) provides real-time protection against application vulnerability attacks on a per application basis.

The A10 Lightning ADC architecture provides the added advantage that when new LADCs come up in your application infrastructure, the LADCs can share the same WAF configurations. The elastic WAF service scales to ensure that sufficient resources are available to process the incoming traffic. Hence you need not re-configure WAF for each new LADC added to the deployment. The application security policies (including the WAF policy) scales up as the application infrastructure expands.

What’s more, single pass integrated execution for WAF, load balancing, and other application delivery directives minimizes latency across the data plane. In A10 Lightning ADC, security policies can be quickly enabled in the Cloud Services Controller (CSC) and changes are propagated to all LADCs in an LADC cluster. This way, an attack can be quickly mitigated.

The figure below shows a typical WAF deployment scenario in the LADCs. WAF inspects incoming traffic and lets legitimate traffic flow through it.

_images/image276.png

Note

When configured in the Active mode, WAF blocks all malicious traffic based on the generic or application protection configurations. In Passive mode, WAF provides a warning to the user and lets all traffic (including malicious traffic) pass through it. See Configuring Web Application Firewall for more information.

One-Click Provisioning

Web Application Firewall (WAF) provides simpler provisioning of application-specific rules for modern web applications, and safeguards cloud applications with higher levels of security and compliance. Provisioning and Updating security rules for the broad range of applications used by enterprises are incredibly complex and pose an ongoing challenge for IT teams. A10 Lightning ADC significantly decreases the time required to a provision by providing a one-click rule set which instantly deploys thousands of preconfigured rules to secure popular applications against known threats immediately.

A10 Lightning ADC WAF includes preconfigured rule sets that protect against top common vulnerabilities (such as SQL injection and Cross-site scripting), and specific attack vectors in popular Web Applications like Microsoft SharePoint, Outlook Web Access, WordPress, Joomla, and others. This capability takes the guesswork out of determining what security controls are essential for each application, reduces false positives, and reduces the time for deploying application security to seconds.

Note

See Configuring Web Application Firewall and Configuring Application Security WAF Policy for more information on WAF configuration.

Additionally, provides daily automatic ruleset updates, reducing the risks from emerging attack vectors, and minimizing the occurrence of false-positive vulnerability reports.

Inheriting WAF Security Policy

The WAF security policies can be applied both at Global/Application level as well as Smartflow level. When applied at Application level the same policies can be inherited at Smartflow Application Security. At the Smartflow level, the user gets to choose three application security policy setting options; those are Inherited, Enable, and Disable. To inherit the security policies same as the Global level user can choose Inherited option. If the user prefers to customize the security policies at Smartflow Application Security level, then can select Enable option. Choose Disable option to disable the policy.

The below figure shows the Security policy option available at Application level:

_images/image2.31.png

The below figure shows the Security policy options available at Smartflow level:

_images/image2.30.png

WAF Operation Modes

WAF has two exclusive modes of operation:

Active mode: In Active Mode, WAF prevents common threats from reaching the application server based on the configurations in this mode.

To know more about how to configure WAF in active mode, you can check out the following video

Passive mode: In Passive Mode, WAF allows malicious traffic to pass through but with a warning to the IT administrator. In other words, in this mode, WAF raises alerts when threats are detected but do not block the threats.

_images/image1231.png

To know more about how to configure WAF in passive mode, you can check out the following video

You can creat custom alerts using LADS alert functionality. You can find more details in the following video

Configuring WAF Operation Modes

Follow the below steps to configure WAF policies in Generic Protection Mode in A10 Lightning ADC:

  1. In the A10 Lightning ADC screen click on Configuration > Services > Edit SmartFlow
_images/image2.0.png
  1. In the edit SmartFlow screen, under policies click Security Tab > Application Security. And then, select an option to Enable, Disable, or to Inherit the policies at SmartFlow level.
  • Enable: Enables the Application Security at SmartFlow level.
  • Disable: Disables the Application Security at SmartFlow level.
  • Inherited: Inherits the default security policies set at the Application level for the SmartFlow traffic.
_images/image2.1.png
  1. Set the WAF policies for Generic Protection Mode.
_images/image2.2.png

WAF Protection Modes

These are the two types of WAF protection modes:

Generic Protection Mode

Most common forms of threats, such as SQL Injection and Cross-Site Scripting, are prevented in this protection mode.

Application Protection Mode

Specific application types with known vulnerabilities are protected. There is also an option to disable the protection mode in WAF.

Generic Protection Mode

Perform the steps below to configure WAF policies in A10 Lightning ADC in the Generic Protection Mode:

  1. In the A10 Lightning ADC screen click on Configuration > Services > Edit SmartFlow
  2. In the edit SmartFlow screen, under policies click Security Tab > Application Security. Enable Application Security policy by clicking the Enable button. Select Active WAF Mode by choosing Active radio button.
_images/image2.2.png

Select the Protection Mode as Generic. Here, you can select the generic attack categories that should be identified and blocked from the generic attack categories listed on the screen.

  • SQL Injection: Hackers inject SQL commands to access or delete database information.
  • Cross-Site Scripting (XSS): Attackers introduce client-side scripts in web pages to bypass access controls and bring down applications and web sites.
  • Remote Command Execution: Attackers, use a breached application to execute random commands on the host’s operating system.
  • Remote File Inclusion (RFI): This involves using remote files located on the server to launch an attack.
  • Local File Inclusion(LFI): This involves using local files located on the server to launch an attack, instead of remote files.
  • Broken Session Management: By default Cross-Site Scripting and SQL Injection attacks are seen selected. You can select multiple categories using the Ctrl key or select all groups using Ctrl + A key combination.

Application Protection Mode

Perform the steps below to configure WAF policies in A10 Lightning ADC in the Application Protection Mode:

  1. In the A10 Lightning ADC screen click on Configuration > Services > Edit SmartFlow
  2. In the edit SmartFlow screen, under policies click Security Tab > Application Security. Enable Application Security policy by clicking the Enable button. Select Active WAF mode by choosing Active radio button.
_images/image2.3.png

Select the Protection Mode as Application. The Application Types are listed on the screen. Select the Application Types that should be protected from threats using WAF.

IP Reputation

IP Reputation-based Traffic Filtering To prevent geographically distributed DoS attacks which can span multiple networks, A10 Lightning ADC WAF provides the IP Reputation-based filter which can apply to applications in different geographic regions or collection of regions.

IP addresses can be filtered based on the following categories:

TOR Exit Nodes: The IP addresses that are identified as TOR nodes. Malicious Attack Sources Identified from Web Honeypots: Filter IP addresses of malicious sources identified from web honeypots. When malicious IP addresses are identified with the IP Reputation-based filter, WAF blocks these attacks and records attack-related information in the logs.

Configuring IP Reputation

Perform the steps below to configure IP Reputation-based traffic filtering in A10 Lightning ADC:

  1. In the A10 Lightning ADC screen click on Configuration > Services > Edit SmartFlow (the Pencil icon)
  2. In the edit SmartFlow screen, under policies click Security Tab > Application Security. To enable IP Reputation, check the box next to it, as shown on the screen. And then, save the security policy.
_images/image2.4.png

Block Sensitive Data

When Block Sensitive Data WAF policy is enabled it allows A10 Lightning ADC to block certain patterns from being captured by the intruders who are trying to attack or capture such data. For now this policy is designed to block sensitive data such as credit card or debit card number to be exposed to the outsiders.

Webshell/Backdoor Detection and Prevention

There are many methods attackers employ to upload Web shell backdoor code onto compromised web servers including Remote File Inclusion (RFI), WordPress Tim Thumb Plugin and even non-web attack vectors such as Stolen FTP Credentials. Web shells can be written in any language that a server supports and some of the most common are PHP and.NET languages. These shells can be extremely small, needing only a single line of code or can be full featured with thousands of lines. Some are self-sufficient and contain all required functionality while others require external actions or a “Command and Control”9D (C&C) client for interaction. When the shell is installed, it will have the same permissions and abilities as the user who put it on the server. A10 Lightning ADC can identify if a client is accessing a web shell/backdoor resource on your website/application by inspecting outbound HTTP data.

A10 Lightning ADC implementation included access to thousands of captured web shells and developed custom detection rules including detections for:

  • C99 Shell
  • R57 Shell
  • WSO
  • PHP Shell
  • Stun Shell
  • JCE File Upload Shell
  • Basic File Uploader

A10 Lightning ADC can detect and block any web shell/backdoor’s to your application.

Configuring Web shell

Perform the steps below to configure Web shell/Backdoor Detection in A10 Lightning ADC:

  1. In the A10 Lightning ADC screen click on Configuration > Services > Edit SmartFlow (the Pencil icon)
  2. In the edit SmartFlow screen, under policies click Security Tab > Application Security. To enable Web shell, check the box next to it, as shown in this screen. And then, save the security policy.
_images/image2.5.png

Botnet Attack Detection and Protection

Attackers build networks of infected computers, known as botnets, by spreading malicious software through emails, websites, and social media. Once infected, these machines can be controlled remotely, without their owner’s knowledge, and used as an army to launch an attack against any target. Botnet attacks attempt to execute botnet code on the server to spread infection.

Botnets can generate huge floods of traffic to overwhelm a target. These floods can be produced in multiple ways, such as sending more connection requests than a server can handle, or having computers send the victim massive amounts of random data to use up the target’s bandwidth.

Enabling Botnet Protection at Layer 7 (Application Layer)

Perform the steps below to enable Botnet Protection in A10 Lightning ADC:

  1. In the A10 Lightning ADC screen click on Configuration > Services > Edit SmartFlow (the Pencil icon)
  2. In the edit SmartFlow screen, under policies click Security Tab > Application Security. To enable Botnet, check the box next to it, as shown in this screen. And then, save the security policy.
_images/image2.6.png

BOT Protection

A bot attack is an unwanted request or set of requests originating from a bad BOT client to your network. Bad bots consume bandwidth, slow down your server, steal your content and look for vulnerability to compromise your server.

An Internet Relay Chat (IRC) bot is a set of scripts or an independent program that connects IRC as a client and so appears to other IRC users as another user. An IRC bot differs from a regular client in that instead of providing interactive access to IRC for a human user; it performs automated functions. A10 Lightning ADC can detect and alert on standard attacks originating from IRC Bot clients.

A10 Lightning ADC looks at URL, parameters, user agent, and request body in some cases, to detect a botnet attack. In particular, |ADS|checks the following categories to detect a dangerous Bot attack:

  • Common IRC Botnet attack command string
  • Common types of Remote File Inclusion (RFI) attack methods
  • URL Contains an IP Address
  • The PHP “include()”9D Function
  • RFI Data Ends with Question Mark(s) (?)
  • PHP Injection attack
  • RPC PHP Injection attack
  • SQL Injection attack
  • Local File Inclusion ENV Attack in User-Agent
  • e107 PHP Injection attack
  • XML-RPC PHP Injection attack
  • OsCommerce File Upload attack
  • Oscommerce File Disclosure and Admin ByPass
  • Zen Cart local file disclosure vulnerability
  • Opencart Remote File Upload Vulnerability
  • e107 Plugin my_gallery Exploit
  • Configuring protection against bad BOTs
  • Local File Inclusion attack

https://www.owasp.org/index.php/Testing_for_Local_File_Inclusion

|ADS|subscribes to the IP reputation list as well as user-agent reputation list for identifying known bad BOTs. Eliminates the traffic from bad BOTs; hence, enhancing the performance of your application servers.

Analytics on BOT Protection

You can use the dashboard (Analytics > Dashboard) to get more insights on BOT Protection.

For example, you can view the percentage of BOTs in the total number of threats detected in the Top Threats pie diagram in the Dashboard.

./images/image80.png

Note

See Application Security Analytics and Insights section for more information.

Malware Protection

Web-based Malware is a growing threat to today’s Internet security. Attacks of these types are very prevalent in a cloud and lead to serious security consequences. Millions of malicious URLs are used as distribution channels to propagate malware all over the Web. After being infected, victim systems fall in control of attackers, who can utilize them for various cybercrimes such as stealing credentials, spamming, and distributed denial-of-service attacks. Moreover, it has been observed that traditional security technologies such as firewalls and intrusion detection systems have only limited capability to mitigate this issue.

A10 Lightning ADC provides Web-based Malware detection by inspecting HTTP response. The Malware Detection checks the response data for malicious code aimed at attacking clients.

Payloads are matched against:

Location Response Headers that redirect users to malware sites, and Response Body Payloads that may contain off-site links (scripts and iframes) or full payloads.

A10 Lightning ADC identifies Web-based Malware in many categories including:

  • Drive-by-Download URLs
  • Malicious Redirect URLs
  • Malicious JS Payloads

Configuring Web-based Malware Detection

Perform the steps below to enable Web-based Malware Detection in A10 Lightning ADC:

  1. In the A10 Lightning ADC screen click on Configuration > Services > Edit SmartFlow (the Pencil icon)
  2. In the edit SmartFlow screen, under policies click Security Tab > Application Security. To enable Web-based Malware Detection, Check the box next to it, as shown in this screen. And then, save the security policy.
_images/image2.7.png

Cross-Site Request Forgery(CSRF)

Cross Site Request Forgery (CSRF) is one of the most common web application attacks. CSRF occurs when a malicious website, email, blog, or any other program which causes the user’s to perform an undesired function on a trusted site for which the user is currently authenticated. The request from the browser includes any information associated with the browser session or website, such as a cookie, passwords, and so on. A Cross Site Request Forgery (CSRF) attack occurs when the user is authenticated to the site, or when the user clicks on a malicious link, button or any malicious HTML element.

Hence, to overcome such attacks A10 Lightning ADC implements a defense mechanism against CSRF by including a hash element in the form submitted by a user. Now, if the attacker wants to access the form submitted, he will need to know the unique key used to create the hash. To add more protection, the hash key generated is made unique for each user sessions. Hence, making it difficult for the attacker to predict its value, avoiding CSRF attacks. The CSRF security feature can be enabled either at the Application level or SmartFlow level by inheriting the default security policies set at the Application level or by enabling the Application security at SmartFlow only.

While enabling the CSRF, the form action URLs that need to be protected is an input parameter. LADC looks at the responses and adds a hash to all the forms for which the action URL matches with the configured URL. It inspects the requests, and if the request URL matches with the configured form action URL, it verifies the hash value in the request. If the value is not present or is incorrect, then the request is blocked.

Configuring Cross Site Request Forgery (CSRF)

Perform the steps below to enable CSRF in A10 Lightning ADC at the Application level:

  1. In the A10 Lightning ADC screen click on Configuration > Application > Security > Application Security
  2. In the Application Security screen. To enable CSRF, check the box next to it, as shown in this screen. And then, save the security policy.
_images/image2.28.png

Function Level Access Control

The Function level access control attacks could result from the inadequate security of sensitive request handlers within an application. An application may only hide access to sensitive actions, fail to enforce sufficient authorization for certain activities, or inadvertently expose an action through a user-controlled request parameter. These attacks could be much more complex and be the result of subtle edge-cases in the underlying application logic.

A10s Function Level Access Control feature eliminates such attacks by adding a sign in all the links we get in Href, Form action, Iframe source, Frame Source, Location Response Header. If a sign mismatch is identified then the request is not allowed to proceed, thus eliminating Function Level Access Control attacks.

While enabling the Function Level Access Control, the form action URLs that need to be protected is an input parameter. LADC looks at the responses and adds a hash to all the forms for which the action URL matches with the configured URL. It inspects the requests, and if the request URL matches with the configured form action URL, it verifies the hash value in the request. If the value is not present or is incorrect, then the request is blocked.

Configuring Function Level Access Control

Perform the steps below to enable Function Level Access Control in A10 Lightning ADC at the Application level:

  1. In the A10 Lightning ADC screen click on Configuration > Application > Security > Application Security
  2. In the Application Security screen. To enable Function Level Access Control, check the box next to it, as shown in this screen. And then, save the security policy.
_images/image2.29.png

Dealing with False Alarms

The A10 Lightning ADC Application Security Exceptions feature allows a user to create an exception for application security rules to handle false positives (an attack detected by the application security, but not one). These false positives are blocked based on the conditions defined in the rules and many other parameters. In some cases, if the user wants such false positives to be allowed even if it looks like a threat or attack but not one, then exceptions are created to overwrite few conditions defined in rule and allow such false positives. The Application Security and Application Security Exceptions are two different policies. However, the exception policies can overlook the security policies set in A10 Lightning ADC.

Creating Exception Rules

Follow the steps below to create an Application Security Exceptions:

  1. Click on Configuration > Secutiry > Application Security Exception
_images/image2.8.png
  1. Click Add Rule > Select Rule Type > Select a URL condition form the list > Select a Parameter from the list > Select a Apply Rule On condition**
_images/image2.9.png

However, these exceptions can also be set up from Analytics > Logs, or from Analytics > App Dashboard > Blocked Request > Logs screen. The Application Security and Application Security Exceptions are two different policies. However, the exception policies can take precedence over the security policies set in A10 Lightning ADC.

Creation of exceptions can be seen in the following recording

SSL Termination

Secure Socket Layers (SSL) provides your visitors and businesses with an additional layer of security in deployment scenarios.

Elastic SSL refers to auto-scaling of SSL operations (handshake plus bulk encryption/decryption) based on SSL traffic. A10 Lightning ADC provides elastic SSL that ensures autoscaling of SSL resources with the increase in the user traffic to the site.

A10 Lightning ADC offloads resource-intensive SSL encryption and decryption tasks to autoscaling Cloud Services Proxy servers that are adjacent but separate from your dedicated application servers. This efficient architecture enables consistently high throughput at any traffic level providing processing efficiency and cost savings.

In a typical A10 Lightning ADC deployment, the Lightning Application Delivery Controller (LADCs) are delivered as an elastic, highly available, resilient cluster. The cluster autoscale to support variable workloads.

Use A10 Lightning ADC’s elastic infrastructure to extend SSL capacity without changing your application code or web servers. Gain visibility into SSL traffic, behavior and potential attacks with A10 Lightning ADC’s comprehensive application delivery analytics dashboards.

SSL between Client and Proxy

SSL Settings for an Application Domain

A10 Lightning ADC accepts client requests for the domain names configured as application domains. When you onboard an application in A10 Lightning ADC, an application domain is created by default (based on your application endpoint).

Follow the steps below to configure the SSL settings for an Application Domain(s):

  1. Click Configuration on the A10 Lightning ADC screen, from the drop-down list click Application.
  2. Click SSL Settings from the application settings screen.
_images/image2.10.png
  1. For each Application Domain (FQDN) provide the SSL Settings inputs if SSL is enabled on the A10 Lightning ADC.
_images/image2.11.png

When you enable SSL in A10 Lightning ADC, the following options are displayed:

Server Certificate Chain

For an SSL certificate to be trusted, the certificate issued must be by Certificate Authority(CA) that is included in the trusted store of the connecting device. If a trusted CA does not issue the certificate, the connecting device (For example, the web browser) displays an error. However, if the issued certificate is from a trusted source, then the connecting device establishes a secure and reliable connection. The list of certificates from the root certificate to the end-user certificate represents the SSL server certificate chain.

While entering the server certificate chain in the SSL settings for your application domain, you must link your server certificate chain of your CA to ensure that you are providing the complete server certificate chain.

Server key

The private key of the application server which is required to validate the SSL Certificate.

Choosing an SSL Versions

A10 Lightning ADC uses TLS (Transport Layer Security), and SSL (Secure Sockets Layer) protocols for secure transmission of data between the A10 Lightning ADC and Application servers.

You can select one or more TLS/SSL versions from this list.

TLS (Transport Layer Security) and SSL (Secure Sockets Layer) are protocols that provide data encryption and authentication between applications and servers in scenarios where the data is sent across an insecure network.

Note

That the terms SSL and TLS are often used interchangeably or in conjunction with each other (TLS/SSL), but one is, in fact, the predecessor of the other SSL 3.0 served as the basis for TLS 1.0.

Choosing an Ciphers

A cipher is an algorithm used to encrypt and decrypt data. When a client initiates an SSL connection with a server, the client and server must agree on a cipher to use to encrypt information. In any two-way encryption process, both parties must use the same cipher. The cipher used depends on the current order of the cipher list kept by the server. The server chooses the first cipher presented by the client that matches a cipher in its list.

You can choose the supported cipher algorithms from the list for secure SSL connection between A10 Lightning ADC and the application server.

Configuring SSL while adding Listening Ports

The application traffic is listened by A10 Lightning ADC on the listening port. Note that, before adding any Http2 or SSL ports as a listener port make sure the SSL is enabled.

To enable the listener port go to Application Settings screen and click Add Port/Listner. Here, enter the listening port number and choose SSL or Http2, and then, click Save button.

_images/image2.12.png

SSL between Proxy and Server

Secure Sockets Layer (SSL) Certificates (also called digital certificates) allows establishing a secure encrypted connection between A10 Lightning ADC and application servers. Hence, protecting the sensitive data exchanged during each session.

SSL certificate provided must be from a trusted source for an application server to install and enable SSL connection. The SSL certificate is indicated by a padlock icon in web browsers, but it is also indicated by a green address bar. On completion of SSL installation, A10 Lightning ADC can be accessed securely by changing the URL from http:// to https:// ensuring that the information you enter is secure over this session.

Follow the steps below to add a Service in A10 Lightning ADC:

  1. Click Configuration on the A10 Lightning ADC screen, from the drop-down list click Services.
  2. Click ADD NEW SERVICE from the Services settings screen.
_images/image2.13.png
  1. The Add New Service window displays the following SSL settings.
_images/image2.14.png

Click on the relevant help buttons to get more information on these options; these options are displayed in the Add Service window if SSL is enabled.

Validate Certificate

Mark the checkbox, if you want to enable SSL certificate validation.

The value of SSL is protected by a standard two-point validation process:

  1. Verify that the applicant owns, or has the legal right to use, the domain name featured in the application.
  2. Verify that the applicant is a legitimate and legally accountable entity.

Note

Certification Authorities (CAs) perform SSL validation and have a responsibility to ensure that they issue SSL Certificates only to legitimate applicants.

Exposure Reduction

Header Rewrite

HTTP header rewrite helps to rewrite HTTP request or response headers of the content exchanged between a client and a server. It is often used to keep compatibility between old and new URLs, to turn user-friendly URLs into one’s CMS friendly, and so on. It is also used to mask the information leaked by the application servers in the HTTP headers. Attackers may use this leaked information to identify potential vulnerabilities and launch an attack.

Configuring Header Rewrite Policy

Follow the steps below to configure a rewrite policy for an HTTP header rule in A10 Lightning ADC: To edit the default Smart Flow:

  1. Click on Configuration > Services > default-smart flow > Edit Smart Flow
_images/image2.15.png
  1. Click on Security > Header Rewrites
_images/image2.16.png
  1. Enable the access policy using the Enable button. By default, the screen displays three X-Forwarded header screens.
_images/image2.17.png

Enter the header name for the required X-Forwarded header screen. Enter the variable names for Header Value.

For example, for X-Forwarded For screen, enter these variables: $http_x_forwarded_for

Enter the variable corresponding to the client IP address here. $remote_addr

Enter the variable corresponding to the proxy through which the request passes. Select the header rewrite Action. Enable the rules and save the policy. Save the SmartFlow.

The Action tab displays the following actions:

_images/image74.png

Returning Custom Content

Action Policies (Alias Response code or Redirect URL)

Action policies allow you to configure rules or action policies which specify a custom content return to the user (For example, an alias response code) for the response codes coming from an application server(s). The action policies enhance the user experienceE2f (For example, if you want to hide a particular response code from the user you can specify an alias code in the action policy configured in the LADC so that the user sees the alias code instead of the response code that you want to hide).

Configuring Action Policy Rules

Follow the steps below to configure the Action policy in A10 Lightning ADC:

  1. Click on Configuration > Services > default-smart flow > Edit Smart Flow
_images/image2.15.png
  1. Under Policies> Traffic > Action > Enable to view the Action policy configuration screen.
_images/image2.18.png

In the action policy rules, you can do the following:

  • Set up alias response codes or alias response URLs that LADC should provide the user for response codes coming from the Application server.
  • Redirect the user to a redirect URL.
  • Add more than one action policy rule.
  • Configure Action policy rules from the Security tab (Path: Configuration> Security)by enabling Allow merging of rules.

Mask Policy

Masking allows you to control how servers respond to a user, thereby, increasing application security.

Configuring Mask Policy

Follow the steps below to configure the Mask policy in A10 Lightning ADC:

  1. Click on Configuration > Services > ADD SMARTFLOW > Edit SmartFlow
_images/image2.15.png
  1. Under Policies> Security > Mask > Enable to view the Mask policy configuration screen.
_images/image2.19.png

The Mask policy configuration has three options:

  • Remove Server Header from Response: Turn on this option to prevent users from knowing what type of web server is used in your operations.
  • Remove ETag Header from Response: Activate this option to avoid unethical users from knowing about your website hosting on multiple servers.
  • Return HTTP 404 if the server returns HTTP 5xx: Enable this option to ensure users receive friendlier error messages, rather than having to read complicated error messages.

Sensitive Data Exposure

In cookie poisoning attack, unauthorized access is made into the application by modifying the contents of the cookie. Solutions to this attack include cleaning up the cookie or encrypting cookie data.

A10 Lightning ADC can be configured to provide cookie security by encrypting or suppressing cookies information. When cookie security policy is enabled, if A10 Lightning ADC detects that a cookie does not have a valid signature and does not follow the correct format, it identifies a “Session Cookie Tampering”9D incident. Thus cookie security policy helps to prevent session cookie tampering.

Access Control

IP Access Policy

Access Policies (Whitelists and Blacklists)

Access Policies allow you can define access policies by specifying allow or deny rules for traffic from IP addresses. Specify the IP address from which traffic should be allowed or denied. Hence, providing the mechanism to build white-list (allow rules) and black-lists (deny rules) which allows requests based on the IP address or denies unwanted traffic.

_images/image2.21.png

Whitelist helps in preventing DDoS by allowing traffic only from trusted sources. Blacklist helps in preventing DDoS attacks by restricting traffic from known attackers.

Order of rules

User can specify network address instead of just IP The importance of the keyword ‘all’. An example displaying combination of allow/deny rules using individual IP, network address, and ‘all’

Configuring Allow Rule

Perform the steps below to configure an Allow rule in A10 Lightning ADC.

  1. Click on Configuration > Services > default-smartflow> Edit SmartFlow
  2. Under Policies> Security > Access > Enable to view the Allow Rule configuration screen.
  3. Add an Allow rule by entering the IP address and enable the rule or Enter the value all in the allow rule. Note, that all is the default value.
_images/image2.22.png

You can add multiple allow rules using the Add Rule button.

  • Save the Rule and policy.
  • Save the SmartFlow.
  • Send request to the Lightning Application Delivery Controller (LADC) from the IP which is allowed.

Expected Results

When a request is made from the Application server specified by the IP address in the Allow rule in the Access Policy, 200 OK response code is displayed along with the content in the reply. When you specify the option all in the Access policy, the user receives an appropriate response if he sends requests from any client IP addresses.

Configuring Deny Rule

Perform the steps below to configure a deny rule in A10 Lightning ADC:

  1. Click on Configuration > Services > default-smartflow> Edit SmartFlow
  2. Under Policies> Security > Access > Deny > Enable to disbale the Allow Rule configuration.
_images/image2.23.png

Add a Deny Rule

Enter the IP address (For example, 54.186.134.82). Disable the rule, save the rule and policy; save the SmartFlow. And then send a request to the Application Delivery Controller (LADC) from the IP which is denied.

Add multiple deny rules as required, using the Add Rule button.

  • Save the rules and policy.
  • Save the Smart Flow.
  • Send request to the Application Delivery Controller (LADC) from the IP addresses specified in the Deny rules.

Expected Results

When requests are made from the IP addresses specified by Deny rules, a 403 Forbidden response is displayed.

Disable Rule Feature

Perform the step below to disable a rule in A10 Lightning ADC:

Select Configuration> Services> default-smartflow> Edit SmartFlow to edit the default Smart Flow. Choose Security > Access and then disable the Access policy using the Disable option.

Geographic Access Control

Controlling Access based on any information in HTTP request.

Protection against DDoS Attacks

A Distributed Denial of Service (DDoS) attack is an attempt to make an online service unavailable by overwhelming it with traffic from multiple sources. A DDoS attack can cripple your network and take your servers offline, by flooding the network with malicious traffic leaving no room for legitimate traffic.

A10 Lightning ADC monitors traffic patterns to identify and protect your business from application-layer Distributed Denial of Service (DDoS) attacks. Clean user traffic is allowed through while the system identifies and drops malicious traffic before it can impact app server resources and availability. A10 Lightning ADC detects and mitigates application layer threats such as SlowLoris, Slow Post, HashDoS, and GET Floods.

_images/ddos1.png

Application availability is maximized using A10 Lightning ADC DDoS protection even during attacks. The elastic infrastructure allows mitigation to keep pace with application traffic and keep latency to a minimum. The comprehensive traffic and security metrics in the A10 Lightning ADC web interface helps you to learn about specific attacks and patterns in attack detection. A10 Lightning ADC Blacklists and Whitelists and customized Web Application Firewall (WAF) rules help mitigate these attacks.

A10 Lightning ADC Mitigation Mechanisms for DDoS Attacks A10 Lightning ADC provides different mitigation mechanisms to thwart Layer 4 network level attacks.

_images/image393.png

Types of Attacks

  • Mitigation Mechanisms
  • Volumetric/Flood Attacks
  • IP protection, Rate limiting, and Throttling
  • Session attacks
  • SSL termination and SSL re-negotiation validation

Elastic SSL with Auto-Scaling

Application Attacks, Blacklist and Whitelist support, Full proxy for HTTP, Anomaly detection, Web Application Firewall (WAF) A10 Lightning ADC mitigates different types of DDoS attacks with security policies and features, as explained here:

By default, the mitigation mechanisms in A10 Lightning ADC include connection pooling, surge protection, request queueing, and auto-scaling capabilities. These can absorb any small to medium intensity attacks. If the attack is planned to exploit HTTP 1.1 protocol limits and is made in the form of SlowLoris, SlowPost or other similar “low and slow”9D attacks, the aggressively configured restrictions in the `Surge Protection policy helps to mitigate the attack. Limiting the total number of user sessions and rate limiting traffic within a session using `Session Tracking policy prevents the attacker from creating junk connections and hogging server resources. If the attack is done using a tool or IP network that is known for bad BOT traffic, the attack is prevented by the configuration setting in A10 Lightning ADC that prevents dangerous BOT attacks. Getting the IP addresses of attackers and create whitelists and blacklists (access/deny rules) or Access Policy rules prevents attacks from known IP addresses.

Connection Timeouts

Surge Protection Policy

Surge Protection policy is the security policy in A10 Lightning ADC that protects your infrastructure from external network traffic surges caused by DDoS attacks which exploit conditions/parameters such as connection time, connection requests, or provisions of the HTTP protocol such as requests and responses. This policy allows you to specify the limits and timeouts for handling traffic surges present in the network or created by attacks, by aggressively closing the connections based on the policy configuration.

You can configure these functions in the Surge Protection policy screen in A10 Lightning ADC:

  • Specify limits or timeouts for traffic surges by aggressively closing connections causing surges.
  • Prevent specific DDoS attacks such as SlowLoris and SlowPost by closing idle connections, or specifying limits for slow connections.
  • In attacks that exploit provisions of HTTP protocol, you can specify limits for the HTTP request body length or the maximum number of requests to process on a connection.

Configuring Surge Protection Policy

Perform the steps below to configure Surge Protection policy in A10 Lightning ADC:

  1. Click on Configuration> Security tab > Surge Protection menu. Enable Surge Protection policy by clicking on the Enable button.
_images/image2.24.png
  1. The Surge Protection policy screen displays with these fields:
_images/image2.25.png

** Surge Protection limits can be set on these parameters:**

  • Maximum allowed Request Body (bytes) Size: You can set a limit on the HTTP request body length that can be accepted by the HTTP Provider Service to protect your system from malicious Denial-of-Service (DoS) attacks. The system controls this limit by inspecting the Content-Length header of the request or monitoring the chunked request body (in case chunked encoding is applied to the message). If the value of the Content-Length header exceeds the maximum request body length, then the HTTP Provider Service rejects the request with a 413 “Request Entity Too Large”9D error response.
  • The maximum number of requests to process on a connection: You can limit the number of HTTP requests per source IP address, on a connection from the client to the application server. The limit can be an integer value between 0 and 65536.
  • Close idle connection after (seconds): Some attacks involve malicious clients that linger on with partial requests and responses, and indulge in minimum interaction to prevent server idle times from expiring. The attacks slow down applications by consuming system resources, leading eventually to an inability to handle server traffic. These are the “low and slow”9D attacks, as a relatively small number of clients can DoS the server stealthily and slowly, without consuming any significant bandwidth on the network.

In A10 Lightning ADC, this field allows setting the time within which the system should close idle connections so that low and slow attacks are prevented.

Protection against SlowLoris

Slow Loris is an attack tool that holds HTTP connections open by sending partial HTTP requests. The headers are sent at regular intervals to occupy the application stack and keep connections from closing. This keeps the server threads and network resources from being released, eventually leading to collapse. The web server quickly reaches its maximum application stack capacity and becomes unavailable for new connections by legitimate users. From a protocol compliance perspective, this appears to be normal traffic which the signature or blacklist-based devices do not detect.

  1. Click on Configuration > Services > default-smartflow> Edit SmartFlow
  2. Under Policies> Performance > Compressions
_images/image2.26.png

In A10 Lightning ADC, this field allows you to protect against SlowLoris attacks by closing HTTP connections when the headers are not received within the specified time interval (in seconds). The default allowed time is 60 seconds.

Close connection if all headers are not received in (seconds)- Protection Against SlowLoris: Set the time (in seconds) to close connections if HTTP headers are not received within the specified period.

Protection against SlowPost

SlowPost is an attack tool which brings down a web server by creating long form field submissions. This is done by iteratively injecting one byte into a web application post field followed by a sleep period. The result is that application threads become stuck because they are occupied with these one-byte POST fragments.

_images/image63.png

In A10 Lightning ADC, this field allows you to protect against SlowLoris attacks by closing HTTP connections if the request body is not received within the specified time interval (in seconds). The default allowed time is 60 seconds.

Close connection if it goes idle while receiving request body for seconds)- Protection against SlowPost Set the time (in seconds) to close idle connections while receiving HTTP request body.

Terminate Connection after every request When you enable this button, a new connection is opened for every new request.(That is, the session is terminated after a request.)

Volumetric Traffic Limits

Session Tracking Policy

A session is a series of related browser requests that come from the same client during a period. Session tracking is a mechanism to track a customer session and enforce traffic management policies on sessions. During a session, a series of continuous web requests and responses from the same client to the server can cause traffic congestion and inadequate network bandwidth. This is because HTTP is a stateless protocol and the server does not store the incoming client information. Session tracking enables you to track a user’s progress over multiple servlets or HTML pages during a session. Session tracking mechanisms are required so that Volume-based DDoS attacks caused by large traffic generation from a single client, or a large amount of connections created for a short duration from multiple clients can be detected and mitigated.

Session Timeout You can specify an interval of time after which HTTP sessions expire. When a session expires, all data stored in the session is discarded. The session timeout is 30 minutes as per industry standards.

Session Tracking Policy in A10 Lightning ADC

Session Tracking policy in A10 Lightning ADC allows you to track user sessions and then limit usage of resources by those sessions. The A10 Lightning ADC performs session tracking to apply rate limits on incoming web requests from clients to servers.

_images/image64.png

You can set these parameters in the session tracking policy in A10 Lightning ADC: - Number of simultaneous user sessions for an application.

Some simultaneous requests within a session. The rate of request per session. The rate of session creation per application.

Note

See Step 3 of Configuring Session Tracking Policy in A10 Lightning ADC for more information.

Configuring Session Tracking Policy

Perform the step below to configure the session tracking policy in A10 Lightning ADC:

Click on Configuration > Security tab > Session Tracking to access the Session Tracking screen.

_images/image2.27.png

Configure the Session Tracking Mechanism. A10 Lightning ADC provides these mechanisms for session tracking:

LADC cookie: This session tracking mechanism uses cookies to track sessions. A10 Lightning ADC insets its cookie to track a session. A unique cookie identifies each session. This should be utilized when the traffic is expected from web clients supporting cookie’s typical example is a web browser.

Client IP: This session tracking mechanism is based on tracking the sessions originating from a customer IP address to the application server. A session is identified by the IP address of the web client. This should be used when clients do not support cookies (For example, mobile apps) but are expected to have different public IP addresses.

Configure the following parameters for session tracking:

Maximum concurrent sessions: The maximum number of concurrent users accessing the application.You can set any integer value in this field.

Session create rate The rate at which users access the application. This parameter is measured in per second rate. Maximum concurrent requests per session’s. The highest number of concurrent requests per user session. This field is particularly useful in browser sessions (when users access the application through browsers). This parameter is measured in per second rate.

Maximum concurrent requests per session: The maximum number of concurrent requests in a user session.

Request rate per session The number of requests in a user session. This field is particularly useful in API-based sessions. This parameter is measured in per second rate.

Note

Session Tracking can also be configured at the Smart Flow level.

Session Tracking Trend Graphs

You can view trend graphs and analytics of your session tracking policy from Analytics> Dashboard > Blocked Requests menu.

_images/image2.32.png