Wielu początkujących administratorów przeczesuje zasoby sieci w poszukiwaniu stron z opisami poprawnej konfiguracji serwerów usług bądź w poszukiwaniu znajomych taką wiedzę posiadających. Nauczony doświadczeniami płynącymi ze współpracy z jednym panem, postanowiłem opisać dokładnie proces konfiguracji idealnego środowiska produkcyjnego.
Na początek, jako że pierwszy odcinek kursu, nie bądźmy zbyt ambitni i zacznijmy od zwykłego serwera proxy.
Potrzebny będzie nam nosiciel (host) i dystrybucja linuksa. Linux jest najlepszym wyborem, bo jest bardzo modny i fajnie zasłynąć w światku znajomych swoimi pierwszymi doświadczeniami w tym kierunku. Oczywiście w domu lepiej mieć Windowsa, więc serwer produkcyjny nadaje się na poligon idealnie. Do naszych testów wybrałem skwapliwie najstabilniejsze środowisko produkcyjne. Musicie więc znaleźć gdzieś płytki zawierające Debian Unstable/Testing z archiwum pakietów z okolic sylwestra 2002. A może to był styczeń? Tuż po nowym roku wszystko się człowiekowi miesza.
Uzbrojeni w aparaturę i software przystępujemy do instalacji. Niektórzy znani mistrzowie techniki zen doradzają w tym momencie, aby na czuja zainstalować wszystko. Od przybytku głowa nie boli. Ja pozwolę sobie ograniczyć się do pakietów squida, mini-httpd i iptables. Reszta pociągnie się po zależnościach. Byle nie za dużo, bo nasza precyzyjnie spartycjonowana maszyna ma na rootsystem przewidziane całe 10 giga przestrzeni (jako że posiadałem kiedyś Amigę 500, zapewniam że 10 giga to niewyobrażalnie dużo). Nie dzielimy dysku na partycje, bo właściwie to nie jest już trendy. I tak nikt nie będzie nam umiał wytłumaczyć jak przełączyć się na inny dysk pod midnightem (Alt + F1 nie działa). Nie zapominajmy też o pakiecie lm_sensors. Jako, że sensory są bardzo czułe, pakiet ten ma kluczową wartość na naszym serwerze proxy.
Gdy wszystko stoi, przystępujemy do konfiguracji squida. Zależy nam na przepustowości sieci, więc dla pewności cache'ujemy wszystko. Tak, koniecznie zaznaczamy flagę "ignoruj nagłówek Expires", w praktyce nikt przecież go nie czyta. Katalog ze stronami tymczasowymi ustawiamy w katalogu /var/spool/squid na głównej partycji (mi też \var\spool\squid nie chciało działać). 10 giga to zapas na lata, przecież nikt nie widział takiej dużej strony. Proxy jest już gotowe, ale ale, zanim je włączymy, ustawiamy nasze błyszczące i nowe mini-httpd na wyświetlanie generowanych przez squida statystyk. W końcu nie poto trzymamy je w nieskończoność, żeby leżały odłogiem na dysku.
Po konfiguracji tej części przyjdzie nam najtrudniejsze, zabezpieczanie serwera. Jak mówi stare japońskie przysłowie, dobry serwer jest jak dobry ninja. Można go zabić jednym ciosem, ale pozostaje niewykrywalny. Kierując się tą maksymą ustawiamy domyślną politykę wszystkich potoków ruchu na accept
, ale już w pierwszej regule odrzucamy prośby o ping kierowane na adres rozgłoszeniowy naszej podsieci (broadcast). Haha! To dopiero przebiegłość, nikt go nie znajdzie! Do tego dopisujemy kilka dodatkowych reguł z polityką accept
dla podstawowych protokołów (czyli dla zwykłego pinga i traceroute - tego fajnego narzędzia do śledzenia kumpli z gadu-gadu). Dla zwiększonego bezpieczeństwa resztę pakietów przekierowujemy żywcel do sysloga z poziomem raportowania 4. Teraz nic nam nie umknie, żadna próba włamania nie pozostanie niezauważona. Tym bardziej, że w syslogu usuwamy wpis przesyłający logi iptables do pliku, przez co są bardziej widoczne niż kiedykolwiek, na żadnej konsoli się przed nimi nie ukryjesz! Toż ci dopiero majstersztyk!
Krokiem drugim powinno być zwiększenie niezawodności naszej sieci przez instalację bardzo popularnego narzędzia, jakim jest Nagios. Nie wiemy do końca, co on robi, ale fajnie wygląda na screenach i ma tam dużo ładnych ikon. Dziwne, bo po instalacji nie widać ikon, tylko jakieś śmieci na konsoli, że coś nieustawione niby. Bzdura. Aha, jednak. Zmieniamy adresy z przykładowej konfiguracji na dane osobe sąsiada, który parkuje nam pod domem (używa mało na topie Outlook Expressa, to niech się męczy ze spamem). Działa. Dalej nic nie rysuje na ekranie, ale screeny pewnie podrobione w Photoshopie, mniejsza o to. Podobno trzeba mieć jakiś serwer poczty tam do tego Nagiosa, więc instalujemy szybko NullMailer. Do tego jakiś szybki soft do rozsyłkim np. exim3 w trybie bezdemonowym (bo nie chcemy duchów na serwerze było nie było publicznym, mogą wystraszyć potencjalnych użytkowników). Demona nie ma, więc i konfigurować pewnie nie trzeba. Odpalamy i zapominamy.
Powiadomienia nie przychodzą, więc wszystko jest w porządku. Spokojnie pracujemy dalej. Zależy nam na niezawodności systemu, więc co kilka tygodni uruchamiamy apt-get upgrade w poszukiwaniu krytycznych poprawek. Zależy nam również na przepustowości łącza, więc unikamy stosowania apt-get update, które generuje tylko zbędny ruch, a przecież wszystko mamy na płytkach. Ignorujemy też maile od klientów, ze względów bezpieczeństwa. W końcu pod wiadomością podpisać może się każdy, nie możemy ufać każdemu. Kontakt z klientami nawiązujemy dopiero w momencie, kiedy szef danej firmy zadzwoni do nas osobiście, to pozwala dokładnie potwierdzić tożsamość rozmówcy i jego dobre intencje.
Gdy po kilku miesiącach pracy klienci zaczynają spamować naszą prywatną skrzynkę do tego stopnia, że spamassassin pochłania sporą część czasu procesora, bierzemy ich metodą na przetrzymanie
. Na dwa dni znikamy bez słowa, śmiejąc się w duchu z ich dziecięcej bezradności.
Po powrocie do pracy ze zdumieniem dostrzegamy, że szef w międzyczasie zatrudnił nowego administratora, który wraz z programistą próbuje dojść, jakim cudem statystyki dysków na systemie squidowym pokazują 100% wykorzystania miejsca. Wkrótce dochodzą do tego, że Nagios nie miał prawa wykonywania binarki /bin/ping, wskutek czego wygenerował słuszną liczbę 110 tysięcy powiadomień o martwych hostach. Niestety, z powodu błędnej konfiguracji exima, połowa z tych maili nie dotarła do jednego z adresatów (powiadomienia dostawał szef firmy, ale nie administrator). Może to i dobrze, bo każdy wysłany pomyślnie mail generował kilkadziesiąt stron zrzutu stosu TCP/IP w logu podstawowym, który wkrótce (mimo codziennej rotacji) przepełnił 10-gigowy dysk (nie do zapełnienia
). Nie wspomnę, jaki jest komfort pracy na konsoli, przez którą przewija się bez przerwy ramka za ramką cały ruch TCP i UDP wychodzący z maszyny.
Na dziś to tyle, do zobaczenia w kolejnym odcinku, gdzie nauczymy się równie pożytecznych i przydatnych umiejętności.