[aprssig] UNDEFINED?

Thu Apr 30 13:52:15 EDT 2020

Actually, this might be the manufacturer:

http://www.corget.com/en/

They have fleet management apps:

http://www.corget.com/en/fwzc.php?id=7

corget.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