K-NET s.c.

VMware, converter, 97% error

Wirtualizacja w wydaniu VMware jest bardzo popularnym rozwiązaniem. Żeby uruchomić pełnoprawny serwer z maszynami wirtualnymi wystarczy średniej klasy sprzęt oraz konto na platformie VMware. Oprogramowanie ESXi (co prawda w ograniczeniami, które dotyczą przede wszystkim limitu rdzeni na jednostkę) jest dostępne jako wersja ewaluacyjna do pobrania. Wygodny interfejs webowy pozwala nawet niezaawansowanemu użytkownikowi na zarządzanie swoim środowiskiem.

Gdy przekonamy się do zalet wirtualizacji może pojawić się konieczność przeniesienia fizycznych serwerów do Vmware. Również w tym przypadku firma udostępnia narzędzie Vmware Standalone Converter (VCS), aby za jego pomocą automatycznie przeprowadzić proces migracji. I tutaj zaczynają się schody. Wspomniana aplikacja, która adresowana jest dla systemów Windows jest po prostu przestarzała. Owszem obsługuje większość systemów operacyjnych, ale nie wszystkie do końca prawidłowo.

Pierwsze kłopoty pojawiają się w momencie konwersji systemów linuksowych z macierzą RAID zrealizowaną programowo. Ze względu na ogólnodostępne informacje na ten temat nie skupie się dalej na tym problemie. Następne w przypadku nowszych wersji Linuksów. W artykule opisuje proces na przykładzie Debiana w wersji 10. VSC nie potrafi sobie poradzić z przeniesieniem GRUB, czyli zainstalowaniem bootloadera. Konwersja zatrzymuje się na 97% i pojawia się komunikat o błędzie.

Jest on mylący ponieważ sugeruje nieukończenie konwersji, która w rzeczywistości dobiegła do końca etapu klonowania danych i jedyną operacją niesfinalizowaną jest wspomniana wcześniej instalacja GRUB.

Możemy (a raczej powinniśmy) ręcznie naprawić sytuację. Na hoście maszyn wirtualnych wyszukujemy zduplikowany serwer (w tym przypadku jego kopie). Następnie edytujemy jego ustawienia i wskazujemy obraz ISO z wersją instalacyjną Debian 10 jako źródło dla danych w napędzie DVD. Trzeba jednak pamiętać o włączeniu opóźnienia w bootowaniu systemu (opcja ukryta w menu Edit) tak aby możliwe było wyświetlenie menu wyboru źródła systemu za pomocą klawisza ESC podczas uruchamiania maszyny.

Po starcie systemu z płyty instalacyjnej wybieramy Rescue Mode. Następnie powinniśmy uruchomić konsolę tekstową i wywołać polecenie blkid. Jest to konieczne, gdyż musimy poznać nowe identyfikatory dysków twardych UUID, które zmieniają się podczas klonowania.

Następny krok to pracowita edycja pliku /etc/fstab, aby poprawić identyfikatory, o których wspomniałem powyżej. Możemy to zrobić za pomocą edytora vi lub nano, w zależności od tego, który będzie dostępny.

W ostatnim kroku korzystamy z dwóch komend, instalując (i naprawiając przy okazji) GRUB:

grub-install /dev/sda
update-grub

W miejsce przykładowej /dev/sda powinniśmy wstawić docelową partycję dla bootloadera (prawdopodobnie w 90% przypadków nie trzeba tego zmieniać).

Ostatnią czynnością będzie ręczne zrestartowanie maszyny wirtualnej – korzystamy z funkcji ESXi. Przy odrobinie szczęścia okaże się, że jednak maszyna została przeniesiona prawidłowo.

MG

Tagi: Debian, Linux, serwer, VMWare, wirtualizacja

Portainer – aktualizacja

Portainer to jedna z najlepiej znanych i powszechnie stosowanych platform do wygodnego zarządzania kontenerami Dockera. Zamiast koncentrować się na zapamiętaniu komend linii poleceń możemy przez interfejs graficzny wyklikać praktycznie wszystko. Oczywiście, że zawsze znajdą się zwolennicy „czarnego ekranu”, przyznam że rówież często korzystam z tej metody, ale przy dużej liczbie zarządzanych kontenerów wygodniej jest po prostu skorzystać z przeglądarki.

Od czasu do czasu, w dolnym lewym rogu ekranu powitalnego Portainera pojawia się jednak informacja o dostępności nowej wersji. I w tym przypadku, nie ma już wyjścia, musimy posilić się bezpośrednio terminalem tekstowym. Poniżej zamieściłem podstawowe komendy, których użycie pozwoli zaktualizować Portainer. Oczywiście założyłem, że środowiskiem uruchomieniowym naszego Dockera jest Linux. W moim przypadku, bez wyjątku to któraś wersja pochodna z gałęzi Dabiana. Należy również wspomnieć, że jak będziemy już mieć najnowszy Portainer, to z jego poziomu możemy aktualizować inne kontenery, nie używając linii poleceń.

Zaczynamy od wpisania dwóch poleceń aby zatrzymać i usunąć kontener Portainera:

docker stop portainer
docker rm portainer

Następnie usuwamy obraz Portainera z lokalnego repozytorium:

docker images
docker rmi [IMAGE ID]

Pierwsze polecenie pokaże nam listę wszystkich obrazów. W kolejnym staramy się usunąć wybrany poprzez wskazanie jego ID.

Teraz czas na pobranie najnowszego obrazu Poratinera:

docker pull portainer/portainer-ce

I wreszcie możemy zainstalować nową wersję platformy:

docker run -d -p 8000:8000 -p 9000:9000 —name=portainer /
—restart=always -v /var/run/docker.sock:/var/run/docker.sock /
-v portainer_data:/data portainer/portainer-ce

Dobrze jest pamiętać aby nie zmieniać wartości parametru portainer_data, dzięki czemu nie stracimy ustawień konfiguracyjnych pomiędzy kolejnymi aktualizacjami.

I to wszystko. Teraz można przystąpić do testowania.

MG

Tagi: Docker, linia poleceń, Linux, Portainer, wirtualizacja

Automatyczne rozsyłanie e-maili – Swaks

Automatyczne rozsyłanie e-maili (np. za pomocą opisanego poniżej programu Swaks) z informacjami technicznymi jest chlebem powszednim każdego właściciela serwera. Ponieważ nadzorowanie za pomocą codziennego logowania się i ręcznego przeglądania dzienników systemowych bywa dość żmudną czynnością, stąd każda automatyzacja jest w cenie. Generalnie w systemach linuksowych lokalny serwer SMTP jest na wyposażeniu standardowym. Wysłanie wiadomości z jego pomocą nie stanowi problemu, o ile stosujemy lokalnego klienta. Zresztą wiele usług systemowych właśnie w ten sposób komunikuje się z użytkownikiem. Niemniej czasami potrzebujemy wysłać email na zewnętrzny adres. Poza tym nie zawsze chcemy konfigurować w pełni MTA. Być może łatwiej byłoby użyć jakiegoś kompaktowego narzędzia, które pozwoli z linii poleceń, wygodnie i w prosty sposób przesłać pełnowartościowy email.

Aplikacja Swaks (Swiss Army Knife for SMTP) jest maksymalnie uproszczonym, ale bardzo przydatnym narzędziem wiersza poleceń. Jest ono przede wszystkim używane do testowania serwera SMTP, ale również do wysyłania poczty bezpośrednio „z palca” oraz za pomocą skryptów czy systemowej usługi crone.

Żeby nie zagłębiać się zbytnio w opis wszystkich możliwości Swaks, które zawsze można poznać z pomocą dokumentacji, przejdźmy bezpośrednio do przykładu:

swaks --to odb@mail.org --from "nad@mail.net" /
--server serwer.smtp.net --auth LOGIN --auth-user / 
"nad@poczta.net" --auth-password "P@ssw0rD" / 
-tls --port 587 --header "Subject: [WAZNE] Log systemowy" /
--body /var/log/sys.log

Rozłóżmy powyższą komendę na czynniki pierwsze:

• to – wskazujemy odbiorcę naszej wiadomości,
• from – to adres, który zostać wyświetlony w polu FROM,
• server – serwer SMTP, którego chcesz użyć do wysyłania poczty (np. Gmail),
• auth – rodzaj identyfikacji, jeśli używamy hasła to LOGIN,
• auth-user – nazwa użytkownika na serwerze SMTP,
• auth-password – hasło użytkownika (niestety zapisane jawnym tekstem!),
• tls – włączamy szyfrowanie STARTTLS,
• port – port serwera SMPT, np. 587 czyli Submission,
• header – nagłówek wiadomości, jeśli chcemy dodać temat to użyjemy wyrażenia Subject:,
• body – tutaj może pojawić się tekst lub ścieżka do pliku, który chcemy wczytać.

Celowo pominąłem sposób dodawania załącznika, bo chcę zachęcić do zabawy z narzędziem. Zawsze warto poświęcić 15 minut na testy i przekonać się jak bardzo jest ono wygodne, nawet dla użytkownia z podstawową wiedzą.

MG

Tagi: komendy, linia poleceń, Linux, serwer

Konteneryzacja – error while removing network

Konteneryzacja jest obecnie bardziej modna niż wirtualizacja. Świadomie zaryzykuję takie stwierdzenie choć wiem, że wielu mogłoby się oburzyć. Nie obecnie, tylko od kilku lat, oraz wirtualizacja nadal ma się dobrze. Trzeba jednak przyznać, że lista aplikacji, które zostają zwirtualizowane do formy kontenera np. typu Docker, wydłuża się z każdym rokiem wykładniczo. Dlatego jako fanatyk klasycznej wirtualizacji również musiałem zmierzyć się z tym zagadnieniem. Początki były trudne i nie była to miłość od pierwszego wejrzenia. Jednak z czasem powoli przekonywałem się, chociaż do dzisiaj gnębi mnie myśl o bezpieczeństwie w kontekście aktualizacji gotowych kontenerów dostępnych chociażby przez stronę Docker Hub. Jest to jednak historia na inną opowieść.

Wracając do tematu, skoro przekonałem się do świata kontenerów to zacząłem niemal masowo testować nowe rozwiązania, aplikacje itd. Taki jest los neofity, ale co na to poradzić. Będąc jednocześnie zagorzałym zwolennikiem minimalizmu, wymyśliłem sobie implementację minimalnego serwera w oparciu o Debian Buster (coś w rodzaju bare metal) gdzie jedynym większym softem będzie właśnie paczka docker. W miarę przybywania aplikacji w moim testowym środowisku zacząłem szukać nakładki graficznej do zarządzania. Z pomocą przyszedł pakiet Portainer ze środowiskiem graficznym do zarządzania całą wirtualizacją wraz z prawie jej wszystkimi elementami. Brnąłem dalej. Wiadomo jednak, że im dalej w las tym więcej drzew. Zaczęły się pojawiać problemy. Co gorsza czasami były to w zasadzie dość zasadnicze usterki Dockera. Jedną z nich okazały się hmm… nieścisłości dotyczące definiowania sieci przydzielanych poszczególnym aplikacjom.

Jedną z opcji dostępnych z poziomu Dockera jest tworzenie tzw. macvlan. Jest to sieć kontenerów, które są wystawione poza natowaną warstwą sieciową chronioną przez natywną wirtualizację, co zapewnia oczywiście separowanie aplikacji, a więc odpowiedni poziom bezpieczeństwa, ale uniemożliwia z kolei przydzielanie adresów IP na poziomie równorzędnym z hostem dockera. Czasami potrzebujemy właśnie takiego rozwiązania aby uzyskać efekt podobny do interfejsu typu bridge z klasycznej wirtualizacji (VMware czy KVM). Niestety moim zdaniem obsługa macvlan jest po prostu źle napisana. W wyniku eksperymentowania z sieciami tego typu często dochodzi do sytuacji, w której w systemie pozostają sieci macvlan zachowujące się jak zombie tzn. takie, które do niczego nam się nie przydają (chcieliśmy akurat coś przetestować) a nie można ich usunąć bo otrzymujemy błąd:

„Error response from daemon: error while removing network: configuration network „…. macvlan x.x.x.x” is in use”

W sieci można znaleźć bardzo dużo informacji na ten temat oraz niemal tyle samo propozycji rozwiązania. Ja natomiast chciałem zaproponować jedno z nich, wybrane przeze mnie i myślę, że niezawodne. Zaznaczam od razu, że dotyczy ono hostów typu Linux i wymaga minimalnej znajomości konsoli systemowej. Cały przepis wygląda mniej więcej tak:

• Zaloguj się do swojego hosta za pomocą połączenia SSH.
• Zmień konto na root (o ile już nie zalogowałeś się jako root, ale w tym przypadku poważnie zastanowiłbym się nad zabezpieczeniami Twojego systemu)
• Usuń ręcznie plik local-kv.db

rm /var/lib/docker/network/files/local-kv.db

Tyle w temacie. Rozwiązanie ma tylko taką wadę, że usuwa wszystkie zdefiniowane przez nas sieci ze środowiska konteryzacji. Pozostawia oczywiście tylko te standardowe tj. tworzone na początku instalacji Dockera. Ale porządek na pewno zostanie przywrócony. 🙂

MG

Tagi: Docker, linia poleceń, Linux

Nigdy nie zajrzysz do logów systemowych – porada dla leniwych

Każdy użytkownik systemów z rodziny linuksów w pewnym momencie zaczyna się interesować komunikatami systemowymi. Może się oczywiście zdarzyć, że nigdy nie zajrzysz do logów systemowych, ale jest to raczej mało prawdopodobne. Jeśli zaś jesteś administratorem serwera to czy chcesz czy nie, w terminalu systemowym na pewno zaskoczą Cię nie raz informacje pochodzące od rozmaitych procesów działających w tle. Tak czy inaczej, aby cokolwiek poprawnie zainstalować, a już na pewno skonfigurować, znajomość zawartości katalogu /var/log wydaje się niezbędna.

Oczywiście przeglądanie logów jest czynnością (powiedziałbym) konieczną ale również żmudną. Bywa tak, że nadmiar informacji generowanych przez rozmaite programy staje się przekleństwem. Jest o tyle niebezpieczna sytuacja, że w szumie informacyjnym mogą być ukryte te naprawdę istotne z punktu widzenia np. bezpieczeństwa. Trzeba spojrzeć prawdzie w oczy i z ręką na sercu odpowiedzieć sobie na pytanie czy będzie mi się chciało codziennie pracowicie studiować linijka po linijce pliki z logami, czy może lepiej w jakiś sposób usprawnić to zadanie.

Istnieje kilka dobrych wspomagaczy, czyli narzędzi, które pozwalają parsować logi w locie i kierować do administratora systemu wyłącznie przydatne komunikaty. Aplikacją, z której korzystam na co dzień jest logcheck. Ponieważ mam zwyczaj traktowania poczty elektronicznej jak osobisty notatnik, to właśnie logcheck przesyłający rezultaty skanowania na moją skrzynkę wydaje się być idealnym i dopasowanym rozwiązaniem. Niestety rzeczywistość jest często daleka od ideału. Co prawda nie muszę już ręcznie przeglądać plików, ale tak czy inaczej dziennie otrzymuje od kilkunastu do kilkudziesięciu komunikatów (sic!). Mowa tu o sytuacji kiedy korzystamy z logchecka bez żadnych usprawnień i dodatekowej konfiguracji.

Jak praktycznie każdy program konsolowy również logcheck umożliwia konfigurację do własnych potrzeb. Możliwe jest napisanie własnych filtrów w oparciu o składnie wyrażeń regularnych, które odsieją dla nas automatycznie niepożądaną treść. Tyle, że pisanie wyrażeń regularnych wraz z ich testowaniem na plikach logów systemowych wcale nie jest łatwe i przyjemne. Mogłoby się wydawać, że sytuacja jest bez wyjścia.

Można być jednak zawsze leniwym administratorem i skorzystać z pracy innych (czytaj społeczności Linuksa) i zajrzeć na stronę: https://github.com/ties/logcheck-extrarules. W katalogu ignore.d.server, który jest odpowiednikiem takiego samego zasobu na naszym serwerze znajdziecie wiele zestawów reguł, które są ładnie i logicznie posortowane oraz opisane. W zasadzie wystarczy wyszukać interesujące nas filtry, powiedzmy dla nadmiarowych komunikatów jądra systemu będą to local-kernel, a następnie pobrać do naszego systemu. Jeśli coś nie będzie działać jak trzeba, to zawsze pozostaje ręczne zdobywanie wiedzy i doświadczenia poprzez pisanie wyrażeń regularnych osobiście.

MG

Tagi: Linux, monitoring, serwer

Aktualizacja XSIBackup

XSIBackup jako super wygodne narzędzie do wykonywania kopii zapasowych maszyn wirtualnych VMware sprawuje się bez zarzutu. Pisałem o tym programie wielokrotnie np. tutaj. Wspominałem również, że w połączeniu z VMware vCenter Converter Standalone stanowi szwajcarski scyzoryk na wypadek grubszej awarii tj. gdy musimy bardzo szybko odtworzyć wirtualizację np. z powodu awarii sprzętowej hosta.

W przyrodzie nie ma jednak rozwiązań doskonałych i nawet XSIBackup potrafi spłatać figla. Sytuacja, którą chciałem opisać dotyczy momentu tuż po aktualizacji VMware ESXi, kiedy mamy już powgrywane najnowsze patche a jeszcze nie aktualizowaliśmy naszego programu do kopii. Ja po prostu o tym zapomniałem – do tego stopnia, że nawet przeoczyłem brak nowych raportów email o kopiach zapasowych. A program się zwiesił.

Dość szybko znalazłem opis błędu w Internecie, odpowiedzialny był interpreter, a dokładniej jego niezgodność (w nowej wersji VMware) ze starszą wersją XSIBackup. Stanąłem przed koniecznością zainstalowania nowego wydania… i popełniłem duży błąd. Podążając za rozmaitymi poradnikami z forów użytkowników, gdzie twierdzono, że zasadniczo wystarczy podmienić odpowiednie pliki i wszystko powinno działać, pracowicie skopiowałem co trzeba. Zależało mi głównie na tym aby nie tracić tzw. jobs, czyli zadań kopiowania, które zdążyłem skonfigurować (nie jest to trywialna czynność ze względu na mnogość opcji). Zostawiłem całość bez przetestowania – kolejny błąd, a za dwa dni zadzwonił do mnie zaniepokojony użytkownik z informacją, że serwer nie działa. Chodziło o jdną z maszyn wirtualnych. Okazało się, że nie odpowiada cały host VM 🙁 Była sobota i w tym momencie runęła perspektywa wypoczynku. Po dotarciu na miejsce tzn. do serwerowni, ze zdziwieniem stwierdziłem, że serwer działa bez zarzutu, ale interfejsy sieciowe padły. Rzecz jasna restart całej jednostki pomógł, ale zmobilizowało mnie to do wykonania dwóch czynności, które powinienem zrobić od razu.

Po pierwsze usunąłem całą instalację XSIBackup. Polega to głównie na skasowaniu wszystkich plików i co ważne usunięciu zadań kopiowania na poziomie cron:

rm -rf "/vmfs/volumes/datastore1/xsi-dir"; \ 
chmod 0700 /var/spool/cron/crontabs/root; \ 
sed -i '/-dir\/jobs/d' /var/spool/cron/crontabs/root; \ 
sed -i '/cron-init/d' /etc/rc.local.d/local.sh

Po drugie zainstalowałem od nowa XSIBackup odtwarzając skopiowane wcześniej zadania automatycznego wykonywania kopii. Na szczęście pomogło.

MG

Tagi: ESXi, linia poleceń, Linux, serwer, VMWare

Zewnętrzny numer IP?

Numer IP – bardzo często bywa tak, że z jakichś powodów chcielibyśmy uzyskać informację na ten temat (zwłaszcza jeśli chodzi o zewnętrzny numer IP). Jak zauważyłem problem ten dotyczy nie tylko sytuacji, w której po prostu sprawdzamy czy operator przydzielił nam właściwy adres IP, ale również coraz częściej jeśli chcemy np. sprawdzić czy zadziałało połączenie prywatne VPN. Zauważyłem, że powoli stają się one standardem (i bardzo dobrze), warto zatem czasami upewnić się, że nasz ruch przechodzi przez odpowiedni router.

Do tej pory można to było zrobić na kilka, mniej lub bardziej eleganckich sposobów. Dla mniej wprawnych zawsze pozostaje np. serwis https://www.whatismyip.com. Ta metoda wymaga jednak posiadania interfejsu graficznego czyli GUI. A jak zrobić to samo na serwerze, który posiada tylko czystą konsolę tekstową?

Tutaj również mamy do dyspozycji wiele metod. Szczególnie jeżeli używamy mojego ulubionego rozwiązania czyli Linuxa. Od lat korzystałem w tym celu z dobrze znanego polecenia wget, które pozwala na sparsowanie wyjścia i tą nieco pokrętną metodą uzyskanie odpowiedzi na pytanie postawione w tytule artykułu:

/usr/local/bin/wget -qO - http://ipinfo.io/ip

Świat idzie jednak do przodu (i bardzo dobrze). wget powoli jest zastępowany przez nowe polecenie (a w zasadzie rozbudowane narzędzie) czyli curl. W takim wydaniu uzyskanie informacji jaki jest zewnętrzny numer IP jest jeszcze prostsze:

curl http://icanhazip.com

I o to przecież wszystkim chodzi 🙂

MG

Tagi: komendy, konfiguracja, linia poleceń, Linux

Eksport i import LDAP

Przez ostanich parę lat serwery poczty e-mail przeszły niemałą rewolucję. Jak dobrze pamiętam, kiedyś postawienie własnego MXa wiązało się z konkretną pracą. Mówiąc precyzyjniej zabezpieczeniem takiego serwera tak, aby nie był open-relayem, włączeniem wszystkich autoryzacji i np. przygotowaniem skrzynek z obsługą IMAP, LDAP itp. Obecnie można w miarę łatwo osiągnąć ten cel stosując dopracowane i wygodne w użyciu platformy, jak chociażby iRedMail. Jest to prawdą w odniesieniu do standardowych konfiguracji. Nie po to jednak mamy Linuxa aby zostawić rzeczy samym sobie i nie próbować zmieniać czy poprawiać konfiguracji, czytaj – dostosowywać do swoich potrzeb.

Przy rozbudowanych systemach, z obsługą dużej liczby skrzynek pocztowych, wygodną metodą jest przechowywanie konfiguracji w bazie danych. Osobiście preferuję w tym celu usługi katalogowe LDAP. Moim zdaniem są szybkie i niezawodne, a odpowiednio skonfigurowane bezpieczne. Wspomniany iRedMail pozwala na organizowanie warstwy logiki serwera pocztowego za pomocą LDAPa.

Świat nie stoi w miejscu i nawet jeżeli jako administratorzy mamy względny spokój, bo nikt od nas nie wymaga przenoszenia usługi pocztowej do nowego dostawcy lub na nowe serwery, to zawsze może się zdarzyć, że sami zostaniemy do tego zmuszeni, bo np. chcemy wymienić sprzęt (lub fizycznie nawet cały serwer). Oczywiście w najprostszym scenariuszu będzie się to wiązało z wykonaniem kopii zapasowej bazy LDAP a potem odtworzeniem jej na nowym węźle. No właśnie – w najprostszym, co się jednak stanie jeżeli musimy zmienić co nieco w naszej usłudze katalogowej.

Przykładem takiej ingerencji może być wymuszenie zmiany atrybutu Distinguished Name – DN. Dzieje się tak, gdy przenosimy jedną z obsługiwanych domen emailowych do całkowicie nowej struktury LDAP. W tym miejscu okazuje się jak wygodny i zarazem niewygodny potrafi być LDAP. Otóż dla jego doświadczonego użytkownika sprawa jest prosta i realizowana w 3 krokach:

• wyeksportuj starą bazę LDAP do pliku LDIF (format tekstowy, bez kompresji)
• wyedytuj dowolnym edytorem plik LDIF i wprowadź potrzebne zmiany
• zaimportuj plik LDIF do nowej bazy LDAP

I wszystko byłoby dobrze gdyby nie fakt, że w trakcie eksportu każdy wiersz pliku LDIF jest obcinany do 76 znaków a część nadmiarowa przenoszona ze spacją do nowej linii. Bardzo to utrudnia zastosowanie popularnej metody edycji Search and Replace, ponieważ wzorzec wyszukiwania nie jest jednoznaczny. Należy po prostu inteligentnie usunąć wszystkie miejsca łamiania wiersza.

Jeżeli dysponujemy Linuxem z jego wszelkiemi udogodnieniami i narzędziami to przepis jak to zrobić będzie prosty:

awk 'NR>1 && !sub(/^ /,""){print s; s=""} \ 
{s = s $0} END{print s}' stary.ldif > nowy.ldif

Potem pozostaje już tylko import atrybutów z wartościami do nowej bazy LDAP.

MG

Tagi: konfiguracja, ldap, Linux, poczta elektroniczna

DNSBL i Postfix

RBL, DNSBL o co w tym chodzi? Chociaż czasami poczta elektroniczna nie jest łatwa w konfiguracji to do tej pory, przynajmniej moim zdaniem, nie wymyślono lepszego zamiennika. Szczególnie jeśli mowa np. o korespondencji firmowej, oficjalnej itp. Będąc administratorem firmowego serwera pocztowego na pewno nie unikniemy walki ze spamem i temu chciałbym poświęcić ten wpis.

Wydawać by się mogło, że temat jest ponad miarę wyeksploatowany i w zasadzie nie ma nad czym się rozwodzić. Dlatego nie chcę się skupiać na instalacji i zabezpieczeniu serwera w całości. W końcu można do tego użyć chociażby pakietu iRedMail, który naprawdę polecam. Tym razem chcę pokazać jak ubić spam na wejściu, czyli na poziomie Postfixa, a jeszcze precyzyjniej na poziomie demona systemowego nierozerwalnie z nim związanego – mowa o Postscreen. Zwróćmy od razu uwagę, że taka konfiguracja nie wymaga instalacji np. Amavis i Spamassasin, co bywa pewnym wyzwaniem, zwłaszcza dla początkujących użtkowników.

Podstawą dla przytaczanego tutaj rozwiązania jest DNSBL, czyli czarna lista tworzona z pomocą DNS. Nie musimy tworzyć jej sami, możemy wykorzystać ogólnodostępne serwisy, które robią to dla nas. Z Postfixem bardzo dobrze komponują się dwa z nich – Spamhaus oraz BarracudaCentral. W tym miejscu należy wspomnieć, że Spamhaus ma ograniczenie do 100.000 połączeń na dzień. Zakładam jednak, że mówimy o normalnym serwerze pocztowym dla średniej firmy, więc raczej nie powinniśmy przekroczyć 100.000 maili przychodzących z zewnątrz dziennie.

Ostatecznie uzbrojenie w powyższą wiedzę możemy przystąpić do konfiguracji Postfixa, która jak zwykla jest dosyć prosta. 🙂

Skonfigurowanie obsługi DNSBL wymaga wyedytowania pliku /etc/postfix/main.cf i dodaniu parametrów do opcji postscreen_dnsbl_sites:

postscreen_dnsbl_sites =
  zen.spamhaus.org*2
  b.barracudacentral.org*2

Liczba na końcu parametru jest wagą, która powoduje podbicie punktacji.

Sugerowaną konfiguracją jest również korzystanie z lokalnego serwera cache DNS. Może to być dowolny pakiet. Przy dużym natężeniu ruchu przychodzącego zdecydowanie przyspiesza działanie usługi pocztowej:

postscreen_dnsbl_sites =
  zen.spamhaus.org=127.0.0.[2..11]*2
  b.barracudacentral.org=127.0.0.2*2

Ostanim parametrem, którego wartość warto rozważyć jest postscreen_dnsbl_action. Zazwyczaj jest ona ustawiona na enforce, co oznacza przekazanie do dalszego przetwarzania. Czasami jednak warto jest ubić wszystkie niechciane połączenia:

postscreen_dnsbl_action = drop

Po zapisaniu nowej konfiguracji Postfixa, musimy ponwnie uruchomić serwis.

MG

Tagi: konfiguracja, Linux, poczta elektroniczna, Postfix

OpenVAS – testy penetracyjne

W dzisiejszych czasach wykonywanie testów penetracyjnych jest, lub przynajmniej powinno być, elementarzem każdego administratora, który zarządza siecią z serwerami obsługiwanymi przez innych użytkowników. Doświadczenie uczy, że pomysłowość ludzka polegająca m. in. na pozostawianiu niezabezpieczonych usług, skonfigurowanych niepoprawnie aplikacji itp. jest praktycznie nieograniczona. Niestety sieć jest tak bezpieczna jak jej nasłabszy punkt. Dlatego chciałem napisać parę słów o dosyć popularnym i prostym w obsłudze narzędziu jakim jest OpenVAS.

Większość popularnych dystrybucji Linuxa posiada gotowe paczki do instalacji. W Debianie 10 Buster (jak do tej pory ostatnim) nie trzeba nawet wspomagać się dodatkowymi bibliotekami, wystarczy wydać polecenie:

apt-get install openvas -y

Po kilku lub kilkunastu minutach, w zależności od stanu łacza internetowego, cały pakiet zostanie zainstalowany i można przejść do jego konfiguracji:

openvas setup

Aplikacja rozpocznie pobieranie aktualizacji z 3 źródeł – NVT, Cert Data i SCAP Data, tak abyśmy mieli dostęp to świeżego zestawu testów, czyli tak naprawdę np. najnowszych definicji dotyczących exploitów, opisanych zagrożeń itp. Całość trochę potrwa i na koniec zostaniemy poinformowani o sukcesie (mam nadzieję) oraz co najważniejsze wyświetlone zostanie hasło dla administratora usługi. Hasło w zasadzie jest jednorazowe i należy je zmienić od razu po pierwszym zalogowaniu, tym bardziej, że nie jest wygodne do zapamiętania.

OpenVAS jest obsługiwany za pomocą przeglądarki internetowej. Domyślnie skonfigurowany jest tylko dostęp lokalny. Może to stanowić pewne utrudnienie, szczególnie w sytuacji gdy korzystamy z serwera bez środowiska graficznego. Dlatego powinniśmy sprawdzić adres IP swojego serwera:

ip a

Następnie trzeba wedytować 2 pliki konfiguracyjne:

/lib/systemd/system/greenbone-security-assistant.service
/lib/systemd/system/openvas-manager.service

i zmienić adres '127.0.0.1′ na uzyskany adres naszego serwera – w każdym miejscu, w którym występuje.

Na koniec pozostaje uruchomić ponownie usługę OpenVAS:

systemctl daemon-reload 
openvas-stop 
openvas-start

Od tej chwili możemy cieszyć się w pełni funkcjonalnym skanerem sieci do celów testów penetracyjnych. Otwieramy przeglądarkę i podajemy adres:

https://adres_ip_serwera:9392

MG

Tagi: Debian, konfiguracja, linia poleceń, Linux, serwer