<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body>So what is the solution? Do we need to put in throttling for uplinked clients not known explicitly to be other backbone servers?
<div><br></div><div>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.</div><div><br></div><div>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</div><div><br></div><div>What exactly is the organization of the backbone server operators that ensures that a bogus backbone server can't connect in?</div><div><br></div><div>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.</div><div><br></div><div>Just my $.02.</div><div><br></div><div>Andrew, KA2DDO</div><div>author of YAAC</div><div>professional software and network security engineer</div><br><br>-------- Original message --------<br>From: Heikki Hannikainen <hessu@hes.iki.fi> <br>Date: 9/5/20 04:18 (GMT-05:00) <br>To: Bill Vodall <wa7nwp@gmail.com> <br>Cc: TAPR APRS Mailing List <aprssig@lists.tapr.org> <br>Subject: Re: [aprssig] aprsis DOS in Poland, observation <br><br>On Fri, 4 Sep 2020, Bill Vodall wrote:<br><br>> Is aprs-is under a Denial of Services attack by jankesi and others?<br>> Looks like multiple packets arriving every second.<br><br>The packet rate during the DOS abuse event last night was some 1500-1700 <br>packets per second at peak.<br><br>https://www.dropbox.com/s/tztvaup286vzwnb/aprsfi-polish-abuse-20200904-traffic.png?dl=0<br><br>Some APRS-IS clients on the full feed could not take this traffic (too <br>slow to process, or too slow network, buffers fill up) and got <br>disconnected. As a network traffic rate, it was only around 1.4 Mbit/s sec <br>though. Due to a bug, the two APRS-IS data aggregator aprsc instances at <br>aprs.fi crashed too, leaving aprs.fi without a data feed.<br><br>This is how it looked on the map, screen shot courtesy of Mateusz Szyper <br>on the aprs.fi discussion group:<br><br>https://www.dropbox.com/s/5wbjtttkkw1munh/aprs-polish-abuse-20200904-map.jpg?dl=0<br><br>And here are a few sample packets, showing what the randomly generated <br>packets looked like. The coordinates are random, in Poland, with the <br>clear intention of polluting the map fully.<br><br>2020-09-04 19:48:27 EEST: CI37PA>APDR16,WIDE3-3,qAC,SQ6KPO-1:=5031.68N\01844.35EZ jeszcze nie dojrzalem.<br>2020-09-04 19:48:46 EEST: CI371PY-3>APDR16,WIDE3-3,qAC,SQ6KPO-1:=5248.72N/01933.83EX sie draznic z ludzmi.<br>2020-09-04 19:45:58 EEST: CI37PA-21>APDR16,WIDE3-3,qAC,SQ6KPO-1:=5411.38N\01600.85E-2 Jebane kurwy cebulaki.<br>2020-09-04 19:48:56 EEST: CI37PA-20>APDR16,WIDE3-3,qAC,SQ6KPO-1:=5051.97N/01543.24Eb masz, masz.<br>2020-09-04 19:49:26 EEST: CI37PA-88>APDR16,WIDE3-3,qAC,SQ6KPO-1:=5002.85N/02147.17Ec pomarancza kurwo niebieska.<br><br>Here's more, each source callsign emitted packets at random coordinates <br>with comments from some pool of (obscene) text, so you can just pick one <br>call and watch:<br><br>https://aprs.fi/?c=raw&limit=&call=CI37PA-9<br><br>I haven't looked at a large data set yet; these samples were from a very <br>small set of a thousand packets that I took a quick look at now. These <br>packets were injected using an igate call of SQ6KPO-1 but there's no <br>reason why that could not be a random call in the future. Also, it would <br>be *very* unlikely that SQ6KPO is the callsign of the person doing this <br>abuse - it is more likely that the intention is to abuse him by using his <br>callsign.<br><br>It's easy to write a client to do this kind of abuse, and easy to improve <br>it (make more things random), and after that it's quite difficult to fully <br>filter.<br><br>This is just to describe what happened, and what you should expect to see <br>in the future. We've been lucky to have very little abuse and DOS attacks <br>so far.<br><br> - Hessu<br><br><br>_______________________________________________<br>aprssig mailing list<br>aprssig@lists.tapr.org<br>http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org<br></body></html>