Jump to content
Welcome to our new Citrix community!

Two problems using ip-reputation feature with or without appFW


Recommended Posts

 

I want to use the IP-Reputation feature, but I ran into two problems…

 

The ip-reputation docs say: “…Enable the IP reputation and application firewall features…”
https://docs.citrix.com/en-us/netscaler/12/reputation/ip-reputation.html

 

If I activate the citrix application firewall, the response headers will be modified. (see https://support.citrix.com/article/CTX131488 / Response Headers Modified by the Application Firewall)

 

But I need the headers unmodified to ensure the correct caching in other systems like a CDN.

So I see only two solutions…

a) Find a way to use the citrix application firewall without modifying headers?

b) Maybe use the ip-reputation feature in AppExpert/Responder Policy?

 

Is there a way to prevent the headers to be modified and have the application firewall enabled?

 

I tried to use “IPREP_IS_MALICIOUS” in a Responder Policy but I get a Syntax error…
(HTTP.REQ.HEADER("X-Forwarded-For").TYPECAST_IP_ADDRESS_AT.IPREP_IS_MALICIOUS)

 

Any suggestions, hints or help?

 

 

Platform: NSMPX-8000 4*CPU+12*E1K+1*E1K+4*CVM 1620 675300

Release: NS12.1 50.28.nc

Link to comment
Share on other sites

You can use IPREP without AppFW enabled, if the feature is licensed.  You would use it with responder policies to filter traffic.  (The statement is if you are going to filter traffic before doing appfw policies, then appfw policy 1 would filer by iprep and then policy 2 would do the regular appfw signature/security protections.  AS a result, you would need both features enabled.)

 

If the traffic is being processed by AppFw then you cannot prevent the modification of these headers.  But you should be able to use IPREP filters without appfw, so I think you can avoid this issue if you don't also need AppFw protections.

Link to comment
Share on other sites

both features are enabled (see show ns features and iprep.log Snippet below). But there is no binding of a Web App Firewall Policies...

 

if i use the Expression Evaluator i get a "invalid expression" error message

image.thumb.png.7883222d7a0c0e8ff3145fb050854a85.png

 

i tried different expression to check the reason of the

HTTP.REQ.HEADER("X-Forwarded-For").TYPECAST_IP_ADDRESS_AT.IPREP_IS_MALICIOUS

HTTP.REQ.HEADER("X-Forwarded-For").REGEX_SELECT(re#\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}#).TYPECAST_IP_ADDRESS_AT.IPREP_IS_MALICIOUS

...

 

 

when i try HTTP.REQ.HEADER("X-Forwarded-For").REGEX_SELECT(re#\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}#)  --> without TYPECAST_IP_ADDRESS_AT.IPREP_IS_MALICIOUS

the expression Evaluator returne the Result as string: 17.36.62.212 so far no error

 

image.thumb.png.001d7510fe01d3dc7ecbd2c27b59d3a8.png

 

it seems the error came from "IPREP_IS_MALICIOUS" .... No errors until i add it.... but why?

 

 

 

> show ns feature

        Feature                        Acronym              Status
        -------                        -------              ------
 1)     Web Logging                    WL                   OFF
 2)     Surge Protection               SP                   OFF
 3)     Load Balancing                 LB                   ON
 4)     Content Switching              CS                   ON
 5)     Cache Redirection              CR                   OFF
 6)     Sure Connect                   SC                   OFF
 7)     Compression Control            CMP                  OFF
 8)     Priority Queuing               PQ                   OFF
 9)     SSL Offloading                 SSL                  ON
 10)    Global Server Load Balancing   GSLB                 OFF
 11)    Http DoS Protection            HDOSP                OFF
 12)    Content Filtering              CF                   OFF
 13)    Integrated Caching             IC                   OFF
 14)    SSL VPN                        SSLVPN               OFF
 15)    AAA                            AAA                  OFF
 16)    OSPF Routing                   OSPF                 OFF
 17)    RIP Routing                    RIP                  OFF
 18)    BGP Routing                    BGP                  OFF
 19)    Rewrite                        REWRITE              ON
 20)    IPv6 protocol translation      IPv6PT               OFF
 21)    Application Firewall           AppFw                ON
 22)    Responder                      RESPONDER            ON
 23)    HTML Injection                 HTMLInjection        OFF
 24)    NetScaler Push                 push                 OFF
 25)    AppFlow                        AppFlow              OFF
 26)    CloudBridge                    CloudBridge          OFF
 27)    ISIS Routing                   ISIS                 OFF
 28)    CallHome                       CH                   ON
 29)    AppQoE                         AppQoE               OFF
 30)    Content Accelerator            ContentAccelerator   OFF
 31)    RISE                           RISE                 OFF
 32)    Front End Optimization         FEO                  OFF
 33)    Large Scale NAT                LSN                  OFF
 34)    RDP Proxy                      RDPProxy             OFF
 35)    Reputation                     Rep                  ON
 36)    URL Filtering                  URLFiltering         OFF
 37)    Video Optimization             VideoOptimization    OFF
 38)    Forward Proxy                  ForwardProxy         OFF
 39)    SSL Interception               SSLInterception      OFF
 40)    Adaptive TCP                   AdaptiveTCP          OFF
 41)    Connection Quality Analytics   CQA                  OFF
 42)    ContentInspection              CI                   OFF

 

iprep.log

Dec  5 16:10:00 <local2.info> ns iprep: iprep process started...
Dec  5 16:10:00 <local2.info> ns iprep: iprep_get_schema_version:134 current schema version:1.1
Dec  5 16:10:00 <local2.info> ns iprep: IPREP update versions: major version:1 minor version:2368 update version:95 total ips:946263 last update time:1575558300
...
Dec  5 16:10:01 <local2.info> ns iprep: iprep process exiting with error code:0

 

Link to comment
Share on other sites

2 hours ago, Matthias Schumacher1709157051 said:

when i try HTTP.REQ.HEADER("X-Forwarded-For").REGEX_SELECT(re#\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}#)  --> without TYPECAST_IP_ADDRESS_AT.IPREP_IS_MALICIOUS

the expression Evaluator returne the Result as string: 17.36.62.212 so far no error

 

 

I see you're testing in the evaluator.  Have you tested this policy on an actual request (test NS) outside of the evaluator.

The reason why I ask is that still on 12.1 I've seen the evaluator mis-apply regex expressions and throw false errors that the actual policy engine on live traffic would handle.  So the error is an evaluator error.  These complex expressions don't always work on the evaulator screen.

 

If you try with just the typecast value, you will see the evaluator kind of chokes on the output..so its the typecast failing in the evaulator and not necessarily the iprep expression.  This might just be an evaluator issue and I would test on traffic in a test scenario if you can to see if actually works or not.   (I did a limited test in lab just on a host header conversion to ip address and not the regex method and it seemed to allow typecast and the iprep expression.)

 

I haven't had a chance to vet the regex completely, but I think it should work.

 

 

 

 

 

 

 

Link to comment
Share on other sites

There is a bit of misunderstanding. IP reputation is licensed like - and together with - the WAF. But it is not the WAF, it is not part of the WAF. And it does not change any headers.

 

I explained why WAF changes headers and it totally makes sense to me. But IP reputation is just a lookup of IP addresses in a (locally cached) database. I digged a little bit into the feature. Maybe you want to read this?

 

So the feature itself will only download and update the database. You may use any policy (responder, WAF, ...) together with IP reputation.

 

I usually don't use threat categories as I found out, malicious clients tend to change threat categories quite often, but instead just ISMALICIOUS to drop the TCP connection.

 

I did not understand which kind of problem you have about changed headers. Are your concerns on request or response side?

Link to comment
Share on other sites

thanks all of you. I will try out all suggestions you have made and reported (hopefully) success

 

2 hours ago, Johannes Norz said:

I did not understand which kind of problem you have about changed headers. Are your concerns on request or response side?

 

the problem with that is the delete of last modified header. Some searchengines first look via HEAD request if the site has changed.
Next is the overwrite of Cache-control max-age and the modification of Expires Header. 
Akamai CDN Option --> "Honor Origin: You can choose to set content through honoring origin Cache-Control response headers, Expires response headers..."
So we have a dynamic control of the caching mechanism

 

Link to comment
Share on other sites

1 hour ago, Matthias Schumacher1709157051 said:

the problem with that is the delete of last modified header. Some searchengines first look via HEAD request if the site has changed.
Next is the overwrite of Cache-control max-age and the modification of Expires Header. 
Akamai CDN Option --> "Honor Origin: You can choose to set content through honoring origin Cache-Control response headers, Expires response headers..."
So we have a dynamic control of the caching mechanism

 

Ah, I totally understand your concerns. Ever tried to rewrite this header right before sending the packet to the user?

 

The WAF tries to keep caching solutions from caching. That's why it removes these headers. I linked the wrong blog article before. That's the one I wanted to referre too.

Link to comment
Share on other sites

6 minutes ago, Johannes Norz said:

Ah, I totally understand your concerns. Ever tried to rewrite this header right before sending the packet to the user?

 

No not yet. because I would have to save the cache header information before I can send it again.
or I would have to rename the headers twice, once before WAF and once after.
I have avoided this way so far i don't want to cause any unnecessary load (only one fear, not confirmed)

I would not immediately know how I can catch the response in front of the waf and modify it again after. Here I would probably have to study the documentation a little more. :-)

again, thank you. 

unfortunately i have some other work to do, but i will check the suggestions as soon as possible

Link to comment
Share on other sites

5 hours ago, Matthias Schumacher1709157051 said:

I would not immediately know how I can catch the response in front of the waf and modify it again after. Here I would probably have to study the documentation a little more. :-)

I don't think this would work because of the complexities in the flow and where you would have to reinsert the headers...

 

If you want to use IPREP filtering, you can without using AppFw. And then hopefully, the typecasting issue actually works unlike what the evaluator is indicating.

 

If you decide to use AppFw too, then the cache headers indicated will be removed/modified to prevent most client and intermediate caching because certain AppFw features (especially the sessionization stuff) would break.  This isn't something that can be prevented so if the cache headers you need are the ones modified by the AppFw you probably couldn't use the appfw feature.   

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...