Don Y <blockedofcourse@foo.invalid> wrote:

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

Can you actually do that, with a standard server? Normally every
TCP/IP packet is acked. This is deep in the system.

UDP isn't, which is why port knocking works so well.

On 3/14/2024 9:26 PM, Don Y wrote:
> On 3/14/2024 2:37 PM, bitrex wrote:
>> Maybe consider hosting the web server yourself, using a virtual
>> machine/Promox as the host and a Cloudflare tunnel for security:
>
> The advantage is that you can institute whatever policies you want.
> The DISadvantage is that YOU have to implement those policies!
>
> And, nothing prevents your site from being targeted for a [D]DoS
> attack, etc.  Or, any other behavior that increases the cost to
> you (in terms of your effort or servicing/hosting fees from
> provider(s).
>
> It's often easier (less hassle) to just avail yourself of some
> free service to host the content and let THEM worry about
> these issues.  (unless you enjoy dicking with this sort of thing)
>
>

OK, don't have to self-host. There are possible privacy/security
concerns using Cloudflare for private data/WAN applications but for
public-facing generally static web pages it seems like a no-brainer,
they have pretty generous free plans.

On 3/15/2024 8:56 AM, Peter wrote:
>
> Don Y <blockedofcourse@foo.invalid> wrote:
>
>> Then, DON'T acknowledge the packet. Pretend the network
>> cable is terminated in dead air.
>
> 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.

[And, you can't have an active proxy upstream that blindly
intercepts them]

The server effectively does a passive open and waits for
packets ON *ANY* PORT. You obviously have to hide ALL
ports as a potential client could poke ANY port, notice a
response, then assume you are *deliberately* hiding OTHER ports
that don't reply! If you reply ANYWHERE, then the "adversary"
knows that you aren't just a "dangling wire"!

Think of an old-fashioned RdTd serial port (no handshaking lines
that you can examine as "active"). You can listen to incoming
character stream without ever responding to it -- even allowing
your driver to lose characters to overrun/parity/framing/etc. errors.

Only when you see something that you recognize do you "react".

[This is the easy way to hide an "internal" 3-pin serial port
(that you likely have for diagnostics in a product) from folks
who like looking for shells, etc. on such things!]

Of course, if something (adversary or sniffer) sees that reaction,
then the secret is out. So, you don't want to abuse this access
mechanism.

It's like tunneling under some existing protocol; it works
only as long as folks don't *notice* it!

> UDP isn't, which is why port knocking works so well.

Anything that can be routed can be used. You can knock
on UDP/x, then UDP/y, then... before trying to open a
particular UDP/TCP connection. The point is to just LOOK
at incoming packets and not blindly act on them -- even
if that action is to block the connection.

On 3/15/2024 9:05 AM, bitrex wrote:
> On 3/14/2024 9:26 PM, Don Y wrote:
>> On 3/14/2024 2:37 PM, bitrex wrote:
>>> Maybe consider hosting the web server yourself, using a virtual
>>> machine/Promox as the host and a Cloudflare tunnel for security:
>>
>> The advantage is that you can institute whatever policies you want.
>> The DISadvantage is that YOU have to implement those policies!
>>
>> And, nothing prevents your site from being targeted for a [D]DoS
>> attack, etc.  Or, any other behavior that increases the cost to
>> you (in terms of your effort or servicing/hosting fees from
>> provider(s).
>>
>> It's often easier (less hassle) to just avail yourself of some
>> free service to host the content and let THEM worry about
>> these issues.  (unless you enjoy dicking with this sort of thing)
>
> OK, don't have to self-host. There are possible privacy/security concerns using
> Cloudflare for private data/WAN applications but for public-facing generally
> static web pages it seems like a no-brainer, they have pretty generous free plans.

IME, most of these efforts are just a shitload of unplanned effort,
that you (later) discover. And, are under some (self-imposed?) pressure
to keep running ASAP.

[I *really* don't like something imposing a timing constraint on my
actions. "Your site is down!" "Yeah. And?"]

On 3/15/2024 8:55 AM, Peter wrote:
>
> "Carlos E.R." <robin_listas@es.invalid> wrote:
>
>>> Port knocking ;)
>>
>> I was thinking of using a high port. I do that.
>
> The sniffer will find any port # in a few more seconds...

Point a nessus daemon at yourself and see what it finds.

GRC.com offers some (less exhaustive) on-line tools...

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.

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]

On 2024-03-15 16:55, Peter wrote:
>
> "Carlos E.R." <robin_listas@es.invalid> wrote:
>
>>> Port knocking ;)
>>
>> I was thinking of using a high port. I do that.
>
> The sniffer will find any port # in a few more seconds...

Actually it takes longer than that. So far, no hits; and I would notice
when someone tries to login on ssh.

Of course, one can defend the fort from casual attackers, not from
determined attackers; those will eventually find a way.

--
Cheers, Carlos.

On 3/20/2024 8:03 AM, Carlos E.R. wrote:
> On 2024-03-15 16:55, Peter wrote:
>>
>>   "Carlos E.R." <robin_listas@es.invalid> wrote:
>>
>>>> Port knocking ;)
>>>
>>> I was thinking of using a high port. I do that.
>>
>> The sniffer will find any port # in a few more seconds...
>
> Actually it takes longer than that. So far, no hits; and I would notice when
> someone tries to login on ssh.

Why would an attacker try to breach a secure protocol -- hoping
you have enabled it without any protections??

A port scanner just needs to see if it gets a response from
a particular port, not whether or not it can invoke a particular
protocol on that port. Even "refusing the connection" tells the
scanner that there is a host at that IP.

Simple exercise: go to another host and just TRY to open a
connection to port 22 (sshd) or 23 (telnetd). Don't try to
login. What do you see on the server concerning this
activity?

You can learn a lot about the host, OS, etc. just from watching how
it reacts to connections and connection attempts (e.g., how it
assigns sequence numbers, which ports are open "by default", etc.)

> Of course, one can defend the fort from casual attackers, not from determined
> attackers; those will eventually find a way.

Only if they sense potential value beyond what they can get
for less effort, elsewhere. With all of the casual hosts out there,
(especially those folks who don't realize their security risks)
its silly to waste resources trying to get to one that poses any
sort of obstacle.

And, if you don't KNOW that there is a machine at that IP, then
what's your attack strategy? Just push packets down a black hole
and *hope* there is something there, listening (but ignoring)?

What do you do if I just hammer away at your IP even KNOWING that
you've got all your ports closed? Any *legitimate* traffic
can't get through (including replies to your outbound requests)
because I am saturating your pipe. What can you do to *stop* me
from doing this?

[The same sort of logic applies to "hidden" diagnostic ports
in devices. If I keep pushing bytes into a "debug" UART, I
consume system resources at a rate that *I* control. Was your
firmware designed to handle this possibility? Or, did you
assume only "authorized technicians" would use said port and
only in benevolent ways?]