Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

fail2ban is a protection against brute-force that locks a user out after a definable maximum failed login-attempts.

But if a user already has access to a server with another username already fail2ban is not active anymore from the inside, so you have infinite tries to brute-force with

slogin otheruser@localhost

into another useraccount.

  • Is there a tool I could install on linux that kicks a user after a number of failed local ssh-login attempts?
  • And how do I have to configure it so a user gets kicked after 10 false attempts?
share|improve this question
add comment

3 Answers

You can use fail2ban for this also. It is very configurable. In this case, you would need to write a new filter to watch your auth logs. You can use the <HOST> shortcut to match usernames, too, since those ought to conform to "hostname" parameters. You would also need to write a new action to perform the kick. The fail2ban manual has lots of good information to get you started.

As another example of extending fail2ban, I set up a filter to watch fail2ban's own logs. If any 1 host triggers any combination of bans more than 4 times in a month, they get a month-long ban.

share|improve this answer
    
I altered the question. The main reason I ask here and don't just RTFM is because I get overwhelmed by the amount of information in the manual :) So how would I have to change the default configuration of fail2ban? –  rubo77 Oct 8 '13 at 6:07
add comment

if you already have fail2ban deployed, go with it, otherwise and for larger setups, OSSEC is always good for host-based intrusion detection.

Maybe a start: Looking for the best way to log all "sudo su - someuser".


so kid, you neva herd 'bout the BOFH, didnt ya? otherwise you'd know about the "Bastard Operation Control Center"; another tool to suggest would be a LART

related:

share|improve this answer
add comment

sligtly OT: SU would be a reason to kick a user forever; use SUDO instead, so you dont have to give out the root-password.

this is what we do:

  • we have a lot of different developers on our servers
  • we have a limitted set of tasks that needs SUDO-rights, like services test/restart, cleanups etc
  • we have a simple task-shell for users to select and perform these commands via bash (its called bosh : bastard operator shell :); this also prevents stupid things like RESTART instead of RELOAD or a forgotten CONFIG_TEST before a RELOAD
  • those without shell-accounts can execute some tasks via hudson
  • we have a special workshop for that users and additional, up-to-date documents available in a wiki
  • ALL sudo/su attempts are logged and reported
  • if one shell-user tries to su or sudo he must report WHY and face the LART
  • each shell-user has signed a "i know i'm doomed if i try to h4xor something" agreement
  • we let every user know that we monitor their steps
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.