Annoying malicious keys - any easy solution?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Annoying malicious keys - any easy solution?

echelon
Hi

I´ve redone my keyserver and currently the annoying malicious keys
annoying me.
Somehow it managed to kill sks and OOM my apache2 setup, until I did fix
small sks changes.
command_timeout: 600
wserver_timeout: 30
max_recover: 150

It seems to keep the sks server stable, but these keys:
0x69D2EAD9
0x1013D73FECAC918A0A25823986CE877469D2EAD9
0x2016349F5BC6F49340FCCAF99F9169F4B33B4659
(one of them specially notes "do not use sks keyservers as they are broken")

seems to be asked a lot (200-500 times/hour), and those seems to be
broken with ueseless trash (e.g. requests are handled with 40
MB/keyrequest). Like a email spammer someone ruins the SKS database.

I use apache2 as a proxy webfront to sks, so I could try apache2 to
limit the access.

I know sks devs do not want to take actions, but those keys really do
annoy me and renders server useless, somewhat. It fills the database
with GBs of useless trash (up to 10GB/day on syncing with other DB
servers the last days).

So, what can I do?
I know ths patch (which seems to be included in debian sks package) to
ignore one special malicious key, but that seems to not help about those
noted above. Is there a patch to add more keys to be ignored?
As some IPs requests the same KeyID over and over again (>100 reqs/day),
I do block those IPs with fail2ban.
Anyone has a Apache2 redirect entry to redirect the requests to
$somewhere else with a error page?
Or a way to limit keysize to some 100kb/1MB ?

Yeah, I know all the sideeffects and issues with these hacks, but I do
want to keep my sks server running, but not with these bastard keys
annoyingly using bandwidth and HD space for trash. Sorry.
Also I do know, this persons spamming will use more and more keys, until
a solution in sks is found.

And one note about all this: if this spamming goes on, and sks does not
work around it, it will destroy/remove lots of key servers from the
network, thus killing this nice features.

thank you.

echelon

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Annoying malicious keys - any easy solution?

Kiss Gabor (Bitman)
> So, what can I do?
> I know ths patch (which seems to be included in debian sks package) to
> ignore one special malicious key, but that seems to not help about those
> noted above. Is there a patch to add more keys to be ignored?
> As some IPs requests the same KeyID over and over again (>100 reqs/day),
> I do block those IPs with fail2ban.

Fail2Ban is useful but I intentionally do not log where the requests
come. Logging in the proxy is turned off.

Gabor

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Annoying malicious keys - any easy solution?

Andreas Puls


Am 17.02.2019 um 11:54 schrieb Gabor Kiss:

>> So, what can I do?
>> I know ths patch (which seems to be included in debian sks package) to
>> ignore one special malicious key, but that seems to not help about those
>> noted above. Is there a patch to add more keys to be ignored?
>> As some IPs requests the same KeyID over and over again (>100 reqs/day),
>> I do block those IPs with fail2ban.
>
> Fail2Ban is useful but I intentionally do not log where the requests
> come. Logging in the proxy is turned off.
>

I'm using nginx as reverse proxy and added this to the config:
if ( $args ~
"op=get&options=mr&search=(0x1013D73FECAC918A0A25823986CE877469D2EAD9|0x2016349F5BC6F49340FCCAF99F9169F4B33B4659|0xB33B4659|0x69D2EAD9)"
) {
        return 444;
}

444: Connection Closed Without Response

Additonal i use fail2ban which triggers on the errorcode 444
> Gabor

Br
  Andreas
>
> _______________________________________________
> Sks-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Annoying malicious keys - any easy solution?

Todd Fleisher
Do you (or others) see are any side effects to this approach? I’m particularly wondering if it would cause your server to fall behind if it repeatedly closes connections from its peers.

-T

> On Feb 17, 2019, at 3:00 AM, Andreas Puls <[hidden email]> wrote:
>
>
>
> Am 17.02.2019 um 11:54 schrieb Gabor Kiss:
>>> So, what can I do?
>>> I know ths patch (which seems to be included in debian sks package) to
>>> ignore one special malicious key, but that seems to not help about those
>>> noted above. Is there a patch to add more keys to be ignored?
>>> As some IPs requests the same KeyID over and over again (>100 reqs/day),
>>> I do block those IPs with fail2ban.
>>
>> Fail2Ban is useful but I intentionally do not log where the requests
>> come. Logging in the proxy is turned off.
>>
>
> I'm using nginx as reverse proxy and added this to the config:
> if ( $args ~
> "op=get&options=mr&search=(0x1013D73FECAC918A0A25823986CE877469D2EAD9|0x2016349F5BC6F49340FCCAF99F9169F4B33B4659|0xB33B4659|0x69D2EAD9)"
> ) {
> return 444;
> }
>
> 444: Connection Closed Without Response
>
> Additonal i use fail2ban which triggers on the errorcode 444
>> Gabor
>
> Br
>  Andreas
>>
>> _______________________________________________
>> Sks-devel mailing list
>> [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/sks-devel
>>
>
> _______________________________________________
> Sks-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Annoying malicious keys - any easy solution?

Andreas Puls
Hi Todd,

Am 17.02.2019 um 17:02 schrieb Todd Fleisher:
> Do you (or others) see are any side effects to this approach? I’m particularly wondering if it would cause your server to fall behind if it repeatedly closes connections from its peers.
>

Sorry, currently i don't know - it was a shortcircuit reaction.
But i think it shouldn't affect the peering with other. They do somthing
like this "POST /pks/hashquery HTTP/1.0" (maybe some one can give a
short feedback)

These keys made about 80% of the whole traffic (keyserver), the request
per seconds where kinda high.
If you try to get info about the keys via webinterface you will receive
garbage, the key itselfs is about 2.5Mb big.
The blocking will only affect the request where are you trying to
donwload the .asc file.
Maybe i'm a bit stubborn but after this step my server is much more
reachable. (until now. my provider had to reboot the server but sks
isn't marked for autostart :( )

> -T
>

Br
  Andreas

>> On Feb 17, 2019, at 3:00 AM, Andreas Puls <[hidden email]> wrote:
>>
>>
>>
>> Am 17.02.2019 um 11:54 schrieb Gabor Kiss:
>>>> So, what can I do?
>>>> I know ths patch (which seems to be included in debian sks package) to
>>>> ignore one special malicious key, but that seems to not help about those
>>>> noted above. Is there a patch to add more keys to be ignored?
>>>> As some IPs requests the same KeyID over and over again (>100 reqs/day),
>>>> I do block those IPs with fail2ban.
>>>
>>> Fail2Ban is useful but I intentionally do not log where the requests
>>> come. Logging in the proxy is turned off.
>>>
>>
>> I'm using nginx as reverse proxy and added this to the config:
>> if ( $args ~
>> "op=get&options=mr&search=(0x1013D73FECAC918A0A25823986CE877469D2EAD9|0x2016349F5BC6F49340FCCAF99F9169F4B33B4659|0xB33B4659|0x69D2EAD9)"
>> ) {
>> return 444;
>> }
>>
>> 444: Connection Closed Without Response
>>
>> Additonal i use fail2ban which triggers on the errorcode 444
>>> Gabor
>>
>> Br
>>  Andreas
>>>
>>> _______________________________________________
>>> Sks-devel mailing list
>>> [hidden email]
>>> https://lists.nongnu.org/mailman/listinfo/sks-devel
>>>
>>
>> _______________________________________________
>> Sks-devel mailing list
>> [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/sks-devel
>>
>

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (201 bytes) Download Attachment