Le 13/06/2021 à 19:55, William Unruh a écrit :
> On 2021-06-13, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
>> Le 12/06/2021 à 19:12, Grant Taylor a écrit :
>>> On 6/12/21 3:16 AM, Pascal Hambourg wrote:
>>>> Granularity is one single address.
>>>
>>> Okay.
>>>
>>> The next (snarky) question is how many of those fine granular single
>>> addresses do you want to support.  Supporting a few networks of that and
>>> lumping the rest could be done.
>>
>> Supporting a few networks only has been out of the scope from the
>> beginning of this thread. The OP wrote "no matter where the laptop may
>> be", which means from ANY assigned public unicast address.
>
> Except that each of those does not need individual attention. You can
> just lump them together.

Of course it does. You don't want to allow your "neigbour" which is
eavesdropping on your traffic to replay the port knocking sequence you
just sent.

> Of course that opens you up to ssh attacks so
> you need something else (eg port knocking)

This is exactly what we are discussing in that part of the thread : port
knocking implemented with iptables as someone suggested.

>> Scalability makes its tecnhically possible - or not. Even the simplest
>> port knocking algorithm (one packet) requires at least two iptables
>> rules per address, so it accounts for about 8 billion rules. Even if
> Why? you can have one rule for a range of addresses.

No, you need different one rule per single address to prevent port
knocking replay.

On 6/14/21 8:29 AM, Pascal Hambourg wrote:
> You are right. I have always used the recent match in pairs and did not
> think that one rule could be shared.

;-)

> You are right again, only 4 billion rules (one per address). A bit less
> if you remove the reserved ranges (multicast, private...) but that's
> still the order of magnitude.

I largely agree. (I'll reply to your reply to William in more details.)

> In an attempt to gather real figures, I did some tests on Debian 10
> amd64, with 8 GiB memory. iptables-nft-restore (nftables compatibility
> flavour) failed after adding ~300k rules, iptables-legacy-restore
> (original flavour) failed after adding ~1,3M rules.

Please elaborate on how you did your testing.

You say iptables-*-restore, which tells me that you were trying to read
rules and restore them as one operation. (As opposed to iptables which
is non-atomic and does a read / modify / write cycle per rule added.)

Did you create a file that was the rule set that iptables-*-restore was
reading in?

What did a rule (which I assume was the same and repeated for each
different IP) look like?

I wonder if the problem that you were running into was a problem with
the number of rules and or an issue with a part of the rule, e.g.
scalability of the recent match extension.

> The used memory was much lower than the available memory and I got
> the same results after limiting the usable memory to 2 GiB, so these
> limits do not seem memory-related.

ACK

I am both surprised and not surprised at the same time. I know that
some memory allocation is a percentage of overall system memory. Though
that may be based on a percentage of an upper bound.

> So it seems that iptables cannot hande more than 1,3M rules, which
> is very far from 4G.

I'll agree that the kernel you were booting couldn't scale anywhere near
the 4 B rules. But I wouldn't say that it's not possible based off of
one kernel. But your tests do give information where there previously
was none. (At least in this discussion.)

> I also estimated by comparison of the output of free that each rule
> consumes ~500 bytes (iptables-legacy) to ~670 bytes (iptables-nft), much
> more than I expected. So even if iptables could handle 4G rules, they
> would consume at least 2 TB of memory.

I think that 2 TB of memory is within the realm of possibility if
someone wanted to do it. Though I doubt they would do so for a firewall.

--
Grant. . . .
unix || die

On 6/14/21 8:34 AM, Pascal Hambourg wrote:
> Of course it does.

I agree with William. I don't believe that each individual source IP
needs individual port knock sequences.

> You don't want to allow your "neigbour" which is eavesdropping on
> your traffic to replay the port knocking sequence you just sent.

I don't care about my neighbor. I care about random malware not being
able to get to my SSH daemon.

There's also the fact that my neighbor - who's not on my LAN - is going
to have trouble eavesdropping on the port knock sequence.

> This is exactly what we are discussing in that part of the thread : port
> knocking implemented with iptables as someone suggested.

Which is entirely possible to do, especially with loose granularity.
I've done it multiple times.

> No, you need different one rule per single address to prevent port
> knocking replay.

Not if you don't care about knock reply.

It really depends on what you're trying to use port knocking to protect
against. If you're trying to simply reduce noise from SSH brute force
attempts, then you very likely don't care about knock reply protection.
If you're trying to protect against someone else in the coffee shop
replaying and attacking you personally, well, a port knock sequence no
matter how complex, probably won't suffice and you need a different
solution.

--
Grant. . . .
unix || die

On 2021-06-14, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
> On 6/14/21 8:34 AM, Pascal Hambourg wrote:
>> Of course it does.
>
> I agree with William. I don't believe that each individual source IP
> needs individual port knock sequences.
>
>> You don't want to allow your "neigbour" which is eavesdropping on
>> your traffic to replay the port knocking sequence you just sent.
>
> I don't care about my neighbor. I care about random malware not being
> able to get to my SSH daemon.
>
> There's also the fact that my neighbor - who's not on my LAN - is going
> to have trouble eavesdropping on the port knock sequence.
>
>> This is exactly what we are discussing in that part of the thread : port
>> knocking implemented with iptables as someone suggested.
>
> Which is entirely possible to do, especially with loose granularity.
> I've done it multiple times.
>
>> No, you need different one rule per single address to prevent port
>> knocking replay.
>
> Not if you don't care about knock reply.
>
> It really depends on what you're trying to use port knocking to protect
> against. If you're trying to simply reduce noise from SSH brute force
> attempts, then you very likely don't care about knock reply protection.
> If you're trying to protect against someone else in the coffee shop
> replaying and attacking you personally, well, a port knock sequence no
> matter how complex, probably won't suffice and you need a different
> solution.
>
>

You could also do something like. "knock on port A, where you do not
care if anyone knows port A." That triggers a subrouting on both your
travel machine and your home machine to encrypt the IP address your
remote machine and use that to determine a port number for the next
knock. Both the home machine and the touring one use the same key for
the encryption so both know, but noone else does, what the next port is
to knock at. So you then knoch on that port, and the ssh port is then
opened. (or even use that encrypted port as the ssh port). To prevent
replay, the encryption mixes the current UTC (to the nearest minute say)
time with the IP address to encrypt to find the next port. You also do
not let in another attempt on that port in that minute, to prevent
replay. Ie, if you screw up, say your ssh password at logon. You have to
wait a minute to try again, but then who says security is a free ride:-)

>

On 2021-06-14, William Unruh <unruh@invalid.ca> wrote:
> On 2021-06-14, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>> On 6/14/21 8:34 AM, Pascal Hambourg wrote:
>>> Of course it does.
>>
>> I agree with William. I don't believe that each individual source IP
>> needs individual port knock sequences.
>>
>>> You don't want to allow your "neigbour" which is eavesdropping on
>>> your traffic to replay the port knocking sequence you just sent.
>>
>> I don't care about my neighbor. I care about random malware not being
>> able to get to my SSH daemon.
>>
>> There's also the fact that my neighbor - who's not on my LAN - is going
>> to have trouble eavesdropping on the port knock sequence.
>>
>>> This is exactly what we are discussing in that part of the thread : port
>>> knocking implemented with iptables as someone suggested.
>>
>> Which is entirely possible to do, especially with loose granularity.
>> I've done it multiple times.
>>
>>> No, you need different one rule per single address to prevent port
>>> knocking replay.
>>
>> Not if you don't care about knock reply.
>>
>> It really depends on what you're trying to use port knocking to protect
>> against. If you're trying to simply reduce noise from SSH brute force
>> attempts, then you very likely don't care about knock reply protection.
>> If you're trying to protect against someone else in the coffee shop
>> replaying and attacking you personally, well, a port knock sequence no
>> matter how complex, probably won't suffice and you need a different
>> solution.
>>
>>
>
> You could also do something like. "knock on port A, where you do not
> care if anyone knows port A." That triggers a subrouting on both your
> travel machine and your home machine to encrypt the IP address your
> remote machine and use that to determine a port number for the next
> knock. Both the home machine and the touring one use the same key for
> the encryption so both know, but noone else does, what the next port is
> to knock at. So you then knoch on that port, and the ssh port is then
> opened. (or even use that encrypted port as the ssh port). To prevent
> replay, the encryption mixes the current UTC (to the nearest minute say)
> time with the IP address to encrypt to find the next port. You also do
> not let in another attempt on that port in that minute, to prevent
> replay. Ie, if you screw up, say your ssh password at logon. You have to
> wait a minute to try again, but then who says security is a free ride:-)
>
>>

So. Make sure both machines are running chrony or ntp to make sure that
both have the system time accurate to a minute say.

Port K on the home machine simply runs a little program which reflects
back the IP address that it sees coming in. That is to make sure that
you know what your own IP address is on the mobile machine. You now
concatente that IP address with the the time to the minute, hash is with
some suitable hash, encrypt it with some encryption routing and common
password and connect to the home machine on the port corresponding to
the 1000+last six bits of that encryption. Meanwhile the home machine
has done the same-- hashed the concatenationof the incoming IP with the
time to the nearest minute and encrypted it with the encryption with the
common password, and started sshd on that port. Now the remote machine
connects to that port as usual. Then sshd no longer
responds to that port. If there is a second knock on the port with on
the same date, the knock port does not respond. This means a replay will
not work. This also makes the port as secure as the two passwords (one
the knock password, and the other the ssh password).

The knock program is extremely simple, so its security can be assured
(It just listens, reflects back the incoming IP, and encrypts the
incoming IP and starts sshd on the resultant port number, and refuses to
respond to any more knocks until the minute has passed. That program
should be able to guarentee security of. Then one still has to log onto
ssh with the ssh logon security.

Then one still has the security of ssh.

On 5/30/21 10:35 AM, Marc Haber wrote:

> minute) with acceptable results and no complaints from the users.
>
> My other machines have an access list making port 22 only available
> from my own IPv6 address range.
>
> Greetings
> Marc
>

Step 1. Don't use the default port #s. That will stop a lot of drive-by
attacks that are part of automated systems.