1

I'm using postfix with courier and mysql for authentication.

Lately I have some segmentation faults, which causes sasl deamon to crash. It seems, the have something to do with dictionary attacks on my mail server. In the log files, I got segfault errors for saslauthd

segfault at 0 ip 00007fe3107a3d8e sp 00007ffc2b007de8 error 4 in libc-2.19.so
  • libsasl2-2 version: 2.1.26.dfsg1-13+deb8u1
  • postfix version: 2.11.3-1

saslauthd conf:

START=yes
DESC="SASL Authentication Daemon"
NAME="saslauthd"
MECHANISMS="pam"
MECH_OPTIONS=""
THREADS=5
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd -r"

postfix main.cf

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

append_dot_mydomain = no

readme_directory = no

smtpd_tls_cert_file = /root/ssl/startssl/server.crt
smtpd_tls_CAfile = /root/ssl/startssl/startssl-ca-bundle.pem
smtpd_tls_key_file = /root/ssl/startssl/server.key

smtpd_use_tls=yes
smtpd_tls_received_header = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_loglevel = 3
tls_random_source = dev:/dev/urandom

myhostname = ...
mydestination = localhost, localhost.localdomain
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = ipv4

#smtpd
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_sasl_authenticated_header = yes
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes

# virtual
virtual_alias_domains =
virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf, mysql:/etc/postfix/mysql-virtual_email2email.cf
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-virtual_domains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailboxes.cf
virtual_mailbox_base = /home/vmail
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
transport_maps = proxy:mysql:/etc/postfix/mysql-virtual_transports.cf

proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks $virtual_mailbox_limit_maps

# spam/virus
content_filter = amavis:[127.0.0.1]:10024
receive_override_options = no_address_mappings
message_size_limit = 52428800
virtual_mailbox_limit = 102400000

Any suggestions to stop saslauthd from crashing?

Feel free to post other suggestions/issues about my postfix conf file..

  • Configuration should not be able to cause crashes. Ensure all packages are up-to-date with security fixes. If your distribution no longer supports your install, plan to upgrade your distro or commit to the arduous task of building critical packages from source. – Olipro Mar 14 '16 at 19:16
  • I'm running Debian Jessie and the packages are managed by apt and up-to-date – Philipp Mar 14 '16 at 19:19
  • Well, this appears to be a known issue posted here: bugs.debian.org/cgi-bin/bugreport.cgi?bug=784112 - so are you sure about being up to date? – Olipro Mar 14 '16 at 19:23
  • I've seen this bugreport. My libsasl2-2 version is 2.1.26.dfsg1-13+deb8u1 which is listed in your bugreport as fixed. Or did I'm missing something? – Philipp Mar 14 '16 at 19:28
  • If you really are fully up-to-date with everything, they may be taking advantage of an 0day. Maybe a known 0day, but... if not, worth looking into. Are you sure saslauthd isn't just running out of memory? Do you have some sort of rate-limiting in place for auth requests (e.g. fail2ban)? – Parthian Shot Mar 14 '16 at 20:09
0
+50

When you see processes stopped with a segfault, the best way to debug them is to enable core dumps. Then you can use gdb to print a stack trace and see precisely where the program has crashed.

As there is a recent security bug for glibc, I would start by upgrading glibc and restarting the machine. See: CVE-2015-7547

  • Is an restart required to apply the changes? – Philipp Apr 1 '16 at 8:53
  • In recent distributions you can use prlimit to change the limit for a running process. In some older ones you could write into /proc/<pid>/limits. Otherwise you can use ulimit command, or edit /etc/security/limits.conf. you need to change the core size to unlimited . – Mircea Vutcovici Apr 1 '16 at 10:46
  • In worst case you need to restart only the process you need to debug. – Mircea Vutcovici Apr 1 '16 at 10:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.