Re: Chinese downloads overloading my website

On 3/20/2024 4:43 AM, Peter wrote:

   Don Y <blockedofcourse@foo.invalid> wrote:
 

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.

 OK, so this is very rare.

Yes.  So, sysadms aren't really looking for it or trying to
defend against it.
It's not a trivial solution as you need the skillset (as well
as access to the specific server!) to be able to, essentially,
rewrite the stack.
The easiest way to do this is to build a shim service to sit
above the NIC's IRQ as an agent; intercepting network
packets and only passing "select" ones up to the underside
of the *real*/original stack.  You would then track the
"state" of each client's "knocking" sequence so you would know
who to BLOCK and who to PASSTHRU at any given time.
And, you can apply it to all ports/protocols (an essential
requirement as you don't want ANYTHING to be visible to a probe).
The problem with this approach lies in  knowing when to
"stop" passing packets from a particular client as you
don't have an easy way of knowing that the "real"
"service" has been terminated.  This a consequence of the
monolithic nature of most kernels.
[My new OS uses an entirely different approach to the stack
so its relatively easy for me to deal with "transactions"]
The *advantage* is that you can use it to effectively tunnel
under HTTP without worrying about sysadms blocking your
specific traffic:  "Why is Bob, in accounting, trying to
send datagrams to port XYZ at DonsHouseOfMagic?"
[Very few protocols are *reliably* allowed through firewalls
without some form of caching, rescheduling, rewriting, etc.
E.g., tunneling under DNS is easily "broken" by a caching
server between the client and external agency.  And, most
can't deliver large payloads without raising suspicions!
And, remember, you can't "sort of" process the protocol
without indicating that you exist!]
OTOH, a TCP connection (HTTP on port 80) to DonsHouseOfMagic
likely wouldn't arouse any suspicion.  Nor would the payload
merit examination.  Great for slipping firmware updates through
a firewall, usage data, etc.
[HTTP/3 adds some challenges but is no worse than any other
UDP service]