You are here: Home » Topic » Failed Authentications

Failed Authentications

This topic contains 7 replies, has 2 voices, and was last updated by  rpedde 12 years, 3 months ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #1113

    mas
    Participant

    mt-daapd has a quite verbose log even at standard loglevel.

    But wrong authentications are just logged with a standard message, not indicating from what IP etc. the login came. And no discimination whether someone has given no password or a wrong password.

    And I of course at least want to see if someone hammers it with a dictionary.

    Could that be changed to a more sensible behaviour? Perhaps logging access attempts that gave a WRONG password via syslog ideally, so that it gets put into auth.log where it belongs?

    #9227

    mas
    Participant

    Ok, that I managed myself with my limited abilities (after some looking around.

    src/webserver.c:

    REPLACE:
    if(auth_handler(pwsc,username,password))
    can_dispatch=1;

    WITH:
    if(auth_handler(pwsc,username,password))
    can_dispatch=1;
    else
    DPRINTF(E_WARN,L_WS,”Thread %d: Wrong password entered! (%d: %s)n”,
    pwsc->threadno,401,pwsc->hostname);



    Just a quick hack to ensure things get noticed at least. I am sure you can put that patch in much more elegantly, Ron.

    Now all we need is some way to have have mt-daapd store these wrongly logged in IPs and block logins if someone logs in wrong too often. Alternatively that could also be accomplished by an external proggy, e.g. denyhosts, which can scan logfiles and enter evil doers into hosts.deny. Then mt-daapd would have to somehow check against host.deny (could be done with libwrap?).

    Another idea would be to add a config option that makes it only allow computers listed in hosts.allow explicitly so one could limit the range of IPs that can access via a “mt-daapd: IP” entry in hosts.allow.

    #9228

    mas
    Participant

    Hey Ron,

    could you please put that simple patch in so that I dont have to patch every version manually before I compile it (as I did with the svn-1528).
    That logging of failed logins cannot hurt.

    #9229

    rpedde
    Participant

    @mas wrote:

    Hey Ron,

    could you please put that simple patch in so that I dont have to patch every version manually before I compile it (as I did with the svn-1528).
    That logging of failed logins cannot hurt.

    Okay. The auth stuff is going to change soon, so it’s not probably in its final form, but there is something in there now. (r1534)

    #9230

    mas
    Participant

    Thanks a lot. I would help out a bit more myself but after looking over the code its a bit too complicated for me so my abilities limit me to such simplistic approaches.

    #9231

    mas
    Participant

    Uhm, just compiled the Version svn-1549. But I am afraid this logging you put in isnt gonna help a lot.

    What it does when I do a correct login is it writes into both syslog and mt-daapd.log:

    Apr 22 22:12:39 schnecke mt-daapd[32203]: Checking NULL/NULL for admin
    Apr 22 22:12:39 schnecke mt-daapd[32203]: Checking /[pw] for admin

    So each CORRECT password authentication goes with the cleartext password into the log files.

    And if I do a wrong password login it looks like, you guess:
    Apr 22 22:08:37 schnecke mt-daapd[32126]: Checking /[wrongpw] for admin
    Apr 22 22:08:37 schnecke mt-daapd[32128]: Checking NULL/NULL for admin

    Nothing to discriminate this from a correct login. Plus I believe logging the PASSWORDS in cleartext is no good practice.

    It should log the IP-address there, NOT the passwords attempted. Also it would be preferably not to log correct logins into syslog – blows up the syslog a lot. Only faulty ones with a message indicating this was a wrong login attempt. Plus the ideal place to log these wrong loging on my debian slug would be auth.log even.

    But the cleartext correct logins going into the log files is IMHO even dangerous, even though the log shouldnt be world readable. Pls change that to log the IP not the passwords.

    #9232

    mas
    Participant

    And my mt-daapd.log is even by default world readable. UUUUhhh. No idea if that is because I messed with it a long time ago or if the make install installs it with the WRONG permissions. But world readable logs with cleartext passwords are not so good. Please check up on that as well.

    This is by the way how ssh logs things to auth.conf:


    Apr 16 20:23:57 schnecke sshd[14453]: Did not receive identification string from 61.51.17.161
    (Some asshole tried to login to my ssh server with empty pw)

    Apr 21 02:39:05 schnecke sshd[7249]: Failed password for invalid user admin from 208.70.255.64 port
    49033 ssh2
    (Some idiot trying to use a wordbook attack on the non existing user admin)



    The best thing would be to log it in a very similar way than ssh does, because then my denyhosts script could immediately block such IPs as I do block all these nerds trying their pathetic ssh breakin attempts. denyhosts also has a function to share these IPs world-wide so if someone tries to breakin on my computer they get blocked world-wide by all denyhost users. 😎

    My suggestion for a format to log these failed attempt would therefore be something like:
    Apr 21 02:39:05 schnecke mt-daapd[3453]: Failed password for user admin from 208.70.255.64 port 3689 mt-daapd

    #9233

    rpedde
    Participant

    @mas wrote:

    My suggestion for a format to log these failed attempt would therefore be something like:
    Apr 21 02:39:05 schnecke mt-daapd[3453]: Failed password for user admin from 208.70.255.64 port 3689 mt-daapd

    Erp… probably so. 🙂

    Should be logging successful ones, and I dropped the pw in there so I could see if it was doing first or second pass authentication, and then left it in there. D’oh.

Viewing 8 posts - 1 through 8 (of 8 total)

The forum ‘Feature Requests’ is closed to new topics and replies.