LinuxQuestions.org
Help answer threads with 0 replies.
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-13-2017, 06:50 AM   #31
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 wpeckham View Post
No argument except with this:
That part is not true. A "subnet" is a portion of the address space that may be addressed and routed differently than other parts of the network. It may be local or remote.

As an example, I use a full class C local and network (10.10.255.0/24, a subnet of the entire 10.* class A, itself a subnet of the larger ipv4 network space. From that I subnet 10.10.255.128/25 subnet for WIFI and use the lower 10.10.255.0/25 for direct wired network. There is no traffic allowed between these two local subnets, with one exception: a static route that allows all devices on both networks to reach my network printer.
This is entirely true, but VPN is engineered to act as a secure router (or bridge), implemented in software. You could implement a third subnet on your network, which is located somewhere else and reached through the Internet, and with VPN you would know with whom you were communicating, and you would (if you do it right) also know that no one else on the planet can discover the link (in order to try to log on to it), let alone penetrate it.
 
Old 11-13-2017, 12:00 PM   #32
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
I think I'm giving up on OpenVPN after reading many different guides on getting started with it. Too many different ideas on how to secure it, too complex, too many different places to make mistakes and have stumbling blocks. For on-the-road access, I'm more comfortable with the simple and limited ssh on custom port. Even if someone gets the key file, the passphrase still protects it, and it's only for a single non-root user.

For internal use within my LAN, it seems OpenSwan may be easier to set up. Fits on one page:

https://wiki.debian.org/HowTo/openswan

(Obviously, I'll use "systemctl restart ipsec" rather than the init.d script.)

Since I'll be using this strictly for computer-to-computer access within a shared LAN, I'll need to set up dummy interfaces rather than "real" subnets, but this seems simple enough.
 
Old 11-13-2017, 12:10 PM   #33
273
LQ Addict
 
Registered: Dec 2011
Location: UK
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
Posts: 7,348

Rep: Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258
Quote:
Originally Posted by IsaacKuo View Post
I think I'm giving up on OpenVPN after reading many different guides on getting started with it. Too many different ideas on how to secure it, too complex, too many different places to make mistakes and have stumbling blocks.
Sadly that has been my experience also. I've set up (simple) LAMP servers with HTTPS and use SSH with keys but just can't find a straightforward guide for getting OpenSSH running.
 
Old 11-13-2017, 01:29 PM   #34
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
Sadly that has been my experience also. I've set up (simple) LAMP servers with HTTPS and use SSH with keys but just can't find a straightforward guide for getting OpenSSH running.
"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?"

Even though (Open)VPN documentation is not the best, in my blog, right here, I have sincerely attempted to share the product of my experiences , and I am happy to write more installments.

I found that there are basically two obstacles to the adoption of VPN, among users who are accustomed to SSH:
  1. The notion that a VPN serves the role of a network appliance, either a "router" or (much less commonly) a "switch." Frankly, many users have never encountered a network which involved the use of a router other than their "internet router," and have never dealt with "round-trip TCP/IP routing issues" of any kind.
  2. The process of creating and then setting-up a TLS "self-signing CA" and then issuing certificates under it. (And subsequently managing those certificates.)

"Real-world" encryption technologies are all about "Alice and Bob, and Eve." (And they never(!) assume that "Eve" can actually "successfully pretend to be Alice, such that Bob cannot tell the difference," merely(!) by "Saying the Magic Word!") Therefore, they do require a certain amount of patience. Until you get "the entire(!) incantation" just right, the door will not open. And, quite by design, it will strive to give you "not one single miserable hint" what you (presumed to be "Eve!") did wrong.

However, if you persevere, just one time, you will be rewarded with ... silence. With security logs that are ... empty.
 
Old 11-13-2017, 01:30 PM   #35
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
P.S.: I will be more than happy to write new articles in my blog, here.
 
Old 11-13-2017, 02:12 PM   #36
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
Like I noted before, I looked at your four blog articles, and none of them describe how to set this up.

I'm actually a bit puzzled that you don't already have some sort of documentation of what to do. I have set up various things on my main server, and I have instructions for myself on how to do it all over again. These instructions aren't entirely readable for others, but I include enough detail for myself to replicate what I've done. I've done so several times, because I like to have a drop-in replacement server and I also like to occasionally do a fresh reinstall (about once every Debian Stable release).

I mean, look at my blog. All 8 of my blog posts are detailed instructions on how to do something. Do you think that's only for the benefit of others? Nope, I'm sure the person who refers to them the most is myself. So, not only do I say why you'd want to do X, I also describe how to actually do X. It helps others, sure, but it also helps myself.

My point is - if I had to build a replacement server and install/set up from scratch, I could and it would be done in one night's work thanks to the instructions I maintain for myself.

So why don't you have your own instructions, even if only for your own use? Are you confident that you could replicate your VPN server quickly after a fresh linux install? If not, why not?

I personally wouldn't be comfortable with anything I couldn't set up over again in a straightforward way. When I set up a new server, I don't expect to bang my head against a wall. I expect to follow my notes and for it to work.

Note that you don't need to make a blog post that's more "user friendly" than an info dump. Sometimes, your notes consist of little more than fragments of configuration files and copy/paste commands to enter. It may not be the easiest thing for others to comprehend, but you can just post an info dump and then maybe modify it later with explanations. A lot of times, just seeing raw config file fragments can be more helpful than a wordy description of what to do in the abstract. (My own blog posts combine wordy descriptions with config files/script fragments.)

As for security logs - as others have already noted, this just isn't a problem with ssh on a custom port. Custom ports for ssh just don't get hit often, and even if they did it doesn't matter with password authentication turned off.

Last edited by IsaacKuo; 11-13-2017 at 02:17 PM.
 
Old 11-13-2017, 04:10 PM   #37
haertig
Senior Member
 
Registered: Nov 2004
Distribution: Debian, Ubuntu, LinuxMint, Slackware, SysrescueCD, Raspbian, Arch
Posts: 2,280

Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354
A VPN server is much harder to set up than an SSH server. IMHO, there's no comparison between the two in that regard. You will have to don your learning hat to get the most functionality/security out of VPN if you don't already know how to configure it. Same goes for SSH, but the learning hat is much smaller.

Saying "always use UDP for VPN" is entirely too simplistic. I agree that most of the time, for most users, UDP is the way to go. However there are times when TCP will offer more functionality (breaking through restrictive firewalls), or (paradoxically) better performance (when faced with large scale packet loss or rearrangement of packet order).

Next up, you have to decide it you want a TUN or a TAP VPN setup. TUN is also called "a routed VPN" and TAP is called "a bridged VPN". Bridging is easier to set up and comprehend, but routed gives you more fine-tuned control. e.g., You can easily firewall stuff with a routed VPN - not so easy in a bridged one (you can't use iptables for something that is bridged, you have to go to a lower level). So your choice between TAP/TUN will depend on the level of access you want to grant and the amount of trust you have in your VPN users. You can assign VPN users specific IP addresses based on their cert. So when "Fred" comes in, you know it is him for sure, you give him a specific IP address that does not vary, and thus you can control what he can access via iptables rules (on a routed VPN). "Bob" then comes in, has a totally different IP address assigned to him, and you can give him completely different access to things than you gave to "Fred".

VPN is more powerful and flexible than SSH. But with that power and flexibility comes quite a bit of added complexity. And the more you want to up the security, the more complex it gets as well. login/password is the least secure, but the easiest to set up. Next, in the SSH world, comes pubkey authentication. Much better than login/password. But not as good as certificates. Certificate authentication is the standard in VPN (although you can set authentication in other ways). I consider pubkey the standard for SSH in my installations, but many would argue that login/password is the standard in their installations. You can use certificates in SSH. I am not up-to-date in OpenSSL vs. certs. It used to be that OpenSSL (opensource, free) didn't support them, but maybe they do now. I remember having to use Tectia SSH (commercial, paid) to enable client cert authentication years ago for a specific installation at work.

SSH is much easier to test than VPN. Assuming you are sitting at home and all your devices are on the same LAN, you can't bring up a VPN for testing (well you can, but it won't work reliably, probably not at all). This is because packet routings get very confused deciding to send packets directly over the LAN, or over the LAN via the VPN. SSH does not have this constraint, and you can easily test it with all devices on the same LAN.

Conclusion: There is no one answer to VPN vs. SSH. No one answer to UDP vs. TCP. No one answer to TUN vs. TAP. No one answer to login/password vs. pubkey vs. certificate authentication. Every situation has a different balance of ease vs. complexity and ease vs. security. Put on your learning hat and do some research before making a decision.

FWIW - at home, I run VPN on my router. Two instances. One is TUN/UDP, the other is TAP/TCP. Remotely I can connect either way, depending on the situation. But since I only implicitly trust myself, other users of my VPN (limited family members) are all TUN/UDP only. While they are trustworthy, I'm not so sure about the other environments that connect in, thus their actual devices could be compromised. My family VPN users are very tightly firewalled. By default they can't connect to anything, zero network activity allowed, unless I explicitly grant a specific access to each of them, on an individual basis. My router runs OpenVPN. There is a GUI for administering it. But I do not use that. I use good old manual config files that I set up from scratch. I do not trust the GUI configuration to do what I want to do. You never really know what those little GUI checkboxs actually do down in the bowels of the OpenVPN configuration. Some are obvious, others are not.

Also, I run SSH on my home router. Pubkey only. Very tightly configured. I am the only user allowed in. While SSH/pubkey is weaker than VPN/certificate, the way I have it configured it is strong enough for my personal needs, which is what matters.

Also, iptables on my router. Again, manually configured - not with the GUI checkboxes provided in the user interface.

Last edited by haertig; 11-13-2017 at 04:13 PM.
 
1 members found this post helpful.
Old 11-13-2017, 05:21 PM   #38
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
The "customary" way of doing this, it would seem, is ssh. This is referred-to as a "secure shell," simply because it encrypts the traffic that it sends to its destination.
Although you have seen that I agree with you that a VPN makes life much easier, just wondering. I do need SSH access to my servers for maintenance and setup. Even if they are on a VPN, I must have SSH open. Is an additional requirement to deny SSH from any subnet except the VPN?

jlinkels
 
Old 11-13-2017, 06:29 PM   #39
ntubski
Senior Member
 
Registered: Nov 2005
Distribution: Debian, Arch
Posts: 3,498

Rep: Reputation: 1806Reputation: 1806Reputation: 1806Reputation: 1806Reputation: 1806Reputation: 1806Reputation: 1806Reputation: 1806Reputation: 1806Reputation: 1806Reputation: 1806
Quote:
Originally Posted by sundialsvcs View Post
Quote:
Originally Posted by 273 View Post
Sadly that has been my experience also. I've set up (simple) LAMP servers with HTTPS and use SSH with keys but just can't find a straightforward guide for getting OpenSSH running.
"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?"
Doesn't apply to SSH with keys.
 
Old 11-13-2017, 07:36 PM   #40
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
Doesn't apply to SSH with keys.
There are three basic problems with this:
  1. Everyone in the Known Universe knows that "ssh" is there, and therefore they will do so.
  2. It is actually quite difficult to prevent "ssh" from falling-back to a password prompt.
  3. Even when an "ssh tunnel" is successfully established, you must take special precautions to ensure that your traffic is actually passing through it.
Without ... obviously ... "over-simplifying this matter," the VPN approach to security has compelling advantages because "it's just there."
  • When you use VPN to connect your private network to another private network, you can basically forget that there is "an Internet" in the way.
  • When you use VPN to connect to your private network from the outside, you can basically forget that you are "remote."
  • When digital certificates and tls-auth are used, "unauthorized access attempts" become impossible.

"ssh" operates at a level above "the TCP/IP stack," while "VPN" operates within it.
 
Old 11-13-2017, 08:16 PM   #41
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,272

Rep: Reputation: 1943Reputation: 1943Reputation: 1943Reputation: 1943Reputation: 1943Reputation: 1943Reputation: 1943Reputation: 1943Reputation: 1943Reputation: 1943Reputation: 1943
Quote:
Originally Posted by sundialsvcs View Post
2. It is actually quite difficult to prevent "ssh" from falling-back to a password prompt.
Are you saying that "PasswordAuthentication no" in the sshd_config file is not sufficient?
 
Old 11-13-2017, 08:35 PM   #42
ntubski
Senior Member
 
Registered: Nov 2005
Distribution: Debian, Arch
Posts: 3,498

Rep: Reputation: 1806Reputation: 1806Reputation: 1806Reputation: 1806Reputation: 1806Reputation: 1806Reputation: 1806Reputation: 1806Reputation: 1806Reputation: 1806Reputation: 1806
Quote:
Originally Posted by sundialsvcs View Post
Everyone in the Known Universe knows that "ssh" is there, and therefore they will do so.
Do what?

Quote:
It is actually quite difficult to prevent "ssh" from falling-back to a password prompt.
If you rephrase as "it's easy to neglect to forbid password login" I would agree, and it is a real drawback (default is not secure).

Quote:
Even when an "ssh tunnel" is successfully established, you must take special precautions to ensure that your traffic is actually passing through it.
I think most people use ssh as a shell, so this is not much of an issue. That is, ssh isn't meant to be a replacement for VPN.
 
Old 11-14-2017, 12:39 AM   #43
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 rknichols View Post
Are you saying that "PasswordAuthentication no" in the sshd_config file is not sufficient?
Lock it down with more than just "PasswordAuthentication no". The following is not a complete sshd config, it just touches on security related stuff. Also, some of the settings are not used because other settings negate their need. But it doesn't hurt to set them anyway.

Code:
Protocol 2
UsePrivilegeSeparation yes
StrictModes yes
PermitRootLogin no
RSAAuthentication no
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication no
KerberosAuthentication no
KerberosGetAFSToken no
GSSAPIAuthentication no
UseLogin no
UsePAM no
PubkeyAuthentication yes
IgnoreRhosts yes
IgnoreUserKnownHosts yes
AllowUsers your_user_id
I don't think it's difficult to instruct SSHD to not prompt for passwords. Pretty simple really - just say "no" to the things you don't want and "yes" to the things you do want.
 
Old 11-14-2017, 12:54 AM   #44
273
LQ Addict
 
Registered: Dec 2011
Location: UK
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
Posts: 7,348

Rep: Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258Reputation: 2258
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?"
I've spent a fair bit of time playing with virtual machines with various ports open to the internet and it's my experience that if SSH isn't on port 22 that cuts down script kiddies to practically zero*. As to brute force -- if they brute force the private key or my Pi then they've probably wasted a lot of computing power for virtually none. Sure, it's possible but unlikely.


*Less security through obscurity than log management.
 
Old 11-14-2017, 06:44 AM   #45
ntubski
Senior Member
 
Registered: Nov 2005
Distribution: Debian, Arch
Posts: 3,498

Rep: Reputation: 1806Reputation: 1806Reputation: 1806Reputation: 1806Reputation: 1806Reputation: 1806Reputation: 1806Reputation: 1806Reputation: 1806Reputation: 1806Reputation: 1806
Quote:
Originally Posted by haertig View Post
I don't think it's difficult to instruct SSHD to not prompt for passwords. Pretty simple really - just say "no" to the things you don't want and "yes" to the things you do want.
The tricky bit is figuring out which things you want. Or that you need to say "no" or "yes" to things in the first place.

Quote:
Originally Posted by 273 View Post
As to brute force -- if they brute force the private key or my Pi then they've probably wasted a lot of computing power for virtually none. Sure, it's possible but unlikely.
It's the same likelihood as brute forcing the VPN certificate.
 
  


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 04:11 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