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
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel