tcpdump: capturing traffic only from external hosts
Mark Hobley
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?
--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/
Chris Davies
> 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?
You need a combination of two filters, one matching data from your server
to "the world" and one matching data from "the world" to your server.
You mentioned 10.0.0.101. For the purposes of this example I'm going to
assume that you're using network 10.0.0.0 with an 8-bit subnet mask. (If
you'd mentioned an address starting 192.168 I'd have assumed a 24-bit
mask.)
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.
Chris
Rick Jones
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
> 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
Allen Kistler
> Mark Hobley <markh...@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?
>
>
> 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/8)"
Anything meeting "(...)" is local-only, so anything "not (...)" is not
local-only.
Mark Hobley
> 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.
Chris Davies
> 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
Allen Kistler
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.
Christian Winter
> 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
>> Mark Hobley <markh...@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 <acki...@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