K-NET s.c.

Time has been changed – co oznacza ten komunikat

Jednym z problemów w administracji serwerami (nie tylko inuxowymi) jest synchronizacja czasu. Praktycznie każda usługa systemowa może odmówić posłuszeństwa jeżeli nie zadbamy o prawidłową podstawę czasu. Z pozoru zadanie to jest dość proste. Wystarczy zainstalować pakiet ntp:

apt-get install ntp

i od razu wszystko powinno działać. Osobiście polecam takie rozwiązanie na każdym sewerze z Linuxem aby właśnie zadbać o zsynchronizowanie naszej skali czasu z serwerami źródłowymi dostępnymi w Internecie. Musimy jednak pamiętać, że oprócz zegara systemowego, każdy komputer wyposażony jest w zegar sprzętowy. Funkcjonowanie tego ostatniego, a raczej jego zła praca, na pewno będzie miała wpływ na stabilność zegara systemowego. Są to bardzo rzadkie przypadki ale zdarzają się. Np. w Debianie Jessie aby zrealizować synchornizację wykorzystywane są kolejno usługi i funkcje systemd, swdate i w konsekwencji Slow Clock Adjuster. Co w moim przypadku, przy korzystaniu z maszyny VirtualBox, i zapewne błędnej obsłudze czasu przez środowisko wirtualne, zaowocowało komunikatami systemowymi (rsyslogd):

host systemd[1]: Time has been changed

Jak wspomniałem, jest to błąd oprogramowania i aby pozbyć się powyższych komunikatów trzeba je po prostu odfiltorwać na poziomie logu systemowego. W tym celu logujemy do konsoli roota i zakładmy plik time_msgs.conf:

touch /etc/rsyslog.d/time_msgs.conf

Następnie edytujemy plik:

vi /etc/rsyslog.d/time_msgs.conf

i dodajemu linijkę:

:msg, contains, "Time has been changed" stop

Po wszystkim musimy ponownie uruchomić usługę:

/etc/init.d/rsyslog stop
/etc/init.d/rsyslog start

Tym samym pozbyliśmy się niepotrzebnych komunikatów z logów systemowych.

MG

Fail2Ban – usuwanie adresu IP z czarnej listy

Jedną z najbardziej popularnych metod obrony przed atakami typu brute-force, które realizowane są automatycznie za pomocą skryptów sieciowych, jest zastosowanie aplikacji Fail2Ban na serwerze. Być może wspomniane ataki nie są szczególnie niebezpieczne, zwłaszcza jeżeli pamiętamy o stosowaniu odpowiednio skomplikowanych haseł dla kont użytkowników, generują jednak tony niepotrzebnych wpisów w logach systemów. Utrudnia to późniejszą analizę zdarzeń systemowych. Poza tym przy nieodpowiedniej konfiguracji naszych sieciowych usług serwerowych może to doprowadzić do zatrzymania się całego serwera – atak typu denial-of-service. Stąd trudno dziwić się popularności Fail2Ban, który po prostu umożliwia zablokowanie na jakiś czas adresu IP, jeśli jest on źródłem często powtarzających się zapytań, skierowanych do wybranej usługi sieciowej np. SSH, FTP itd.

Problemem jaki jest związany ze stosowaniem Fail2Ban jest blokowanie dobrych adresów IP. Na przykład może do tego dojść jeśli nasz użytkownik zapomni hasła do poczty i będzie usiłlował wielokrotnie zalogować się z błędem. Zgodnie ze zdefiniowanymi regułami zostanie zablokowany. Taka sytaucja zdarza się dosyć często. Wie o tym każdy kto zajmuje się administrowaniem. W dokumentacji Fail2Ban można znaleźć informacje jak odblokować wskazany adres za pomocą narzędzia fail2ban-client. Niestety ze względu na różnicę wersji samego oprogramowania dla różnych dystrybucji systemu Linux, jak również niepoprawnie obsługiwane funkcje, bywa, że Fail2Ban nie radzi sobie z tym zadaniem prawidłowo. Dlatego chciałem zaproponować inną metodę, bazującą na poleceniu iptables. Fail2Ban wykorzystuje iptables do blokowania połączeń, zatem poniższa metoda jest jak najbardziej bezpieczna.

Z poziomu administratora – konto root – wydajemy polecenie w konsoli systemowej:

iptables -L -n --line-numbers

Następnie odnajdujemy poszukiwany adres IP na liście i zapamiętujemy nazwę łańcucha np. Chain dynamic – nazwa dynamic, oraz numer linii. Parametry te posłużą do usnięcia adresu IP z czarnej listy za pomocą polecenia:

iptables -D nazwa_lancucha numer_linii

W tym momencie przywracamy dostęp do serwera naszemu zapominalskiemu użytkownikowi.

MG

Port Forwarding na serwerze Windows

Przekierowanie portów (port forwarding) za pomocą reguł iptables jest dobrze znaną i często wykorzystywaną funkcją w systemach Linux. Każdy kto z niej korzystał wie, że bywa bardzo przydatna w różnych sytuacjach. Jednak czy można uzyskać podobny efekt na serwerze z zainstalowanym systemem Windows? Na pierwszy rzut oka wbudowana zapora Windows Firewall nie posiada takich możliwości. Pomimo szczegółowego przeszukiwania wszystkich opcji dostępnych z poziomu menu graficznego, trudno jest tam nawet znaleźć wzmiankę o podobnych usługach. Okazuje się jednak, że pod spodem, pod warstwą interfejsu mającego upraszczać i ułatwiać codzienne czynności administracyjne kryje się całe bogactwo rozmaitych narzędzi. Tym razem chciałbym zwrócić uwagę na polecenie netsh.

Netsh jako narzędzie linii poleceń pozwala zrealizować wiele ciekawych i rozbudowanych czynności związanych z obsługą sieci w Windows. Bardzo dobrym źródłem informacji na ten temat jest Microsoft TechNet. Ponieważ omawianie wszystkich możliwości wykracza daleko poza ramy krótkiego artykułu chciałem pokazać wspomniany w tytule przykład:

netsh interface portproxy add v4tov4 →
listenaddress=localaddress listenport=localport →
connectaddress=destaddress connectport=destport

Poszczególne opcje oznaczają:

• listenaddress: lokalny adres IP oczekujący na połączenie,
• listenport: nasłuchujący port,
• connectaddress: adres IP, na który zostanie przekierowane połączenie,
• connectport: port, na który zostanie przekierowane połączenie.

Powyższy przykład pokazuje jak ciekawe narzędzia kryją się pod powłoką graficzną. Mam nadzieję, że jest to wystarczająca zachęta do zabawy z terminalem tekstowym. Podobnie jak w Linuksie 🙂

MG

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

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

Postfix – jak usunąć wybrany email z kolejki pocztowej

Każ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

Conky – integracja z Fetchmail

Conky to potężny i popularny pakiet wśród użytkowników desktopowych Linuxów. Wyróżnia się przede wszystkim niesamowitą elastycznością pozwalając zastąpić dowolne applety pulpitu i przygotować spersonalizowany wygląd desktopu. Przyznam, że również jestem jego zagorzałym zwolennikiem jednak ostanio przy zmianie systemu z poczciwego Ubuntu 12.04 na wersję 14.04 czekała mnie niemiła niespodzianka. Jako właściciel kilku kont pocztowych lubię wyświetlać informację o liczbie nowych wiadomości bezpośrednio na pulpicie. Do tej pory radziłem sobie za pomocą dodatku conkyemail. Niestety nie jest on dalej rozwijany a dla Ubuntu 14.04 istnieje wiele niespełnionych zależności podczas instalacji dlatego musiałem z niego zrezygnować. Po kilku godzinach poszukiwań czym można zastąpić wspomniany pakiet zdecydowałem się zainstalować sprawdzony Fetchmail. Integracja z Conky nie jest w tym przypadku prosta i oczywista ale efekt końcowy wygląda całkiem dobrze.

Po pierwsze, jak wspomniałem, musimy zainstalować pakiet Fetchmail. Po drugie należy utworzyć specjalny plik konfiguracyjny .netrc w katalogu domowym. Plik będzie zawierał nazwę użytkownika oraz hasło dla konta pocztowego, dla którego sprawdzamy nowe wiadomośc

machine serwer.pocztowy.pl
    login nazwa_użytkownika
    password hasło_użytkownika

Ze względu na bezpieczeństwo powinniśmy zmienić uprawnienia dla pliku:

chmod 600 ~/.netrc

Warto również wspomnieć, że możemy skonfigurować dowolną liczbę kont, Fetchmail podczas połączenia będzie przeszukiwał listę żeby odnaleźć pasujący wzorzec.

Teraz możemy zająć się plikiem konfiguracyjnym .conkyrc. W przypadku opisywanego rozwiązania powinniśmy w nim umieścić następującą linijkę:

pocztowy.pl: ${execi 300 fetchmail -c -p pop3 -u nazwa_użytkownika →
serwer.pocztowy.pl | sed -e 's/fetchmail: //' | sed -e 's/for.*$//'}

Jej działanie polega na okresowym wywoływaniu Fetchmail w celu sprawdzenia czy są nowe wiadomości – opcja -c. Zaś aby usunąć niepotrzebne informacje z komunikatu zwrotnego zastosowałem filtrowanie w potoku za pomocą sed. Efektem końcowym będzie wyświetlenie na pulpicie liczby nieprzeczytanych wiadomości email.

MG

Postfix main.cf czyli kolejność ma jednak znaczenie

Przez 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

Budowa serwera SFTP na bazie SSH i Debiana

Jak powszechnie wiadomo nie wynaleziono jeszcze bardziej popularnej usługi do transferu plików niż FTP. Być może większość administratorów wolałaby korzystać z innych rozwiązań ale tak się składa, że znają prawie wszyscy użytkownicy i to oni z reguły wymuszają stosowanie FTP. Podstawowy problem w tym przypadku to brak szyfrowania transmisji co przede wszystkim oznacza przesyłanie haseł jawnym tekstem. Jednak mając gotowy serwer z Linuxem oraz dostępem zdalnym po SSH można pokusić się o przygotowanie serwera SFTP, który zachowując większość funkcji FTP będzie zabezpieczał odpowiednio nasze połączenia. Co więcej jeśli ktoś dotychczas korzystał z bardzo popularnych programów typu WinSCP czy FileZilla to zasadniczo nie powinien mieć żadnych problemów z korzystaniem z SFTP bowiem obsługa tego ostatniego została już zaimplementowana w tych windowsowych klientach. Zatem do dzieła.

Po pierwsze sprawdzamy czy obsługa SFTP została włączona w konfiguracji serwera OpenSSH. Plik /etc/ssh/sshd_config powinien zawierać wpis:

Subsystem sftp internal-sftp

Teraz, na końcu pliku możemy dodać sekcje dla nowego konta z dostępem SFTP:

Match User KontoSFTP
  ChrootDirectory /home
  AllowTCPForwarding no
  X11Forwarding no
  ForceCommand internal-sftp

Oczywiście zakładam, że wcześniej założyliśmy sobie takie konto w systemie. Po ponownym uruchomieniu serwera SSH wszystko powinno zacząć działać… oprócz dwóch drobnostek.

Na pewno warto zadbać aby użytkownik KontoSFTP nie miał dostępu shellowego do systemu. W tym celu musimy zmienić mu domyślny shell. Najpierw sprawdzamy czy możemy użyć shella typu sftp-server:

cat /etc/shells

Jeśli nie zostanie wyświetlona nazwa sftp-server powinniśmy użyć polecenia:

echo '/usr/lib/openssh/sftp-server' >> /etc/shells

Teraz możemy już zmodyfikować konto naszego użytkownika:

usermod -s /usr/lib/openssh/sftp-server KontoSFTP

Druga sprawa to powinniśmy zmienić prawa dostępu do tych podkatalogów w /home, do których chcemy zabezpieczyć dostęp. W ten sposób nasz użytkownik nie będzie mógł zwiedzać innych podkatalogów. Dla każdego z zabezpieczanych katalogów należy wydać polecenie:

chmod 700 /home/NazwaZabezpieczanegoKatalogu

Po wykonaniu powyższych czynności możemy cieszyć się nowym serwerem SFTP. Powyższe uwagi dotyczą rzecz jasna mojego ulubionego Debiana.

MG

ClamAV-clamd av-scanner FAILED

Całkiem niedawno instalowałem po raz kolejny serwer poczty dla klienta. Niestety wsparcie dla mojego ulubionego Debiana Squeeze skończyło się w kwietniu tego roku dlatego postanowiłem od razu pominąć dystrybucje Wheezy i skorzystać z Jessie. W jednym ze wcześniejszych wpisów podałem adres bardzo dobrego poradnika, który omawiał jak niewielkim kosztem przygotować bardzo wydajną i sprawną bramkę mailową typu Antivirus/Antispam. Świat idzie szybko do przodu i okazało się, że poradnik już nie jest dostępny. Co więcej autor poleca skorzystanie ze skryptów iRedMail. Skrypty skryptami, niby rozwiązanie wygodne i szybkie ale co ma zrobić administrator przyzwyczajony do konfigurowania wszystkiego ręcznie? Przez wiele lat nagromadziłem własne gotowe pliki konfiguracyjne i nie bardzo uśmiechało mi się przeglądanie gotowców z iRedMail. Dlatego postanowiłem sprawdzić co pozmieniało się w stosunku do informacji (konfiguracji) które już posiadam i jednak zbudować serwer poczty od początku na własną ręke. Musze przyznać, że zmian było stosunkowo niewiele. Oczywiście niektóre repozytoria wygasły a w ich miejsce pojawiły się inne. Miłą niespodzianką okazała się na przykład dostępność w podstawowym repo pakietu clamav-unofficial-sigs, o czy zupełnie nie wiedziałem i zawsze instalowałem „z palca”. W trakcie instalacji trafiłem jednak na spory problem. Coś co do tej pory działało niezawodnie, nagle w Jessie przestało funkcjonować prawidłowo. Chodzi o pakiet Clamav, który zaczał zgłaszać błędy:

... run_av (ClamAV-clamd) FAILED ...
... ClamAV-clamd av-scanner FAILED ...
... WARN: all primary virus scanners failed, considering backups...

Sprawa wyglądała dość poważnie bo dotyczyła jednego z kluczowych elementów każdego systemu pocztowego. Jak zwykle w takich sytuacjach rozwiązanie okazało się dość banalne. W pliku konfiguracyjnym /etc/clamav/clamd.conf, w dystrybucji Jessie zmieniła się jedna linijka. Wygląda ona obecnie tak:

AllowSupplementaryGroups false

a powinna wyglądać jak w poprzednich dystrybucjach, czyli:

AllowSupplementaryGroups true

I to wszystko.

MG

Roaming Profile – kopia zapasowa c.d.

Dwa miesiące temu pisałem o tym jak zrobić kopie zapasową profilu typu Roaming Profile w sieci Active Directory. W trakcie korzystania przez cały ten czas z opisywanego narzędzia psexec będącego częścią pakietu SysInternals PSTools okazało się, że potrafi ono odmówić posłuszeństwa. Każda próba uruchomienia środowiska za jego pomocą kończy się komunikatem:

Error communicating with PsExec service

Próba zwyczajnego przeinstalowania pakietu nie pomaga. Okazuje się, że antidotum w tej sytuacji jest wykonanie poniższej procedury i nie pytajcie mnie dlaczego to działa akurat w taki sposób:

1. Na komputerze z zainstalowaną usługą psexec należy ją po prostu zatrzymać. Można to zrobić za pomocą GUI lub za pomocą polecenia pskill.
2. Na drugim komputerze trzeba zdalnie usunąć psexec poleceniem sc \\nazwa_naprawianego_komputera delete psexesvc.
3. Dopiero teraz można ponownie zainstalować pakiet PSTools ponownie.

Hmm…, dziwne.

MG