[Dxspider-support] Fwd: Max Spot per Minute (how to avoid flooding)

Sat Jan 25 08:12:52 GMT 2025

Hi Dirk, and all.
I think we have to split this topic in 2 parts:
1) commands that have only local effect (so only on the cluster node where
the user is connected).
2) commands that have effect on all the cluster networks with a potential
amplification risk (like DX, ANN, etc)

About the 1) I think that what you already did in the code is great, and
IMHO no need to restrict the limit.

The 2) is what I'm more concerned about because it spreads across the
entire network, is visible to all the clients on the network and can come
in from different ways (coming from a node that is not a DXspider so
without the local restrictions applied in point 1), or from an older
version node with no such restrictions implemented).
We need a sort of DOS (denial of service) protection (the terms come from
the IP network industry***).
In my opinion we need to limit the number of DX or ANN (others?) messages a
node can accept from the same local or remote user (callsign? IP?) in a
specific time window.
In my experience 5 messages (DX/ANN) in 10 seconds is more than enough (I'm
not talking about RBN, that in any case remains local). But as I said
before, we cannot rely only on the node where the user is connected.

There is another thing I would like to say. In recent HF award I have seen
on the network a very bad habit to bypass the de-dupe check by inserting in
the spot a variable part (like timestamp). We should also think of
something to limit this bad behaviour.

*** A DoS or DDoS attack attempts to flood a server, website, network
device or machine with so much malicious traffic that it is unable to
operate. In a volumetric attack — such as an ICMP flood or a UDP flood
attack — attackers overwhelm a target with massive amounts of traffic,
overloading the system, or network path to the system, while preventing
legitimate traffic and users from accessing that resource.

73
Andrea IZ2LSC
-->

On Fri, Jan 24, 2025 at 2:48 PM Dirk Koopman via Dxspider-support <
dxspider-support at tobit.co.uk> wrote:

> We seem to be starting to lose the "battle" between nodes <-> users on
> client programs issuing data (for whatever reason).
>
> The piece of code shown below was introduced in March 2023, together with
> the following comment underneath:
>
>    These default values are set generously deliberately to allow certain
> user
>    programs to get with the program and reduce the number of cmds that they
>    issue on connection down to something reasonable. For instance, I cannot
>    see why things like name, qth, lat/long/QRA (amongst several other
> sticky
>    user attributes that only need to be entered once) are sent on every
> login.
>
> It is clear to me that the situation has got worse and the time to tighten
> the defaults has arrived. In addition, I will add a general re-login delay
> so that programs cannot instantly reconnect and just carry on. Maybe with a
> second/other safeguard of recording the IP address rather than the callsign
> with an backoff timer after Z number of "fast" attempts to re-login. Or
> something like that (maybe a timed local IP address ban?).
>
> I will happily accept suggestions for "better" values for X = 16 and Y = 9
> below. As well as other ways of discouraging this sort of behaviour.
>
> I fail to understand the point of spotting an entire FTx channel's decoded
> callsigns. You haven't worked them, your program just heard them, but
> you're probably drinking tea and working someone else OR you've simply left
> the computer on whilst going out for the day. This, incidentally, is why I
> won't, ever, gate out raw skimmer spots to users. Speaking of which: the
> FTx skimmer network will likely do a better job than your random user
> "skimmer" so why not just connect to that instead!
>
> This person appears to have taken it upon himself (gender deliberately
> chosen) to become an FTx skimmer that gates his data out into the general
> spot pool. But he could not do this unless the CLIENT SOFTWARE he is using
> provides that facility. So the obvious solution to this is to try to
> identify the author(s) of the client software and persuade them to not
> allow this sort of thing to occur. Experience shows that authors are
> reluctant to change the behaviour of their creations (I can understand
> that) and simply ignore requests for changes from "outside" their user
> communities. It probably takes at least 15 years of full time professional
> programming before one truly believes that all software has bugs, or
> undesirable behaviours that have been discovered by users that require
> changes. Unfortunately many authors are hobby programmers and resistant to
> external pressure for change. Probably, because their software is written
> in a way that makes it too difficult to change. I remember that :-)
>
> As I have been writing this, I am starting to get a bit annoyed by the
> thoughtlessness of some authors and users. So I will implement an linearly
> increasing IP address ban time, together with message on login (with a
> fixed delay of say 10 secs before forced disconnect) saying something like
> "You are sending too many commands too quickly, you are banned from
> reconnecting until <date/time>". Obviously if they reconnect and do it
> again (within some interval) they will be have more time added - and -
> "good behaviour" over a period of time will reduce their penalty ban time.
>
> Your thoughts and suggestions for default values for these times /
> intervals will be gratefully received.
>
> 73 Dirk G1TLH
>
> On 21/01/2025 21:31, IZ2LSC via Dxspider-support wrote:
>
> I know there is the following knob, but if the originating node is not up
> to date (or is not a spider), then the flood is sent into the network.
>
>    Added cmd entry rate limiting. If a user sends X commmands in Y secs
> then
>    they are disconnected without notice. The defaults are X
>    ($DXCommandmode::maxcmdcount) = 16 and Y ($DXCommandmode::cmdinterval)
> = 9.
>
>
> Andrea, IZ2LSC
>
> -->
>
>
> On Tue, Jan 21, 2025 at 10:07 PM <ea3cv at cronux.net> wrote:
>
>> The only thing I can think of is to treat spotter+time as a duplicate
>> variant within a 1s window.
>> I don't know if Dirk has something implemented.
>> I'll look tomorrow, I'm curious.
>>
>> Kin
>>
>>
>> Enviado desde Outlook para Android <https://aka.ms/AAb9ysg>
>>
>> ------------------------------
>> *De:* Dxspider-support <dxspider-support-bounces at tobit.co.uk> en nombre
>> de IZ2LSC via Dxspider-support <dxspider-support at tobit.co.uk>
>> *Enviado:* martes, enero 21, 2025 9:30:48 p. m.
>> *Para:* The DXSpider Support list <dxspider-support at tobit.co.uk>
>> *CC:* IZ2LSC <iz2lsc.andrea at gmail.com>
>> *Asunto:* [Dxspider-support] Fwd: Max Spot per Minute (how to avoid
>> flooding)
>>
>> Hi sysops!
>> I was reviewing my cluster stats when I noticed this spike in spot per
>> minute (see attached image).
>>
>> [image: immagine.png]
>>
>>
>> Looking at the logs I can see a flood of 55 spots coming in the same
>> second from the same user, an extract below:
>>
>>
>> 7074.4^DH2YBG^1737474360^FT8^KC9LFD^32^226^DB0ERF-5^28^14^8^4^^^204.93.149.214
>>
>> 7074.4^GM6URC^1737474360^FT8^KC9LFD^65^226^DB0ERF-5^27^14^8^4^^^204.93.149.214
>>
>> 7074.4^N5TLH^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^7^4^8^4^^^204.93.149.214
>>
>> 7074.4^LA8ENA^1737474360^FT8^KC9LFD^123^226^DB0ERF-5^18^14^8^4^^^204.93.149.214
>>
>> 7074.4^P40AA^1737474360^FT8^KC9LFD^326^226^DB0ERF-5^11^9^8^4^^^204.93.149.214
>>
>> 7074.4^F5SJF^1737474360^FT8^KC9LFD^42^226^DB0ERF-5^27^14^8^4^^^204.93.149.214
>>
>> 7074.4^VK2WN^1737474360^FT8^KC9LFD^198^226^DB0ERF-5^59^30^8^4^^^204.93.149.214
>>
>> 7074.4^N1UL^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^8^5^8^4^^^204.93.149.214
>>
>> 7074.4^KA9SOG^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^8^4^8^4^^^204.93.149.214
>>
>> 7074.4^VK3YW^1737474360^FT8^KC9LFD^198^226^DB0ERF-5^59^30^8^4^^^204.93.149.214
>>
>> 7074.4^N9IBM^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^8^4^8^4^^^204.93.149.214
>>
>> 7074.4^W5ORC^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^8^5^8^4^^^204.93.149.214
>>
>> 7074.4^KP2BH^1737474360^FT8^KC9LFD^119^226^DB0ERF-5^11^8^8^4^^^204.93.149.214
>>
>> 3573.4^K8CW^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^8^4^8^4^^^204.93.149.214
>>
>> 3573.4^P40AA^1737474360^FT8^KC9LFD^326^226^DB0ERF-5^11^9^8^4^^^204.93.149.214
>>
>> 3573.4^K1TAP^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^8^5^8^4^^^204.93.149.214
>>
>>
>> Is there a way to activate a sort of flooding protection?
>>
>>
>> Thanks and 73
>>
>>
>> Andrea, IZ2LSC
>>
>>
>>
> _______________________________________________
> Dxspider-support mailing listDxspider-support at tobit.co.ukhttps://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20250125/f5326e62/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: immagine.png
Type: image/png
Size: 33364 bytes
Desc: not available
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20250125/f5326e62/attachment-0001.png>