LinuxQuestions.org
Visit Jeremy's Blog.
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 01-09-2015, 10:18 PM   #1
Miati
Member
 
Registered: Dec 2014
Distribution: Linux Mint 17.*
Posts: 326

Rep: Reputation: 106Reputation: 106
Post Securing SSH - Allow/Denying & Match Statements


Written for OpenSSH_6.6.1p1 Ubuntu based (Actually LM)
Other versions might have more or less features. Test and see what works.
Also, when I say LAN network, I presume it starts with 192.168.1. Different routers will assign different local ips.

I'm writing this to help increase general security while using ssh while also permitting plenty of usability.
Prior, when I was trying to figure this all out, a lot of the ssh documentation was extremely confusing and often outdated.
So if you have had a similar experience trying to setup sshd, hopefully this will be of use.

I expect you have a working openssh server setup and understand the basic options and know how to test new configs without locking yourself out (hint: don't close the original connection)
If you have a ssh server facing the Internet, please read through this.
There should be no reason for decreased security, even when using passwords via external ips!
However, using public key auth will always be significantly more secure and should be considered best practice to use.

Some things I will cover
  • Explanation and examples of AllowUsers, AllowGroups, DenyUsers, DenyGroups
  • Explanation and examples of Matching statements
  • Using combinations of Allow/Deny and Match statements to support complex situations
  • Connecting via password from external address

The OpenSSH Server configuration file is located at /etc/ssh/sshd_config
The options inside are obeyed from top to bottom.
So if you put in

PasswordAuthentication no
PasswordAuthentication yes

Then passwords are allowed. Thus, all default configurations must be above the conditional options in the file.

Best Practice:
In general, make sure to make permissions as limited as possible. This is much better then opening the gates and putting up numerous barriers
to stop intruders.
Say no to everyone, then say yes to a very select choice of users.
If you must have password access, ensure the users using password access have exceptionally limited permissions.
No matter how small the door is, if your one user permitted passwords has a easy password and root (or sudo) access, you are asking for trouble.


____________________________________

AllowUsers, AllowGroups, DenyUsers, DenyGroups

The names should explain themselves.
e.g. if you set a AllowUsers option, that user will be permitted while everyone else is denied.
If you set DenyGroups, that group will be denied but all others will be permitted.
If a person matches multiple (in allow users but in deny groups) behavior has been a little inconsistent.
Deny seems to be more powerful then Allow. I suggest testing to see how it acts on your system.
My sshd_config man page says it is processed in this order:
DenyUsers, AllowUsers, DenyGroups, then AllowGroups.

If you specify multiple AllowUsers (or any other) it will compound them.

Here's some examples of setups.

If I want everyone in group admin but user hazcheezburger to have access while everyone else is denied

Code:
AllowGroups admin
DenyUsers hazcheezburger
Multiple options are permitted.
Users alice and bob are permitted, everyone else is denied.

Code:
AllowUsers alice bob
Wildcards are permitted as well. * means any or all. ? Meaning anything for that character
! negates the option.
This will deny all groups starting with user_ and permit user alice but not bob from accessing

Code:
AllowUsers ?????
DenyGroups user_*
You do not want user bob connecting but wish to permit alice and charlie (yes, denyuser would the better method of doing this)

Code:
AllowUsers !bob alice charlie
SSH deals with network connections. Oftentimes, people will connect from one ip address. If they connect from another one, that could indicate a risk.
Let's ensure the user backup_files (a automated user that connects from 72.45.21.664) can only login from one address.
However, we want to ensure user sam can login from any lan address
Code:
AllowUsers backup_files@72.45.21.664 sam@192.168.1.*
Now let's make sure sam can login from lan and his work ip, 23.432.36.1. However, the local ip 192.168.1.20 is known to be extremely insecure, so we won't let sam login from there

Code:
AllowUsers sam@192.168.1.*,23.432.36.1,!192.168.1.20
Let's make a bad example. I'm trying to block user hacker in group evil who uses a lan connection but want to permit everyone else to access via lan.

Code:
AllowUsers *@192.168.1.* !hacker
This will permit hacker to login. Do you know why? I'll post the answer later.
____________________


Matching statements

Sometimes we want fine-grained control of what goes on. While the Allow/Deny options are useful, they are sweeping in that the two possible options are to deny or permit access.

This is where using Match comes into play. Remember to ensure these are placed at the bottom of the file, to prevent overruling.
Also, not all config options can be changed. Look through man sshd_config for full list & make sure to test your sshd config

There are a few possible options. There are more, but I see these to be the most useful.
  • Address
  • User
  • Group

Address refers to a ip address (e.g. 192.168.1.25) and hosts refer to dns lookup.
Someone from linuxquestions.org logging in? Use Host to modify their login.

To write a generic match statement, it goes like this

Code:
Match Filter Argument
    Option Argument
The best example of using addresses to match is to ensure external connections cannot use passwords, but local connections can use passwords
This will set a default of no password auth, but anyone connecting from 192.168.1.* is permitted
Code:
PasswordAuthentication no

Match Address 192.168.1.*
    PasswordAuthentication yes
alice & bob are permitted to use X11 forwarding, however the default is set to deny.

Code:
X11Forwarding no

Match User alice,bob
    X11Forwarding yes
Groups work in a similar way and can be combined with other options.
Let's permit groups admin or homework or user alice to use x11 forwarding

Code:
X11Forwarding no

Match Group admin,homework User alice
    X11Forwarding yes
These options can be combined for specialized purposes.

Generally, the security risks of X11 forwarding are reduced in the lan network. But the only users who need it belong in group gui.
I will also give everyone in the lan network permission to use password authentication
Notice if I combined the below Matching statements, it would only permit those in lan and group gui to use pass auth. Everyone else would not be permitted.


Code:
PasswordAuthentication no
X11Forwarding no

Match Group gui Address 192.168.1.*
    X11Forwarding yes
Match Address 192.168.1.*
    PasswordAuthentication yes
Here we mandate that banners will be displayed to all users except those in the group nobanner.

Code:
Banner none

Match User * Group !nobanner
    Banner /etc/banner
________

3 Complex examples

1.

Let's say you are setting up the ssh server for the main connection between external and internal connections for a school. Administrators in the group admin are permitted to login from anywhere
but must not use x11 forwarding or passwords if from a external network. Students in the group student must be within the lan to connect, are permitted to use password auth but
not permitted to use x11 forwarding. There is a IT support tech that manages schools up and down the district who must have x11 forwarding access from her home address (32.65.435.63) lan and work ip which may vary but
will start with 92.45.13., her username is sally and is part of the admin group.
Everyone else should be denied

Code:
X11Forwarding no
PasswordAuthentication no

AllowGroups admin student@192.168.1.*

Match Address 192.168.1.* Group admin
    PasswordAuthentication yes
    X11Forwarding yes
Match Group student
    PasswordAuthentication yes
Match User sally Address 192.168.1.*,32.65.435.63,92.45.13.*
    X11Forwarding yes
2.

A individual uses his home computer to write documents for his business. He wants to be able to access this from his work with a ip address of 24.562.2.526 but sometimes will connect
from the local cafe which has the ip of 75.743.1.632. He trusts the security of his work network so password auth is ok but does not trust the cafe, which should be key based.
He will be the only user ever connecting to this computer and the server should never permit any other user from accessing, nor should anyone be able to access the server from
any other ip address. His username is uplink

Code:
PasswordAuthentication no

AllowUser uplink@24.562.2.526,75.743.1.632

Match Address 24.562.2.526
    PasswordAuthentication yes
3.

A group of people use ssh in their building to login to each other's computer for work. One of them will be going to another country for a few months to work on a project.
Let's ensure he can continue to do his job, however we must make sure no one else can access via external network. He will be using key based auth but passwords are acceptable in lan.
He doesn't know what ip he'll be connecting from but plans to followup with the info. his username is rocker

Code:
PasswordAuthentication no

AllowUser *@192.168.1.* rocker

Match Address 192.168.1.*
    PasswordAuthentication yes
Later on, you notice in the logs rocker is connecting from 999.23.53.1. He confirms he will be consistently connecting from this ip. He is using key based auth, which is secure,
however you decide to update the config to be safe. If someone manages to get his private key, it will be useless unless from the one ip address.

Code:
AllowUser *@192.168.1.* rocker@999.23.53.1
_____


Password based Authentication open to external networks.


Pretty much every guide out there says do not permit passwords to external ips. I agree.
But people need it sometimes. Before you set it though, think for a moment and answer these questions:
  • Do you need ALL users to be able to login with password from anywhere? Maybe just one user?
  • Would it be ok to permit passwords in the lan, but restrict users using passwords from external ip's?
  • Will users be using the same network to connect from? Would it be ok to restrict passwords to limited ip's?

Also, if you have to use passwords for external ips...
Make sure to use a strong password and additional protections such as banning programs when too many invalid attempts are made
Even a 5 minute ban on a ip after 3 guesses can be the difference between being cracked and making the attack too expensive to pursue.
There are a assortment of easy to use and effective programs out there. I use fail2ban. A 5 minute ban will not ruin your day. A hacked computer will.

If you have a username of miati (don't use something easy, like admin)

Code:
PasswordAuthentication no

Match User miati
    PasswordAuthentication yes
or to only permit one user to login

Code:
PasswordAuthentication no

AllowUser miati

Match User miati
    PasswordAuthentication yes

Last edited by Miati; 01-10-2015 at 12:54 PM.
 
Old 01-10-2015, 05:17 AM   #2
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,415
Blog Entries: 55

Rep: Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600
While I applaud you for documenting by example (always a good thing)
Quote:
Originally Posted by Miati View Post
(..) Connecting via password (..) Generally, the security risks (..) are reduced in the lan (..) give everyone in the lan network permission to use password authentication (..) He trusts the security of his work network so password auth is ok (..) passwords are acceptable in lan. (..)
and while everyone knows users like the convenience of (simple, easily to guess) passwords still I don't agree with skipping over pubkey auth that easily. Also recent breaches of security have again shown the mindset of certain admin folk that the "LAN == safe" idea (aka "hard on the outside chewy on the inside") without need for auditing, network separation, proper access controls and immediate response is an idea that needs eradicating swiftly.

Realizing pubkey auth shifts part of the responsibility to the user and that a user may not 'pwgen -1 -s -c -n -N 1 -y 16;' properly, still pubkey auth:
- requires only one pass phrase entry per user session using ssh-agent or keychain,
- is based on both what you know and have,
- does not expose credentials inside the SSL channel,
- allows you to grant access without giving users the accounts password,
- allows you to restrict movement to one or more commands,
- annuls password guessing,
- makes for easy access management across multiple servers.

*Please note this isn't "textbook" but practical experience. This is how we've done things for years now. Admins adhere to this because they've been tasked with keeping our infrastructure secure. Users adhere to this because they've tasked us with keeping their data secure.
 
Old 01-10-2015, 10:18 AM   #3
Miati
Member
 
Registered: Dec 2014
Distribution: Linux Mint 17.*
Posts: 326

Original Poster
Rep: Reputation: 106Reputation: 106
Quote:
While I applaud you for documenting by example (always a good thing) .. I don't agree with skipping over pubkey auth that easily. .. Admins adhere to this because they've been tasked with keeping our infrastructure secure. Users adhere to this because they've tasked us with keeping their data secure.
In order to make examples, I have to create situations of why I'm setting something up a certain way. Otherwise I'm throwing random code with only my understanding of any of it.
I have no experience setting up a ssh server for a school, but I needed a plausible example so I could write the config for it. It's defintely not a example of how to make a school as secure as possible, but as secure as possible with the critera specified.
Public based authentication has and will be much more secure then password based, and there are plenty more of excellent reasons to use pub keys as you mention. As I mention in my post, just about every guide out there saying "secure your ssh server" begins with "here's how to make your ssh-key".

But then I'll read another person mentioning ssh isn't as good as windows server something or another because it doesn't permit password usage in lan addresses, or another user getting hacked because he wanted to use passwords in his home network but also wanted access from external addresses & inadvertenly created a huge security hole. Or another person asking for help with setting up exactly that, and the only responses are to use public key auth, it's the only way to go. It's the best way, but it doesn't really help the person who probably has heard about pub key plenty already, but has their own reasons for why they haven't yet, technical or just stubborn.

So hopefully what I wrote will assist in creating a middle ground between permitting passwords everywhere or public key everywhere.

Obviously, what I wrote can be used in other purposes as well dealing with less security related issues. e.g. banners.

Last edited by Miati; 01-10-2015 at 12:53 PM.
 
1 members found this post helpful.
  


Reply

Tags
ssh


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
Billing & Invoicing Software for Clients with Multiple Matters & Monthly Statements Bob Jones Linux - Software 2 02-12-2012 12:21 PM
Slack 13.37 - Securing the SSH & SSHFS access from the outside OldLodgeSkins Slackware 5 09-27-2011 09:33 AM
How to make PAM give a message when denying ssh access brobeck Linux - Security 7 10-25-2009 08:09 PM
Bash: Problems testing multiple statements with logical and (-a or &&) AncientPC Programming 4 04-14-2008 12:16 AM
vsftpd + denying & allowing IP's kurrupt Linux - Security 1 10-17-2006 03:34 AM

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

All times are GMT -5. The time now is 08:24 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
Open Source Consulting | Domain Registration