|
From: Jai H. <jai...@mu...> - 2018-04-06 03:30:53
|
I hate to keep bringing this up, but I still don't see how my problem can
be addressed.
I will rephrase my question in the form of an example:
StartLine is received: Post /Post HTTP/1.1
-> Invoke ModSec->ProcessConnection() with client IP which is available at
this time to my application.
For a request that is forwarded, this client IP will identify the load
balancer, and not the true client.
-> Invoke ModSec to parse the start line.
Header is received: host: localhost
-> Invoke ModSec to parse header.
Header is received: X-Forwarded-For: 172.23.116.55
-> What should be done?
Should I re-invoke ModSec->ProcessConnection() with this true client
IP = 172.23.116.55?
Is there an alternative way to inform ModSec of this is the true
client IP?
Should I delay the call to ModSec->ProcessConnection() until all
headers are parsed and then call it with either
the original client IP or an XFF IP if one was received?
Any other options? None of the above seem like good ones.
Seems like this should be a typical scenario that already has a solution.
On Thu, Mar 8, 2018 at 8:42 AM, Jai Harpalani <jai...@mu...>
wrote:
> Sounds like it is a good idea to always call ProcessConnection(). If this
> is the case, then I'm still confused on how I can do this for the XFF case.
> My application has ModSec built into it. So, if I want to call
> ProcessConnection() from my application, I believe I must:
>
> 1 - Invoke it early in the transaction phase (before processing request
> headers, body, etc).
> 2 - Pass it serverIP/serverPort which identifies my application that has
> ModSec built into it.
> 3 - Pass it clientIP/clientPort which identifies the client making the
> request.
>
> For #3, an earlier email stated:
>
> In that case, it is safe to use the ip that initiated the request (tcp
> request). That is the same scenario as having ModSecurity behind a reverse
> proxy of some sort.
>
> For XFF requests, the ip that initiated the request will not accurately
> identify the client. Instead, it may identify a load balancer or similar
> entity which is in front of my application. If this ip is used to identify
> the client, it is not accurate, and all rules will be operating against a
> load balancer or similar entity rather than the true client.
>
>
>
> On Thu, Mar 8, 2018 at 8:03 AM, Felipe Costa <FC...@tr...> wrote:
>
>> Hi Jai,
>>
>>
>>
>> That is an assumption that may be true on a given time frame. The library
>> can do something else in a near future and it will assume that this method
>> is being called from whomever is consume it. That is one of the reasons
>> that calling this method is important.
>>
>>
>>
>> Br.,
>>
>> *Felipe “Zimmerle” Costa*
>>
>> Security Researcher, Lead Developer ModSecurity.
>>
>>
>>
>> *Trustwave* | SMART SECURITY ON DEMAND
>>
>> *www.trustwave.com <http://www.trustwave.com/>*
>>
>>
>>
>> *From: *Jai Harpalani <jai...@mu...>
>> *Date: *Thursday, March 8, 2018 at 1:53 AM
>> *To: *Felipe Costa <FC...@tr...>
>> *Cc: *Robert Paprocki <rpa...@fe...>, "
>> mod...@li..." <
>> mod...@li...>
>> *Subject: *Re: [Mod-security-developers] Question regarding
>> transaction::processConnection()
>>
>>
>>
>> Searching through the CRS rules, I see that real_ip is used for DOS and
>> IP_REPUTATION rules. I am excluding those rules for my specific
>> application. Due to these exclusions, it seems like the call to
>> ProcessConnection() is required only to set the uniqueID. Is this an
>> accurate statement?
>>
>>
>>
>> (…)
>>
>
>
|
