Re: Chinese downloads overloading my website

On 3/15/2024 8:56 AM, Peter wrote:

   Don Y <blockedofcourse@foo.invalid> wrote:
 

Then, DON'T acknowledge the packet.  Pretend the network
cable is terminated in dead air.

 Can you actually do that, with a standard server? Normally every
TCP/IP packet is acked. This is deep in the system.

You have to rewrite your stack.  *You* have to handle raw
packets instead of letting services (or the "super server")
handle them for you.
[And, you can't have an active proxy upstream that blindly
intercepts them]
The server effectively does a passive open and waits for
packets ON *ANY* PORT.  You obviously have to hide ALL
ports as a potential client could poke ANY port, notice a
response, then assume you are *deliberately* hiding OTHER ports
that don't reply!  If you reply ANYWHERE, then the "adversary"
knows that you aren't just a "dangling wire"!
Think of an old-fashioned RdTd serial port (no handshaking lines
that you can examine as "active").  You can listen to incoming
character stream without ever responding to it -- even allowing
your driver to lose characters to overrun/parity/framing/etc. errors.
Only when you see something that you recognize do you "react".
[This is the easy way to hide an "internal" 3-pin serial port
(that you likely have for diagnostics in a product) from folks
who like looking for shells, etc. on such things!]
Of course, if something (adversary or sniffer) sees that reaction,
then the secret is out.  So, you don't want to abuse this access
mechanism.
It's like tunneling under some existing protocol; it works
only as long as folks don't *notice* it!

UDP isn't, which is why port knocking works so well.

Anything that can be routed can be used.  You can knock
on UDP/x, then UDP/y, then... before trying to open a
particular UDP/TCP connection.  The point is to just LOOK
at incoming packets and not blindly act on them -- even
if that action is to block the connection.