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 for Android: free password hash cracker in your pocket

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

Message-ID: <b00fb6e2-c923-39e9-f326-6ec485fcff21@linaro.org>
Date:   Wed, 15 Dec 2021 08:47:51 -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 3:18 AM, Andrew Lunn wrote:
>> IPA is a device that sits between the main CPU and a modem,
>> carrying WWAN network data between them.
>>
>> In addition, there is a small number of other entities that
>> could be reachable through the IPA hardware, such as a WiFi
>> device providing access to a WLAN.
>>
>> Packets can travel "within IPA" between any of these
>> "connected entities."  So far only the path between the
>> AP and the modem is supported upstream, but I'm working
>> on enabling more capability.
>>
>> Technically, the replicated packets aren't visible on
>> any one port; the only way to see that traffic is in
>> using this special port.  To me this seemed like port
>> mirroring, which is why I suggested that.  I'm want to
>> use the proper model though, so I appreciate your
>> response.
> 
> 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?

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).

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.

> where you are mirroring eth0 to tun0. eth0 would have to be your modem
> netdev, or your wifi netdev, and tun0 would be your monitor device.
> 
> If you do have a netdev on the host for each of these network
> interfaces, mirroring could work. Architecturally, it would make sense
> to have these netdevs, so you can run wpa_supplicant on the wifi
> interface to do authentication, etc.
> 
> 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.

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.

Thanks.

					-Alex

> 	Andrew
>