LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
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 09-08-2016, 06:09 PM   #1
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078
Blog Entries: 4

Rep: Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177
(OpEd) Why you should not use sshd (directly), and what you should use


Anyone who has launched sshd on an Internet-facing server has had the same experience: within a matter of hours or even minutes, the server is receiving hundreds of failed-login attempts per minute. This continues night and day.

In my opinion, the fundamental problems with ssh are twofold:
  1. Most damningly, it is "a shell." The fact that it encrypts its network traffic is immaterial: it presents the dreaded prompt:
    Quote:
    login:
  2. It reveals its presence to anyone who does a port-scan.

But there is an alternative: OpenVPN with digital certificates and tls-auth security.

As I describe in my blog post How to Build a Dwarvish Door With OpenVPN, it is possible to create an outer portal into your system that not only cannot be penetrated, it cannot be detected!

When the tls-auth feature is used, the OpenVPN server requires that supplicants show possession of a particular digital certificate, on their first exchange with the server. If they do not, OpenVPN silently drops the packet: it does not respond at all. Thus, to a port scan and to a "script kiddie," it simply isn't there.

Someone who does possess the first-level certificate does receive a response, and the only response that should be accepted is: a unique, one-of-a-kind, individually issued (usually, "self-signed") certificate: up to 4,096 bits of pure-random information. (N-E-V-E-R(!!) settle for "Pre-Shared-Keys (PSKs) == Passwords!") Falsification or "brute forcing" of such a thing is impossible, and each recognized certificate is unique. Thus, they can be revoked individually. (For "road warriors," the certificates can also be encrypted such that a password is required to unlock it.)

It is reasonable that authorized users should be subject to further challenges -- user names and passwords, ssh certificates, and so on -- once they have successfully passed through the OpenVPN portal. But, by placing this "undetectable bastion" as your outer-ring defense, you leave 100% of the script-kiddies out in the cold. Your servers (sshd and otherwise ...) should "listen" only to the virtual-tunnel provided by OpenVPN, so that in order to reach any of them you must first have passed through the tunnel.

(Also: you should constantly "port scan" your own systems to be certain that "no ports appear to be open.")

Is it "hard to do?" Frankly, no. OpenVPN uses the same "TLS" cryptographic protocol that is used by https: web sites. It includes the "EasyRSA" toolkit that, as the name implies, makes the necessary operations very "easy."

Try it, and "enjoy the blissful silence." Your server logs simply don't have any(!) "failed login attempts" to report ... period. The script-kiddies never make it that far. And, they never will.

... and yet, your authorized users, each of whom you know by the unique certificates that each one bears, can pass through the gantlet with ease. Once the "tunnel" is connected, they can access network resources as though they were "local." You don't have to worry about their traffic passing through the Internet without encryption if they "do the wrong thing" or "fail to do the right thing." The seemingly-effortless simplicity with which they gain access stands in direct contrast to the impossibility that faces everyone(!) else in the world.

This, in my opinion, is "encryption as it should be."
  • Authorized users are not inconvenienced.
  • Access is tied to the possession of "a unique thing," not "a (not-so) secret," and each-and-every thing is tied to a single authorized possessor of that particular thing.
  • The scenario can be centrally managed.
  • Access can be revoked at will, without impacting any other authorized user.
  • Unauthorized users face an impenetrable (and, invisible) barricade that they cannot penetrate. ("The door is shut.")

Last edited by sundialsvcs; 09-08-2016 at 06:15 PM.
 
Old 09-09-2016, 12:36 AM   #2
HMW
Member
 
Registered: Aug 2013
Location: Sweden
Distribution: Debian, Arch, Red Hat, CentOS
Posts: 773
Blog Entries: 3

Rep: Reputation: 369Reputation: 369Reputation: 369Reputation: 369
Quote:
Originally Posted by sundialsvcs View Post
Anyone who has launched sshd on an Internet-facing server has had the same experience: within a matter of hours or even minutes, the server is receiving hundreds of failed-login attempts per minute. This continues night and day.
Not that I want to take anything away from your very insightful post, but I don't fully agree with the above.
My personal (Debian) server runs ssh on a non-standard port with a limit set on said port (using ufw). I have had 0 (zero!) brute force attempts since this server went live.

In fact, I found it so strange that I did a little "penetration testing" on my own. To my surprise I found that even though port 123* is open for ssh it does NOT show as an open port using nmap. I did find port 123, but that required some serious effort.

I am not claiming this to be a perfect solution, it is not, but when compared to another server I managed several years ago that ran ssh on the standard (22) port and only in combination with fail2ban, the difference is remarkable.

What I do get however are tons of attemtps to crack via port 80 (I use apache2 for some websites), but I can live with that, and deal with most of them via mod_rewrite.

Finally, thank you for posting, I learn a lot from reading stuff like this.

Best regards,
HMW

*This is not the actual port!

Last edited by HMW; 09-09-2016 at 12:38 AM.
 
Old 09-09-2016, 09:50 AM   #3
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078

Original Poster
Blog Entries: 4

Rep: Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177
The IP-addresses most commonly probed are those known to be associated with public hosting services or cloud servers.

I helped to deploy a server at one of those sites and we had not even logged-off for the first time before the SSH login-attempts had started, and we logged about 400 attempts per minute. They did not stop ... until we shut the cryptographic door in their face, and the rate dropped neatly to: Zero. Nada. None.

Of course you will continue to get probes of the HTTP(S) ports, but all you need to do there is, well, "don't do stupid things." Don't run Plesk. Don't install PHPMyAdmin. If you do run a CMS, keep it up to date. Use restricted-access SQL passwords. And, so on.

Last edited by sundialsvcs; 09-09-2016 at 09:53 AM.
 
Old 09-11-2016, 04:33 AM   #4
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,409
Blog Entries: 55

Rep: Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582
It's a given that any service connected to the 'net introduces an attack surface and VPN is no exception.
Plus there's situations where VPN just isn't doable or practical.
Doesn't mean people shouldn't be aware of the option but it's not (yet?) "the new gold standard" IMHO.
 
  


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
sshd rejects root with RSA key but sshd -d accept it yek Linux - Software 2 08-19-2015 11:15 AM
Starting sshd: /etc/init.d/sshd: line 113: /usr/sbin/sshd: Permission denied sumanc Linux - Server 5 03-28-2008 04:59 AM
FC4-Starting sshd: Privilege separation user sshd does not exist FAILED kiranherekar Fedora 5 12-29-2005 02:22 PM
Enabling SSH in mandrake 9.2 - sshd vs. sshd-xinetd DogTags Linux - Newbie 7 11-25-2003 12:17 PM

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

All times are GMT -5. The time now is 08:10 AM.

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