tcpdump: capturing traffic only from external hosts

Mark Hobley <markhobley.DeleteThis@hotpop.donottypethisbit.com> wrote:
> I am using tcpdump, and I want to capture only traffic coming from
> external hosts (ie not coming from LAN hosts).

> For example, I have a server on 10.0.0.101 providing a service on
> port 9999. This is being used by both internal and external hosts.

> If an internal host (say 10.0.0.102) makes a connection, I do not
> wish to capture this.

> However, if an external host (say 118.168.141.172) made a
> connection, I would like to capture the traffic.

> I cannot predict the address of the external host, and require
> capture of all traffic not being established from hosts on the local
> area network.

> How do I do this?

With a tcpdump filter program. There should be at least a little
about it in the tcpdump manpage, and do doubt lots of examples out in
the web. You would want something along the lines of (not proper
tcpdump syntax)

rick jones
--
web2.0 n, the dot.com reunion tour...
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Chris Davies wrote:
> Mark Hobley <markhobley RemoveThis @hotpop.donottypethisbit.com> wrote:
>> I am using tcpdump, and I want to capture only traffic coming from
>> external hosts (ie not coming from LAN hosts).
>
>> For example, I have a server on 10.0.0.101 providing a service on
>> port 9999.
>
>> How do I do this?
>
> [snip]
>
> First filter, matching traffic from your server:
> S='( src host 10.0.0.101 and ! dst net 10.0.0.0/8 )'
>
> Second filter, matching traffic to your server:
> D='( dst host 10.0.0.101 and ! src net 10.0.0.0/8 )'
>
> Now you want either of them to fire, so you join them with "or":
> tcpdump "$S or $D"
>
> Needless to say, you don't need to use shell variables unless you want
> to do so. In this example, though, I've used them to try and show how
> the filter is built up.

Or just

# tcpdump "not (src net 10.0.0.0/8 and dst net 10.0.0.0/"

Anything meeting "(...)" is local-only, so anything "not (...)" is not
local-only.

Rick Jones <rick.jones2.TakeThisOut@hp.com> wrote:
> With a tcpdump filter program. There should be at least a little
> about it in the tcpdump manpage

IIRC there was very little useful information in the tcpdump manpage. And
even less in the replacement wireshark/tshark pages, although at least
those seem to refer usefully to pcap-filter.


> and no doubt lots of examples out in the web

That may be true, indeed, although a quick perusal suggests that the
OP's request is not one that could be found easily.

Chris

Chris Davies <chris-usenet.TakeThisOut@roaima.co.uk> wrote:

> First filter, matching traffic from your server:
> S='( src host 10.0.0.101 and ! dst net 10.0.0.0/8 )'
>
> Second filter, matching traffic to your server:
> D='( dst host 10.0.0.101 and ! src net 10.0.0.0/8 )'
>
> Now you want either of them to fire, so you join them with "or":
> tcpdump "$S or $D"

Right cheers Chris. That has given me a good start. I am actually running
tcpdump on the host 10.0.0.101, so I have scrubbed the host bit, and used the
port number to restrict the logging against that port.

I came up with:

tcpdump -f -xx '( port 9999 ) and (( ! src net 10.0.0.0/8 ) or
( ! dst net 10.0.0.0/8 ))'

The story is a bit more complicated. I am actually trying to trap a bug in
the netfilter where connections from outside of the address whitelist are
being established.

Unfortunately tcpdump logs the traffic before the netfilter, so the only way
that I can determine that the traffic traversed that filter is that the
application responds to the incoming packet.

It would be nice if there was a way to put tcpdump onto the other side of the
netfilter, so only traffic that has traversed the filter gets logged.

As a workaround, I will capture the output to a file, and then search for
traffic that the application has responded to, and then scrub out the entries
that are on the whitelist.

Cheers,

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

Mark Hobley <markhobley.TakeThisOut@hotpop.donottypethisbit.com> wrote:
> tcpdump -f -xx '( port 9999 ) and (( ! src net 10.0.0.0/8 ) or
> ( ! dst net 10.0.0.0/8 ))'

You might want to consider sessions *starting* from port 9999.

Chris

Chris Davies wrote:
> Mark Hobley <markhobley.TakeThisOut@hotpop.donottypethisbit.com> wrote:
>> tcpdump -f -xx '( port 9999 ) and (( ! src net 10.0.0.0/8 ) or
>> ( ! dst net 10.0.0.0/8 ))'
>
> You might want to consider sessions *starting* from port 9999.

tcpdump doesn't track connection state, only packet direction.

(not src net ...) or (not dst net ...)
is the same as
not (src net ... and dst net ...)
by Boolean distribution.

A local src with a non-local dst meets (not dst net) or fails (dst net),
whichever way you want to look at it. The overall Boolean is true and
captures the packet.

Mark Hobley wrote:
> It would be nice if there was a way to put tcpdump onto the other side of the
> netfilter, so only traffic that has traversed the filter gets logged.

Maybe not with tcpdump directly, but you could use ulogd2's PCAP output
plugin towards the end of your rules to dump only the relevant filtered
packets into a tcpdump-compatible file.

-Chris

> Chris Davies wrote:
>> Mark Hobley <markhobley RemoveThis @hotpop.donottypethisbit.com> wrote:
>>> tcpdump -f -xx '( port 9999 ) and (( ! src net 10.0.0.0/8 ) or
>>> ( ! dst net 10.0.0.0/8 ))'
>>
>> You might want to consider sessions *starting* from port 9999.

Allen Kistler <ackistler RemoveThis @oohay.moc> wrote:
> tcpdump doesn't track connection state, only packet direction.

I know, thank you. That wasn't the point I was trying to make. The OP
wanted traffic hitting destination port 9999 but the ruleset will also
capture traffic with a source of 9999.

Chris