Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hello.
I like to limit SSH connection to my server that use "CentOS release 6.6 (Final)". I Google it and found two ways: 1- use "hosts.allow" file 2- use "sshd_config".
Which one is better and more easy?
The latter. tcpd aka tcpwrappers support is discontinued in modern versions of OpenSSH server. You can do the same filtering with iptables instead. However, to keep everything in one place, you can modify sshd_config to accept or block connections from specific IPs. You might even put it inside a Match block. See the manual page for sshd_config for the authoritative specifics.
my personal preference is to use ipsets with iptables, works well on CentOS 6, but there have been issues with the ipset package in RHEL/CentOS 7.
With ipsets, instead of having to set-up a rule per ip, you can set rules per ipset and then add ips to the ruleset. For example you could do the following to get two groups for admins and developers with everything else blocked.
ipset -N admins iphash
ipset -A admins 10.0.0.10
ipset -A admins 10.0.1.10
ipset -N developers iphash
ipset -A developers 10.1.0.15
ipset -A developers 172.16.23.72
iptables -I INPUT 3 -m conntrack --ctstate ESTABLISHED -j ACCEPT
iptables -I INPUT 4 -m set --match-set admins src -j ACCEPT -m comment --comment "Admins ipset group can connect all"
iptables -I INPUT 5 -p tcp -m conntrack --ctstate NEW --dport 22 -m set --match-set developers src -m limit --limit 12/hour --limit-burst 5 -m comment --comment "5 login attempts every 5 minutes" -j ACCEPT
iptables -I INPUT 6 -j DROP
of course to get to this level you would have to learn iptables and ipset but it gives you very explicit control over what you allow and do not allow to connect. To be fair the limit module still leaves me a tiny bit confused.
Last edited by r3sistance; 02-07-2017 at 08:28 AM.
I'd be tempted to do it at iptables level as it's closer up the chain. That way you can block/reject/drop the traffic before sshd even has the connection to consider.
Then add layers, the more layers the better.
For example it's possible within .ssh/authorized_keys specify that a key is only valid from a specific IP address.
For example it's possible within .ssh/authorized_keys specify that a key is only valid from a specific IP address.
oh yes! Good point, you can also use DenyUsers and AllowUsers within the SSH configuration to lock down the users. My test box is down at the moment and don't have accessibility to my work test boxes from home but I would usually do something like...
printf "DenyUsers " >> /tmp/denies
# awk -F":" '{print $1}' | tr '\n' ' ' >> /tmp/denies
EDITOR /tmp/denies
-- manually move users you do want to allow, to next line with an AllowUsers
cat /tmp/denies >> /etc/ssh/sshd_config
rm /tmp/denies
restart ssh and test. This way you further fine tune down the security.
oh yes! Good point, you can also use DenyUsers and AllowUsers within the SSH configuration to lock down the users. My test box is down at the moment and don't have accessibility to my work test boxes from home but I would usually do something like...
printf "DenyUsers " >> /tmp/denies
# awk -F":" '{print $1}' | tr '\n' ' ' >> /tmp/denies
EDITOR /tmp/denies
-- manually move users you do want to allow, to next line with an AllowUsers
cat /tmp/denies >> /etc/ssh/sshd_config
rm /tmp/denies
restart ssh and test. This way you further fine tune down the security.
Nooooooo......
Create a group "sshusers", use AllowGroups sshusers in your sshd config and then just add sshusers as a secondary group to the users allowed access.
Create a group "sshusers", use AllowGroups sshusers in your sshd config and then just add sshusers as a secondary group to the users allowed access.
Fair enough, either way an extra layer of protection to lock down users. I just work with people who would probably get lost if we did it by group unfortunately, more so the junior technical engineers. Tho where I work we also lock things down on hardware or virtual firewall devices too, depending on the customer set-up, even more layers.
Last edited by r3sistance; 02-07-2017 at 05:09 PM.
I just work with people who would probably get lost if we did it by group unfortunately, more so the junior technical engineers.
Sad and strange to hear. Assigning permissions at group level has been established best practice for decades, for what should be obvious reasons. If they can't handle groups, they should not have accounts until they prove themselves capable at remedial training or their replacements can be hired and the old accounts removed instead. This isn't about "security", this is about basic concepts needed to operate the machines they have gotten into. A metal shop makes sure anyone on the floor is both qualified to operate the equipment and follow best practices. This is not much different, just digital.
Sad and strange to hear. Assigning permissions at group level has been established best practice for decades, for what should be obvious reasons. If they can't handle groups, they should not have accounts until they prove themselves capable at remedial training or their replacements can be hired and the old accounts removed instead. This isn't about "security", this is about basic concepts needed to operate the machines they have gotten into. A metal shop makes sure anyone on the floor is both qualified to operate the equipment and follow best practices. This is not much different, just digital.
Tell me about it, I unfortunately am not responsible for recruiting. Management don't value engineering skills highly and look to always do what is cheapest rather than what is best meaning we get people who many have never had a real IT job before, let alone experience with Linux.
Well the team I am in, we are constantly complaining about many MANY issues. I couldn't really respond to this earlier while I was at work for obvious reasons but honestly every company has issues and if not for our sys admin teams (of which I am in one) the company would have failed a long time ago... anyways not gunna hi-jack this thread too far away. I am instead looking at other jobs.
Sorry apologies about doing things in a bit of a too simplistic way instead of a more functionally correct and secure method, the mindset is a bit off from where I'd like it to be sometimes.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.