Re: blacklisting nodes that probe non-existant nodes

[Roy Marples <roy%marples.name@localhost>]

On 11/03/2020 15:52, Christos Zoulas wrote:
> In article <6d301f35-05ea-25b4-fb19-c473d68fd29f%marples.name@localhost>,
> Roy Marples  <roy%marples.name@localhost> wrote:
> > -=-=-=-=-=-
> >
> > Hi
> >
> > So I have an IPv6 capable interface on my router.
> > When I run route monitor, I get a lot of RTM_MISS for non-existant nodes on my
> > prefix. Logging this to the ERLITE takes a fair chunk of CPU time.
> > I added a small patch to the kernel to add the source address of the requesting
> > node here:
> > https://mail-index.netbsd.org/source-changes/2020/03/09/msg114961.html
> >
> > I would like to move this to the next level - blacklisting the source address!
> >
> > I've added two patches to blacklistd:
> > https://mail-index.netbsd.org/source-changes/2020/03/11/msg114980.html
> > https://mail-index.netbsd.org/source-changes/2020/03/11/msg114981.html
> >
> > This now allows a userland application to poll route(4) messages for RTM_MISS
> > and blacklist the RTA_AUTHOR if his address does not belong to a prefix on our
> > network.
> >
> > I have authored such an application, routemissd (although I'm not beholden to
> > the name).
> > Patch against current attached, comments welcome.
> >
> > For the record, I have one node probing my network in random burst lengths,
> > maybe two or three times a minute, sometimes nothing for a few minutes.
> > Currently the smallest gap is about 8 minutes.
> >
> > When routemissd is running, my load averages are pratically zero on my ERLITE,
> > even with route monitor constantly logging.
> >
> > I doubt this will be of any use for systems that are not routers, but I would
> > still like to include it in NetBSD base system.
> >
> > Comments, as ever, welcome.
>
> While that's nice it opens a huge security hole to blacklistd, since the
> socket is world writable and by letting blacklistd accept -1 as the fd
> there are no access control checks. One thing we can do to mitigate this,
> is to pass the routing socket, and then blacklistd can check that this
> is the routing socket and presume that if you have access to that, you
> can do what you want (since you can control routing you can control the
> packet filter).

Anyone can open PF_ROUTE and read from it or write RTM_GET.
However, you need to have it opened as root to write any other operations.
Do we have a means of testing that without writing to the socket?
I'm guessing no.

I suppose we could enforce testing if SCM_CREDENTIALS passed uid root or same 
uid as blacklistd as running as or maybe even one that matches a rule in 
blacklistd.conf?

Roy