Oct 23, 2023: iRedMail-1.6.6 has been released.
- Spider Email Archiver: Lightweight on-premises email archiving software, developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.
- Join our Telegram group (@iredmail_chat) to get help from other iRedMail users.
SASL LOGIN authentication failed: UGFzc3dvcmQ6
iRedMail → iRedMail Support → SASL LOGIN authentication failed: UGFzc3dvcmQ6
Pages 1
You must login or register to post a reply
Posts: 4
1 Topic by laboratorio 2022-08-16 17:04:11
Topic: SASL LOGIN authentication failed: UGFzc3dvcmQ6
Hi,
We are getting a lot of annoying «warning: unknown[]: SASL LOGIN authentication failed: UGFzc3dvcmQ6» probably from spammers.
Is there an easy way to block this with fail2ban?
Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.
2 Reply by ZhangHuangbin 2022-08-17 10:03:47
Re: SASL LOGIN authentication failed: UGFzc3dvcmQ6
Fail2ban is configured to ban such client with jail /etc/fail2ban/jail.d/postfix.local.
3 Reply by laboratorio 2022-08-17 17:00:19 (edited by laboratorio 2022-08-17 17:11:32)
Re: SASL LOGIN authentication failed: UGFzc3dvcmQ6
ZhangHuangbin wrote:
Fail2ban is configured to ban such client with jail /etc/fail2ban/jail.d/postfix.local.
I’m afraid something is not working as it should. It looks like this:
Status for the jail: postfix
|- Filter
| |- Currently failed: 30
| |- Total failed: 1315
| `- File list: /var/log/maillog
`- Actions
|- Currently banned: 0
|- Total banned: 0
`- Banned IP list:
[postfix]
backend = polling
journalmatch=
enabled = true
filter = postfix.iredmail
logpath = /var/log/maillog
action = iptables-multiport[name=postfix, port=»80,443,25,587,465,110,995,143,993,4190″, protocol=tcp]
banned_db[name=postfix, port=»80,443,25,587,465,110,995,143,993,4190″, protocol=tcp]
sendmail-whois[name=postfix, dest=root@example.com, sender=fail2ban@example.com]
4 Reply by Cthulhu 2022-08-18 01:33:24
Re: SASL LOGIN authentication failed: UGFzc3dvcmQ6
iptables was dropped some time ago, iredmail uses nftables instead (which is common for any debian higher than 9.0)
aswell, seems that you have an own implementation since banned_db needs an API token and sendmail-whois is not configured by default
Posts: 4
Pages 1
You must login or register to post a reply
iRedMail → iRedMail Support → SASL LOGIN authentication failed: UGFzc3dvcmQ6
Currently installed 2 official extensions . Copyright © 2003–2010 PunBB.
Generated in 0.007 seconds (69% PHP — 31% DB) with 8 queries
Abuse — SASL LOGIN authentication failed: UGFzc3dvcmQ6
X.X.X.X is our IP. I don’t see any abusiveness or something wrong here, I don’t get the postfix part we don’t have any postfix server here and this ip is our users internet IP not any server, people use outlook. I see the same problem with one of my server (word press installed) someone hacked into the server and added scripts to send spam emails. but I don’t know how to read this log and investigate or what should I ask from ISP for more info.
Report from fail2ban Reported-From: [email protected] Report-Type: login-attack User-Agent: vaniersel.net abuse report Report-ID: [email protected] Date: Thu, 26 Apr 2018 01:55:17 +0200 Source: X.X.X.X Source-Type: ipv4 Destination: 94.x.x.x Destination-Type: ipv4 Attachment: text/plain Schema-URL: http://www.x-arf.org/schema/abuse_login-attack_0.1.2.json Category: abuse Service: smtp Port: 25 SASL LOGIN authentication failed: UGFzc3dvcmQ6 — Find the username
First let me state that the mail server is working fine and users can connect and send email. Basically there is a local web script connecting into the mail server trying to send mail every few minutes. It has the wrong password. Problem is we don’t know what script is connecting in so we are looking for a way to get the username which is being tried. UGFzc3dvcmQ6 — decodes to Password: so isn’t much help. A full log line is below.
Dec 11 20:15:37 HOST postfix/smtpd[642]: warning: HOST[x.x.x.x]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 Server is running Debian/Postfix/Dovecot.
asked Dec 11, 2010 at 21:47
3,107 5 5 gold badges 25 25 silver badges 33 33 bronze badges
I have the very same logs. The IP address alway changes, and requests are coming in from all over the world. It it more likely a break in attempt.
Sep 13, 2016 at 5:51
Good old UGFzc3dvcmQ6. Still trying to log in to my server from all over too after all these years. Just have to ignore it.
Dec 16, 2018 at 9:16
UGFzc3dvcmQ6 is ‘Password’ encoded in base64, I also see ‘VXNlcm5hbWU6’ which is ‘Username’ — been like that for years.
Oct 22, 2019 at 16:48
And years, and years, and years. when, oh when, will they ever give up?? I mean, these days, we even know what kind of attempt is being made, even without using a base64 decoder.
Aug 9, 2022 at 20:07
4 Answers 4
We were able to trace the username by using Dovecot itself.
In the /etc/dovecot/conf.d/10-logging.conf config we enabled verbose auth logging using
auth_verbose = yes This put the information in
/etc/dovecot/info.log 1,174 4 4 gold badges 19 19 silver badges 35 35 bronze badges
answered Jan 21, 2011 at 12:26
3,107 5 5 gold badges 25 25 silver badges 33 33 bronze badges
Shouldn’t the log be in /var/log/dovecot-info.log ?
May 8, 2016 at 23:52
Mine is in syslog
Nov 3, 2017 at 7:04
This method won’t always work — depending on how you setup things / how sasl and auth are done. Best to debug postfix if that is where you see bad auths. Debug peer list is best answer I’ve found. (below). It can also give you the LAN ip of client if that helps.
Oct 21, 2020 at 18:08
I was able to prevent this by setting up SSL and requiring auth attempts over SSL only with
smtpd_tls_auth_only = yes This doesn’t present the AUTH option to the remote client after EHLO and so the spammers/hackers give up because establishing a SSL connection is too much time. They work a numbers game. Now instead it hangs up when they try AUTH and I get this in my logs:
Jan 7 22:14:27 ip-99-99-99-99 postfix/smtpd[22274]: warning: 91.200.12.140: hostname vps863.hidehost.net verification failed: No address associated with hostname Jan 7 22:14:27 ip-99-99-99-99 postfix/smtpd[22274]: connect from unknown[91.200.12.140] Jan 7 22:14:27 ip-99-99-99-99 postfix/smtpd[22274]: lost connection after AUTH from unknown[91.200.12.140] Jan 7 22:14:27 ip-99-99-99-99 postfix/smtpd[22274]: disconnect from unknown[91.200.12.140] answered Jan 7, 2017 at 22:18
1,174 4 4 gold badges 19 19 silver badges 35 35 bronze badges
TLS is so cheap now that they try even after TLS only auth enabled.
May 17, 2020 at 1:47
I had similar issue with SASL by setting that flag it’s gone. and Yes now I’m having connect/disconnect issue for a unknown IP. what you did for that to fix?
Feb 6, 2021 at 3:49
If you have fail2ban installed you can enable sasl (or sometimes called postfix-sasl) in your jail.local (or jail.d) and that should make the annoyances go away.
## for me this is in /etc/fail2ban/jail.d/defaults-debian.conf [postfix] enabled = true [postfix-sasl] enabled = true answered Oct 22, 2019 at 17:08
378 4 4 silver badges 11 11 bronze badges
Blocking these IPs with firewall rules hurts you more than them. The attacks are generally from botnets and there are millions of compromised machines. Adding firewall rules only slows down your server but does nothing to stop the attacks.
Dec 4, 2022 at 20:24
Fail2Ban uses IPTABLES and (as I understand it) the IPTABLES firewall is built into the Linux kernel and very lightweight. A benchmark (here kinvolk.io/blog/2020/09/…) shows it can handle 10000 rules on a 10G link. As (for example) the block rules only stay there for 5 mins you would be hard pressed to get 2000 blocked connections per minute given most of them would come from the same bad actor IP. Due to the way TCP works once the syn is blocked you would have to re-negotiate the link (which would fail). That syn is small.
Dec 4, 2022 at 21:58
@TerryCarmen — blocking with iptables is FAR better than your server having to accept the inbound connection and actually start having a conversation with the other end. There may be millions of compromised machines out there but I’ve only ever seen a small number of IPs trying to connect at once. Blocking them temporarily usually makes them give up and try bothering someone else.
Jul 20 at 22:28
There are at least two ways of finding the user name(s) being tried.
Logging SMTP transactions with Postfix
If you know which host(s) your strange connections are coming from, you can enable verbose debugging for them by specifying a debug_peer_list in /etc/postfix/main.cf :
debug_peer_list = 192.0.2.1 This will yield, among other things, a message like this in syslog:
postfix/smtpd[123]: xsasl_dovecot_handle_reply: auth reply: FAIL?5?user=info You will want to use this setting for very specific debugging only, since the full SMTP session is logged, including the password.
postfix/smtpd[123]: < unknown[192.0.2.1]: AUTH LOGIN postfix/smtpd[123]: xsasl_dovecot_server_first: sasl_method LOGIN postfix/smtpd[123]: xsasl_dovecot_handle_reply: auth reply: CONT?5?VXNlcm5hbWU6 postfix/smtpd[123]: >unknown[192.0.2.1]: 334 VXNlcm5hbWU6 postfix/smtpd[123]: < unknown[192.0.2.1]: aW5mbw== postfix/smtpd[123]: xsasl_dovecot_handle_reply: auth reply: CONT?5?UGFzc3dvcmQ6 postfix/smtpd[123]: >unknown[192.0.2.1: 334 UGFzc3dvcmQ6 postfix/smtpd[123]: < unknown[192.0.2.1]: Zm9vYmFy postfix/smtpd[123]: xsasl_dovecot_handle_reply: auth reply: FAIL?5?user=info postfix/smtpd[123]: warning: unknown[192.0.2.1]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 postfix/smtpd[123]: >unknown[192.0.2.1]: 535 5.7.8 Error: authentication failed: UGFzc3dvcmQ6 In this example, a LOGIN attempt for user «info» has failed after the password «foobar» was presented. Like the challenges, you can decode the replies as base64:
$ echo aW5mbw== | echo $(base64 -d) info $ echo Zm9vYmFy | echo $(base64 -d) foobar Logging authentication with Dovecot
Postfix itself does not include a SASL implementation. Traditionally, it was hooked up to Cyrus SASL, but if you are using the Dovecot POP/IMAP server, Postfix can reuse its SASL module.
As you have found out, Dovecot has its own debugging facility, enabled with
auth_verbose = yes in its config file, often /etc/dovecot/conf.d/10-logging.conf . The output in /var/log/dovecot-info.log will look something like this:
Jun 10 13:16:40 auth-worker(14936): Info: pam([email protected],192.0.2.1): pam_authenticate() failed: Authentication failure (password mismatch?) While there is no host-based control here, there are a number of related options to control what gets logged, specifically whether or not to include the attempted passwords. From the example config:
# Log unsuccessful authentication attempts and the reasons why they failed. auth_verbose = no # In case of password mismatches, log the attempted password. Valid values are # no, plain and sha1. sha1 can be useful for detecting brute force password # attempts vs. user simply trying the same password over and over again. auth_verbose_passwords = no # Even more verbose logging for debugging purposes. Shows for example SQL # queries. auth_debug = no # In case of password mismatches, log the passwords and used scheme so the # problem can be debugged. Enabling this also enables auth_debug. auth_debug_passwords = no See also the Dovecot documentation for details.
About SMTP authentication
As you note, the string UGFzc3dvcmQ6 in the log message is the base64-encoding of «Password:». What Postfix is logging here is the particular authentication «challenge» that it has sent and received an erroneous reply for. There is also a preceding challenge for «Username:» ( VXNlcm5hbWU6 ). However, even for nonexistent users, the failure will only be reported after the password.
The values of the challenge strings are actually unimportant and should be ignored. The first challenge is always for the user name, and the second is for the password. The details about this can be found in the specification for the LOGIN method.
NB: Since this is all a bit noodly for just transfering and checking the username-password pair, LOGIN is long obsoleted. The PLAIN method works essentially the same but packs both pieces of information into the same base64 string.
Finally, the fact that parts of this conversation are base64-encoded is actually a feature of SMTP Authentication in general. The idea is to easily allow arbitrary (possibly binary) data to be exchanged between the SASL modules of client and server, without those SASL modules needing to know or care about SMTP itself. You can get an idea of how SASL operates from the Cyrus SASL documentation.
Saved searches
Use saved searches to filter your results more quickly
Cancel Create saved search
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot send emails using compose dialog, SASL LOGIN authentication failed: UGFzc3dvcmQ6 #7845
phil8900 opened this issue Sep 11, 2019 · 1 comment
Cannot send emails using compose dialog, SASL LOGIN authentication failed: UGFzc3dvcmQ6 #7845
phil8900 opened this issue Sep 11, 2019 · 1 comment
Comments
phil8900 commented Sep 11, 2019
After setting up an personal outbound email configuration, I hit the test button and the test mail was sent, the credentials are working.
I then tried to send an email to a test contact through the compose dialog which results in the following error:
Error Sending Email. Please contact your administrator for assistance.
Expected Behavior
The mail dialog should use the same settings as the test mail button and send the email.
Actual Behavior
The mail is not sent.
I took a look at the mail.log on my server, and the logs are different. For the working test mail, the following is logged:
Sep 11 13:44:50 mail postfix/submission/smtpd[21400]: connect from suitecrm.instance[myip] Sep 11 13:44:50 mail postfix/submission/smtpd[21400]: 90F267F519: client=suitecrm.instance[myip], sasl_method=LOGIN, sasl_username=test@mydomain Sep 11 13:44:50 mail postfix/cleanup[21339]: 90F267F519: message-id= Sep 11 13:44:50 mail postfix/submission/smtpd[21400]: disconnect from suitecrm.instance[myip] ehlo=2 starttls=1 auth=1 mail=1 rcpt=1 data=1 quit=1 commands=8
But for the non working mail, this happens:
Sep 11 13:29:57 mail postfix/submission/smtpd[20187]: warning: suitecrm.instance[myip]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 Sep 11 13:29:57 mail postfix/submission/smtpd[20187]: disconnect from suitecrm.instance[myip] ehlo=2 starttls=1 auth=0/1 quit=1 commands=4/5
And in suitecrm.log, the following line appears:
Wed Sep 11 11:29:57 2019 [2476][b0fe6bfa-d97b-304c-10b9-5d775f07fa84][FATAL] SugarPHPMailer encountered an error: SMTP Error: Could not authenticate.
Possible Fix
I am not sure about why this happens, but I logged $GLOBALS[‘log’]->fatal($this->Username); in SugarPHPMailer, and it printed the user name for the system outbound mail settings instead of the personal one I set up.
Steps to Reproduce
- Configure the systemwide email settings
- Disallow users sending from the general account
- Allow users to send from individual mailboxes
- Create a new user
- Set up a personal inbox and outbound email settings
- Send a test mail from the dialog (which should succeed)
- Create a contact and click on the email top open the mail compose dialog
- Try to send an email using the personal adress
Context
This bug is preventing us from using SuiteCRM at all, as we cannot synchronise our work.
Your Environment
- SuiteCRM Version used: 7.11.8
- Browser name and version (e.g. Chrome Version 51.0.2704.63 (64-bit)): Firefox 69, but the issue does not seem to be browser related
- Environment name and version (e.g. MySQL, PHP 7): PHP 7.3.9-1, MySQL 5.7.27
- Operating System and version (e.g Ubuntu 16.04): Ubuntu 18.04.3
The text was updated successfully, but these errors were encountered: