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