<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body>We can't ever stop people from being evil; we can only make it more trouble than it's worth to be evil.
<div><br></div><div>My proposal assumes throttling per connection, with a lower throttling rate for the completely compromised passcode authentication than for PKI authentication. That way, Scott's telemetry devices, which shouldn't be sending packets very fast any way (more than 1 every 10 seconds average would be excessive for that use case) would still work, while the more stringent PKI authentication (much harder to forge) would have a higher throttling threshold. </div><div><br></div><div>As for multiple attacks from different IP addresses, since only one login per callsign-SSID combination is allowed at a time, multiple IP address hacks would simply disconnect each other, and the low throttling threshold for passcode authentication would make it not worth the attacker's effort.</div><div><br></div><div>I also propose that a throttling disconnect (regardless of authentication type) should stop accepting traffic from the throttled connection for 10 seconds before sending the throttled status comment and closing the connection, thereby back-pressuring the offender when it fills up its TCP buffer window (alternatively, the traffic could be read and discarded, so the attacker doesn't get advance notice of the throttling. Also, reconnects from a throttled IP address or callsign-SSID should be rejected for at least 30 seconds.</div><div><br></div><div>This shouldn't affect any _legitimate_ APRS-IS user, except for those whose callsigns are being forged by the attackers (much like forged caller-ID with illegal telemarketing). Such poor victims may have trouble getting in until the attacker moves on to another callsign.</div><div><br></div><div>We do need to arrange a more global PKI authentication scheme, but any multi-authority system would have to have a means of ensuring that compromised PKI could be revoked (but only by the victim, not by the attacker), and that attackers could not be issued PKI authentication.</div><div><br></div><div>Andrew, KA2DDO</div><div><br></div><br><br>-------- Original message --------<br>From: Patrick <winston@winston1.net> <br>Date: 9/7/20 18:06 (GMT-05:00) <br>To: Nick VA3NNW <tapr@noseynick.com> <br>Cc: TAPR APRS Mailing List <aprssig@lists.tapr.org> <br>Subject: Re: [aprssig] aprsis DOS in Poland, observation <br><br><div><div>It's not about what you personally have with current dos techniques, it's about exploiting other people who are unaware and often doing something else.. Picture it being run as a browser based JavaScript client, either as a direct IP client or easier to exploit might be <span style="font-family:sans-serif">for servers which support http send ports, because you could then exploit them through an ajax style query which is basic dynamic web programming these days.</span> In either case you would have random people sending packets just from viewing a webpage, and using a thirst trap of some porn images it would be easy to get lots of those happening. </div><div dir="auto"><br></div><div dir="auto">p<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Mon., Sep. 7, 2020, 5:29 p.m. Nick VA3NNW, <<a href="mailto:tapr@noseynick.com">tapr@noseynick.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Hessu mentioned this already, but rate limits may protect against an <br>
> accidental situation... but even forcing things right down to 2 <br>
> packets per second as mused by Curt, 1500 - 2000 packets per second <br>
> can be done with 750-1000 clients which can be done with unique IPs <br>
> pretty easily meaning there is no way to block it if done on purpose.<br>
<br>
If someone has access to 1000 IPs... are these in the same subnet (which <br>
could be given an aggregated token-bucket of uplink bandwidth), or do <br>
they already have a botnet that can already DDoS almost anything?<br>
<br>
-- <br>
"Nosey" Nick Waterman, VA3NNW/G7RZQ, K2 #5209.<br>
use Std::Disclaimer; <a href="mailto:sig@noseynick.net" target="_blank" rel="noreferrer">sig@noseynick.net</a><br>
Modem: How a Southerner asks for seconds...<br>
<br>
<br>
_______________________________________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@lists.tapr.org" target="_blank" rel="noreferrer">aprssig@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" rel="noreferrer noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br>
</blockquote></div></div></div>
</body></html>