Wrzesień, 2000
Częścią mojej pracy jest rozbudowa systemu BigBrother o profesjonalne mechanizmy przechowywania i analizowania zbieranych danych. Dalszym krokiem jest instalacja rozbudowanego systemu na serwerach Wydziału MIM UW i przeprowadzenie testów. Testy te z jednej strony pokazują jak działa i co umożliwia system BigBrother, a z drugiej strony umożliwiają analizę pracy serwerów wydziałowych. Dzięki temu możliwa będzie poprawa funkcjonowania sieci i systemów wydziałowych, a także znacznie szybsze reagowanie administratorów na awarie lub też stany bliskie awarii.
Drugim odrębnym zagadnieniem, którym zajmuję się w niniejszej pracy, jest bezpieczeństwo przesyłanych danych o monitorowanym systemie. Pokazuję, jakie są niebezpieczeństwa wynikające z możliwości przechwycenia danych przez osoby niepowołane i mechanizmy umożliwiające poprawę bezpieczeństwa przesyłanych informacji.
Niniejszy tekst jest skróconą wersją pracy. Zawiera wybrane rozdziały:
2 Opis ogólny zagadnienia
4 Opis przedmiotu pracy
8 Podsumowanie
9 Literatura
Aby program taki był użyteczny, musi zbierać i przetwarzać dane dotyczące nadzorowanych systemów. Dlatego głównym elementem takich programów jest system monitorujący.
W dalszej części niniejszego rozdziału opisuję architekturę typowych systemów monitorujących, jak również możliwości takich systemów i korzyści płynące z ich używania.
Rysunek 2.1 przedstawia schemat powiązań pomiędzy elementami systemu monitorującego a systemem monitorowanym.
Przedstawiony model bardzo często jest rozbudowywany o inne podsystemy. Czasem jest też upraszczany. W pewnych sytuacjach funkcje serwera zbierającego i udostępniającego dane może pełnić kilka serwerów, np. serwer bazy danych i serwer WWW działające na osobnych komputerach. Inną modyfikacją może być jednoczesne wykorzystanie któregoś z monitorowanych systemów do pełnienia niektórych lub wszystkich funkcji serwera zbierającego dane, lub też odwrotnie serwer zbierający dane może być jednocześnie monitorowany. Czasem zdarza się też, że program konsoli działa na tym samym komputerze co system zbierający dane.
Rysunek 2.1. System monitorowany i węzły systemu monitorującego.
Inną bardzo ciekawą i często realizowaną funkcją w takim systemie jest możliwość przesłania ostrzeżenia na wybrany adres poczty elektronicznej, pager lub telefon. Daje to możliwość szybkiego ostrzeżenia administratora monitorowanego systemu i, co za tym idzie, szybkiego podjęcia kroków zapobiegawczych.
Rysunek 2.2 przedstawia architekturę typowego systemu monitorującego.
Rysunek 2.2. Architektura typowego systemu monitorującego.
Dobre systemy zapewniają możliwość bardzo dokładnego monitorowania systemu operacyjnego oraz działających na nim aplikacji i serwisów.
Dzięki monitorowaniu systemu administrator może znacznie wcześniej przewidzieć konieczność wymiany sprzętu na lepszy, rekonfiguracji lub wymiany oprogramowania. Nieprawidłowe działanie elementów monitorowanego systemu może być dla administratora ostrzeżeniem o włamaniu do systemu.
Kiedy już wszystkie dane o zdarzeniach znajdą się w bazie danych kolejnym krokiem jest dodanie funkcji umożliwiających tworzenie i przeglądanie raportów z wybranego okresu czasu (na podstawie danych zebranych w bazie). Funkcje te oczywiście umożliwiają zdefiniowanie dowolnego z raportów standardowo generowanych przez system BigBrother (są nadzbiorem tych raportów). Dodatkowo umożliwiają administrację danymi w bazie (np. wykasowanie danych dla komputerów, które przestaliśmy monitorować, wykasowanie starych danych).
Innym całkowicie osobnym problemem jest bezpieczeństwo przesyłanych danych w obrębie systemu. Przechwycenie takich danych przez potencjalnego włamywacza może ułatwić mu zadania. Dlatego proponuję zabezpieczenie komunikacji pomiędzy demonem głównym i agentami z monitorowanych systemów za pomocą mechanizmów SSL i certyfikatów.
Kolejna rzecz dotycząca bezpieczeństwa, to możliwość przeglądania raportów udostępnianych na serwerze WWW. W standardowej instalacji każdy ma niczym nieograniczony dostęp do tych stron, dlatego proponuję zabezpieczenie ich za pomocą mechanizmów doinstalowywanych do serwera WWW.
Dołożenie mechanizmów bezpieczeństwa pozwoli administratorowi na utrzymanie w tajemnicy danych o monitorowanym systemie. Dzięki temu potencjalny włamywacz nie będzie mógł wykorzystać ich przy próbach włamania lub destabilizacji systemu. Oczywiste wydaje się, że nikt prócz administratora nie powinien wiedzieć np. o błędach pojawiających się w dziennikach systemowych.
Kolejnym bardzo ważnym elementem jest opracowanie efektywnej metody zapisu danych do bazy. Nadchodzące komunikaty są zapisywane w taki sposób, aby zajmowały jak najmniej miejsca w bazie danych. Jeśli kolejne komunikaty niczym się nie różnią, to są zapisywane w bazie danych w postaci jednego rekordu, co drastycznie redukuje rozmiar jej.
Zostały również stworzone programy-skrypty PHP umożliwiające przeglądanie zgromadzonych danych w formie raportów i zarządzanie zgromadzonymi danymi. Dostarczone mechanizmy umożliwiają przygotowywanie raportów przy zastosowaniu filtrów wyszukiwania. Można na przykład zrobić raport dotyczący tylko wybranych komputerów lub też tylko wybranego zestawu usług na tych komputerach. Można też wyszukiwać w bazie zdarzenia z zadanego okresu czasu. Innym możliwym raportem jest wykres przedstawiający stan zmian danych usług w czasie.
Tak rozbudowany system zainstalowano na serwerach Wydziału MIM UW. System ten posłużył (i w dalszym ciągu będzie służył) do monitorowania kilku serwerów. Dzięki temu udało się w krótkim czasie wykryć kilka elementów, które mogłyby w najbliższym czasie doprowadzić do awarii lub pogorszenia funkcjonowania serwerów. Najczęściej spotykanymi problemami było przepełnianie się niektórych partycji na dyskach twardych. Innym problemem było okresowe zwiększanie obciążenia procesora wynikające z dużej liczby jednocześnie pracujących użytkowników.
W pracy poruszono także kwestie bezpieczeństwa danych przesyłanych pomiędzy agentem a procesem zbierającym dane. Zaproponowałem rozwiązanie umożliwiające zwiększenie bezpieczeństwa przesyłanych danych (brak możliwości ich podsłuchiwania i podrabiania).
Inną istotną funkcją, o którą warto rozbudować system BigBrother, byłoby rozbudowanie funkcjonalności agentów BigBrother. Agent taki mógłby podejmować samodzielnie zadania naprawcze za pomocą skryptów (restart serwisów, czyszczenie niepotrzebnych plików na dysku itd.). Akcje podejmowane przez agenta, jak też i warunki, w których byłyby uruchamiane, musiałyby być definiowane przez administratora.
Kolejnym elementem może być napisanie mechanizmów umożliwiających zaawansowaną analizę zbieranych danych. Mechanizm taki mógłby na podstawie kilku zdarzeń nadchodzących kolejno z tego samego systemu lub też jednocześnie z kilku różnych systemów wyciągać wnioski i podpowiadać administratorowi, jakie akcje powinny być wykonane. Oczywiście proste akcje naprawcze system mógłby podejmować samodzielnie.
Dla wszystkich wymienionych wyżej elementów należałoby przewidzieć taką rozbudowę skryptów PHP, aby konfigurację i sterowanie systemem można było przeprowadzić za pomocą przeglądarki internetowej.
[1] Apache. http://www.apache.org/ informacje na temat oprogramowania Apache, źródła i dodatki do Apache.
[2] BigBrother. http://www.bb4.com/ informacje na temat oprogramowania BigBrother, źródła i dodatki do BigBrother.
[3] BMC Patrol. http://www.bmc.com/ informacje na temat oprogramowania BMC Patrol.
[4] Douglas E. Comer. Sieci komputerowe TCP/IP. Tom I: Zasady, protokoły i architektura. WNT, Warszawa 1997.
[5] HP OpenView. http://www.openview.hp.com/ informacje na temat oprogramowania HP OpenView.
[6] IBM Tivoli. http://www.tivoli.com/ informacje na temat oprogramowania IBM Tivoli.
[7] MySQL. http://www.mysql.com/ informacje na temat oprogramowania MySQL, źródła i dodatki do MySQL.
[8] PHP. http://www.php.net/ informacje na temat PHP, źródła PHP.
[9] Secure Sockets Agent (SSA). http://www.privador.com/products/extranet/index.phtml informacje na temat oprogramowania SSA.
[10] Secure Sockets Layer (SSL V3.0) protocol. Specyfikacja protokołu: http://home.netscape.com/eng/ssl3/.
[11] Simple Network Management Protocol (SNMP). Specyfikacja protokołu: RFC 1157.
[12] W. Richard Stevens. Biblia TCP/IP. Tom 1: Protokoły. Read Me, Warszawa, 1998.
[13] Unicenter TNG. http://www.cai.com/ informacje na temat oprogramowania Unicenter TNG (firmy CA).
[14] Artur Wyrzykowski. Bezpłatne serwery baz danych. Szybkie lecz niedoskonałe, PC Kurier nr 3/2000, strony 52-56. Lupus, Warszawa, 7 lutego 2000.