2

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?
Improve this question
0

3 Answers 3

Reset to default
7

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.

Improve this answer
1
  • 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
    Commented Oct 8, 2013 at 6:07
3

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:

Improve this answer
0
1

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
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .