Bądź na bieżąco - RSS

Aktualizacja Debian LTS za pomocą Freexian

1 sierpnia, 2023 | Brak Komentarzy | Kategoria: Linux, Porady

Debian, Freexian, aktualizacja, LTS

Debian

Każdy, nawet najlepszy system operacyjny ma swój termin przydatności. Najczęściej po jego przekroczeniu trudno oczekiwać wsparcia w postaci aktualizacji oprogramowania systemowego. Prowadzi to z kolei do całkiem prawdopodobnego narażania się na niebezpieczeństwo w postaci niezałatanych dziur i w konsekwencji ataków na usługi, które pracowicie utrzymujemy. Takie niedbałości w postaci porzuconych systemów można spotkać wbrew pozorom całkiem często.

Jeśli mamy pod opieką pojedyncze maszyny, nieważne czy jako fizyczne serwery czy jako wirtualne instancje, to oczywiście aktualizacja systemu operacyjnego do nowszej wersji jest wyzwaniem ale prawdopodobnie niezbyt wymagającym. Jeśli jednak wspomnianych serwerów jest cała masa albo co gorsza zainstalowaliśmy unikalne ale ważne usługi, których konfiguracja jest naprawdę pracochłonna to aktualizacja może być procesem, który spowoduje, że będziemy musieli się nieco napracować.

Nic dziwnego, że o ile jest dostępna droga przedłużenia wsparcia dla systemu, nawet jako alternatywa dla oficjalnych repozytoriów, to czasami chętnie po nią sięgamy. Tak właśnie można wytłumaczyć popularność projektu Freexian, który ratuje przeterminowane serwery z Linux Debian.

O projekcie Freexian wspomninałem już w innym wpisie. Jeśli ktoś chce zapoznać się ze szczegółami to serdecznie zachęcam. Jednak ponieważ pojawiło się parę istotnych nowości to postanowiłem zaktualizować informację.

Wspomniane nowości dotyczą aktualizacji kluczy instalacyjnych, które jakiś czas temu zostały zmienienione. Na szczęście przepis na instalację nowych jest bardzo prosty i sprowadza się do wydania dwóch poleceń:

wget https://deb.freexian.com/extended-lts/pool/main/f/freexian-archive-keyring/freexian-archive-keyring_2022.06.08_all.deb && dpkg -i freexian-archive-keyring_2022.06.08_all.deb
wget https://deb.freexian.com/extended-lts/archive-key.gpg -O elts-archive-key.gpg && mv elts-archive-key.gpg /etc/apt/trusted.gpg.d/freexian-archive-extended-lts.gpg

Jeżeli wszystko przebiegnie pomyślnie to możemy dodać do pliku /etc/apt/sources.list odpowienie repozytorium w zależności od wersji naszego systemu operacyjnego:

deb http://deb.freexian.com/extended-lts jessie-lts main contrib non-free
deb http://deb.freexian.com/extended-lts stretch-lts main contrib non-free

Pamiętajmy jednak, że nie zwalnia nas to z obowiązku podniesienia wersji systemu… gdy już będziemy gotowi zmierzyć się z tym zadaniem.

MG

Tagi: , , ,

PHP – konfiguracja wersji

10 listopada, 2022 | Brak Komentarzy | Kategoria: Linux, Porady
PHP

Wiele lat temu gdy Internet dopiero powstawał tworzenie stron było dosyć proste a dokumenty, które w ten sposób przygotowywano były zazwyczaj statyczne. Wkrótce potem apetyt twórców szybko wzrósł i powoli zaczęły pojawiać się treści dynamicznie generowane. Upłyneło kolejnych kilka lat i dziś żeby napisać stronę używamy całych gotowych platform nawet jeżeli treści będzie tam niewiele. Jeśli zaś mowa o platformach to wykorzystują one z reguły do pracy wybrany bazowy język programowania. Oczywiście rozwiązań jest tutaj multum, jednak tym razem chciałem skupić się na dosyć popularnym, chociaż nie pozbawionym wielu wad języku PHP.

Załóżmy, że budujemy witrynę www korzystając z serwera on-premise. W dobie olbrzymiej popularności roziązań chmurowych może wydawać się to nieuzasadnione i szalone ale jeśli komuś zależy nad panowaniem nad całością architektury IT to musi zmierzyć się z budową własnych narzędzi. Załóżmy, że korzystamy już z serwera na bazie Debiana, Ubuntu etc., skonfigurowaliśmy silnik bazy danych, serwer HTTP, w tym przypadku Apache, a teraz chcemy zapanować nad wersjami PHP. Rzecz w tym, że ze względu na mnogość gotowych rozwiązań rozszerzających funkcje z poziomu witryny możemy doświadczyć mnogości wymagań odnośnie typu bibliotek PHP zainstalowanych i uaktywnionych w systemie. Poniżej zamieszczam parę wskazówek jak szybko przełączać ich wersje bez skomplikowanej reinstalacji.

Po pierwsze musimy sprawdzić jakie wersje PHP są dostępne w naszym systemie a następnie zdezaktywować starszą i uaktywnić najświeższą dostępną, jeśli chcemy mieć wszystko zaktualizowane:

a2dismod php7.4
a2enmod php8.0
service apache2 restart

To jednak nie wystarczy aby nasza platforma usług WWW zaczęła widzieć zmiany. Teraz musimy rekonfigurować ustawienia systemowe:

update-alternatives --config php
update-alternatives --config phar
update-alternatives --config phar.phar

Za każdym razem konsekwentnie wybieramy pożądaną wersje PHP. Na koniec ponownie uruchamiamy serwer Apache:

service apache2 restart

Opisana powyżej procedura pozwola zmieniać wersję PHP w obydwie strony, zapewnia zatem całkowitą dowolność.

MG

Tagi: , , ,

openmediavault NAS

25 września, 2022 | Brak Komentarzy | Kategoria: Linux, Porady
openmediavault NAS

openmediavault to projekt, którego popularność wzrasta nieustannie od kilku ładnych lat. Jest to gotowy do użytku zestaw aplikacji pozwalający na zbudowanie własnego serwera NAS w systemie opartym o Debian Linux. W dobie dwóch bardzo dobrych komercyjnych rozwiązań, którymi są produkty firm Synology i QNAP wydawać by się mogło, że kolejny gracz nie jest już potrzebny. Jednak openmediavault to rozwiązania wręcz perfekcyjne jeśli dysponujemy starym serwerem i nie chcemy wydawać pieniądzy żeby przygotować sobie maszynę na kopie zapasowe.

Tym razem jednak chciałbym napisać o alternatywnej metodzie instalacji openmediavault. Ze strony www.openmediavault.org możemy pobrać gotowe obrazy ISO tak aby przeprowadzić standardową instalację tak jak w przypadku każdego systemu operacyjnego tzn. z nośnika USB lub płyty DVD ale istnieje również inna metoda.

Wyobraźmy sobie, że mamy już sewer z Debianem i chcielibyśmy wzbogcić go o nakładkę w postaci openmediavault. Tego typu instalacja nie musi być pozbawiona sensu, zwłaszcza że wraz z oprogramowaniem dostaniemy wygodne narzędzie GUI do utrzymywania środowiska z kontenerami typu Docker plus Portainer czy narzędzie do zarządzania wirtualizacją Linux KVM. Jakby tego było mało – dodatkowo jeśli nie myślimy o zaawansowanej pracy z serwerem Debian – to przy odrobinie samozaparcia możemy w całości zarządzać systemem przy pomocy wspomnianego wyżej GUI.

Co zatem należy zrobić? Trzeba z poziomu konsoli systemowej uruchomić skrypt:

wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/install |  bash

Jeśli zaś nie używamy wget możemy to zrobić tak:

curl -sSL https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/install |  bash

Po kilku, kilkunastu minutach powinniśmy mieć zainstalowaną nakładkę openmediavault.

Jeśli nadal coś nie będzie działać lub pojawią się dodatkowe problemy to polecam sprawdzić u źródeł na stronie GitHub OpenMediaVault Plugin Developers w sekcji installScript.

MG

Tagi: , , ,

Linux Debian ELTS

26 kwietnia, 2022 | Brak Komentarzy | Kategoria: Linux, Porady
Linux Debian ELTS

Linux Debian to niewątpliwie jedna z bazowych dystrybucji, przynajmniej do tej pory tak zawsze pisano na rozmaitych wiki – pozostałe dwie to rodziny RedHat i Slackware. Osobiście bardzo ją lubię, w głównej mierze za prostotę i dosyć logicznie poukładany system operacyjny. Od wielu lat twierdzę, że dużo łatwiej nauczyć się dobrze posługiwać Debianem niż MS Windows (sic!). W wersji instalacji sieciowej można za pomocą kilku komend dostać naprawdę dobrze skrojony system i co ważne bez zbędnych dodatków. Dla porównania w Ubuntu, które wykorzystuje Debiana już nie jest tak wydajnie.

Czy istnieją jednak jakieś niedogodności Debiana, a być może wady? Świat byłby zbyt piękny gdyby istniał ideał. Jak się zapewne domyślacie musi być coś co denerwuje nawet tak oddanych użytkowników jak autor tego wpisu. I rzeczywiście można wymienić zapewne kilka ułomności, z których mi najbardziej przeszkadza cykl wydawniczy kolejnych wersji. A w zasadzie jego długość (bądź krótkość żeby być bardziej precyzyjnym).

Debian przede wszystkim stara się być bardzo stabilny. Zatem wszelkie nowości pojawiają się z dużym opóźnieniem w stosunku do innych dystrybucji. Najpierw każdy z pakietów jest testowany a dopiero później – jeżeli wszystko będzie w porządku według deweloperów – włączany do głównego repozytorium. To zajmuje sporo czasu. Co dwa lata pojawia się nowe główne wydanie a wsparcie przewidziane jest na trzy. Jeśli wybierzemy wersję hmm… długowieczną tzw. long life LTS to otrzymamy aktualizacje do pięciu lat od momentu debiutu. Można powiedzieć, że ten sposób dystrybucji jest optymalny ale dobrze wiadomo, że trzy lata potrafią minąć bardzo szybko. Wsparcie kończy się nagle. Nowe pakiety nie pojawiają się w repozytorium a my zostajemy z przeterminowanym serwerem. Prawdę mówiąc jeżeli utrzymujemy jeden taki serwer to wymiana systemu może być pracochłonna ale stosunkowo bezbolesna. Aktualizacji typu distroupgrade dystrybucji nie polecam. Raz tak zrobiłem i bardzo żałowałem. Inaczej sprawa wygląda jeśli hostów z przestarzałym Debianem mamy kilka lub kilkanaście.

Wychodząc naprzeciw potrzebom sysopsów w dużych sieciach serwerów niektórzy dostawcy oprogramowania oferują swoje repozytoria, które pozwalają przedłużyć życie naszych węzłów poza wsparcie LTS. Naprawdę warto poszukać w sieci. Przykładem z mojej praktyki jest Debian Jessie, którego wsparcie skończyło się 30 czerwca 2020 roku. Okazało się jednak, że jest dosyć popularna dystrybucja (a admini dosyć leniwi) i społeczność zaczęła pracować nad alternatywnymi repozytoriami.

Mamy pierwszy kwartał 2022 roku, dwa lata po terminie a nadal wychodzą aktualizacje. Jednak należy ich szukać na stronie (czyli jak wspominałem poza oficjalnym źródłem):

https://deb.freexian.com/extended-lts/

Projekt nazywa się Debian Extended LTS (ELTS) i jest odpowiedzią na zapotrzebowanie rynku. Zupełnie inną sprawą jest pytanie czy jest to właściwy sposób rozwiązania problemu? Z różnych względów zapewne nie. Ale potrzeba i lenistwo są matką wynalazków. Zatem jeśli nie widzisz innego wyjścia to możesz użyć ELTS ale pamiętaj, że również to repozytorium przestanie być kiedyś używane.

MG

Tagi: , ,

VMware, converter, 97% error

28 listopada, 2021 | Brak Komentarzy | Kategoria: Linux, Porady
VMware

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

Czyszczenie dysków twardych na zdalnym serwerze

24 listopada, 2019 | Brak Komentarzy | Kategoria: Linux, Porady
Odkurzacz, czyszczenie

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.

MG

Tagi: , ,

OpenVAS – testy penetracyjne

29 września, 2019 | Brak Komentarzy | Kategoria: Linux, Porady
OpenVAS

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

Wysoki uptime – jak nie restartować serwera

26 maja, 2019 | Brak Komentarzy | Kategoria: Linux, Porady
Uptime - system is up to date

Być może obecnie nie jest to specjalnie popularne, ale dawno, dawno temu jednym z parametrów świadczących o stabilności serwera i zarazem o zdolnościach jego administratora był tzw. uptime. Żyjemy w czasach gdy aktualizacje systemowe bardzo często wymuszają restart całego systemu. Niestety nie dotyczy to tylko serwerów Windows, co kiedyś było głównie ich domeną, ale również serwerów opartych o jądro Linuxa. Często tego typu działania kończą się wyzerowaniem licznika serwera i wspomniany uptime rozpoczyna zliczanie od początku.

Stare nawyki jednak pozostają na trwałe w pamięci i o ile dla Windowsów przestałem się wogóle przejmować ponownym uruchamianiem systemu, o tyle w przypadku ulubionego Debiana za każdym razem ręka drżała jeśli po aktualizacji pojawiał się komunikat o nowych bibliotekach systemowych czy o zgrozo nowej wersji jądra.

Tak było przez kilkanaście lat. Po prostu uznałem, że tak musi być i za każdym razem wolałem dla świętego spokoju zrestartować system. I nagle w zeszłym tygodniu, przy okazji serii aktualizacji serwerów, pojawiła się myśl, że być może są jakieś narzędzia, które podpowiedzą czy na pewno muszę tracić licznik uptime. Okazało się, że jak najbardziej można sobie pomóc. W końcu to Linux.

Pierwsza metoda jest niezwykle prosta. Po każdej aktualizacji należy sprawdzić czy w określonym miejscu pojawił się plik systemowy o nazwie reboot-required. Wygląda to następująco:

$ ls /var/run/reboot-required

Jeśli otrzymamy wynik pozytywny to oczywiście musimy ponownie uruchomić serwer.

Druga metoda polega na zainstalowaniu narzędzia o nazwie needrestart.

$ apt-get install needrestart

Różnica polega na tym, że w wyniku jego działania np. po ręcznym wywołaniu komendy, otrzymamy pełen raport dotyczący nie tylko zrestartowania systemu ale również usług, które należy uruchomić ze względu na nowe wersje bibliotek systemowych. Dodatkowym bonusem jest fakt, że po każdorazowej aktualizacji needrestart zostanie uruchomiony samoistnie i podpowie co należy zrobić dalej. Czyli prawie jak na Windowsach. 😉

MG

Tagi: , , ,

Hasło root – jak je odzyskać?

28 kwietnia, 2019 | Brak Komentarzy | Kategoria: Linux, Porady
Hasło root

Czasami zdarza się nam zapomnieć hasła. Nie jest to żaden duży problem jeżeli np. chodzi o konto w usłudze internetowej gdzie zazwyczaj dostępna jest opcja przypomnienia za pomocą adresu e-mail. Jednak inaczej sprawa wygląda gdy zapomnieliśmy hasła administracyjnego, a jeszcze gorzej hasła administratora dla konta root w systemie opartym o jądro Linuxa. No właśnie. Pytanie brzmi jak odzyskać hasło root?

Istnieje sporo metod pozwalających odzyskać takie hasło, a dzisiaj chciałem skupić się na systemie Debian w wersji 9. Pisze o tym ponieważ całkiem niedawno padłem ofiarą własnego gapiostwa i zakładając kilka maszyn wirtualnych pod rząd zdecydowałem, że nie będę zapisywał haseł. Oczywiście przesłałem je użytkownikom ale… niestety w kilku przypadkach z błędem. Mając alternatywę przygotowywania systemów od początku i wizję kolejnych spędzonych bezproduktywnie godzin zdecydowałem się poszperać w sieci, żeby szybko odzyskać, a w zasadzie zmienić hasła.

Po lekturze kliku artykułów w sieci, ze zdziwieniniem odkryłem, że nie będę nawet musiał uruchamiać systemów z płyty instalacyjnej, ale po kolei.

Po pierwsze powinniśmy uruchomić ponownie system i w chwili pojawnienia się menu startowego z wyborem opcji uruchomieniowych zatrzymać rozruch dowolnym klawiszem (nie może to być Enter 🙂 ). Wybierając pierwszą opcje startową należy wcisnąć e aby przejść do edycji linii wywołania jądra systemowego z opcjami.

Po drugie przechodzimy do linii zaczynającej się od słowa linux, pracowicie przesuwamy się na jej koniec i dopisujemy frazę

init=/bin/bash

Po trzecie wciskamy ctrl+x lub F10 aby uruchomić system. W ten sposób wystartujemy w trybie pojedynczego użytkownika z systemem plików zamontowanym w trybie tylko-do-odczytu. Ponieważ chcemy zmienić hasło root zdecydowanie trzeba to zmienić. Wpisujemy zatem polecenie:

mount -o remount /

Po czwarte używamy dobrze znanej komendy (mam taką nadzieję)

passwd

aby zmienić hasło root. Na koniec uruchamiamy ponownie system, jednak tym razem znamy już hasło.

MG

Tagi: , , ,

AIDE – wykrywanie zmian w systemie plików

31 marca, 2019 | Brak Komentarzy | Kategoria: Linux, Porady
AIDE

Wiele lat temu miałem wątpliwą przyjemność doświadczyć ataku na jeden z serwerów Apache, którymi się opiekowałem. Zmiany, które skutkowały przejęciem serwera i rozsyłaniem za jego pomocą spamu pojawiały się każdego dnia a ja usiłowałem bezskutecznie walczyć z nimi. Wtedy po raz pierwszy pojawiła się myśl, żeby po prostu podejrzeć co atakujący zmienia w systemie plików, tak aby można było rozszyfrować na czym polega sama metoda włamania. Ostatecznie, szczerze mówiąc, zostałem pokonany i wszystko skończyło się instalacją od początku serwisu, ale poznałem narzędzie detekcji włamiań działające na poziomie systemu plików jakim jest AIDEAdvanced Intrusion Detection Environment.

Wiele lat później ta wiedza i to narzędzie bardzo mi pomogły w powstrzymaniu jednego z ataków na inny serwer w celu uruchomienia koparki kryptowalut. Myślę, że warto jest korzystać z AIDE, w szczególności na serwerach wystawionych na publiczny dostęp. Zatem do dzieła!

Zaczynamy od instalacji pakietu AIDE, po uprzednim zaktualizowaniu systemu:

apt-get update -y && apt-get upgrade -y
apt-get install aide

Następnie wykonujemy kopie zapasową pliku konfiguracyjnego AIDE:

cp /etc/aide/aide.conf /ect/aide/aide.oryg;

Teraz możemy przejść do edycji pliku konfiguracyjnego, aby poprawić/dostosować niektóre jego ustawienia. Możemy skorzystać na przykład z edytora nano.

nano /etc/aide.conf 

W plików tym, na początek, zmieniamy absolutne minimum opcji. Z czasem, po zapoznaniu się z pełnymi możliwościami AIDE możemy pobawić się jego ustawieniami. Trzeba jednak pamiętać, że możemy w ten sposób doprowadzić do przeciążania zasobów serwera ze względu na np. długotrwałą i zbyt szczegółową analizę. Dlatego zaczynamy od absolutnego minimum dla obliczenia sumy kontrolnej:

Checksums = sha512+tiger

I tyle na pierwszy raz wystarczy 🙂 .

Po zapisaniu ustawień możemy zaincjalizować AIDE, co może trochę potrwać w zależności od mocy serwera:

aideinit

Następnie wykonujemy małą sztuczkę upewniając się, że AIDE zadziała z poziomy crona systemowego, czyli:

mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
/etc/cron.daily/aide
cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

I to wszystko. Teraz przy odrobinie szczęścia, tzn. jeżeli wszystko poszło zgodnie z oczekiwaniami, będziemy codziennie otrzymywać raport na skrzynkę root z listą zmian w systemie plików w ciągu ostatnich 24 godzin.

MG

Tagi: , , ,