Jump to content

  • Articles

    Show all categories
    Guest
    NetScaler WAF Signatures Update v123
     NetScaler has released a new version of its integrated Web App Firewall signatures to help customers mitigate several CVEs with variable CVSS. Two notable additions are:
    CVE-2024-21650 which is a vulnerability in XWiki Enterprise, an open-source wiki software that is used by many organizations to manage their knowledge base. This vulnerability has been assigned a CVSS score of 9.8, which is considered critical. The vulnerability allows an attacker to execute arbitrary code with elevated privileges, which could lead to a complete compromise of the system. This could result in the loss of sensitive data, unauthorized access to critical systems, and other serious consequences. It is recommended that users apply the latest security patches to their XWiki Enterprise installations to mitigate the risk of exploitation.
    CVE-2023-22527 which is a template injection vulnerability in Atlassian Confluence Data Center and Server. This vulnerability only affects out-of-date versions of these products. An unauthenticated attacker could exploit this vulnerability by sending a specially crafted request to a vulnerable Confluence Data Center or Server instance. Successful exploitation would allow an attacker to obtain remote code execution. This vulnerability carries a CVSS score of 10, the highest critical rating. It is recommended that users upgrade to the latest version of Confluence Data Center or Server to mitigate the risk of exploitation. Additionally, users should ensure that their Confluence instances are not exposed to the internet and that access to the application is restricted to authorized personnel only.
      Signatures included in v123:
    Signature rule
    CVE ID
    Description
    998548
    CVE-2024-21650
    WEB-MISC xWiki Platform Prior Multiple Versions - Remote Code Execution Vulnerability (CVE-2024-21650)
    998549
    CVE-2023-6875, CVE-2023-7027
    WEB-WORDPRESS POST SMTP Plugin Prior to 2.8.8 - Missing Authorization/XSS Vulnerability (CVE-2023-6875,CVE-2023-7027)
    998550
    CVE-2023-51409
    WEB-WORDPRESS AI Engine Plugin Prior To 1.9.99 - Unauthenticated Arbitrary File Upload (CVE-2023-51409)
    998551
    CVE-2023-46805, CVE-2024-21887
    WEB-MISC Ivanti Connect Secure Multiple Versions - Remote Code Execution vulnerability (CVE-2023-46805,CVE-2024-21887)
    998552
    CVE-2023-46805, CVE-2024-21887
    WEB-MISC Ivanti Connect Secure Multiple Versions - Remote Code Execution vulnerability (CVE-2023-46805,CVE-2024-21887)
    998553
    CVE-2023-22527
    WEB-MISC Atlassian Confluence Server and Data Center Multiple Versions - Remote Code Execution Vulnerability (CVE-2023-22527)
    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 123 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. 
     
     
     
     
     
    Mayur Vadhar
    Use the REST APIs to create and consume reports that help you to manage licensing in Citrix Cloud. As an IT administrator, use the Citrix cloud licensing APIs for enterprise customers, partners with on-premises Citrix Virtual Apps and Desktops or Citrix DaaS (formerly Citrix Virtual Apps and Desktops service).
    Citrix cloud licensing API for enterprise customers
    Use Citrix cloud licensing APIs for the following:
    Export data about the different cloud services into Excel or Tableau. You can export data on devices, users, enrolment, license assigned date, last login time, and historical data up to 12 months. Release expired cloud service licenses such as licenses Citrix DaaS, Citrix DaaS Standard for Azure (formerly Citrix Virtual Apps and Desktops Standard for Azure), Citrix Endpoint Management, or Citrix Secure Workspace Access. Customize and aggregate data for reporting purposes. Citrix cloud licensing API for partners with on-premises Citrix Virtual Apps and Desktops
    As a partner with on-premises Citrix Virtual Apps and Desktops, use Citrix cloud licensing APIs for the following:
    To get the number of licenses at a summary level for the following: Total users Paid users Free users License servers Customers count To get the number of licenses per customer for the following: Account name Total users Paid users Free users Historical data up to 12 months Citrix cloud licensing API for partners with Citrix DaaS
    As a partner with Citrix DaaS, use Citrix cloud licensing APIs for the following:
    To get the number of licenses at a summary level for the following: Total current number of customers Total current number of licenses across all customers Total current number of users across all customers Total current number of license overage across all customers To get the number of licenses per customer for the following: Organization ID Current 'Total Licenses' owned Current 'Total Users' used Current 'License Overage' Historical data up to 12 months
    Steven Wright
    Overview
    Citrix Application Delivery Management (ADM) is a centralised management solution that enables you to operate, upgrade, report on, and troubleshoot all your NetScaler's across a global estate.
    One of Citrix ADM's best features is StyleBooks - declarative descriptions of a desired state written in YAML and consisting of input parameters and components driven by those inputs. A StyleBook causes Citrix ADM to read your current NetScaler configuration, compute the differences between your current and target state, and implement the required settings.
    While you can write StyleBooks yourself, Citrix ADM comes with more than 35 default StyleBooks, covering everything from building a simple HTTP load balancer to all of the content switching, load balancing, and authentication settings needed to support Exchange 2016. Learn about using default StyleBooks and creating custom StyleBooks.
    In this blog post, I focus on simple HTTP load balancers but provide enough detail so you can apply the logic to any StyleBook. Specifically, I'm going to focus on a StyleBook called "lb" with the namespace "com.citrix.adc.stylebooks"which you can find by selecting Applications, Configuration, StyleBooks within Citrix ADM.
     


    This post is the first in a two-part series that describes how to rapidly create services on your NetScaler's using Citrix ADM StyleBook automation, accelerating your migrations. We'll create 300 load balancers across an estate of several NetScaler's within 15 minutes. This post is aimed at DevOps employees who want to start working with Citrix ADM and need a brief introduction with examples (which you can download here).
    In my second post, I target sysadmins and focus on using preprepared scripts to achieve our goal of creating the 300 load balancers.
     

    Citrix ADM and the NITRO API
    The second best thing about Citrix ADM is that you can access it using API calls, which is how we'e going to automate our StyleBook. You can see more on that below but, you can also find more information here:
    Citrix ADM 13.1 NITRO API Reference documentation Using APIs to create configurations from StyleBooks To call your script to log in using the NITRO API, you need an ID and secret. You can create the ID and secret for Citrix ADM service by doing the following steps:
    Sign in to the Citrix Cloud portal. Select Identity and Access Management from the menu. Select the API Access tab. Name your Secure Client, and click Create Client.  

     


    NITRO API request for a session ID
    After you have the ID and secret, you can sign in and collect a session ID using the following Python commands (this isn't my real ID and secret):
    Python
    import http.client import json id = "f20e7432-7a83-416d-a171-9347b92761f4" secret = "7-rotB6QMFZTuOgpPajPBg==" conn = http.client.HTTPSConnection("adm.cloud.com") headers = { 'isCloud': 'true', 'Content-Type': 'text/plain', 'Cookie': '' } request = { "login": { "ID": id, "Secret": secret } } payload = json.dumps(request) conn.request("POST", "/nitro/v2/config/login", payload, headers) response = conn.getresponse() data = response.read() if response.status != 200: print("Error:") print(" Status code: " + str(res.status)) print(" Error payload: " + data) exit(1) jsondata = json.loads(data) sessionid = jsondata["login"][0]['sessionid'] print (sessionid) Output ia6bMEB9xn_XUW0Rfy_86zNbKlG1rJgZrd-DM3u3MIM NITRO API request using the session ID to retrieve a list of NetScaler identifiers
    Now that you have a session ID token, you can request a list of NetScaler's and find the unique identifier of the instance on which you would like to operate. The session ID is taken from the preceding script.
    Python
    import http.client import json sessionid = "ia6bMEB9xn_XUW0Rfy_86zNbKlG1rJgZrd-DM3u3MIM" conn = http.client.HTTPSConnection("adm.cloud.com") headers = { 'isCloud': 'true', 'Content-Type': 'text/plain', 'Cookie': 'NITRO_AUTH_TOKEN=' + sessionid } conn.request("GET", "/nitro/v2/config/managed_device", None, headers) response = conn.getresponse() data = response.read() if res.status != 200: print("Error:") print(" Status code: " + str(res.status)) print(" Error payload: " + data) exit(1) jsondata = json.loads(data) #print('\n\nHere is the full JSON output from ADM.\n') #print (jsondata["managed_device"]) print('\n\nHere is a list of ADCs.\n') for device in jsondata["managed_device"]: name = device['hostname'] ip = device['ip_address'] id = device['id'] type = device['type'] version = device['version'] status = device['status'] if status == "Success": print (name + " " + ip + " " + id + " " + type) Output Here is a list of ADCs. myhostname 192.168.1.240 a1fe50be-e187-44bb-871b-d60f112b0aff nsvpx Knowing the parameters to submit to a StyleBook
    Now that we have a session ID and the identifier of an NetScaler to target, we can run a StyleBook. First, however, we need to understand the various parameters that it expects us to submit before doing so.
    You can gather the parameters by programmatically requesting the StyleBook's schema, which describes all valid parameters and which are optional, or by reviewing the source YAML for the StyleBook and its dependencies.
    Here are the Python commands to request a StyleBook's schema.
    Python
    import http.client import json sessionid = "ia6bMEB9xn_XUW0Rfy_86zNbKlG1rJgZrd-DM3u3MIM" base_types = ["string", "ipaddress", "number", "boolean", "tcp-port", "password", "file", "certfile", "keyfile", "certkey", "ipnetwork"] def get_config_parameters(parameters): configpack_params = {} for parameter in parameters: parameter_name = parameter["name"] parameter_type = parameter["type"] parameter_required = parameter["required"] if parameter_type in base_types: if parameter_required: parameter_type += "*" if parameter_type.endswith("[]"): configpack_params[parameter_name] = [parameter_type] else: configpack_params[parameter_name] = parameter_type else: if "parameters" in parameter: subparameters = parameter["parameters"] datatype = get_config_parameters(subparameters) else: datatype = parameter_type if parameter_type.endswith("[]"): configpack_params[parameter_name] = [datatype] else: configpack_params[parameter_name] = datatype return configpack_params conn = http.client.HTTPSConnection("adm.cloud.com") stylebook = "com.citrix.adc.stylebooks/1.1/lb" headers = { 'Cookie': 'NITRO_AUTH_TOKEN= ' + sessionid } conn.request("GET", "/stylebook/nitro/v1/config/stylebooks/" + stylebook + "/schema", None, headers) res = conn.getresponse() data = res.read() if res.status != 200: print("Error:") print(" Status code: " + str(res.status)) print(" Error payload: " + data) exit(1) schema = json.loads(data, "utf-8") parameters = schema["schema"]["parameters"] config_parameters = { "parameters": get_config_parameters(parameters) } print(json.dumps(config_parameters)) The output from this schema request is the format of the parameters section of a config pack. From this output, you can remove parameters you don't intend to use. As a clue, the required parameters are marked with a "*" at the end of their type.
    Another (and possibly easier) way to achieve the same thing is to use the Citrix ADM UI to create a template that shows only the parameters I want to use.
    To create the template, I open Citrix ADM's web interface and run my selected StyleBook with dummy values against a non-production NetScaler in a lab. In doing so, I create a config pack with each of the values I would need for a production service.
     
     


     
     

    Having created the config pack, I now select Applications > Configuration > Config Packs from within the Citrix ADM web interface and export the resultant configuration.
     

     
     

     

    After downloading and opening the exported ZIP file, I find that it contains a single JSON file with all the parameters that I need to submit to the API.
     


     
     


    NITRO API request using the session ID to automate a StyleBook and target an NetScaler identifier
    Finally, having retrieved a session ID, the unique identifier of the NetScaler to operate on, and clarity into the parameters needed to submit to the StyleBook, we are ready to script execution of the StyleBook itself.
    Note: Delete the template configuration pack from Citrix ADM if you want to use the same input parameters within your Python script.
    Python
    import http.client import json sessionid = "ia6bMEB9xn_XUW0Rfy_86zNbKlG1rJgZrd-DM3u3MIM" target_adc = "a1fe50be-e187-44bb-871b-d60f112b0aff" stylebook = "com.citrix.adc.stylebooks/1.1/lb" conn = http.client.HTTPSConnection("adm.cloud.com") payload = json.dumps({ "configpack": { "targets": [ { "id": target_adc } ], "parameters": { "lb-appname": "ApplicationName", "lb-virtual-ip": "192.168.50.10", "lb-virtual-port": "80", "lb-service-type": "HTTP", "svc-service-type": "HTTP", "svc-servers": [ { "ip": "192.168.5.20", "port": 80, "add-server": True }, { "ip": "192.168.5.21", "port": 80, "add-server": True } ], } } }) headers = { 'Content-Type': 'application/json', 'Accept': 'application/json', 'Cookie': 'NITRO_AUTH_TOKEN=' + sessionid } conn.request("POST", "/stylebook/nitro/v1/config/stylebooks/" + stylebook + "/configpacks", payload, headers) res = conn.getresponse() data = res.read() if res.status != 200: print("Error:") print(" Status code: " + str(res.status)) print(" Error payload: " + data) exit(1) payload = json.loads(data, "utf-8") jobid = payload["configpack"]["job_id"] print("Configuration Job " + jobid + " has started.") Output Configuration Job 204770189 has started. Viewing a job_id
    At this point you are able to see the config pack that your script created within the ADM GUI and the resultant configuration on your NetScaler.
     

     
    If that didn't happen, you can view the details of the "job_id" and understand its status. We can retrieve the outcome of the job by sending a GET request.
    To illustrate, I purposely ran another StyleBook targeted at a non-existent NetScaler ID.
    Python
    import http.client import json sessionid = "ia6bMEB9xn_XUW0Rfy_86zNbKlG1rJgZrd-DM3u3MIM" jobid = "2476087615" headers = { 'Content-Type': 'application/json', 'Accept': 'application/json', 'Cookie': 'NITRO_AUTH_TOKEN=' + sessionid } conn = http.client.HTTPSConnection("adm.cloud.com") job_status = None while job_status != "completed" and job_status != "failed": conn.request("GET", "/stylebook/nitro/v1/config/jobs/" + jobid, None, headers) response = conn.getresponse() data = response.read() if response.status != 202: print("Error:") print(" Status code: " + str(response.status)) print(" Error payload: " + data) exit(1) payload = json.loads(data, "utf-8") job_status = payload["job"]["status"] config_id = payload["job"]["progress_info"][0]["id"] if job_status == "completed": print("Success: configuration " + config_id + " successully created") else: print("Error: Failed to create configuration.") progress_info = payload["job"]["progress_info"] for step in progress_info: error_details = step["message"] print(" " + json.dumps(error_details)) exit(1) Output (failure) Error: Failed to create configuration. "Validating the parameters" "Configuration pack process failed. Instance with id g4702445-2286-4b6d-8fb1-c231a0ee17b1 not found on the system." Here, we can observe a clear explanation of the issue. We can observe success messages on jobs that run without issue.
    Output (success) Success: configuration 204770189 successfully created Next steps
    We have now seen how we can programmatically authenticate to Citrix ADM, retrieve a list of identifiers for the NetScaler's that it manages, prepare and run StyleBooks against a chosen NetScaler, and retrieve the result.
     
    We have also observed how you can find the namespace, version, and name of alternative StyleBooks and retrieve the various properties they require.
     
    Using this knowledge, your DevOps team is able to integrate Citrix ADM StyleBooks and their automated NetScaler configuration into your existing workflows.
     
    In the second of this two-part series, using the example of creating 300 load balancers across an estate of several NetScaler's within 15 minutes, I share prebuilt scripts that allow those without a DevOps team to create business services rapidly during a platform migration.
    Steven Wright
    In this two-part blog series, I describe how to rapidly create services on your NetScaler's using Citrix Application Delivery Management (ADM) StyleBook automation to accelerate migrations. In the example, we create 300 load balancers across an estate of several NetScaler's within 15 minutes.
    My first post was aimed at DevOps. In this post, I target Sysadmin employees and focus on a pre-prepared script that I wrote. The script helps you to achieve our goal of rapidly creating load balancing virtual servers.
    You can download the script and its two supporting files here.
    Note: The script requires Python 3 and jinja2, that you can install with pip using the command
    pip install jinja2 Prepare the StyleBook template("template.txt")
    The first of the script's two supporting files is named template.txt.
    The template.txt file is already preprepared for the simple HTTP load balancers that we create in this post, and you don't need to modify it. However, I do want to explain how you can make those modifications, in case you want to target other StyleBooks or introduce extra parameters.
    On the second line of the template.txt, you can find the namespace, version, and the name of the targeted StyleBook.
    StyleBook NAMESPACE/VERSION/STYLEBOOK com.citrix.adc.stylebooks/1.1/lb If you want to change the template file's target, you can view the namespace, version, and the name of another StyleBook within Citrix ADM's web interface.
     
     

     

    On lines five to 12 of the template.txt, you can find placeholder names that correspond to the columns in a CSV file called lbvserver.csv, which is also included with the script.
    CSV columns
    targetadc name lbvirtualip lbvirtualport lbservicetype svcservicetype svcservers: list svcserverport As you can see from the placeholder named svcservers: list, if the columns in the CSV file contain a list of items, such as a list of back-end servers for a load balancing virtual servers, we note this by appending ": list" to the placeholder's name.
    You can find a template with each value that our script must submit to the StyleBook at line 14. Each item in the template matches one of the placeholder values you created earlier, and the template includes a loop where it encounters a list.

    Template
    { "configpack": { "targets": [{"id": "<<targetadc>>"}], "parameters": { "lb-appname": "<<name>>", "lb-virtual-ip": "<<lbvirtualip>>", "lb-virtual-port": "<<lbvirtualport>>", "lb-service-type": "<<lbservicetype>>", "svc-service-type": "<<svcservicetype>>", "svc-servers": [ <% for server in svcservers %> { "port": << svcserverport >>, "ip": "<< server >>", "add-server": true }<<,>> <% endfor %> ] } } } Again, you need to edit the template file only you're modifying the script to target an alternative StyleBook or you're introducing extra parameters.


    Preparing the script
    As we saw in Part 1, you need an ID and secret to allow the script to log in into your Citrix ADM environment. If you're using the Citrix ADM service, you can create the ID and secret by doing the following steps:
    Sign in to the Citrix Cloud portal. Select Identity and Access Management from the menu. Select the API Access tab. Name your Secure Client, and click Create Client.  

     

    After you have the ID and secret, replace the placeholder example values within the create2.py python script.
    # Set my login variables for ADM # You can create an ID and secret by selecting the Identity and Access Management tab in your Cloud portal Id = "1707d2ff-e200-46be-848a-93faf2076d6b" Secret = "DIH1CzF_GSZG2zNnEVShLA=="` Preparing the Excel CSV template
    Now that you've set the ID and secret values, you can run the script with the "-a" parameter to display a list of NetScaler's and their identifiers.
    Command
    python create2.py -a Output
    The following NetScaler instances IDs can be referenced within your CSV file. Name - IP address - ID for use in CSV. 1\. bob - 192.168.1.240 - a0de40bb-e186-44bb-871b-d60f112b0a3a Here, we can observe that I have an NetScaler with the host name "bob" on IP address "192.168.1.240" with the unique identifier "a0de40bb-e186-44bb-871b-d60f112b0a3a." You must note each identifier because we need them later.

     
    Prepare a list of load balancing virtual server ("lbvserver.csv")
    The second of the script's two supporting files is named lbvserver.csv.
    Each row in the lbvserver.csv file includes the properties for a single StyleBook, in this case, the properties for a single HTTP Load Balancing virtual servers.
    Each column in the lbvserver.csv file is the source for the placeholders within the template.txt file. The columns and placeholders are in the same order, with the first column being the first placeholder and so on.
    I have expanded the lbvserver.csv file to contain 300 rows (300 HTTP Load Balancing virtual servers) for this post. If my customer had a similar requirement, I would likely populate an initial CSV with all the expected values. Then, they would forward the CSV internally to ensure that the names, naming conventions, and IP addresses were all as desired.
    As you can observe by comparing the columns to the template.txt file, column A specifies the unique identifier of the NetScaler that we target, and columns B to H are the input parameters for the StyleBook. You can include lists in the parameters with ":" used as a separator.
    After modifying the lbvserver.csv file to reflect the virtual servers that you want to create, you must save in "CSV" rather than "CSV (UTF8)" format.
     
     

     


    Running the script (python create2.py)
    Having populated the script with an ID and secret that allow access to your Citrix ADM environment and updated the columns to reflect which NetScaler you want to build on and the properties, we are now ready to create our load balancing virtual servers.
    We can now run the script and create a Citrix ADM config pack along with the resultant NetScaler configuration.
     
    Command
    python create2.py Output (shortened)
    Creating ADM Config Pack based on CSV row: 1 {"configpack": {"job_id": "1926702141"}} Creating ADM Config Pack based on CSV row: 2 {"configpack": {"job_id": "2520889571"}} Creating ADM Config Pack based on CSV row: 3 {"configpack": {"job_id": "2581540139"}} Creating ADM Config Pack based on CSV row: 4 {"configpack": {"job_id": "1440135035"}} Creating ADM Config Pack based on CSV row: 5 {"configpack": {"job_id": "3264746514"}} The script takes around two to three seconds per row and completes the 300 rows in just under 15 minutes. After completion, the resultant Config Packs will be visible within ADM.
     
    Ongoing maintenance
    In addition to creating the virtual servers rapidly from a pre-agreed Excel CSV file, this script-based approach also allows management of the resultant virtual servers using ADM and future changes without a need to understand the underlying commands on their NetScaler's.
    You can view each of the resultant Config Packs by selecting Applications, Configuration, Config Packs from within the Citrix ADM web interface. By selecting Edit, you can then manage and update the Config Pack as your needs change.
     

     
     

     
     

     
     
     
     
    Next steps
    We have now created 300 load balancers across our estate using an adaptable template that allows you not only to create load balancers but any other StyleBook based configuration.
    If you want to understand how the script works, you can read through the first article in this series .
    Mayur Vadhar
    NetScaler Ansible modules can be used for automating NetScaler configurations. It also contains a generic module called citrix_adc_nitro_request which doesn’t target a particular endpoint instead can be used to perform NITRO API operations on various endpoints.
    Using Nitro Request Ansible module
    Let’s go through the example and understand the  execution of citrix_adc_nitro_request module
    - name: Get lb vserver delegate_to: localhost register: result citrix_adc_nitro_request: nsip: "{{ nsip }}" nitro_user: "{{ nitro_user }}" nitro_pass: "{{ nitro_pass }}" operation: get resource: lbvserver name: lbvs1 As we can see there is a group of attributes that are common among all ansible NetScaler modules for connecting to the target NetScaler. After these, we have the operation attribute which is the key to the execution of the module. It instructs the module which operation to perform. In our case we want the get operation to get information for a particular NITRO object. After that, we have the attributes that will determine which object will be fetched. In our case, we want the resource lbvserver with the name lbvs1. The result is stored in the result variable for further processing by subsequent modules. We could for example print out its contents with the debug module.
    Supported Operations
    Apart from the get operation the citrix_adc_nitro_resource module supports the following operations:
    add update Get get_by_args get_filtered get_all delete delete_by_args count mas_login save_config action The add operation is used to create a new NITRO object.
    The update operation is used to update an existing object
    The get* operations are used to retrieve information for an object. They are differentiated by how we define the choice criteria for object retrieval.
    The delete and delete_by_args operations are used to delete existing objects.
    The count operation is used to return the count of a NITRO object.
    The mas_login operation is used to retrieve the authentication token from an ADM to use in subsequent calls where the ADM will be used as a NITRO API proxy.
    The save_config operation is used to save the configuration on the target NetScaler.
    Finally, the action operation is used to perform an action against a NITRO endpoint. The action can vary. For example. one action would be to enable a basic server.

    It is worth noting that nitro_request will try to do as little as possible of processing apart from the operation it is instructed to do. In this way, you can think of it as a thin wrapper around the Ansible URI module. It mainly will provide a more convenient and intuitive interface to perform an HTTP operation. As a consequence of that it will always report a changed state as it will not do any processing to determine if an actual configuration change took place in the target Netscaler.

    Despite these limitations, it is useful in its own right and also can be combined with the citrix_adc_nitro_resource module to perform more complex tasks. For example, we could use the nitro_resource module to create a server and then the nitro_request module to enable or disable the server. An example playbook of that is shown below where we create a server and then proceed to disable it.
    Although it is a bit artificial as an example it showcases how the two generic modules could be combined to achieve the desired configuration.
    - hosts: citrix_adc gather_facts: False vars_files: - deps/workflows.yaml collections: - citrix.adc tasks: - name: Setup server delegate_to: localhost citrix_adc_nitro_resource: nsip: "{{ nsip }}" nitro_user: "{{ nitro_user }}" nitro_pass: "{{ nitro_pass }}" validate_certs: "{{ validate_certs }}" state: present workflow: "{{ workflow.server }}" resource: name: test-server ipaddress: 192.168.11.34 - name: Disable server delegate_to: localhost register: result citrix_adc_nitro_request: nsip: "{{ nsip }}" nitro_user: "{{ nitro_user }}" nitro_pass: "{{ nitro_pass }}" validate_certs: "{{ validate_certs }}" operation: action action: disable resource: server attributes: name: test-server delay: 30 graceful: !!str yes Useful Resources :
    NetScaler Ansible modules repository ( https://github.com/citrix/citrix-adc-ansible-modules ) Nitro resource examples ( https://github.com/citrix/citrix-adc-ansible-modules/tree/master/samples/nitro_resource ) Nitro request examples ( https://github.com/citrix/citrix-adc-ansible-modules/tree/master/samples/nitro_request )
    Steven Wright
    NetScaler migration
    Have you bought a new NetScaler with more throughput or is it time to refresh? Are you migrating from old NetScalers to new ones? Sounds difficult? Then you've stumbled across the right article. Installing new NetScalers into production and migrating services may seem like a complicated process, but once you know how to do it, it's much easier than you might think. This blog post will walk you through the steps needed.

    In this article, we will assume that you have an existing source NetScaler that's running in production and a new target NetScaler that you want to prepare in a non-production environment and migrate to under a change control process.



    Prepare for the migration (existing NetScaler)
    ADM Service's migration feature requires NetScaler firmware version 13.1.17 or above. To prepare for the upcoming migration, upgrade your existing NetScalers to 13.1.17 firmware so that both the source and target NetScaler have the same firmware version and support for ADM Service's migration feature.

    NetScaler recommends upgrading to the same firmware on the source and target NetScalers to minimize the number of changes during the migration and, in the unlikely event of any issues, to identify the cause more easily.

    You can upgrade your existing NetScaler to 13.1 firmware using the instructions here.


    Prepare for the migration (target NetScaler)
    First, install your new target NetScaler into a non-production environment without a connection to the production network. Ensuring the non-production and production networks are isolated from each other will prevent unintended interactions such as IP address conflicts.

    Once you have installed the new NetScaler, connect it to ADM Service. To do this, you need to add an ADM Agent into the non-production environment. You can install a new ADM Agent using the instructions here and add you can connect the new NetScaler to ADM Service using these instructions.

    Next, install a license onto your new NetScaler. You can apply a pooled license to your new NetScaler using the instructions here.



    Replicate the configuration
    After ensuring that the new NetScaler is not connected to any production networks, follow these steps to replicate the configuration.

    1. Select Infrastructure, Instances, NetScaler, and NetScaler form factor
    In the screenshot, we have selected the "VPX" form factor and can see two NetScalers, "192.168.6.30" and "192.168.1.230".

    In this article, we will use "192.168.6.30" as the source NetScaler and will replicate its configuration onto the target NetScaler on "192.168.1.230".
     

     
     
     
     

    2. Tick the source NetScaler, click "Select Action", and then choose "Replicate Configuration"
     
     
     
     
     

     
     
     

    3. Move the target NetScaler instance from the "Available" to "Configured" window using the arrow button and click "Create"
     
     


    ADM Service will now replicate the configuration from your source to target NetScaler.

    Note: Any existing configuration on the target instance will be erased and replaced with the configuration of the source NetScaler. The source and target NetScalers should be on separate networks to prevent IP conflicts.



    Validate the network configuration on the target NetScaler
    Although the source and target NetScalers will now have the same configuration, the management NSIP and network interface layout may differ.

    If you installed your new NetScaler into the non-production environment using a network interface layout that you don't want to use in production, you should change they layout now.

    To change the network configuration, log into the target NetScaler and ensure:
     
     
    That all unused interfaces are disabled That you have created LACP channels as you require That a SNIP is bound to each VLAN That each VLAN is bound to an interface or channel using your intended network layout
    You can find instructions detailing how to disable unused interfaces, create LACP channels, and how to bind SNIPs and VLANs here.


    Replace the NSIP on the target NetScaler
    If you installed your new NetScaler into the non-production environment using an NSIP that differs from production and would prefer it was the same at the point of migration, you should change the NSIP now.
    You can change the NSIP using the following steps.

    Note: If you are migrating an HA pair, you must perform the commands below on both nodes at the same time and shutdown both nodes at the same time.
     
    Select the target NetScaler within the "Infrastructure, Instances, NetScaler" menu of ADM, choose "SNMP" from "Select Action", then disable SNMP.
    Note: We are disabling these services to ensure they are not configured to communicate with the pre-production ADM Agent, we will re-enable them after the migration is complete.
     


     

     
     
     
    Using the same process as "step 1" (above), disable Syslog and Analytics on the target NetScaler.  
    Select the source NetScaler and repeat steps one and two (above) to disable SNMP, Syslog, and Analytics.  
    Log into the target NetScaler's command line interface using SSH. You can find details of how to use SSH here.  
    Change the NSIP of the target NetScaler using the commands shown in red. shell cd /nsconfig cp ns.conf ns.old sed -i -e 's/192.168.1.230/192.168.6.30/g' ns.conf Note: 192.168.6.30 is the source NetScaler in our example and 192.168.1.230 is the target NetScaler. You must replace the IP addresses within the command with those of your source and target NetScaler.
     
    Change references to the NSIP of the other HA node if applicable sed -i -e 's/192.168.1.231/192.168.6.31/g' ns.conf Note: You will run the sed command twice on both HA nodes. Firstly, to replace the NSIP of the current node. Secondly, to replace all references to that changed NSIP on its HA partner.
     
    Shutdown the NetScaler shutdown now Note: If you shutdown the NetScaler using an alternative command then you should reply "no" when ask if you wish to save the running configuration.

    The output will look like the text below.

    Note: In this example, we have included an example HA node with an NSIP of 192.168.1.231 that needs to be replaced with 192.168.6.31 - the replacement needs to be executed on both HA nodes.

    ###############################################################################
    #                                                                             #
    #        WARNING: Access to this system is for authorized users only          #
    #         Disconnect IMMEDIATELY if you are not an authorized user!           #
    #                                                                             #
    ###############################################################################

    Password:
    Last login: Mon Dec  6 14:26:05 2021 from 192.168.6.20
    Done
    nsroot@-Primary> shell
    Copyright (c) 1992-2013 The FreeBSD Project.
    Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
           The Regents of the University of California. All rights reserved.

    root@ns# cd /nsconfig
    root@ns# cp ns.conf ns.old
    root@ns# sed -i -e 's/192.168.1.230/192.168.6.30/g' ns.conf
    root@ns# sed -i -e 's/192.168.1.231/192.168.6.31/g' ns.conf
    root@ns# shutdown now
    Shutdown NOW!
    shutdown: [pid 8140]
    root@ns#                                                                               
    *** FINAL System shutdown message from root@ns ***                          

    System going down IMMEDIATELY                                                 

                                                                                  
    System shutdown time has arrived
    Connection to 192.168.6.30 closed by remote host.



    Replace the NetScaler under change control
    With the existing source and target NetScalers now having identical configurations, you can replace them in compliance with your change control procedures.

    Many customers achieve that change using a two-stage replacement process.

    In the first stage, they work with their network teams to connect the new NetScalers to network switch ports that are administratively disabled or offline.

    In the second stage, during a change control window, the network team places the switch ports to the old NetScalers into a disabled or offline state, brings the interfaces connecting the new NetScalers online, and flushes the ARP cache on their router.

    The effect is that all hardware installation and readiness activities can be completed in-advance and the change control window to move from the old to new appliances is completed in minutes. This approach also provides an excellent rollback strategy as the network could disable the interfaces connecting the new NetScaler and reenable those for the old, which are still powered on and running without modification.


    Re-establish connectivity to ADM Service
    You have now replaced the source NetScaler with the target. ADM will show the source as online (as the target is using the source NetScaler's NSIP) and the target's old NSIP as offline.

    You should now complete the following steps to ensure the migrated NetScaler is correctly communicating with ADM Service.
     
    To ensure ADM is communicating with the new NetScaler that has taken over the NSIPs of the source, select the source NetScaler within "Infrastructure, Instances, NetScaler" menu of ADM and, choose "Rediscover" from "Select Action".  
    After the rediscovery completes, re-enable the SNMP, Analytics, or Syslog capabilities that you disabled at step one of "Replace the NSIP on the target NetScaler". To enable each, select the NSIP of the source NetScaler and the capability under "Select Action".  
    If you are using pooled licensing on the new NetScaler, you must also ensure it is using the production ADM Agent as its license server. To do this, log into the new NetScaler using SSH and enter the following commands:
    sh nslicenseserver
     
    If the new NetScaler is not using the production ADM Agent as its license server, you can correct the license server to production ADM using the following commands:
    add nslicenseserver <prod_agent_ip> -port 27000 -forceUpdateIP
     
    Remove the target NetScaler's old NSIP from ADM by ticking the old NSIP within the "Infrastructure, Instances, NetScaler" menu of ADM and pressing "Remove".


    Next steps

    You have now finished migrating from your old to new NetScalers and can begin using them in production.
    Hemang Raval
    Submitted on:  May 10, 2021
    Author: Dharanikanth Dugginni   APIs are a critical infrastructure component and help to drive the modern digital economy. If your organization is using APIs, you can’t afford for them to go down. If your APIs are attacked successfully, it can lead to data loss, frustrated customers, and hits on your revenue and reputation. Strong authentication (Who is the client or user?) and authorization (What can the client or user do?) practices are essential to ensuring your APIs are secure.
    In this blog post, I’ll cover oAuth2.0, which has become the de facto standard for authenticating APIs and users in modern hybrid multi-cloud architectures (single-page apps, progressive web apps, mobile clients, and microservices). We’ll also look at how you can leverage the NetScaler API authentication and authorization solution to protect your APIs and simplify your app deployment.
    What Is oAuth2.0?
    oAuth2.0 provides an interoperable framework to convey authorization information. It uses short-lived tokens — JSON Web Tokens (JWT) or opaque tokens — with limited rights as a means to provide delegated access control.
    A valid token indicates that the client (user) has been authenticated and any requested permissions (claims) are present in the token, the permissions may be used for authorization policy decisions. Clients include the token in the requests using the Authorization header with “Bearer” type, like this:
    "Authorization: Bearer &lt;token&gt;" Other commonly used authentication methods like basic authentication and API keys are less secure because of the risk of exposure of credentials (username, password or API keys); mutual TLS, often used in service-to-service scenarios, is more complex to deploy. oAuth2.0 provides a more robust and scalable solution by decoupling authentication and authorization. It eliminates issues around credential sharing by giving users more control over their data; supports a variety of devices; and is extensible and can be developed upon.
    Citrix API Gateway: Authentication and Authorization
    NetScaler ADC is the foundation of the NetScaler API gateway solution and serves as the data plane (run-time proxy), with NetScaler Application Delivery Management (ADM) serving as the management plane. (You can use Kubernetes as the controller in a cloud-native environment.)
    NetScaler ADC provides comprehensive authentication and authorization features and supports various authentication protocols, including oAuth2.0. You can create authentication and authorization policies for fine-grain access control to your apps’ web and API resources.
    With the NetScaler API gateway solution, you don’t have to deal with implementing different authentication protocols for your app. It’s deployed in front of your app and handles authentication and authorization.
     

     
    A Traditional HMC Deployment
    NetScaler ADM service provides the control/management plane for the API gateway solution in on-prem and cloud deployments. You can carry out your configuration workflows using the intuitive UI or with APIs.
    To configure an oAuth policy to validate JWT tokens using the Citrix ADM UI, first navigate to Applications → API Gateway → Policy.
    Create a policy by selecting a deployment and upstream. Choose the ‘oAuth’ policy type and enter your details, as shown below.
     

     
    The JWKS URI is the URL where you’ll find the signature “keys” for the token issuer; these are fetched and used to validate tokens. The Issuer and Audience should match the values present in the token.
    NetScaler ADC can enhance your security posture because it supports the best practices for JWT validation outlined in RFC8725, including validation of issuer and audience. You can also limit the signature algorithms to asymmetric variants.
    If your use case requires you to validate “opaque” tokens, the introspection URL needs to be configured along the with client ID and secret. The URL is used to reach out to the authorization server for token validation. The API gateway uses the client ID and secret to identify itself with the authorization server.
    Please note, Citrix ADC uses a positive security model, so when you configure an auth policy for some API resources, you’ll configure the “No Auth” policy for the remaining API resources to skip authentication. Otherwise, access will be denied with a 401 error message.
    NetScaler ADC supports authorization policies, too. If you want to verify access privileges to a resource, you generally check the claims associated with the token using authorization policies. The policies can verify whether the required claims are present in the token received with an API request.
    In the NetScaler ADM service, navigate to Applications → API Gateway → Policy.
    Create the policy by selecting a deployment and upstream. Choose the “Authorization” policy type and enter the required claims and values expected for the selected resource endpoints. You should save any claims that you want to use here as part of your authentication configuration.
    Please note, if the API resources have authentication policies, you’ll need to create authorization policies also for those API resources. Otherwise, you’ll get a 403 error message. If you do not need authorization checks, you can create an authorization policy with empty claims.
    Deploying in Kubernetes Environment
    Apps are usually deployed as microservices in a Kubernetes environment. The configuration is applied using the Kubernetes APIs or a command line utility like ‘kubectl’ and config files. NetScaler ADC provides custom resource definitions (CRDs) for an app-specific configuration.
    Authentication and authorization policies are configured using the Auth CRD, which comes with the Citrix Ingress Controller. Typically, users apply the CRD spec, create one or more instances with values required to configure the desired authentication and authorization policies, then apply those. The following yaml file shows the use of the oAuth JWT token validation setup:
     

     
    If you save the config as auth-example.yaml file and you already have a Citrix Ingress Controller running in your cluster, you can take these steps to create the auth policies:
    # kubectl create -f auth-crd.yaml customresourcedefinition.apiextensions.k8s.io/authpolicies.citrix.com created # kubectl create -f auth-example.yaml Analytics and Observability
    NetScaler ADM has a breadth of analytics features to support observability, performance, and security monitoring. For authentication, it provides the number of authentication requests, successes, and failures, as well as the reason for failures both at the API level and for each resource individually.
     

     
    NetScaler ADC is also integrated with open-source tools like elastic search, Kibana, Prometheus, and Grafana, and you can use these to build custom reports.
     

     
    Conclusion
    There are several methods for API authentication and authorization, but oAuth2.0 is the most popular, scalable and secure. NetScaler's API gateway supports oAuth2.0 in traditional on-prem and cloud deployments, as well as in Kubernetes deployments.
    Learn more about API gateway policy creation using NetScaler ADM service and the Citrix Ingress Controller Auth CRD.
    Click Down
    Isha Khurana
    March 10, 2021
    Author: Jeff Qiu   NetScaler has offered Nitro API support for NetScaler ADC for many years, and you can find a lot of great resources online that cover how to use Nitro APIs to control NetScaler ADCs the REST API way.
    But what about the average IT guy without much web development experience (like me)? It can be tough. I spent a little bit of time playing with it and wanted to share this blog post to provide some easy-to-follow steps that will help any infrastructure admin (with some experience in C#) automate the configuration of NetScaler ADC and implement customized tools with complex logic flows.
    Part 1: Set Up Your Environment
    First, read the online documentation before you get started. Then, go to the web console of your NetScaler ADC, where you’ll find the download link to the C# SDK on the Downloads page, as shown below.
    /applications/core/interface/js/spacer.png" data-src="/monthly_2022_12/image.jpg.6d668ed6856c3aad44094408a8632f4a.jpg" data-ratio="71.64" width="737" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
    SDK download page You can also download the SDK from your NetScaler ADC from the following folder, via a tool such as WinSCP:
    ./var/netscaler/gui/nitro-csharp.tgz
    Download the file and extract it. Guess what’s in the nitro-csharp.tgz file? Another ns_nitro-csharp_<codename>_XX_XX.tar file! Extract that file again. You will get the C# SDK folder, as shown below.

    /applications/core/interface/js/spacer.png" data-src="/monthly_2022_12/image.jpg.468fbefba9c1992ded67ce7c0170ae0f.jpg" data-ratio="24.86" width="1050" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
    Start your adventure with the readme_start.txt file, which will explain the folder structure. In the doc folder, you will find a help file that contains the API reference. You need to have (at least) .NET 3.5 installed on your machine to use Csharp SDK.
    Please note, you will need to reference two DLLs in the lib folder (Nitro.dll and Newtonsoft.Json.dll) to build the sample code. A build command will look something like this:
    csc /r:../lib/nitro.dll;../lib/Newtonsoft.Json.dll MyFirstNitroApplication.cs
    If you have access to and are familiar with Microsoft Visual Studio, you can also reference those two DLLs from the menu Project → Add Reference → Browse.
    If you can successfully build the sample code into a .exe file, you are good to move forward.
    Part 2: Your First Nitro Application in C#
    Open MyFirstNitroApplication.cs to go through the very first sample code. At the start of the program, it creates a new instance of itself and tries to read three parameters.
    MyFirstNitroApplication config = new MyFirstNitroApplication(); config.ip = args[0]; config.username = args[1]; config.password = args[2]; After the build, the usage will look as follows:
    MyFirstNitroApplication.exe <NS_IP> <username> <password>
    Then, followed by a big try-catch from lines 45 to 88, it begins the configuration. Let’s take a segment out and have a closer look:
    //Create an instance of the virtual server class lbvserver new_lbvserver_obj = new lbvserver(); //Create a new virtual server new_lbvserver_obj.name = "MyFirstLbVServer"; new_lbvserver_obj.ipv46 = "10.102.29.88"; new_lbvserver_obj.servicetype = "HTTP"; new_lbvserver_obj.port = 80; new_lbvserver_obj.lbmethod = "ROUNDROBIN"; lbvserver.add(ns_session,new_lbvserver_obj); The code will typically start with a new object based on a certain object class. In this case, it is a lbvserver type of object. You might need to initialize some of the properties before you call the add method to create the real vServer. As shown in the example above, it will initialize the attributes needed for a load-balancing vServer object and then call the lbvserver.add() method to create the object in the session we created using the NSIP and login credentials. Proper error handling is always recommended.
    You can find examples of how to create objects and change configurations in the Sample folder. Use the structure of the very first program and rewrite everything between lines 53 and 75 with your own code.
    Here, I’ve created a real-world example of how to use Nitro API in C# to find out unbound/orphan objects in a production NetScaler ADC instance. Enjoy coding!
    Wrapping Up
    Thanks for reading, and I hope this helps you get ready to use Nitro APIs in C# for NetScaler ADC automation. Automation using a language you know, like C# in my case, is really useful when managing a NetScaler ADC! As always, if you’re looking for assistance implementing any of the code in this blog, contact our NetScaler Consulting team.
    DISCLAIMER:
    This sample code is provided to you “as is” with no representations, warranties or conditions of any kind. You may use and distribute it at your own risk. CITRIX DISCLAIMS ALL WARRANTIES WHATSOEVER, EXPRESS, IMPLIED, WRITTEN, ORAL OR STATUTORY, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT. Without limiting the generality of the foregoing, you acknowledge and agree that (a) the software application may exhibit errors, design flaws or other problems, possibly resulting in loss of data or damage to property; (b) it may not be possible to make the software application fully functional; and (c) Citrix may, without notice or liability to you, cease to make available the current version and/or any future versions of the software application. In no event should the code be used to support of ultra-hazardous activities, including but not limited to life support or blasting activities. NEITHER CITRIX NOR ITS AFFILIATES OR AGENTS WILL BE LIABLE, UNDER BREACH OF CONTRACT OR ANY OTHER THEORY OF LIABILITY, FOR ANY DAMAGES WHATSOEVER ARISING FROM USE OF THE SOFTWARE APPLICATION, INCLUDING WITHOUT LIMITATION DIRECT, SPECIAL, INCIDENTAL, PUNITIVE, CONSEQUENTIAL OR OTHER DAMAGES, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. You agree to indemnify and defend Citrix against any and all claims arising from your use, modification or distribution of the code.
    Isha Khurana
    Introduction
    Enterprises continue to migrate their web apps and APIs to the Cloud to better support work from home employees, fueled by the pandemic. At the same time, they still support business-critical web apps hosted On-Premises or in Private Clouds. Along with the growth in these internet-facing services, there has been growth in internet-borne threats.
    Bad actors continue to develop new ways to compromise them to support their illicit activities. Protecting applications from attack requires rapid identification of threats and launching of countermeasures. Citrix Web App and API Protection (CWAAP) service provides a consistent security posture and comprehensive protection for Monolithic applications On-Premises or microservices in the Cloud.
    Overview
    CWAAP service guards against their attempts to exfiltrate, manipulate or destroy online Enterprise web apps, APIs and data. It includes a comprehensive suite of technology to mitigate the risk to business-critical operations.
    Web Application Firewall - short for web application firewall, “WAF” origins are in protecting web sites hosted on-premises. However, in the Cloud Era the scope of WAFs are expanded to hybrid cloud or public cloud environments with broader attack surfaces to protect. Protection also extends to APIs used by Cloud-native systems to communicate between distributed functions that operate independently in containers. Also know as microservices, this form of development is more efficient in many ways than traditional monolithic architecture, yet by nature is primarily hosted in the Cloud, and subsequently, APIs are vulnerable to attack. DDOS Protection - Distributed Denial of Service (DDOS) Protection guards against internet-born attacks that seek to disrupt access to cloud services. Typically initiated by bad actors through BOT armies, DDOS attacks focus on consuming available resources to the point customer access is disrupted or denied.
    WAF Protection
    Hosted in the Cloud or on Premises Citrix WAF protects against known and unknown attacks, including application-layer and zero-day threats. It includes protections against Top 10 Web Application security risks, defined by the OWASP Foundation, at its core and expands on those with ever-growing security definitions and countermeasures from multiple threat research sources.
    Large enterprises may have hundreds or thousands of applications online that need to be secured. Therefore matching attacks, against unique web app flows to different applications at scale is a challenge. Citrix WAF automates Protection against internet-borne attacks keeping traffic at the Cloud or On-Premises edge. It detects and mitigates incessant online threats around the clock. This allows Security operations to focus more on strategic security activities and address vulnerabilities elsewhere in the infrastructure.
    Citrix WAF works on both a positive and negative attack model. The positive model identifies zero-day threats by looking for abnormal activity patterns. The negative model identifies previously documented attack signatures.
    Negative Security Model
    Injection flaws, such as SQL and LDAP injection, have been a perennial favorite among hackers, along with Cross-site scripting attacks. Other web attack protections include:
    Core
    HTML SQL Injection - provides defenses against injection of unauthorized SQL code that might break security. HTML Cross-Site Scripting - examines both the headers and the POST bodies of user requests for possible cross-site scripting attacks. Cross-Site Request Forgery (CSRF) Form Tagging - tags each web form sent by a protected website to users with a unique and unpredictable FormID and then examines the web forms returned by users to ensure that the supplied FormID is correct. Buffer Overflow Check - detects attempts to cause a buffer overflow such as URLs, cookies, or headers that are longer than the configured length. Advanced
    Cookie Consistency - examines cookies returned by users to verify that they match the cookies that the protected website set for that user. If a modified cookie is found, it is stripped from the request before the request is forwarded to the webserver. Field Consistency - examines the web forms returned by users in response to HTML requests and verifies that unauthorized changes to the structure were not made. Field Format - verifies the data that users send, including the length and type. Content-Type - ensures the Content-Type headers are either“application/x-www-form-urlencoded”, “multipart/form-data,” or “text/x-gwt-rpc”types. Any request that has any other content type designated is blocked. HTTP RFC - inspects the incoming traffic for HTTP RFC protocol compliance and drops any request with RFC violations. Deny URL - examines and blocks connections to URLs commonly accessed by hackers and malicious code. POST Body Limit - Limits the request payload (in bytes) inspected for signatures. XML
    XML SQL Injection - examines and blocks user requests with injected SQL in XML payloads. XML XSS - examines and blocks user requests with cross-site scripting attacks in XML payloads. XML Format - examines and blocks incoming requests that are not well-formed or that do not meet the specification for properly-formed XML documents. XML SOAP Fault - examines responses from your protected web services and filters out XML SOAP faults. This prevents the leaking of sensitive information to attackers. Web Service Interoperability - examines and blocks requests and responses that do not adhere to the WS-I standard and might not interact with XML application appropriately. Positive Security Model
    Citrix WAF supports a positive protection model with learning rules that build on the negative model by creating a profile of allowed traffic. Advanced heuristics analyze traffic to identify standard behavior and make recommendations for tuning of countermeasures. This helps ensure Protection against zero-day attacks that are not addressed in existing signatures.
    DDOS Management
    DDOS attacks focus on disruption through resource consumption. There are three main groups of DDOS attacks:
    Volume-based attacks - attempt to disrupt regular service by overwhelming sites with a flood of traffic. These include UDP or ICMP floods that try to exceed available bandwidth, denying legitimate user requests from ever reaching the target site. Protocol-based attacks - focus on the transport layer and take advantage of protocol operations. Packets are typically “spoofed” or sent with fake IP header information to illicit a response to consuming site resources. A typical example is a “SYN” attack. With this type of attack, the bad actor’s host, or a BOT, sends a request to establish a TCP layer session. A TCP session is ultimately required for legitimate users to establish an HTTP session to use the web service. However, the initiating host never responds to the site’s SYN ACK yet sends more SYNs, steadily consuming memory on the web service as it waits to establish TCP sessions. Application layer attacks - these attacks focus on the application layer and seek to overcome resources or take advantage of web server vulnerabilities. The attacks try to illicit, excessive site responses by manipulating protocol communication with crafted GETs or POSTs. The Citrix DDoS solution provides a holistic solution to DDOS protection buyers. It is an always-on DDoS attack management service. It features one of the world’s largest scrubbing networks with 14 POPs and 12 Tbps capacity that protects applications from large-scale volumetric DDoS attacks.
    Management
    CWAAP is configured and managed through a flexible SaaS portal. The CWAAP service portal, accessible through a browser, enables security admins to configure attack protections, monitor attack activity through a dashboard, or report on events.
    Setup
    CWAAP is setup with the help of Citrix using one of two methods:
    DNS - using DNS is the most common and easiest method. Customers direct their site A records to a Citrix CWAAP domain setup for their site. With this method, customers maintain control and can schedule a quick transition using a low TTL setting for the record. BGP - using BGP requires customers to transfer control of their pertinent routing block to Citrix. Then Citrix announces the route on behalf of the customer, and traffic to target sites without the block is directed to the CWAAP for inspection. Configuration
    CWAAP WAF policies and custom rules are configurable through the SaaS portal:
    WAF Policies - there are three primary sets of policies, and when detected, administrators can configure them to block, log, or both. Core policies are the most common types of attacks, including SQL injection, cross-site scripting, and buffer overflow. Advanced are more complex attacks using cookies or trying to take advantage of the HTTP protocol, while the last group pertains to XML-specific attacks. Signatures to identify the attacks are continuously developed by a Citrix research team and are updated automatically when published. Responder Policies - admins may configure custom rules to drop, log, or redirect connections based on specific parameters such as the hostname, source IP address, or destination port. Network Controls - admins may configure ACLs to block specific IP address ranges or traffic from specific countries. Alerts - admins may configure custom alerts when the amount of traffic within a certain interval is exceeded from a specific parameter such as the same ASN, country, or User-Agent. Trusted Sources - admins may configure an allow list of trusted sources that bypass inspection policies. Assets - admins configure the target site or sites these configured policies should apply to.
    Monitoring
    The CWAAP Portal gives Citrix admins the ability to monitor CWAAP Protections centrally. The main dashboard provides an aggregate view of site volume, including total traffic, broken down by clean traffic and mitigated traffic.
    It also includes a detailed log of attacks, including volume, duration, and countermeasures deployed.

    Summary
    Enterprises’ use of cloud services and mobile applications continues to drive the growth of cloud-native web and API traffic while maintaining some business-critical web apps On-Premises. With this growth in apps and APIs online, they are increasingly vulnerable to the persistent attacks that come with being hosted on the public internet. Citrix Web App and API Security service is constantly evolving to stay ahead of these complex attacks. It includes an advanced suite of technology based on Machine Learning and Artificial Intelligence to protect these critical Enterprise services in the Cloud and On-Premises.
    References
    Learn more at Citrix® Web App and API Protection™
    Akhil Nair
    Pre-Requisite: Customers should have a Premium NetScaler License and ADM Service to enable API Gateway
    The rise of API-driven software has seen a corresponding rise in API-related security attacks. In the last few years, the industry has seen an increase in data breaches across companies of all shapes and sizes. Notable enterprises such as Venmo, Experian, and Peloton among others have all been victims of API attacks and data breaches. This has led to the exposure of millions of personally identifiable information (PII) records of their customers, costing millions in damages and fines.
    As organizations are realizing the critical need for effective API security in their overall security posture, Citrix API Gateway is one solution that’s ready to solve the challenge. 3 simple steps can enable organizations to protect their APIs by deploying them behind the Citrix API Gateway. They are as follows:
    Onboarding the API Deploying the API Enabling Policies Onboarding the API
    To onboard your API to the Citrix API Gateway, the first step is uploading the API specification. An API specification is a high-level blueprint of how your API works structurally. Although sometimes development teams may overlook creating an API specification, it is an incredibly important step in the end to have secure applications.
    The OpenAPI Specification (OAS), previously known as Swagger, is one such standard interface for RESTful API specifications, allowing APIs to be discovered and understood by both computers and humans. An OAS specification is represented as an object in a JSON or YAML file. No need to worry if you don’t have your API spec already created. You can create one manually inside the Citrix API Gateway.
    To begin, navigate to your instance of Citrix ADM and login. Once there, follow these steps.
    Go to the sidebar and click Security >> API Gateway >> API Definitions Click Add and either upload your OAS API specification file (if you have one) OR select Create Your Definition to create one manually Now that you’ve added your API spec, it’s time to deploy your API to the gateway.
    Deploying the API
    Go to the sidebar and click Security >> API Gateway >> Deployments Click Add and fill out the details under the Deployment Basic Info Give your deployment a name and select the target API gateway (NetScaler) from the drop-down menu. Select the relevant API definition and fill out details around IP address, port, certification, and so on Next, under Upstream Services, click Add to configure your Upstream API Services (aka your back end API service) Next, Under Routing, add routes for the API Upstream Services or back-end API services that you created. Routing for API Upstream Services adds details about API routing configuration for the API Gateway to route incoming API calls to the right back end service. Enabling Policies
    The next step in the deployment process is to create policies for the API Upstream Services or back end API services.
    Go to the sidebar and click Security >> API Gateway >> Policies Click Add. Fill out a name, select a deployment and choose the appropriate upstream service Next, click Add to create various types of policies against different API resources Some useful policies include rate-limiting, authorization, WAF, Bot, header rewrite, and deny. You can also create custom rules according to your business needs. Once complete with all policies, click Save and Apply. And that’s it. You’ve successfully onboarded your API to the Citrix API Gateway. This is one step that pays dividends in the end as your APIs and applications are now more secure. Not only this helps limit your attack surface, but it will also help you gain holistic visibility into your API ecosystem (via the API Analytics feature). This allows you to monitor API performance, discover shadow and leaky APIs, monitor endpoint activity, and gain various insights on your API deployments.
    With the added level of security, rest assured knowing that the Citrix API Gateway takes care of the tedious and keeps your applications much more secure.

©

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