Jump to content
Welcome to our new Citrix community!

Conversion of F5-iRule to Netscaler Policy


Sudhir Bhagat

Recommended Posts

Hi All, 

 

Requesting help to convert below 02 x F5-iRule to Netscaler Policy.

 

1) 

 

when CLIENT_ACCEPTED {
    # initialize TLS/SSL handshake count for this connection
    set sslhandshakecount 0
}
when CLIENTSSL_HANDSHAKE priority 1 {
    # a handshake just occurred
    incr sslhandshakecount
    # is this the first handshake in this connection?
    if { $sslhandshakecount > 1 } {
        # log (rate limited) the event (to /var/log/asm)
        log "\[VS [IP::local_addr]:[TCP::local_port] client [IP::remote_addr]:[TCP::remote_port]\]:TLS/SSL renegotiation"
        # if not, close the clientside connection
        reject
    }
}

 

++++++++++++++++++++++++++++++++++++++++++++

 

2) 

 

when RULE_INIT {
    array set static::webservers {
        1   10.10.10.1
        2   10.10.10.2
    }
}

when CLIENT_ACCEPTED { 
    set default_pool [LB::server pool]
}

when HTTP_REQUEST {
    set target_member [HTTP::header X-silo-number]
    if {!($target_member eq "") && [info exists static::webservers($target_member)]} {
        pool $default_pool member $static::webservers($target_member)
    }
}

 

 

Link to comment
Share on other sites

1) Your First irule appears to be about SSL Renegotiation and allowing if the client does it once and logging; but denying the rest of the time(?)

There's not an exact equivalent on the ADC. When you create an SSL vserver (LB/CS etc) you can use the SSL Profile to set the parameters of that vserver including setting the Deny SSL Renegotiation setting:  https://support.citrix.com/article/CTX123680/configure-denysslreneg-parameter-to-disable-client-side-and-server-side-ssl-renegotiation-on-adc.

You can also adjust session reuse settings:  https://support.citrix.com/article/CTX121925/ssl-renegotiation-process-and-session-reuse-on-adc-appliance

 

IF its just to log the renegotiation event, a responder policy set to noop (or reset/drop if you are terminating connection) with an expression such as client.ssl.client_hello.is_renegotiate plus a logging action MIGHT do this. BUT not based on exceeding a count and not if the parameter is denying renegotiations anyway.  

If you just want to prevent renegotiations, set the SSL profile.  

 

I would want to clarify exactly what your rule is doing and why and maybe there's just an alternate approach to solve the same problem.

(If anyone else, has a better idea; feel free to correct me.)

 

Update:  I saw Carl responded before I could post, while rate limiting might help with connections exceeding a number of connections; I'm not sure if it can filter specifically based on the renegotiate behavior.  But its worth looking into with the link Carl provided. 

 

2) Your second irule appears to make a load balancing decision to a backend server (what we call a service) based on if a specific header ("x-silo-number") contains an ID that matches a value assigned to service destination.  If this is a value that the server sets in the header during a prior transaction and you want the lb to look for the header to override a load balancing decision, we do this by setting service "server id".  Can also be set on members in a servicegroup.  (In Gui, this is under the basic service properties.)

 

Create your two service(s) reprepsenting your backend servers you are load balancing too. Custom server ID should be a static value (string, number, whatever) that is inserted into the responses with the header indicated for future load balancing."  So the "Custom Server ID" can be set to whatever the app is using to identify each backend.

add service svc_1 10.10.10.1 http 80 -CustomServerID 1                          

add service svc_1 10.10.10.2 http 80 -CustomServerID 2                          

 

On the lb vserver, use your regular load balancing method and CustomerServerID persistence with expression would likely be:   http.req.header("X-silo-number")

If not token load balancing and rule-based persistence might be needed.  https://docs.citrix.com/en-us/citrix-adc/current-release/load-balancing/load-balancing-persistence/custom-server-id-persistence.html

 

 

 

Link to comment
Share on other sites

So, first option is if the app is inserting an identifier based on which server serves the response, then you set the custom server id on the service to match that value. The load balancing method then matches to that id; if none present, it does normal load balancing.

 

If the value is a unique value in a request header set per client and therefore not tied to a specific ID on the backend, then use the rule load balancing and token load balancing based on http.req.header("x-silo-number") or whatever the header name and requests with a particular value will be hash load balanced where previous requests will return to previous servers. When no header is present, it will load balance normally. 

 

So, check with the app team for what determines that value.

Link to comment
Share on other sites

Hi Rhonda, 

 

Thanks for reply.

 

for iRule-1 (which looks to be for SSL re-negotiation) ....the links shared by You.

 

1) https://support.citrix.com/article/CTX123680/configure-denysslreneg-parameter-to-disable-client-side-and-server-side-ssl-renegotiation-on-adc   referring to the SSL settings on ADC global level.

 

2) https://support.citrix.com/article/CTX121925/ssl-renegotiation-process-and-session-reuse-on-adc-appliance   doesn't contains the full details of the configuration. 

 

In Our case :

 

when CLIENT_ACCEPTED {
    # initialize TLS/SSL handshake count for this connection
    set sslhandshakecount 0
}
when CLIENTSSL_HANDSHAKE priority 1 {
    # a handshake just occurred
    incr sslhandshakecount
    # is this the first handshake in this connection?
    if { $sslhandshakecount > 1 } {
        # log (rate limited) the event (to /var/log/asm)
        log "\[VS [IP::local_addr]:[TCP::local_port] client [IP::remote_addr]:[TCP::remote_port]\]:TLS/SSL renegotiation"
        # if not, close the clientside connection
        reject
    }
}

 

There is condition for SSL Handshake count and Increment condition as well along with some logging condition.

 

Requesting If you help me to understand this irule.

 

Link to comment
Share on other sites

It looks like a rule to block an ssl renegotiation attempt, but logging it too.  However, the rule allows 1 renegotiation; just not more than one.

 

If you use the SSL Parameters, you can just block any ssl renegotiation attempt. If you want to log the attempt, you have to allow ssl renegotiations and then possibly use a rate limit to the then drop after it exceeds a certain count, which seems very, very odd to me.

 

Rule basically:

when client_accepted >> meaning when ssl connection occurs, set sslhandshakecount to 0 (clears value).

when clientssl_handshake {  >>>meaning when an ssl handshake is requested

    increment handshakecount +1  >>> so now, the count is 1 higher than previous; making this first handshake #1

   If handshake is >1 LOG and close connection

   Else handshake is 1 >>> allow content and one handshake is permitted.

 

Beyond that...I don't know *why* you would want to do this, this way.

 

A ratelimit that exceeds connection 1 in a certain time frame when combined with ssl.is_renegotiation filter MIGHT work.  But I can't say there won't be a security risk.

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...