LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 11-14-2017, 08:57 AM   #46
jlinkels
LQ Guru
 
Registered: Oct 2003
Location: Bonaire, Leeuwarden
Distribution: Debian /Jessie/Stretch/Sid, Linux Mint DE
Posts: 5,191

Rep: Reputation: 1039Reputation: 1039Reputation: 1039Reputation: 1039Reputation: 1039Reputation: 1039Reputation: 1039Reputation: 1039

Quote:
Originally Posted by sundialsvcs View Post
"So, is that why your servers spend X% of their time fighting-off Y,000 'unauthorized access attempts' per hour," until one of their dictionary-bots finally, by pure brute-force tactics, manages to penetrate your system and install a root-kit?"
Still the question: if I need to have SSH access to the hosts which are part of the VPN how do I prevent the above mentioned break-in-attempts. IPtables to allow only traffic from the VPN subnet?

jlinkels
 
Old 11-14-2017, 09:00 AM   #47
wpeckham
Senior Member
 
Registered: Apr 2010
Location: Continental USA
Distribution: Debian, Ubuntu, Fedora, RedHat, DSL, Puppy, CentOS, Knoppix, Mint-DE, Sparky, Vsido, tinycore, Q4OS
Posts: 3,008

Rep: Reputation: 1289Reputation: 1289Reputation: 1289Reputation: 1289Reputation: 1289Reputation: 1289Reputation: 1289Reputation: 1289Reputation: 1289
Forgive me, but I still do not see a real point here. VPN (as a networking access technique/concept) and SSH (as a terminal session client) are both excellent concepts that apply to different problems. They are versatile, and SSH CAN be applied to some of the same issues as a VPN, but that does not make it the right answer. VPN is a network concept, while SSH is a client/server session concept.

Any problem that is entirely local that a VPN can solve, can be better solved by smart networking (routing, firewalls, etc.) and should not require VPN software. VPN is an elegant solution to remote network access, and not really appropriate to other uses.

OpenVPN, as a specific VPN application, is very powerful and somewhat complex and designed for network and system administrators.
OpenSSH, as a specific SSH application (server and client), is easier because the server side is intended for system administrators and network administration skills are not as critical. The OpenSSH client applications are intended for normal users, and have useful defaults that are simple enough for any normal user. (And more advanced options for those who are more skilled.)

OpenSSH has, in recent versions, some significant VPN features tacked on. These make host-to-host VPN sessions very easy to do in that tool. Host to remote network (routing through a remote host) solutions are possible, but hardly as secure or stable as when using a proper VPN.

Several messages here make it very clear that there is a learning curve involved in advanced use of either one. It is worth climbing that curve IF you have a good case for that learning, and it is worth the effort if you really want to know.

Arguing that one is better than the other is like arguing the advantages of motorcycles over boats. It depends upon the environment (How wet is YOUR highway?) and where/how you need to use them.
 
Old 11-14-2017, 09:03 AM   #48
wpeckham
Senior Member
 
Registered: Apr 2010
Location: Continental USA
Distribution: Debian, Ubuntu, Fedora, RedHat, DSL, Puppy, CentOS, Knoppix, Mint-DE, Sparky, Vsido, tinycore, Q4OS
Posts: 3,008

Rep: Reputation: 1289Reputation: 1289Reputation: 1289Reputation: 1289Reputation: 1289Reputation: 1289Reputation: 1289Reputation: 1289Reputation: 1289
Quote:
Originally Posted by jlinkels View Post
Still the question: if I need to have SSH access to the hosts which are part of the VPN how do I prevent the above mentioned break-in-attempts. IPtables to allow only traffic from the VPN subnet?

jlinkels
I recommend you search for fail2ban on duckduckgo or google. It provides automated blocking (we assume iptables is available) that is adequate to block those dictionary or brute force attacks by detecting and acting on the activity.

This does not mean I approve the use of SSH for secure network communications where a VPN would be more appropriate, but if that is your limit then making it more secure is only reasonable.

Last edited by wpeckham; 11-14-2017 at 09:05 AM.
 
Old 11-14-2017, 09:21 AM   #49
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078

Original Poster
Blog Entries: 4

Rep: Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176
Quote:
Originally Posted by ntubski View Post
It's the same likelihood as brute forcing the VPN certificate.
Indeed, i-f you are using only digital certificates for SSH, "brute forcing" of those certificates is impossible. But, SSH has the very annoying characteristic that it will continue to "ratchet down" to lesser and lesser authentication alternatives, accepting the least secure ("passwords") alternative that it has been told to allow.

Furthermore, if an intruder can "slip" a new certificate into the authorized-keys file, he can grant access to himself with a fairly-low probability of actually being detected. All he needs to do is to penetrate the system once, and hope that you're not paying attention.

And, in any case, it's all happening on top of the network stack, and processes which wish to use it e.g. for "tunneling" must do so explicitly. Whereas, VPN operates as a router or a switch, and it normally communicates using UDP. Therefore, I-f you are using one-of-a-kind certificates, not "PSKs" == "passwords"(!), for authentication, you are rewarded with an unobtrusive secure link to a remote system, which both parties can identify with certainty, and which is simply "the route" to that subnet. Any and all traffic bound to/from those IPs will pass through the tunnel, automagically.

It literally is a "Virtual Private Network."

If the connection is secured with both digital certificates and tls-auth, not only penetration but even detection of the link becomes ... impossible. And yet, authorized users can open a new connection in less than ten seconds and thereafter "simply communicate," as though the resources were directly attached using boxes and wires instead of passing through an insecure public network.

Last edited by sundialsvcs; 11-14-2017 at 09:28 AM.
 
Old 11-14-2017, 09:57 AM   #50
IsaacKuo
Senior Member
 
Registered: Apr 2004
Location: Baton Rouge, Louisiana, USA
Distribution: Debian 9 Stretch
Posts: 2,349
Blog Entries: 8

Rep: Reputation: 384Reputation: 384Reputation: 384Reputation: 384
Quote:
Originally Posted by sundialsvcs View Post
Indeed, i-f you are using only digital certificates for SSH, "brute forcing" of those certificates is impossible. But, SSH has the very annoying characteristic that it will continue to "ratchet down" to lesser and lesser authentication alternatives, accepting the least secure ("passwords") alternative that it has been told to allow.
As already noted, it is very easy to set up /etc/ssh/sshd_config to lock everyone out except for one user which is only allowed to log in via key (encrypted with pass phrase).

In contrast, it seems that setting up a VPN with the exact right security is NOT so easy. And you're not making it any easier.

Quote:
Furthermore, if an intruder can "slip" a new certificate into the authorized-keys file, he can grant access to himself with a fairly-low probability of actually being detected. All he needs to do is to penetrate the system once, and hope that you're not paying attention.
Eh, you mean the intruder "just" needs root access once. With root access, there are a zillion different ways to insert a back door without messing with any configuration file. For example, unless you block outgoing web requests (the typical method by which a linux distribution will download security updates), it'll be possible for a compromised executable to reach out with a reverse ssh.

Quote:
And, in any case, it's all happening on top of the network stack, and processes which wish to use it e.g. for "tunneling" must do so explicitly.
Which, honestly, I am more comfortable with when it comes to on-the-road access. You're assuming the client computer is never compromised, but what are the chances? Physical security on a laptop is typically going to be less robust. If I accidentally leave my laptop unlocked for a minute while distracted or something? It takes only a few seconds to plug in a USB device and run a script kiddie script. It's not root level access, but regular user level access is plenty to start banging around a VPN connected network for any internal vulnerabilities.

I like the fact that when I'm on the road, the only connection back home is a narrow straw - just ssh for text console login and sshfs for file transfers, with only the access level of a single specified regular user to a single machine. The way ssh works, it's not so easy to piggyback on an ssh connection to try and root around for vulnerabilities in the connected computer (much less the LAN connected to it). A script kiddie script could still potentially do a lot of damage, but it's not so easy to cover its tracks when it only has regular user level access.

Last edited by IsaacKuo; 11-14-2017 at 10:23 AM.
 
Old 11-14-2017, 10:19 AM   #51
Sefyir
Member
 
Registered: Mar 2015
Distribution: Linux Mint
Posts: 602

Rep: Reputation: 300Reputation: 300Reputation: 300Reputation: 300
Quote:
Are you saying that "PasswordAuthentication no" in the sshd_config file is not sufficient?
I'd say it is.
Changing the below is typically all I'll do. Sometimes I'll spend a little more time on more public servers and more precise options, but they are generally options that deal with the two computers, and not "3rd parties".
However, I've yet to see, in any capacity, that the below is in any way more "insecure" then say, a vpn setup.

Setting up passwordless SSH is also very simple.
Not to mention I can do it completely in the command line without any guides
Also, accessing multiple, separate servers is very useful. Is this trivially possible with VPN? Seems like it'd mostly only be good for accessing a single (or group of related) servers.

Code:
ssh-keygen
ssh-copy-id username@myserver
Then change the below

Code:
# /etc/ssh/sshd_config
RSAAuthentication yes                                                           
PubkeyAuthentication yes

PasswordAuthentication no
Quote:
Indeed, i-f you are using only digital certificates for SSH, "brute forcing" of those certificates is impossible.
I feel like this settles the issue.
 
Old 11-14-2017, 10:24 AM   #52
anisoptera
LQ Newbie
 
Registered: Oct 2017
Posts: 28

Rep: Reputation: 13
You should probably address your concerns to the project's mailing lists: http://www.openssh.com/list.html

Some reading on proper SSH configuration from a reputable author: https://www.michaelwlucas.com/tools/ssh
 
Old 11-14-2017, 10:56 AM   #53
haertig
Senior Member
 
Registered: Nov 2004
Distribution: Debian, Ubuntu, LinuxMint, Slackware, SysrescueCD, Raspbian, Arch
Posts: 2,280

Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354
Quote:
Originally Posted by sundialsvcs View Post
Furthermore, if an intruder can "slip" a new certificate into the authorized-keys file...
Just a point of clarification for the users here that are new to this stuff: you do not find "certificates" in an "authorized_keys" file. You find "public keys". The two are quite different things. Since we have gone back and forth between "certificate authentication", "pubkey authentication" and "password authentication" in this thread, it's important to keep the terminology correct so as not to confuse the less experienced. This was just a simple typo by @sundialsvcs, but could throw some users into a fit of misunderstanding.
 
Old 11-14-2017, 11:02 AM   #54
jlinkels
LQ Guru
 
Registered: Oct 2003
Location: Bonaire, Leeuwarden
Distribution: Debian /Jessie/Stretch/Sid, Linux Mint DE
Posts: 5,191

Rep: Reputation: 1039Reputation: 1039Reputation: 1039Reputation: 1039Reputation: 1039Reputation: 1039Reputation: 1039Reputation: 1039
Quote:
Originally Posted by wpeckham View Post
I recommend you search for fail2ban on duckduckgo or google. It provides automated blocking (we assume iptables is available) that is adequate to block those dictionary or brute force attacks by detecting and acting on the activity.
I know fail2ban.
But the OP claims that using an OpenVPN minimizes flooding the sshd with unauthorized login attempts. Since I do use OpenVPN and do not like some aspects of fail2ban, I'd like to know if the OP claims this because he knows a smarter way to avoid thousands of login attempts.

jlinkels
 
Old 11-14-2017, 12:29 PM   #55
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,268

Rep: Reputation: 1943Reputation: 1943Reputation: 1943Reputation: 1943Reputation: 1943Reputation: 1943Reputation: 1943Reputation: 1943Reputation: 1943Reputation: 1943Reputation: 1943
Quote:
Originally Posted by rknichols View Post
Are you saying that "PasswordAuthentication no" in the sshd_config file is not sufficient?
Quote:
Originally Posted by Sefyir View Post
I'd say it is.
Apparently you need "ChallengeResponseAuthentication no" as well. That's the one that actually sends out the "Password: " challenge and is considered marginally more difficult for an attack script than is simple "PasswordAuthentication".
 
2 members found this post helpful.
Old 11-14-2017, 12:38 PM   #56
273
LQ Addict
 
Registered: Dec 2011
Location: UK
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
Posts: 7,340

Rep: Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258
Quote:
Originally Posted by rknichols View Post
Apparently you need "ChallengeResponseAuthentication no" as well. That's the one that actually sends out the "Password: " challenge and is considered marginally more difficult for an attack script than is simple "PasswordAuthentication".
Do you have any examples of this being explioted? I ask because I can't say just as I type whether I have that set or not but I know that I cannot attempt to use SSH to connect to my machine without having a valid key.
 
Old 11-14-2017, 01:13 PM   #57
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,268

Rep: Reputation: 1943Reputation: 1943Reputation: 1943Reputation: 1943Reputation: 1943Reputation: 1943Reputation: 1943Reputation: 1943Reputation: 1943Reputation: 1943Reputation: 1943
Quote:
Originally Posted by rknichols View Post
Apparently you need "ChallengeResponseAuthentication no" as well. That's the one that actually sends out the "Password: " challenge and is considered marginally more difficult for an attack script than is simple "PasswordAuthentication".
Quote:
Originally Posted by 273 View Post
Do you have any examples of this being explioted? I ask because I can't say just as I type whether I have that set or not but I know that I cannot attempt to use SSH to connect to my machine without having a valid key.
I'm just going by what I read about the openssh options. Part of this is going to be controlled by what methods the local ssh agent is configured to try or fallback to.
 
Old 11-14-2017, 06:02 PM   #58
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078

Original Poster
Blog Entries: 4

Rep: Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176
Quote:
Originally Posted by haertig View Post
Just a point of clarification for the users here that are new to this stuff: you do not find "certificates" in an "authorized_keys" file. You find "public keys". The two are quite different things. Since we have gone back and forth between "certificate authentication", "pubkey authentication" and "password authentication" in this thread, it's important to keep the terminology correct so as not to confuse the less experienced. This was just a simple typo by @sundialsvcs, but could throw some users into a fit of misunderstanding.
Thank you for the clarification.

But, functionally speaking, the two are, at some level, similar: they are both things that you must possess a copy of, in order to gain access. They consist of thousands of strongly-pseudorandom bits, thereby creating a level of "entropy" that dwarfs that of any possible "password (PSK)." But a "public key" has no concept of, say, being "signed" by a "certifying authority (CA)." And, the SSH authorized-keys file for a particular user is located in a place that the user himself can access and control.

OpenVPN certificates use the same TLS/SSL technology that is at the center of "https" web-sites. Certificates are issued and then (self-)signed by a central authority (a "CA") within the company ... or, within your home, and it is that signature that makes them valid. They are stored in a place that users cannot reach, and they are not particular to any user. They do not grant "login access." VPN is a secure networking layer, [i]not[/u] any sort of a "shell."

Last edited by sundialsvcs; 11-14-2017 at 06:03 PM.
 
Old 11-14-2017, 06:05 PM   #59
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078

Original Poster
Blog Entries: 4

Rep: Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176
Quote:
Originally Posted by 273 View Post
Do you have any examples of this being explioted? I ask because I can't say just as I type whether I have that set or not but I know that I cannot attempt to use SSH to connect to my machine without having a valid key.
With OpenVPN, if you do not possess a valid (tls-auth ...) preliminary certificate, you can't even attempt to connect. In fact, you can't even discover that an OpenVPN server is out there!
 
Old 11-14-2017, 06:20 PM   #60
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078

Original Poster
Blog Entries: 4

Rep: Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176Reputation: 3176
Quote:
Originally Posted by jlinkels View Post
I know fail2ban.
But the OP claims that using an OpenVPN minimizes flooding the sshd with unauthorized login attempts. Since I do use OpenVPN and do not like some aspects of fail2ban, I'd like to know if the OP claims this because he knows a smarter way to avoid thousands of login attempts.
OpenVPN will reduce the "number of unauthorized access attempts" to ... zero.

Set up your "sshd" so that it listens only to the inside of the tunnel. Firewall it away from being able to access, or being accessible by, the outside world, and have it listen only to the virtual IP-address that represents the tunnel. Now, the only way to reach "sshd" is to first pass through the OpenVPN gantlet. (There are numerous Internet articles which describe exactly how to do this.)

Next, use tls-auth and strong, one-of-a-kind digital certificates to set up your OpenVPN. Authorized users bearing non-revoked credentials will be able to pass through easily, and then, having done so, they will perceive "sshd" and everything else that you've decided to expose.

Everyone else in the world finds – nothing at all! There are no "open ports" to "scan." Attempts to establish an OpenVPN connection are ignored, and this means that you can't even detect that an OpenVPN server exists. (The server "silently drops" the connection-request packet, having determined on the basis of this one packet's initial content that it was not provided by a possessor of the tls-auth certificate.)

After all ... think about it ... "who do you want to even give the opportunity to connect to your machine?" The whole damned world? I think not! But, at the end of the day, and in spite of the fact that it encrypts the traffic that it passes to the host, "sshd" is "a shell." And it just might be open to the entire world, maybe giving all of them this prompt:

login:

Last edited by sundialsvcs; 11-14-2017 at 06:24 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
ssh session "disconnects" after "route add default ppp0", any suggestion? pettha Linux - Networking 2 09-15-2014 04:38 AM
[SOLVED] Don't understand how to use SSH keys with "ssh" and "scp" commands on Lubuntu maples Linux - Newbie 12 03-10-2014 10:09 PM
Is anyone familiar with "KiTTY"? (SSH client - based on "PuTTY") haertig General 1 09-22-2013 04:32 PM
"Keep laptop running on lid close?" + "ssh via crossover cable?" FatalKeystroke Linux - Laptop and Netbook 7 03-11-2011 07:53 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 03:32 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration