-
Getting Started with Citrix ADC
-
Deploy a Citrix ADC VPX instance
-
Install a Citrix ADC VPX instance on Microsoft Hyper-V servers
-
Install a Citrix ADC VPX instance on Linux-KVM platform
-
Prerequisites for Installing Citrix ADC VPX Virtual Appliances on Linux-KVM Platform
-
Provisioning the Citrix ADC Virtual Appliance by using OpenStack
-
Provisioning the Citrix ADC Virtual Appliance by using the Virtual Machine Manager
-
Configuring Citrix ADC Virtual Appliances to Use SR-IOV Network Interface
-
Configuring Citrix ADC Virtual Appliances to use PCI Passthrough Network Interface
-
Provisioning the Citrix ADC Virtual Appliance by using the virsh Program
-
Provisioning the Citrix ADC Virtual Appliance with SR-IOV, on OpenStack
-
Configuring a Citrix ADC VPX Instance on KVM to Use OVS DPDK-Based Host Interfaces
-
-
Deploy a Citrix ADC VPX instance on Microsoft Azure
-
Network architecture for Citrix ADC VPX instances on Microsoft Azure
-
Configure multiple IP addresses for a Citrix ADC VPX standalone instance
-
Configure a high-availability setup with multiple IP addresses and NICs
-
Configure a high-availability setup with multiple IP addresses and NICs by using PowerShell commands
-
Configure HA-INC nodes by using the Citrix high availability template with Azure ILB
-
Configure address pools (IIP) for a Citrix Gateway appliance
-
-
Upgrade and downgrade a Citrix ADC appliance
-
Solutions for Telecom Service Providers
-
Load Balance Control-Plane Traffic that is based on Diameter, SIP, and SMPP Protocols
-
Provide Subscriber Load Distribution Using GSLB Across Core-Networks of a Telecom Service Provider
-
Authentication, authorization, and auditing application traffic
-
Configuring authentication, authorization, and auditing policies
-
Configuring Authentication, authorization, and auditing with commonly used protocols
-
Use an on-premises Citrix Gateway as the identity provider for Citrix Cloud
-
Troubleshoot authentication issues in Citrix ADC and Citrix Gateway with aaad.debug module
-
-
-
-
-
-
Persistence and persistent connections
-
Advanced load balancing settings
-
Gradually stepping up the load on a new service with virtual server–level slow start
-
Protect applications on protected servers against traffic surges
-
Retrieve location details from user IP address using geolocation database
-
Use source IP address of the client when connecting to the server
-
Use client source IP address for backend communication in a v4-v6 load balancing configuration
-
Set a limit on number of requests per connection to the server
-
Configure automatic state transition based on percentage health of bound services
-
-
Use case 2: Configure rule based persistence based on a name-value pair in a TCP byte stream
-
Use case 3: Configure load balancing in direct server return mode
-
Use case 6: Configure load balancing in DSR mode for IPv6 networks by using the TOS field
-
Use case 7: Configure load balancing in DSR mode by using IP Over IP
-
Use case 10: Load balancing of intrusion detection system servers
-
Use case 11: Isolating network traffic using listen policies
-
Use case 12: Configure Citrix Virtual Desktops for load balancing
-
Use case 13: Configure Citrix Virtual Apps for load balancing
-
Use case 14: ShareFile wizard for load balancing Citrix ShareFile
-
-
-
-
-
Authentication and authorization
-
-
Configuring a CloudBridge Connector Tunnel between two Datacenters
-
Configuring CloudBridge Connector between Datacenter and AWS Cloud
-
Configuring a CloudBridge Connector Tunnel Between a Datacenter and Azure Cloud
-
Configuring CloudBridge Connector Tunnel between Datacenter and SoftLayer Enterprise Cloud
-
Configuring a CloudBridge Connector Tunnel Between a Citrix ADC Appliance and Cisco IOS Device
-
CloudBridge Connector Tunnel Diagnostics and Troubleshooting
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
Mitigate DNS DDoS attacks
DNS servers are one of the most critical components of a network, and they must be defended against attacks. One of the most basic types of DNS attacks is the DDoS attack. Attacks of this type are on the rise and can be destructive. You can do the following to mitigate DDoS attacks:
- Flush negative records.
- Restrict the time to live (TTL) of negative records.
- Preserve Citrix ADC memory by limiting the memory consumed by the DNS cache.
- Retain DNS records in the cache.
- Enable DNS cache bypass.
You can also limit DNS queries to a single packet and thus prevent Slowloris
attacks.
Flush negative records
A DNS attack fills the cache with negative records (NXDOMAIN and NODATA). As a result, responses to legitimate requests are not cached, so new requests are sent to a back-end server for DNS resolution. Responses are therefore delayed.
You can now flush the negative DNS records from the Citrix ADC appliance’s DNS cache.
Flush negative cache records by using the CLI
At the command prompt, type:
flush dns proxyrecords -type (dnsRecordType | negRecType) NXDOMAIN | NODATA
Example:
flush dns proxyrecords –negRecType NODATA
Flush of negative cache records by using the GUI
- Navigate to Configuration > Traffic Management > DNS > Records.
- In the details pane, click Flush Proxy Records.
- In the Flush Type box, select Negative Records.
- In the Negative Records Type box, select either NXDOMAIN or NODATA.
Protection against random subdomain and NXDOMAIN attacks
To prevent random subdomain and NXDOMAIN attacks, you can restrict the DNS cache memory, and you can adjust the TTL values for negative records.
To limit the amount of memory consumed by the DNS cache, you can specify the maximum cache size and the cache size (in MB) for storing negative responses. When either limit is reached, no more entries are added to the cache. Also, syslog messages are logged and, if you have configured SNMP traps, SNMP traps are generated. If these limits are not set, caching continues until the system memory is exhausted.
A higher TTL value for negative records can result in storing records that are not valuable for a long time. A lower TTL value results in sending more requests to the back-end server.
The TTL of the negative record is set to a value that can be the lesser of the TTL value or the ”Expires” value of the SOA record.
Note:
- This limitation is added per packet engine. For example, if the maxCacheSize is set to 5 MB and the appliance has 3 packet engines, the total cache size is 15 MB.
- The cache size for the negative records must be less than or equal to the maximum cache size.
- If you reduce the DNS cache memory limit to a value lower than the amount of data already cached, the cache size remains above the limit until the data ages out. That is, exceeds its TTL0 or is flushed (
flush dns proxyrecords
command, or Flush Proxy Records in the Citrix ADC GUI). - To configure SNMP traps, see Configuring the NetScaler to Generate SNMP Traps.
Limit the memory consumed by the DNS Cache by using the CLI
At the command prompt, type:
set dns parameter -maxCacheSize <MBytes> -maxNegativeCacheSize <MBytes>
Example:
set dns parameter - maxCacheSize 100 -maxNegativeCacheSize 25
Limit the memory consumed by the DNS Cache by using the GUI
Navigate to Configuration > Traffic Management > DNS, click Change DNS Settings, and set the following parameters:
- Max Cache Size in MB
- Max Negative Cache Size in MB
Restrict the TTL of negative records by using the CLI
At the command prompt, type:
set dns parameter -maxnegcacheTTL <secs>
Example:
set dns parameter -maxnegcacheTTL 360
Restrict the TTL of negative records by using the GUI
- Navigate to Configuration > Traffic Management > DNS.
- Click Change DNS Settings and set the Max Negative Cache TTL in sec parameter.
Retain DNS records in the cache
An attack can flood the DNS cache with non-important entries but can cause flushing of the already cached legitimate records to make room for the new entries. To prevent attacks from filling the cache with invalid data, you can retain the legitimate records even after they exceed their TTL values.
If you enable the cacheNoExpire parameter, the records currently in the cache are retained until you disable the parameter.
Note:
- This option can be used only when the maximum cache size is specified (maxCacheSize parameter).
- If maxnegcacheTTL is configured and cacheNoExpire is enabled, cacheNoExpire takes priority.
Retain DNS records in the cache by using the CLI
At the command prompt, type:
set dns parameter -cacheNoExpire ( ENABLED | DISABLED)
Example:
set dns parameter -cacheNoExpire ENABLED
Retain DNS records in the cache by using the GUI
- Navigate to Configuration > Traffic Management > DNS and click Change DNS Settings.
- Select Cache No Expire.
Enable DNS cache bypass
For greater visibility and control of DNS requests, set the cacheHitBypass parameter to forward all requests to the back-end servers and allow the cache to be built but not used. After the cache is built, you can disable the parameter so that requests are served from the cache.
Enable DNS cache bypass by using the CLI
At the command prompt, type:
set dns parameter -cacheHitBypass ( ENABLED | DISABLED )
Example:
set dns parameter -cacheHitBypass ENABLED
Enable DNS cache bypass by using the GUI
- Navigate to Configuration > Traffic Management > DNS and click Change DNS Settings.
- Select Cache Hit Bypass.
Prevent the Slowloris
attack
A DNS query spanning multiple packets, presents the potential threat of a Slowloris
attack. The Citrix ADC appliance can silently drop DNS queries that are split into multiple packets.
You can set the splitPktQueryProcessing
parameter to ALLOW or DROP a DNS query if the query is split into multiple packets.
Note: This setting is applicable only for DNS TCP.
Limit the DNS queries to a single packet by using the CLI
At the command prompt, type:
set dns parameter -splitPktQueryProcessing ( ALLOW | DROP )
Example:
set dns parameter -splitPktQueryProcessing DROP
Limit DNS queries to a single packet by using the GUI
- Navigate to Configuration > Traffic Management > DNS and click Change DNS Settings.
- In the Split Packet Query Processing box, choose ALLOW or DROP.
Collect statistics of the DNS responses served from the cache
You can collect statistics of the DNS responses served from the cache. Then use these statistics to create a threshold beyond which more DNS traffic is dropped, and enforce this threshold with a bandwidth based policy. Previously, bandwidth calculation for a DNS load balancing virtual server was not accurate, because the number of requests served from the cache was not reported.
In proxy mode, the statistics for Request bytes, Response bytes, Total Packets received, and Total Packets sent statistics are continuously updated. Previously, these statistics were not always updated, particularly for a DNS load balancing virtual server.
Proxy mode also now enables you to determine the number of DNS responses served from the cache. To collect these statistics, the following options have been added to the stat lb vserver <DNSvirtualServerName>
command:
- Requests – Total number of requests received by the DNS or DNS_TCP virtual server. Includes the requests forwarded to the back end and the requests answered from the cache.
- Vserver hits –Total number of requests forwarded to the back end. The number of requests served from the cache is the difference between the total number of requests and the number of requests served from the virtual server.
-
Responses – Total number of responses sent by this virtual server. For example, if a DNS LB virtual server received 5 DNS requests, forwarded 3 of them to the back end, and served 2 of them from the cache, the corresponding value of each of these statistics would be as follows:
- Vserver hits: 3
- Requests: 5
- Responses: 5
Share
Share
This Preview product documentation is Cloud Software Group Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Cloud Software Group Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Cloud Software Group product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.