Connecting to an SSH server from the external world

[John Smith]

I have the following problem:

I would like to be able to connect from my laptop to my SSH
server in my internal network, no matter where the laptop may be.
However, my SSH server accepts connections from specific IP addresses -
those to do with work - and rejects all others.

The problem is that I will often try to connect from my laptop
when it is using an Internet feed that is not the one at work. Is there
anything I can do at the laptop so that when it tries to connect to my
SSH server, the connection will be accepted?

The obvious solution would be to have an SSH server listening on
a non-standard port, for this specific purpose. However, I would prefer
to use a solution that requires no changes in my SSH server - only in the
client in my laptop. Any ideas?

[William Unruh]

On 2021-05-28, John Smith <12...@whatismyemailaddress.xyz> wrote:
> I have the following problem:
>
> I would like to be able to connect from my laptop to my SSH
> server in my internal network, no matter where the laptop may be.
> However, my SSH server accepts connections from specific IP addresses -
> those to do with work - and rejects all others.

Lets see, that ssh server (Is it really yours-- ie do you own it-- or is
it your company's) has security on it to only accept connections from
the company network and you want instead to connect from anywhere, which
means that anyone can connect from anywhere.
Remove the condition that ssh can only connect from work IP
addresses. Or would this be against company policy?

[Grant Taylor]

On 5/28/21 3:31 PM, John Smith wrote:
> I would like to be able to connect from my laptop to my SSH server
> in my internal network, no matter where the laptop may be. However,
> my SSH server accepts connections from specific IP addresses - those
> to do with work - and rejects all others.

I can't tell if the enforcement / filtering of specific IP addresses is
done on the SSH server and / or something between the SSH server and the
Internet.

Is the SSH server running on the router or something downstream / inside
of the router?

> The problem is that I will often try to connect from my laptop when
> it is using an Internet feed that is not the one at work. Is there
> anything I can do at the laptop so that when it tries to connect to
> my SSH server, the connection will be accepted?

You're asking if there is something that a client can do to defeat the
security that a server has in place. I would certainly hop not.

That being said, you can probably make some minor modifications to your
server and your client to allow them to talk.

You can probably also ssh from your client to a work system and then ssh
from there to your home system so that your home system sees your work
IP and allows the connection with the existing filtering / enforcement.

> The obvious solution would be to have an SSH server listening on
> a non-standard port, for this specific purpose.

Obscurity is not security in and of itself. Many things will find SSH
servers on alternate ports on the Internet.

> However, I would prefer to use a solution that requires no changes
> in my SSH server - only in the client in my laptop. Any ideas?

You really want something that requires you make a change, likely small,
to the ssh server and / or router connecting it to the Internet. Then
you make a similar change to your client to dock with the ssh server.

Port knocking and VPNs come to mind.

One thing that comes to mind is making your ssh server available via a
Tor hidden service (with strict security requirements. Tor has the
advantage of being able to reach out to systems on the Internet and
rondevu without needing to poke holes in firewalls.

I'm sure that there are other VPNs that can do similar. I'm just not
familiar with them.

You can also make changes your ssh server / router that it's behind to
enable the client to connect and communicate with some form of
authentication. This is also frequently the realm of VPN / port
knocking / single packet authorization.

But you *REALLY* want to have to do /something/ on the SSH server /
router to say that clients with a very specific behavior are allowed in.
If clients could make a change and bypass your security without the
SSH server / router blessing it ... that would be a security fail.



--
Grant. . . .
unix || die

[Henning Hucke]

On 2021-05-28, John Smith <12...@whatismyemailaddress.xyz> wrote:

Hi John (Yeah! "John" is certainly your name. Isn't it?).

> I have the following problem:

Ever heard about port knock client and server?

You would have to install a knockd on you server and use a knock client
on your laptop. This way you explicitly open your firewall for a short
period to establish a connection and then close it again.

Best regards.
--
Can't open /usr/fortunes. Lid stuck on cookie jar.

[Richard Kettlewell]

John Smith <12...@whatismyemailaddress.xyz> writes:
> I have the following problem:
>
> I would like to be able to connect from my laptop to my SSH
> server in my internal network, no matter where the laptop may be.
> However, my SSH server accepts connections from specific IP addresses -
> those to do with work - and rejects all others.

The solution is to remove this restriction.

> The problem is that I will often try to connect from my laptop
> when it is using an Internet feed that is not the one at work. Is there
> anything I can do at the laptop so that when it tries to connect to my
> SSH server, the connection will be accepted?

SSH from the laptop to work, if that’s allowed, and within that SSH from
work to your internal network.

Otherwise, no, there’s nothing you can do with the laptop alone.

--
https://www.greenend.org.uk/rjk/

[Giovanni]

On 05/28/2021 11:31 PM, John Smith wrote:

> The problem is that I will often try to connect from my laptop when
> it is using an Internet feed that is not the one at work. Is there
> anything I can do at the laptop so that when it tries to connect to
> my SSH server, the connection will be accepted?

To overcome this problem I installed openvpn both in the server and on
several clients. Each user has his own certificate and as long You
start the private connection You will be able to connect via ssh from
anywhere.

Ciao
Giovanni
--
A computer is like an air conditioner,
it stops working when you open Windows.
< http://giovanni.homelinux.net/ >

[John Smith]

On Fri, 28 May 2021 22:28:22 +0000, William Unruh wrote:

> On 2021-05-28, John Smith <12...@whatismyemailaddress.xyz> wrote:
>> I have the following problem:
>>
>> I would like to be able to connect from my laptop to my SSH
>> server in my internal network, no matter where the laptop may be.
>> However, my SSH server accepts connections from specific IP addresses -
>> those to do with work - and rejects all others.
>
> Lets see, that ssh server (Is it really yours-- ie do you own it-- or is
> it your company's) has security on it to only accept connections from
> the company network and you want instead to connect from anywhere, which
> means that anyone can connect from anywhere.
> Remove the condition that ssh can only connect from work IP
> addresses. Or would this be against company policy?

The server is my own - I can modify it as I wish.

What I am asking is whether things could be arranged so that
specific clients - as in running on specific hardware - could connect
from anywhere, whereas any other clients cannot, unless they come from
specific IP addresses. I guess that ome could use the client's MAC
address, but I don't know how.

[John Smith]

On Fri, 28 May 2021 16:36:03 -0600, Grant Taylor wrote:

> On 5/28/21 3:31 PM, John Smith wrote:
>> I would like to be able to connect from my laptop to my SSH server in
>> my internal network, no matter where the laptop may be. However,
>> my SSH server accepts connections from specific IP addresses - those to
>> do with work - and rejects all others.
>
> I can't tell if the enforcement / filtering of specific IP addresses is
> done on the SSH server and / or something between the SSH server and the
> Internet.
>
> Is the SSH server running on the router or something downstream / inside
> of the router?

Downstream. The router just forwards connections on port 22 to
the appropriate system in my network.

>> The problem is that I will often try to connect from my laptop when it
>> is using an Internet feed that is not the one at work. Is there
>> anything I can do at the laptop so that when it tries to connect to my
>> SSH server, the connection will be accepted?
>
> You're asking if there is something that a client can do to defeat the
> security that a server has in place. I would certainly hop not.

What I am asking is whether the server could allow connections in
selectively on the basis of some piece of information unique to hardware
that the client is running on - like e.g. its MAC address.

[Pascal Hambourg]

Le 29/05/2021 à 16:38, John Smith a écrit :
>
> I guess that ome could use the client's MAC address

No. A MAC address can be forged easily and is visible only on the same
LAN, not across an internet.

[William Unruh]

On 2021-05-29, John Smith <12...@whatismyemailaddress.xyz> wrote:
> On Fri, 28 May 2021 22:28:22 +0000, William Unruh wrote:
>
>> On 2021-05-28, John Smith <12...@whatismyemailaddress.xyz> wrote:
>>> I have the following problem:
>>>
>>> I would like to be able to connect from my laptop to my SSH
>>> server in my internal network, no matter where the laptop may be.
>>> However, my SSH server accepts connections from specific IP addresses -
>>> those to do with work - and rejects all others.
>>
>> Lets see, that ssh server (Is it really yours-- ie do you own it-- or is
>> it your company's) has security on it to only accept connections from
>> the company network and you want instead to connect from anywhere, which
>> means that anyone can connect from anywhere.
>> Remove the condition that ssh can only connect from work IP
>> addresses. Or would this be against company policy?
>
> The server is my own - I can modify it as I wish.
>
> What I am asking is whether things could be arranged so that
> specific clients - as in running on specific hardware - could connect
> from anywhere, whereas any other clients cannot, unless they come from
> specific IP addresses. I guess that ome could use the client's MAC
> address, but I don't know how.

None of that information is transmitted in trying to set up the
connection. It would be insecue to do so, handing out far too much
information to the whole world. As has been mentioned you could try port
knocking-- still not terribly secure but it depends on the level of
aversary you are protecting from. You could also just change your ssh
port number since most ssh attacks use the standard ssh ports.

[John Smith]

Yes, if that information is transferred in the clear then this
approach would be a no-no. Thanks.

[Marc Haber]

John Smith <12...@whatismyemailaddress.xyz> wrote:
>What I am asking is whether the server could allow connections in
>selectively on the basis of some piece of information unique to hardware
>that the client is running on - like e.g. its MAC address.

Without tinkering, and at your level of knowlegde, no. Those people
who would be able to do that would probably need to modify the server,
and would probably refrain from building such a construction for good
reasons.

Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Marc Haber]

Giovanni <lso...@home.net.it> wrote:
>On 05/28/2021 11:31 PM, John Smith wrote:
>
>> The problem is that I will often try to connect from my laptop when
>> it is using an Internet feed that is not the one at work. Is there
>> anything I can do at the laptop so that when it tries to connect to
>> my SSH server, the connection will be accepted?
>
>To overcome this problem I installed openvpn both in the server and on
>several clients. Each user has his own certificate and as long You
>start the private connection You will be able to connect via ssh from
>anywhere.

This is actually no better than having the ssh server accessible from
the Outside. Just the keys are longer

[Giovanni]

On 05/29/2021 06:44 PM, Marc Haber wrote:

>> To overcome this problem I installed openvpn both in the server and
>> on several clients. Each user has his own certificate and as long
>> You start the private connection You will be able to connect via
>> ssh from anywhere.

> This is actually no better than having the ssh server accessible
> from the Outside. Just the keys are longer

The OP said that he wants access only from authorized IP addresses but
he gets locked out if he uses foreign IP. That was exactly my problem
when trying to access my network when I was traveling.

Well maybe a VPN isn't more secure than SSH, but while I see lots of
failed attempts on the ssh port, there are very few on the VPN port.
And when I connect the VPN I use SSH to login.

[William Unruh]

On 2021-05-29, Giovanni <lso...@home.net.it> wrote:
> On 05/29/2021 06:44 PM, Marc Haber wrote:
>
>>> To overcome this problem I installed openvpn both in the server and
>>> on several clients. Each user has his own certificate and as long
>>> You start the private connection You will be able to connect via
>>> ssh from anywhere.
>
>> This is actually no better than having the ssh server accessible
>> from the Outside. Just the keys are longer
>
> The OP said that he wants access only from authorized IP addresses but
> he gets locked out if he uses foreign IP. That was exactly my problem
> when trying to access my network when I was traveling.
>
> Well maybe a VPN isn't more secure than SSH, but while I see lots of
> failed attempts on the ssh port, there are very few on the VPN port.
> And when I connect the VPN I use SSH to login.

Theeasiest way to get rid of the vast majority of ssh attacks isto
simply put it on a different port. And setop your ssh_config to connect
to that host on that port.
Host donaldduck*
Port 11823
>
> Ciao
> Giovanni

[Carlos E.R.]

On 28/05/2021 23.31, John Smith wrote:
> I have the following problem:
>
> I would like to be able to connect from my laptop to my SSH
> server in my internal network, no matter where the laptop may be.
> However, my SSH server accepts connections from specific IP addresses -
> those to do with work - and rejects all others.

Remove this restriction, as you control the server, and instead have the
server listen to some high port (not 50000, that one is common), and use
public key certificates, disabling password login. This is what most
people do and it works.

As an added security, you could do some port knocking.


You might hire an VPN, and connect via it, if you tell the server to
accept that VPN address. Provided you are sure the VPN will never change.

However, if someone wants to attack you, they will see established
connections from those addresses, while other addresses fail fast; thus
they will figure out that they have to "fake" those IP addresses to
connect to your server.

--
Cheers, Carlos.

[Roger Blake]

On 2021-05-29, William Unruh <un...@invalid.ca> wrote:
> Theeasiest way to get rid of the vast majority of ssh attacks isto
> simply put it on a different port. And setop your ssh_config to connect
> to that host on that port.

Also set up for key-based login only to prevent brute-force password
attacks from going anywhere, and use the firewall to limit the number
of connection attempts permitted per minute.

--
------------------------------------------------------------------------------
Roger Blake (Posts from Google Groups killfiled due to excess spam.)

18 Reasons I won't be vaccinated -- https://tinyurl.com/ebty2dx3
Covid vaccines: experimental biology -- https://tinyurl.com/57mncfm5
The fraud of "Climate Change" -- https://RealClimateScience.com
Don't talk to cops! -- https://DontTalkToCops.com
------------------------------------------------------------------------------

[Grant Taylor]

On 5/29/21 8:42 AM, John Smith wrote:
> Downstream. The router just forwards connections on port 22 to the
> appropriate system in my network.

Is the router forwarding /all/ connections to the system in your
network? Or is it only forwarding /some/ /specific/ source IPs?

If it is, or could be made to be, forwarding /all/ connections, then you
can have filtering logic on the system in your network.

> What I am asking is whether the server could allow connections in
> selectively on the basis of some piece of information unique to
> hardware that the client is running on - like e.g. its MAC address.

MAC addresses as they are normally used don't traverse routers.

I would strongly advocate for SSH keys. Or better would be SSH
certificates. The client must present a client certificate to the SSH
server that the SSH server trusts. (This is in addition to normal
account requirements like ~/.ssh/known_hosts.) Though these rely on the
security of the SSH server and it needs to be exposed to the Internet to
allow incoming connections from anywhere.

I would suggest a VPN of some sort; IPsec, OpenVPN, or WireGuard,
between clients and your router. Your router could be configured to
allow SSH traffic from VPN(s) in to the server on your network while
blocking SSH traffic that didn't come through a VPN. This has the
advantage of only needing to expose the SSH server to clients that have
valid VPN connections, meaning people you likely trust.

[Grant Taylor]

On 5/29/21 12:21 PM, William Unruh wrote:
> Theeasiest way to get rid of the vast majority of ssh attacks isto
> simply put it on a different port.

The operative phrase is "the vast majority". There will still be plenty
of attacks even on non-standard port.

Obscurity, by itself, is not security.

Obscurity can be one of many layers of a security solution.

> And setop your ssh_config to connect to that host on that port.

I absolutely endorse the /client/ ssh configuration files, either
individual (~/.ssh/config) or system wide (/etc/ssh/ssh_config).

[Grant Taylor]

On 5/29/21 12:56 PM, Carlos E.R. wrote:
> However, if someone wants to attack you, they will see established
> connections from those addresses, while other addresses fail fast; thus
> they will figure out that they have to "fake" those IP addresses to
> connect to your server.

Spoofing IP addresses on TCP connections is possible, but it's a LOT
harder to do than UDP. As long as the security requires round trip
traffic, a la established connections, then fire and forget attacks are
almost completely off the table.

I say almost completely because there are ways to deal with this, but
they are considerably more involved. If you're defending against this,
you are well beyond simply getting rid of log noise from worms.

[Grant Taylor]

On 5/29/21 9:27 AM, William Unruh wrote:
> As has been mentioned you could try port knocking-- still not terribly
> secure but it depends on the level of aversary you are protecting from.

Dynamic port knocking or Single Packet Authentication uses cryptographic
primitives to make each knock different. As in the source IP and / or
time of day is taken into consideration for the port(s) and / or
sequence to be knocked on.

Much like port knocking eliminates a lot of chaff, dynamic port knocking
or SPA eliminates the simple playback of previous port knocks.

[Grant Taylor]

On 5/29/21 10:44 AM, Marc Haber wrote:
> This is actually no better than having the ssh server accessible from
> the Outside. Just the keys are longer

I disagree.

The biggest difference I see is the scope and complexity of the
different systems.

OpenSSH is a LOT of lines of code and is quite complex. Conversely,
WireGuard is many fewer lines of code and purportedly quite a bit
simpler. From a security standpoint, this is a HUGE difference.

There is also some security benefit on having the VPN and the SSH server
on different devices.

[Johann Beretta]

On 5/29/21 2:28 PM, Roger Blake wrote:

>
> and use the firewall to limit the number
> of connection attempts permitted per minute.
>

That could easily lead to you being denied access. A bad actor would
only have to keep attempting to connect, rapidly.

[Marc Haber]

Giovanni <lso...@home.net.it> wrote:
>On 05/29/2021 06:44 PM, Marc Haber wrote:
>
>>> To overcome this problem I installed openvpn both in the server and
>>> on several clients. Each user has his own certificate and as long
>>> You start the private connection You will be able to connect via
>>> ssh from anywhere.
>
>> This is actually no better than having the ssh server accessible
>> from the Outside. Just the keys are longer
>
>The OP said that he wants access only from authorized IP addresses but
>he gets locked out if he uses foreign IP.

Yes, that's an unfillable request. Either there is a restriction, or
there is not.

What you're suggesting is an enterprise-level policy circumvention
that people do if they have contradicting requirements and don't dare
to educate the people who made those requirements.

>Well maybe a VPN isn't more secure than SSH, but while I see lots of
>failed attempts on the ssh port, there are very few on the VPN port.

the VAST majority of the connectionst to ssh servers are just
bruteforcing joe accounts. That doesnt matter at all for an ssh server
with passwords disabled.

[Marc Haber]

Now read this Usenet Article: "I have moved my ssh server to Port
11823 to get rid of the net's backgound noise. Now I ABSOLUTELY NEED
to connect to this ssh server from a network that doesn't allow
outgoing connections to my port 11823. How can I access port 11823
when I can only access port 22 from the place I am?"

[Marc Haber]

Grant Taylor <gta...@tnetconsulting.net> wrote:
>On 5/29/21 10:44 AM, Marc Haber wrote:
>> This is actually no better than having the ssh server accessible from
>> the Outside. Just the keys are longer
>
>I disagree.
>
>The biggest difference I see is the scope and complexity of the
>different systems.
>
>OpenSSH is a LOT of lines of code and is quite complex. Conversely,
>WireGuard is many fewer lines of code and purportedly quite a bit
>simpler. From a security standpoint, this is a HUGE difference.

We need to agree to disagree then. WireGuard might be easier, but it
runs in the Kernel. Way more dangerous.

>There is also some security benefit on having the VPN and the SSH server
>on different devices.

Yes, again, we seem not to be talking professional IT here.

[Pascal Hambourg]

Le 30/05/2021 à 05:34, D. Stussy a écrit :
> One doesn't need to run a program to do port knocking if one has a
> stateful firewall.  For Linux and similar unices, iptables with a recent
> list (using a timeout) can be configured to work.

This only allows basic port knocking which is vulnerable to replay and
brute force attacks.
And it still requires a program on the client side to send the packets.

[Pascal Hambourg]

Indeed. This can be mitigated by limiting the rate of connections per
source IP address, but this is still vulnerable to "blind" (one way)
spoofing attacks if you count only the TCP SYN packets. To protect
against this you must count TCP connections with complete handshake (SYN
- SYN/ACK - ACK). This is still vulnerable to an attacker able to do
two-way spoofing (i.e. receive the packets you send to the spoofed
address) but then I guess you have bigger concerns.

[Richard Kettlewell]

John Smith <12...@whatismyemailaddress.xyz> writes:
> On Fri, 28 May 2021 22:28:22 +0000, William Unruh wrote:
>> On 2021-05-28, John Smith <12...@whatismyemailaddress.xyz> wrote:
>>> I have the following problem:
>>>
>>> I would like to be able to connect from my laptop to my SSH
>>> server in my internal network, no matter where the laptop may be.
>>> However, my SSH server accepts connections from specific IP addresses -
>>> those to do with work - and rejects all others.
>>
>> Lets see, that ssh server (Is it really yours-- ie do you own it-- or is
>> it your company's) has security on it to only accept connections from
>> the company network and you want instead to connect from anywhere, which
>> means that anyone can connect from anywhere.
>> Remove the condition that ssh can only connect from work IP
>> addresses. Or would this be against company policy?
>
> The server is my own - I can modify it as I wish.

So remove the restriction that you find inconvenient. You are currently
locking your own door and then asking how to open it.

> What I am asking is whether things could be arranged so that
> specific clients - as in running on specific hardware - could connect
> from anywhere, whereas any other clients cannot, unless they come from
> specific IP addresses. I guess that ome could use the client's MAC
> address, but I don't know how.

SSH authenticates by key or password. Keys seem like a good fit for you
here.

--
https://www.greenend.org.uk/rjk/

[pk]

On Sat, 29 May 2021 14:38:16 +0000 (UTC), John Smith
<12...@whatismyemailaddress.xyz> wrote:

> On Fri, 28 May 2021 22:28:22 +0000, William Unruh wrote:
>
> > On 2021-05-28, John Smith <12...@whatismyemailaddress.xyz> wrote:
> >> I have the following problem:
> >>
> >> I would like to be able to connect from my laptop to my SSH
> >> server in my internal network, no matter where the laptop may be.
> >> However, my SSH server accepts connections from specific IP addresses -
> >> those to do with work - and rejects all others.
> >
> > Lets see, that ssh server (Is it really yours-- ie do you own it-- or is
> > it your company's) has security on it to only accept connections from
> > the company network and you want instead to connect from anywhere, which
> > means that anyone can connect from anywhere.
> > Remove the condition that ssh can only connect from work IP
> > addresses. Or would this be against company policy?
>
> The server is my own - I can modify it as I wish.
>
> What I am asking is whether things could be arranged so that
> specific clients - as in running on specific hardware - could connect
> from anywhere, whereas any other clients cannot, unless they come from
> specific IP addresses.

If you can accept the connecting username as identifier (admittedly a weak
security model difficult to enforce and easy to bypass; you can make it
slightly better if you use pubkey authentication only and users are not
allowed to copy other users' keys), then you can use openssh server's
"Match" directives in sshd_config to filter based on that and/or source IP
address and deny or permit access accordingly.

Eg (adapt as needed):

PasswordAuthentication no
PubKeyAuthentication no

# allow user bob and alice only from host 1.2.3.4
Match User alice,bob Address 1.2.3.4
PasswordAuthentication yes # or whatever
PubKeyAuthentication yes


# allow user charlie from anywhere
Match User charlie Address *
PasswordAuthentication yes
PubKeyAuthentication yes


Or directly use the AllowUsers option:

AllowUsers b...@1.2.3.4 al...@1.2.3.4 charlie@*

(Going by memory here, the syntax for all the above might not be 100%
correct, but those options do definitely exist.)

As mentioned, this is a very low-security solution, but depending on your
specific environment and use case it might be enough for your needs.

[William Unruh]

On 2021-05-30, Grant Taylor <gta...@tnetconsulting.net> wrote:
> On 5/29/21 12:21 PM, William Unruh wrote:
>> Theeasiest way to get rid of the vast majority of ssh attacks isto
>> simply put it on a different port.
>
> The operative phrase is "the vast majority". There will still be plenty
> of attacks even on non-standard port.
>
> Obscurity, by itself, is not security.

Nothing "by itself" is security. Obsurity is however one of many
invaluable layers of security. I went from 100 (or more) attacks per day to maybe one per
month by altering the port. The fewer the number of attacks the smaller
the chance that one will breach the real defences.

[Marc Haber]

jftr, I am running a couple of servers with no access list, but a TCP
SYN Rate Limit on Port 22 (I think it's like 10 SYN packets per
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.

[Marc Haber]

William Unruh <un...@invalid.ca> wrote:
>I went from 100 (or more) attacks per day to maybe one per
>month by altering the port. The fewer the number of attacks the smaller
>the chance that one will breach the real defences.

On a machine with password logins disabled (or reasonably secure
passwords), an occasional ssh connect (yes, five digit numbers of
attempts per day do still count as occasional) is only called an
"attack" by people who want to impress.

It's actually just Internet Background Noise.

[William Unruh]

On 2021-05-31, Marc Haber <mh+usene...@zugschl.us> wrote:
> William Unruh <un...@invalid.ca> wrote:
>>I went from 100 (or more) attacks per day to maybe one per
>>month by altering the port. The fewer the number of attacks the smaller
>>the chance that one will breach the real defences.
>
> On a machine with password logins disabled (or reasonably secure
> passwords), an occasional ssh connect (yes, five digit numbers of
> attempts per day do still count as occasional) is only called an
> "attack" by people who want to impress.

A reduction by a factor of over a 1000 is what the point was.
Note that the latest tactic is to attack from a bunch of different
taken-over machines, to get around the blacklisting of attacks from a single
IP.
(And attack is a technical term, having to do with intent, not number. A
single attempt is an attack if the intent is to break into the machine.)

[Grant Taylor]

On 5/29/21 9:34 PM, D. Stussy wrote:
> One doesn't need to run a program to do port knocking if one has a
> stateful firewall.  For Linux and similar unices, iptables with a recent
> list (using a timeout) can be configured to work.

Salute! to someone else that knows about IPTable's recent match
extension and finds creative uses for it. :-D

[Grant Taylor]

On 5/30/21 4:51 AM, Pascal Hambourg wrote:
> This only allows basic port knocking which is vulnerable to replay and
> brute force attacks.

Yes in a basic sense.

No in that it's possible, all be it complicated, to code things such
that different knocks are needed from different IPs.

Technically, it can be replayed for the same IP. But it can't be
replayed for different IPs.

There's also the fact that the IPTables rule set could be periodically
changed thus thwarting replay for even the same IP.

> And it still requires a program on the client side to send the packets.

Depending on what protocol and port is used, it may be possible to use a
web browser or telnet or ping.

Does using Bash's built in ability to send TCP & UDP packets count as a
program in the manner you are describing?

}:-)

[Pascal Hambourg]

Le 01/06/2021 à 06:48, Grant Taylor a écrit :
> On 5/30/21 4:51 AM, Pascal Hambourg wrote:
>> This only allows basic port knocking which is vulnerable to replay and
>> brute force attacks.
>
> Yes in a basic sense.
>
> No in that it's possible, all be it complicated, to code things such
> that different knocks are needed from different IPs.

How do you do this with iptables for any IP address ?
I am not asking for the complete solution, only the basic principle.

>> And it still requires a program on the client side to send the packets.
>
> Depending on what protocol and port is used, it may be possible to use a
> web browser or telnet or ping.
>
> Does using Bash's built in ability to send TCP & UDP packets count as a
> program in the manner you are describing?

No more than the other programs you mentioned. It may be used by a port
knocking client script, but none is a port knocking program by itself.

[Grant Taylor]

On 6/1/21 10:42 AM, Pascal Hambourg wrote:
> How do you do this with iptables for any IP address ?
> I am not asking for the complete solution, only the basic principle.

In short, you add additional rule sets for different source IPs.

You obviously don't want to explode the multiple rules for each set by
the number of IPs that are out there.

But, I could see how someone might duplicate the multiple rules for
different networks / ASNs.

Note: I'm speaking to a technical possibility, not the practicality of
doing something.

[Pascal Hambourg]

Le 01/06/2021 à 22:46, Grant Taylor a écrit :
> On 6/1/21 10:42 AM, Pascal Hambourg wrote:
>> How do you do this with iptables for any IP address ?
>> I am not asking for the complete solution, only the basic principle.
>
> In short, you add additional rule sets for different source IPs.
>
> You obviously don't want to explode the multiple rules for each set by
> the number of IPs that are out there.
>
> But, I could see how someone might duplicate the multiple rules for
> different networks / ASNs.

IIUC it is not applicable to connect from any random IP address, only
from specific IP addresses or networks known in advance.

[Grant Taylor]

On 6/3/21 4:50 AM, Pascal Hambourg wrote:
> IIUC it is not applicable to connect from any random IP address, only
> from specific IP addresses or networks known in advance.

It depends on how the knock is configured.

If it's a static knock on port A, then not on port Blue, and finally
knock on port triangle, then someone could do that A -> blue -> triangle
from any IP. Conversely if the source IP was part of the knock, as in
data for identifying the sequence, a simple replay wouldn't work.

[Pascal Hambourg]

How do you configure iptables to do this for all IP addresses ?

[Grant Taylor]

On 6/5/21 11:25 AM, Pascal Hambourg wrote:
> How do you configure iptables to do this for all IP addresses ?

It depends on what how you're doing port knocking.

But in essence, you configure whatever you're using to use a different
sequence based on the different source IP (or network). E.g.

1/8 = A -> blue -> triangle
2/8 = green -> square -> B
3/8 = oval -> C -> orange
...

Pick how granular you want things to be.

You can encode this purely as iptables rules with the recent match
extension. It will just take a fair number of rules and some thought to
make it work.

I've never used port knocking software, so I have no idea how to go
about configuring it.

The other catch is that the client will need to know the public IP
address that the world sees it connecting from so that it can pick the
proper sequence.

[David W. Hodgins]

On Sat, 05 Jun 2021 18:38:27 -0400, Grant Taylor <gta...@tnetconsulting.net> wrote:
> I've never used port knocking software, so I have no idea how to go
> about configuring it.

See https://www.zeroflux.org/projects/knock/ for one implementation.

On Mageia 8 ...
# urpmq -i knock
Name : knock
Version : 0.7
Release : 3.mga8
Group : Networking/Other
Size : 90001 Architecture: x86_64
Source RPM : knock-0.7-3.mga8.src.rpm
URL : http://www.zeroflux.org/knock/
Summary : Open connection through firewall on specified signal
Description :
knock is a server/client set that implements the idea known as port-
knocking. Port-knocking is a method of accessing a backdoor to your
firewall through a special sequence of port hits. This can be useful
for opening up temporary holes in a restrictive firewall for SSH
access or similar.

Regards, Dave Hodgins

--
Change dwho...@nomail.afraid.org to davidw...@teksavvy.com for
email replies.

[Pascal Hambourg]

Le 06/06/2021 à 00:38, Grant Taylor a écrit :
> On 6/5/21 11:25 AM, Pascal Hambourg wrote:
>> How do you configure iptables to do this for all IP addresses ?
>
> It depends on what how you're doing port knocking.
>
> But in essence, you configure whatever you're using to use a different
> sequence based on the different source IP (or network).  E.g.
>
> 1/8 = A -> blue -> triangle
> 2/8 = green -> square -> B
> 3/8 = oval -> C -> orange
> ...
>
> Pick how granular you want things to be.

Granularity is one single address.

> You can encode this purely as iptables rules with the recent match
> extension.  It will just take a fair number of rules and some thought to
> make it work.

I doubt this scales well with billions of addresses.

[Grant Taylor]

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.

> I doubt this scales well with billions of addresses.

Agreed.

But I hope we can agree that scalability is different than technical
possibility. As is should something be done or not.

If I wanted to do this to */32 on the Internet, I would not try to
implement this in /just/ IPTables+Recent. I would be far more likely to
do this in IPTables+Recent+<something in user space>. Where the
something in user space is likely NFQUEUE or quite similar. Keep the
bulk of the filtering in IPTables+Recent and only punt to user space for
things that don't qualify with the known good connections (dynamic)
kernel space.

[Pascal Hambourg]

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.

>> I doubt this scales well with billions of addresses.
>
> Agreed.
>
> But I hope we can agree that scalability is different than technical
> possibility.  As is should something be done or not.

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
iptables can handle so many rules, storing them requires more memory
than most systems have.

[Grant Taylor]

On 6/13/21 5:55 AM, Pascal Hambourg wrote:
> 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.

My experience is that just about every time someone says "no matter
where", they actually mean "no matter where I'm likely to use it from".
The latter is almost guaranteed to be a significantly smaller number.

> Scalability makes its tecnhically possible - or not.

I'm not entirely sure what you're trying to say.

But something can easily be technically possible without being scalable.
There are companies that hand build cars at the rate of a single digit
per year. That is more than technically possible. But it's decidedly
not scalable.

> Even the simplest port knocking algorithm (one packet) requires at
> least two iptables rules per address,

Why does it require /two/ iptables rules /per/ address?

I can easily see /one/ iptables rule /per/ address with a small number
of additional rules that are shared across addresses.

1) If the source IP is in the recent list then allow it. (Shared)
2) If the source IP is A.B.C.D then jump to OpenDoor. (Per IP)
3) If the source IP is W.X.Y.Z then jump to OpenDoor. (Per IP)
4) OpenDoor: Add source IP to the recent list and allow.

That's very crude with one rule per address and two rules shared with
other IPs.

> so it accounts for about 8 billion rules.

I seriously question that number.

> Even if iptables can handle so many rules, storing them requires more
> memory than most systems have.

"most systems" doesn't rule out all systems. There may very well be
some systems that can handle it.

I agree that such a method is not practical. But it's still technically
possible.

[William Unruh]

On 2021-06-13, Pascal Hambourg <pas...@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 that opens you up to ssh attacks so
you need something else (eg port knocking) to get in while still
preventing ssh attacks. Of course one of the easiest, not safe from a
determined attacker but very effective against script kiddies, is just
to use a non-standard port.

>
>>> I doubt this scales well with billions of addresses.
>>
>> Agreed.
>>
>> But I hope we can agree that scalability is different than technical
>> possibility.  As is should something be done or not.
>
> 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.

[Pascal Hambourg]

Le 13/06/2021 à 18:40, Grant Taylor a écrit :
> On 6/13/21 5:55 AM, Pascal Hambourg wrote:
>
>> Even the simplest port knocking algorithm (one packet) requires at
>> least two iptables rules per address,
>
> Why does it require /two/ iptables rules /per/ address?
>
> I can easily see /one/ iptables rule /per/ address with a small number
> of additional rules that are shared across addresses.

You are right. I have always used the recent match in pairs and did not
think that one rule could be shared.

>> so it accounts for about 8 billion rules.
>
> I seriously question that number.

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.

>> Even if iptables can handle so many rules, storing them requires more
>> memory than most systems have.
>
> "most systems" doesn't rule out all systems.  There may very well be
> some systems that can handle it.
>
> I agree that such a method is not practical.  But it's still technically
> possible.

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. 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. So it seems that iptables cannot hande more than 1,3M
rules, which is very far from 4G.

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.

HTH

[Pascal Hambourg]

Le 13/06/2021 à 19:55, William Unruh a écrit :
> On 2021-06-13, Pascal Hambourg <pas...@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.

[Grant Taylor]

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 Taylor]

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.

[William Unruh]

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:-)

>

[William Unruh]

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.

[Johann Beretta]

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.