[aprssig] UNDEFINED?

Thu Apr 30 13:31:40 EDT 2020

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