Re: [Sks-devel] Unusual traffic for key 0x69D2EAD9 and 0xB33B4659

[brent s.]

On 3/20/19 4:44 PM, Jeremy T. Bouse wrote:>
>       I don't speak for all SKS server operators, but I do have a
> configuration block in my NGINX configuration that specifically
> identifies those keys and simply returns a 444 status code.
> 
>       I've been trying to get a handle on the instability of my server
> which has been running the CPU at 100% at times so I enabled an access
> log rule to idenitfy the query strings and upstream times but not the
> requesting IP address... According to my status page my server only
> spent 61.924% of yesterday in the pool or roughly 14.86 hours, during
> that same period of time my server saw 12436 requests for those 2 keys
> for an average of 836.86 requests per hour or nearly 14 per minute.
> During most times that wouldn't be a lot but when the system is under
> load that volume adds up and is non-trivial.
> 
>       One opption the FreePBX team could do is self-publish their key using
> WKD or PKA. WKD you would store the file on your own web server
> that no one else could touch (presumably if setup properly anyway) and
> PKA you would publish within DNS records. GPG has the ability to
> retrieve from both methods without needing to use a keyserver.
> 


I'd second this, as it's the "most right" solution (he says, still not
having set up WKD/PKA for his own personal infra yet. I really need to
get on that...).

An alternative is to set up your own SKS that does not allow submissions
(I'd imagine you could just 403 the upload path/args except for a few
authorized addresses since HKP more or less is just HTTP), keep that as
your modules' key repository, and create a fresh master key that signs
those pubkeys, and publish that new master to the WoT/SKS pool. That
doesn't do a terribly good job of preventing something like this in the
future, of course, but does insulate you from the load caused by
installations fetching the keys; core could be distributed with the
master pubkey, even, and you'd then have a method of checking module
signatures right from the get-go.

You can also just host the master pubkey as an exported key somewhere,
and fetch that directly.

I think the massive load is mostly caused by the querying of the master
key against the SKS pool more than anything.

-- 
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info

signature.asc
Description: OpenPGP digital signature