[aprssig] aprsis DOS in Poland, observation

[spam8mybrain]

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 SSLWhat 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 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, KA2DDOauthor of YAACprofessional 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=0Some 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=0And 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-9I 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 listaprssig at lists.tapr.orghttp://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20200905/7e749c42/attachment.html>