• Connecting to an SSH server from the external world

    From John Smith@21:1/5 to All on Fri May 28 21:31:30 2021
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to John Smith on Fri May 28 22:28:22 2021
    On 2021-05-28, John Smith <12345@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 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?


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to John Smith on Fri May 28 16:36:03 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Henning Hucke@21:1/5 to John Smith on Sat May 29 07:17:52 2021
    On 2021-05-28, John Smith <12345@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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Kettlewell@21:1/5 to John Smith on Sat May 29 08:55:02 2021
    John Smith <12345@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/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Giovanni@21:1/5 to John Smith on Sat May 29 11:01:59 2021
    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/ >

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Smith@21:1/5 to Grant Taylor on Sat May 29 14:42:47 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Smith@21:1/5 to William Unruh on Sat May 29 14:38:16 2021
    On Fri, 28 May 2021 22:28:22 +0000, William Unruh wrote:

    On 2021-05-28, John Smith <12345@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.




    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?


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to John Smith on Sat May 29 15:27:34 2021
    On 2021-05-29, John Smith <12345@whatismyemailaddress.xyz> wrote:
    On Fri, 28 May 2021 22:28:22 +0000, William Unruh wrote:

    On 2021-05-28, John Smith <12345@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.
    .




    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?



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Pascal Hambourg@21:1/5 to All on Sat May 29 17:19:19 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Haber@21:1/5 to John Smith on Sat May 29 18:44:00 2021
    John Smith <12345@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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Haber@21:1/5 to Giovanni on Sat May 29 18:44:38 2021
    Giovanni <lsodgf0@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

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Giovanni@21:1/5 to Marc Haber on Sat May 29 19:14:36 2021
    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.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Smith@21:1/5 to Pascal Hambourg on Sat May 29 16:27:38 2021
    On Sat, 29 May 2021 17:19:19 +0200, Pascal Hambourg wrote:

    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.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to John Smith on Sat May 29 20:56:28 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Giovanni on Sat May 29 18:21:11 2021
    On 2021-05-29, Giovanni <lsodgf0@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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Roger Blake@21:1/5 to William Unruh on Sat May 29 21:28:13 2021
    On 2021-05-29, William Unruh <unruh@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 ------------------------------------------------------------------------------

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to John Smith on Sat May 29 19:37:51 2021
    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. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to William Unruh on Sat May 29 19:41:28 2021
    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. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Carlos E.R. on Sat May 29 19:44:08 2021
    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. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Marc Haber on Sat May 29 19:48:15 2021
    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.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to William Unruh on Sat May 29 19:46:30 2021
    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. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From D. Stussy@21:1/5 to John Smith on Sat May 29 20:34:48 2021
    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.

    Note also that port knocking, although defined in terms of UDP, need not use UDP ports. One can use other IP protocols, and in some
    circumstances, even some port-less protocols might work.

    "Henning Hucke" wrote in message news:slrnsb3ql0.9a0.h_hucke+spam.news@romulus.aeon.icebear.cloud...
    On 2021-05-28, John Smith <12345@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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Johann Beretta@21:1/5 to Roger Blake on Sat May 29 22:03:15 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Haber@21:1/5 to Giovanni on Sun May 30 12:11:20 2021
    Giovanni <lsodgf0@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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Haber@21:1/5 to William Unruh on Sun May 30 12:12:33 2021
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-05-29, Giovanni <lsodgf0@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

    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?"

    --
    -------------------------------------- !! 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Haber@21:1/5 to Grant Taylor on Sun May 30 12:13:42 2021
    Grant Taylor <gtaylor@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.

    --
    -------------------------------------- !! 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Pascal Hambourg@21:1/5 to All on Sun May 30 12:51:59 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Pascal Hambourg@21:1/5 to All on Sun May 30 13:02:49 2021
    Le 30/05/2021 à 07:03, Johann Beretta a écrit :
    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.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Kettlewell@21:1/5 to John Smith on Sun May 30 14:42:08 2021
    John Smith <12345@whatismyemailaddress.xyz> writes:
    On Fri, 28 May 2021 22:28:22 +0000, William Unruh wrote:
    On 2021-05-28, John Smith <12345@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/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pk@21:1/5 to 12345@whatismyemailaddress.xyz on Sun May 30 16:31:18 2021
    On Sat, 29 May 2021 14:38:16 +0000 (UTC), John Smith <12345@whatismyemailaddress.xyz> wrote:

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

    On 2021-05-28, John Smith <12345@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 bob@1.2.3.4 alice@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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Grant Taylor on Sun May 30 14:43:53 2021
    On 2021-05-30, Grant Taylor <gtaylor@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.

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




    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Haber@21:1/5 to Pascal Hambourg on Sun May 30 19:35:47 2021
    Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
    Le 30/05/2021 à 07:03, Johann Beretta a écrit :
    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.

    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.

    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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Haber@21:1/5 to William Unruh on Mon May 31 10:22:36 2021
    William Unruh <unruh@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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Marc Haber on Mon May 31 17:29:47 2021
    On 2021-05-31, Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
    William Unruh <unruh@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.)

    It's actually just Internet Background Noise.

    Greetings
    Marc

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Pascal Hambourg on Mon May 31 22:48:20 2021
    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?

    }:-)



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to D. Stussy on Mon May 31 22:45:36 2021
    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. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Pascal Hambourg@21:1/5 to All on Tue Jun 1 18:42:59 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Pascal Hambourg on Tue Jun 1 14:46:41 2021
    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.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Pascal Hambourg@21:1/5 to All on Thu Jun 3 12:50:37 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Pascal Hambourg on Thu Jun 3 22:53:07 2021
    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.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Pascal Hambourg@21:1/5 to All on Sat Jun 5 19:25:03 2021
    Le 04/06/2021 à 06:53, Grant Taylor a écrit :
    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.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David W. Hodgins@21:1/5 to Grant Taylor on Sat Jun 5 18:58:15 2021
    On Sat, 05 Jun 2021 18:38:27 -0400, Grant Taylor <gtaylor@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 dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
    email replies.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Pascal Hambourg on Sat Jun 5 16:38:27 2021
    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.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Pascal Hambourg@21:1/5 to All on Sat Jun 12 11:16:13 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Pascal Hambourg on Sat Jun 12 11:12:31 2021
    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.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Pascal Hambourg@21:1/5 to All on Sun Jun 13 13:55:22 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Pascal Hambourg on Sun Jun 13 10:40:59 2021
    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.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Pascal Hambourg on Sun Jun 13 17:55:41 2021
    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 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.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Pascal Hambourg@21:1/5 to All on Mon Jun 14 16:29:01 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Pascal Hambourg@21:1/5 to All on Mon Jun 14 16:34:33 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Pascal Hambourg on Mon Jun 14 11:39:12 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Pascal Hambourg on Mon Jun 14 11:32:54 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Grant Taylor on Mon Jun 14 21:03:20 2021
    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:-)



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to William Unruh on Mon Jun 14 22:26:24 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Johann Beretta@21:1/5 to Marc Haber on Wed Aug 11 11:48:38 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)