[aprssig] UNDEFINED?

Thu Apr 30 16:30:51 EDT 2020

Well, there's certainly no excuse for a commercial fleet tracking system to be on APRS-IS (except, of course, saving company money by mooching someone else's infrastructure). Thankfully, throttling might discourage them.

Related to throttling, I came up with another discouraging idea for such abusers. Each time a client connects to an APRS-IS server, send comments stating this is an amateur radio only network, and commercial traffic is forbidden by national and international law. Then ignore/discard all of their traffic in both directions for 10 to 30 seconds before resuming normal processing (with throttling). It would be a little annoying for legitimate users with flaky Internet connections, but it might lower our network's usability for commercial purposes beyond their tolerance. After all, we know abusers will ignore the legal notice (that's why they're abusers), but having throttling and outages every time they reconnect should make us less usable for them. And when they research the problem, they might get the hint we don't want them there.Andrew, KA2DDOauthor of YAAC andprofessional software engineer for commercial international logistics software (no ad for my employer here)

-------- Original message --------
From: Heikki Hannikainen <hessu at hes.iki.fi> 
Date: 4/30/20  13:52  (GMT-05:00) 
To: aprssig at lists.tapr.org 
Subject: Re: [aprssig] UNDEFINED? 

Actually, this might be the manufacturer:http://www.corget.com/en/They have fleet management apps:http://www.corget.com/en/fwzc.php?id=7corget.cn is listed as the app version in the APRS-IS login string, as described below.On Thu, 30 Apr 2020, Heikki Hannikainen wrote:>> Hi,>> I agree; if a single callsign of an intentional abuser is filtered > altogether, it is very easy for him to switch to another callsign, and then > it's again much more work for us to filter the second callsign.>> If we somehow filter all non-valid-looking callsigns, then he will start > using someone's valid callsign, and then it's even more problematic since > that someone may be quite upset.>> But if this is not intentional abuse, rather just a misbehaving client app, > filtering will help.>> I have been thinking about a rate limiter on client ports, where a single > client could not accidentally send huge bursts of packets. Such bursts may > potentially cause slower clients or slower interserver links to get > disconnected due to a buffer overrun.>>> I checked the logs of T2FINLAND of a few days. The connections from UNDEFINED > came from 125 unique IPs (to just T2FINLAND alone), from USA, Mexico, Chile, > Costa Rica, AWS EC2, South Africa, Jersey and Sweden. Mostly > end-user/customer networks (ATT mobile, etc) and some hosting networks. For > many networks (such as the ATT mobile access network) many close-by IP > addresses appeared from the same operator allocation / subnet, indicating > dynamic IP allocation; these could be all the same client just getting > different IPs over time, or multiple clients.>> Because there were a lot of IPs around the world, I suspected they may be TOR > exit nodes; but no, none of them are listed in the TOR exit node lookup > service.>> So, my *guess* is that some pre-existing vehicle tracking software from China > has recently gained APRS support in a new software version, and without > proper configuration present, it runs with the UNDEFINED callsign and still > transmits positions. Guessing China, because it says "gpserver" as the > application name, and "corget.cn" as the version number. No such domain on > DNS though, but these might help in finding the software.>> For aprsc operators, you can look for these IPs like this (shows the number > of connections from each IP):>> grep UNDEFINED aprsc.log*|grep -v DEBUG|grep closed|sed -e 's/.*Client TCP > //' -e 's/:.*//'|sort|uniq -c|sort -n|less>> and then to look up whether any TOR exit nodes are present:>> grep UNDEFINED aprsc-t2finland.*|grep -v DEBUG|grep closed|sed -e 's/.*Client > TCP //' -e 's/:.*//'|sort|uniq|perl -nle 'print(join(".",reverse(split > /\./,$_)) . ".dnsel.torproject.org")' | xargs -n 1 dig +noall +nocomments > +answer>>> It might be interesting to try to look for log entries using this gpserver > app, but not an UNDEFINED callsign.>> As for workaround, maybe I should add a method in aprsc to reject packets > sent by a specific client app (such as 'gpserver' in this case) if so > configured.>> But how about if we'll just filter packets originated by UNDEFINED on the T2 > hub servers for now? This will take the rate down and hide this from the core > servers; you'll still see some of these packets if you're connected to the T2 > leaf with one of these clients.>>> On Thu, 30 Apr 2020, Lynn W Deffenbaugh (Mr) wrote:>>> There are many valid APRS stations that use so-called tactical calls that >> look just like this one, so any attempt at automatic>> filtering would not be a good idea.>> >> I'm suspecting it may be one new software implementation that is executing >> on several devices in different locations.  But that's>> just a guess.  I didn't look at the servers it was coming through, but that >> can also be explained by a novice coder that is>> resolving a round-robin DNS, connecting to the server, logging in, sending >> the packet and dropping the connection rather than>> keeping it open.>> >> I think if it were an actual DOS attempt, the tracks wouldn't be following >> roads if you ignore the physics-defying jumps.>> >> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32>> >> >> On 4/30/2020 11:55 AM, spam8mybrain via aprssig wrote:>>       Is it coming from a single client IP address, or do they have a >> botnet driving this?>> Since UNDEFINED is not a valid callsign, can the backbone servers blacklist >> this?>> >> Perhaps the servers need a patch so that the callsign-SSID has to look >> semi-legitimate (digits and letters, part preceding a>> hyphen limited to 6 or 7 characters, etc.). Of course, that level of >> hardening would be easy for the evil one to work around>> by just forging a legitimate callsign. But let's not document it, since >> legitimate users would never be hindered by the>> constraint.>> >> Andrew, KA2DDO>> author of YAAC>> >> >> >> -------- Original message -------->> From: John Langner WB2OSZ <wb2osz at comcast.net>>> Date: 4/30/20 10:49 (GMT-05:00)>> To: aprssig at lists.tapr.org>> Subject: [aprssig] UNDEFINED?>> >> This looks like a deliberate attack, not an innocent accidental>> misconfiguration.>> >> It appears to be scanning thru a large number of T2 servers, around the>> world. The location is bouncing all over the place, perhaps to thwart>> duplicate removal and fill up the database.>> >> >> At  http://ontario.aprs2.net:14501/   we find:>> >> >> 187.210.189.241 UNDEFINED true gpserver  corget.cn No filter>> set 0d1h0m4.17s 121 2,402 7,676 184,425 21 512>> 0d0h0m4.249s>> >> 2400 packets per hour to the Ontario server alone. >> >> This might be an attempt at a denial of service attack.>> >> >> >> >> _______________________________________________>> 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>> >> >> >> >>  - Hessu>   - 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/20200430/e3be06cb/attachment.html>