Wireshark · Wireshark-users: Re: [Wireshark-users] how can I filter on traffic that is (a) going in/out through the company inter

[Martin Visser <martinvisser99@xxxxxxxxx>]

Or there is a risk someone has hardcoded the address in a hosts file (or even if your .pac file doesn't use names but IP addresses).

There is always a lot of assumptions.

I'm not sure of your situation but you also might find it more convenient to capture topologically closer to the proxy servers, say port-mirroring off of the switch you connect to.

I guess the other question is that you are going to a lot of effort to isolate just the proxy traffic out. You haven't really articulated why you are doing this - it could be that wireshark is not really the best tool. In fact all proxy servers that I know of have a very comprehensive logging capability - recording URLs and clients. You may find that this will give you what you want in a much more digestible form.

Regards, Martin

MartinVisser99@xxxxxxxxx

On Tue, Aug 17, 2010 at 7:17 AM, Greg Hauptmann <greg.hauptmann.ruby@xxxxxxxxx> wrote:

PS. Just adding to my question below: Would there be any issues
sniffing for the DNS call in terms of an assumption this call would
always transit from the PC running the sniffing tool to a separate DNS
server?  In particular I thought I recalled that Windows has it's own
DNS cache/service locally?  So if I'm correct here, is there a risk
that the actual DNS lookup would occur internally on the windows
server & therefore wireshark wouldn't actually capture this call?  And
then if I'm correct here, :), then how could I work around this?
[phew]

On 17 August 2010 07:07, Greg Hauptmann <greg.hauptmann.ruby@xxxxxxxxx> wrote:
> @Kevin - thanks - I'll look into your suggestion, however I'm not sure
> that one could rely on all browser proxies setting being configured
> this way - like many may just be setup manually by a user, in which
> case it wouldn't go through this process - let me know if I've
> misunderstood however
>
> @Sake - good idea - it would probably fall down for other reasons
> however such as non-HTTP traffic passing through proxy I'm guessing.
> Also I wonder if it would handle HTTPS too?
>
> What about this idea - Capture all traffic for a period and then
> programmatically parse through it looking for DNS calls to the main
> proxy server, in which case for each hit capture the IP address (which
> should be for the specific proxy server handed out) and keep in an
> array.  Then loop through all packets captured looking for traffic
> to/from this IP address and the local PC.  Would this work in
> principle?   Only thing would be I assume it implies you would need to
> do off-line, as I'm not sure if there would be a way to do this in
> real time using Wireshark?
>
>
>
> On 17 August 2010 04:44, Sake Blok <sake@xxxxxxxxxx> wrote:
>> On 16 aug 2010, at 13:21, Greg Hauptmann wrote:
>>
>>>  Would it be
>>> possible in fact on review of the packets captured to identify which
>>> traffic relates back to use of an internet proxy that was handed out
>>> by DNS versus any other internal traffic that is going on?   I mean,
>>> if you didn't know what the alias names were for the proxy servers
>>> (i.e. you didn't that know that proxy3.zzz.aaa.mycompany.com was a
>>> proxy server) would there be a way using the packet content of this
>>> packet to tell for sure whether it is proxy traffic or not?
>>
>> Proxied HTTP requests are different from normal HTTP requests in that the request URI starts with "http://<host>/" while a non-proxied request will start straight away with the requested object (ie "/index.html" for example).
>>
>> That can be used in a display filter by using something like:
>>
>> http.request.uri contains "http://"
>>
>> If you want to build a capture filter for this, you can use something like:
>>
>> tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420 and tcp[(((tcp[12:1] & 0xf0) >> 2) + 4):4] = 0x68747470 and tcp[(((tcp[12:1] & 0xf0) >> 2) + 8):4] & 0xffffff00 = 0x3a2f2f00
>>
>> (that would capture all TCP packets in which the first 11 octets form the string "GET http://", if you also want to capture HEAD and POST requests, you need to extend the filter, but I leave that as an exercise to the reader)
>>
>> The problem with these filters is that you only capture the http requests and not the responses, but you might need be interested in the responses ;-)
>>
>> Hope this helps,
>> Cheers,
>>
>>
>> Sake
>>
>> PS  pre HTTP/1.0 requests will also match these filter, but I think you will not find those on your network ;-)
>> ___________________________________________________________________________
>> Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
>> Archives:    http://www.wireshark.org/lists/wireshark-users
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>>             mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>>
>
>
>
> --
> Greg
> http://blog.gregnet.org/
>



--
Greg
http://blog.gregnet.org/
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
            mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe