|This forum is proudly powered by Scientific Linux 6||SL website Download SL Help Search Members|
|Welcome Guest ( Log In | Register )||Resend Validation Email|
Posted: Aug 31 2011, 04:23 AM
Member No.: 127
Joined: 6-May 11
So I've read that, in addition to using a long and secure password, it is also helpful to set a time delay (say, 5 seconds) between password login attemps (SSH or anything else that requires password login). Also, one might set it up so that after a certain number of failed attempts, login will be disabled for another set amount of time (e.g. 24 hours).
How can this be setup on a SL system? If the method varies greatly, a SSH login example would be great.
Finally, is this really an effective secuirty measure?
Posted: Aug 31 2011, 10:42 AM
SLF Senior Administrator
Member No.: 2
Joined: 8-April 11
Can't tell you how to set this up. But, looking at from a statistical point of view, it will never be 100% adequate. IF they want to break your system, they will succeed. But than they would need your system at their place.
For external safety I believe it will always be helpful. But don't depend on it, expect it to be enough. In order to keep the crackers out, you need to think like one. Compare it to a car thief wanting to steal a car. If he has the choice for a "normal" one or one that has one of those buggy bars attached to the steeringwheel, he will almost certainly go for the "normal" car.
You might want to have a look at this topic on practical tips how to secure SSH.
Desktop: ASUS P5QPL-AM, Intel Dual-Core E6500, 4GB DDR2, ASUS GeForce GT 430 1GB, SL7.1 MATE x86_64
Build server: HP Proliant ML350 G5, Intel Xeon Quad-Core E5410, 16GB ECC DDR2 FB-DIMM, ASUS GeForce GT 730 1GB, SL7.1 MATE x86_64
Posted: Aug 31 2011, 12:48 PM
Member No.: 4
Joined: 8-April 11
linux security is really wide theme and you can set it up service-wise (if possible - like with sshd) or OS-wise in the:
4. any special tool (fail2ban)
5. anything that i forgot now
In your case, if it is ssh securing, check:
AllowUsers xxx yyy
3. iptables (this is not from my head, just googled it, but seams it could work, or work around this bases)
iptables -A INPUT -m tcp -p tcp -m recent --dport 22 --rcheck --seconds 30 --hitcount 2 --name sshlist --rsource -j LOG --log-prefix "SSH ATTACK: "
iptables -A INPUT -m tcp -p tcp -m recent --dport 22 --rcheck --seconds 30 --hitcount 2 --name sshlist --rsource -j DROP
iptables -A INPUT -m state --state NEW -m tcp -p tcp -m recent --dport 22 --set --name sshlist --rsource -j ACCEPT
That will block any ip that tries to connect more than twice in 30 seconds.
other good googled example:
iptables -A INPUT -m tcp -p tcp --dport 22 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m tcp -p tcp -s 10.1.0.0/24 --dport 22 -j ACCEPT
iptables -A INPUT -m tcp -p tcp --dport 22 -m state --state NEW -m limit --limit 3/min --limit-burst 3 -j ACCEPT
iptables -A INPUT -m tcp -p tcp --dport 22 -j DROP
The second line allows the hosts on the network block 10.1.0.0/24 to connect an unlimited number of times. Do this for hosts that you would normally connect from. Then, in an emergency, you can get in from another machine, as long as someone else isn't hitting the machine more than 3 times per second.
The 3rd line allows a burst of up to 3 SSH connection attempts from a given remote IP address, and once that's exceeded it will limit that IP to 3 attempts per minute. The burst recharges every time that the limit is not hit. This set of rules only gets invoked on the initial SSH connection establishment attempt, so it doesn't impact SSH connections after they are made.
4. /etc/hosts.allow and hosts.deny
if any particular q, ask further, it's really quite wide area to cover in forum post