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

Roaming Profile – kopia zapasowa

Domena MS Active Directory umozliwia przechowywanie profilu użytkownika w postaci tzw. Roaming Profile. Oznacza to, że przede wszystkim dane użytkowników mogą byc składowane na serwerze i umieszczone w odpowiednim współdzielonym katalogu. Główną zaletą takiego rozwiązania (pominę tym razem wady) jest umożliwienie pracy z każdej końcówki w domenie ponieważ po zalogowaniu profil użytkownika jest przesyłany na stację roboczą. Zaś podczas pracy system dba o synchronizację jego zawartości z serwerem. Brzmi całkiem nieźle i powiedzmy, że generalnie się sprawdza.

W skład profilu użytkownika wchodzą przede wszystkim jego pliki i poczta ale również ustawienia związane z całym spersonalizowanym środowiskiem pracy – czyli profil użytkownika w całości. Są to dane bardzo wrażliwe na zmiany. Powszechnie wiadomo czym może zakończyć się ręczne modyfikowanie profilu Windows. Stąd Roaming Profile przechowywany na serwerze ma odpowiedni poziom zabezpieczeń. Dostęp do swoich plików ma praktycznie tylko ich użytkownik. Nie ma go nawet administrator. Co jednak można zrobić w sytuacji gdy powinniśmy (jako administrator) wykonywać kopie zapasową profilu użytkownika?

Rozwiązaniem tego problemu jest zmodyfikowanie uprawnień dla poszczególnych katalogów wewnątrz profilu użytkownika. Aby chronić środowisko pracy najlepiej jest ograniczyć się np. tylko do katalogów: Pulpit i Moje dokumenty (większość cennych danych znajduje się właśnie tutaj).

Zaczynamy od pobrania narzędzia PSTools ze strony SysInternals. Po rozpakowaniu pliku PSTools.zip, z katalogu PSTools uruchamiamy okienko systemowe poleceniem:

psexec -i -s cmd.exe

Potem korzystając z otworzonego okna systemowego (wywołanego z najwyższymi uprawnieniamy – SYSTEM, należy korzystać bardzo ostrożnie) wydajemy polecenie zmieniające uprawnienia dla wybranego katalogu:

icacls "D:\Profiles\*" /grant "domain admins":(OI)(CI)F /T

Naturalnie przykładowa ścieżkę D:\Profiles\* zmieniamy na docelową dla swoich zastosowań (np. wspomniany Pulpit lub Moje dokumenty).

MG

update.rc-d vs rc.local vs @reboot

Tym razem chciałem przedstawić krótki i treściwy wpis na temat uruchamiana aplikacji w trakcie startu serwerowego systemu operacyjnego. Sprawa dotyczy mojego ulubionego Debiana. Właściwie najabardziej elegancką i zgodną z regułami metodą jest umieszczenie skryptu startowego w katalogu /etc/init.d/, nadanie mu praw wykonywalnych i wywołanie polecenia:

update-rc.d nasz_skrypt defaults 99

Niemniej z różnych przyczyn nie zawsze się to udaje. Trzeba podejść do tematu inaczej. Od razu zaznaczam, że poniższe metody, jakkolwiek spełniające swój cel, są po prostu bardzo nieeleganckie i nie świadczą najlepiej o umiejętnościach administratora. Czasami jednak trzeba się ugiąć – chociażby pod presją czasu.

Druga metoda polega na dopisaniu skryptu do pliku /etc/rc.local. Generalnie tym sposobem można rozwiązać dużo problemów ale osobiście stosuje go tylko doraźnie. Polecam to jako rozwiązanie tymczasowe.

Trzecia metoda, kiedy zawiodą dwie poprzednie, to umieszczenie skryptu startowego w cronie systemowym dla konta root. Wywołujemy go poleceniem:

crontab -e

a następnie na końcu pliku dopisujemy linijkę:

@reboot /ścieżka_dostępu/nasz_skrypt

Od tego momentu, za każdym razem podczas uruchamiania się systemu, automatycznie będzie wykonywał się skrypt. Mało elegancko ale skutecznie.

MG