Path: ...!weretis.net!feeder8.news.weretis.net!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: Fri, 15 Mar 2024 06:00:23 -0700
Organization: A noiseless patient Spider
Lines: 67
Message-ID: <ut1gpg$29itn$2@dont-email.me>
References: <7qujui58fjds1isls4ohpcnp5d7dt20ggk@4ax.com>
 <6lekuihu1heui4th3ogtnqk9ph8msobmj3@4ax.com> <usec35$130bu$1@solani.org>
 <u14quid1e74r81n0ajol0quthaumsd65md@4ax.com> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 15 Mar 2024 13:00:33 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="c86af28dc75bef790d14c8cfb4054056";
	logging-data="2411447"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19tuXS02E/Ky76pXmkttZ5F"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:t9V85b2MKkb1dgqAjyGPCD/loJQ=
Content-Language: en-US
In-Reply-To: <gsrdckxea6.ln2@Telcontar.valinor>
Bytes: 3971

On 3/15/2024 5:34 AM, Carlos E.R. wrote:
> On 2024-03-15 12:33, Peter wrote:
>>
>>   Don Y <blockedofcourse@foo.invalid> wrote:
>>
>>> I operate a server in stealth mode; it won't show up on
>>> network probes so robots/adversaries just skip over the
>>> IP and move on to others.  Folks who *should* be able to
>>> access it know how to "get its attention".
> 
> What is "stealth mode", what do you do?

It's what you *don't* do that is important.

When you receive a packet, you extract all of the
information indicating sender, intended destination
port, payload, etc.

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

The *determined* "caller" sends another packet, some time later
(with limits on how soon/late this can be).

Again, you extract the information in the packet -- and
ignore it.

Repeat this some number of times for a variety of
different ports, payloads -- all traced back to the
same sender.

Then, on the *important* packet that arrives, subsequently,
acknowledge it with the service that is desired.

If the sequence is botched at any time -- like a sender doing
a sequential port scan -- then you reset the DFA that is
tracking THAT sender's progress through the automaton.

Note that you can handle multiple clients attempting to
connect simultaneously -- "hiding" from each of them
until and unless they complete their required sequences.

Anyone with a packet sniffer can be thwarted by ensuring
that the sequence is related to source IP, time of day,
service desired, etc.  (though security by obscurity)

Because you don't react to most (all?) packets, a systematic
probe of your IP will not turn up a "live machine" at your
end.

Once you actually acknowledge a packet, all of the
regular authentication/encryption/etc. mechanisms come
into play.  You just don't want to reveal your presence
unless you are reasonably sure the client is someone
that you *want* to have access...

>> Port knocking ;)
> 
> I was thinking of using a high port. I do that.

But a port scanner can stumble on that.  Or, it can be leaked
by a malevolent user.

The "knock sequence" can be customized per sender IP address,
per client identity, per service, etc.  So, it's less vulnerable
than something (anything!) static.