Postfix na szybko, czyli jak wzbogacić swój serwer pocztowy o autoryzację SMTP oraz TLS (część II)
Pierwsza część artykułu przeprowadziła nas przez prostą konfigurację postfixa, zapobiegającą przerobieniu naszego serwera na open-relay przy pomocy autoryzacji poprzez pop-before-smtp. Dziś czas na część drugą, czyli jak szybko włączyć autoryzację, tls i mieć to z głowy.
Pierwszą rzeczą jaką trzeba sprawdzić, to czy mamy zainstalowane potrzebne pakiety:
- postfix-tls
- sasl2-bin
- libsasl2
- openssl
- libsasl2-modules
Ruszamy - naszym celem są następujące pliki:
- /etc/postfix/main.cf, czyli plik zawierający opcje postfixa
- /etc/postfix/sasl/smtpd.conf, sposoby autentykacji sasl
- /etc/postfix/smtpd.key, klucz, którym będzie autoryzowany postfix
- /etc/default/saslauthd, konfiguracja demona SASL, który będzie dokonywał autentykacji
- /etc/fstab, nawet tu będziemy musieli dokonać zmiany, jeśli chcemy, żeby sasl działał poprawnie
Na pierwszy ogień idzie konfiguracja postfixa - otwieramy /etc/postfix/main.cf i dodajemy linie:
- smtpd_sasl_auth_enable = yes, odpowiada za włączenie mechanizmu autoryzacji
- broken_sasl_auth_clients = yes, pozwala na autoryzację klientom takim jak OE. Nazwa opcji jest swoją drogą jednoznaczna…
- smtpd_use_tls = yes, pozwalana włączenie szyfrowania transmisji
- smtpd_tls_cert_file = /etc/postfix/smtpd.cert, informuje gdzie znajduje się klucz publiczny serwera
- smtpd_tls_key_file = /etc/postfix/smtpd.key, dla odmiany wskazuje lokalizację klucza prywatnego
- do linijki smtpd_recipient_restrictions = dodajemy opcję permit_sasl_authenticated. Należy ją dodać przed jakimkolwiek zakazem typu reject.
Postfix już skonfigurowany - teraz pozostaje mu tylko dostarczyć dane, które obiecaliśmy. Na pierwszy ogień idzie autentykacja. Przede wszystkim otwieramy plik /etc/default/saslauthd i ustawiamy opcje
MECHANISMS=”shadow”
(lub “pam” lub “pam shadow”). Szybciutko restartujemy demona (/etc/init.d/saslauthd restart).
Nie jest to wszystko - drugi plik, którym musimy się zająć (a wręcz stworzyć ), to /etc/postfix/sasl/smtpd.conf. Opisuje on jakim mechanizmem posłużymy się do autentykacji - możemy użyć baz danych lub też w opisywanym przypadku, skonfigurowanego przed chwilą demona odwołującego się do kont systemowych. W naszej sytuacji wystarczy do tego pliku dodać linie
mech_list: plain login
W perfekcyjnym świecie to byłoby wszystko, w tym mniej doskonałym okazuje się, że dostaniemy komunikat
postfix/smtpd[7663]: warning: SASL authentication failure: Password verification failed
postfix/smtpd[7663]: warning: SASL PLAIN authentication failed
Dzieje się tak, ponieważ domyślnie sasl tworzy swój socket w /var/run/saslauthd/ a postfix, działający w chrootowanym środowisku szuka plików w (domyślnie) /var/spool/postfix/var/run/saslauthd/. Tworzenie katalogu (mkdir -p /var/spool/postfix/var/run/saslauthd) a potem tworzenie softlinka (ln -s) jest tu oczywiście opcję, niemniej nie rozwiązującą sytuacji. Dużo lepszym rozwiązaniem (i dość permanentym), jest zamontowanie tego katalogu poprzez dowiązanie. Na stałe rozwiązuje to odpowiednia linijka w /etc/fstab:
.
I już jest prawie dobrze gdyby nie to, że przy próbie autentykacji okazuje się że coś jest nie tak z uprawnieniami (warning: SASL authentication
failure: cannot connect to saslauthd server: Permission denied; warning: SASL authentication
failure: Password verification failed; SASL PLAIN authentication failed). Żeby poprawić sytuację wystarczy dodać postfixa do grupy sasl komendą usermod -G sasl postfix i już po sprawie.
Po restarcie autentykacja już działa. Możemy sprawdzić to telnetując się na port 25. Po komendzie ehlo wyświeli nam się linijka z wspieranymi rodzajami autentykacji. My wydamy następną komendę - AUTH PLAIN dGVzdAB0ZXN0AHRlc3Q=. Jeśli mamy użytkownika o loginie test i haśle test to autoryzacja przebiegnie pomyślnie. A tak przy okazji - jeśli nie mamy, to ciąg znaków za metodą PLAIN możemy łatwo uzyskać za pomocą następujące komendy:
lub
printf ‘user\0user\0hasło’ | mmencode
jeśli mamy oczywiście zainstalowanego albo perla z modułem MIME::Base64 albo xemacs21-bin
Pozostała nam kwestia bezpieczeństwa. Musimy utworzyć parę kluczy, tak aby można było hasło przesyłać bezpiecznie. W tym zakresie wystarczy wykonać polecenie
. Wpisanie danych daje nam ważny rok, podpisany samemu przez siebie certyfikat. Jeśli mamy certyfikat kwalifikowany, to wystarczy go dograć w to właśnie miejsce.
Voila - cel osiągnięty. Teraz pozostaje dodać spamassassina oraz clamav’a i mamy prosty, funkcjonalny serwer pocztowy, ale o tym w następnych odcinkach.
Comments
Comment from vermin
Time: 03/09/06, 6:26
Wow 
Cieszę się, że mogłem pomóc. Polecam się na przyszłość!
Comment from marek
Time: 09/09/06, 13:45
Mam problem z postfixem i saslem na debianie 3.1 otoz pomimo posiadania bibliotek plain i wpisu w main.cf smtpd_sasl_security_options = noanonymous, noplaintext po probie zatelnetowania sie dostaje cos takiego:
ehlo localhost
250-host.domena.pl
250-PIPELINING
250-SIZE 419430400
250-VRFY
250-ETRN
250-AUTH NTLM DIGEST-MD5 CRAM-MD5
250-AUTH=NTLM DIGEST-MD5 CRAM-MD5
250 8BITMIME
co robie nie tak ?
Comment from vermin
Time: 10/09/06, 10:06
W zasadzie to musisz upewnić się, że metodę plain masz wpisaną w /etc/postfix/sasl/smtpd.conf, bo sasl ewidentnie startuje i listuje pozostałe metody.
Dodanie w main.cf smtpd_sasl_security_options = noanonymous, noplaintext powoduje wyłączenie autoryzacji PLAIN i LOGIN.
Brak listowania metod plain i login może pojawić się czasem nawet bez wyłączenia tych metod. Wystarczy, że do powyższej linijki dodamy nodictionary, które blokuje metody autentykajci podatne na atak słownikowy.
Na koniec upewnił bym się, że na pewno biblioteki autoryzacji dla sasl plain są zainstalowane oraz, że używamy saslauthd, bo to też częsty błąd (niby się zgłasza, a tu nic - patrzeć w logach).
Comment from MG
Time: 12/12/06, 12:47
Witam,
Od kilku dni walcze z postfixem+SASL.Gdy próbuje wysyłać pocztę z outlook’a przy włączonym uwierzytelnianiu bez końca wyskakuje monit o wpisanie hasła.
W logach mail.log mam:
postfix/smtpd[13077]: connect from unknown[192.168.1.9]
postfix/smtpd[13077]: warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory
postfix/smtpd[13077]: warning: unknown[192.168.1.9]: SASL LOGIN authentication failed: generic failure
postfix/smtpd[13077]: lost connection after AUTH from unknown[192.168.1.9]
ns postfix/smtpd[13077]: disconnect from unknown[192.168.1.9]
testsaslauthd -u uzytkownik -p haslo pokazuje 0: OK “Success.”
Tworzyłem dowiązania symboliczne jak napisane w artykule ale nie pomaga. Próbowałem również wywoływać saslauthd z opcją -m /var/state.. /var/run itp. i niestety to samo.
W /etc/postfix/main.cf mam:
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_sasl_security_options = noanonymous
smtpd_recipient_restrictions = permit_sasl_authenticated,
smtpd_recipient_restrictions = reject_unauth_destination
Wynik telnet localhost 25:
ehlo localhost
250-host.domena.pl
250-PIPELINING
250-SIZE 25000000
250-VRFY
250-ETRN
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
No to chyba wszystkie informacje jakie mogę udzielić. Mogę liczyć na jakąś podpowiedź co jest nie tak?
Comment from vermin
Time: 12/12/06, 15:11
Z logów wynika, że postfix nie może się połączyć z saslauthd. W związku z tym to:
1. Sprawdź czy sasl na pewno działa: powinieneś mieć wpis w /var/log/auth.log
Dec 11 23:20:53 red saslauthd[17410]: ipc_init : listening on socket: /var/spool/postfix/var/run/saslauthd/mux
Jeśli masz coś takiego jak:
Dec 11 23:20:03 red saslauthd[17385]: main : chdir: No such file or directory
Dec 11 23:20:03 red saslauthd[17385]: main : Check to make sure the directory exists and is
Dec 11 23:20:03 red saslauthd[17385]: main : writeable by the user this process runs as.
to nie działa.
2. Mechanizmy masz dobre (czyli config jest ok), ponieważ coś jednak jest napisane. Jeśli używasza parametru albo mount, to także sprawdź czy aby na pewno jest zamontowane i czy katalog istnieje. Głupie, wiem.
Comment from MG
Time: 12/12/06, 15:26
-Dalsze informacje-
Okazuje się, że gdy uruchomię saslauthd z opcjami: -m /var/spool/postfix/var/state/saslauthd/ -a shadow
to mogę wysyłać pocztę z włączonym uwierzytelnianiem ale i bez niego ale tylko na adresy swojej domeny :(.
postfix/smtpd[21819]: NOQUEUE: reject: RCPT from unknown[192.168.1.9]: 554 5.7.1 : Relay access denied; from= to= proto=SMTP helo=
postfix/smtpd[21819]: disconnect from unknown[192.168.1.9]
Coś mam mocno namieszane
Comment from vermin
Time: 12/12/06, 15:37
OK, po tym co napisałeś sugeruję, żebyś:
1. dodał /etc/default/saslauthd:
MECHANISMS=”shadow”
OPTIONS=”-c -m /var/spool/postfix/var/run/saslauthd”
i zrestartował sasl
2. w /etc/postfix/main.cf zmienił linijkę smtpd_recipient_restrictions na
To ostatnie jest lepsze niż reject, bo w innym wypadku możesz mieć faktycznie problem z wysyłaniem
Comment from MG
Time: 12/12/06, 15:46
saslauthd działa. Mam odpowiednie wpisy w auth.log
Comment from MG
Time: 12/12/06, 16:02
No to jeszcze jedna sprawa. SASL był kompilowany ze źródeł i nie ma pliku saslauthd w /etc/default więc stworzyłem zgodnie z opisem ale nie wiem czy saslauthd w tym przypadku korzysta z tego pliku bo po restarcie nie uwzględnił OPTIONS
saslauthd[22657]: detach_tty : master pid is: 22657
saslauthd[22657]: ipc_init : listening on socket: /var/state/saslauthd/mux
Comment from vermin
Time: 12/12/06, 17:19
1. No tak, faktycznie nie słucha - jeśli był kompilowany ze źródeł, to czy ze źródeł zdebianizowanych, czy też z ogólnych? Czy ten sasl czymś się różni? Jakieś specyficzne opcje?
2. Czy udało Ci się wysłać pocztę poza własny serwer po zmianach w smtpd_recipient_restrictions? (powinno zabronić wysyłania poczty bez autentykacji spoza swojej sieci i umożliwić wysyłanie poza serwer).
Comment from vermin
Time: 12/12/06, 19:27
Czy masz swoją droga dodanego usera postfix do grupy SASL?
Comment from MG
Time: 13/12/06, 11:33
SASL był chyba ogólny i kompilowałem go z opcjami (wersja 2.1.20):
shell> ./configure –prefix=/usr –sysconfdir=/etc –localstatedir=/var –enable-login –enable-plain –disable-anon –disable-gssapi –disable-krb4 –with-pam –with-digest –with-gnu-ld –with-saslauthd
postconf -a wskazuje:
cyrus
dovecot
postconf -n :
alias_maps = hash:/etc/postfix/aliases
bounce_queue_lifetime = 2d
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
command_time_limit = 1200
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
home_mailbox = Mailbox
html_directory = no
inet_interfaces = all
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/local/man
maximal_queue_lifetime = 3d
message_size_limit = 25000000
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
mydomain = moja_domena
myhostname = nazwa_kompa
mynetworks = 127.0.0.0/8, 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24,
myorigin = $myhostname
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
queue_minfree = 10000000
queue_run_delay = 30m
readme_directory = no
relay_domains = $mydestination
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_recipient_limit = 20
smtpd_recipient_restrictions = reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
unknown_local_recipient_reject_code = 550
Przy włączonym uwierzytelnianiu i wysyłaniu poza mój serwer po wpisaniu błędnego hasła:
connect from unknown[192.168.1.9]
postfix/smtpd[30055]: warning: unknown[192.168.1.9]: SASL LOGIN authentication failed: authentication failure
postfix/smtpd[30055]: lost connection after AUTH from unknown[192.168.1.9]
Po wpisaniu odpowiednio poprawnego hasła:
connect from unknown[192.168.1.9]
postfix/smtpd[30112]: NOQUEUE: reject: RCPT from unknown[192.168.1.9]: 554 5.7.1 : Relay access denied; from= to= proto=ESMTP helo=
postfix/smtpd[30112]: disconnect from unknown[192.168.1.9]
Może uwierzytelninie i przekazywanie poczty to dwa różne niezależne problemy.
Comment from vermin
Time: 13/12/06, 19:34
OK, czyli rozumiem, że autoryzacja (uwierzytelnienie) działa, bo tylko po podaniu błędnego hasła nie zadziała(?)
Co do przekazywania to przyjrzałbym się zmiennej smtpd_recipient_restriction. W tym momencie odrzucasz nieznane cele, a spróbuj dopuścić także tych, którzy się autentykowali permit_sasl_authenticated.
To co masz ustawione, czyli reject_unauth_destinations pozwala jedynie na odbiór poczty lokalny, czyli to, jeżeli serwer z postfixem jest bezpośrednim adresatem (jest w jednej ze zmiennych
) lub ma przesłać do relay domains - czyli u Ciebie relay_domains = $mydestination do siebie samego. Wszystko co wychodzi na zewnątrz w związku z tym odpada błędem 55x.
A przy okazji - jesli wybaczysz mojej ciekawości: czemu sam kompilowałeś SASL a nie korzystałeś z paczki? Zawsze mnie to interesuje, jeśli ktoś wybiera dystrybucję binarną i sam kompiluje pakiety - i to jeszcze na dodatek nie na sposób debianowy.
Comment from MG
Time: 14/12/06, 15:55
Już sam nie wiem. Teroetycznie działa po zmianach w smtpd_recipients_restrictions tzn. z klinta poczty muszę mieć włączone uwierzytelnianie i podać poprawne hasło czyli OK. Ale jak zrobie ‘telnet moj.serv 25′ to mogę wysłać maila z fałszywego konta.
alias_maps = hash:/etc/postfix/aliases
bounce_queue_lifetime = 2d
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
command_time_limit = 1200
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
home_mailbox = Mailbox
html_directory = no
inet_interfaces = all
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/local/man
maximal_queue_lifetime = 3d
message_size_limit = 25000000
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain, http://www.mydomain
mydomain =
myhostname =
mynetworks = 127.0.0.1/32, 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24
myorigin = $myhostname
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
queue_minfree = 10000000
queue_run_delay = 30m
readme_directory = no
relay_domains = $mydestination
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_recipient_limit = 20
smtpd_recipient_restrictions = permit_sasl_authenticated, reject_rhsbl_recipient bl.spamcop.net, reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
unknown_local_recipient_reject_code = 550
Mam problem z wysyłaniem ze squirrelmaila na zewnątrz:
connect from unknown[127.0.0.1]
postfix/smtpd[21680]: NOQUEUE: reject: RCPT from unknown[127.0.0.1]: 554 5.7.1 : Relay access denied; from= to= proto=ESMTP helo=>
postfix/smtpd[21680]: lost connection after RCPT from unknown[127.0.0.1]
A kompilowałem wszytko ze źródeł bo korzystałem z opisu jaki znalazłem na sieci a jak się pewnie zorientowałeś nie jestem orłem w tych usługach. Wcześniej obsługiwałem gotowego sendmaila.
Comment from MG
Time: 14/12/06, 17:25
Wiesz co w końcu załapałem. Działa tak jak chce. Wszystko opiera się na smtpd_recipient_restrictions. Wielkie dzięki bardzo dużo mi pomogłeś. Gdybyśmy się spotkali to masz u mnie beczke piwa :). Pozdrawiam
Comment from Adam
Time: 23/08/06, 17:23
Ostatnio stracilem mnostwo czasu, zeby ozenic postfixa z saslauthd, naguglalem sie, a tu chodzilo wlasnie o to, ze:
“domyślnie sasl tworzy swój socket w /var/run/saslauthd/ a postfix, działający w chrootowanym środowisku szuka plików w (domyślnie) /var/spool/postfix/var/run/saslauthd/.”
Informacja na wage zlota.
Dzieki!