[aprssig] Fwd: aprsis DOS in Poland, rate limiting ideas

Sun Sep 6 02:14:35 EDT 2020

I have already before thought about having packet rate connection per 
client socket, on the filtered connections which should not have any 
servers on them.

Mostly just to protect the network against some client accidentally (due 
to a bug or misconfiguration) sending thousands of packets per second. 
This wouldn't prevent against abuse, as someone can easily make a 1000 
parallel connections.

The rate could be something like 100 or 200 packets per second which the 
network should survive. Or something like 50 packets per second with a 
slightly longer average so that it would allow bursts over that (there 
could be a 200 pps burst in a second, but over 10 seconds, it would not be 
allowed to go over 50 pps on average). Or something roughly towards that 
direction.

On Sat, 5 Sep 2020, Curt Mills wrote:

> Oh, forgot to mention: I have throttling built-in to those of my Perl
> scripts that generate a lot of objects so they don't throw too many
> packets at the servers per second.
>
> If the throttling were done at the server and by callsign, I'd have to
> make sure I was injecting under a different callsign per script. If it
> was done by connection instead the limit might need to be higher than
> 2 or 3 per second for a couple of my scripts: Quakes and Stream Gauges
> are the two I'm thinking about. Other packet generators on Firenet
> might have different requirements for their scripts or programs.
>
>
> On Sat, Sep 5, 2020 at 4:33 PM Curt Mills <curt.we7u at gmail.com> wrote:
>>
>> Connection throttling, or callsign throttling?
>>
>> I have multiple Perl scripts that send objects into Firenet and
>> APRS-IS, but mostly Firenet... The same server software is used on
>> APRS-IS and Firenet, so if it gets added to APRS-IS, the same
>> "feature" will get added to Firenet and cause trouble for we object
>> generators.
>>
>> On Sat, Sep 5, 2020 at 2:36 PM spam8mybrain via aprssig
>> <aprssig at lists.tapr.org> wrote:
>>>
>>> So what is the solution? Do we need to put in throttling for uplinked clients not known explicitly to be other backbone servers?
>>>
>>> Throttling actually might be a good solution. Since any real I-gate couldn't send up more than about 2 packets per second (given the bandwidth of the RF channel it monitors, and assuming tiny Mic-E packets), any connections sending, say, a 10-second average of faster than 2 packets/second (or 120 payload bytes/second) is disconnected with a status comment of throttling.
>>>
>>> Obviously, one wouldn't want to do that on downwards paths, or on uplinks/sidelinks from another backbone server (i.e., Tier 2 to Tier 1), but the identity of those servers are well-known, so such connections could be identified (IP address check plus more stringent authentication such as SSL/TLS) as privileged. For example, an SSL
>>>
>>> What exactly is the organization of the backbone server operators that ensures that a bogus backbone server can't connect in?
>>>
>>> As an alternative for plain IP address checking, the backbone servers could do something like SPF (Sender Policy Framework, as is used for email validation) to confirm a connecting host claiming to be a backbone server really is one, allowing changing IP addresses of backbone servers and"Stephen H. Smith via aprssig" <aprssig at lists.tapr.org>"Stephen H. Smith via aprssig" <aprssig at lists.tapr.org> multihoming without huge reconfiguration issues. But there aren't that many backbone-server-to-backbone-server links on any given server for it to be a major issue; if one link goes down for a while, there are enough redundant links to keep the net going until an administrator can apply a config change to match someone else's config change, which should be coordinated anyway.
>>>
>>> Just my $.02.
>>>
>>> Andrew, KA2DDO
>>> author of YAAC
>>> professional software and network security engineer
>>>
>>>
>>> -------- Original message --------
>>> From: Heikki Hannikainen <hessu at hes.iki.fi>
>>> Date: 9/5/20 04:18 (GMT-05:00)
>>> To: Bill Vodall <wa7nwp at gmail.com>
>>> Cc: TAPR APRS Mailing List <aprssig at lists.tapr.org>
>>> Subject: Re: [aprssig] aprsis DOS in Poland, observation
>>>
>>> On Fri, 4 Sep 2020, Bill Vodall wrote:
>>>
>>>> Is aprs-is under a Denial of Services attack by jankesi and others?
>>>> Looks like multiple packets arriving every second.
>>>
>>> The packet rate during the DOS abuse event last night was some 1500-1700
>>> packets per second at peak.
>>>
>>> https://www.dropbox.com/s/tztvaup286vzwnb/aprsfi-polish-abuse-20200904-traffic.png?dl=0
>>>
>>> Some APRS-IS clients on the full feed could not take this traffic (too
>>> slow to process, or too slow network, buffers fill up) and got
>>> disconnected. As a network traffic rate, it was only around 1.4 Mbit/s sec
>>> though. Due to a bug, the two APRS-IS data aggregator aprsc instances at
>>> aprs.fi crashed too, leaving aprs.fi without a data feed.
>>>
>>> This is how it looked on the map, screen shot courtesy of Mateusz Szyper
>>> on the aprs.fi discussion group:
>>>
>>> https://www.dropbox.com/s/5wbjtttkkw1munh/aprs-polish-abuse-20200904-map.jpg?dl=0
>>>
>>> And here are a few sample packets, showing what the randomly generated
>>> packets looked like. The coordinates are random, in Poland, with the
>>> clear intention of polluting the map fully.
>>>
>>> 2020-09-04 19:48:27 EEST: CI37PA>APDR16,WIDE3-3,qAC,SQ6KPO-1:=5031.68N\01844.35EZ jeszcze nie dojrzalem.
>>> 2020-09-04 19:48:46 EEST: CI371PY-3>APDR16,WIDE3-3,qAC,SQ6KPO-1:=5248.72N/01933.83EX sie draznic z ludzmi.
>>> 2020-09-04 19:45:58 EEST: CI37PA-21>APDR16,WIDE3-3,qAC,SQ6KPO-1:=5411.38N\01600.85E-2 Jebane kurwy cebulaki.
>>> 2020-09-04 19:48:56 EEST: CI37PA-20>APDR16,WIDE3-3,qAC,SQ6KPO-1:=5051.97N/01543.24Eb masz, masz.
>>> 2020-09-04 19:49:26 EEST: CI37PA-88>APDR16,WIDE3-3,qAC,SQ6KPO-1:=5002.85N/02147.17Ec pomarancza kurwo niebieska.
>>>
>>> Here's more, each source callsign emitted packets at random coordinates
>>> with comments from some pool of (obscene) text, so you can just pick one
>>> call and watch:
>>>
>>> https://aprs.fi/?c=raw&limit=&call=CI37PA-9
>>>
>>> I haven't looked at a large data set yet; these samples were from a very
>>> small set of a thousand packets that I took a quick look at now. These
>>> packets were injected using an igate call of SQ6KPO-1 but there's no
>>> reason why that could not be a random call in the future. Also, it would
>>> be *very* unlikely that SQ6KPO is the callsign of the person doing this
>>> abuse - it is more likely that the intention is to abuse him by using his
>>> callsign.
>>>
>>> It's easy to write a client to do this kind of abuse, and easy to improve
>>> it (make more things random), and after that it's quite difficult to fully
>>> filter.
>>>
>>> This is just to describe what happened, and what you should expect to see
>>> in the future. We've been lucky to have very little abuse and DOS attacks
>>> so far.
>>>
>>>    - Hessu
>>>
>>>
>>> _______________________________________________
>>> aprssig mailing list
>>> aprssig at lists.tapr.org
>>> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
>>> _______________________________________________
>>> aprssig mailing list
>>> aprssig at lists.tapr.org
>>> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
>>
>>
>>
>> --
>> Curt, WE7U        http://xastir.org        http://www.sarguydigital.com
>
>
>
> --
> Curt, WE7U        http://xastir.org        http://www.sarguydigital.com
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
>

   - Hessu