Miranda IM multikomunikator do wszystkiego

Multikomunikator Miranda IMKomunikatorem którego używam i który wart jest polecenia jest Miranda-IM. Miranda jest multikomunikatorem zużywa małą ilość pamięci, nie wymaga instalacji, jest niewielkich rozmiarów, nie zawiera reklam i co ważne jest bezpłatny programem wydawanym na licencji GNU GPL, a kod Ÿźródłowy programu jest powszechnie dostępny. Potężny system wtyczek czyni z niego bardzo elastyczne narzędzie do komunikacji i nie tylko. Dzięki zastosowaniu odpowiednich protokołów Miranda jest w stanie obsługiwać większośćœć sieci. Program oferuje rozmowy w trybie tekstowym również konferencje, przesyłanie plików, a takie wtyczki jak tlen czy Skype umożliwiają rozmowy głosowe.

Miranda IM MultikomunikatorMimo powszechnej opinii iż Miranda jest programem łatwym i przyjemnym moje pierwsze spotkanie zakończyło się niepowodzeniem. Pobierając program ze strony otrzymujemy kilka wtyczek, spartański wygląd programu i wiele opcji do konfiguracji. Jednak po dłuższej i głębszej analizie programu i poszukiwaniach można uzyskać wygląd programu jak na zdjęci obok oraz dużą funkcjonalnośćœć przewyższającą inne komunikatory. Oczywiście nie każdemu taki wygląd może się podobać ale możliwośćœci konfiguracyjnych oraz wyglądu programu jest całe mnóstwo. Miranda posiada ponad 500 wtyczek z których można zbudować własny komunikator.

Do wykonania komunikatora Miranda ze zdjęcia wykorzystano:

Miranda IM version: 0.6.1 Unicode
Build time: 13:51:28 on 09 January 2007
Unicode core: Yes

Użyte wtyczki (23):
chat.dll Chat (Unicode) [0.6.1.3]
clist_modern.dllModern Contact List (UNICODE) [0.4.3.55]
copyip.dllCopy IP [0.0.0.3]
dbx_3x.dllMiranda database driver [0.5.2.0]
fingerprint.dllFingerprint [0.1.0.70]
ftpfile.dllFTP File [0.0.1.1]
gg.dllGadu-Gadu Protocol [0.0.4.1]
icolib.dllIcons Library Manager (Unicode) [0.0.1.6]
ieview.dllIEView [1.0.9.4]
jabber.dllJabber Protocol [0.6.0.2]
msms.dllmSMS [0.0.6.9]
mstatus.dllmStatus [0.0.1.8]
mtooltip.dllmToolTip [0.0.1.0]
mucc.dllMUCC Plugin [1.0.7.3]
opensms.dllOpenSMS [0.0.0.3]
png2dib.dllPNG images processor [0.1.3.1]
popup.dllPopUp Interoperability [1.0.1.9]
scriver.dllScriver [2.3.2.14]
simpleaway.dllSimpleAway [1.6.1.1]
smileyadd.dll SmileyAdd [0.1.12.7]
tlen.dll – Tlen Protocol [1.0.7.3]
typingnotify_xp.dllTyping Notify [0.0.1.6]
versioninfo.dllVersion Information [2.0.0.0]

Galeria zdjęć Miranda IM


Komunikator Miranda-IM

Komunikator Miranda-IM

Komunikator Miranda-IM

Komunikator Miranda-IM

Komunikator Miranda-IM

Komunikator Miranda-IM

Apache – Serwery wirtualne

Od jakiegoś czasu można zaobserwować niesłychany wzrost popularności serwerów WWW. O ile jakiś czas temu firma czy organizacja mogła zadowolić się stroną WWW zamieszczoną w podkatalogu jakiegoś serwera, to dzisiaj ambicją każdego jest posiadać własny adres (najlepiej bardzo krótki i prosty do zapamiętania – np.w często opisywanej postaci http://www.firma.com.pl/). Czy to oznacza, że dla każdego serwera WWW trzeba poświęcać osobny komputer? Byłoby to ogromnym marnotrawstwem i czyniłoby takie rozwiązanie mało opłacalnym. Z pomocą przychodzi mechanizm tzw. serwerów wirtualnych. Wirtualne serwery są niezwykle przydatne kiedy chcemy, aby nasz serwer obsługiwał kilka witryn widocznych pod innymi adresami URL niebędącymi nazwą serwera z katalogiem tych witryn, w którym znajduje się strona. Umożliwia to dokładna personalizacje ustawień dla każdego i tworzenie osobnych dzienników serwera.

Uruchomienie serwerów wirtualnych możemy uzyskać na dwa sposoby:

  • Uruchomić pojedynczą kopie serwera obsługującą dwie lub więcej witryn z wykorzystaniem serwerów wirtualnych. Rozwiązanie to jest najczęściej stosowane.

  • Uruchomienie dwóch lub więcej kopi serwera Apacze, z których każda obsługuje osobną witrynę. Rozwiązanie to wykorzystuje się bardzo rzadko.

Serwery Wirtualne można tworzyć na podstawie adresów IP czyli do jednego urządzenia sieciowego przypisanych jest kilka adresów IP z odpowiadającym innym adresem domenowym lub poprzez identyfikowanie serwerów różnymi adresami URL związanymi z tym samym adresem IP.

Rozwiązanie wykorzystujące identyfikacje serwerów poprzez nazwy domenowe jest najbardziej polecane i bazuje ono na protokole HTTP/1.1. Rozwiązanie to wykorzystuje jeden adres IP, a rozróżnianie polega na zdefiniowaniu rożnych nazw domeny np. forma.com.ploraz biuro.firma.com.pl oczywiście nazwy te muszą być zarejestrowane w systemie DNS.

Apache serwery wirtualne – przykłady

<VirtualHost firma.com.pl>

ServerAdmin  administartork@firma.com.pl

DocumentRoot   /usr/Apache2/httdocs

SerwerName  firma.com.pl

(…)  # tu inne parametry

ErrorLog  /usr/Apache2/logs/error_log

TransferLog  /usr/Apache2/logs/access_log

</VirtualHost>

 

<VirtualHost biuro. firma.com.pl>

ServerAdmin  administartor@firma.com.pl

DocumentRoot  /usr/www/biuro

SerwerName biuro.firma.com.pl

(…)  # tu inne parametry

ErrorLog  /usr/www/biuro/logs/error_log

TransferLog  /usr/www/biuro/logs/access_log

</VirtualHost>

W tym przykładzie kluczowym elementem jest dyrektywa NameVirtualHost,która informuje serwer że żądanie kierowane jest do danego adresu IP i powinno być rozdzielone w zależności od nazwy domenowej witryny.

Dyrektywa: NameVirtualHost

Wartości: Adres IP port

Użycie: Konfiguracja główna

Opis: Umożliwia zdefiniowanie adresu IP oraz portu wykorzystywane przez serwery wirtualne identyfikowane za pomocą nazw.

Identyfikacja serwerów wirtualnych za pomocą adresów IP jest w Internecie ciągłe dość popularna mimo iż dostępny zakres adresów drastycznie zmalał.

W protokole HTTP/1.0 identyfikacja stron możliwa była jedynie w oparciu o numery IP. Dopiero protokół HTTP/1.1 wprowadził metodę umożliwiającą przesłanie przez przeglądarkę nazwy domenowej serwera.

Wielu administratorów korzysta z adresu IP ze względu na to, że starsze przeglądarki nie będą udostępniały możliwości dostępu do serwera Apache

<VirtualHost 83.210.159.2>

ServerAdmin administartork@firma.com.pl

DocumentRoot /usr/Apache2/httdocs

SerwerName firma.com.pl

ErrorLog /usr/Apache2/logs/error_log

TransferLog /usr/Apache2/logs/access_log

</VirtualHost>
<VirtualHost 83.210.159.3>

ServerAdmin administartor@firma.com.pl

DocumentRoot /usr/www/biuro

SerwerName biuro.firma.com.pl

ErrorLog /usr/www/biuro/logs/error_log

TransferLog /usr/www/biuro/logs/access_log

</VirtualHost>

Ostatnią metodą konfiguracji serwerów wirtualnych jest identyfikacja oparta na numerach portów. Zaletą tej techniki jest uruchomienie większej ilości serwerów wirtualnych z użyciem jednego adresu IP i pojedynczej nazwy domenowej.

Listen 8080

<VirtualHost 83.210.159.2:80>

ServerAdmin administartork@firma.com.pl

DocumentRoot /usr/Apache2/httdocs

SerwerName firma.com.pl

ErrorLog /usr/Apache2/logs/error_log

TransferLog /usr/Apache2/logs/access_log

</VirtualHost>
<VirtualHost 83.210.159.2:8080>

ServerAdmin administartor@firma.com.pl

DocumentRoot /usr/www/biuro

SerwerName biuro.firma.com.pl

ErrorLog /usr/www/biuro/logs/error_log

TransferLog /usr/www/biuro/logs/access_log

</VirtualHost>

Ze względu na to, że metoda jest oparta na metodzie opierającej się na adresach IP do obsługi nie jest potrzebny protokół HTTP/1.1.
Jeżeli będziemy chcieli obejrzeć stronębiuro.firma.pl, to w przeglądarce musimy podać adres: firma.pl:8080. Z tego powodu ta metoda nie jest zbyt popularna wśród użytkowników Internetu.

Czasami istnieje potrzeba, by dany serwer wirtualny był widoczny pod wieloma nazwami ze względu na przyzwyczajenia użytkowników podczas wpisywania adresów w przeglądarce. Najczęstszym przypadkiem jest wpisywanie adresu bez znaków WWW. Rozwiązanie tego problemu stanowi dyrektywa ServerAlias, która umożliwia zdefiniowanie aliasów identyfikujących serwer wirtualny.

 

<VirtualHost 83.210.159.2>

ServerAdmin administartork@firma.com.pl

DocumentRoot /usr/Apache2/httdocs

SerwerName firma.com.pl

ServerAlias www.firma.pl

ErrorLog /usr/Apache2/logs/error_log

TransferLog /usr/Apache2/logs/access_log

</VirtualHost>

 

Dyrektywa:ServerAlias

Użycie:Serwery wirtualne

Opis:Dyrektywa ta pozwala określić synonimy nazw (aliasy) danego serwera wirtualnego

Możliwości jest oczywiście o wiele więcej, ale przedstawione powyżej pozwolą na podstawową konfigurację.

.htaccess plik konfiguracyjny serwera Apache

.htacses
Plik konfiguracyjny serwera Apache .htaccess

Plik .htaccess jest charakterystycznym elementem serwera WWW, pozwalającym skonfigurować niektóre jego parametry. Może zostać umieszczony w każdymkatalogu, wywołując tym samym określoną reakcję odnośnie znajdujących się w nim plików, jak również zawartości podkatalogów, chyba, że w podkataloguumieszczono kolejny .htaccess. W ramach jednego konta może funkcjonować wiele niezależnych plików .htaccess, z których każdy definiuje inną akcję. Za pomocą specjalnych dyrektyw możliwe jest m.in. wskazywanie stron WWW wyświetlanych w odpowiedzi na różne komunikaty błędów serwera, ograniczanie dostępu do zasobów i wiele innych. Plik .htaccess odczytywany jest podczas każdego żądania dotyczącego plików danego katalogu, a więc jego modyfikacja znajduje natychmiastowe odzwierciedlenie w zachowania się serwera co może stanowić alternatywne rozwiązanie zmiany konfiguracji serwera w czasie jego pracy i jest swoistym rozszerzeniem pliku konfiguracyjnego httpd.conf, który jest odczytywany tylko raz podczas startu serwera.

Zaletą takiego rozwiązanie jest elastyczność administrator może zmienić konfiguracje poprzez modyfikacje tego pliku w dowolnym momencie bez potrzeby zatrzymywania Apacze. Niestety odbywa się to kosztem dość poważnego spadku wydajności spowodowanego koniecznością przeczytania i przeanalizowania przez serwer tego pliku podczas każdego odwołania do tej witryny.

Administrator może graniczyć efekt działania pliku za pomocą dyrektywy AllowOverride lub uniemożliwić klientom witryny podglądanie tego pliku. W tym celu należy w pliku konfiguracyjnym httpd.conf umieścić dyrektywę

<Files .htaccess>
Order allow, deny
Deny from all
</Files>

Nazwa .htaccess jest domyślną nazwą pliku konfiguracyjnego Apache. Może jednak zostać zmieniona za pomocą dyrektywy AccessFileName.

.htaccess – różne przykłady zastosowań

Ograniczenie odwiedzającym dostęp do określonego katalogu. Należy w tym katalogu umieścić plik .htacces z następującą treścią:

AuthName \”Dostep za zgodą forma.com.pl\”
AuthType Basic
AuthUserFile /ściezka do tajnego katalogu/.htpasswd
require valid-user

Do tego potrzebny jest jeszcze plik .htpasswd zawierający hasła i loginy dostępowe do ów katalogu. Hasła dodajemy za pomocą programu htpasswd, który znajduje się w katalogu c:\usr\Apache2\bin i wykonujemy:

htpasswd -c -b / ściezka do tajnego katalogu /.htpasswd user haslo

Opcja „c” służy nam jedynie wtedy gdy po raz pierwszy tworzymy plik z hasłami. Każde następne wywołanie wykonujemy już bez parametru –c

Zablokowanie dostęp niektórym IP, do serwera lub strony , plik .htacess powinien wyglądać tak:

Order allow,deny
Allow from all
Deny from xxx.xxx.xxx.xxx

Gdzie xxx.xxx.xxx.xxx to IP, które chcemy zablokować.

Zabezpieczenie się przed wyświetleniem zawartości katalogu, jeżeli w nim nie ma pliku startowego (index.html, index.php, itp.)

DirectoryIndex index.php index.html index.htm index.php3
Options -Indexes

.htaccess – zdefiniowanie własnej strony błędów

Aby zdefiniować własne strony błędów hosta lub serwera należy założyć na nim katalog o dowolnej nazwie np. error i wgrać do niego własne strony błędów.
Następnie należy wyedytować plik .htaccess o przykładowej treści i wgrać do katalogu głównego serwera – przykładowa treść poniżej:

ErrorDocument 400  http://domena.pl/error/400.shtml
ErrorDocument 401   http://domena.pl/error/401.shtml
ErrorDocument 403  http://domena.pl/error/403.shtml
ErrorDocument 404  http://domena.pl/error/404.shtml
ErrorDocument 405  http://domena.pl/error/405.shtml
ErrorDocument 406  http://domena.pl/error/406.shtml
ErrorDocument 408  http://domena.pl/error/408.shtml
ErrorDocument 410  http://domena.pl/error/410.shtml
ErrorDocument 411   http://domena.pl/error/411.shtml
ErrorDocument 414  http://domena.pl/error/414.shtml
ErrorDocument 500  http://domena.p/error/500.shtml
ErrorDocument 503  http://domena.pl/error/503.shtml

Oczywiście adresy plików są dowolne, nie wszystkie kody błędów trzeba ustawiać, będą działać w takim przypadku te dla całego serwera.

Definiowanie strony głównej za pomocą .htaccess

Funkcja definiowania strony głównej umożliwia określenie dokumentów wyświetlanych domyślnie po wpisaniu odnośnika, który nie zawiera wywołania konkretnej strony (np. http://biuro.firma.com.pl/oferta).

Index start.htm start.html index.htm index.html index.php

Jak zdefiniować przekierowanie 301 w pliku .htaccess?

Przekierowanie 301 jest to sposób za pomocą którego można internautę przekierować z jednego adresu URL na inny który może znajdować się na innym serwerze lub na tym samym. Jest to najlepsze rozwiązanie przy pozycjonowania strony WWW w wyszukiwarkach.

Kod 301 oznacza „Moved Permanently”, czyli trwale przeniesiony. Przekierowanie 301 powinniśmy stosować w przypadku, gdy posiadamy kilka domen, które wskazują na tą samą stronę internetową. Na przykład dla Google strona znajdująca się pod adresem twoja-strona.pl i www.twoja-strona.pl są to dwie różne strony. Dlatego należny wybrać adres główny z www lub bez i za pomocą przekierowania 301 a pozostałe domeny skierować na adres główny.

.htaccess – wymuszanie adresu domeny z przedrostkiem „www.” lub bez

RewriteEngine On
RewriteCond %{HTTP_HOST} ^twojadomena.pl$ [NC]
RewriteRule ^(.*)$ http://www.twojadomena.pl/$1 [R=301,L]

.htaccess przekierowanie z jednej domeny na drugą

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?stara-domena\.pl [NC]
RewriteRule (.*) http://nowa-domena.pl/$1 [R=301,L]

.htaccess – wymuszanie adresu domeny z przedrostkiem „https://”

RewriteEngine On
RewriteCond %{HTTPS} !^on$
RewriteRule ^(.*)$ https://www.domena.pl/$1 [R=301,L]

.htaccess – zabezpieczenie przed linkowaniem obrazków

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://(www\.)?twojadomena\.pl [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} ^http://.*$
RewriteRule \.(jpe?g|gif|bmp|png)$ /obrazki/image.png [L]

.htaccess – przekierowanie kilku domen na jeden adres

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?domena1.pl$ [OR]
RewriteCond %{HTTP_HOST} ^(www\.)?domena2.pl$
RewriteRule ^(.*)$ http://www.domena.pl/$1 [R=301,L]

 

 

Bezpieczeństwo serwera Apache

Bezpieczeństwo serwera Apache

Jednym z aspektów funkcjonowania serwera WWW jest bezpieczeństwo udostępnianych danych i informacji.

Udostępnianie komputera osobom postronnym jest bardzo niebezpieczne i można to porównać do otwartych drzwi i wpuszczeniu nieznajomych do mieszkania. Przeciętny komputer stojący na biurku zapewnia pewien poziom bezpieczeństwa wykradzenie danych czy innych informacji oraz uszkodzenie wymaga po prostu fizycznego dostępu czyli włamania się na ten komputer. Sytuacja zmienia się diametralnie kiedy ten komputer podłączony jest do sieci Internet za pomocą linii telefonicznej lub innego medium. Jeśli komputer nie zostanie odpowiednio zabezpieczony skutki takiej nierozwagi mogą być poważne.

Dyskusja na temat bezpieczeństwa systemów i serwerów praktycznie nie ma końca i można by na ten temat długo dyskutować.

Jednym z ważniejszych zagadnień funkcjonowania serwera Apache jest problem bezpieczeństwa. Oprócz wszystkich normalnych zagrożeń, takich jak włamania, serwery WWW są odpowiedzialne za chronienie integralności zarówno informacji rozsyłanej przez serwer, jak i informacji wysyłanej przez klienta do serwera.

Główne zagrożenia spowodowane bezpieczeństwem to:

  • wykorzystanie błędów programowych serwera WWW i skryptów CGI do uzyskania nielegalnego dostępu do plików systemu czy nawet przejęcia kontroli nad całym komputerem
  • przedostanie się ważnych informacji z serwera do nieupoważnionych użytkowników
  • przechwycenie danych przesyłanych między serwerem i przeglądarką
  • przedostanie się ważnych informacji z komputera, na którym działa przeglądarka WWW do fałszywego serwera prowadzonego potajemnie przez przestępców.

Podstawowym zadaniem dobrego zarządzania serwerem jest uniemożliwienie udostępnienia poufnych informacji. Z drugiej jednak strony serwer ma służyć do szybkiego udostępniania dużej ilości informacji. Co za tym idzie wzrasta poziom niebezpieczeństwa.

Jednakże tak jak i każde udostępnienie czegokolwiek pociąga za sobą ryzyko, że udostępnione zasoby mogą być nadmiernie wykorzystywane lub też sposób ich udostępniania może być co najmniej niewłaściwy. Dlatego też przy prowadzeniu serwisów administratorzy powinni zwrócić szczególną uwagę na prawidłowe ich zabezpieczenie.

Jakie środki podejmiemy w celu zabezpieczenia serwera zależeć będzie przede wszystkim jakiego typu będzie nasz serwis. Inaczej będzie to wyglądało w przypadku serwera na którym testujemy swoje strony, a inaczej w przypadku serwera w intranecie czy też udostępnionego publicznie.

W przypadku bezpiecznego serwera użytkownicy i projektanci aplikacji muszą dokładnie rozważyć, które z certyfikatów i urzędów certyfikacji można uznać za wiarygodne. Jakiekolwiek błędy spowodowane nieodpowiednim wybraniem mogą spowodować duże straty.

Zabezpieczenie serwera Apache w systemach Windows jest dyskusyjne nie oznacza to ze systemy te nie posiadają żadnych zabezpieczeń a raczej są one słabo udokumentowana i zrozumiałe dla wąskiej grupy ludzi. Dlatego też dla poważnych czy tez komercyjnych serwisów zaleca się instalowania serwera Apache na którejś z odmian systemów operacyjnych Unika.

Zabezpieczenie Apache w tych systemach ogranicza się do odpowiedniej przemyślanej konfiguracji serwera:

  • ograniczenie wykonywania skryptów CGI w ogóle lub tylko w obrębie katalogu użytkownika
  • ograniczeni wykonywania skryptów PHP, JAVA, ActiveX
  • zabezpieczenie plików czy katalogów na hasło za pomocą pliku .htacces
  • używanie dyrektyw deny i allow dla określenia lub zablokowania komputera lub grupy komputerów
  • serwery WWW pozwalają na przechodzenie do miejsc docelowych wskazywanych przez łącza symboliczne, które znajdują się poza strukturą drzewa katalogów przeznaczonych na dokumenty serwera. W ramach bezpieczeństwa powinniśmy zabronić przechodzenia do linków wskazujących na łącza symboliczne lub umożliwić tylko przechodzenie do łącz, takich gdzie dowiązanie i wskazywany przez nie plik lub katalog należą do tego samego użytkownika. Łącza symboliczne mogą być niebezpieczne ze względu na możliwość stworzenia przez lokalnych userów dowiązań do plików systemowych co może spowodować ominięcie zabezpieczeń. Stosowanie łącz symbolicznych umożliwia opcja FollowSymLinks dyrektywy Options
  • dużą porcję informacji mogą nam dostarczyć pliki dzienników. Wszystkie błędy wykryte przez serwer zapisywane są w pliku wskazanym przez dyrektywę ErrorLog. Zaleca się więc wyłączeni modułu mod_status i mod_info (domyślnie są wyłaczone)
  • ograniczenie działania komputera jedynie do prowadzenia serwera WWW
  • ustalenie maksymalnej wielkości plików przesyłanych na serwer co zabezpieczy przed nadmiernych zapełnieniem buforów pamięci
  • uruchamiamy jedynie te usługi, które są niezbędne dla działania serwera WWW
  • przeprowadzanie regularnie wykonywanych kopii zapasowych
  • śledzenie na bieżąco informacji na temat wykrytych przez producenta i użytkowników luk w bezpieczeństwie w używanym systemie operacyjnym

Powyższe zagadnienia obejmują bezpieczeństwo po stronie serwera ale oprócz samego bezpieczeństwa serwera, bardzo ważne jest bezpieczeństwo po stronie klienta. Jeżeli chcemy prowadzić biznes e-commerce, możemy skorzystać z bezpiecznego serwera, który korzysta z bezpiecznego protokołu.

Wszystkie dane przesyłane są w formie czystego tekstu. Na dodatek jest to robione na otwartym kanale. Każdy kto ma dostęp do któregokolwiek z serwerów, przez które przechodzą informacje od użytkownika, może bez problemów przechwycić te dane. Jedynym wyjściem z tej sytuacji jest zastosowanie systemu szyfrującego. Obecnie, wszystkie bardziej liczące się przeglądarki (Internet Explorer, Netscape czy Opera), umożliwiają obsługę standardów kodowania, lecz każda robi to w inny sposób.

Protokół TCP/IP nie zawiera w budowanych mechanizmów ochrony danych w komunikacji klient – serwer, co umożliwiłoby bezpieczną wymianę danych. Może to stanowić zagrożenie, że dane zostaną przechwycone przez osoby trzecie. Dla spełnienia wymagań bezpieczeństwa na rynku internetowym zostało opracowanych wiele protokołów pośredniczących pomiędzy warstwą transportu – TCP/IP a warstwą aplikacyjną – np. HTTP (protokół przesyłania danych w WWW).

Do najważniejszych z nich zaliczamy:

  • S-HTTP (Secure-HTTP) jest modyfikacją HTTP umożliwiającą bezpieczne przesyłanie informacji zgodnych z protokołem HTTP. S-HTTP nie jest standardem. Został zgłoszony do World Wide Web Consortium (W3C) w celu poddania procesowi standaryzacyjnemu. Zapewnia poufność, integralność i autoryzację danych, a jednocześnie możliwość negocjowania algorytmów, zarządzania kluczami oraz metod szyfrowania.
  • SSL (Secure Socket Layer) jest to protokół opracowany przez firmę Netscape Communications, stanowi „nakładkę” na TCP/IP i jako taki umożliwia zarówno przesyłanie wiadomości w protokole HTTP jak i innych.
  • SST (Secure Transaction Technology) opracowany został przez Microsoft i firmę VISA. Protokół jest przeznaczony do prowadzenia bezpiecznych zakupów w Internecie przy pomocy kart kredytowych.

Najbardziej rozpowszechnionym z wyżej wymienionych protokołów jest protokół SSL i używa się go w przypadku, gdy istnieje potrzeba zestawienia bezpiecznego połączenia, aby dane wymieniane między klientem a serwerem nie mogły być przechwycone przez niepowołane osoby. Zapewnia szyfrowanie i integralność danych serwera oraz opcjonalnie klienta. Bezpieczny serwer stosujemy przy prowadzeniu m.in. sklepów internetowych, w których korzystamy z numerów kont czy kart kredytowych. Protokół SSL dopuszcza trzy warianty uwierzytelniania porozumiewających się stron: uwierzytelnienie obustronne (serwer i klient), uwierzytelnienie jednostronne (serwer, klient zostaje anonimowy) i komunikację całkowicie anonimową.

Jeśli chcemy korzystać z bezpiecznego uwierzytelnienie musimy zaopatrzyć się w moduł mod_ssl, który dla opisywanego serwera nie jest aktualnie dostępny.

Dokumentacja opisująca bezpieczeństwo serwera Apache w systemie Windows praktycznie nie istnieje nawet w dokumentacji dostarczanej razem z serwerem, jednak przeanalizowanie dostępnych dyrektyw i zdrowy rozsadek może uczynić z serwera Apache w miarę bezpieczny serwer stron WWW.

Dyrektywy blokowe serwera HTTP Apache

 Apache udostępnia cały szereg tzw. dyrektyw blokowych (ang. block directives). Dyrektywy te pozwalają na ograniczenie innych zawartych w nich dyrektyw określonych dla plików, katalogów czy serwerów wirtualnych. Dyrektywy blokowe stanowią, więc rodzaj kontenera dla innych dyrektyw, które są wykonywane tylko i wyłącznie w obrębie danej dyrektywy blokowej i są one niezwykle istotne dla administrowania serwerem.

Dyrektywa blokowa na następującą składnie:

<dyrektywa blokowa>

</dyrektywa blokowa>

Poniżej przedstawię dyrektywy blokowe oraz dyrektywy używane wewnątrz dyrektyw blokowych przez serwer Apache.

<VirtualHost>

Dyrektywa blokowa używaną przez Apache do definiowania tzw. serwerów wirtualnych. Jeśli na przykład mamy domenę o nazwie moja_firma.com.pl i chcemy utworzyć oddzielna stronę dla biura w tej firmie np. biuro.moja_firma.com.pl to właśnie do tego celu używamy <VirtualHost>.

Dostępne dyrektywy:

  • ServerAdmin – adres emal administratora serwera wirtualnego
  • DocumentRoot – ścieżka dostępu do katalogu z plikami serwera wirtualnego
  • SerwerName – nazwa domeny serwera wirtualnego
  • ErrorLog – ścieżka do pliku error.log w którym zapisywane SA błędy w działaniu serwera
  • TransferLog – ścieżka do pliku acces.log

 

Przykład:

<VirtualHost biuro.moja_firma.com.pl>

        ServerAdmin aminek@moja_firma.com.pl

       DocumentRoot /usr/www_virtual/biuro

       SerwerName biuro.moja_firma.com.pl

       ErrorLog /usr/www_virtual/biuro/logs/error_log

      TransferLog /usr/www_virtual/biuro/logs/access_log

</VirtualHost>

 

Kolejne trzech dyrektyw blokowych, (Directory, Files, Location), zostaną przedstawione w kolejności rosnącej, co oznacz ze dyrektywa Directory może zostać zmodyfikowana przez Files, a ta musi ustąpić pierwszeństwa Location.

<Directory> i <DirecoryMatch>

Zapis:

<Directory Nazwa_katalogu>

</Directory>

Dyrektywa ta pozwala na ograniczenie zasięgu działania dyrektyw do wybranego katalogu lub grupy katalogów. Nazwa katalogu może zawierać symbole wieloznaczności „?” (dowolny znak) i „*” (dowolny ciąg dowolnych znaków), a również nawiasy kwadratowe ([ ]), służące do definiowania grup znaków. Na przykład [a-d] oznacza dowolny znak z ciągu a, b, c, d. Umieszczenie tyldy (~) na początku nazwy katalogu pozwala na użycie wyrażeń regularnych.

Wyrażenia regularne (ang. regular expressions) to wzorce, które opisują łańcuchy symboli. Teoria wyrażeń regularnych jest związana z teorią tworzenia tzw. języków naturalnych. Wyrażenia regularne mogą określać zbiór pasujących łańcuchów, mogą również wyszczególniać istotne części łańcucha.
Dyrektywa <DirectoryMatch> działa tak samo jak <Direktory>, tj. akceptuje definicję nazwy katalogu w postaci wyrażeń regularnych, tak więc zapis <Directory ~/katalog> i <Directory /katalog> są identyczne.

Dyrektywy te można użyć w konfiguracji głównej oraz serwerach wirtualnych.

<Files> i <FilesMatch>

Zapis:

<Files nazwa_pilku>

</Files>

Dyrektywy tej używa się dla ograniczenia określonego pliku podanego w parametrze nazwa_pliku. Dyrektywa <FileMatch> używana jest wraz z wyrażeniem regularnym nie poprzedzonym znakiem tyldy.

Aby ograniczyć obsługiwanie przez serwer tylko plików graficznych z rozszerzeniem *.gif, *.jpg musimy użyć dyrektywy <FileMatch „.gif|jpg”>.

Dyrektywę tą używamy w konfiguracji głównej, serwerach wirtualnych oraz plikach .htaccess.

<Location> i <LocationMatch>

Zapis:

<Location adres-url>

</Location>

Użycie tych dyrektyw pozwala na ograniczenia zasięgu działania bloku dyrektyw do zadanych adresów URL.

Dyrektywy te używa się w konfiguracji głównej oraz serwerach wirtualnych.

<IfDefine>

Zapis:

<IfDefine nazwa>

</IfDefine>

Dyrektywa ta pozwala na warunkowe uaktywnienie bloku dyrektyw w przypadku uruchomienia Apache z opcja –D nazwa. Pozwala to na zamkniecie w osobnym pliki httpd.conf osobnych wariantów konfiguracyjnych. Przydaje się to głównie podczas tworzenia i testowania tworzonych witryn. W przypadku regularnie działających witryn nie jest to stosowane.

<IfModule>

Zapis:

<IfModule [!]Nazwa_modułu>

</IfModule>

Dyrektywa pozwala na warunkowe uaktywnienie bloku dyrektyw w zależności od tego czy moduł o danej nazwie jest dołączony (podczas kompilacji lub dynamicznie przez załadowanie biblioteki dll) do programu Apache. Poprzedzenie nazwy modułu wykrzyknikiem powoduje uaktywnienie modułu, jeśli nie został on dołączony do programu.

Pliki konfiguracyjne Apache

Apache jest najszerzej stosowanym serwerem HTTP w Internecie. Jego udział wśród serwerów wynosił około 65%. W połączeniu z interpreterem języka skryptowego PHP i bazą danych MySQL, Apache stanowi jedno z najczęściej spotykanych środowisk w firmach oferujących miejsce na serwerach sieciowych.

Konfiguracja serwera Apache odbywa się za pomocą kilku plików konfiguracyjnych.

Należą do nich:

httpd.conf

Jest to główny plik konfiguracyjny Apache. W pliku tym zapisane są m.in. informacje na temat komputera, portu, trybu pracy, logów, zasobów udostępnianych przez serwer. Tutaj również przeprowadzamy konfigurację serwerów wirtualnych WWW uruchamianych przy pomocy Apache.

srm.conf

Plik ten konfiguruje sposób zarządzania żądaniami serwera, wskazuje na katalogi, które zawierają informacje oferowane przez serwer i różne elementy potrzebne do formatowania i prezentowania informacji.

access.conf

Służy do definiowania kontroli dostępu dla serwera i dostarczanych przez niego informacji.

Wszystkie trzy pliki mają podobną strukturę. Są one plikami ASCII, komentarze zaczynają się od znaku # i wszystkie posiadają obszerny komentarz do poszczególnych poleceń. Ponadto, większość poleceń w plikach jest zapisana w formie opcji, po której następuje wartość przypisana do opcji. Użycie trzech plików konfiguracyjnych jest podyktowane zachowaniem ze standardem serwera NCSA. Od wersji 1.3.4 zaleca się umieszczenie wszystkich parametrów konfiguracyjnych w jednym pliku co sprawia łatwiejsze zarządzanie serwerem. Pozostałe pliki (srm.conf i acess.conf) nadal istnieją, ale zawierają informacje, że istnieją wyłącznie ze względów historycznych a całą konfigurację należy przeprowadzić w pliku httpd.conf. W wersji prezentowanej w tym opracowaniu, czyli 2.0.52 już całkowicie zrezygnowano z tych plików i nie znajdują się one w katalogu konfiguracyjnym serwera.

Konfiguracja pliku serwera WWW składa się z dyrektyw, które można ustawić konkretną opcją, pozwalającą na kierowanie procesem uruchamiania serwera.
Dyrektywy wraz z opcjami zapisujemy w jednej linii w następujący sposób:

dyrektywa opcja 1 opcja 2

<Directory />
AllowOverride none
Require all denied
</Directory>

Po każdej modyfikacji pliku konfiguracyjnego należy z restartować serwer tak, aby nowe ustawienia zostały zaktualizowane.

Oprócz zwykłych dyrektyw możemy korzystać z dyrektyw blokowych posiadających budowę podobną do znaczników języka HTML. Dyrektywy te pozwalają na ograniczenie zasięgu działania innych zawartych w nich dyrektyw dla określonych serwerów wirtualnych, katalogów i plików.