Deutsch English Français Italiano |
<utet8h$1honb$3@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Don Y <blockedofcourse@foo.invalid> Newsgroups: sci.electronics.design Subject: Re: Chinese downloads overloading my website Date: Wed, 20 Mar 2024 07:52:59 -0700 Organization: A noiseless patient Spider Lines: 60 Message-ID: <utet8h$1honb$3@dont-email.me> References: <usjiog$15kaq$1@solani.org> <t7rrui5ohh07vlvn5vnl277eec6bmvo4p9@4ax.com> <usm6v6$17e2c$1@solani.org> <gabuui56k0fn9iovps09um30lhiqhvc61t@4ax.com> <usqjih$h74g$1@dont-email.me> <afq1viha37gjs37sprgfb30dfm0m1ok5jh@4ax.com> <ustdn0$176f7$1@dont-email.me> <usv8fu$1nhtm$1@dont-email.me> <usvu8g$1slrq$2@dont-email.me> <ut1bm8$28gvp$1@dont-email.me> <gsrdckxea6.ln2@Telcontar.valinor> <ut1gpg$29itn$2@dont-email.me> <ut1r44$2bmvo$3@dont-email.me> <ut29n3$2epl6$2@dont-email.me> <utei5t$1fej6$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 20 Mar 2024 14:53:05 -0000 (UTC) Injection-Info: dont-email.me; posting-host="d6fdbaa94c63f1c94d0dc6aeabf5edd0"; logging-data="1630955"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+2k+/yT0m5YFiF3z7cHiJB" User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Cancel-Lock: sha1:RDg9GRKQdLKRkHF4ycc0aiHn/GE= Content-Language: en-US In-Reply-To: <utei5t$1fej6$1@dont-email.me> Bytes: 3976 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]