Re: how can I filter on traffic that is (a) going in/out through the company internet proxy [e.g. proxy.mycompany.com] and (b) to/from my PC?

[Greg Hauptmann <greg.hauptmann.ruby () gmail com>]

Hi Martin - I guess it's more turned out to be a challenge question
for me.  In fact the generalised questions probably are:

a) Is it possible on a PC within a company network, to be able to
identify traffic that is internet bound, without any additional
information (e.g. proxy name)?   [perhaps the answer to this question
is no]

b) Same question as above, but this time assume you know the main DNS
name for the company proxy server.  So with this knowledge is it
possible in this case to be able to identify traffic that is internet
bound?  [which is what I've been asking about re logistics, but the
generalized question is whether its possible at all]

thanks

On 17 August 2010 08:02, Martin Visser <martinvisser99 () gmail com> wrote:
> 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 () gmail com
>
>
> On Tue, Aug 17, 2010 at 7:17 AM, Greg Hauptmann
> <greg.hauptmann.ruby () gmail com> 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 () gmail com>
> > 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 () euronet nl> 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 () wireshark org>
> > > > Archives:    http://www.wireshark.org/lists/wireshark-users
> > > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> > > >
> > > > mailto:wireshark-users-request () wireshark org?subject=unsubscribe
> > >
> > >
> > >
> > > --
> > > Greg
> > > http://blog.gregnet.org/
> >
> >
> >
> > --
> > Greg
> > http://blog.gregnet.org/
> >
> > ___________________________________________________________________________
> > Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> > Archives:    http://www.wireshark.org/lists/wireshark-users
> > Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> >
> > mailto:wireshark-users-request () wireshark org?subject=unsubscribe
>
>
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>             mailto:wireshark-users-request () wireshark org?subject=unsubscribe



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