Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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?
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...
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.