Bądź na bieżąco - RSS

Logcheck, systemd – zaśmiecone logi

Kwiecień 21st, 2018 | Brak Komentarzy | Kategoria: Linux, Porady

logcheck, systemdWśród administratorów Linuksa, od wielu lat prym wiedzie mały ale bardzo poręczny pakiet logcheck. Narzędzie to wykonuje niezwykle żmudną, ale bardzo potrzebną pracę, polegającą na przeszukiwaniu logów systemowych pod kątem wszelkich anomalii. Skonfigurowane według standardowych zaleceń potrafi być bardzo krzykliwe zasypując nas stosem maili informujących w wykrytych, podejrzanych odstępstwach od prawidłowej pracy systemu operacyjnego. Co prawda zwalnia nas ono z konieczności codziennego przeglądania raportów o systemie, jednak nawet najbardziej usłużne narzędzie będzie bezlitosne jeśli nie zajmiemy się filtrowaniem generowanych komunikatów.

W przypadku logcheck cała sztuka polega na odpowiednim definiowaniu filtrów w katalogach:

/etc/logcheck/ignore.d.{paranoid;server;workstation}

Zazwyczaj wystarczy korzystać ze ścieżki /etc/logcheck/ignore.d.server, wpisując w plikach testowych wyrażenia regularne. logcheck porównuje wyrażenie z wyszukanym rezultatem i w przypadku zgodności zapobiega generowaniu monitu. Budowanie wyrażeń regularnych samo w sobie jest małą sztuką. Czasami niektórzy wpisują po prostu wzorce na sztywno np.

Reloading web server: apache2.

co zapobiegnie periodycznym informacjom o restartowaniu naszego serwera www. Inni zaś potrafią zbudować naprawde wyrafinowane wyrażenia.

W wydaniu 8 Debiana o nazwie Jessie pojawił się jednak pewien błąd, który bardzo utrudnia życie. Dotyczy właśnie filtrowania za pomocą logcheck i demona systemowego systemd. Dotąd nie było żadnych problemów, jednak właśnie Jessie zaczął zasypywać nas komunikatami, które wydają się nie mieć końca. Co ważniejsze żadne filtry wpisane na sztywno nie pomagają, bowiem reguły systemd są bardzo obszerne i groźne byłoby wycięcie informacji, które mogą okazać się istotne z punktu widzienia administrowania naszym serwerem.

W tym przypadku z pomocą przychodzi strona Debian Wiki i gotowy zestaw wyrażeń przygotowanych przez jej użytkowników. Wystarczy skopiować je do pliku tekstowego we wspomnianym wcześniej katalogu i gotowe. Wszytskie aktualne reguły można pobrać, a w zasadzie skopiować pod adresem:

https://wiki.debian.org/systemd/logcheck

Zapraszam 🙂

MG

Tagi: , ,

Macierz RAID1 i problemy z GRUB2

Luty 18th, 2017 | Brak Komentarzy | Kategoria: Linux, Porady

RAID1Powszechnie wiadomo, że nie jest szczególnie trudno zbudować macierz programową RAID1 używając systemu operacyjnego Debian. Przy instalacji jest to jedna z najczęściej wybieranych opcji, w celu zabezpieczenia się przed niespodziewaną utratą danych. Większość tak zwanych software’owych raidów, oferowanych przez producentów płyt głównych, opiera się właśnie o pakiet mdadm, czyli w zasadzie jest to dokładnie takie samo rozwiązanie jak w przypadku zwyczajnej instalacji. Przyznam się, że często wyłączam raid na płycie głównej, bo wolę panować do końca nad systemem, i po prostu instaluję oprogramowanie ręcznie. I wszystko było by dobrze gdyby nie jeden, nie zrozumiały przeze mnie fakt. Otóż do tej pory, przy składaniu raidu, instalator modyfikuje konfigurację bootloadera grub tylko dla pierwszego dysku (np. /dev/sda). Co oznacza, że w przypadku uszkodzenia drugiego dysku (np. /dev/sdb) twardego komputer przeżyje awarię, jednak jeżeli zostanie uszkodzony pierwszy dysk można mieć sporo kłopotów z jego uruchomieniem. Internet jest pełen takich historii, jak również mnóstwo jest porad jak zapobiegać lub usunąć ten błąd. Ja gorąco będę namawiał do przygotowania się zawczasu i skonfigurowania prawidłowo systemu na samym początku. W tym celu zaraz po instalacji systemy wystarczy skorzystać z trzech prostych poleceń (wydawanych z konta root)):

mv /boot/grub/device.map /boot/grub/device.map.old
grub-mkdevicemap
update-grub2 && grub-install /dev/sda && grub-install /dev/sd

Czasami naprawdę niewiele wystarczy, żeby zabezpieczyć się na przyszłość.

MG

Tagi: , , , ,

Debian Jessie – sshd i obsługa PAM

Styczeń 21st, 2017 | Brak Komentarzy | Kategoria: Linux, Porady

Debian PAMW najnowszej wersji Debiana (Jessie), nie wiedzieć skąd pojawił się błąd związany z obsługą sesji SSH. Do tej pory, wykonując typowe prace administracyjne takie jak aktualizacje, w szczególności wymianę jądra systemu na nowszą wersję, nie było żadnego problemu kiedy trzeba było wydać polecenie reboot. Serwer prawidłowo kończył sesję SSH i po krótkiej chwili można było znowu się połączyć. O ile oczywiście dał radę podnieść się po naszych zabiegach. Tym razem jest inaczej. Krótko mówiąć sesja SSH zawiesza się i bez siłowego zamknięcia terminala nie ma mowy o kontynuowaniu pracy. Związane jest to z obsługą biblioteki PAM. Żeby pozbyć się opisanej niedogodności konieczna jest instalacja dodatkowych bibliotek, które nie są dostarczane w standarowej wersji:

apt-get install libpam-systemd dbus

Na tym nie koniec. Musimy upewnić się, że nasz daemon sshd ma włączoną obsługę PAM. Tak inaczej wystarczy wydać polecenie:

 grep -i UsePAM /etc/ssh/sshd_config

i ewentualnie odkomentować w pliku /etc/ssh/sshd_config wspomnianą linię. Na koniec restartujemy sshd:

/etc/init.d/ssh restart

MG

Tagi: , , ,

Time has been changed – co oznacza ten komunikat

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

Time has been changedJednym 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

Tagi: , , , , ,

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

Budowa serwera SFTP na bazie SSH i Debiana

Maj 21st, 2016 | Brak Komentarzy | Kategoria: Linux, Porady

SFTPJak 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

Tagi: , , , , ,

ClamAV-clamd av-scanner FAILED

Kwiecień 16th, 2016 | Brak Komentarzy | Kategoria: Linux, Porady

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

Tagi: , , ,

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

Październik 17th, 2015 | Brak Komentarzy | Kategoria: Linux, Porady

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

Tagi: , , , ,

Jak zmienić UID i GID w Linuxie

Wrzesień 19th, 2015 | Brak Komentarzy | Kategoria: Linux, Porady

TerminalPrzenoszenie kont użytkowników między serwerami Debian jest czynnością prostą i bezpieczną. W zasadzie wystarczy wykonać 3 podstawowe czynności:

  1. Skopiować odpowiednie grupy z pliku /etc/group.
  2. Skopiować odpowiednich użytkowników z pliku /etc/passwd.
  3. Skopiować hasła powyższych użytkowników z pliku /etc/shadow.

Wymienione pliku są tekstowe zatem sprawdzi się metoda copy-paste. Oczywiście na koniec trzeba skopiować katalogi domowe użytkowników (np. używając tar z opcjami cvzf) a potem rozpakować na serwerze docelowym (tar xvzf). Jeśli ktoś woli można skorzystać z synchronizacji między serwerami za pomocą rsync.

Problem może pojawić się wtedy kiedy na docelowym serwerze istnieją już konta posiadające identyfikatory systemowe UID (user ID) i GID (group ID) i nie możemy wprost kopiować linii plików konfiguracyjnych aby uniknąć sytuacji, w której np. dwa konta posiadają ten sam UID. Wówczas przed kopiowaniem trzeba zmienić UID i GID na serwerze źródłowym. Czy jest to proste? Jak wszystko w Linuxie… Poniżej zamieszczam polecenia pozwalające przygotować się do całego procesu:

usermod -u <NowyUID> <Login> 
groupmod -g <NowyGID> <Grupa>
find / -user <StaryUID> -exec chown -h <NowyUID> {} \;
find / -group <StaryGID> -exec chgrp -h <NowyGID> {} \;
usermod -g <NowyGID> <Login>

MG

Tagi: , ,