Re: monitoring proxied web traffic

Thank You Michał

Client to Proxy would not be encrypted. So based on that I will have all
the logs, however my destination IP for proxied connections would be proxy
IP (that was my understanding). I guess ingesting proxy logs would then
provide full visibility as you mentioned. I am thinking maybe if for some
reason I cannot get the proxy logs ingested and also tap after the proxy, I
could possibly correlate both ends of the connections based on URI/SNI/etc
and same timestamps in my analytics platform. Anyways I will give that a
try as well. Thanks for your help again.

Konrad



On Wed, Nov 6, 2019 at 6:59 PM Michał Purzyński <[email protected]>
wrote:

> There is no way for Zeek to really correlate if the proxy does everything
> at the application level, like Squid. The proxy
>  terminates the connection and then it's free to start the second leg, to
> the destination host, as it wishes to.
>
> Is your traffic from clients to proxy encrypted as well?
>
> If the traffic between clients are the proxy is not encrypted (as it's
> usually the case) then even if the client will establish a TLS session
> _through_ the proxy you will see a destination with the "service" field
> http,ssl and all the conn + ssl + http logs.
>
> We have that + proxy logs and that's pretty much a full visibility.
>
>
>
> On Wed, Nov 6, 2019 at 1:11 PM Konrad Weglowski <
> [email protected]> wrote:
>
>> Hello,
>>
>> I need to monitor web traffic with Zeek that is going through an implicit
>> web proxy. I would like to be able to see real client IPs in which case tap
>> would be placed before the proxy, however I will not be able to see the
>> real destination IP as it will always be proxy IP. I can also tap on the
>> other side of the proxy where source will always be proxy IP at the same
>> time.
>>
>> Is there a way with Zeek to correlate the two sessions (before and after
>> proxy) somehow?
>>
>> I realize that UID or Community ID are probably not going do it since
>> different source/destinations pairs for each for each session, but maybe
>> based on the timestamp/URI/SNI/byte or packet counts/etc?
>>
>> I was also thinking "X-Forwarded-For" header but I guess that would only
>> work for HTTP and not HTTPS connections.
>>
>> Thank You,
>>
>> Konrad
>> _______________________________________________
>> Zeek mailing list
>> [email protected]
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/zeek
>
>

_______________________________________________
Zeek mailing list
[email protected]
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/zeek