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

[Greg Hauptmann <greg.hauptmann.ruby@xxxxxxxxx>]

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/