netdev - Re: Port mirroring (RFC)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c71f1f98-13cc-ff82-7bf5-2c733de9ab2b@linaro.org>
Date:   Mon, 20 Dec 2021 13:27:58 -0600
From:   Alex Elder <elder@...aro.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Network Development <netdev@...r.kernel.org>,
        "bjorn.andersson@...aro.org" <bjorn.andersson@...aro.org>
Subject: Re: Port mirroring (RFC)

On 12/15/21 11:42 AM, Andrew Lunn wrote:
>>> Do you have netdevs for the modem, the wifi, and whatever other
>>> interfaces the hardware might have?
>>
>> Not yet, but yes I expect that's how it will work.
>>
>>> To setup a mirror you would do something like:
>>>
>>> sudo tc filter add dev eth0 parent ffff: protocol all u32 match u32 0 0 action mirred egress mirror dev tun0
>>
>> OK so it sounds like the term "mirror" means mirroring using
>> Linux filtering.  And then I suppose "monitoring" is collecting
>> all "observed" traffic through an interface?
> 
> Yes, that seems like a good description of the difference.
>   
>> If that's the case, this seems to me more like monitoring, except
>> I suggested presenting the replicated data through a separate
>> netdev (rather than, for example, through the one for the modem).
> 
> The wifi model allows you to dynamical add netdev on top of a physical
> wireless LAN chipset. So you can have one netdev running as an access
> point, and a second netdev running as a client, both sharing the
> underlying hardware. And you should be able to add another netdev and
> put it into monitor mode. So having a dedicated netdev for your
> monitoring is not too far away from what you do with wifi.

It sound to me like WiFi monitoring mode could very much be
a model that would work.  I need to spend some time looking
at that in a little more detail.  I don't think there's any
reason the "dedicated" netdev couldn't be created dynamically.

I'll come back again after I've had a chance to look at these
suggestions (yours and others'), possibly with something closer
to a design to follow.

Thank you very much, this is a promising lead.

					-Alex

>> If it makes more sense, I could probably inject the replicated
>> packets received through this special interface into one or
>> another of the existing netdevs, rather than using a separate
>> one for this purpose.
> 
>>> Do you have control over selecting egress and ingress packets to be
>>> mirrored?
>>
>> That I'm not sure about.  If it's possible, it would be controlling
>> which originators have their traffic replicated.
> 
> You need this if you want to do mirroring, since the API requires to
> say if you want to mirror ingress or egress. WiFi monitoring is less
> specific as far as i understand. It is whatever is received on the
> antenna.
> 
>> I don't think it will take me all that long to implement this, but
>> my goal right now is to be sure that the design I implement is a good
>> solution.  I'm open to recommendations.
> 
> You probably want to look at what wifi monitor offers. And maybe check
> with the WiFi people what they actually think about monitoring, or if
> they have a better suggestion.
> 
>       Andrew
>