Prace z informatyki

Prace dyplomowe z informatyki

Załadowanie danych do bazy POSTGRESQL

5/5 - (1 vote)

Pliki w formacie tekstowym wczytywane są po ich otrzymaniu z serwera wewnętrznego firmy. W tym momencie wykonywana jest konwersja kodowania na stronę kodową iso88592 (obowiązujący standard kodowania polskich znaków na stronach www tzw. iso-latin2). Proces ten wywoływany jest również jako cykliczne zadanie w crontab’ie następującym wpisem w plik konfiguracyjny:

# zasilenie dla emarket codziennie o 20:30

30 20 * * 1,2,3,4,5,6,7 /home/bazy/emarket/zaladunek 2>&1 | /var/qmai1/bin/qmai1-inject

Skrypt „załadunek” zbudowany jest podobnie jak skrypt konwersji danych na maszynie wewnętrznej i wykonywane działania wyświetla na standardowe wyjście (stdout) co jest poprzez sposób wywołania w corntab wysyłane jako raport do operatora. Jedyną różnicą w wywołaniu skryptu jest to, iż działa on na tej samej maszynie na której zainstalowany został system pocztowy Qmail i dlatego można było wykorzystać jeden z pocztowych programów usługowych do dostarczenia poczty bezpośrednio do adresata. Działania takie maja na celu informowanie obsługi lub administratorów o wszelkich występujących problemach a także o powodzeniu każdego z etapów działania sklepu internetowego. Poniższy skrypt prezentuje działania wykonywane w czasie importowania danych do bazy PostgreSQL:

Skrypt służy do załadowania danych do bazy danych eMarket. Jest to przykład skryptu automatyzującego proces wczytywania i konwersji danych do odpowiednich formatów przed załadowaniem ich do systemu. Poniżej przedstawiam omówienie jego przydatności oraz poszczególnych kroków:

1. Wysyłanie powiadomienia e-mail

Skrypt rozpoczyna się od wysłania e-maila, który informuje o rozpoczęciu procesu załadowania danych do bazy eMarket. Dzięki temu administrator lub odpowiednia osoba odpowiedzialna za system może monitorować stan procesu.

2. Definicja katalogów roboczych

Zdefiniowanie katalogów roboczych i ustawienie zmiennych systemowych, takich jak KAT_TMP i BINARIA, pozwala na łatwe zarządzanie lokalizacjami plików oraz narzędziami używanymi w procesie.

3. Sprawdzanie obecności wymaganych plików

Skrypt sprawdza, czy w katalogu roboczym znajdują się pliki wejściowe (z rozszerzeniem .IN). Jeśli pliki nie zostaną znalezione, skrypt przerywa działanie i wysyła powiadomienie o błędzie. To zapewnia, że proces nie rozpocznie się, jeśli brakuje niezbędnych danych.

4. Konwersja kodowania znaków

Skrypt dokonuje konwersji znaków w pliku CENNIK.IN z jednego formatu (LAT) na inny (ISO). Jest to ważne, gdyż różne systemy mogą używać różnych standardów kodowania, a konwersja zapewnia spójność danych.

5. Zablokowanie dostępu do bazy

Skrypt blokuje dostęp do bazy danych na czas wczytywania danych. Tworzenie pliku tymczasowego (emarket.tmp) zapewnia, że nikt nie będzie mógł modyfikować bazy danych podczas załadowania nowych danych, co zapobiega możliwym błędom lub kolizjom.

6. Wykonywanie skryptów załadunkowych

Po zablokowaniu dostępu do bazy, skrypt uruchamia serię skryptów, które odpowiadają za:

  • Usuwanie starych tabel (90-usuntabełe),
  • Tworzenie nowych tabel (20-załoztabełe),
  • Załadowanie danych (30-załadujtabełe),
  • Tworzenie indeksów (40-załozindeksy),
  • Ładowanie katalogu (40-załadujkatałog),
  • Optymalizację (45-optymałizuj),
  • Generowanie statystyk (50-statystyka).

Te kroki są kluczowe dla prawidłowego załadowania danych i ich późniejszego przetwarzania w systemie.

7. Zakończenie procesu

Na końcu skryptu zostaje usunięty plik tymczasowy, który blokował dostęp do bazy, a także użytkownicy ponownie uzyskują dostęp do systemu. Skrypt informuje o zakończeniu procesu załadunku danych.

Przydatność skryptu:

Skrypt ten jest przydatny w systemach, które wymagają regularnego i zautomatyzowanego załadowania danych do bazy. Automatyzacja tych procesów zmniejsza ryzyko błędów ludzkich i zapewnia płynność operacji. Skrypt wspiera także konwersję danych, co jest istotne, gdy systemy używają różnych kodowań znaków. Dodatkowo, blokowanie dostępu do bazy podczas załadowania danych zapewnia integralność danych i chroni przed niepożądanymi zmianami w trakcie procesu.

Etapy załadunku danych do bazy zostały podzielone na osobne funkcjonalne części, co ułatwia ewentualne diagnozowanie nieprawidłowości oraz dalszy rozwój tego oprogramowania. Każdy ze skryptów wykonujących działania na bazie PostgreSQL otrzymał nazwę zbudowaną z początkowych dwóch cyfr oznaczających jego logiczną kolejność w wykonaniu, analogicznie jak to ma miejsce w przypadku skryptów startowych w systemach UNIX typu SysV 4.2 gdzie takie uporządkowanie występuje oraz w systemach BSD w skryptach administracyjnych (daily, weekly, monthly itp.). Omówienie poszczególnych skryptów SQL zostało umieszczone w kolejnych rozdziałach traktujących o samej strukturze bazy danych. Wspomnieć należy, iż aby wykorzystywać bazę danych PostgreSQL, administrator bazy założył odpowiednich użytkowników bazy z hasłami dostępu i uprawnieniami pozwalającymi na czynności administracyjne.  Głównym plikiem konfiguracyjnym PostgreSQL regulującym dostęp określonych użytkowników z określonych hostów jest plik konfiguracyjny „pg_hba.conf\ Dokładnie omawia to dokumentacja PostgreSQL. Sposób autoryzacji (czy system wymaga hasła czy też nie) jest definiowany w tym pliku. Na jego końcu przy domyślnej konfiguracji znajdują się wpisy: local all trust

host all 127.0.0.1 255.255.255.255 trust_____________________________________________

Oznaczają one, że dla połączeń lokalnych (local) – czyli takich, gdzie łączymy się nie korzystając z socket’ów tcpip i dla dowolnej bazy (all), system ma przyjąć regułę nie pytania o hasło (trust) natomiast dla połączeń zdalnych, ale tylko z maszyny o adresie 127.0.0.1 (czyli z tego samego hosta, ale przez sockety tcpip), będzie obowiązywać ta sama reguła. Aby to zmienić należy zastąpić ostatnie słowo (trust) na „password” lub „crypt” (różnią się one metodą przesyłania hasła). Przykładowo zapis:

host all 192.168.1.10 255.255.255.0 password                  ~

Oznacza, że osoby łączące się z serwera o adresie 192.168.1.10 oraz z całej klasy C (czyli

w rzeczywistości adres ip może być typu 192.168.1.*) muszą podać hasło aby dostać się do dowolnej bazy. Chcąc wymusić aby wzorcowy szablon bazy PostgreSQL był także chroniony można dokonać zapisu: host template1 192.168.1.10 255.255.255.0 password

co oznacza, że te same osoby będą mogły teraz dostać się tylko do bazy template1 i będą musiały podać hasło. Metod autoryzacji użytkowników jest wiele, między innymi także na podstawie protokołu ident. Przy pisaniu reguł dostępu należy pamiętać o kolejności. Zawsze użyta zostanie ta reguła która jest pierwsza w pliku i pasuje do sytuacji (regułki przeszukiwane są w kolejności od początku do końca pliku aż do znalezienia pierwszej

pasującej i na tym się kończy przeszukiwanie). Poniższy zapis byłby błędny, pozbawiony sensu poprzez swoją błędną hierarchię:

local all trust

host all 127.0.0.1 255.255.255.255 trust local templatel password

host templatel l27.0.0.1 255.255.255.255 password

Poprawnej konfigurację tej access listy przedstawia przykładowy zapis: local templatel password

host templatel l27.0.0.1 255.255.255.255 password local all trust

host all l27.0.0.l 255.255.255.255 trust______________________________________________

W przypadku konfiguracji rzeczywistej sklepu wpisy dopuszczające ustalają dostęp do bazy sklepu nazwanej jako „emarket” tylko i wyłącznie z serwera na którym działa sklep oraz dla określonego użytkownika z hasłem. Zapewnia to już zwiększony poziom bezpieczeństwa poprzez odrzucenie przez silnik bazy danych połączeń pochodzących zarówno od użytkowników lokalnych serwera jak i zdalne próby nawiązania połączeń (choć to także zabezpiecza zastosowany firewall). PostgreSQL zapewnia ponadto zabezpieczenia dostępu do tabel zgodnie ze standardem SQL92 (www.postaresal .org/idocs/index.php?sq1 .html). Na zasadzie przywilejów na konkretne działania i operacje na krotkach, tabelach, indeksach, procedurach czy funkcjach. Można tu bardzo precyzyjnie określać co, kto jak i kiedy może uczynić ze zgromadzonymi danymi, czy może tylko czytać nasze dane czy też usuwać, poprawiać, dodawać nowe itp.

Struktura systemu CMS

5/5 - (1 vote)

Systemy zarządzania treścią zazwyczaj oparte są na bazach danych oraz na językach skryptowych po stronie serwera. Najczęściej spotykanym zestawem jest baza danych MySQL i język skryptowy PHP. Dane są oddzielone od szablonu strony i przechowywane w bazie danych. Aplikacje działające na serwerze pobierają dane i wyświetlają je w wyznaczonych uprzednio miejscach na stronie.

Warstwy

W systemach CMS nastąpiło oddzielenie warstwy prezentacji treści od warstwy aplikacji. Pierwsza z tych warstw jest tym, co widzą użytkownicy – naszą stronę internetową, która jest efektem naszej pracy. Druga z nich to warstwa, w której tworzymy nasz projekt, czyli warstwę, w której pracują osoby zarządzające stroną.

Strona internetowa, którą widzą goście i zalogowani użytkownicy to tzw. strona frontowa (ang. front end). W jej skład wchodzą: menu, zawartość, reklamy, różne funkcje, np. logowania użytkownika. Natomiast warstwą administracyjną strony jest zaplecze (ang. back end). Można w niej konfigurować oraz konserwować nasz portal, czyścić oraz tworzyć statystyki lub przygotowywać zawartość. Część tej warstwy znajduje się pod innym adresem URL (ang. Uniform Resource Locator) niż strona WWW.

Logowanie do panelu administracyjnego

Wstęp do panelu administracyjnego jest chroniony. Zarządzać systemem mogą tylko użytkownicy, którzy posiadają konto i odpowiednie uprawnienia – głównego administratora, administratora lub operatora.

Podczas logowania system sprawdza:

  • czy logujący się ma prawo wstępu na zaplecze (ang. Access right),
  • jakim poziomem uprawnień dysponuje, jakie może wykonywać zadania (ang. Access level).

Tę procedurę nazywa się często uwierzytelnieniem, autoryzacją, autentykacją czy rejestracją. Ale nie są to terminy równoznaczne. Uwierzytelnienie lub autentykacja to sprawdzenie, czy użytkownik jest tym, za kogo się podaje. Autoryzacja, to sprawdzenie, do czego użytkownik ma prawo. Natomiast rejestracja oznacza zakładanie konta użytkownika.

Prawa dostępu

Mówiąc o zarządzaniu myślimy o administracji istniejącymi zasobami. W CMS każdy użytkownik otrzymuje swój status, do którego przypisane są różne prawa dostępu. Wśród użytkowników wyróżniamy[1]:

  • Zwykli użytkownicy (zarejestrowani i niezarejestrowani)
  • Autorzy – autorzy mają prawo przesyłać materiały do wyznaczonych sekcji i kategorii artykułów oraz edytować swoje materiały.
  • Redaktorzy – mają prawo dodawać i redagować artykuły w wyznaczonych sekcjach i kategoriach oraz edytować (redagować) artykuły wszystkich innych autorów.
  • Wydawcy – mają prawo dodawać artykuły w każdej sekcji witryny, edytować (redagować) artykuły wszystkich innych autorów oraz dodatkowo decydować o opublikowaniu bądź zakończeniu publikacji każdego artykułu.
  • Operatorzy – najniżsi rangą w grupie administratorów prawa do zarządzania artykułami i zarządzania pozycjami menu witryny. Nie mogą dodawać użytkowników ani modyfikować ich kont, nie mogą instalować składników systemu, nie mają na zapleczu dostępu do komponentów i modułów.
  • Administratorzy – mogą prawie wszystko, z wyjątkiem spraw zastrzeżonych tylko dla głównego administratora. A więc nie mogą dokonywać zmian w konfiguracji, nie mogą instalować szablonów, języków. Ponadto nie mogą rozsyłać korespondencji seryjnej do użytkowników.
  • Główny administrator – odpowiada za całą witrynę. Jest jedynym, który ma dostęp do wszystkich funkcji zaplecza oraz jedynym, który ma prawo konfigurować witrynę, instalować szablony i pliki językowe, tworzyć dodatkowe konta głównych administratorów. Konto głównego administratora zakładane jest podczas instalacji Joomla!.

Powyższy podział jest stosowany w Joomli!, lecz podobne rozwiązania występują w innych systemach CMS. Strona WWW wyświetla różną zawartość lub udostępnia strefę administracyjną w zależności od uprawnień użytkownika.

Szablony

Są to wizualne formaty edycyjne, w których umieszcza się w zawartość. Szablon określa rozmiar, kolor i krój czcionki, podział strony, odstępy między obiektami, czyli wszystko to, co odpowiada za wygląd strony. Dobry szablon powinien zapewnić administratorom i projektantom witryn[2]:

  • swobodę decyzji o wyświetlaniu lewej i prawej kolumny,
  • ukrywanie lewej i prawej kolumny, gdy nie ma w nich żadnych modułów,
  • łatwą wymianę elementów identyfikacyjnych – logo, treści, stopki,
  • wybór j ednego z kilku wariantów kolorystycznych.

Szablon można zaprojektować samodzielnie, poszukać darmowych wzorów w Internecie, zakupić gotowy projekt lub zlecić profesjonalnej firmie opracowanie go, gdyż wykonanie własnego szablonu wymaga znajomości HTML[3] oraz CSS[4].

Typowym wzorcem rozmieszczenia treści na stronach CMS jest struktura portalu opartego na 3-kolumnowym układzie (rys.1). Jednak układ ten nie jest w żaden sposób ograniczony i można go w dowolny sposób modyfikować.

Rysunek 1. Struktura portalu tworzonego w Joomla! źródło: [Polskie Centrum Joomla!

NAGŁÓWEK:logo, nazwa, logo, menu główne, menu narzędziowe, wyszukiwarka, ścieżka powrotu
LEWA KOLUMNA

menu główne lokalne użytkownika logowane i inne.

 MODUŁ MODUŁ PRAWA KOLUMNA
Tytuł st rony
GŁÓWNA TREŚĆ MODUŁ
MODUŁ
MODUŁ

STOPKA: noty prawne, adresy, powtórzenie menu głównego

Trzypoziomowa struktura treści

Joomla! oraz inne systemy CMS obsługują różne typy zawartości takie jak: tekst, obraz, muzyka. Aby jednak dodać jakikolwiek artykuł, trzeba stworzyć przynajmniej jedną sekcję, a w niej kategorię[5] (rys.2).

Pozycje – są to podstawowe, pojedyncze elementy treści: tekst artykułu, odnośnik do strony WWW, adres e-mail, obraz w galerii, produkt w katalogu, itp.

Kategorie – to kolekcje, zbiory pozycji zgrupowanych ze względu na jakieś kryterium tj. temat, rodzaj, typ; w kategorie porządkowane są artykuły oraz informacje gromadzone w komponentach.

Sekcje i komponenty – zawierają kolekcje kategorii artykułów (sekcje) i innych materiałów (komponenty), są to kontenery, w których grupuje się kategorie.

Rysunek 2. Struktura organizacji zawartości publikowanej w Joomla! źródło: [Graf H., „Joomla! System zarządzania treścią.”, Helion, Gliwice 2007]

Każda pozycja należy do jakiejś kategorii, a każda kategoria do sekcji lub komponentu.[6] Kategoria nie może istnieć bez sekcji lub poza komponentem, a w sekcji artykułów, a często także w komponencie musi być przynajmniej jedna kategoria. Jedynie w przypadku materiałów statycznych oraz komponentów udostępniających procedury (np. zakupów) nie ma podziału na sekcje i kategorie.

Zawartością w systemach CMS są zarówno sekcje, kategorie, jak i konkretne artykuły, obrazy czy odnośniki. W Joomla! rozróżnia się trzy podstawowe typy zawartości:

  • Artykuły dynamiczne – są powiązane z innymi elementami struktury serwisu. Treści te organizowane są w sekcje, a w tych z kolei wyodrębnione są kategorie, którym podporządkowuje się konkretne pozycje zawartości jak artykuły czy wiadomości.
  • Artykuły statyczne – to specyficzny rodzaj zawartości, który swoją budową przypomina statyczną stronę opartą na HTML. Stanowi on samodzielny element struktury serwisu. Części składające się na treść strony są tworzone i sortowane na sekcje i kategorie. Elementy te mają charakter dynamiczny i są z reguły wyświetlane chronologicznie. Z artykułami statycznymi jest inaczej; brak powiązań powoduje, że aby udostępnić taki artykuł, należy w sposób „ręczny” umieścić odnośnik do niego w jednym z menu bądź w innym artykule. Jeśli chodzi o uprawnienia edytorskie, to zawartość statyczną mogą tworzyć tylko redaktorzy i administratorzy w panelu administracyjnym serwisu. Artykuły statyczne wykorzystuje się do umieszczania informacji, które nieczęsto ulegają zmianie i stanowią niejako stałe elementy strony, np. regulamin, polityka bezpieczeństwa, dojazd i położenie firmy itp. Treści te można w dowolnej chwili zmieniać, jednak jest to wykonywalne tylko z poziomu administracyjnego.
  • Odnośniki lub ich zestawy – to także szczególny rodzaj zawartości. Odnośniki w Joomla! mogą prowadzić do:

o artykułów statycznych i dynamicznych, o kategorii artykułów, o zawartości sekcji artykułów, o dowolnego pliku, strony w Internecie.

Rozszerzenia (komponenty)

Artykuły i materiały statyczne dobrze sprawdzają się w prezentowaniu treści przeznaczonych do przeglądania. Jeśli jednak chcemy zapewnić na witrynie możliwości działania użytkowników, np. dyskusji czy dokonywania zakupów, nie obsłużymy tych potrzeb artykułami. Złożone zadania wymagają bogatszych narzędzi, wygodniejszych w użyciu, dostarczających zaawansowanych możliwości. Tę rolę spełniają w systemach CMS komponenty. To właśnie komponenty czynią je elastycznymi programami dla każdego, który łatwo dostosować do przeróżnych potrzeb – odpowiadają one za możliwość rozwoju systemu. Dla przykładu, komponent rescent news przenosi do szablonu nagłówki najnowszych wiadomości. Inny może pokazywać informacje meteorologiczne z rejonu, w którym mieszka osoba odwiedzająca stronę.

Projektując treści witryny, trzeba rozważyć:

  • czy i które z komponentów wykorzystamy,
  • czy standardowy zestaw zaspokoi nasze potrzeby,
  • czy wystarczą nam oferowane przez wybrane komponenty możliwości,
  • jakie komponenty warto j eszcze doinstalować.
    • Strony statyczne i dynamiczne

Portal złożony ze stron statycznych jest zbiorem stron HTML i powiązanych plików źródłowych (takich jak obrazki), które są przechowywane na serwerze. Strony statyczne nie są tworzone „w locie”. Zmiany tworzone są poprzez zastąpienie starej strony jej poprawioną wersją na serwerze[7] (rys.3).

Rysunek 3. Schemat budowy statycznej strony internetowej źródło: opracowanie własne, na podstawie [Frankowski P. 2007]


Strony dynamiczne, w przeciwieństwie do stron statycznych, generowane są na bieżąco przez serwer HTTP na podstawie zmiennych i parametrów przekazanych przez przeglądarkę internetową (rys.4). W procesie generowania strony WWW udział bierze współpracujący z serwerem rezydentny moduł lub program zewnętrzny, który interpretuje polecenia zawarte w skrypcie. Wygenerowany w ten sposób dokument w całości opiera się na kodzie HTML.

Funkcjonalność stron dynamicznych ujawnia się dopiero podczas współpracy z serwerami baz danych, gdzie przechowywane są elementy niezbędne do wygenerowania pojedynczej strony WWW – przede wszystkim teksty i grafiki. W dużym uproszczeniu można powiedzieć, że dynamiczna strona to kompozycja dwóch składowych: szablonu decydującego o formatowaniu i zmiennych decydujących o zawartości. Jak wielce pomocna jest technika dynamicznego generowania stron WWW, obrazuje bardzo prosty przykład. Chcąc uruchomić księgarnię internetową oferującą 10 000 książek, a dla każdej książki przygotować dedykowaną stronę WWW, która zawierałaby podstawowe informacje o tej książce – tytuł, autor, wydawca, rok wydania i krótki opis – zmuszeni bylibyśmy do zaprojektowania 10 000 odrębnych plików ze stronami HTML. Przy wykorzystaniu dobrodziejstw dynamicznego generowania stron WWW, ten sam efekt można uzyskać, projektując wyłącznie jedną stronę. Strona taka funkcjonowałaby na zasadzie wspomnianego szablonu, zawierającego stałe elementy formatowania wraz z elementami zmiennymi – informacjami o danej książce – które pobierane byłyby z bazy danych.

Tabela 1. Zestawienie cech zarządzalnej i niezarządzalnej strony

Cechy CMS Statyczna strona
Miejsceprzechowywania zawartości strony Baza danych Kod strony
Miejsceprzechowywania wyglądu strony (szablonu) Wyodrębnione pliki Kod strony lub wyodrębnione pliki
Tworzenie nowej podstrony Nowa podstrona jest tworzona na bazie zdefiniowanego szablonu. Cała nawigacja strony jest automatycznie aktualizowana, bez konieczności ingerowania w jej kod Dodanie podstrony wymaga utworzenia nowego pliku, połączenia się z serwerem, wgrania i modyfikacji istniejących plików (odpowiednie odnośniki do istniejących treści)
Zmiany na stronie Prosta możliwość wprowadzenia zmian w dowolnym momencie. Modyfikacja polegająca na dodaniu lub usunięciu strony nie wymaga wykonywania żadnych zmian graficznych Aktualizacja stron wiąże się z ingerencją w kod, co wymaga wiedzy wszystkich użytych technologii. To wymusza interwencję specjalisty, któremu przekazujemy informacje o tym, co chcemy zmienić
Szybkość wprowadzania zmian na stronie Błyskawiczna. Wystarczy zalogować się do panelu administracyjnego strony, edytować stronę i zapisać zmiany Czas od kilku minut do kilku dni, składa się na niego czas przekazania informacji webmasterowi, czas który musi poświęcić na dokonanie poprawek, akceptacja poprawek i wysłanie plików na serwer
Narzędzia do edycji strony Przeglądarka strony Edytor kodu HTML, klient FTP, przeglądarka internetowa
Wymagania co do wiedzy technicznej Nie jest wymagana specjalistyczna wiedza, wystarczą podstawy edycji tekstu Od webmastera wymagana jest specjalistyczna wiedza w zakresieHTML, CSS
Model zarządzania Rozproszony- różne uprawnienia dla dowolnej liczby osób Często scentralizowany- webmaster publikujący wszystkie informacje
Koszty utrzymania W zależności od skali projektu na cenę mogą składać się opłaty za utrzymania domeny na serwerze, aktualizację systemu CMS, zaprojektowanie CMS (jeśli nie korzystamy z darmowego), jego instalację i skonfigurowanie Wysokie, każda aktualizacja wiąże się z wydatkiem na webmastera lub wyspecjalizowaną agencją interaktywną
Koszt wdrożenia W zależności od wyboru systemu CMS- od darmowego do kilku tysięcy złotych Od kilkuset złotych do kilku tysięcy
Dodatkowafunkcjonalność Szerokie możliwości instalacji dodatkowych modułów Wymagana interwencja webmastera, który musi stworzyć nową funkcję
Stworzenie nowej wersji językowej strony Bardzo uproszczone, dodajemy kolejne strony Trudne, wymagana ingerencja webmastera w nawigację strony
Zapleczetechniczne Konto WWW z obsługa PHP i bazą danych Dowolne konto WWW
Szybkośćwyświetlania Mniejsza od wyświetlania samego kodu HTML, w głównej mierze zależne od parametrów bazy danych Duża szybkość wyświetlania
Funkcjonalność np.dodanie wyszukiwania wewnątrz strony Informacje zachowane w bazie danych, dzięki temu mamy szybki dostęp do informacji Możliwe, wymaga jednak tworzenie odpowiednich skryptów
Bezpieczeństwodanych Z charakteru budowy strony wynika, że cała strona jest przechowywana w dwóch miejscach: lokalnie oraz na serwerze. W razie awarii wystarczy ponownie skopiować pliki na serwer. System jest narażony na ataki hackerów, którzy mają otwarty dostęp do kodu i mogą wyszukiwać w nim błędy Wymagane jest robienie kopii zapasowych

Źródło: opracowanie własne, na podstawie [Rosenfeld L., Morville P. 2003]

Wykorzystanie systemu CMS ma sens, jeśli tworzony przez nas projekt składa się z wielu stron i w założeniu będzie ich systematycznie przybywać, jego treść będzie często ulegać zmianie, równocześnie przy zachowaniu jednolitego wyglądu. Z powyższego zestawienia (tab.1) wynika, iż najważniejszą zaletą systemów CMS jest prostota obsługi, dzięki której od użytkowników wymaga się tylko znajomości podstawowych możliwości popularnych aplikacji biurowych.

Zaletą jest jej możliwość szybkiego i precyzyjnego wprowadzania zmian przez wiele osób oraz obniżenie kosztów administracji strony internetowej. Za wadę należy uznać nieznacznie wolniejsze wyświetlanie stron oraz możliwe ataki na bazę danych. Także graficzny wygląd strony jest narzucony, a jego modyfikacja niesie ze sobą dodatkowe koszty.

[1] Frankowski P., „CMS. Jak szybko i łatwo stworzyć stronę WWW i zarządzać nią.”, Helion, Gliwice 2007

[2] Joomla! Templates [templatka.pl]

[3] HTML (ang. HyperTextMarkup Language) – dominujący język wykorzystywany do tworzenia stron internetowych..

[4] Kaskadowe arkusze stylów (ang. Cascading Style Sheets) to język służący do opisu formy prezentacji (wyświetlania) stron WWW.

[5] Rosenfeld L., Morville P., „Architektura informacji”, Helion, Gliwice 2003

[6] Howil W., „CMS. Praktyczne projekty”, Helion, Gliwice 2007

[7] Linderman M., Fried J., “Przyjazne witryny WWW”, Helion, Gliwice 2005

Maskowanie adresu IP

5/5 - (1 vote)

Mechanizm translacji adresów sieciowych NAT nazywany również maskowaniem adresu IP rozwiązuje problem ukrywania wewnętrznych hostów. NAT jest mechanizmem zastępczym – pojedynczy host wysyła żądania w imieniu wszystkich wewnętrznych hostów i ukrywa w ten sposób ich tożsamość dla sieci publicznej. Windows NT nie zapewnia takiej funkcji jeżeli zachodzi potrzeba użycia NAT trzeba zainstalować oprogramowanie firewall z innego źródła[1].

W Linuxie i systemach operacyjnych typu UNIX funkcja NAT wchodzi w skład pakietu. Mechanizm NAT ukrywa wewnętrzne adresy IP za pomocą zamiany wszystkich adresów wewnętrznych hostów na adres ściany ogniowej. Następnie ściana przesyła ładunek danych pochodzący z wewnętrznych hostów zaopatrując go we własny adres. Wykorzystuje przy tym numer portu TCP w celu śledzenia odwzorowań połączeń ze strony sieci publicznej z hostami wewnętrznymi. Z punktu widzenia Internetu cały ruch wydaje się pochodzić z jednego, obciążonego komputera. Mechanizm NAT skutecznie ukrywa wszystkie informacje warstw TCP/IP związane z hostami wewnętrznymi przed użytkownikami Internetu. Translacja adresów pozwala również na korzystanie w sieci wewnętrznej z dowolnego zakresu adresów IP, nawet jeżeli są one używane gdzieś w Internecie. Oznacza to, że nie trzeba rejestrować dużych bloków adresów w InterNIC lub zmieniać adresy wstępnie nadane w sieci, zanim została ona przyłączona do Internetu.

NAT pozwala także na rozdzielenie pojedynczego adresu IP na całą sieć. Wiele małych instytucji korzysta z pomocy dostawcy  usług internetowych, który może niechętnie przydzielać duży blok adresów IP ponieważ jego puka jest ograniczona. Dzięki maskowaniu adresu użytkownik może współużytkować pojedynczy adres modemu (przyłączonego na stałe lub dial-up) bez konieczności informowania o tym swojego dostawcy. Wadą korzystania z NAT jest to, że jest on implementowany tylko na poziomie warstwy transportowej. Oznacza to w praktyce, że informacja ukryta  w części danych pakietu TCP/IP może być przesłana do usług wyższej warstwy i wykorzystania do eksploatacji słabości w innej warstwie lub do komunikowania się z koniem trojańskim.

Użytkownicy, którzy chcą zapobiegać naruszeniom bezpieczeństwa muszą korzystać z usług takich jak proxy. NAT rozwiązuje wiele problemów związanych z bezpośrednim połączeniem z internetem, ale nadal nie ogranicza całkowicie przepływu datagramów przez firewala. Osoba wyposażona w monitor sieciowy może obserwować ruch wychodzący ze ściany ogniowej i stwierdzić, że przekształca on adresy innych komputerów. Hakerzy mogą w takiej sytuacji przechwycić połączenia TCP lub je sfałszować. Takiemu zagrożeniu zapobiega tzw. proxy aplikacyjne. Pozwalają one całkowicie rozłączyć przepływ protokołów warstwy sieciowej przez ścianę ogniową i skierować ruch do protokołów warstwy wyższej takich jak HTTP, FTP i SMTP.

Proxy przyjmuje próbę połączenia z zewnętrznymi serwerami i następnie w imieniu klienta wykonuje żądanie połączenia do serwera docelowego. Gdy serwer zwraca dane proxy przekazuje je do klienta. Proxy aplikacyjne różnią się od mechanizmów NAT i filtrów tym, że aplikacja klienta internetowego jest konfigurowana tak, aby komunikowała się z proxy. Na przykład użytkownik przekazuje aplikacji Internet Explorer adres swojego proxy WWW i wtedy Internet Explorer przesyła wszystkie żądania WWW do proxy, zamiast odwzorowywania nazwy na adres IP i wykonywania połączenia bezpośrednio.

Proxy aplikacyjne nie muszą być uruchamiane na komputerach-ścianach ogniowych. Każdy serwer, zarówno wewnątrz jak i na zewnątrz sieci użytkownika, może spełniać funkcję proxy. Jednak bez ściany ogniowej nie można osiągnąć prawdziwego bezpieczeństwa, potrzebne są oba rozwiązania. Niezbędny jest co najmniej jeden filtr pakietów po to, aby chronić serwer proxy przed atakami w warstwie sieciowej typu uniemożliwienia działania [2].

Jeżeli zaś proxy nie jest uruchomione na komputerze  pełniącym rolę ściany ogniowej, trzeba otworzyć kanał w ścianie w taki lub inny sposób. Najlepsza jest sytuacja, gdy ściana ogniowa spełnia rolę proxy. Zapobiegałoby to przekazywaniu pakietów przychodzących z sieci publicznej do sieci użytkownika. Niektóre ściany ogniowe typu proxy są bardziej złożone od innych. Ponieważ mają one mechanizmy filtrów oraz maskowania IP, można za ich pomocą blokować próby połączeń wychodzących (port80 w przypadku HTTP) do zdalnych hostów zamiast wymagać, aby oprogramowanie klienta było odpowiednio skonfigurowane z uwzględnieniem usługi proxy. Proxy firewala łączy się odpowiednio ze zdalnym serwerem i żąda danych w imieniu zablokowanego klienta. Odszukane dane są zwracane do klienta za pomocą mechanizmu NAT i wygląda to tak, jakby pochodziły ze zdalnego serwera [3].

Proxy zabezpieczające potrafią także wykonywać filtrowanie określonej zawartości na poziomie warstwy aplikacyjnej. Na przykład niektóre proxy HTTP szukają etykiet na stronach HTML, które odwołują się do wbudowanych apletów Java lub ActiveXi następnie usuwają z nich zawartość. Zapobiega to wykonaniu apletu na komputerze klienckim i eliminuje ryzyko przypadkowego załadowania przez klienta konia trojańskiego. Tego typu działanie jest bardzo ważne, ponieważ filtrowanie IP, stosowanie proxy i maskowanie adresu nie zapobiegną naruszeniu bezpieczeństwa sieci, jeżeli użytkownik załaduje aplet ActiveX z koniem trojańskim.. W miarę przechodzenia do warstw wyższych sieci usługi bezpieczeństwa są coraz ściślej określane. Na przykład filtrowanie dotyczy warstw IP i następnie TCP oraz UDP.

Aplikacje, które korzystają z IP w połączeniu z innymi protokołami na przykład Banyan Vines, muszą stosować specjalne, bardzo kosztowne lub niezwykle silne ściany ogniowe. Proxy są bardzo ściśle określone ponieważ mogą one pracować tylko dla konkretnej aplikacji. Na przykład HTTP wymaga oddzielnego modułu proxy niż FTP lub Telnet. W miarę rozwoju protokołów (szczególnie HTTP zmienia się szybko) moduł proxy związany z danym protokołem musi być aktualizowany. Istnieje wiele protokołów, które są własnością producenta lub są na tyle rzadkie, że nie ma dla nich proxy zabezpieczającego. Przykładem protokołu aplikacyjnego, który jest własnością i nie ma proxy zabezpieczającego jest Lotus Notes. Protokoły te muszą być przesyłane poprzez filtry warstwy sieciowej lub można dla nich użyć uniwersalne proxy TCP, który odtwarza pakiet ale nie ingeruje w przesyłane dane. Przykładem proxy uniwersalnego jest pakiet SOCKS, nazywany czasem bramą warstwy obwodowej. Mimo, że proxy uniwersalne nie może zapobiec atakowi z zawartości protokołu, jest bezpieczniejsze niż filtrowanie routingu, ponieważ pakiety warstwy sieciowej są całkowicie odtworzone i usunięte są z nich zniekształcenia, które mogłyby być nie wykryte przez ścianę ogniową.

[1] Windows 2000 posiada wbudowany NAT.

[2] Atak typu Ping of Death.

[3] Taki typ proxy nazywany jest proxy przezroczystym (ang. Transparent)

Ataki powodujące blokowanie usług DoS (denial of service)

Oceń tę pracę

Ataki typu DoS  stanowią znacznie większe zagrożenie – zwłaszcza dla provider’ów i administratorów sieci, ponieważ mogą tymczasowo unieruchomić całą sieć (a przynajmniej te serwery, których działanie opiera się na protokole TCP/IP).

Cel blokady usług jest jeden – pozbawienie prawowitych użytkowników możliwości korzystania z usług sieciowych, od prostego zajęcia całego pasma, po drastyczne wymuszenie załamania serwera. Każde takie działanie jest nielegalne [1]. Administrator zaatakowanej sieci powinien powiadomić władze – nie są to bowiem działania ciekawskich hakerów, lecz czyny przestępcze, dokonywane we wrogich zamiarach.

Atak polegający na blokowaniu usług wykorzystuje immanentne właściwości protokołu IP, tak więc może być wyprowadzony przeciw serwerowi na dowolnej platformie systemowej. Co gorsza – z racji faktu, że implementacje tego protokołu nie różnią się zbytnio pomiędzy platformami – pojedynczy atak  DoS może unieszkodliwiać kilka docelowych systemów operacyjnych. Niesławnym dowodem na potwierdzenie tej tezy jest atak przy pomocy programu destrukcyjnego LAND, który potrafi zablokować ponad 20 różnych systemów operacyjnych, w tym Windows NT i kilka odmian UNIX-a. Co więcej, analiza kodu źródłowego programów do przeprowadzania ataków DoS wykazuje, że raz wymyślony algorytm – nawet jeśli początkowo działa przeciw jednemu systemowi – szybko zyskuje na swej „funkcjonalności”. Nowe odmiany programów atakujących typu DoS pojawiają się mniej więcej co dwa tygodnie.

Programy te są zazwyczaj przeznaczone do uruchamiania na jednej platformie (na przykład Linux-ie), a ich celem również jest jedna platforma systemowa (powiedzmy Windows 95). Gdy taki kod zostanie udostępniony, wpada w ręce hakerów i krakerów, czego efektem jest powstanie w przeciągu dni zmodyfikowanych wersji programu (mutacji), które mogą unieruchomić większą ilość systemów operacyjnych.

—

[1] Prawo amerykańskie

Ściany Ogniowe w systemie Linux

Oceń tę pracę

Ściany ogniowe (firewalle) w systemie Linux to narzędzia służące do zarządzania ruchem sieciowym, które kontrolują, które połączenia są dozwolone, a które blokowane w oparciu o określone zasady bezpieczeństwa. W systemie Linux firewalle są kluczowym elementem w zapewnianiu bezpieczeństwa sieciowego, umożliwiając administratorom ochronę przed nieautoryzowanym dostępem oraz innymi zagrożeniami związanymi z siecią.

1. iptables:
Najbardziej popularnym narzędziem do zarządzania zaporami sieciowymi w systemie Linux jest iptables. Jest to narzędzie wbudowane w jądro systemu Linux, które pozwala na tworzenie i zarządzanie regułami filtracji pakietów. Iptables umożliwia definiowanie zasad dotyczących przychodzącego i wychodzącego ruchu sieciowego, na przykład poprzez określenie, które porty są otwarte, jakie protokoły mogą być używane, a także które adresy IP mogą mieć dostęp do zasobów systemu. Reguły w iptables są zazwyczaj zapisane w tabelach, które są podzielone na różne łańcuchy odpowiadające różnym etapom przetwarzania pakietów.

2. nftables:
nftables to nowsza i bardziej zaawansowana wersja narzędzia iptables, które zostało wprowadzone w jądrze Linux 3.13. Jest to system zarządzania zaporami, który zastępuje iptables, ip6tables, arptables oraz ebtables, umożliwiając jednolite zarządzanie różnymi typami ruchu w jednym narzędziu. Nftables oferuje bardziej zwięzłą składnię, lepszą wydajność oraz elastyczność w definiowaniu reguł, co czyni go preferowanym rozwiązaniem w nowszych dystrybucjach Linuksa. Nftables umożliwia łatwiejsze zarządzanie i bardziej złożoną konfigurację reguł, dzięki czemu jest bardziej skalowalny.

3. Firewalld:
Firewalld to narzędzie zapory sieciowej, które bazuje na iptables, ale oferuje bardziej przyjazny interfejs do zarządzania regułami zapory. Jest dostępne głównie w dystrybucjach takich jak CentOS, Fedora oraz RHEL. Firewalld działa na zasadzie stref, które definiują poziom zaufania dla różnych połączeń sieciowych. Każda strefa ma przypisane reguły dotyczące ruchu, co pozwala na łatwiejsze zarządzanie zaporą w porównaniu do iptables. Firewalld pozwala na dynamiczne dodawanie, usuwanie i modyfikowanie reguł bez konieczności restartowania zapory, co czyni go wygodnym narzędziem w środowiskach produkcyjnych.

4. UFW (Uncomplicated Firewall):
UFW to narzędzie zapory, które jest szczególnie popularne w dystrybucjach opartych na Debianie, takich jak Ubuntu. Jego celem jest zapewnienie prostoty konfiguracji zapory przy zachowaniu wysokiego poziomu bezpieczeństwa. UFW zapewnia łatwy sposób na tworzenie reguł filtracji pakietów za pomocą prostych poleceń. Dzięki temu jest to dobre rozwiązanie dla osób, które nie chcą zagłębiać się w szczegóły iptables, a potrzebują narzędzia do szybkiej konfiguracji zapory. UFW jest idealnym rozwiązaniem dla początkujących użytkowników Linuxa, którzy potrzebują prostych, ale skutecznych narzędzi zabezpieczających.

5. SELinux i AppArmor:
Choć SELinux (Security-Enhanced Linux) i AppArmor nie są zaporami sieciowymi w tradycyjnym sensie, to również pełnią istotną rolę w bezpieczeństwie systemu Linux, zwłaszcza w kontekście ochrony aplikacji i procesów przed nieautoryzowanym dostępem. SELinux to mechanizm kontroli dostępu oparty na politykach, który może ograniczać, do jakich zasobów mogą uzyskać dostęp aplikacje w systemie. Z kolei AppArmor oferuje podobną funkcjonalność, pozwalając na tworzenie profili bezpieczeństwa dla aplikacji i usług. Oba narzędzia współpracują z zaporami, aby zapewnić wielowarstwową ochronę systemu.

6. Zastosowanie ścian ogniowych w praktyce:
W kontekście praktycznym, zapory ogniowe w systemie Linux pełnią rolę pierwszej linii obrony przed atakami z sieci. Mogą być używane do blokowania nieautoryzowanego dostępu do systemu, ochrony przed atakami typu DoS (Denial of Service) oraz kontrolowania ruchu wychodzącego z systemu. W środowiskach produkcyjnych często stosuje się połączenie kilku narzędzi, takich jak firewalld lub iptables wraz z SELinux lub AppArmor, aby zapewnić kompleksową ochronę systemu przed zagrożeniami z sieci.

Zarządzanie zaporami sieciowymi w systemie Linux jest kluczowym elementem zapewnienia bezpieczeństwa i integralności systemu. Odpowiednia konfiguracja zapory ogniowej może znacząco zwiększyć odporność systemu na ataki z sieci, jednocześnie umożliwiając elastyczną kontrolę nad dostępem do zasobów systemowych.

Należy zacząć od świeżej instalacji posiadanej dystrybucji Linuxa (poniższe przykłady bazują na dystrybucji RedHat 3.0.3). Im mniej oprogramowania zostanie zainstalowane tym mniej będzie w nim dziur, tylnych wejść i / lub błędów wprowadzających do naszego systemu problem bezpieczeństwa, więc dobrze jest zainstalować jedynie minimalny zestaw aplikacji.

Należy użyć stabilnego jądra. Poniżej przedstawiona jest dokumentacja podstawowych ustawień (dla wersji 2.0.14) [1].

Oto są sieciowe ustawienia, które poznajemy wykonując komendę make config

  1. Under General setup
    1. Turn Networking Support ON
  2. Under Networking Options
    1. Turn Network firewalls ON
    2. Turn TCP/IP Networking ON
    3. Turn IP forwarding/gatewaying OFF (UNLESS you wish to use IP filtering)
    4. Turn IP Firewalling ON
    5. Turn IP firewall packet loggin ON (this is not required but it is a good idea)
    6. Turn IP: masquerading OFF (I am not covering this subject here.)
    7. Turn IP: accounting ON
    8. Turn IP: tunneling OFF
    9. Turn IP: aliasing OFF
    10. Turn IP: PC/TCP compatibility mode OFF
    11. Turn IP: Reverse ARP OFF
    12. Turn Drop source routed frames ON
  3. Under Network device support
    1. Turn Network device support ON
    2. Turn Dummy net driver support ON
    3. Turn Ethernet (10 or 100Mbit) ON
    4. Select your network card

Teraz możemy dokonać rekompilacji i reinstalacji jądra oraz zrestartować system. Nasza karta/y sieciowa/e powinna pojawić się w trakcie procedury startowej.

[1] R. Ziegler „Linux. Firewalls“