Assume our WebApp (any platform) is running on Linux (any distro).

Problem: WebApp is logging an insane number requests that contain invalid but encrypted session data.

1. Each nefarious client request invokes a server-side decryption that consumes valuable CPU time - How can we throttle the decryptions so that our WebApp (or Linux utils) can successfully execute the tasks below?

2. The WebApp reads HTTPS headers and associates the bad session data with one (or more) client IP Address (hopefully not 0.0.0.0) - Can this information be trusted? What can a WebApp log that would enable various Linux utils to positively identify the bad agent?

3. The WebApp (or Linux utils) then instruct IPTABLES to DROP incoming packets from the suspect IP Address - Will this happen quickly enough?

4. When changed IPTABLES takes effect, what happens to the many nefarious packets that have already entered the TCP stack?

5. Most users connect via NAT, Proxy, or Tor such that blocking one IP Address could affect many users - What alternative identifier is available?

1. possibly use renice to temporarily lower WebApp priority when it is under attack?

2. http-headers are designed to be rewritten (i.e. that is exactly how proxy servers work) so are inherently untrusted; but the original tcp handshake does not lie. WebApp could flag the miscreant's traffic with a plain/text header (i.e. X-MISCREANT=TRUE); then separately all outbound tcp traffic can be piped through openssl | tcpdump | grep to expose the miscreant's true IP address - what about Q5?

3. To achieve fast atomic rule updates, replace IPTABLES with NFTABLES - but before that: Should another util continually analyse many rows of naïve WebApp logging (slow); Should the WebApp output a single message that initiates the rule update (one app performing many tasks?); or perhaps the third way outlined in 2?

4. ...?

5. Reusing 2, instead of capturing the IP address, capture the entire TCP payload and (includes Proxy forwarding headers) and match the identifying strings in future packets - not sure if NFTABLES is built for this kind of work?

Having isolated the miscreant's network traffic, is it better to block their packets from only your network, or nuke their machine for wider social good?

Don't give details, what would be the overview to nuke a machine?

The requesting entity implicitly trusts the server and invites it to deposit an unknown payload. The attacking client machine has made a request from the server, without controlling TCP/IP stack behaviour, and without knowing in advance what the server will send back...

Hmmm..wow..thank you for the idea.

I'll create one hahaha, is there an opensource one that does this kind of thing.