VMware ogłasza powrót jednego z najpopularniejszych produktów w katalogu – vCenter Converter. Wydano nową i ulepszoną wersję produktu, kompatybilną z vSphere 7.0 i ESXi 7.0. Opublikowana wersja koncentruje się głównie na poprawie stabilności i standardów bezpieczeństwa Konwertera oraz zachowaniu istniejącej funkcjonalności.
VMware vCenter Converter zachęca do wysłania informacji o chęci dołączenia do programu vCenter Converter Beta. Można skorzystać z tej możliwości, aby wpływać na przyszły kierunek rozwoju produktu. Jeśli nie masz dostępu do społeczności Beta, wystarczy, że odwiedzisz stronę rejestracji vCenter Converter BETA i przejdziesz do wypełnienia oraz wysłania formularza.
vCenter Converter jest bezpłatnym narzędziem zapewniającym możliwość konwersji maszyn wirtualnych działających na hiperwizorach innych dostawców oraz maszyn fizycznych na maszyny wirtualne VMware. Mowa wersja vCenter Converter obsługuje konwersję rozwiązań opartych na MS Hyper-V, konwersję pomiędzy formatami wirtualnymi VMware (Workstation, Fusion) oraz rekonfigurację maszyn wirtualnych VMware. vCenter Converter wspiera wirtualne stacje robocze działające pod kontrolą systemów Windows, Linux Ubuntu, CentOS, Red Hat Enterprise Linux.
Kolejne wydania będą wzbogacać listę obsługiwanych hyperwizorów, wersji vSphere, systemów operacyjnych i wirtualnych wersji sprzętu.
Jak powiadają rasowi sysadmini nie poznał życia kto nie administrował serwerem poczty – niezależnie czy sam czy za pomocą dużego dostawcy – wszędzie czekają pułapki jak chociażby rekord Gmail SPF. Całkiem niedawno oznaczało to budowanie serwera od podstaw. Można w tym celu bawić się Linuksem i rozwiązaniami typu iRedMail, które zdecydowanie polecam jako wieloletni użytkownik. Nie ma przeszkód aby bardzo ułatwić sobie zadanie i w oparciu o kontenery Dockera zainstalować mailcow. Można wreszcie skorzystać z Microsoft Exchange. Dla każdego coś się znajdzie.
Po instalacji serwera pocztowego dla wybranej domeny trzeba skonfigurować serwer DNS. Oprócz obligatoryjnych rekordów MX wskazujących podstawowy serwer pocztowy a także zapasowe jeśli jest taka potrzeba i możliwość warto pamiętać o kilku dodatkowych. We współczesnym świecie liczą się wszelkiego rodzaju zabezpieczenia.
Rekordem który chciałbym krótko opisać jest TXT pozwalający na zdefiniowanie protokołu SPF – Sender Policy Framework. Obecnie wiele serwerów sprawdza jego wartość i nie pozwala przyjąć wiadomości w przypadku błędów bądź braku tego wpisu. Generalnie nie jest to specjalnie trudna rzecz a w sieci można znaleźć dużo poradników na ten temat, czy nawet generatorów znacznie upraszczających sprawę.
Co jednak zrobić gdy zdecydowaliśmy się na skorzystanie z dużego dostawcy usług a nie budowanie własnego serwera? Czy mocny gracz na rynku zawsze będzie pamiętał o wszystkich szczegółach? W kontekście ustawień DNS niekoniecznie. Zwłaszcza jeżeli serwer nazw nie został zrealizowany za pomocą jego zasobów. Weźmy jako przykład usługi pocztowe Google.
Samo wykupienie skrzynek pocztowych Gmail dla naszej domeny firmowej lub jakiejkolwiek innej nie załatwi nam wspomnianych wpisów DNS, w szczególności Gmail SPF. Może się wydawać, że jest to dosyć niespotykany scenariusz użycia. W rzeczywistości jednak nierzadko firma posiada najpierw własny serwer pocztowy i własny serwer DNS a potem przenosi tylko usługę email na zewnątrz. Jeśli mamy do czynienia z taką sytuacją należy pamiętać aby zdefiniować koniecznie rekord TXT postaci
v=spf1 include:_spf.google.com ~all
Aż tyle i tylko tyle…. aby nie otrzymywać niespodziewanych telefonów od użytkowników z uwagami typu ”moja poczta nie dochodzi” a przecież o to w praktyce chodzi 🙂
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.
Wakacje dobiegają końca. Będąc cały czas na urlopie zastanawiałem się czym mógłbym się podzielić. Zależało mi na czyś w miarę świeżym, ale jednocześnie lekkim do przyswojenia. Wybór padł na dwa tematy tj. platforma TP-Link Omada oraz bramka Apache Guacamole. Ten pierwszy jest dużym zagadnieniem, chociaż wielu użytkowników dowiaduje się o produkcie TP-Link przy okazji budowy zarządzanych centralnie sieci bezprzewodowych. Zapewniam jednak, że Omada to dużo więcej. Cóż, właśnie poznaję ten system, zatem dzisiaj parę, wakacyjnych jeszcze, zdań o bardzo przyjemnym wynalazku jakim jest Guacamole (nieco przewrotnie).
Na pewno każdy zajmujący się zagadnieniami sieciowymi czytelnik napotkał problem związany z uzyskaniem dostępu do zdalnych lokalizacji. Czy to będą sieci firmowe, czy też całkiem prywatne, zazwyczaj kończy się na uruchomieniu VPN. Wielokrotnie wspominałem, że najbardziej lubię tandem sprzętowo-programowy czyli router Mikrotika plus L2TP VPN. Główną przyczyną jest klient L2TP VPN, który został wbudowany w większość systemów operacyjnych, a Windows 10, po ostatnich aktualizacjach prowadzi wręcz za rękę jeśli chcemy z niego skorzystać.
Innym rozwiązaniem jest tzw. poor man’s VPN, czyli serwer SSH wraz z tunelowaniem i przekierowywaniem portów. Zalętą rozwiązania jest konieczność posiadania tylko jednego otwartego portu TCP na firewallu. Zaś wadą instalowanie użytkownikom klientów SSH, w tym najbardziej popularnego dla Windows PuTTY. Ich obsługa nie jest prosta dla przeciętnej osoby. Jak zauważyłem, mnogość opcji, która mnie osobiście przypadła do gustu stanowi problem dla innych. Jak dostać się do zdalnego pulpitu RDP w firmie za pomocą tunelu SSH, zdecydowanie nie należy do kwestii łatwych do wyjaśnienia.
Jeszcze inną kwestią pozostają klienty do obsługi wszelkich zdalnych dostępów, które muszą być bezpieczne i jednocześnie w prosty sposób dawać możliwość pracy ze zdalnymi zasobami. Czy można jednak pominąć jakiekolwiek instalacje i jednocześnie zabezpieczyć swój dostęp?
Okazuje się, że odpowiedzią na tak postawione pytanie jest bramka Apache Guacamole. Produkt ten cyt. jest aplikacją webową HTML5, która zapewnia dostęp do środowisk pulpitu za pomocą zdalnych protokołów (takich jak VNC lub RDP). Guacamole jest również projektem, który tworzy tę aplikację internetową i dostarcza API, które ją napędza. API może być używane do zasilania innych podobnych aplikacji lub usług. Tyle od autorów projektu.
Ponieważ wpis miał być wakacyjny, a to oznacza, że nie będę rozwodził się nad technikaliami, chciałbym natomiast zachęcić do wypróbowania. W tym miejscu zaoszczędzę Wam czasu i napiszę, że najprzyjemniejszą metodą instalacji Guacamole będzie kontener Dockera. Aby zrobiło się jeszcze łatwiej dodam, że można użyć platformy Portainer. Poniżej załączam plik dla docker-compose, co jak mam nadzieję spowoduje, że cała instalacja będzie trwała tylko parę minut (sekcja Stacks w Portainer). Resztę pozostawiam na letni wieczór, mamy końcówkę sierpnia, zatem ciemno robi się już dosyć wcześnie, a nic lepiej nie nastraja do zabawy z nowym oprogramowaniem.
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:
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ą.
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.
Problem wyciekania danych z naszych komputerów jest jednym z najczęściej omawianych zagadnień przez ostatnie miesiące a nawet lata. Skądinąd wiadomo, że wszyscy wielcy gracze na rynku ogólnie pojętych usług internetowych starają się pozyskiwać wszelkie możliwe informacje niezależnie od tego czy wyrażamy na to zgodę czy nie. A ponieważ nawet Ci, którzy dotychczas nie korzystali z usług rozporoszonych, na przykład w architekturze klient-serwer, opracowali nowe wersje swoich produktów, które po prostu wymagają Internetu pod pozorem chociażby aktualizacji, to praktycznie każdy chce stosować telemetrię. Jest to oczywiście dość łagodne określenie dla ciągłej obserwacji użytkownika, uczenia się jego nawyków itp.
Żeby walczyć z podobnymi praktykami można zastosować kilka różnych podejść. Pierwszym, które wydaje się być dosyć oczywiste jest zainstalowanie odpowiedniej aplikacji. Często funkcje nadzorowania połączeń wychodzących z komputera mają wszelkiej maści programy antywirusowe. Ale uwaga – bywa, że same lubią nas podglądać. Poza tym wiele aplikacji potrafi wykryć działanie tychże i na przykład prosić użytkownika o wyłączenie zapory pod pozorem odmowy świadczenia dalej usługi.
Kolejnym jest zainstalowanie w przeglądarce internetowej odpowiednich dodatków. Dotyczy to oczywiście korzystania z samej przeglądarki i nie zabezpiecza przed innym rodzajem użytkowania. Nie mniej wtyczki takie jak AdBlock czy Ghostery są bardzo popularne. Ponadto producenci samych przeglądarek dodają w ich najnowszych wersjach blokowanie reklam itd. Z drugiej strony czy można im wierzyć do końca? To pytanie retoryczne. Jedno jest pewne – ta metoda również ma wiele wad.
Trzecim rozwiązaniem będzie skorzystanie z połączenia VPN z funkcją blokowania dla wycieku danych z naszych komputerów. Wymaga to najczęściej zastosowania dodatkowej aplikacji, która będzie w stanie wygenerować wspomniane połączenie VPN, za co nierzadko trzeba zapłacić. Tutaj prym wiedzie usługa o nazwie Internet Private Access. Posiada bardzo szerokie możliwości konfiguracji oraz aplikacje w wersji instalacyjnej dla niemalże każdego systemu operacyjnego. Do równie ciekawych rozwiązań, które zdążyły już zdobyć pewną sławę w kręgach deweloperów należy ProtonVPN. Lista dostawców jest naprawdę długa i nietrudno jest wyszukać odpowiedniego dla siebie.
Na sam koniec zostawiłem rozwiązanie, które moim zdaniem jest najlepsze. Jest ono lekkie bo nie wymaga instalowania żadnego dodatkowego oprogramowania. Ciężko jest je wykryć (mam na myśli aplikacje czy systemy korzystające z telemetrii) bo ingeruje w jeden z podstawowych protokółów sieciowych jakim jest DNS. Jest w stanie zmienić zachowanie absolutnie każdego programu, który tylko będzie chciał nawiązać komunikację przez sieć Internet. Co więcej, całkiem prawdopodobne, że przyspieszy oraz poprawi funkcjonowanie naszych końcówek sieciowych, bo znacznie ograniczy niepotrzebny ruch. Mowa oczywiście o serwerze DNS, który będzie miał odpowiednio skonfigurowane reguły rozwiązywania nazw, tak aby po prostu zablokować wszystkie podejrzane odwołania.
W wersji dla leniwych można po prostu skorzystać z bezpłatnego (będzie miał wyłączone niektóre funkcje ale na początek powinno wystarczyć) gotowca. Jest nim na przykład serwis OpenDNS. Przyznam, że korzystałem z niego przez wiele lat z dużym powodzeniem. Po zarejestrowaniu konta użytkownika oraz skonfigurowaniu serwerów DNS, czyli podaniu poniższych wartości w ustawieniach karty sieciowej system startował bez zarzutu.
208.67.222.222
208.67.220.220
W wersji dla zuchwałych trzeba samemu lokalnie przygotować serwer DSN, który będzie mógł obsługiwać ruch sieciowy. Bardzo dobrym rozwiązaniem jest w tym przypadku Pi-hole. Społeczność użytkowników i programistów przygotowała kompletny system, gotowy do użycia “po wypakowaniu z pudełka”. Można go zastosować na mikrokomputerze Raspberry Pi – jest to jeszcze jedno jego doskonałe zastosowanie. Można również, do czego zachęcam, skorzystać z kontenerów Docker i w zasadzie jednym poleceniem postawić cały serwer.
Na zakończenie warto zadać ponownie pytanie – problem wyciekania danych, czy można skutecznie przeciwdziałać? Odpowiedzią niech będzie prosty raport z dnia dzisiejszego dla mojej domowej sieci.
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.
Czasami zdarza się sytuacja, która zmusza nas do zrównania serwera z ziemią – mam na myśli czyszczenie dysków twardych. Powodów może być wiele, np. zwrot do dostawcy wynajmowanego zdalnego serwera fizycznego itp. Tak czy inaczej lepiej nie oddawać swoich danych. O danych innych użytkowników, ze względu na przepisy RODO, mogę nawet nie wspominać.
Jeśli sprzęt stoi pod ręką to zwykle nie problemu – chociażby ze sformatowaniem dysków. Możemy je nawet wyjąć i zabezpieczyć. Co zrobić jednak kiedy nasze zasoby są zainstalowane w centrum danych a jedyną możliwością jest połączenie zdalne. Nie ma nawet dostępu do konsoli. Wiem, że wielu osobom może wydawać się prawie niemożliwe, ale jednak tak bywa. Nawet w dzisiejszych czasach. Uściślając jedyną metodą dostępu pozostaje terminal SSH.
Po zabezpieczeniu/skopiowaniu danych, o czym musimy zawsze pamiętać, możemy przystąpić do dzieła zniszczenia, chodzi o czyszczenie dysku twardego. Na początek warto wspomnieć, że większość systemów linuksowych w lokalizacji:
/dev/shm
udostępnia dysk RAM. Jest to dobre miejsce na skopiowanie narzędzi, do których nie będziemy mieć dostępu po skasowaniu danych np. ls. Następnie powinniśmy zabezpieczyć dostęp do procesów czyli wykonać następujące komendy:
mkdir /dev/shm/proc mount -t proc proc /dev/shm/proc
Tak przygotowani przystępujemy do ostatniego nieodwracalnego zestawu kroków.
Najpierw odmontowywujemy wszystkie niepotrzebne partycje. Potem, jeżeli używamy macierzy RAID, to powinniśmy odmontować wszystkie dyski poza bieżącym (de facto należy je wyczyścić oddzielnie). Wreszcie zmieniamy katalog na dysk RAM i wpisujemy:
shred -n2 -z -v /dev/sda
W wyniku działania aplikacji shred usuniemy zawartość dysku sda. Komenda zapisuje losowo bity na /dev/sda, w dwóch pełnych przebiegach (-n2), a następnie wykonuje końcowy przebieg zerami, dzięki czemu dysk wygląda na idealnie czysty (-z). Ostatnia opcja (-v) posłuży do zwiększenia poziomu szczegółowości logów wyświetlanych na ekranie podczas wykonywania polecenia.
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:
