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?
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?
I have the following problem:
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 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?
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.
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?
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?
I guess that ome could use the client's MAC address
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.
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.
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
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.
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.
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
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.
Downstream. The router just forwards connections on port 22 to the appropriate system in my 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.
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.
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.
This is actually no better than having the ssh server accessible from
the Outside. Just the keys are longer
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.
I have the following problem:
and use the firewall to limit the number
of connection attempts permitted per minute.
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.
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.
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
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.
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.
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.
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.
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.
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).
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.
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.
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
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.
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.
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.
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?
How do you do this with iptables for any IP address ?
I am not asking for the complete solution, only the basic principle.
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.
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.
I've never used port knocking software, so I have no idea how to go
about configuring it.
How do you configure iptables to do this for all IP addresses ?
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.
Granularity is one single address.
I doubt this scales well with billions of addresses.
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.
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.
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.
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.
Why? you can have one rule for a range of addresses.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.
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.
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.
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)
Scalability makes its tecnhically possible - or not. Even the simplestWhy? you can have one rule for a range of addresses.
port knocking algorithm (one packet) requires at least two iptables
rules per address, so it accounts for about 8 billion rules. Even if
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.
This is exactly what we are discussing in that part of the thread : port knocking implemented with iptables as someone suggested.
No, you need different one rule per single address to prevent port
knocking replay.
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.
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.
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.
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:-)
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
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (2 / 14) |
Uptime: | 86:40:16 |
Calls: | 6,496 |
Calls today: | 7 |
Files: | 12,099 |
Messages: | 5,277,131 |