Re: Auth-Trouble
Hi, Am 01.11.21 um 18:00 schrieb infoomatic: > please inform the mailing list if problems persist, thank you! > > I am about to migrate to FreeBSD ... it does. Fresh install with a config, that used to work: # doveadm sync -u x...@zzz.de tcps:mail.bruecko.de doveadm(x...@zzz.de): Panic: file array.c: line 10 (array_idx_modifiable_i): assertion failed: (idx < array->buffer->used / array->element_size) Abort I'm clueless. Regards Hanns
Re: Auth-Trouble
please inform the mailing list if problems persist, thank you! I am about to migrate to FreeBSD ... On 01.11.21 13:53, Hanns Mattes wrote: Hi, Am 01.11.21 um 00:51 schrieb Hanns Mattes: Hi, Am 01.11.21 um 00:27 schrieb infoomatic: does 2.3.17_1 from ports fix the problem? I'm building own packages with poudriere and "pkg info dovecot" says it's 2.3.17_1 Given the fact that this version is dated 2021-10-28 I'm not sure, if its part of the problem or the solution. I'll do a complete reinstallation of the server, there are obviously more problems. For example: I can ssh to both servers (and i can connect from them to my server at home) but they refuse to talk to each other. Same with telnet etc. No idea why, so I'll start over and recheck things. Regards Hanns
Re: Auth-Trouble
Hi, Am 01.11.21 um 00:51 schrieb Hanns Mattes: > Hi, > > Am 01.11.21 um 00:27 schrieb infoomatic: >> does 2.3.17_1 from ports fix the problem? > > I'm building own packages with poudriere and "pkg info dovecot" says > it's 2.3.17_1 > > Given the fact that this version is dated 2021-10-28 I'm not sure, if > its part of the problem or the solution. > I'll do a complete reinstallation of the server, there are obviously more problems. For example: I can ssh to both servers (and i can connect from them to my server at home) but they refuse to talk to each other. Same with telnet etc. No idea why, so I'll start over and recheck things. Regards Hanns
Re: Auth-Trouble
Hi, Am 01.11.21 um 00:27 schrieb infoomatic: > does 2.3.17_1 from ports fix the problem? I'm building own packages with poudriere and "pkg info dovecot" says it's 2.3.17_1 Given the fact that this version is dated 2021-10-28 I'm not sure, if its part of the problem or the solution. Regards Hanns
Re: Auth-Trouble
does 2.3.17_1 from ports fix the problem? On 01.11.21 00:01, Hanns Mattes wrote: Hi, Am 31.10.21 um 18:30 schrieb Hanns Mattes: Hi, me again, Hanns Mattes schrieb: I stand corrected and forgot to remove things are working, except replication. no, they don't. okay, imap logins are working again. Replication still failing. My guess is, that my master-user configuration is the culprit. Any Ideas? Regards
Re: Auth-Trouble
Hi, Am 31.10.21 um 18:30 schrieb Hanns Mattes: > Hi, me again, > Hanns Mattes schrieb: > I stand corrected and forgot to remove >> things are working, except replication. > no, they don't. okay, imap logins are working again. Replication still failing. My guess is, that my master-user configuration is the culprit. Any Ideas? Regards
Re: Auth-Trouble
Hi, me again, Hanns Mattes schrieb: I stand corrected and forgot to remove >things are working, except replication. no, they don't. Regards Hanns
Auth-Trouble
Hi,
I've installed Dovecot on a freshly installed machine running Freebsd
13.4.
Configuration was copied from an earlier installation, which worked
perfectly, until I screwed an update.
AFAICS things are working, except replication. I see tons of Errors on
the remote and the local machine
Oct 31 16:15:30 freebsd dovecot[3248]: doveadm(x...@xx.de): Fatal:
connect(213.239.197.36:54321) failed: Interrupted system call
and some
Oct 31 16:47:33 freebsd dovecot[5509]: auth:
cram-md5(x...@xx.de,176.199.241.57,): Password mismatch
Oct 31 16:47:28 freebsd dovecot[5509]: doveadm(x...@yy.de): Fatal:
connect(213.239.197.36:54321) failed: Connection refused
and we also get
Oct 31 18:17:17 freebsd dovecot[934]:
imap(x...@wxxx.de)<1649>:
Panic: file array.c: line 10 (array_idx_modifiable_i): assertion failed:
(idx < array->buffer->used / array->element_size) Oct 31 18:17:17
freebsd dovecot[934]:
imap(x...@wxxx.de)<1649>:
Fatal: master: service(imap): child 1649 killed with signal 6 (core not
dumped - https://dovecot.org/bugreport.html#coredumps - set service imap
{ drop_priv_before_exec=yes })
not to forget
Oct 31 18:18:33 freebsd dovecot[934]: doveadm(xxx@xxx):
Fatal: connect(213.239.197.36:54321) failed: Connection refused
Users are authenticating with ldap.
I'm clueless, and I don't have any clue, if it is a misconfiguration of
dovecot or my freebsd-install.
Any ideas appreciated
Here is the output of doveconf -n
# 2.3.17 (e2aa53df5b): /usr/local/etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.17 (054dddfa)
# OS: FreeBSD 13.0-RELEASE-p4 amd64
# Hostname: freebsd.bruecko.de
auth_mechanisms = plain login digest-md5 cram-md5 apop
auth_username_chars =
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890+.-_@
auth_verbose = yes
doveadm_password = # hidden, use -P to show it
doveadm_port = 54321
lda_mailbox_autocreate = yes
lda_mailbox_autosubscribe = yes
lda_original_recipient_header = X-Original-To
lmtp_save_to_detail_mailbox = yes
mail_location = mdbox:~/mdbox
mail_plugins = " quota fts fts_xapian trash zlib notify replication acl"
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy
include variables body enotify environment mailbox date index ihave duplicate
mime foreverypart extracttext
namespace {
hidden = no
ignore_on_failure = no
inbox = no
list = children
location = mdbox:%%h/mdbox
prefix = shared/%%u/
separator = /
subscriptions = yes
type = shared
}
namespace {
location = mdbox:/virtualmail/public:INDEXPVT=%h/mdbox/Public
prefix = Public/
separator = /
subscriptions = yes
type = public
}
namespace inbox {
inbox = yes
location =
mailbox Drafts {
auto = subscribe
special_use = \Drafts
}
mailbox Sent {
auto = subscribe
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
auto = subscribe
special_use = \Trash
}
prefix = INBOX/
separator = /
}
passdb {
args = /usr/local/etc/dovecot/master-users
driver = passwd-file
master = yes
pass = yes
}
passdb {
args = /usr/local/etc/dovecot/dovecot-ldap.conf.ext
driver = ldap
}
plugin {
acl = vfile
acl_anyone = allow
acl_shared_dict = file:/virtualmail/shared-mailboxes.db
fts = xapian
fts_autoindex = yes
fts_autoindex_exclude = \Trash
fts_enforced = yes
fts_xapian = partial=3 full=20 verbose=0
mail_replica = tcps:mail.bruecko.de
quota = dict:User quota::file:%h/dovecot-quota
quota_exceeded_message = Storage quota for this account has been exceeded,
please try again later.
quota_grace = 250M
quota_rule = *:storage=2500M
quota_rule2 = INBOX/Trash:storage=+10%%
quota_status_nouser = DUNNO
quota_status_overquota = 552 5.2.2 Mailbox is full / Mailbox ist voll
quota_status_success = DUNNO
quota_warning = storage=95%% quota-warning 95 %u
quota_warning2 = storage=80%% quota-warning 80 %u
quota_warning3 = storage=75%% quota-warning 75 %u
sieve = ~/dovecot.sieve
sieve_dir = ~/sieve
sieve_global_dir = /virtualmail
sieve_max_actions = 0
sieve_max_redirects = 128
sieve_max_script_size = 0
sieve_quota_max_scripts = 0
trash = /usr/local/etc/dovecot/dovecot-trash.conf.ext
}
postmaster_address = ad...@bruecko.de
protocols = imap pop3 lmtp sieve
replication_dsync_parameters = -d -N -l 30 -U -x Public
service aggregator {
fifo_listener replication-notify-fifo {
user = vmail
}
unix_listener replication-notify {
user = vmail
}
}
service auth {
unix_listener /var/spool/postfix/private/auth {
mode = 0666
}
unix_listener auth-userdb {
group = vmail
user = vmail
}
}
service decode2text {
executable = script /usr/local/libexec/dovecot/decode2text.sh
unix_listener decode2text {
mode = 0666
}
user = dovecot
}
service doveadm {
inet_listener {
port = 54321
ssl = yes
}
vsz_limit = 0
}
service im
Re: [Dovecot] auth trouble
On Jun 8, 2012, at 10:25 AM, Timo Sirainen wrote: > I think the answer to this is simply that Dovecot v1.0 didn't tell PAM the > rhost. Upgrade. Will do. What you say fits with what I see in the logs and is a lot simpler than many other suggestions. And you do have some credibility in this area :-) Thanks. -- Glenn English hand-wrapped from my Apple Mail
Re: [Dovecot] auth trouble
On 6.6.2012, at 2.08, Glenn English wrote: >> And these brute force attempts would be logged, each one. > > They are, with no rhost. And there are other brute force attempts > that *do* have IPs. I think the answer to this is simply that Dovecot v1.0 didn't tell PAM the rhost. Upgrade.
Re: [Dovecot] auth trouble
On Jun 5, 2012, at 3:53 PM, /dev/rob0 wrote: > What suspicions were confirmed? At first I thought that somebody was TCP'ing in and somehow turning off the remote IP in the log so I couldn't block it. Then an answer from another mailing list, and a little thinking, made it occur to me that maybe my server had been penetrated. > And these brute force attempts would be logged, each one. They are, with no rhost. And there are other brute force attempts that *do* have IPs. > I think you are overreacting. I really hope so. What's your thinking? Have you seen this before? And most important: what is it, how does it work, and how do I get rid of it and keep it from coming back? -- Glenn English hand-wrapped from my Apple Mail
Re: [Dovecot] auth trouble
Glenn English wrote:
Maybe someone is brute forcing your server's Postfix authenticated
SMTP service since Postfix can be configured to use Dovecot's SASL
authentication framework.
and for the suggestion -- I do have Postfix using Dovecot-Auth checking
for SASL.
I think I'm going to re-install and run Tripwire...
Tripwire? If the purpose of your query is to automate blocking of brute
forcers, this software is not what you want (which detects tampering of
critical system files).
I suggest trying to find where Postfix failed login reports go, then use
your fail2ban or what-have-you to detect and block hosts that repeatedly
fail authentication.
(First Google hit I did on this subject)
http://scottlinux.com/2011/05/26/prevent-postfix-brute-force/
The log entries might look like
{timestamp} {servername} postfix/smtpd[{pid}]: lost connection after
AUTH
from {remote-hostname}[{remote-ip}]
Joseph Tam
Re: [Dovecot] auth trouble
On Tue, Jun 05, 2012 at 09:38:49AM -0600, Glenn English wrote: > On Jun 4, 2012, at 8:45 PM, Joseph Tam wrote: > > If dovecot-auth is getting input from a local socket, then rhost > > information is irrelevant since the host doing the asking is the > > server itself (maybe from another daemon connected to a remote > > host). > > Thanks for the confirmation of my suspicions What suspicions were confirmed? > > Maybe someone is brute forcing your server's Postfix > > authenticated SMTP service since Postfix can be configured to > > use Dovecot's SASL authentication framework. And these brute force attempts would be logged, each one. > and for the suggestion -- I do have Postfix using Dovecot-Auth > checking for SASL. > > I think I'm going to re-install and run Tripwire... I think you are overreacting. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: [Dovecot] auth trouble
On Jun 4, 2012, at 8:45 PM, Joseph Tam wrote: > If dovecot-auth is getting input from a local socket, then rhost > information is irrelevant since the host doing the asking is the server > itself (maybe from another daemon connected to a remote host). Thanks for the confirmation of my suspicions > Maybe someone is brute forcing your server's Postfix authenticated > SMTP service since Postfix can be configured to use Dovecot's SASL > authentication framework. and for the suggestion -- I do have Postfix using Dovecot-Auth checking for SASL. I think I'm going to re-install and run Tripwire... -- Glenn English hand-wrapped from my Apple Mail
Re: [Dovecot] auth trouble
Glenn English writes: I'm getting a lot of what I think is a local socket asking dovecot:auth to verify username/passwords: May 31 09:00:54 server dovecot-auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=admin rhost= If dovecot-auth is getting input from a local socket, then rhost information is irrelevant since the host doing the asking is the server itself (maybe from another daemon connected to a remote host). Maybe someone is brute forcing your server's Postfix authenticated SMTP service since Postfix can be configured to use Dovecot's SASL authentication framework. Joseph Tam
Re: [Dovecot] auth trouble
I forgot to include this config info: > # 1.0.15: /etc/dovecot/dovecot.conf > log_timestamp: %Y-%m-%d %H:%M:%S > protocols: imap pop3 > ssl_listen: * > ssl_disable: yes > disable_plaintext_auth: no > login_dir: /var/run/dovecot/login > login_executable(default): /usr/lib/dovecot/imap-login > login_executable(imap): /usr/lib/dovecot/imap-login > login_executable(pop3): /usr/lib/dovecot/pop3-login > login_max_processes_count: 12 > mail_privileged_group: mail > mail_executable(default): /usr/lib/dovecot/imap > mail_executable(imap): /usr/lib/dovecot/imap > mail_executable(pop3): /usr/lib/dovecot/pop3 > mail_plugin_dir(default): /usr/lib/dovecot/modules/imap > mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap > mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3 > pop3_uidl_format(default): > pop3_uidl_format(imap): > pop3_uidl_format(pop3): %08Xu%08Xv > auth default: > mechanisms: plain login > verbose: yes > passdb: > driver: pam > userdb: > driver: passwd > socket: > type: listen > client: > path: /var/spool/postfix/private/auth > mode: 432 > user: postfix > group: postfix -- Glenn English hand-wrapped from my Apple Mail
[Dovecot] auth trouble
Debian Lenny, Dovecot v 1.0.15. I'm getting a lot of what I think is a local socket asking dovecot:auth to verify username/passwords: > May 31 09:00:54 server dovecot-auth: pam_unix(dovecot:auth): authentication > failure; logname= uid=0 euid=0 tty=dovecot ruser=admin rhost= Note the empty 'rhost='. That's why I think it's on the server. I see others that look like bots: > May 30 23:08:43 server dovecot-auth: pam_unix(dovecot:auth): authentication > failure; logname= uid=0 euid=0 tty=dovecot ruser=admin rhost=200.119.139.22 And I know how to promote the latter to a firewall. But with no rhost, I'm stumped... I've read books, googled, read docs, and asked for help on other mailing lists, and I've learned a lot. And I no longer think it really has much to do with Dovecot, other than the login attempt going through it to get to PAM. But has anyone here seen this before? Is my current theory correct? What did you do to make it go away? (I suspect that upgrading to Debian Squeeze might get rid of it, but I'm afraid that if I don't figure out what's going on, it might just come back.) -- Glenn English hand-wrapped from my Apple Mail
