Do czego może służyć serwer domowy?

Witam.

Kilka miesięcy temu zakupiłem stary terminal Neoware CA10, od tego czasu postawiłem na nim kilka ciekawych rzeczy które opiszę Wam w tym wpisie.

Na wstępie jeszcze podam Wam specyfikację na której całość działa:

Procesor: VIA Nehemiah @ 1.0 GHZ (2000 bogomips)
Pamięć ram: 128 mb DDRI 266 mhz (do 1024 mb maksymalnie, dwa sloty)
Zintegrowana pamięć flash: 32 mb
Gniazda USB: 4 x USB 2.0 (możliwość bootowania z USB)
Karta muzyczna: Zintegrowana
Karta graficzna: VIA Technologies, Inc. VT8623 [Apollo CLE266] integrated CastleRock graphics (rev 03)
Karta sieciowa: 10/100 mbit/s VIA  VT6102 [Rhine-II] (rev 74)
Pobór prądu: Do. 20Watt
System operacyjny: Debian GNU/Linux 7 "Wheezy"
Dysk twardy: Z interfejsem ATA na USB 20 GB

1. Status wszystkich komputerów w sieci

Każdy komputer w Mojej sieci wysyła do serwera dane tego typu:

- uptime
- średnie użycie procesora
- użycie pamięci RAM
- listę podłączonego sprzętu (na płycie, pod USB, PCI, ISA, ATA, SATA itp.)
- użycie dysku twardego
- informacje o napięciach jeżeli dostępne
- informacje o wentylatorach jeśli dostępne

Dzięki czemu mam możliwość monitorowania czy przykładowo jakiś komputer zbyt bardzo się nie grzeje - jeśli widzę, że średnie użycie procesora jest za duże to loguję się przez ssh do tego komputera i sprawdzam co jest grane i jak to można poprawić.

2. Automatyczne analizowanie wysyłanych logów

Każdy komputer ma w crontabie (zaplanowaych zadaniach) ustawione automatyczne skanowanie szukające rootkitów (chkrootkit), log jest wysyłany na serwer - a tam serwer go analizuje i wysyła maila bądź wiadomość na Jabbera o występującym problemie.

#!/bin/bash
chkrootkit > /tmp/rk
su webnull -c "screen -DmS /usr/moj-skrypt/send-log http://moj-masterserver/odbierz-log.php?id=`cat /identyfikator-komputera` rk /tmp/rk"

Wysyłam także wyjście z polecenia "last" i szukam tam adresów IP zewnętrznych które logowały się do SSH aby móc wykryć potencjalnego intruza któremu udało się dostać do systemu, a także zbieram informacje o nieoczekiwanym wyłączeniu systemu np. z powodu braku pamięci RAM (często twardy reset jeżeli swapu nie ma, w 50% przypadków da się wyratować system zabijając proces zjadający pamięć - można to zrobić z SSH chyba najlepiej nie powodując jeszcze większego użycia pamięci).

Mam możliwość także przeglądania logów przez przeglądarkę wraz z archiwum, całość dostępna jest tylko dla Mnie, nikt inny nie posiada uprawnień do przeglądania logów.

3. Statystyka, czyli bawimy się w wielkiego brata

Oprócz analizowania logów i wysyłania statusu można także wysyłać różne skany sieciowe przykładowo skan okolicznych sieci bezprzewodowych który uwzględnia adres MAC(główny identyfikator), nazwę sieci, typ zabezpieczenia, kanał itp.

Po zintegrowaniu takiego skanera z GPS można utworzyć mapę punktów dostępowych WiFI.

Ja jednak aktualnie nie posiadam GPS, planuję zakupić jakiś na wejście USB bądź Compact Flash.

4. Bezpieczeństwo, czyli jak to działa?

Komunikacja pomiędzy komputerem a serwerem jest szyfrowana algorytmem AES 256 bitowym.

Serwer i klient posiadają wspólne klucze szyfrujące (każdy klient ma osobny klucz).

Klucze mają często więcej niż 1024 znaki.

Przed zdublowaniem zesniffowanej wiadomości (wysyłamy wiadomość np. o statusie komputera/systemu do serwera a ktoś ją przechwytuje - nie może rozszyfrować ale może ponownie wysłać do serwera aby nadpisać wcześniejsze dane) broni umieszczony wewnątrz timestamp oraz sprawdzanie sumy kontrolnej wiadomości przez serwer.

5. Aktualizacja, czyli jak obsługiwać wszystko z automatu

Postawiłem serwer rsync który służy do synchronizacji danych pomiędzy klientem a serwerem.

Klient codziennie łączy się z serwerem rsync i sprawdza czy któryś z plików lokalnych potrzebuje aktualizacji, jeżeli tak to pobiera nową wersję z serwera.

#!/bin/bash
if ! ping -c 1 -w 2 oneill &>/dev/null ;
then
        echo "Master is offline."
else
        rsync rsync://oneill/aplikacja -avs /usr/share/katalog-aplikacji
fi

receiving incremental file list

sent 25 bytes  received 181 bytes  137.33 bytes/sec
total size is 69332  speedup is 336.56

Podsumowanie

Mały, serwer domowy z niskim poborem prądu jest bardzo przydatny, odwala za Nas całą robotę administracyjną nad większością komputerów w domu.

Wyjątkiem są komputery z systemem Microsoft Windows które stawiają ogromne problemy podczas wdrażania opisanych tutaj rzeczy.

W systemach Windows(R) brakuje odpowiednich narzędzi pod kosnolę takich jak rsync, brakuje bibliotek w Pythonie które zapewniłyby łatwy dostęp do WIFI, program w którym planuje się zadania potrafi nie uruchomić zadania co się zdarza bardzo często na jednym z komputerów z Windows 7 Home Premium.

Ogólnie to system Windows jest bardzo sztywnym systemem nie przystosowanym do tego typu zastosowań, jego użycie zostało przewidziane przez producenta - jeśli jednak chcemy wyjechać poza ten obszar zastosowania to zaczynają się schody.

W systemach Uniksowych udało Mi się wdrożyć coś takiego najmniejszym nakładem pracy pisząc to w Bashu, Pythonie i PHP, pod Windows musiałbym przepisać większość w jakimś języku kompilowanym aby to sprawnie działało.

Proszę nie mówić, że systemy Uniksowe muszą nadganiać Windows, bo Moim zdaniem jest na odwrót.

Udało Mi się wdrożyć częściowo wysyłanie informacji o systemie na komputerach z Windows, lecz nie jest to prefekcyjne - w Windows panuje kodowanie windows-1250 dlatego kiepsko to wygląda.

Nie udało Mi się wdrożyć skanowania sieci WIFI, automatycznego wysyłania logów.

Dlaczego nie udało Mi się wdrożyć wysyłania logów?

- Odpowiedź jest prosta; Windows nie posiada odpowiednich narzędzi które by potrafiły generować logi tekstowe bez użycia GUI (automatycznie w tle)