Announcement

Collapse
No announcement yet.

Blocking legitimate mail users

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Blocking legitimate mail users

    We have a huge issue with Imunify blocking legitimate users.

    For example,

    There is an office with 10 people.
    1 user is entering a password incorrectly, triggering:

    Dovecot Invalid User Login Attempt.
    Exim Auth failed
    Dovecot brute force attack (multiple auth failures).

    This 1 user then gets the entire office IP blocked and 9 other people cant get their mail.

    cPHulk will actually block only the 1 offending mail user.

    How can we solve this?

  • #2
    Hi Mauritz,

    We are going to resolve this issue in our advanced bruteforce protection module (internal task id DEF-4079). Meanwhile, you can add the IP address into Imunify360 whitelist so no blocking will occur for it going forward.

    Comment


    • #3
      Hi,

      When is the Advanced Bruteforce Module scheduled for release? I know you cant say exactly, but are we talking days, weeks or months from now?

      Comment


      • #4
        Current ETA is Q42018

        Comment


        • #5
          Thank you.

          In the meantime, can we disable the rules being triggered and enable cPhulk until Q3 ?

          Comment


          • #6
            Yes, just re-enable cPHulk and it will make Imunify360 disable ossec IDS.

            Comment


            • #7
              Do we know if this has been implemented in 3.8.x already?

              This issue is killing us.

              Comment


              • #8
                Mauritz,

                No, it is not there in 3.8.x. Please, re-enable cPHulk if your are sure it is Imunify360 IDS (ossec) that causing the issue.

                Comment


                • #9
                  Hi,

                  Q4, 2018 has come and gone.

                  Is this still going to be implemented at some point?

                  Comment


                  • #10
                    This might be implemented (no confirmed ETA as of now) as part of mail protocols captcha - users will receive a custom response in their email agents with instructions how to unblock their IP. Another workaround can be to point a browser from an office IP to any http(s) website on the server and pass Imunify360 captcha - the office IP address will be added to Imunify360 whitelist upon that.

                    Comment


                    • #11
                      when?

                      this is a serious problem that needs to get fixed.

                      only way right now is to set ossec custom settings to crazy values like 60 attempts in 10 min.

                      Comment


                      • #12
                        you guys are over complicating this....

                        if there is more then X (2 to 5) users behind an IP authenticating correctly then whitelist that IP for 30 min with the counter resting on next good auth.

                        your software needs to stop blocking office of 200 people when one person has a bad password in there mail client.

                        this is a CRITICAL problem with your software, and needs attention ASAP.

                        I strongly suggest some effort is put into fixing this and less time put into features like multi server dashboard.

                        Thanks

                        Comment


                        • #13
                          Agree, this is still a nightmare for us as well. Running 30 servers with IM360 but have to disable exim and dovecot rules from ossec so that cPHulk can manage those properly, on a per-user basis instead of blocking the IP.

                          Sad but true.

                          Comment


                          • #14
                            Hi John,
                            This is a hard problem, we are working on it - but we have no ETA right now on when it will be solved.
                            Thanks!

                            Comment


                            • #15
                              Good day,

                              Just want to check if anything regarding this issue has been addressed in 4.2.x ?

                              Regards,

                              Comment

                              Working...
                              X