Jump to content
Mumble forums

fail2ban and how murmur logs login failues


12ecq34
 Share

Recommended Posts

Using the murmur-static_x86-1.2.10 binary package on Centos 6.5, I'm noticing that murmur will not log, on the same line, the host which was involved in failed login attempts. I read multiple threads, like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627139, but it appears that this fix was not integrated with the binary archive 1.2.10.


Failed logins are logged like this:

 

<W>2015-07-11 09:46:13.442 1 => <1:(-1)> New connection: 71.193.152.137:38360
<W>2015-07-11 09:46:13.593 1 => <1:(-1)> Client version 1.2.8 (X11: 1.2.8-1~ppa1~utopic1)
<W>2015-07-11 09:46:13.595 1 => <1:testuser(-1)> Rejected connection: Invalid server password
<W>2015-07-11 09:46:13.598 1 => <1:testuser(-1)> Connection closed:  [-1]

 

As an example of how the error should be logged, here is the regex which fail2ban would be using to identify abusive hosts:

 

^\<W\>.*Rejected connection from <HOST>:\d+: Wrong password for user$

 

Note that the message changes from 'Rejected connection:' to 'Rejected connection from :'. Is there something that I'm just doing wrong, or maybe there are some trusted RPMs available in a repo somewhere? I only saw some random RPMs hosted on dropbox or some other site, and was not comfortable trusting prebuilts in that manner.

Link to comment
Share on other sites

  • Moderators

What are you trying to accomplish with fail2ban? Murmur includes it's own auto-ban which helps hinder DDoS and makes online brute force extremely time consuming.

Full disclosure: I used to run a commercial Mumble host, and my opinions do not reflect the opinions of the Mumble project.

Avatar is stolen from here

Link to comment
Share on other sites

What are you trying to accomplish with fail2ban? Murmur includes it's own auto-ban which helps hinder DDoS and makes online brute force extremely time consuming.

 

I want to achieve a consistent security layer across all my exposed services. I utilize fail2ban to make sure that folks that are privy or smart enough to find out what services I run, who then turn around and attempt to harass or abuse them, are quickly banned. It does an excellent job protecting my other exposed services, I'd like to extend its coverage to murmur.


I've taken steps to mitigate flooding via firewall rules, but having protecting against drawn out brute force attacks (and I only allow certificate-based users to join) is also a necessity.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...