This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SMTP Login - I hope this is not standard behaviour

Hello,
In my SMTP proxy I have set 3 hosts in Host Based Relay that are authorized to use the built-in SMTP server. I have noticed that if a user tries to send mail throught Astaro, my asg queries the active directory in order to see if the user is authorized or not to relay, even if its ip address is not listed in Host Based Relay. The result of this is that my astaro was under attack (thousands of smtp transaction, all of these failed cause of unallowed user/password) and my Domain Controller received a lot of query. 

Is it normal? How can I block ip if they fails login attempts?

Thank You
eclipse79


This thread was automatically locked due to age.
  • Look on the 'Relaying' tab to be sure you do not have 'Allow authenticated relay' checked.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Look on the 'Relaying' tab to be sure you do not have 'Allow authenticated relay' checked.



    Hi bob, 
    My actual configuration is this:

    - 3 hosts allowed to send mail
    - 2 LOCAL users allowed to send mail

    Considering that only LOCAL users are allowed to send mail (so no AD users), in my opinion is not correct that everytime a remote users tries to login astaro contact the AD. I think that the correct flow would be this:

    1) Remote user sends username and password
    2) Astaro checks if username is listed in "Allowed users/ groups"
    2.1) If username is listed, astaro should contact the authentication provider of the user (local provider in case of local user, AD provider in case of remote user)
    2.2) If username is NOT listed, astaro should deny the connection without query to authentication provider.

    What do you think about?

    Anyway, i think that the absence of auto-ban ip address in case of failed logins in a unacceptable lack of security. I request this feaure here:
    http://feature.astaro.com/forums/17359-astaro-gateway-feature-requests/suggestions/690018-ban-ip-address-for-x-minutes-if-login-fails?ref=title
  • How do you check if a user is in a AD group if you don't contact the AD?! It could have been updated and the user might not even exist anymore. Relying on caching is not the way to deal with this I think.
  • How do you check if a user is in a AD group if you don't contact the AD?! It could have been updated and the user might not even exist anymore. Relying on caching is not the way to deal with this I think.


    Krycek, I have said that the only 2 allowed users are LOCAL USERS. So what is the need to contact AD?! In my opinion the logical flow is not optimized...
  • I must have skipped that line... sorry!

    But you still said it should only contact the AD server if the user is listed which sometimes doesn't work because it might only be a group and the astaro might not yet be aware that the user exists.

    I agree that this might need some improvement.
  • Is there a real need to authenticate the two users to allow them to send through your Astaro?  You have two mail servers, yet these users don't have relay rights off either server?  At present, would it work better to NOT allow the users to relay, but to make packet filter rules blocking other port 25 traffic except for these two users?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Is there a real need to authenticate the two users to allow them to send through your Astaro?  
    Cheers - Bob


    Hi Bob, unfortunately there is a real need to authenticate the two users because they use mobile phones from internet (the phones are only able to comunicate with SMTP/POP3 account). So my need is real need [:)]
  • You have two "Local" users who connect via the internet to relay mail off your Astaro but not off one of your mail servers? What advantage does that offer?

    CHeers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • You have two "Local" users who connect via the internet to relay mail off your Astaro but not off one of your mail servers? What advantage does that offer?

    CHeers - Bob


    Bob, I think that there is something that I don't understand. Until 1 month ago I didn't use astaro as SMTP proxy. So these two users connected (from internet) to our smtp server in DMZ giving their own user/password, and could send email to internal/external email recipients. Astaro forwarded the packets directed to port 25 to our SMTP server in DMZ. Now that I use SMTP proxy all the connections to port 25 are managed by ASG, so there is no NAT for port 25 anymore. In this case, I think, the only way to let these two mobile users to send email using our "networing systems" is to use ASG as mail server. Am I wrong? Is there another method to contact our DMZ server from internet even if SMTP proxy is active? What would be the best configuration in your opinion?
  • If I understand your situation, I think the DNAT you had before would work if you created an Additional Address on your External interface and had them "aim" at that instead of your primary IP.

    I don't know if the Astaro insists on capturing all traffic that hits the interface regardless of the IP.  If it does, then you'll need to have them use a different port (SMTP-Alt is 587) and change the DNAT to 'Any -> SMTP-ALT -> External (Address) : DNAT SMTP to {mailserver}'.

    In this way, they will be authenticated by the mail server and you can disable user auth for the SMTP Proxy.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA