Jump to content

  • Articles

    Show all categories
    NetScaler Cyber Threat Intelligence
    NetScaler WAF Signatures Update v135
     
    NetScaler has released a new version of its integrated Web App Firewall signatures to help customers mitigate several CVEs with variable CVSS. 
    CVE-2024-36401: GeoServer is an open-source server by the GeoServer community that allows users to share and edit geospatial data, supporting industry-standard OGC protocols like WFS, WMS, and WCS. Identified as CVE-2024-36401 with a CVSS of 9.8, this vulnerability allows remote code execution (RCE) by unauthenticated users through specially crafted input in GeoServer versions prior to 2.23.6, 2.24.4, and 2.25.212. Exploiting this vulnerability enables attackers to execute arbitrary code on the server, significantly compromising the confidentiality, integrity, and availability of the system.
     Signatures included in v135:
    Signature rule
    CVE ID
    Description
    998455
    CVE-2024-38094, CVE-2024-38024,
    CVE-2024-38023
    WEB-MISC Microsoft SharePoint Server 2016 and 2019 - Remote Code Execution Vulnerability (CVE-2024-38094, 38024 and 38023)
    998456
    CVE-2024-36401 
    WEB-MISC GeoServer Multiple Versions - Unauthenticated Remote Code Execution Vulnerability Via TestWfsPost (CVE-2024-36401)
    998457
    CVE-2024-36401 
    WEB-MISC GeoServer Multiple Versions - Unauthenticated Remote Code Execution Vulnerability Via HTTP Params (CVE-2024-36401)
    998458
    CVE-2024-36401 
    WEB-MISC GeoServer Multiple Versions - Unauthenticated Remote Code Execution Vulnerability (CVE-2024-36401)
    998459
    CVE-2024-3246 
    WEB-MISC WordPress Plugin LiteSpeed Cache Prior To 6.3.0 - Cross-Site Request Forgery Vulnerability (CVE-2024-3246)
    998460
    CVE-2024-30043 
    WEB-MISC Microsoft SharePoint Server 2016 and 2019 - XXE Injection Vulnerability Via upload.aspx (CVE-2024-30043)
    998461
    CVE-2024-30043 
    WEB-MISC Microsoft SharePoint Server 2016 and 2019 - XXE Injection Vulnerability (CVE-2024-30043)
    998462
    CVE-2023-46816 
    WEB-MISC SugarCRM Prior to 12.0.4 and 13.0.2 - Server Side Template Injection Vulnerability (CVE-2023-46816)
    998463
    CVE-2023-3162 
    WEB-WORDPRESS Stripe Payment Plugin for WooCommerce Prior to 3.7.8 - Authentication Bypass Vulnerability (CVE-2023-3162)
     
    NetScaler customers can quickly import the above signatures to help reduce risk and lower exposure associated with these vulnerabilities. Signatures are compatible with NetScaler (formerly Citrix ADC) software version 11.1, 12.0, 12.1, 13.0 and 13.1. NOTE: Software versions 11.1 and 12.0 are end of life, and you should consider upgrading for continued support. Learn more about the NetScaler software release lifecycle.
     
    If you are already using NetScaler Web App Firewall with the signature auto-update feature enabled, verify that your signature file version is 135 or later and then follow these steps.
    Search your signatures for <number> Select the results with ID  Choose “Enable Rules” and click OK  
    NetScaler WAF Best Practices
    NetScaler recommends that WAF users always download the latest signature version, enable signature auto-update, and subscribe to receive signature alert notifications. NetScaler will continue to monitor this dynamic situation and provide updates as new mitigations become available.
     
    Handling false positives
    If app availability is affected by false positives that result from the above mitigation policies, relaxations can be applied. NetScaler recommends the following modifications to the policy.
     
    Modifications to NetScaler Web App Firewall Policy:
    add policy patset exception_list
    # (Example: bind policy patset exception_list “/exception_url”) 
    Prepend the existing WAF policy with:
    HTTP.REQ.URL.CONTAINS_ANY(“exception_list”).NOT
    # (Example :  set appfw policy my_WAF_policy q^HTTP.REQ.URL.CONTAINS_ANY(“exception_list”).NOT && <existing rule>^
    NOTE: Any endpoint covered by the exception_list may expose those assets to risks 
    Additional Information
    NetScaler Web App Firewall benefits from a single code base across all its form-factors (physical, virtual, bare-metal, and containers). This signature update applies to all form factors and deployment models of NetScaler Web App Firewall.
    Learn more about NetScaler Web app Firewall, read our alert articles and bot signature articles to learn more about NetScaler WAF signatures, and find out how you can receive signature alert notifications.
    Please join the NetScaler Community today and engage with your peers to learn more about how they are protecting their businesses with NetScaler WAF. 




     
    NetScaler Cyber Threat Intelligence
    NetScaler WAF Signatures Update v134
     
    NetScaler has released a new version of its integrated Web App Firewall signatures to help customers mitigate several CVEs with variable CVSS. 
    CCVE-2024-34102: Adobe Commerce, a popular e-commerce platform, and Magento Open Source, an open-source e-commerce solution, are both impacted by a critical vulnerability, categorized as Improper Restriction of XML External Entity Reference (XXE) with a CVSS of 9.8. It affects Adobe Commerce versions 2.4.7, 2.4.6-p5, 2.4.5-p7, 2.4.4-p8, and earlier and Magento Open Source versions 2.4.7, 2.4.6-p5, 2.4.5-p7, 2.4.4-p8, and earlier. Attackers can exploit this vulnerability by sending a manipulated XML document that refers to external entities. Successful exploitation does not require user interaction and could lead to arbitrary code execution, potentially granting full control over the affected e-commerce platform.
    CVE-2024-20179: Adobe Commerce and Magento Open Source, widely used e-commerce platforms, are impacted by a critical vulnerability known as CVE-2024-20179. This critical vulnerability falls under the category of Stored Cross-Site Scripting (XSS) and was assigned a CVSS of 9.1. It affects Adobe Commerce versions 2.4.4-p1 and earlier, and Magento Open Source versions 2.4.4-p1 and earlier. High-privileged attackers can inject malicious scripts into vulnerable form fields. When a victim visits a page containing the vulnerable field, the injected JavaScript executes in their browser, which could be leveraged to gain admin access.
     Signatures included in v134:
    Signature rule
    CVE ID
    Description
    998464
    CVE-2024-34102
    WEB-MISC Adobe Magento - XML External Entity Vulnerability (CVE-2024-34102)
    998465
    CVE-2024-2782
    WEB-WORDPRESS Contact Form by Fluent Forms before 5.1.17 - Missing Authentication Vulnerability Via POST (CVE-2024-2782)
    998466
    CVE-2024-2782
    WEB-WORDPRESS Contact Form by Fluent Forms before 5.1.17 - Missing Authentication Vulnerability global-settings (CVE-2024-2782)
    998467
    CVE-2024-2771
    WEB-WORDPRESS Contact Form by Fluent Forms before 5.1.17 - Missing Authentication Vulnerability Via DELETE (CVE-2024-2771)
    998468
    CVE-2024-2771
    WEB-WORDPRESS Contact Form by Fluent Forms before 5.1.17 - Missing Authentication Vulnerability Via POST (CVE-2024-2771)
    998469
    CVE-2024-2771
    WEB-WORDPRESS Contact Form by Fluent Forms before 5.1.17 - Missing Authentication Vulnerability Via managers (CVE-2024-2771)
    998470
    CVE-2024-20759
    WEB-MISC Adobe Magento - Stored XSS Vulnerability (CVE-2024-20759)
    998471
    CVE-2024-20179
    WEB-MISC Adobe Magento - Stored XSS Vulnerability (CVE-2024-20179)
     
    NetScaler customers can quickly import the above signatures to help reduce risk and lower exposure associated with these vulnerabilities. Signatures are compatible with NetScaler (formerly Citrix ADC) software version 11.1, 12.0, 12.1, 13.0 and 13.1. NOTE: Software versions 11.1 and 12.0 are end of life, and you should consider upgrading for continued support. Learn more about the NetScaler software release lifecycle.
     
    If you are already using NetScaler Web App Firewall with the signature auto-update feature enabled, verify that your signature file version is 134 or later and then follow these steps.
    Search your signatures for <number> Select the results with ID  Choose “Enable Rules” and click OK  
    NetScaler WAF Best Practices
    NetScaler recommends that WAF users always download the latest signature version, enable signature auto-update, and subscribe to receive signature alert notifications. NetScaler will continue to monitor this dynamic situation and provide updates as new mitigations become available.
     
    Handling false positives
    If app availability is affected by false positives that result from the above mitigation policies, relaxations can be applied. NetScaler recommends the following modifications to the policy.
     
    Modifications to NetScaler Web App Firewall Policy:
    add policy patset exception_list
    # (Example: bind policy patset exception_list “/exception_url”) 
    Prepend the existing WAF policy with:
    HTTP.REQ.URL.CONTAINS_ANY(“exception_list”).NOT
    # (Example :  set appfw policy my_WAF_policy q^HTTP.REQ.URL.CONTAINS_ANY(“exception_list”).NOT && <existing rule>^
    NOTE: Any endpoint covered by the exception_list may expose those assets to risks 
    Additional Information
    NetScaler Web App Firewall benefits from a single code base across all its form-factors (physical, virtual, bare-metal, and containers). This signature update applies to all form factors and deployment models of NetScaler Web App Firewall.
    Learn more about NetScaler Web app Firewall, read our alert articles and bot signature articles to learn more about NetScaler WAF signatures, and find out how you can receive signature alert notifications.
    Please join the NetScaler Community today and engage with your peers to learn more about how they are protecting their businesses with NetScaler WAF. 




     
    NetScaler Cyber Threat Intelligence
    NetScaler WAF Signatures Update v133
     
    NetScaler has released a new version of its integrated Web App Firewall signatures to help customers mitigate several CVEs with variable CVSS. 
    CVE-2024-5806: Last year’s critical zero-day vulnerability, CVE-2023-34362, in Progress MOVEit Transfer, a widely adopted managed file transfer (MFT) solution, attracted significant attention in the cybersecurity community, affecting high-profile organizations. Progress MOVEit Transfer has been found to contain a critical authentication bypass vulnerability (CVE-2024-5806), which has already been under active exploitation in the wild.  This vulnerability, with a CVSS score of 9.1, resides in the product’s SFTP module and affects versions ranging from 2023.0.0 to 2023.0.11, from 2023.1.0 to 2023.1.6, and from 2024.0.0 to 2024.0.2. Unauthenticated attackers can exploit this vulnerability by injecting their own SSH key into the log files of the service and designating it as the resource containing the authentication keys during SFTP authentication. As a result, malicious actors can bypass authentication mechanisms and gain unauthorized access to sensitive data.
    CVE-2024-5276:  Fortra FileCatalyst Workflow, an accelerated file transfer software solution, facilitates secure transfers of large files across remote networks. However, it is currently impacted by a critical SQL Injection vulnerability, rated with a CVSS score of 9.8. This vulnerability affects all versions up to and including 5.1.6 Build 139. The specific vulnerability resides in the component used for HTTP-based transfers. Unauthenticated attackers can exploit this weakness to manipulate or delete data within the application database and potentially create administrative user accounts.
     Signatures included in v133:
    Signature rule
    CVE ID
    Description
    998472
    CVE-2024-5806
    WEB-MISC Progress MOVEit Transfer - Authentication Bypass Vulnerability Via Log Poisoning (CVE-2024-5806)
    998473
    CVE-2024-5276
    WEB-MISC Fortra FileCatalyst Workflow Prior to 5.1.6.139 - SQL Injection Vulnerability (CVE-2024-5276)
    998474
    CVE-2024-31982
    WEB-MISC XWiki Multiple Versions - Unauthenticated Remote Code Execution Vulnerability (CVE-2024-31982)
     
    NetScaler customers can quickly import the above signatures to help reduce risk and lower exposure associated with these vulnerabilities. Signatures are compatible with NetScaler (formerly Citrix ADC) software version 11.1, 12.0, 12.1, 13.0 and 13.1. NOTE: Software versions 11.1 and 12.0 are end of life, and you should consider upgrading for continued support. Learn more about the NetScaler software release lifecycle.
     
    If you are already using NetScaler Web App Firewall with the signature auto-update feature enabled, verify that your signature file version is 133 or later and then follow these steps.
    Search your signatures for <number> Select the results with ID  Choose “Enable Rules” and click OK  
    NetScaler WAF Best Practices
    NetScaler recommends that WAF users always download the latest signature version, enable signature auto-update, and subscribe to receive signature alert notifications. NetScaler will continue to monitor this dynamic situation and provide updates as new mitigations become available.
     
    Handling false positives
    If app availability is affected by false positives that result from the above mitigation policies, relaxations can be applied. NetScaler recommends the following modifications to the policy.
     
    Modifications to NetScaler Web App Firewall Policy:
    add policy patset exception_list
    # (Example: bind policy patset exception_list “/exception_url”) 
    Prepend the existing WAF policy with:
    HTTP.REQ.URL.CONTAINS_ANY(“exception_list”).NOT
    # (Example :  set appfw policy my_WAF_policy q^HTTP.REQ.URL.CONTAINS_ANY(“exception_list”).NOT && <existing rule>^
    NOTE: Any endpoint covered by the exception_list may expose those assets to risks 
    Additional Information
    NetScaler Web App Firewall benefits from a single code base across all its form-factors (physical, virtual, bare-metal, and containers). This signature update applies to all form factors and deployment models of NetScaler Web App Firewall.
    Learn more about NetScaler Web app Firewall, read our alert articles and bot signature articles to learn more about NetScaler WAF signatures, and find out how you can receive signature alert notifications.
    Please join the NetScaler Community today and engage with your peers to learn more about how they are protecting their businesses with NetScaler WAF. 




     
    NetScaler Cyber Threat Intelligence
    NetScaler WAF Signatures Update v132
     
    NetScaler has released a new version of its integrated Web App Firewall signatures to help customers mitigate several CVEs with variable CVSS. 
    CVE-2024-4295: “Email Subscribers” by Icegram Express is a WordPress plugin widely used for email marketing, subscriber list management, and newsletter distribution. With over 90,000 active installations, the plugin is susceptible to SQL Injection via the “hash” parameter in all versions up to, and including, 5.7.20. This vulnerability arises from insufficient escaping of user-supplied parameters and a lack of proper preparation in the existing SQL query. Unauthenticated attackers can exploit this weakness by injecting additional SQL queries, potentially granting access to sensitive information stored in the database.
    CVE-2024-28995: “Serv-U” is SolarWinds’ FTP server for Windows and Linux operating systems. It is susceptible to a directory traversal vulnerability in all versions up to, but excluding, 15.4.2. This vulnerability allows unauthorized access to read sensitive files on the host machine.
     Signatures included in v132:
    Signature rule
    CVE ID
    Description
    998475
    CVE-2024-4295
    WEB-WORDPRESS Icegram Express Email Subscribers Prior to 5.7.21 - SQL Injection Vulnerability (CVE-2024-4295)
    998476
    CVE-2024-37393
    WEB-MISC SecurEnvoy MFA Prior to 9.4.514 - Unauthenticated LDAP Injection Vulnerability Via USERID or MEMBEROF (CVE-2024-37393)
    998477
    CVE-2024-36680
    WEB-MISC Prestashop Promokit Facebook Module Up to 1.0.1 - SQL Injection Vulnerability (CVE-2024-36680)
    998478
    CVE-2024-28995
    WEB-MISC SolarWinds Serv-U Prior to 15.4.2 HF 2 - Directory Traversal Vulnerability (CVE-2024-28995)
    998479
    CVE-2024-27349
    WEB-MISC Apache HugeGraph-Server Prior to 1.3.0 - Authentication Bypass Vulnerability (CVE-2024-27349)
    998480
    CVE-2024-27348
    WEB-MISC Apache HugeGraph-Server Prior to 1.3.0 - Remote code Execution Vulnerability (CVE-2024-27348)
     
    NetScaler customers can quickly import the above signatures to help reduce risk and lower exposure associated with these vulnerabilities. Signatures are compatible with NetScaler (formerly Citrix ADC) software version 11.1, 12.0, 12.1, 13.0 and 13.1. NOTE: Software versions 11.1 and 12.0 are end of life, and you should consider upgrading for continued support. Learn more about the NetScaler software release lifecycle.
     
    If you are already using NetScaler Web App Firewall with the signature auto-update feature enabled, verify that your signature file version is 132 or later and then follow these steps.
    Search your signatures for <number> Select the results with ID  Choose “Enable Rules” and click OK  
    NetScaler WAF Best Practices
    NetScaler recommends that WAF users always download the latest signature version, enable signature auto-update, and subscribe to receive signature alert notifications. NetScaler will continue to monitor this dynamic situation and provide updates as new mitigations become available.
     
    Handling false positives
    If app availability is affected by false positives that result from the above mitigation policies, relaxations can be applied. NetScaler recommends the following modifications to the policy.
     
    Modifications to NetScaler Web App Firewall Policy:
    add policy patset exception_list
    # (Example: bind policy patset exception_list “/exception_url”) 
    Prepend the existing WAF policy with:
    HTTP.REQ.URL.CONTAINS_ANY(“exception_list”).NOT
    # (Example :  set appfw policy my_WAF_policy q^HTTP.REQ.URL.CONTAINS_ANY(“exception_list”).NOT && <existing rule>^
    NOTE: Any endpoint covered by the exception_list may expose those assets to risks 
    Additional Information
    NetScaler Web App Firewall benefits from a single code base across all its form-factors (physical, virtual, bare-metal, and containers). This signature update applies to all form factors and deployment models of NetScaler Web App Firewall.
    Learn more about NetScaler Web app Firewall, read our alert articles and bot signature articles to learn more about NetScaler WAF signatures, and find out how you can receive signature alert notifications.
    Please join the NetScaler Community today and engage with your peers to learn more about how they are protecting their businesses with NetScaler WAF. 




     
    Aman Sood
    TCP
    TCP is one of the major protocols of an IP(Internet Protocol) based network. While IP provides a mechanism by which two hosts on a network can send data to each other; TCP provides a reliable and ordered delivery of the data on top of an IP network. A number of applications such as HTTP, FTP, SSH, etc., use TCP for reliable delivery.
    Latency
    Latency refers to the time taken when a user takes any action on an application and receives a response. Latency impacts the performance of applications particularly time sensitive applications such as online gaming, video conference, financial transactions etc. High latency can lead to delay and poor user experience. 
    In an enterprise environment multiple teams such as network, compute and application teams work together to ensure seamless delivery of applications. Ensuring low and consistent latency is crucial for maintaining quality of service. Being able to measure latency can also help in identifying network issues; pinpoint source of the delay and mitigate the problem.
    Latency is not a single measurement and it consists of a sum of a number of different latencies.

     
    Network Latency: Latency: Time taken by the packet to traverse the network (Indicated by 1,3,5,7) 
    Netscaler Processing time: Time taken by Netscaler to process the incoming packet and decide where it needs to be sent out (Indicated by: 2, 6)
    Server Processing time: Time taken by server to process the request and generate a response (Indicated by: 4)
     
    In this article we will introduce two parameters transClntRTT and transSrvrRTT that NetScaler measures for a transaction. transClntRTT measures the network latency between client and NetScaler and the processing time taken by NetScaler. Similarly transSrvrRTT measures the network latency between NetScaler and Sever and processing time taken by the server
     
    Latency Classification
    There are multiple ways to classify latency such as P99, P95, average, median etc. 
    Average and Median don’t always provide enough information to distinguish between real effects and outliers. They can mask the outliers and hence don’t provide an accurate picture of the latency. If you’re looking at API response time for a real world application, you’ll likely see a frequency distribution curve that looks something like this, instead of a normal bell curve:

     
    As seen in the image above, Median or Average will not provide an accurate information of the response time and will mask the cases where the response time was high. However using percentiles one can move the window and focus on scenarios where x% of users had response time higher than baseline.   
    Thus percentile based measurement such as P99 and P95 are the preferred choice to measure latency. P99 latency denotes the time below which 99% of the requests are served. It's a good way to understand the tail-end behavior of your system, as it provides insights beyond just average or median latencies. Similarly P95 latency denotes the time below which 95% of the requests are served.
    Latency is the time delay between user action and the response. Let's assume that there is an API that is consumed by multiple users. As part of the monitoring setup the response time of the API will be monitored to ensure a good user experience. Now as we have seen above, using median and average is not an ideal way to monitor latency as it can mask outliers and extreme values. Monitoring P99 latency will help you in identifying these outlier conditions and enable you to plan the capacity.
    Let's say there is a data set of n latency records. First those records are arranged in ascending order. The rank R of the data corresponding to the pth percentile is calculated as: 
     
    R = ceil((p*n)/100)
    For example, Let's say there are 20 observations of latency
    Observations = 1,2,4,6,2,4,8,3,8,9,2,4,6,7,4,6,8,9,1,5
    Observations in ascending order = 1,1,2,2,2,3,4,4,4,4,5,6,6,6,7,8,8,8,9,9
    The rank of the 90th percentile = Ceil(90*20/100) = 18, which is 8
     
    Note: NetScaler splunk dashboard provides a view of the P95 and P99 latency using the latency data.
     
    NetScaler Measurement of TCP Latency
    NetScaler is configured in endpoint mode. In the endpoint mode TCP flow and error control between Client and NetScaler, and NetScaler and Backend Server is handled independently.
    NetScaler uses data packets instead of TCP 3 way handshake to calculate the latency. TCP 3 way handshake is not an ideal way to measure the latency since it does not take into account the time taken to process the application data.
     
    Let's consider an HTTP application which is being proxied by NetScaler. Since HTTP runs on top of TCP, when a user sends an HTTP request a TCP session is created. Once the request(s) is served the TCP session is closed. The same mechanism can be used to arrive at latency for any other application that uses TCP as underlying transport protocol.
    For measuring the latency between Client and NetScaler, NetScaler relies on the TCP Acknowledgement generated by the client for the responses sent by the Server. For measuring the latency between NetScaler and the Server, NetScaler relies on the TCP Acknowledgement generated by the Server for requests coming from the Client.  
    TCP presents a simple socket to the upper layer protocols to read and write data. For an application to read from and write to this socket, buffers are implemented on both sides of a TCP connection. Buffers allow for more efficient data transfer as more data can be buffered and then sent out thus improving link utilization. However applications requiring real time data cannot wait for the buffer to fill. Thus TCP has implemented a PSH flag to push the data out immediately. Similarly, different optimizations in the TCP stack such as Nagle Algorithm, Delayed ACK, Fast Open can have an impact on the latency of the application as well as on NetScaler’s calculation of latency.
    In this blog, we are not considering the impact of optimizations such as PSH, Delayed ACK etc for latency calculation.
    Latency measurement between Client and Netscaler

    TCP handshake is completed between Client and NetScaler and between NetScaler and Backend Server. Client issues a GET request. The HTTP request is encapsulated in a TCP segment. Since NetScaler is running in Endpoint mode, it will acknowledge this TCP segment and then proxy the GET request to the Server. Let's say the HTTP response for this GET request from the Server takes 2 TCP segments. Netscaler transmits the first segment and then the second segment. The latency between Client and NetScaler will be calculated as the time duration between NetScaler sending the 1st response and receiving the ACK of this first response and also between sending the 2nd response and receiving the ACK for this second response. SInce there are multiple observations in this case moving averages are used to smoothen the measurement.  
    Latency measurement between NetScaler and Server

    TCP handshake is completed between Client and NetScaler and between NetScaler and Backend Server. Client issues a POST request. The HTTP request is encapsulated in a TCP segment Since NetScaler is running in Endpoint mode, it will acknowledge this TCP segment and then proxy the POST request to the Server. When the server sends a TCP ACK, those ACK are used to measure Server side latency.  
    Configuring NetScaler to report TCP latency
    Configuration on NetScaler
    Perform the below configuration to measure client and server network latency and send the insight data to splunk
     
    Configure NetScaler to run in endpoint mode. set tcpprofile nstcp_default_profile -tcpmode ENDPOINT 
    Create a service on Netscaler with the IP Address of Splunk and port number where splunk server is listening to HEC events. add service my_splunk 10.102.154.64 HTTP 30002 
    Create 2 analytics profile one of type Web Insight and other of type TCP Insigt add analytics profile http-transaction-log-profile -collectors my_splunk -type webinsight -analyticsAuthToken “ Splunk {Token}” -analyticsEndpointUrl "/services/collector/event" -analyticsEndpointContentType "application/json" -httpURL ENABLED
    add analytics profile tcp-insight-profile -collectors my_splunk -type tcpinsight -analyticsAuthToken “ Splunk {Token}” -analyticsEndpointUrl "/services/collector/event" -analyticsEndpointContentType "application/json"
    Bind both the analytics profile to the LB Vserver bind lb vserver WebApp-1 -analyticsProfile http-transaction-log-profile
    bind lb vserver WebApp-1 -analyticsProfile tcp-insight-profile
    Viewing Client and Server RTT for a transaction on Splunk
    For this we have created a basic HTTP application which is being served through NetScaler. We will send a GET and POST request to this application to measure Client side network latency (transClntRTT) and Server side network latency (transSrvrRTT). Below are the transaction logs that NetScaler has sent to Splunk. The Client side network RTT and Server side Network RTT have been highlighted in Red Color 
    Client Latency
    {
      "httpReqUrl": "/",
      "httpReqHost": "10.146.77.110",
      "httpReqMethod": "GET",
      "httpReqUserAgent": "curl/7.81.0",
      "httpRspStatus": 200,
      "httpContentType": "text/html; charset=utf-8",
      "svrIpv4Address": 3232261122,
      "svrDstIpv4Address": 177360230,
      "srvSrcPort": 59281,
      "srvDstPort": 34835,
      "httpRspLen": 1049,
      "transSvrFlowStartUsecRx": 7378739477927409000,
      "transSvrFlowStartUsecTx": 7378739477927388000,
      "transSvrFlowEndUsecRx": 7378739477927418000,
      "transSvrFlowEndUsecTx": 7378739477927417000,
      "transSvrTotRxOctCnt": 2241,
      "transSvrTotTxOctCnt": 245,
      "transSrvrRTT": 5,
      "tcpSrvrConnRstCode": 0,
      "srvrTcpPacketsRetransmited": 0,
      "srvrTcpZeroWindowCount": 0,
      "serverConnStartTimestamp": 7378739477927388000,
      "serverConnEndTimestamp": 0,
      "observationPointId": 177360229,
      "nsPartitionId": 0,
      "exportingProcessId": 0,
      "transactionId": 483884,
      "cltIpv4Address": 177360231,
      "cltDstIpv4Address": 177360238,
      "cltSrcPort": 47329,
      "cltDstPort": 20480,
      "originRspLen": 0,
      "transCltFlowStartUsecRx": 7378739477927388000,
      "transCltFlowStartUsecTx": 7378739477927418000,
      "transCltFlowEndUsecRx": 7378739477927425000,
      "transCltFlowEndUsecTx": 7378739477927418000,
      "transCltTotRxOctCnt": 197,
      "transCltTotTxOctCnt": 1129,
      "transClntRTT": 7,
      "clientMss": 1460,
      "connectionChainHopCount": 0,
      "vlanNumber": 1,
      "appName": "WebApp1-http",
      "tcpClntConnRstCode": 0,
      "clntFastRetxCount": 0,
      "clntTcpRtoCount": 0,
      "clntTcpPacketsRetransmited": 0,
      "clntTcpZeroWindowCount": 0,
      "clntTcpJitter": 0,
      "clientConnStartTimestamp": 7378739477927388000,
      "clientConnEndTimestamp": 0
    }
    Server Latency
    {
      "httpReqUrl": "/",
      "httpReqHost": "10.146.77.110",
      "httpReqMethod": "GET",
      "httpReqUserAgent": "curl/7.81.0",
      "httpRspStatus": 200,
      "httpContentType": "text/html; charset=utf-8",
      "svrIpv4Address": 3232261122,
      "svrDstIpv4Address": 177360230,
      "srvSrcPort": 59281,
      "srvDstPort": 34835,
      "httpRspLen": 1049,
      "transSvrFlowStartUsecRx": 7378739477927409000,
      "transSvrFlowStartUsecTx": 7378739477927388000,
      "transSvrFlowEndUsecRx": 7378739477927418000,
      "transSvrFlowEndUsecTx": 7378739477927417000,
      "transSvrTotRxOctCnt": 2241,
      "transSvrTotTxOctCnt": 245,
      "transSrvrRTT": 5,
      "tcpSrvrConnRstCode": 0,
      "srvrTcpPacketsRetransmited": 0,
      "srvrTcpZeroWindowCount": 0,
      "serverConnStartTimestamp": 7378739477927388000,
      "serverConnEndTimestamp": 0,
      "observationPointId": 177360229,
      "nsPartitionId": 0,
      "exportingProcessId": 0,
      "transactionId": 483884,
      "cltIpv4Address": 177360231,
      "cltDstIpv4Address": 177360238,
      "cltSrcPort": 47329,
      "cltDstPort": 20480,
      "originRspLen": 0,
      "transCltFlowStartUsecRx": 7378739477927388000,
      "transCltFlowStartUsecTx": 7378739477927418000,
      "transCltFlowEndUsecRx": 7378739477927425000,
      "transCltFlowEndUsecTx": 7378739477927418000,
      "transCltTotRxOctCnt": 197,
      "transCltTotTxOctCnt": 1129,
      "transClntRTT": 7,
      "clientMss": 1460,
      "connectionChainHopCount": 0,
      "vlanNumber": 1,
      "appName": "WebApp1-http",
      "tcpClntConnRstCode": 0,
      "clntFastRetxCount": 0,
      "clntTcpRtoCount": 0,
      "clntTcpPacketsRetransmited": 0,
      "clntTcpZeroWindowCount": 0,
      "clntTcpJitter": 0,
      "clientConnStartTimestamp": 7378739477927388000,
      "clientConnEndTimestamp": 0
    }
     
    This article is the first of a multipart series of articles on different latencies that traffic encounters between a client and a server. In the later articles we will cover scenarios of HTTP applications where multiple HTTP packets are sent over a single transaction. We will also take a look at how NetScaler calculates the processing time taken by the Server and NetScaler.
    References
    You can refer below links to know more about NetScaler integration with Splunk and NetScaler support for other observability tools.

    1. https://docs.netscaler.com/en-us/citrix-adc/current-release/observability/integration-with-splunk
    2. https://docs.netscaler.com/en-us/citrix-adc/current-release/observability
    NetScaler Cyber Threat Intelligence
    NetScaler WAF Signatures Update v131
     
    NetScaler has released a new version of its integrated Web App Firewall signatures to help customers mitigate several CVEs with variable CVSS. 
    CVE-2024-4358: Progress Telerik Report Server, a robust reporting solution for businesses, offers a centralized platform for creating, managing, and sharing various report types. In versions 2024 Q1 (10.0.24.305) or earlier, an unauthenticated attacker can exploit an authentication bypass vulnerability, gaining access to restricted functionalities. When combined with CVE-2024-1800, this vulnerability allows for arbitrary remote code execution with elevated user privileges.
    CVE-2024-23917: TeamCity, a build management and continuous integration server from JetBrains, utilizes SpringBoot and internal interceptors for authentication. In versions prior to 2023.11.3, a bypass in an interceptor could disable the entire authentication process, leading to a significant security issue that could potentially result in remote code execution.
     Signatures included in v131:
    Signature rule
    CVE ID
    Description
    998481
    CVE-2024-4956
    WEB-MISC Sonatype Nexus Repository Prior to 3.68.1 - Unauthenticated Path Traversal Vulnerability (CVE-2024-4956)
    998482
    CVE-2024-4577
    WEB-MISC PHP Prior to 8.1.29, 8.2.20 and 8.3.8 - Command Injection Vulnerability (CVE-2024-4577)
    998483
    CVE-2024-4358
    WEB-MISC Progress Telerik Report Server - Authentication Bypass Vulnerability (CVE-2024-4358)
    998484
    CVE-2024-2879
    WEB-WORDPRESS Wordpress plugin LayerSlider Versions 7.9.11 and 7.10.0 - SQL Injection Vulnerability (CVE-2024-2879)
    998485
    CVE-2024-23917
    WEB-MISC JetBrains TeamCity Prior to 2023.11.3 - Authentication Bypass Vulnerability (CVE-2024-23917)
    998486
    CVE-2024-21683
    WEB-MISC Atlassian Confluence Prior to 8.9.1 - Remote Code Execution Vulnerability (CVE-2024-21683)
    998487
    CVE-2024-0507
    WEB-MISC GitHub Enterprise Server - Command Injection Vulnerability (CVE-2024-0507)
    998488
    CVE-2023-46729
    WEB-MISC Sentry Next.JS Prior to 7.77.0 - SSRF Via SDK Tunnel Vulnerability (CVE-2023-46729)
     
    NetScaler customers can quickly import the above signatures to help reduce risk and lower exposure associated with these vulnerabilities. Signatures are compatible with NetScaler (formerly Citrix ADC) software version 11.1, 12.0, 12.1, 13.0 and 13.1. NOTE: Software versions 11.1 and 12.0 are end of life, and you should consider upgrading for continued support. Learn more about the NetScaler software release lifecycle.
     
    If you are already using NetScaler Web App Firewall with the signature auto-update feature enabled, verify that your signature file version is 131 or later and then follow these steps.
    Search your signatures for <number> Select the results with ID  Choose “Enable Rules” and click OK  
    NetScaler WAF Best Practices
    NetScaler recommends that WAF users always download the latest signature version, enable signature auto-update, and subscribe to receive signature alert notifications. NetScaler will continue to monitor this dynamic situation and provide updates as new mitigations become available.
     
    Handling false positives
    If app availability is affected by false positives that result from the above mitigation policies, relaxations can be applied. NetScaler recommends the following modifications to the policy.
     
    Modifications to NetScaler Web App Firewall Policy:
    add policy patset exception_list
    # (Example: bind policy patset exception_list “/exception_url”) 
    Prepend the existing WAF policy with:
    HTTP.REQ.URL.CONTAINS_ANY(“exception_list”).NOT
    # (Example :  set appfw policy my_WAF_policy q^HTTP.REQ.URL.CONTAINS_ANY(“exception_list”).NOT && <existing rule>^
    NOTE: Any endpoint covered by the exception_list may expose those assets to risks 
    Additional Information
    NetScaler Web App Firewall benefits from a single code base across all its form-factors (physical, virtual, bare-metal, and containers). This signature update applies to all form factors and deployment models of NetScaler Web App Firewall.
    Learn more about NetScaler Web app Firewall, read our alert articles and bot signature articles to learn more about NetScaler WAF signatures, and find out how you can receive signature alert notifications.
    Please join the NetScaler Community today and engage with your peers to learn more about how they are protecting their businesses with NetScaler WAF. 





     
    Andrew Scott
    One of the features of running an Internet facing service, is the chance that your service will get noticed by someone looking to access your system who is not authorised. There some common tools freely available to scan vasts ranges of Internet facing addresses for services to attack. This typically will be carried out by a robot or hacker of some sort. The question is:
    How do I stop this kind of attack? What steps are needed to keep the administration overhead low?
    This piece will detail some of the steps that you should take to minimise your exposure to these kinds of attack with a combination settings and processes.
    Who is this for?
    Any NetScaler administrator with a internet facing service, in fact, any service that has an authorisation option enabled. As attacks can come from 'internal’ sources too. The role of an administrator is to ensure that a service is secure and that attacks do not lead to data loss, exfiltration or general compromise.
    Who provided help to create this?
    Many thanks to: Steven Wright, Simha Kaipa, Hemang Raval, Karsten Feldhusen, Martin Nygaard Jensen and Rick Davis for all the suggestions.
    Background
    When you have a NetScaler providing an internet service, you want to only allow authorised users access. The challenge, is how to ensure that person accesses is who they say they are? Typically, users have a password, in combination with a username this gives the administrator some level of security. The problem is that, this ‘single factor authentication’ is a poor starting point. Almost no internet facing system can just use this option, hence the prevalence of One Time Password(OTP) options. OTP gives a better level of security, but it is good practise to combine it with other measures to have good levels of security.
    Other reading?
    An internet search of this topic, yielded a few hits.
    From 2013! A former colleague created this. It is very old now, and things have moved on (classic polices).
    Released 2017 and updated in 2021. There is this support doc here, which just talks about some password options. These are covered in the text below, but need to be combined with other techniques.
    What is the configuration baseline?
    A good starting point for a NetScaler configuration, and something that could make a big difference to the fundamental security that is in place is to follow one of these reference designs. It can be common for NetScaler to be deployed in different ways by different engineers, these designs have been created to create a level of consistency.
    Gateway deployment using SAML: https://bit.ly/3lmAf0x
    Gateway Deployment using LDAP + RADIUS: https://bit.ly/3YX9MVc
    OAuth Idp for Citrix Cloud: https://bit.ly/3HvxTEo Who created these? Steven Wright works in the NetScaler business unit, these designs are based on extensive real world experience and feedback from other product managers and engineers that he works with.
    Simple steps to prevent brute force attacks
    The first item in the following section, is a preferred way to handle brute force attacks, there are other configuration options discussed, some quite new. However, if you are under attack today, this one step will halt the attack in its tracks.
    1. Authentication flow to apply and test the OTP factor first.
    When the user is presented with the login boxes for username, password and OTP factor, it can be common to setup the appliance to have a user password to be tested first, before the OTP factor. One of the elements of the reference design above is that they always apply the OTP factor first. The benefit of this approach is if the OTP is not known, a password (regardless if it's wrong) will never be sent from the NetScaler to the LDAPS server unless OTP is successful, completely eliminating the problem of brute force attempts hammering AD until successful. 
    Having a token based factor as part of the authentication, does make the job of breaking in harder. Access passwords do change, but the frequency at which they are changed is likely every few months. The token typically changes every 30 seconds. A password plus token approach is very common. This process flow provides a level of protection to the ‘weaker or more static’ password that the user has.
    Pros: It is simple and effective, and can be transparent to the user. The settings are defined by the admin.
    Cons: Not much. The issue is typically, this nuance(LDAP first, rather than OTP first) is missed during the NetScaler setup, weakening the overall setup.
    2. IP Reputation with a responder policy
    This reputation feature detailed here, can also be used to potentially reject IP addresses that have been black listed for one reason or another(malware etc). IP addresses will be marked as bad by a web service that the NetScaler can access, a simple responder policy, can be used to inspect the source IP of the client request and decide if the connection is to be allowed.
    Pros: A simple responder policy, not much over head.
    Cons: Needs the premium feature set.
    3. Geo blocking IP ranges
    If the service is typically only to offer access to users in a specific country or locality, why have access to the broader world? A Geo database is included with NetScaler, that could be considered as ‘good enough’ to add this layer of security.
    Pros: Another, simple responder policy, not much over head.
    Cons: Available on all NetScaler types, needs to be included with other techniques.
    4. Allow and Deny lists of IPs
    Using a call out in combination with a ‘list’, this could be Deny list or Allow list. The steps are listed here. The Deny list approach means that the admin will monitor an block denied access requests from the same IP. The Allow list is the opposite, only allowing addresses that have a successful authenticated.
    Pros: It can filter out bad IP addresses.
    Cons: Can be an admin heavy way of doing things, every IP address (following the Deny list approach) needs to be blocked, bad actors can change addresses quickly.
    5. Using Action analytics to dynamically create an ACL in memory for the threat actors’ source IP
    When this was first suggested, it is a very cool way to address an attack. The NetScaler has its configuration modified to address the behaviour of the attacker. Action Analytics can be used to monitor the logs and add/perform an ACL addition to block the requesting Source IP using a callout.
    It is a somewhat over engineered approach. The bad guys get you to change the NetScaler setup. There are possibly other options that get the job done with less complexity.
    Pros: Its cool! It is amazing what a NetScaler can do.
    Cons: This does require a level of expertise to setup the NetScaler that is ‘uncommon’. Does it really need to be done? Again, option 1 is a more simple solution.
    Nice to have/other options?
    Rate limit the VPN Vserver
    Set rate limit for NS GW VPN vserver and have appropriate responder policy. This should help with brute force attack when automated bots are sending several combination of user credentials at high rate.
    Pros: Simple
    Cons: Needs to be added to other options. Could be part of a layered defence. Likely not needed if step 1 is done properly.
    Max Login and timeout
    This CTX230464 support document has some simple policy steps to defend the user password. Adding a ‘Max login attempts’ and a timeout for those attempts does give the admin setting that will trigger if user fails to login within 5 attempts. The account would be locked for 15 minutes. This would push up the time to break in, assuming this is the only option set.
    Pros: It is a simple setting on the gateway vserver. Should be enabled by default.
    Cons: If the attack is consistent, the admin will have multiple requests for ‘unlock’ requests from the legitimate user. This is best when combined with other techniques. Another point about relying on just this option, Max login is unlikely to help very much against a broad brute force attack against many users. If, a dictionary of hundreds of likely usernames and a list of random passwords for each, it would be trivial to ensure it didn't perform multiple attempts for the same account within a period. Rather than trying three logins per minute for one user, it would be possble to try one login per minute for three users, elongating the per user time but neatly avoiding tripping the max login flag.
    WAF on Gateway/AAA Vserver
    The details are listed here. Starting from NetScaler release 14.1 build 21.57, you can protect the NetScaler Gateway virtual servers, traffic management virtual servers, and authentication virtual servers against malicious attacks by applying Web Application Firewall protection. This functionality provides an additional layer of security to your deployments as it filters incoming requests by validating them using the API schema and then authenticates users to access applications.
    Pros: Simple to add, not dependant on having the WAF module licensed.
    Cons: It is quite a new capability.
    Implement Google Captcha (requires nFactor).
    The option described here. This is used to make the user/requester do something only a human can do. This assumes that other techniques have not been successful.
    Pros: Stops a BOT.
    Cons: Can be annoying for the real users, or is that just me?
    Leverage BOT Protection
    NetScaler bot management provides the following benefits:
    Defend against bots, scripts, and toolkits. Provides real-time threat mitigation using static signature based defence and device fingerprinting.
    Neutralise automated basic and advanced attacks. Prevents attacks, such as App layer DDoS, password spraying, password stuffing, price scrapers, and content scrapers.
    Inform the ISP
    A python script could be a good option. The logic would likely be to parse data on the 3P syslog server, query splunk, etc. Match login attempts against IPs within a defined period, set a threshold value for max attempts, find the abuse contact with an automated 'whois' lookup, drop them an email with stock text. "Hey my friend, your IP address A.B.C.D has tried to login to my server 500 times or more in the last hour, you might want to look into that, etc". 
    People say an attacker can create a new VM to attack from in a couple of minutes, but the reality is that it's usually a little more time consuming as you need to fill in at least some forms for a new account and pay some tiny number of dollars. If I were attacking someone and needed to google for a new VM provider, make an account, create a VM, re-upload my naughty scripts, and pay another $5 every day, it would get tiresome quite quickly even if that process only took me five minutes; I'd move on and bother someone else, especially if I were seeing no success. 
    Pros: Could be used with other techniques. Automation is key!
    Cons: Create a script in python to this this might require some skills!
    Summary
    Two factor authentication for NetScaler can be augmented with some of the above steps to keep you gateways/AAA vservers better protected against brute force attack. The document, also talks about other techniques, however using a validated baseline and setting the OTP option to validate first is the best defence.
    NetScaler Cyber Threat Intelligence
    NetScaler WAF Signatures Update v130
     
    NetScaler has released a new version of its integrated Web App Firewall signatures to help customers mitigate several CVEs with variable CVSS. 
    CVE-2024-4434: The LearnPress – WordPress LMS Plugin harbors a weakness, a time-based SQL Injection vulnerability. In versions up to, and including, 4.2.6.5, the plugin fails to adequately escape the term_id parameter. This oversight allows unauthenticated attackers to inject additional SQL queries, potentially extracting sensitive information from the database .
    CVE-2024-4397: Within the same plugin, LearnPress, lies another flaw—this time, an arbitrary file upload vulnerability. The issue arises due to the absence of proper file type validation in the save_post_materials function (versions up to 4.2.6.5). Attackers with Instructor-level permissions or higher can upload arbitrary files, opening the door to potential remote code execution .
    CVE-2024-30163: Alas, this one remains shrouded in mystery. Details for CVE-2024-30163 are currently reserved, leaving us in suspense. When the veil lifts, we’ll learn more about the nature of this vulnerability.
     Signatures included in v130:
    Signature rule
    CVE ID
    Description
    998489
    CVE-2024-4434
    WEB-WORDPRESS LearnPress Prior To 4.2.6.6 - Unauthenticated SQL Injection Vulnerability (CVE-2024-4434)
    998490
    CVE-2024-4397
    WEB-WORDPRESS LearnPress Prior To 4.2.6.6 - Arbitrary File Upload Vulnerability (CVE-2024-4397)
    998491
    CVE-2024-30163
    WEB-MISC Invision Community Prior to 4.7.16 - SQL Injection Vulnerability (CVE-2024-30163)
    NetScaler customers can quickly import the above signatures to help reduce risk and lower exposure associated with these vulnerabilities. Signatures are compatible with NetScaler (formerly Citrix ADC) software version 11.1, 12.0, 12.1, 13.0 and 13.1. NOTE: Software versions 11.1 and 12.0 are end of life, and you should consider upgrading for continued support. Learn more about the NetScaler software release lifecycle.
     
    If you are already using NetScaler Web App Firewall with the signature auto-update feature enabled, verify that your signature file version is 130 or later and then follow these steps.
    Search your signatures for <number> Select the results with ID  Choose “Enable Rules” and click OK  
    NetScaler WAF Best Practices
    NetScaler recommends that WAF users always download the latest signature version, enable signature auto-update, and subscribe to receive signature alert notifications. NetScaler will continue to monitor this dynamic situation and provide updates as new mitigations become available.
     
    Handling false positives
    If app availability is affected by false positives that result from the above mitigation policies, relaxations can be applied. NetScaler recommends the following modifications to the policy.
     
    Modifications to NetScaler Web App Firewall Policy:
    add policy patset exception_list
    # (Example: bind policy patset exception_list “/exception_url”) 
    Prepend the existing WAF policy with:
    HTTP.REQ.URL.CONTAINS_ANY(“exception_list”).NOT
    # (Example :  set appfw policy my_WAF_policy q^HTTP.REQ.URL.CONTAINS_ANY(“exception_list”).NOT && <existing rule>^
    NOTE: Any endpoint covered by the exception_list may expose those assets to risks 
    Additional Information
    NetScaler Web App Firewall benefits from a single code base across all its form-factors (physical, virtual, bare-metal, and containers). This signature update applies to all form factors and deployment models of NetScaler Web App Firewall.
    Learn more about NetScaler Web app Firewall, read our alert articles and bot signature articles to learn more about NetScaler WAF signatures, and find out how you can receive signature alert notifications.
    Please join the NetScaler Community today and engage with your peers to learn more about how they are protecting their businesses with NetScaler WAF. 




     
    Angela Tripp
    NetScaler native support for the Cisco Duo Universal Prompt will be coming in late summer 2024.
    The requirements for using NetScaler with Duo Universal Prompt are:
    NetScaler Advanced or Premium Edition licenses NetScaler version 14.1  A future update of 14.1 that will include native support for the Duo Universal Prompt will be made available  If you are using NetScaler hardware, you can check now to see if it is compatible: NetScaler MPX / NetScaler SDX  Any paid Duo edition In the interim, we want to reassure you that the current NetScaler/Duo integration that displays the Duo Traditional Prompt using RADIUS iFrame will continue to be supported until December 31, 2024. This will give you time to update your NetScaler ADCs so that you can begin using the Duo Universal Prompt when the new integration becomes available. After December 31, 2024, this legacy integration will be considered end of support, with a future end-of-life date to be announced.
    If you are using Citrix Federated Authentication Service (FAS) and NetScaler, you can use the new Duo SSO integration for NetScaler today and get the expanded feature set and stronger security that the Duo Universal Prompt provides.
     
    Rick Davis
    When securing applications with a Web Application Firewall (WAF), issues may arise that require remediation. This article explains how to implement a process for managing temporary allowances while your team addresses these issues. This approach ensures tracking and auditing of exceptions, delegation, and review and removal of allowances when they are no longer needed.
    The process:
    Identify the Issue: Review the logs to pinpoint the specific resource and violation. Configure WAF Logging Troubleshooting with Web Application Firewall logs Support articles: CTX138973, CTX200351, CTX131792 Investigate: Understand the root cause.  Temporary Allowance – It may be necessary to squelch the logging or maintain application functionality for the purpose of providing time for developers to update their code.  Add the impacted URL to an exception list and set a tracking identifier for monitoring and removing the temporary allowance. Configure the WAF to allow the entries in the temporary exceptions list to bypass security processing. Update Code: Modify the application code to comply with security standards. Temporary Allowance Review – Periodically monitor for the remediated code and remove the temporary allowance by removing the URL from the exception list. *Temporary allowances may be necessary earlier in the process to stop application disruptions or to reduce logging of discovered issues. By enabling exceptions, organizations can maintain operational continuity while investigating root causes and devising permanent solutions.
     
    Temporary Allowance Table
    By using a list of exceptions, specific requests which require temporarily bypassing WAF processing can be handled precisely, minimizing the risk of exposing the entire application to potential threats. This targeted approach ensures that only the necessary traffic is bypassed, maintaining overall security while addressing specific needs. Additionally, it allows for better tracking and auditing of these exceptions, ensuring that they are reviewed and removed when no longer needed.
    | Index | URL Pattern       | Comment                             | |-------|-------------------|-------------------------------------| | 1     | example.com/login | Ticket: ABC-123, Expire: 2024-06-30 | | 2     | /admin            | Ticket: DEF-456, Expire: 2024-07-15 | | 3     | mqtt.example.com  | Ticket: GHI-789, Expire: 2024-08-07 | Including a Jira ticket number or another form of development tracking identifier as a comment to the temporary exception provides a clear link between the security exception and the corresponding development task, enabling seamless collaboration between security and development teams and facilitating better coordination and prioritization of efforts. Additionally, specifying an expiration date within the comment ensures transparency and accountability, indicating when the exception should be reviewed or removed to maintain security hygiene and mitigate potential risks effectively.
    add patset temp_exceptions bind policy patset temp_exceptions "example.com/login" -comment "Ticket: ABC-123, Expire: 2024-06-30" bind policy patset temp_exceptions "/admin" -comment "Ticket: DEF-456, Expire: 2024-07-15" bind policy patset temp_exceptions "mqtt.example.com" -comment "Ticket: GHI-789, Expire: 2024-08-07" 🖱️ In the NetScaler web interface: AppExpert > Pattern Sets
    📖 Reference: Configure a Pattern Set
     
     
    Optional: Delegated Authority
    Using a table for exceptions allows management delegation without compromising security settings or policies. By separately defining permissible exceptions, team members can manage these allowances without full access to WAF settings.  This approach ensures efficient workflow and accountability, maintaining the overall security posture while empowering operations teams.
    With the following configuration, read-only users assigned the "Edit_Temp_Exceptions" command policy will be authorized to execute commands specifically for adding and removing entries in the "temp_exceptions" pattern set (table), ensuring controlled access to this aspect of NetScaler configuration.
    add system cmdPolicy Edit_Temp_Exceptions ALLOW "^(bind|unbind)\s+patset\s+temp_exceptions.\s+.*$" 🖱️ In the NetScaler web interface:  System > User Administration > Command Policies     
    📖 Reference: Custom Command Policies
     
     
    Temp Allowances using an AppExpert Policy
    The following AppExpert expression evaluates HTTP requests to check if they contain certain hostname and/or URL patterns associated with the list of temporary exceptions:
    add policy expression temp_exception q{(HTTP.REQ.HOSTNAME.SERVER.APPEND(HTTP.REQ.URL.PATH.SET_TEXT_MODE(IGNORECASE)).STARTSWITH_ANY("temp_exceptions") || HTTP.REQ.URL.PATH.SET_TEXT_MODE(IGNORECASE).STARTSWITH_ANY("temp_exceptions"))} Breaking it down:
    HTTP.REQ.HOSTNAME.SERVER.APPEND(HTTP.REQ.URL.PATH.SET_TEXT_MODE(IGNORECASE)).STARTSWITH_ANY("temp_exceptions"):
    This condition checks if the concatenation of the requested resources name and folder location matches any of the specified patterns defined in the "temp_exceptions" table.  
    📖 Reference: HTTP_HOSTNAME_T HTTP.REQ.URL.PATH.SET_TEXT_MODE(IGNORECASE).STARTSWITH_ANY("temp_exceptions")):
    This condition checks if the requested objects location contains any of the specified patterns defined in the "temp_exceptions" table. Consider changing STARTSWITH_ANY to CONTAINS_ANY() or EQ_ANY() to get desired matching behavior.  Operations on HTTP_URL 🖱️ In the NetScaler web interface:  AppExpert > Expressions > Advanced Expressions
    📖 Reference: Configure advanced policy expressions
     
     
    Optional: Test this expression with the Expression Evaluator.
    🖱️ In the NetScaler web interface:  AppExpert | Tools > Advanced Expression Evaluator               

    Production-quality systems are even faster than the evaluation speed of 0.0001 milliseconds.
     
    Update the AppFirewall Policy
    Finally, prepend your AppExpert policy expression to the existing WAF expression so that requests for objects in the "temp_exception" list are excluded from security enforcement:
    set appfw policy <name> "temp_exception.NOT && <existing rule>" Breaking it down:
    temp_exception.NOT: This named entity is negated with .NOT so that it returns FALSE instead of TRUE when matching patterns defined in the "temp_exception" pattern set table.  When the condition evaluates to FALSE, the AppFW policy will not be applied to the incoming request. &&: This is the logical AND operator, meaning both conditions must be true for the overall expression to evaluate True and enforce the associated security rules. <existing_rule>: Refers to the condition used prior to the addition of the exceptions table.  This may be any AppExpert expression including but not limited to: HTTP.REQ.IS_VALID, or HTTP.REQ.HOSTNAME.DOMAIN.EQ("example.com")  🖱️ In the NetScaler web interface:  Security > NetScaler Web App Firewall > Policies > Firewall
    📖 Reference: Creating and configuring Web App Firewall policies
     
    This appfw policy rule verifies that incoming HTTP requests are a policy match and not listed as a temporary exception. When both conditions are met, the expression evaluates to true, indicating that the request should proceed according to the defined application firewall policy it applies to.
    Periodically check for the remediated code and remove the resource location from the temporary allowance table to reinstate the security enforcement.
     

©

Cloud Software Group, Inc. All rights reserved.
×
×
  • Create New...