Instalacja i konfiguracja SASL dla POSTFIX / Debian

Instalacja i konfiguracja SASL na potrzeby serwera SMTP w tym wypadku popularnego POSTFIXa jest w zasadzie koniecznością. W przeciwnym wypadku dajemy otwartą furtkę dla spamerów, którzy będą wykorzystywali nasz serwer poczty wychodzącej w celu masowego rozsyłania niechcianej poczty. A jak wiadomo kwestii bezpieczeństwa nigdy nie należy ignorować. Aby uniknąc tego typu przypadków wykorzystuje się pośrednią warstwę do autoryzacji wysyłanych maili. Bez autoryzacji ( login/hasło ) wysłanie maila nie będzie możliwa. Uwierzytelnienie pobiera loginy i hasła z kont użytkowników na serwerze lub z bazy danych MySQL – według typu instalacji. W poniższym przykładzie konfiguracji POSTFIX dane autoryzacyjne będą pobierane z /etc/passwd.

Instalacja SASL

W tym wypadku nie będziemy mieli żadnych komplikacji.
Instalujemy odpowiednie pakiety z wykorzystaniem apt-get wpisując w terminalu poniższe polecenie:

apt-get install sasl2-bin libsasl2-2 libsasl2-modules

Konfiguracja SASL + Postfix

Po zainstalowaniu powyższych pakietów przystępujemy do konfiguracji. Na początku edytujemy plik konfiguracyjny SASL:

/etc/default/saslauthd

zmieniając poniższe parametry na:

START=yes
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"

Następnie tworzymy dodatkowy plik o nazwie smtpd.conf w lokalizacji:

/etc/postfix/sasl/smtpd.conf

i wpisujemy metodę autoryzacji dla Postfixa:

pwcheck_method: saslauthd
mech_list: plain login

W pliku konfiguracyjnym Postfixa /etc/postfix/main.cf wpisujemy poniższe parametry dotyczące SASL i przy okazji dodajemy odpowiednie restrykcje w celu zapewnienia większego bezpieczeństwa:

# SASL konfiguracja
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes

# Restrykcje
smtpd_sender_restrictions = reject_unauth_pipelining, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unknown_address, permit
smtpd_recipient_restrictions = reject_invalid_hostname, reject_unknown_recipient_domain, reject_non_fqdn_recipient, permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, check_client_access hash:/etc/postfix/client_checks
smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname

Same restrykcje są podawane w dość opisowy sposób, tak więc nie powinno być wątpliwości do czego służą.
W naszym przypadku należy zwrócić uwagę na dyrektywę: check_client_access hash:/etc/postfix/client_checks aby ta opcja zadziałała musimy utworzyć plik i zapisywać tam restrykcje dla IP, adresów mailowych itp., które chcemy aby były od razu odrzucane, dla przykładu:

89.163.209.133 REJECT

Taki plik oczywiście trzeba jeszcze zahaszować:

postmap /etc/postfix/client_checks

Najprawdopodobniej twój Postfix pracuje w środowisku chroot, tak więc tworzymy odpowiednie dowiązanie symboliczne, tak aby Postfix miał dostęp do właściwej lokalizacji z SASL. Aby sprawdzić czy Postfix pracuje w środowisku chroot patrzymy do pliku: /etc/postfix/master.cf

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
smtp      inet  n       -       -       -       -       smtpd

Trzecia opcja po inet ( znak „-” ) potwierdza, że serwer działa w środowisku chroot.

Tworzymy nasze dowiązanie symboliczne:

rm -r /var/run/saslauthd/
mkdir -p /var/spool/postfix/var/run/saslauthd
ln -s /var/spool/postfix/var/run/saslauthd /var/run

Dodajemy nową grupę dla użytkownika postfix:

usermod -g sasl postfix

Zmieniamy grupę na sasl dla poniższej lokalizacji:

chown -R root:sasl /var/spool/postfix/var/

+ Nasłuchiwanie na porcie 587

Z uwagi iż usługodawcy internetowi blokują port 25 to aby dać zwykłemu użytkownikowi możliwość wysyłania maili z jego prywatnego komputera należy na serwerze udostępnić usługę smtpd ( tzw. submission ). Opcję tą aktywujemy dokładnie w tym samym pliku w którym sprawdzaliśmy czy nasz Postfix pracuję w środowisku chroota, czyli: /etc/postfix/master.cf
Wystarczy odhaszować poniższą linię:

submission inet n       -       -       -       -       smtpd

Jak widać również i ta usługa w naszym przypadku pracuje w środowisku chroot.
To właśnie smtpd ( submission ) będzie nasłuchiwał na porcie 587 dzięki czemu możemy bez obaw wysyłać nasze maile z wykorzystaniem portu 587. Taki mail następnie zostaje przekazany do smtp pracującego na porcie 25 i wysłany w świat ( maile idą w „świat” tylko wtedy kiedy przejdą proces autoryzacji w smtpd, smtp nie musi już dokonywać powtórnej autoryzacji ma zaufanie od smtpd, że można to wysłać w świat ) Dzięki autoryzacji nasz serwer nie stanie się tzw. Open Relay Mail Server 😉

Dodatkowe opcje dla submission w pliku: master.cf dopisujemy je do submission z parametrem -o dajemy je w nowej linii dodajać przed opcją odstęp np. tabulację:

submission inet n       -       -       -       -       smtpd 
        -o syslog_name=posfix/submission 
	-o smtpd_sasl_auth_enable=yes
	-o milter_macro_daemon_name=ORIGINATING
	-o smtpd_client_restrictions=
	-o smtpd_helo_restrictions=
	-o smtpd_sender_restrictions=
	-o receive_override_options=no_header_body_checks,no_address_mappings
	-o smtpd_client_restrictions=permit_sasl_authenticated,reject
	-o smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject

Jeśli chodzi o parametry bez wypisanych opcji to tak jest tylko dlatego, aby nadpisać te parametry z pliku main.cf – a tam mamy nieco inne opcje, które tutaj możemy zignorować w przypadku 3 powyższych parametrów bez opcji. W zasadzie wszystkie opcje określają jakieś restrykcje brane pod uwagę podczas przetwarzania poczty.
Najważniejszą i bezwzględną kwestią jest aby włączyć autoryzację po SASL !
Objaśnienie pozostałych opcji:

PARAMETRY OPCJE
permit_sasl_quthenticated: pozwolenie na autoryzacje SASL
reject_non_fqdn_recipient: domena odbiorcy musi być domeną zgodną z FQDN ( fully qualified domain name ) widoczna w DNS
reject_unknown_recipient_domain: sprawdza na podstawie wpisów DNS czy domena istnieje

+ Chwila prawdy 😉

Restartujemy postfixa i uruchamiamy demona saslauthd:

/etc/init.d/postfix restart
/etc/init.d/saslauthd start

Testowanie SASL

Aby przetestować warstwę autoryzacyjną bez udziału Postfixa, wpisujemy poniższe polecenie:

testsaslauthd -u [login] -p [hasło]

Oczywiście login i hasło ma być zgodne z danymi użytkowników systemowych /etc/passwd
Jeśli wszystko jest OK, dostajemy stosowny komunikat:

0: OK "Success."

Jeśli mamy poniższy komunikat:

connect() : No such file or directory saslauthd

Sprawdzamy czy w ogóle jest uruchomiony proces odpowiedzialny za autoryzacje:

ps ax | grep saslauth

Ewentualnie sprawdzamy w plikach konfiguracyjnych poprawność ścieżki:

/var/spool/postfix/var/run/saslauthd

i czy ma odpowiednie uprawnienia.

+ Wysyłanie maila za pomocą Telnet`u

Teraz możemy przejść do testowania SASL z wykorzystaniem Postfixa.
Wyślemy maila za pośrednictwem programiku telnet, przy okazji zobaczymy że i w trybie tekstowym można wysłać maila nie mając żadnego klienta pocztowego pod ręką 😉

Na samym początku musimy zakodować nasze hasło i login do base64:

perl -MMIME::Base64 -e 'print encode_base64("\0username\0password");'

lub:

echo -ne '\0username\0password' | openssl enc -base64

Jak widać nazwę użytkownika wpisujemy dwa razy nie zapominając o NULL-byte, czyli \0.
Po tej operacji dostaniemy zakodowane dane autoryzacyjne:

dXNlcm5hbWUAdXNlcm5hbWUAcGFzc3dvcmQ=

Tak więc login i hasło jest zakodowane w takiej sytuacji nawet jeśli ktoś przechwyci nam te dane to i tak nie będzie w stanie zalogować się na nasze konto przez FTP czy SSH chyba, że je złamie 😉 Serwer sprawdza zakodowany login i hasło ze swoją bazą użytkowników systemowych i jeśli znajdzie pasujące „sygnatury” uwierzytelniające wtedy proces autoryzacji zakończy się sukcesem. Zaznaczam, że login i hasło dotyczy użytkowników systemowych tak więc jest takie samo jak chociażby do FTP czy SSH. Jeśli chcemy mieć odrębne hasła należy zapoznać się z konfiguracją Postfix+MySQL !

Wykorzystamy je w celu przejścia autoryzacji na naszym serwerze SMTP.

Teraz pozostaje zatelnetować na nasz serwer SMTP podając dodatkowo port na którym nasłuchuje – najczęściej 25 ( dla komunikacji pomiędzy serwerami ) lub 587 jeśli wysyłamy z komputera lokalnego ( domowego ), przykładowo:

telnet serwer.mailowy.pl 587

następnie wpisujemy polecenie: EHLO serwer.mailowy.pl – podając nazwę naszego serwera, po czym dostaniemy odpowiedź od serwera:

250-serwer.mailowy.pl
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

Jak widać w statusie nasz serwer wymaga autoryzacji ( wylistowane opcje: AUTH PLAIN LOGIN i AUTH=PLAIN LOGIN ). A więc podajemy mu zakodowane dane autoryzacyjne:

AUTH PLAIN dXNlcm5hbWUAdXNlcm5hbWUAcGFzc3dvcmQ=

Jeśli wszystko poprawnie zrobiliśmy dostajemy odpowiedni status informujący o sukcesie:

235 2.7.0 Authentication successful

Następnie podajemy podstawowe parametry dla wysyłanego maila:

MAIL FROM:nadawca@serwer.com
RCPT TO:odbiorca@nasz-serwer.com
DATA
jakiś tekst
.
quit

Kropka w nowej linii oznacza koniec wprowadzania tekstu w sekcji DATA

Możemy także szybko wysłać maila z systemowego polecenia: mail np:

echo "Treść wiadomości w BODY" | mail -s "Temat" user@poczta.pl

Dodaj komentarz