Warning / Event ID: 521 | MDaemon Technologies Community Forum
  1. Forum
  2. MDaemon
  3. Warning / Event ID: 521

Warning / Event ID: 521

  • J

    I am seeing randomly generated IP addresses being used to bypass the consectutive IP connection restriction.  I suppose this is impossible to defend against.  I do require a 16 character password on all accounts and Location Screening is active, but still thousands of these occur every week.  Is this something others just ignore for users using email clients?

    Thanks,

    mux

    0 likes
  • A

    Are the connections allowed to attempt Authentication?  What protocol are they using?

    Ideally, you want to block them as quickly as you can.  I'm assuming you have Location screening configued to only Block authentication for SMTP, in which case the session is allowed to occur and can still burn resources even though they can't successfully authenticate.  I'd suggest using the option for Add IP to Dynamic Screen if AUTH attempted when disabled.  Since IPs are changing, it may not help, but it will at least prevent the attacker from re-using IPs. (Security | Security Settings | Screening | Location Screening)

    Block as many countries as you can with location screening.  If you have users that need to authenticate and bypass location screening there are options to bypass it for known ActiveSync devices and using two factor authentication for webmail.

    Configure MDaemon to reject inbound SMTP sessions that do not have a PTR record.  (Security | Security Settings | Reverse Lookups) Check the box for Perform reverse PTR record lookup on inbound SMTP connections and Send 501 and close connection if no PTR record exists.  You will need to uncheck Exempt authenticated sessions.  This can cause issues if you have clients connecting via the internet from IP addresses that do not have a PTR record setup.  

    You should also enable the options to perform lookups passed on the HELO/EHLO domain, and MAIL Command.  For the mail command, enable Refuse to accept mail if a lookup returns 'domain not found'.

    Use the default host screening values. (Security | Screening | Host Screen) Check the boxes for apply host screen to MSA connections, drop connection on host screen refusal, and drop connection after EHLO. The default values should be similar to this:

    all localhost refuse
    all friend refuse
    all user refuse
    all ylmf-pc refuse
    all -* refuse
    all *_* refuse
    all #.#.#.# refuse
    all *.invalid refuse
    all */* refuse
    all *|* refuse
    all <default> refuse

    If your MDaemon\app\hostscreen.dat file is empty, delete the file and restart MDaemon, it should recreate the file with the default entries.

    For SMTP Screening, enable block IPs that connect more than X times in Y minutes.  Then adjust X and Y to be as aggressive as you can set in your environment without interferring with actual users.

    Enable Dynamic Screening (Security | Dynamic Screening).  Block IP addresses after A authentication failures in B minutes.  Set A and B, along with all the other settings, as aggressively as you can in your environment without interferring with users.

    Make sure HiJack Detection in configured in case they are ever able to guess a password, this will limit the amount of mail they can send.

     

    --
    Arron Caruth

    0 likes
  • J

    Thank you for the suggestions, Arron.

    Yes, it appears they are all failing authentication with SMTP.

    I have a large number of countries blocked in Location screening.

    I also found a setting for Hijack Detection.

    "Limit access to [xx] connections from differing IPs in [xx] minutes"

    If I set this to 5 connections within 30 minutes. Does this mean just connections or does this mean if the account has been compromised and accessed?  Should I check the disable account box?  That would mean the actual account user would be locked out until an admin intervened.  Is the postmaster notified when this occurs to give them the opportunity to address the situation quickly?

    Thanks again,

    mux

    0 likes
  • A

    "Limit access to [xx] connections from differing IPs in [xx] minutes"

    In order for this limit to be enforced the connections must authenticate. If it were applied to connections that have not authenticated it could be used to deny a user access to their account and would be considered a denial of service attack.

    Should I check the disable account box?  That would mean the actual account user would be locked out until an admin intervened.  Is the postmaster notified when this occurs to give them the opportunity to address the situation quickly?

    Are you referring to the option to Freeze accounts?  Freezing accounts is slightly different than disabling.  When an account is frozen you cannot authenticate as the account, but the account can still receive email.  Disabled accounts cannot receive email.

    I would proceed with caution when it comes to freezing accounts.  It can easily become an inconvience for users. In my opinion, you only want to freeze an account if you know its been compromised.  The values can easily be set too low for limiting access to different IP addresses. In many cases connections come from more IP addresses than you expect.  If you know you do not have the values set to low and want the extra level of security, then absolutely enable it.

    Freezing an account causes a notification email to be sent to the global administrators and domain administrators.  Administrators can reply to the email to unfreeze the account.

     

    --
    Arron Caruth

    0 likes
Please login to reply to this topic!

Participants