Bądź na bieżąco - RSS

Jak dodać białą listę dla RBL na poziomie Postfixa

Wrzesień 17th, 2016 | Brak Komentarzy | Kategoria: Linux, Porady

White list

Czasami tak się zdarza, że używając do ograniczenia niechcianej poczty przychodzącej (czyli po prostu spamu) list RBL wytniemy coś niepotrzebnie. Sytuacja ta dotyczy w szczególności konfiguracji, w której używamy w tym celu np. Postfixa, definiując w pliku main.cf z jakich list chcemy skorzystać. Takie rozwiązanie jest dosyć skuteczne, ubijamy pocztę bowiem od razu na samym początku łańcucha przetwarzania, nie obciążając zbytecznie np. demona amavisd. Jednak z drugiej strony możemy stanąć przed dylematem jak utworzyć białą listę hostów nie wyłączająć całej listy RBL. Jak się okazuje w Postfixie nie jest to problem. Poniżej krótka instrukcja:

[1] W katalogu /etc/postfix tworzymy plik rbl_override (nazwa przykładowa):

touch /etc/postfix/rbl_override

[2] Edytujemy jego zawartość:

nano /etc/postfix/rbl_override

dodając wyjątki z białej listy:

1.2.3.4    OK
3.4.5.6    OK

[3] Tworzymy bazę dla Postfixa za pomocą polecenia postmap:

postmap /etc/postfix/rbl_override

[4] Na koniec edytujemy plik main.cf:

nano /etc/postfix/main.cf

i dodajemy odpowiednią linijkę w sekcji smtpd_recipient_restrictions bezpośrednio po komendzie reject_unauth_destination ale przed pierwsza czarną listą reject_rbl_client:

[...]
    smtpd_recipient_restrictions = ...
        ...
        reject_unauth_destination,
        check_client_access hash:/etc/postfix/rbl_override,
        reject_rbl_client multi.uribl.com,
        ...
[...]

Trzeba oczywiście pamiętać o zrestartowaniu daemona postfix po wszystkim…

MG

Tagi: , , , ,

Postfix – jak usunąć wybrany email z kolejki pocztowej

Sierpień 20th, 2016 | Brak Komentarzy | Kategoria: Linux, Porady

Ruch pocztowy a obsługa kolejkiKażdy kto zajmował się administrowaniem serwerem poczty na pewno zetknął się z sytuacją, w której kolejka wiadomości na serwerze zaczyna powoli się wydłużać i po pewnym czasie może dojść do małej awarii usługi. Sytuacje takie zdarzają się najczęściej w przypadku zapętlonych emaili ale również gdy jesteśmy celem ataku DoS lub po prostu ktoś z naszych klientów padł ofiarą wirusa wykorzystującego czytnik poczty do rozsyłania spamu. Ponieważ w każdym przypadku są to sytuacje niepożądane a bywa, że niebezpieczne, zazwyczaj należy się tym szybko zająć. Jeżeli korzystamy z serwera Postfix to po wydaniu polecenia:

postqueue -p

powinniśmy zobaczyć co dzieje się z naszą kolejką. Jeśli rzeczywiście zobaczymy, że jest ona przepełniona bo np. na naszym serwerze czeka kilka tysięcy emaili do wysłania (tak, miewałem takie sytuacje) to zasadniczo mamy dwie możliwości. Pierwsza, nazwałbym ją drastyczną, to usunięcie całej kolejki emaili:

postsuper -d ALL

Trzeba pamiętać jednak, że wraz z niepotrzebnymi wiadomościami możemy usunąć te, na których może nam bardzo zależeć (lub klientowi rzecz jasna). Dlatego czasami warto się przyjrzeć kolejce po to aby upewnić się czy przypadkiem ruch emailowy nie wychodzi z jednego z naszych kont pocztowych a wtedy warto rozważyć usunięcie jedynie wybranych emaili. Można to zrobić za pomocą komendy:

postqueue -p | tail -n +2 | awk 'BEGIN { RS = "" } / →
konto@domena\.net/ { print $1 }' | tr -d '*!' | postsuper -d -

która spowoduje usnięcie wiadomości od (lub do) użytkownika konto@domena.net. Ta prosta linijka pozwala czasami ustrzec się bardzo poważnych konsekwencji.

MG

Tagi: , , , ,

Postfix main.cf czyli kolejność ma jednak znaczenie

Czerwiec 18th, 2016 | Brak Komentarzy | Kategoria: Linux, Porady

PostfixPrzez wiele lat konfigurowałem rozmaite serwery poczty opierając się o sprawdzony serwer Postfix w tandemie z Debianem. Były to konfiguracje bardzo proste, średnio złożone i takie, które wymagają posiedzenia nad problemem dłużej. Wykorzystywałem Postfix natywnie i w połączeniu z gotowymi skryptami (np. polecanym iRedMail). Przyznam, że nigdy nie zawiódł i wydawał się być dość prosty w obsłudze przy jednocześnie rozbudowanych opcjach ustawień. Do czasu aż trafiłem na problem, który zatrzymał mnie w miejscu na parę godzin. O co chodzi? Otóż w każdej sieci znajdzie się urządzenie, komputer, router może termometr IP, które będzie chciało wysyłać emaile z komunikatami. I zazwyczaj mają one wbudowaną obsługę autoryzacji dla połączeń SMTP. Jedna raz na jakiś czas trafi się egzamplarz, który za żadne skarby świata nie potrafi się kulturalnie przedstawić naszemu Postfixowi. Wówczas nie pozostaje nic innego jak zrobić małe obejście i dopuścić urządzenie do wysyłania emaili bez żadnych ograniczeń. Wiem, że nie powinniśmy tak nigdy robić ale czasem trzeba. W Postfixie służy do tego opcja (na przykładzie adresu 10.10.10.10):

mynetworks = 127.0.0.1 10.10.10.10

która spowoduje, że wymienione po kolei hosty stają się uprzywilejowane. Czy zawsze to zadziała? W tym właśnie tkwi sedno sprawy, że nie! Otóż jeżeli w naszej konfiguracji stosujemy różne ograniczenia (a jak wspomniałem Postfix jest bogaty w możliwości) czyli np. zastosujemy dyrektywę smtpd_recipient_restrictions to kolejność jej atrybutów zaczyna mieć znaczenie. Czyli np. kod:

smtpd_recipient_restrictions =
  permit_mynetworks
  reject_unknown_recipient_domain
  reject_non_fqdn_recipient

jest prawidłowy bo atrybut permit_mynetworks jest pierwszy na liście. Jednak ten sam kod zapisany:

smtpd_recipient_restrictions =
  reject_unknown_recipient_domain
  reject_non_fqdn_recipient
  permit_mynetworks

jest już nieprawidłowy bo kolejność ma jednak duże znaczenie. Reguła ta obowiązuje dla wszystkich dyrektyw, dla których możemy użyć atrybutu permit_mynetworks.

MG

Tagi: , , , ,

WordPress – włamanie w celu rozsyłania spamu (Apache+PHP+Postfix)

Styczeń 17th, 2015 | Brak Komentarzy | Kategoria: Linux, Porady

HackerWordPress jako bardzo popularne narzędzie jest często obiektem ataków w celu przejęcia zawartości strony. Podmiana treści serwisu przez hackera jest widocznym skutkiem złamania zabezpieczeń. Sama w sobie nie jest jednak tak groźna jak np. wykorzystanie naszego serwera do rozsyłania spamu (co może spowodować umieszczenie go na czarnych listach). Najczęściej atakujący starają się umieścić w strukturze katalogów serwisu przygotowane skrypty PHP (w formie plików), które następnie wykorzystują do wysyłania maili. Co zrobić, żeby zabezpieczyć się przed tą formą ataku?

Przede wszystkim konieczne jest wykonanie 2 czynności: (a) ograniczenie zainstalowanych motywów do niezbędnego minimum oraz (b) usunięcie wszystkich zbędnych wtyczek (bywają takie, które z powodu słabej jakości kodu umożliwiają natychmiastowy dostęp do serwera). Kolejną rzeczą jest uniemożliwienie przesłania spreparowanego zapytania do naszego serwera. Absolutnym minimum jest przygotowanie pliku .htaccess z odpowiednimi regułami. Jeśli chcemu pójść na skróty można skorzystać ze zbioru gotowych reguł: http://perishablepress.com/5g-blacklist-2013/. W zasadzie dzięki tym dwóm prostym krokom uzyskamy przynajmniej minimalny poziom zabezpieczeń strony w WordPressie. Dodam jeszce, że na końcu .httaccess można  dopisać linijkę

RewriteRule ^(php\.ini|\.htaccess) - [NC,F]

która zabezpieczy nas przed modyfikacją zawartości plików index.php i właśnie .htaccess co z kolei uniemożliwi np. przekierowanie wywołań naszej strony na inny serwer www.

Jednak w jaki sposób powstrzymać doraźnie atak na nasz serwer (jeśli już doszło do niego). Przy założeniu, że korzystamy z domyślnej konfiguracji Apache trzeba zatrzymać wysyłanie poczty z konta www-data. Edytujemy plik /etc/postfix/main.cf i dodajemy na końcu wiersz

authorized_submit_users = !www-data, static:all

Natstępnie wczytujemy nową konfiguracje serwera poczty:

/etc/init.d/postfix reload

Teraz musimy wyczyścić kolejkę maili oczekujących na nadanie:

postsuper -d ALL

Przechodzimy do najbardziej monotonnej częsci całego procesu. Edytujemy plik /etc/php5/apache2/php.ini, żeby znaleźć (i odkomentować lub zmienić na postać przedstawioną poniżej) fragment:

mail.add_x_header = On
mail.log = /var/log/phpmail.log

Pierwsza spowoduje dodanie nagłówka do wszystkich maili nadawanych z wykorzystaniem PHP a druga włączy logowanie informacji na ten temat (do pliku /var/log/phpmail.log). Teraz pozostaje nam żmudne przeglądanie pliku z logami w celu śledzenia historii ataku oraz usuwania niepożądanych plików (zawierających np. skrypty PHP), które są wykorzystywane do rozsyłania spamu.

MG

Tagi: , , , ,

Dovecot, Postfix, IMAP – Operation not permitted

Lipiec 19th, 2014 | Brak Komentarzy | Kategoria: Linux, Porady

ThuderbirdDzisiaj krótki, wakacyjny wpis dotyczący błędu związanegoz konfiguracją obsługi IMAP za pomocą Dovecot. W tandemie ze standardowo skonfigurowanym Postfixem, gdy zdecydowaliśmy się przechowywać pocztę w formacie mbox w katalogu /var/mail/ przy próbie pobrania poczty za pomocą dowolnego programu pocztowego (np. Thunderbird) w pliku /var/log/mail.log mogą pojawić się następujace błędy:

 

dovecot: imap(...):
Error: chown(...) failed: Operation not permitted
Error: mkdir(...) failed: Operation not permitted
Error: fchown(...) failed: Operation not permitted
Error: file_dotlock_create(...) failed: Permission denied

Jest to związane z niewystarczającymi uprawnieniami w katalogu użytkownika. Zgodnie z dokumentacją powinniśmy zajrzeć na stronę z opisem roziwązania http://wiki2.dovecot.org/Errors/ChgrpNoPerm. Ponieważ dla mnie obydwa omawiane tam rozwiązania wyglądają niedobrze, proponuję zastosować w pliku /etc/dovecot/conf.d/10-mail.conf zastosować następującą łatkę, w miejsce linijki:

mail_location = mbox:~/mail:INBOX=/var/mail/%u

podstawić:

mail_location = mbox:~/mail/mailboxes:INBOX=/var/mail/%u:→
DIRNAME=mBoX-MeSsAgEs:INDEX=~/mail/index:CONTROL=~/mail/control

Sprawdziłem… pomaga. Tak jak obiecałem – krótko i na temat136.

MG

Tagi: , , , , , ,