Access control with TCP-wrapped SSH
- Palavi Karnik
- Aug 17, 2024
- 3 min read
We find ourselves drawn to iptables and ipsets for their remarkable functionality today, but it doesn't change the fact that several relatively old servers and hosts may rely on a hybrid mix of the two (iptables and TCP wrappers) even today. Which makes it imperative for us as system administrators to thoroughly understand how the seemingly ancient access control solution is configured.
TCP-wrapped services can be configured globally or in their respective service configuration files. Taking SSH as an example service for this tutorial, we will dive into:
Whitelisting a host in /etc/hosts.allow
Blacklisting a host in /etc/hosts.deny
Different configurations of /etc/ssh/sshd_config and their precedence order
1. Whitelisting a host in /etc/hosts.allow
In your preferred text editor, open the '/etc/hosts.allow' file. The entries here are colon delimiter-ed.
The first field being for the daemon corresponding to the service your whitelist is intended for. You may choose to leave it at 'ALL' should you wish the change be applicable to all services.
The second field defines the hostname or IP address you whitelist.
daemon: host IP address
Ensure restarting the service for the changes to take effect.
Verify by SSH-ing to your machine through the whitelisted host. This can be checked in the brief SSH logs obtained with 'systemctl status ssh'.
Log in from the whitelisted host IP (192.168.56.1) is thereby successful.
2. Blacklisting a host in /etc/hosts.deny
Syntax is the same as that for /etc/hosts.allow.
daemon: host IP address
Restart the service before verifying the service status.
Log in from the blacklisted host IP (192.168.56.1) is thereby refused.
3. Different configurations of /etc/ssh/sshd_config and their precedence order
We may choose to control access using these four parameters in /etc/ssh/sshd_config file:
AllowUsers
AllowGroups
DenyUsers
DenyGroups
We will demonstrate this with our four users- Alice, Bob, Tom and Harry.
Alice and Bob are users whose primary group is set to 'accounts'.
Case 1. AllowUsers for one user is set
If say, we add 'AllowUsers Tom' to our /etc/ssh/sshd_config file:
Then, as can be seen below, Alice, Bob and Harry are 'denied permission' while Tom can successfully log in. This can be seen in the SSH status logs.
Alice, Bob and Harry are not allowed because they are not listed in AllowUsers.
Case 2: AllowUsers for one user is listed, along with AllowGroups for one group
In this case, we get a less intuitive result with neither Tom nor Alice and Bob (users in 'accounts' group) being allowed to log in.
Tom is unable to log in because he isn't listed in AllowGroups while Alice & Bob (users in 'accounts' group) are unable to log in as they aren't listed in AllowUsers.
Case 3. AllowGroups is listed, AllowUsers being commented out
In this case, Alice and Bob (members of 'accounts' group) are allowed their SSH session while Tom and Harry remain locked out.
Only the members of the group listed in AllowGroups i.e, Alice & Bob from accounts group are allowed to log in.
Case 4: AllowUsers and DenyUsers is listed for the same user
This is where the precedence order takes effect. 'DenyUsers' is applicable regardless of its set 'AllowUsers' counterpart.
We can verify the same below.
Permission is denied. For better insight, we can refer to the logs.
This gives us adequate clarity as to why the login was unsuccessful.
As rightly assumed, it is because we listed Tom as DenyUsers, and because DenyUsers takes precedence over AllowUsers.
Case 5: AllowGroups is listed for a group but with one of its members listed in DenyUsers
We list Bob for DenyUsers here, although listing the group he is a part of- accounts, in AllowGroups.
We then test our modified configuration's effect on Alice and Bob.
Once again we see that 'DenyUsers' clearly takes precedence, as Bob cannot log in.
Inference:
Comments