Usługi sieciowe

O podstawowych usługach sieciowych

konto shell'owe (ssh, scp, sftp, unix)

Jest to usługa polegająca na udostępnieniu kont użytkowników na serwerze (z dostępem zdalnym przez SSH, rzadziej telnet) pozwalających na korzystanie z zainstalowanych tam programów oraz innych usług omawianych poniżej, jak również umieszczania tam swoich plików (przy pomocy SCP lub SFTP, rzadziej FTP).

SSH (bezpieczny shell) jest protokołem pozwalającym na zdalną pacę w którym połączenie (a w szczególności hasło) jest kodowane, na jego bazie funkcjonują rozwiązania takie jak SCP (bezpieczne kopiowanie) pozwalający na kopiowanie plików między zdalnymi serwerami i SFTP (bezpieczny FTP) pozwalający pracować z komendami FTP przy połączeniu szyfrowanym.

poczta (SMTP, POP3, IMAP)

Simple Mail Transfer Protocol to protokół przesyłania poczty elektronicznej pomiędzy agentami dostarczania - MTA (jest to względnie prosty, tekstowy protokół, w którym określa się co najmniej jednego odbiorcę wiadomości (w większości przypadków weryfikowane jest jego istnienie), a następnie przekazuje treść wiadomości). SMTP (także w wersji rozszerzonej m.in. o autoryzację - zobacz SMTP-AUTH) jest często stosowany także do wysyłania poczty z programu pocztowego do pierwszego MTA. SMTP operuje kilkoma typami numerów błędów - są to podstawowe numery zdefiniowane w samym SMTP, numery rozszerzające (rozdzielane kropkami) zdefiniowane w RFC 3463 oraz numery błędów DSN (RFC 1894).

Dopiero odbieranie wiadomości z serwera na którym działa MTA odbywa się przy pomocy innych protokołów takich jak POP3 (Post Office Protocol) oraz IMAP (Internet Message Transfer Protocol). IMAP jest protokołem nowszym od POP3 i posiadającym więcej funkcji m.in. obsługę już przefiltrowanej poczty umieszczanej w różnych plikach - skrzynkach (w odróżnieniu od POP3, który jest w stanie pobrać tylko wiadomości ze skrzynki systemowej, pozostawiając je tam lub kasując). Aby odbierać przez IMAP pocztę ze skrzynki systemowej jako folder należy podać INBOX, natomiast aby odebrać pocztę z innej skrzynki należy podać jej ścieżkę (np. ~/Mail/wazne odbierze pocztę z pliku ważne umieszczonego w podkatalogu Mail katalogu domowego użytkownika). Warto również zwrócić uwagę na systemy obsługi poczty przez WWW, zarówno przez POP3, IMAP jak i z lokalnych skrzynek, bardzo popularnym programem tego typu obsługującym zasadniczo pocztę z lokalnego serwera jest SquirrelMail. Wart jeszcze wspomnieć o możliwości czytania poczty po zalogowaniu na swoje konto - najczęściej program mutt lub poprzez edytor tekstowy.

Systemy obsługi poczty umożliwiają często konfigurację zaawansowanego jej przetwarzania po stronie serwera (takiego jak przenoszenie do odpowiednich folderów pocztowych, autoodpowiadanie, przekazywanie na inne adresy, ...)

NNTP

NNTP - zbliżony do poczty elektronicznej protokół grup dyskusyjnych (wiadomości wysyłane są do grupy o zadanej nazwie, przechowane są na serwerze i mogą zostać pobrane przez osoby czytające daną grupę). Protokół może być wykorzystywany na pojedynczym serwerze lub w ramach sieci serwerów (gdzie te same grupy przechowywane są na wielu serwerach, a użytkownik korzysta z "najbliższego"). W oparciu o ten protokół funkcjonuje sieć usenet.

HTTP (HTML, PHP, DB)

Protokół Transmisji Hipertekstu (Hypertext Transfer Protocol) - jest to obecnie jeden z najpopularniejszych protokołów internetowych. Jest on odpowiedzialny za transfer stron WWW (zarówno samego pliku HTML'owskiego jak i elementów w nim umieszczonych - grafiki, dźwięku, ...), obecnie (dzięki możliwości wznawiania przerwanej transmisji) często wykorzystywany również do przesyłu pobieranych z WWW plików. Pozwala również na transfer od użytkownika do serwera (ciasteczka (cookies), formularze, a nawet całe pliki).

W budowie serwisów (oprócz HTML'a, elementów graficznych, skryptów wykonujących się w przeglądarce, ...) często korzysta się z serwerowych języków skryptowych (CGI, PHP, ...) które pozwalają na dynamiczną generację wysyłanej strony (strona sama w sobie zawiera takie same elementy jak strony tworzony w sposób statyczny). Ich wykorzystanie często łączy się z wykorzystaniem systemów baz danych (prawie zawsze są to bazy SQL, do najpopularniejszej należy system MySQL).

DNS

Domain Name System - system pozwalający na posługiwanie się nazwami przyjaznymi dla człowieka zamiast numerami IP (oraz translację odwrotną). Jest jednym z podstawowych protokółów Internetu. DNS oparty jest na hierarchicznym układzie domen (domena nadrzędna to pierwsza od prawej część adresu, natomiast nazwa najbardziej na lewo określa konkretny komputer w danej domenie).

Serwery DNS zawierają różnego rodzaju wpisy, do najważniejszych zalicza się wpisy typu: A (zamiana nazwy na IPv4), AAAA (zamiana nazwy na IPv6), CNAME (alias), MX (serwer obsługi poczty), NS (serwer nazw obsługujący daną poddomenę), SRV (serwer obsługi zadanej usługi), PTR (DNS odwrotny).

Rekordy SRV są bardzo dobrym rozwiązaniem aby móc oferować usługi zlokalizowane na różnych serwerach pod wspólną nazwą domenową, a także rozkładać obciążenie pomiędzy serwery. Jednak niestety dla wielu (głównie starszych) protokołów implementacja tego mechanizmu praktycznie nie istnieje - jest tak m.in. w wypadku SMTP (tu co prawda mamy MX ale o mniejszych możliwościach niż SRV), HTTP

IRC

IRC - najstarszy, ale nadal bardzo popularny protokół chatów internetowych, rozmowy odbywają się na tzw. kanałach (np. tematycznych), możliwe jest też prowadzenie prywatnej rozmowy z wybraną osobą. Protokół umożliwia tworzenie sieci serwerów przekazujących wiadomości między sobą, wtedy użytkownik komunikuje się z najbliższym siebie serwerem (sieci irc).

Przekaz w czasie rzeczywistym i VoIP

Sieci pakietowe (w szczególności Internet) nie były tworzone z myślą o przesyłaniu danych w czasie rzeczywistym (oczywiście przesyłanie jest stosunkowo szybkie, jednak nie ma gwarancji braku opóźnień ani poprawnej kolejności odbioru pakietów). Jednak popularyzacja tych rozwiązań wraz z chęcią integracji sieci IP z systemami telefonii, radiofonii czy telewizji. O ile w przypadku tych dwóch ostatnich (podobnie jak przy większości usług multimedialnych, np. video na życzenie (VoD)) dość prostym rozwiązaniem jest buferowanie po stronie odbiornika (nawet przy transmisjach na żywo kilkudziesięcio-sekundowe opóźnienie jest zaniedbywalne w świetle opóźnień wprowadzanych na etapie realizatorskim ...). O tyle w przypadku telefonii czy wideotelefonii i usług pokrewnych (konferencje, ...) rozwiązanie to nie może być zastosowane a opóźnienia w przesyle informacji muszą być małe (inaczej rozmowa staje się uciążliwa). VoIP (Voice over IP) jest właśnie określeniem zbioru technik i protokołów służących do przesyłania głosu i obrazu w czasie rzeczywistym. Wykorzystuje się m.in. pola pozwalające na priorytetowanie ruchu IP, kompresję danych (często dostosowaną tylko do danego zagadnienia - np. mowy).

SIP

Session Initiation Protocol (SIP) jest dominującym obecnie standardem tego typu usług (wypiera królujący do niedawna H.323). SIP jest w zasadzie protokołem typu "peer to peer", współpracuje z Session Description Protocol (SDP), natomiast do przesyłu swoich sesji wykorzystuje pakiety protokołu RTP. Konstrukcja SIP oparta jest w zasadzie na HTTP, podobnie jak on SIP używa prostego mechanizmu żądań i odpowiedzi oraz korzysta z czystego tekstu. Metoda adresacji została natomiast zaczerpnięta z poczty elektronicznej i jest postaci "uzytkownik@host.domena:port", SIP korzysta z URI scheme "sip:" oraz domyślnego portu 5060; możliwa jest tez adresacja w stylu PSTN. Opracowywany jest też protokół IM opary na założeniach SIPu - SIMPLE. Warto wspomnie o serwerach typu registrar oraz proxy - te pierwsze służą wskazywaniu położenia klienta (ale rozmowa nie przechodzi przez ten serwer, chyba że jest do niego jawnie adresowana), te drugie przekazują rozmowę przez siebie (mogą tym samym udostępniać usługi takie jak nagrywanie rozmów itp.). Obok tych serwerów (mogą być niezależnymi usługami) funkcjonuje także nazwa domenowa konta, która w ogólności może być inna od nazw tych serwerów (ale w pewnym sensie musi być rozwijana do adresu serwera registrar.

Zobacz w Sieci: Telefonia @ Wikibooks, Bezpieczeństwo VOIP opartego na SIP.

XMPP/Jabber

Bardzo interesującym wydaje się protokół XMPP/Jabber (który z dużym prawdopodobieństwem ma szansę stać się oficjalnym protokołem IM). Jest to otwarty, uniwersalny protokół rozproszonej sieci Instant Message (podobnie jak email użytkownik mający konto na serwerze X nie ma problemów z komunikacją z użytkownikiem z serwera Y (są nawet bramki do innych usług IM, takich jak GG, ICQ, ...); a nie jak dzieje się w komunikatorach tylko z użytkownikiem swojej sieci).

W JEP-0111: TINS określona jest procedura inicjalizowania połączenia SIP (celem przeprowadzenia rozmowy głosowej itp). Dalszą obsługą połączenia zajmuje się już SIP. Istnieje także prawdziwie jabberowska odmiana usług VoIP (a raczej ogólnie usług P2P) - Jingle.

Protokół jabbera posiada wiele interesujących cech takich jak: filtrowanie wiadomości po stronie serwera (privacy list stanowiące część XMPP), forwardowanie, potwierdzanie dostarczenia, auto-odpowiadanie itp. (Advanced Message Processing, JEP-0079), wieloadresowanie (pola cc, bcc; Extended Stanza Addressing, JEP-0033), archiwizacja wiadomości po stronie serwera (Message Archiving, JEP-0136), sprawdzanie wiadomości w trybie off-line (Flexible Offline Message Retrieval, JEP-0013). Niestety często dużo gorzej jest z implementacją - zarówno w serwerach jak i klientach (jeżeli problem jest w kliencie zawsze pozostaje konsola XML, w ten sposób na wielu serwerach już dziś można używać filtrowania - ochrona prywatności w XMPP), w wielu wypadkach mamy tez doczynienia z niestandardową implementacją jakiś usług w klientach (głównie transfer plików i VoIP). Jednak daje się zauważać jakiś postęp w tej dziedzinie - np. zarówno serwer ejabberd, jak i klient Psi posiadają w głównej gałęzi wspomniane filtrowanie (po zmianie w listach - zwłaszcza usunięciu blokady warto się przelogować). Psi (wersja 0.11) posiada także (nie uaktywnioną jeszcze - ma by6ć w 0.12) obsługę komunikacji głosowej jingle, a ejabberd (jako dodatkowe moduły) m.in. archiwizację wiadomości po stronie serwera.

Gorzej jest natomiast gdy funkcjonalności brakuje na serwerze ... dla mnie osobiście największe braki w obecnej wersji jabberd2 od strony obsługi protokołu to: brak możliwości przechowywania wiadomości na serwerze (tak jak ma to miejsce w przypadku IMAPu), brak możliwości konfigurowania przekierowań, bardziej zaawansowanych autodpowiedzi (w jabberd 1.4 był jabber:iq:filter teraz jest tylko http://jabber.org/protocol/vacation), brak wieloadresowania; natomiast od strony konfiguracji serwera to: tworzenie v-hostów oraz aliasów (tak jak ma to miejsce np. w sendmail'owskim /etc/mail/virtusertable), udostępnianie pewnych usług tylko "swoim" użytkownikom (np. prawa do zakładania pokoi w ogólnie dostępnym MUC), przechowywanie danych użytkownika w $HOME. Parę rozwiązań tego typu problemów umieściłem w dziale związanym z programowaniem.

telnet

Telenet jest usługą internetowa pozwalająca na zdalne logowanie się na serwer i zdalną pracę. Hasło przesyłane jest jednak otwartym tekstem co nie jest bezpieczne i dlatego też usługa ta jest bardzo rzadko używana.
Najbardziej przyjemną cechą telnetu (zasadniczo to jego klientów, a nie samego protokołu) jest możliwość tekstowej komunikacji z innymi usługami (działającymi na innych portach i korzystających z innych protokołów), np: WWW, Jabber. Co jest ważną opcją diagnostyczną.

FTP

Protokół Transmisji Plików (File Transfer Protocol) - jest to usługa internetowa pozwalająca na transfer plików z serwera do komputera i z komputera na serwer. Usługa zasadniczo wymaga autoryzacji, często spotykana jest w wariancie dostępu anonimowego uprawniającego tylko do pobierania plików przez ten protokół, podobnie jak w telnecie hasło wysyłane jest jawnym tekstem. Obecnie coraz częściej wypierany przez SFTP/SCP (z dostępu autoryzowanego) i HTTP (z dostępu nieautoryzowanego).

SMB (samba)

Usługa wykorzystywana w sieciach lokalnych, przeznaczona głównie dla komputerów działających pod kontrolą Windows (taki substytut NFS - sieciowego systemu plików znanego z Unixów / Linuxa), pozwalająca na udostępnianie zasobów dyskowych i drukarek w sieci lokalnej.

Inne usługi: finger, identd, daytime, time, ...

Usługi te (w dużej mierze obsługiwane przez inetd) obecnie praktycznie nie są już używane (ale np. finger na ogół jest dostępny lokalnie) służyły one (w czasach otwartego internetu) podawaniu informacji o maszynie i jej użytkownikach, a także celom diagnostycznym (echo, chargen), były również przodkami usług obecnie powszechnie używanych (gopher -> WWW, talk -> IM, rlogin, rsh -> SSH). Wspomniany inetd / xinetd często odpowiada też za usługi dostępu do poczty, telnet i FTP.

Linki

Zobacz w Wikipedii: Linux, URL_(informatyka), URN

Zobacz w Sieci: Voice Over Internet Protocol Guru, iPBX, Usługi telekomunikacyjne przez Internet, Siproxd, Asterisk, SIP Express Router

Lista ważniejszych programów "komunikacyjnych"

Programy komunikacyjne

Należy tu chyba zacząć od przeglądarek internetowych - są to programy umożliwiające przede wszystkim oglądanie stron WWW (dokumentów opisanych w HTML'u i przesyłanych poprzez protokoły HTTP i HTTPS), jednak obecnie pełnią więcej funkcji z których przede wszystkim trzeba wspomnieć o obsłudze protokołu FTP. W śród nich również znajdziemy programy działające w trybie tekstowym (choćby słynny Lynx czy W3M), jak i w trybie graficznym - Mozilla i jej odmiany, Konqueror.

Następną grupą programów komunikacyjnych są klienci poczty elektronicznej oraz grup dyskusyjnych (często ta funkcjonalność jest połączona w jednym programie), należy tutaj wspomnieć o tekstowym pine oraz graficznych klientach. Należy też pamiętać o programach nie będących typowymi klientami ale pomagającym nam w obsłudze poczty takich jak filtr pocztowy (procmail), narzędzie do przetwarzania nagłówków (formail, będący częścią procmail'a) i podbieracz poczty (fechmail).

Kolejną ważną grupą są klienci takich usług jak telnet, ftp, ssh, scp, sftp, ..., są to najczęściej programy trybu tekstowego o takich właśnie nazwach, jak również klienci graficznie (głównie usług FTP podobnych).

Wspomnieć należy jeszcze o coraz popularniejszych klientach sieci IM, umożliwiających powiadamianie o obecności w sieci, natychmiastowy przesył wiadomości, przesył plików i rozmowy głosowe (skupie się na otwartej i zdecentralizowanej sieci Jabbera), wśród klientów należy wymienić Psi, Exodus oraz tekstowy imcom (stworzony w Perlu) i centericq (obsługujący również inne sieci IM).

Omawianie programów komunikacyjnych zakończyć należy na klientach p2p (sieci bezpośredniej wymiany plików), klientach protokółu VoIP oraz programach obsługujących fax-modem (faxowanie, telefonowanie, aparat zgłoszeniowy, ...) i kartę radiowo-telewizyjną.

Konqueror - graficzna przeglądarka z KDE
Mozilla Firefox - graficzna przeglądarka WWW, ... (przeglądarka posiada możliwość instalacji licznych rozszerzeń - np. VideoDownloader ułatwiający wyciąganie nagrań wideo z odtwarzaczy flash)
Lynx - tekstowa przeglądarka WWW
W3M - tekstowa przeglądarka z wsparciem tabelek, obrazków, ...
HTTrack - przeglądarka off-line (tworzenie mirrorów serwisów WWW, przy pobieraniu w sieci LAN czy też z lokalnego komputera warto w nowszych wersjach zwrócić uwagę na przełącznik -%! oraz odpowiednio duży parametr zadawany przez -A)
wget - pobieranie stron WWW i plików z sieci Web (HTTP, FTP)
KMail - graficzny klient e-mail z KDE
Mozilla Thunderbird - graficzna klient poczty ...
Sylpheed i Sylpheed-Claws - graficzne klienty e-mail
mutt - tekstowy klient e-mail
mailutils, mailx - wysyłanie/obsługa poczty elektronicznej z linii poleceń (komenda mail)
sendEmail - wysyłanie e-maili z załącznikami z linii poleceń
Procmail - przetwarzanie skrzynek pocztowych
Fetchmil - program do odbierania poczty przez POP, IMAP, ...
Knode - graficzny klient nntp dla KDE
Konversation - graficzny klient irc z KDE
Akregator - graficzny klient RSS z KDE
Psi - klient IM "Jabber" (patch mojego autorstwa pozwalający na zalogowanie bez podpisywania statusu, szczegóły)
Exodus
imcom
centericq - działający w trybie tekstowym komunikator IM obsługujący wiele protokołów w tym Jabbera
ekiga (gnomemeeting) - komunikator VoIP z obsługą SIP oraz H.323
kphone - komunikator VoIP z obsługą SIP
linphone - komunikator VoIP
Twinkle - telefon VoIP (SIP)
I Hear U - telefon VoIP (SIP)
OpenSSH - ssh, scp, sftp
VLC media player - sieciowy odtwarzacz multimediów

Serwery

Są to programy pracujące w trybie ciągłym i obsługujące nadchodzące (lub zaplanowane) żądania. Do najważniejszych należą serwery usług sieciowych takie jak poczty (sendmail, ...), WWW (Apache, ...), IMAP, Jabber, FTP, SSH, ... oraz wielu usług (xinetd), systemów baz danych (MySQL, PostgreSQL) . Swoistym serwerem jest też systemowy corn realizujący zaplanowane zadania w zadanym czasie. Więcej na ten temat w osobnym artykule poświęconym stawianiu serwera sieciowego.

Apache (warto zwrócić uwagę na wiele interesujących modułów)
UW-imap - serwer POP i IMAP
Dovecot - serwer IMAP i POP
Sendmail
OpenSSH
jabberd i jabberd2 - serwer sieci IM: Jabber
MySQL
PostgreSQL
Xinetd
NTP - synchronizacja czasu ...
UDPcast - multicastowy serwer plików
Flumotion - serwer strumieniowy
icecast - serwer radia internetowego
Asterisk - centralka telefoniczna (DialogPalette - system IVR)
FreeSWITCH, SipX, CallWeaver (OpenPBX, fork Asteriska) - serwery SIP, centralki telefoniczne, konkurencyjne wobec Asteriska
phpMyAdmin - webowy interfejs administracyjny PostgreSQL
phpPgAdmin - webowy interfejs administracyjny MySQL
phpBB - forum dyskusyjne (warto zwrócić uwagę na wiele interesujących modów)
SquirrelMail - bramka mailowa (warto zwrócić uwagę na wiele interesujących modów)
openwebmail - inna bramka mailowa
Webmnin - administracja przez WWW
Usermin - zarządzanie kontem (hasło, forward, procmail, ...) przez WWW
phpWebFileManager - menager plików przez WWW

O konfiguracji usług sieciowych w zakresie ustawień użytkownika

poczta (~/.forward, vacation, procmail, fetchmail)

Plik .forward (jest to standardowa ścieżka do tego pliku) umieszczany w katalogu domowym pozwala na przekazywanie poczty na inny adres (adres w pełnej postaci (z @), nazwa lokalnego użytkownika, aby dostarczyć bezpośrednio do skrzynki (z pominięciem forward'ów) należy adres poprzedzić znakiem \), na kilka adresów (oddzielamy je przecinkiem) oraz do innych programów ("|polecenie").

Program procmail pozwala na sortowanie, filtrowanie, przesyłanie, automatyczne odpowiadanie na pocztę, pocztę do niego można przekazać przez plik .forward może też być automatycznie dostarczana przez systemowy MTA. Plikiem konfiguracyjnym tego programu zazwyczaj jest .procmailrc. Każda reguła zapisana w tym pliku składa się z kilku linii, zaczyna się od linii postaci: :0 [flagi] [:[plik-blokujący]], do ważniejszych flag należy zaliczyć A - wykonanie reguły zależne od warunku z poprzedniej reguły i c - wykonanie kopii wiadomości, po linii tej następują linie warunków (jeden warunek w linii zaczynającej się od *, opcjonalnie można pominąć linię z warunkiem) a po nich następuje linia zawierająca akcję (linia taka w jednej regule może być tylko jedna !); reguły możemy zagnieżdżać przy pomocy nawiasów klamrowych { i } (po nawiasie otwierającym musi wystąpić spacja tabulator lub nowa linia). Zobacz także: man 1 procmail, man 5 procmailrc, man 5 procmailex

# przykładowy plik .procmailrc
# test zaczynający się od znaku # to komentarz i jest on ignorowany przez procmail

# gdy nie ma w naglowku pola "X-Envelope-To:" to dodaje pole i przekazuje do ponownie  procmaila
# jako wartość pola (zmienna $dla) ustawiany jest pierwszy ($1) argument przekazany do procmaila'
# przy wywolaniu go z pliku jako lokalnego agenta dostarczania z pliku sendmail.cf - makro $h
#
# będzie on ustawiony na user1@domena gdy przy przekazywaniu poczty z tego adresu
# do rzeczywistego użytkownika - user (pliki aliases, virtusertable i .forward)
# podane będzie przekazanie do user+"user1@domena"
# (znaki "" służą do zabezpieczneia symbolu @ i będą w zmiennej wynikowej)
# zamiast adresu user1@domena można podawac dowolny inny tekst
dla=$1
:0
*!X-Envelope-To:
| formail -i "X-Envelope-To: "$dla |procmail

# pocztę adresowaną (opisywane wyżej pole X-Envelope-To:)
# do user1@domena1 umieszczam w skrzynce (pliku) mail/skrzynka1
:0
*X-Envelope-To: "user1@domena1"
mail/skrzynka1

# poczte mającą w temacie "wazne" przesyłam na swoje drugie konto (login@domena.drugiego.konta)
# i do programu vacation aby odpowiedzial na list
# jest to jedno z możliwych rozwiązań - najbardziej logiczne
:0
* ^Subject:.*wazne
{
	:0 c
	! login@domena.drugiego.konta

	:0
	|vacation
}

# na poczte od konto@jakas.domena odrazu odpowiadam
# (wysylajac zawartosc pliku odpowiedz.txt) i jej nie zapisuje
:0
* ^From:.*konto@jakas.domena
| (formail -r ; cat odpowiedz.txt) | $SENDMAIL -oi -t

Program vacation pozwala na proste automatyczne generowanie odpowiedzi, pocztę do programu tego przekazujemy z pliku .forward (warto pamiętać o bezpośrednim przekazaniu listu do swojej skrzynki). Wiadomość zwracana przez ten program przechowywana jest w pliku .vacation.msg, plik ten rozpoczynać się może od pól nagłówków (takich jak Subject: (zawierającego tytuł), From: (zawierającego adres nadawcy, przy braku tego pola zostanie ono wygenerowane automatycznie), Reply-To: (informującego o tym gdzie należy wysłać odpowiedź), w treści tego pliku można także skorzystać ze zmiennej $SUBJECT wstawiającej tytuł wiadomości, na którą generowana jest odpowiedź. Przydatnymi opcjami programu są -j nakazująca odpowiadać m.in. na przeforwardowane wiadomości (nie sprawdza pola To: ani Cc:) oraz opcja -t[N] nakazująca wysyłanie tylko jednego powiadomienia na dany adres w ciągu N dni (aby wyczyścić bazę tych adresów należy wywołać vacation -I). Uwaga na wywołanie samego vacation otwiera ono edycję pliku .vacation.msg i zmienia plik .forward, zapisując starą wersję jako .forward.old. Zobacz także: man 1 vacation

Program fetchmail pozwala na pobieranie (zarówno automatyczne jak i ręczne) poczty z zdalnych serwerów i umieszcza je w skrzynce systemowej (działa tak jak forward z komputera z którego pobiera pocztę). Plikiem konfiguracyjnym tego programu zazwyczaj jest .fetchmailrc, plik ten zawiera konfiguracje kont pocztowych wraz z nazwami użytkowników i hasłami (one są opcjonalne przy uruchamianiu manualnym, ale ze względu na to prawa do pliku muszą przysługiwać tylko właścicielowi) podstawowy wpis składa się z pozycji: poll "nazwa serwera" username "użytkownik" password "hasło", dodanie opcji keep powoduje pozostawienie wiadomości na serwerze. Opcja -d 600 -N pozwala na uruchomienie programu w trybie pracy ciągłej gdzie sprawdzanie poczty odbywa się co 600 sekund, opcja -f pozwala określić alternatywny plik konfiguracyjny i przydaje się, gdy trzeba wykonać jakieś jednorazowe sprawdzenie, a fetchmail działa w trybie pracy ciągłej. Jeżeli jest to możliwe, zawsze należy używać forward'u zamiast fetchmail'a. Jeżeli zachodzi potrzeba rzadszego uruchamiania fetchmail'a (np. kilka razy na dobę), to warto rozważyć skorzystanie z systemowego mechanizmu corn, pozwalającego na uruchamianie programów o zadanej porze, w tym celu należy uruchomić crontab nazwa-pliku aby utworzyć wpis z podanego pliku, każda linia pliku powinna wyglądać następująco: minuta godzina dzień miesiąc dzień tygodnia komenda (przy czym dzień tygodnia - liczba od 0 (niedziela) do 6 (sobota) a także każdy z parametrów można zastąpić gwiazdką co oznacza że dla każdej wartości tego parametru będzie następowało uruchomienie. Zobacz także: man 1 fetchmail

ssh, scp, sftp

Składnia poleceń SSH:
ssh użytkownik@serwer (następnie akceptujemy klucz kodowania (przy pierwszym połączeniu) i podajemy hasło) lub ssh serwer (następnie podajemy nazwę użytkownika, akceptujemy klucz kodowania (przy pierwszym połączeniu) i podajemy hasło)
scp ścieżka-źródła ścieżka-celu lub scp -r ścieżka-źródła ścieżka-celu (pozwala na rekurencyjne kopiowanie katalogów), gdzie ścieżka oznacza ścieżkę lokalną lub użytkownik@serwer: ścieżka-na-serwerze (następnie również akceptujemy klucz kodowania (przy pierwszym połączeniu) i podajemy hasło)
sftp

Przy pomocy ssh (bez scp) tez da się przesyłać pliki (w przypadku dużej ilości plików jest to metoda wydajniejsza, którą możemy także łatwo wzbogacić o kompresję):

na host zdalny: tar cf - pliki do przeslania | ssh user@host 'cd katalog/docelowy; tar xf -'
z hosta zdalnego: ssh user@host 'cd katalog/docelowy; tar cf - pliki do przeslania' | tar xf -

W ~/.ssh/config możemy definiować skrócone nazwy dla hostów wraz z określeniem opcji używanych przy logowaniu (np. port, użytkownik). Ponadto nazwy hostów podane w tym pliku będą rozwijane w ramach pakietu "bash_completion" poprzez tab. Dodanie do tego pliku HashKnownHosts no powoduje że nazwy hostów w ~/.ssh/known_hosts będą zapisywane w sposób jawny i również będą autouzupełniane przez "bash_completion".

W przypadku systemów Windows konieczna jest instalacja programów "Putty" (do połączeń SSH, tekstowe programy scp, sftp dostarczane z Putty noszą nazwy pscp i psftp) i/lub WinSCP (graficzny interfejs do SCP) i/lub "ssh secure shell client" (terminal SSH i graficzny interfejs do SFTP). Zobacz w Sieci: SSH.

Generowanie kluczy SSH

SSH umożliwia także opcję nawiązywania połączeń bez potrzeby podawania hasła - wykozystuje się do tego klucze asymetryczne. Aby je wygenerować korzystamy z komendy ssh-keygen -t rsa (możemy także wybrać inny typ klucza - dsa), jeżeli zależy nam na uniknięciu podawania hasła generujemy klucze niezabezpieczone hasłem (bezpieczniej jest używać kluczy z hasłem i ssh-agent aby podawać je tylko raz ...). Wygenerowane klucze znajdą się w ~/.ssh/id_rsa - prywatny, ~/.ssh/id_rsa.pub - publiczny. Klucz publiczny należy przekopiować na komputer z którym chcemy się łączyć (np[. przy pomocy scp) i dopisać do ~/.ssh/authorized_keys - cat id_rsa.pub >> ~/.ssh/authorized_keys.

Montowanie SFTP jako systemu plików

Możliwe jest montowanie zdalnych zasobów SFTP jako lokalnego systemu plików. Wymaga to zainstalowania pakietu z sshfs oraz załadowania modułu fuse (mechanizm fs opartego na fuse zastąpił opisywany tu niegdyś shfs stanowiący moduł jądra). Montowanie wykonujemy przy pomocy polecenia sshfs -o workaround=rename serwer:katalog punkt_montowania (dość istotna jest opcja "workaround=rename" umożliwiająca przenoszenie plików na takim systemie). Oczywiście użytkownik wykonujący to polecenie musi mieć prawa do /dev/fuse (należeć do grupy fuse). Warto na koniec też zwrócić uwagę iż możliwe jest korzystanie z standardowych kluczy generowanych przez ssh-keygen (i umieszczanych w $HOME/.ssh/ jako: authorized_keys , id_rsa , id_rsa.pub).

W przypadku KDE możliwe jest też korzystanie z zasobów SFTP bez ich montowania - wystarczy w Konqueror'ze wpisać sftp://uzytkownik@nazwa.serwera .

Tunelowanie SSH

Możliwości SSH nie kończą się na udostępnieniu zdalnego shella i możliwości bezpiecznego przesyłu plików, umożliwia on także zdalny dostęp do programów działających w trybie graficznym. Wymaga to jednak włączenia opcji przekazywania protokołu X'ów (w przypadku ssh z linii poleceń opcja -X) oraz działającego na maszynie z której się łączymy serwera X'ów (na maszynie docelowej takiego serwera może nie być w ogóle - musza być tylko stosowne biblioteki oraz program który chcemy odpalić). Po uzyskaniu połączenia shellowego z włączoną opcją przekazywania X'ów programy graficzne odpala się tak jak każdy inny program.

SSH umożliwia także tworzenie tuneli przekierowujących połączenia TCP na zadany port komputera z którego wykonujemy połączenie ssh do określonego adresu IP (wraz z portem) dostępnego z maszyny (serwera ssh) do której się łączymy (może być to np. prywatny adres IP dostępny tylko wewnątrz LANu): ssh -L lokalny_port:mapowany_adres_ip:mapowany_port uzytkownik@serwer_ssh. Możliwe jest też tunelowanie w drugą stronę (ssh -R mapowany_port_serwera:adres_ip:port uzytkownik@serwer_ssh) co umożliwia utworzenie (na serwerze ssh) portu nasłuchujacego który umożliwi połączenie do komputera (z którego zestawiony został tunel) do którego może nie być bezpośredniego dostępu (np. za firewallem); należy tutaj zaznaczyć iż domyślnie nasłuchiwanie na zadanym porcie odbywa się tylko lokalnie aby to zmienić należy przed tym portem określić adres nasłuchiwania (lub * dla wszystkich), aby było to skuteczne musi być włączona w konfiguracji serwera opcja "GatewayPorts". Umożliwia to także proste tworzenie swego rodzaju sieci VPN o bardzo dobrym zabezpieczeniu.

Zobacz w Sieci: Tunelowanie połaczeń po SSH, Cygwin/X czyli Linux na Windowsie !?.

Szyfrowanie

Przesyłanie danych przez Internet pod względem ich bezpieczeństwa przypomina przesyłanie ich przy pomocy kartek pocztowych - każda osoba (serwer/router) pośrednicząca w przekazywaniu może podejrzeć zawartość, ale zrobić to może także osoba będąca dostatecznie blisko i posiadająca np. lornetkę. Dlatego przy poufnych danych stosuje się ich szyfrowanie. Kolejną kwestia jest łatwość zmiany danych będących w postaci cyfrowej tudzież wyparcia się ich autentyczności/autorstwa - stąd bardzo pokrewna szyfrowaniu technika podpisu cyfrowego. Zobacz także skrypt eksportujący dane kryptograficzne (i nie tylko) - commons-config.sh

OpenPGP/GnuPG

Do szyfrowania oraz podpisywania danych możemy skorzystać GnuPG.

Aby wygenerować klucze uruchamiamy gpg --gen-key, aby dodać dodatkowy identyfikator do naszego klucza (przydatne gdy chcemy nim podpisywać np. maile wysyłane z różnych adresów uruchamiamy gpg --edit-key podany.przy.generacji@email.identyfikujacy.klucz i w uzyskanej linii polecen wydajemy adduid.

Aby wyeksportować nasz klucz publiczny używamy komendy gpg --armour --output publiczny.gpg --export podany.przy.generacji@email.identyfikujacy.klucz, aby zaimportować czyjść klucz gpg --import publicznykolegi.gpg. Możemy także uzyskać bardzo streszczony klucz publiczny (pozbawiony wszelkiich podpisów innych osób) - w tym celu nalezy wygenerować go na podstawie klucza prywatnego w następujący sposób:

	mkdir gpg-export-tmp-dir
	chmod 700 gpg-export-tmp-dir
	gpg -a --export-secret-keys > gpg-export-tmp-dir/sec.asc
	gpg --homedir gpg-export-tmp-dir --import gpg-export-tmp-dir/sec.asc
	gpg --homedir gpg-export-tmp-dir -a --export > public.asc
	rm -fr gpg-export-tmp-dir

Aby zaszyfrować dane wysyłane do kogoś jego kluczem publicznym: gpg --output plik_wyjsciowy --encrypt --recipient identyfikator@email.odbiorcy plik_wejsciowy, aby odszyfrować odebrane dane szyfrowane naszym kluczem publicznym: gpg --output plik_wyjsciowy --decrypt plik_wejsciowy. Gdy dysponujemy zestawem klucza publicznego i prywatnego w formacie binarnym możemy to uczynić także bez importowania tych kluczy: gpg --keyring klucz_publiczny --secret-keyring klucz_prywatny --decrypt wiadomosc_do_odszyfrowania. Jeżeli chcemy odszyfrować dane mając klucz prywatny w postaci ASCII nie obędzie się bez jego zaimportowania, można to jednak zrobić do tymczasowego pliku:

	mkdir gpg-decrypt-tmp-dir
	chmod 700 gpg-decrypt-tmp-dir
	gpg --homedir gpg-decrypt-tmp-dir --import secret.asc
	gpg --homedir gpg-decrypt-tmp-dir --decrypt zaszyfrowany.txt > odszyfrowany.txt
	rm -fr gpg-decrypt-tmp-dir

Aby wygenerować podpis do wiadomości: gpg --output wygenerowany_podpis.sig --detach-sig plik_wejsciowy.

Zobacz też: Podpis cyfrowy, Architektura klucza publicznego w Gnu Privacy Guard (GPG), oraz klucze ssh, VPN.

certyfikaty x509

Do szyfrowania i podpisywania możemy korzystać także z z certyfikatów takich jak wykorzystywane w połączeniach SSL. Istnieje kilka dróg generowania certyfikatów i kluczy tego typu. Możemy to zrobić np. w następujący sposób: openssl req -new -x509 -days 4095 -newkey rsa:2048 -keyout ca_key.pem -out ca_cert.pem, wygenerowany zostanie certyfikat podpisany przez samego siebie (opcja -x509), jeżeli dodana byłaby opcja -nodes klucz prywatny nie byłby zabezpieczony hasłem (jest to przydatne przy generowaniu certyfikatów dla serwerów - szyfrowanie www, poczty itp.).

Wygenerowany w sposób opisany powyżej zestaw certyfikatu i klucza możemy używać od razu do szyfrowania bądź do podpisywania próśb o certyfikat generowanych komendą: openssl req -new -keyout server.key -out server.key (UWAGA: w przypadku certyfikatów dla serwerów w "COMMON NAME" nazwa domeny dla której jest certyfikat, można użyć *.domena aby pasował do wszystkich hostów w domenie). Prośbę taką możemy przekazać do podpisu jakiemuś prawdziwemu CA lub podpisać sobie sami (wygenerowanym wcześniej kluczem): openssl x509 -req -out server.crt -in server.key -CA ca_cert.pem -CAkey ca_key.pem -CAcreateserial -days 365. Na koniec możemy usunąć hasło z klucza prywatnego (przydatne dla serwerów): openssl rsa -in server.key -out server.key.

Na potrzeby wielu programów konieczne będzie wyeksportowanie zestawu klucza i certyfikatu do formatu PKCS#12 - openssl pkcs12 -export -in cert1_cert.pem -inkey cert1_key.pem -out cert1.p12. Klucz taki możemy zaimportować np. do gpgsm - gpgsm --import cert1.p12 (wcześniej odpalamy gpg-agent --daemon i eksportujemy tak jak sugeruje GPG_AGENT_INFO). Pozwoli to na włączenie funkcjonalności S/MIME w kmail'u (wymagane pakiety gpgsm i kleopatra), w tym celu należy ponadto zaimportować certyfikaty CA - gpgsm --import /etc/ssl/certs/ca-certificates.crt i zakwalifikować wszystkie te (nasz i CA) certyfikaty jako zaufane - gpgsm -k | grep fingerprint | while read tmp fpr; do echo "$fpr S relax"; done > ~/.gnupg/trustlist.txt

Zobacz też: S/MIME, S/MIME (certyfikaty cyfrowe, identyfikatory cyfrowe)

Konfiguracja serwerów sieciowych

Zawsze w przypadku instalowania i konfiguracji jakiejś usługi należy zapoznać się i ewentualnie poprawić plik konfiguracyjny (domyślne ustawienia najczęściej są OK, ale też prawie zawsze trzeba coś dostosować ...). Dalej przedstawię kilka uwag odnośnie konfiguracji niektórych z ważniejszych usług. Do najistotniejszych usług zaliczyłbym (w nawiasie przykładowe programy będące serwerem danej usługi): SSH/SCP/SFTP (sshd), DNS (bind), pocztę (exim), WWW (apache); warto też znaleźć miejsce na bramkę mail-www (squirrelmail), system bazodanowy (mysql) oraz webowy interfejs jego obsługi (phpmyadmin). Bardzo istotną kwestią jest także routing i podział łącza.

Niestety konfiguracja wielu (zwłaszcza tych młodszych) usług nie sprowadza się wyłącznie do przygotowania plików konfiguracyjnych - często zachodzi potrzeba przygotowania własnej kompilacji programu (z nałożonymi odpowiednimi łatkami) - ma to miejsce m.in. w przypadku ejabberd'a czy squirrelmail'a (szczegóły poniżej). Problemy nastręczają także próby utrzymania wspólnej bazy użytkowników dla wszystkich usług (konta shell, poczta, www, jabber, sip); niestety dodatkowo wiele z bardziej współczesnych programów ignoruje tradycyjny unixowy charakter kont (jedno konto w systemie, tradycyjne aliasy pocztowe, konfiguracja przechowywana w $HOME, ...) - zobacz poniżej informacje o zmaganiach z konfiguracją ejabberd'a i asterisk'a. W przypadku serwerów wielo-użytkownikowych dochodzi jeszcze problem przekazania maksymalnej kontroli nad konfiguracją swoich usług w ręce użytkowników (zobacz poniżej), ewentualnie jakiś panel przez nich zarządzany. Kolejnym problemem jest często obsługa vhostów i aliasingu domen (na serwerze konta kilku firm, i niektóre z nich chcą jeszcze aby wszystko było widoczne w obu ich domenach).

Generalnie w usługach serwerowych podobnie jak i w budowie sieci można wyróżnić kilka skal wielkości:

siec wewnętrzna (firmowa, mieszkaniowa) - dystrybucja głównie pozioma, brak konieczności przekazywania dużej władzy w ręce poszczególnych użytkowników, rzadko kiedy potrzebne silne rozróżnienie usług w oparciu o nazwy domen (vhosty)
siec budynkowa (w pojedynczym budynku mieszkalnym lub biurowym, ewentualnie niewielkiej grupie takich budynków) - dystrybucja najczęściej doprowadzająca sygnał do lokalu/biura, w dużej mierze pionowa, warto przekazywać dużą kontrolę nad usługami serwerowymi użytkownikom, na ogół konieczne rozbudowane vhosty
siec osiedlowa - dystrybucja pozioma (pomiędzy budynkami) i pionowa (w ramach budynków), usług serwerowych brak lub ograniczony ich zakres lub sytuacja jak w sieci budynkowej
duży ISP - dystrybucja pozioma na dużych obszarach, usług serwerowych brak lub ograniczony ich zakres, rzadko rozwinięte vhosty, częściej serwering dedykowany

Na wstępie przedstawię też przykład organizacji kont w sieci kamienicznej (jest to chyba najtrudniejszy organizacyjnie przypadek):

grupy tworzone w oparciu o lokale - nazwa, oraz GID w jakiś sposób zgodna z numeracja lokali (np. dla lokalu nr. 23A - nazwa "23a", GUID 123+1000 = 1123, dla lokalu 23 "23" i 23+1000=1023)
numeracja (klas) ip zgodna w jakiś sposób zgodna z numeracja grup (np. GID - 1000)
konta umieszczane w grupach wg lokalu do którego przypisywany użytkownik
nazwa konta odpowiada najkrótszemu aliasowi
numeracja telefoniczna (podstawowe konto) tworzone w oparciu o UID posiadacza (prefix + UID - 1000)
do konta 3 niezależne konfiguracje aliasów (mail, jabber, voip)
warto tworzyć aliasy SIP generowane w oparciu o numer lokalu, przypisane do konta (podstawowego numeru) głównego użytkownika i dzwoniące na wszystkie telefony w lokalu (odpowiednie wywołanie Macro(call_user|konto_glowne|telefony) z moich przykładów konfiguracji asteriska)

SerwerConfigSwitch

Zamieszczam tutaj archiwum z moim systemem zarządzania konfiguracją serwerów (z archiwum po rozpakowaniu można wygenerować paczkę deb wchodząc do rozpakowanego katalogu i wydając komendę dpkg-buildpackage -rfakeroot). System dostepny jest także do przeglądania w postaci rozpakowanej oraz do pobrania w postaci gotowej paczki dla Debiana. Szczególnej uwadze polecam zagadnienia opisane poniżej (często linkują one do wybranych plików z systemu) oraz główny skrypt systemu SerwerConfigSwitch.sh.

dns

W przypadku DNSu warto zwrócić możliwość na wykorzystanie * oznaczającej dowolną nazwę hosta (np. *.moja.domena.pl oznacza wszystkie adresy postaci ciag_znakow_bez-kropki.moja.domena.pl), podobnie możemy uczynić z konfiguracją webserwera (serwer wirtualny z wpisem "ServerAlias *.moja.domena.pl" będzie obsługiwał wszystkie te odwołania (dalej możemy użyć mechanizmów różnicowania położenia katalogu głównego w zależności od tego co jest podane zamiast kropki).

Kolejną rzeczą o której warto wspomnieć jest konfiguracja DNS w bind9 dla IPv6. W /etc/bind/named.conf.options dodać należy listen-on-v6 { any; }; (wewnątrz options { ... }). Możemy także konfigurować domeny na adresach IPv6 poprzez dodanie w pliku naszej strefy wpisu z typem AAAA. Odwrotny DNS konfigurujemy podobnie jak dla IPv4 - poprzez utworzenie wpisu dla domeny {nasz prefix pisany od tyłu po każdej cyfrze szesnastkowej stawiamy kropkę}.ip6.arpawraz z wpisami dla hostów - tutaj w rekordach PTR piszemy jako nazwę domeny część odpowiedzialną za adres hosta, również od tyłu i z kropką po każdej cyfrze szesnastkowej.

Niekiedy mogą wystąpić problemy z zatrzymywaniem/restartowaniem binda, może to być spowodowane błędem w kluczy (lub haśle do niego) który autoryzuje komunikację binda i programu go nadzorującego. Należy wtedy przegenerować klucz (rndc-confgen -r /dev/urandom > /etc/bind/rndc.key) i dokonać stosowanych zmian w konfiguracji binda (hasło do klucza, ew. jego położenie).

poczta

Przy konfiguracji poczty warto zwrócić uwagę na możliwość zapewnienia jesj filtrowania, przechowywanie jej w katalogach użytkowników oraz umieszczanie nagłówka informującego o adresie koperty - w przypadku exima jest to dość proste do uzyskania, zwłaszcza to ostatnie, które jest robione automnatycznie. Do filtrowania można wykorzystywać np. "procmail". Może on wraz z skanerami clamscan, spamassassin posłuzyć do stworzenia systemu antywirusowego i antyspamowego (przykładowy plik konfiguracyjny filtra antywirusowego). Rozważyć należy również dodanie w głównym pliku ustawień poziomu logowania: VERBOSE=no i pliku logów LOGFILE=/var/log/procmail.log. Warto też rozważyć centralne uruchamianie uczenie antyspamu użytkowników korzystających z tego filtru - posłużyć do tego może następujący skrypt wykonywany przez crona - spam.sh (uwaga: aby skrypt był wykonywany przez crona konieczne może okazać się usuniecie z jego nazwy kropki). Należy jednak zwrócić uwagę na to iż filtry uczące się zaczynają działać dopiero po przeanalizowaniu 200 pozytywnych i 200 negatywnych przykładów ... (prezentowany skrypt uczy tylko negatywów), ustawienia te można zmienić w pliku konfiguracyjnym (więcej na jego temat w SpamAssassin - konfiguracja). Niekiedy (gdy filtr uczący się jest bardzo sprawny warto zwiększyć jego punktację (więcej o ustawianiu punktacji w SpamAssassin - testy).

Zamieszczam też dość bogato komentowany przykładowy plik konfiguracyjny exim'a, implementujący virusertable, obsługę procmaila, plików .forward, systemu vacation oraz tworzenie kopii odbieranej poczty po stronie serwera, a także ssl i autoryzację oraz graylisty (w oparciu o greylistd) i skanowanie antywirusowe i antyspamowe na etapie kopertowym. Zamieszcam także zmodyfikowaną wersję tego pliku - służy ona do wysyłania kopii wychodzącej poczty na zadany adres i korzysta z zewnętrznego serwera SMTP wymagającego autoryzacji. Konfiguracja exima pozwala na odrzucanie wiadomości z informacją o nowym adresie (błąd SMTP 551 User not local), poprzez umieszczenie w pliku aliasów wpisu ::fail: 551 User not local; please try <inny@example.org> niestety w przeciwieństwie do tego czego można by się spodziewać serwery pocztowe (w tym exim) nie rozróżniają tego od zwykłego błędu 550 i nie próbują przekazać poczty na wskazany adres, za to zwracają do adresata.

Ważne jest zapewnienie dostępu do poczty przechowywanej na serwerze - służą do tego protokoły POP i IMAP. Polecam serwer dovecot. przy jego konfiguracji warto zwrócić uwagę na uruchomienie SSL (nieszyfrowany dostęp z zewnątrz można zabronić poprzez zamknięcie portów nieszyfrowanych, a zostawienie szyfrowanych na firewallu i ustawieniu protocols = imap imaps pop3 pop3s w konfiguracji dovecot) a także na ustawienie nasłuchiwania na ipv6 listen = [::] (oczywiście nasłuchuje wtedy także po IPv4).

Popularnym i istotnym elementem systemów pocztowych jest bramka umożliwiająca dostęp do poczty poprzez WWW - np. Squirrel Mail. Większość takich systemów posiada dość rozbudowane opcje (konfiguracja tożsamości, książki adresowej, wersje robocze, ...), które mogą być powiększone przy pomocy dodatkowych modułów/patch'y. W przypadku wspomnianego już Squirrel Mail takie dodatki znaleźć możemy na http://www.squirrelmail.org/plugins.php, na szczególną uwagę zasługują: View As HTML, Advanced Settings (np. wyświetlanie folderów specjalnych na początku, domyślne używanie priorytetów wiadomości), S/MIME verification, Show Headers; a także: File Manager, Calendar File Backend, Notes, To-Do Reminder, NNTP webinterface, Bookmarks, Quick Save, Autocomplete, Custom From, Message Flags & Icons.

www

W konfiguracji Apacha osobiście polecałbym włączenie obsługi katalogów public_html oraz pełnej obsługi plików .htaccess, uwagę raziłbym zwrócić na ściezki gdzie zapisywane są logi - radze podawać od / i upewnić się że katalogi istnieją ... . Natomiast jeżeli występuje problem z starszymi klientami ssh (nieprzyjmowanie poprawnego hasła) to warto w konfiguracji tego serwera ustawić opcję "PasswordAuthentication yes". Jeżeli chcielibyśmy mieć wszystkie logowania ssh w pliku wtmp (wyświetlanym np. przez last) to należy zbudować odpowiedni moduł PAM (np. pam_sessionlog.so) i dodać w /etc/pam.d/ssh session required pam_sessionlog.so service=ssh (podobnie można uczynić z /etc/pam.d/su). Aby zbudować wymagany moduł PAM należy pobrać pakiet źródłowy pam, zastosować łatkę z pam_sessionlog.tgz a następnie zbudować pakiet binarny (skompliowac ...) i zainstalować go lub wypakować z niego stosowny plik i umieścić w /lib/security/ .

XMPP/Jabber

Ciekawą i interesującą usługą jest Instant Message, a konkretniej protokół XMPP. O protokole tym i jego bolączkach wieku dziecięcego wspomniałem już wcześniej. Najciekawszym w chwili obecnej serwerem tej usługi wydaje się być ejabberd. Polecam jednak nałożenie na ten serwer łatki umożliwiającej autoryzację przez PAM (ejabberd_auth_pam.diff, łatka w obecnej wersji zawiera już moją poprawkę do niej umożliwiającą sprawdzanie czy istnieje użytkownik w oparciu o /etc/passwd, nie jest to najlepsza droga, ale na ogół zupełnie wystarczająca a wymagane to jest do działania przechowywania wiadomości off-line).

Warto zainteresować się również mod_archive, dodającym implementację Message Archiving (XEP-0136), tutaj jeżeli zamienimy "groupchat" -> ignore ; na np. "XXXgroupchatXXX" -> ignore ;, możemy potestować archiwizację rozmów z MUC (nie działa ona idealnie, ale działa) w "ejabberd-modules" dostępna jest także wersja SQLowa tego modułu. Kolejnym ciekawym patchem jest mod_multicast implementujący wieloadresowanie Extended Stanza Addressing (XEP-0033). Zainteresować się można również patch'ami umożliwiającymi: dostęp do MUC przez IRC, zapis informacji użytkowników do HTML, logowanie pakietów jako XML, logowanie chatów jako tekst lub xml, filtrowanie dostępu.

Wiecej patchy znaleźć można na: ejabberd.im. Wiele z opisywanych łatek jest do pobrania poprzez: svn co https://svn.process-one.net/ejabberd-modules i budowane są one niezależnie od samego ejabberda. Jednak patche mojega autorstwa związane z aliasami JID ("ejabberd_log_offline_message.diff" i "ejabberd_alias_forward.diff") wymagają pobrania źródeł ejabberda (apt-get source ejabberd) zapatchowania go (cd ejabberd-*/src; patch -p0 < ../../ejabberd_*.diff) i zbudowania (./configure && make lub cd ..; dpkg-buildpackage -rfakeroot). Z koleji patch autoryzacji PAM - http://ejabberd.im/pam wraz z "ejabberd_alias_check.diff" może być zbudowany niezależnie poprzez rozpaczowanie systemu PAM do pustego katalogu i spatchowanie przez "ejabberd_alias_check.diff" - gcc -fpic -shared -lz -lerl_interface -lei -lpam -lpam_misc -o ejabberd_auth_pam.so ejabberd_auth_pam.c; erlc -W ejabberd_auth_pam.erl.

Polecam także mój system powiadomień XMPP/SMTP zawierający m.in. łatką "ejabberd_log_offline_message.diff" powodującą zapisywanie wiadomości trybu offline także do plików tekstowych, które wykorzystuje w moim systemie do przesyłania powiadomień o nowych IM na e-mail. Zachęcam także do zapoznania się z zestawem moich patch'y do serwera ejabberd implementujących JID aliases.

Innymi wartymi zainteresowania uzupełnieniami serwera xmpp są z pewnością: transport xmpp2xmpp (ułatwia on między innymi bycie on-line na kilku kontach równocześnie, korzystanie z adresu na innym serwerze i usług takich jak archiwizacja na innym - JID aliasing) oraz system prezentacji i zarządzania historią rozmów - Jorge.

Przy konfiguracji warto zwrócić uwagę na dostęp do MUC (polecam ustawienie umożliwiające udział każdemu a zakładanie tylko swoim - {mod_muc, [{access, muc}, {access_create, muc_create}, {access_admin, muc_admin}] } oraz uruchomienie słuchania na IPv6 - wpisy inet6 w konfiguracji portów nasłuchiwania np.: [{5222, ejabberd_c2s, [inet6, {access, c2s}, .....

Niekiedy (gdy za dużo napsujemy) mogą wystąpić problemy z startem ejabberd'a. Należy wtedy wyeksportować dane konfiguracyjne z jego bazy (ejabberdctl dump), zatrzymać ejabberda, usunąć /var/lib/ejabberd i po ponownym uruchomieniu ejabberda przywrócić z pliku tekstowego(ejabberdctl load). Można także bawić się z podmianą wybranych plików w tym katalogu, jest to przydatne tylko gdy nie możemy uruchomić ejabberd'a a nie posiadamy zrzutu - przenosimy wtedy ten katalog w inne miejsce, odpalamy ejabberda, zatrzymujemy go, pliki LATEST.LOG config.DCD local_config.DCD disco_publish.DAT z nowo utworzonego katalogu kopiujemy do starego, zastępujemy nim nowy i odpalamy ejabberda. Ta metoda w odróżnieniu od pierwszej regeneruje bazę jednorazowo, więc przy następnym starcie też będzie problem.

VoIP, SIP i Asterisk

Kolejną przydatną usługą są połączenia głosowe realizowane przez protokół IP. Jest to chyba najbardziej wymagająca dla tego protokołu usługa, gdyż wymaga ona bardzo małych opóźnień (dane spóźnione są bezużyteczne, a nie możemy też sobie pozwolić na duży bufor, gdyż usługa realizowana jest w czasie rzeczywistym). Jednak pomimo tych problemów telefonia IP (VoIP) ma liczne zalety - takie jak elastyczność, wysoka konfigurowalność i niskie koszta połączeń (nie jest potrzebny fizyczny kanał a tylko pasmo transmisji danych). Chyba najpopularniejszą softwarową centralką telefoniczną, obsługującą nie tylko VoIP ale także klasyczną telefonię jest Asterisk. Oprogramowanie to jest ponadto, w stanie rozwiązać problemy protokołu SIP z NATem (wystarczy żeby serwer asteriska miał IP z za NATu i publiczne). Prezentuję dwa najciekawszy w mojej opinii fragment konfiguracji Asteriska - konfigurację dialplanu czyli systemu numeracyjnego i sposobów zestawiania połączeń: extensions.conf (z obsługą przekierowań, blokad, systemu zarządzania kontem, zalążkiem systemu domofonowego, mechanizmem vhostów, wsparciem dla ENUM) oraz extensions-local.conf. Pozostałe ważniejsze pliki konfiguracyjne umieszczone są w archiwum systemem zarządzania konfiguracją serwerów.

Asterisk posiada także pewne wady. System momentami dość upierdliwy w konfiguracji - ze względu na pojecie zestawiania połączenia przez kanały i zmiennych przypisanych do kanału (jak się robi Dial(Local/...) to już ciężko nad tym zapanować, jak nie to i tak mamy co najmniej dwa kanały i tez to rodzi problemy ...). Trochę przyjemniejsze pisanie skomplikowanych funkcji dialplanu zapewnić mogą mechanizmy takie jak: AEL i AGI (najpewniej w drodze dalszego rozwoju - więcej usług typowych dla central cyfrowych, w tym kolejkowanie - prezentowane tutaj extensions.conf zostanie przeportowane z wykozystaniem tych mechanizmów). Ponadto standardowy Asterisk w chwili obecnej nie wspiera IPv6 oraz nie wspiera integracji z kontami shellowymi użytkowników.

Zobacz w Sieci: voip-info.

routing

Istotną funkcją w różnych systemach opartych o protokół IP jest routing. Cżesto jest on realizowany przez wyspecjalizowane urządzania (routery sprzętowe), ale równie często jego realizację przeprowadza się software'owo. Prezentuję tutaj kilka skryptów dokonujących konfiguracji takiej usługi w systemie Linux: routing.sh, routing.conf i routing_fun.sh odpowiedzialne za routing IPv4 i IPv6. Skrypty te wymagają pela wraz z NetAddr::IP::Util (pakiet libnetaddr-ip-perl w wersji conajmniej 4.007), a także pakietów iptables, iproute oraz jądra z obsługą iptables, ipv6, htb i innych (zalecana jest obsługa imq w trybie AB).

Pokazane w przykładowym pliku konfiguracyjnym markowanie pakietów (ustawianie numerycznych znaczników dostępnych tylko w ramach hosta routującego) możemy użyć nie tylko jak tam pokazano do tc filter czy iptables ale także do kierowania ruchu do różnych tablic routingu. Możemy wykorzystać do tego polecenie ip rule poprzez wykorzystanie selektora fwmark i celu table. Innymi ciekawymi selektorami są: tos (wybór w oparciu o pole TOS), from lub to (adres źródłowy lub docelowy), iif (interfejs z którego przyszedł pakiet), a z celów nat, reject. Różne tabele routingu możemy tworzyć poprzez ip route table NAZWA_TABELI, przy pomocy tego narzędzia możemy tworzyć zaawansowane mechanizmy routingu (routing lokalny, multicastowy, rozgłoszeniowy, ...). Z innych mniej znanych a ciekawych opcji komendy ip warto wspomnieć o: maddress, link, neighbour, tunel. Więcej szczegółów w man ip.

Warto zaznaczyć iż do przekierowywania usług/portów w moim zestawie konfiguracji wykorzystuje xinetd (zobacz konfigurację) a nie DNAT - co nie rodzi problemów z IPv6 oraz dwiema sieciami IP na jednym interfejsie Kolejnym popularnym zastosowaniem NATu jest chęć skierowania ruchu z jakiś adresów do danego hosta (wyświetlającego np. komunikat odnośnie przerwy w dostępie do Internetu). W przypadku IPv6, gdzie (na linuxie) nie mamy do dyspozycji NATu, możemy to zrobić modyfikując działanie DNS (odpalając sfałszowany DNS) tak aby na każde zapytanie odpowiadał adresem naszego hosta z komunikatem. Sam serwer DNS może identyfikować czy hosta należy przekierować czy nie lub możemy to oprzeć np. na różnych adresach DNS wysyłanych przez DHCP do wybranych grup hostów.

Wspomniana technologia NAT (o której troszkę więcej w artykule o sieciach IP) korzysta z tablicy w której przechowuje śledzone połączenia (pamiętanie NATowanych połączeń jest konieczne aby wykonywać NAT). Aktualną ilość wpisów w tej tablicy można sprawdzić poprzez wc -l < /proc/net/ip_conntrack. Gdy tablica ta się zapełni nie jest możliwe nawiązywanie nowych połączeń, gdy występuje taki problem możemy zmienić jej rozmiar lub zmniejszyć czas przechowywania połączeń poprzez ustawienie odpowiednich wartości odpowiednio w /proc/sys/net/ipv4/netfilter/ip_conntrack_max /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established.

Częstym aspektem przy konfiguracji bramek (jednak tutaj praktycznie pominiętym) jest autoryzacja klientów uprawnionych do dostępu do sieci. Najpopularniejszym rozwiązaniem tego typu jest stosowanie PPPoE, spotkać się można także z wykorzystaniem autoryzacji proxy, stosowania VPN w tym celu. W systemach BSD możliwe jest także dopuszczanie użytkowników którzy nawiążą z serwerem połączenie SSH - poprzez mechanizm Authpf.

Ponadto prezentuję skrypty generujące i prezentujące statystyki obciążenia łącza: traffic_stats.sh i traffic_stats_show.sh.

Zobacz w Sieci: Jak podróżuje pakiet przez router linuxowy, HTB, filtry u32 i inne.

Konfiguracja w ręce użytkowników

Jeżeli zależy nam na samodzielności użytkowników możemy spore możliwości konfiguracyjne przekazać w ich ręce. W ogólności konfiguracja użytkownika może być wprowadza w zależności od usługi na różne sposoby - w przypadku tradycyjnych usług jak poczta i www może to być dostęp shell'owy (ssh), w przypadku jabber'a (XMPP) jest to konfiguracja przez ten protokół (konsola XML/klient) w przypadku voip (SIP) możemy dokonywać konfiguracji poprzez telefon (system menu telefonicznego).

Konfiguracja przez menu telefoniczne jednak nie jest zbyt wygodna i chyba warto umożliwić użytkownikom konfigurację swoich usług poprzez odpowiednie pliki na serwerze - zamieszczam skrypt generujący zbiorczy plik konfiguracyjny dla Asteriska w oparciu o pliki zapisane w katalogach użytkowników. System, automatycznie dodaje do nazw kontekstów identyfikatory użytkowników do których one należą (dzięki czemu nie ma się możliwości grzebania w cudzej konfiguracji), działanie to oparte jest na założeniu że identyfikator odpowiadający użytkownikowi shellowemu jest w prosty sposób zależny od jego UID. System także importuje lub usuwa odpowiednie wpisy bazy danych należące do użytkownika (uwagi i założenia jak poprzednio. A następnie dokonuje zrzutu wpisów bazy danych dotyczących użytkownika do pliku w jego katalogu domowym.

Inną usługą gdzie możemy chcieć aby użytkownik mógł samemu mógł wprowadzać dane konfiguracyjne jest DHCP - zamieszczam skrypt generujący w oparciu o listę mac-adresów w pliku użytkownika konfigurację dla serwera dhcp. Założenie działania skryptu jest takie iż identyfikator numeryczny grupy podstawowej użytkownika (dokładniej grupy będącej właścicielem pliku konfiguracyjnego) przekłada się w prosty sposób na system numeracji IP. Zobacz także prototypy skryptów umożliwiających dodawanie MAC adresów przez WWW - add_mac.php add_mac.sh.

W przypadku omawianego w tym serwisie serwera ejabberd warto także zapewnić okresowy zrzut jego bazy danych (przechowującej m.in. ustawienia wprowadzane przez użytkowników do pliku tekstowego. Można tego dokonać okresowo wywołując: ejabberdctl dump /tmp/ejabberd_`date +%Y%m%dT%H%M%S`.txt. Można by także spróbować parsować tak otrzymany plik celem poumieszczania zrzutu konfiguracji w katalogach odpowiednich użytkowników.

Uwaga: prezentowane powyżej programy mają status beta - przechodzą one dopiero testy i mogą pojawić się jakieś błędy.

W świetle przedstawionych powyżej rozwiązań warto również rozważyć sposób stworzenia bazy domen z powiązaniem do UID/GID (tabelka domena UID, GID jeden z UID/GID == x, mająca znaczenie informacyjne, bo automatyczne generowanie konfigu z plików użytkownika odpada) a także pamiętać też należy że wywołania adduser z odpowiednimi opcjami umożliwiają określenie identyfikatorów numerycznych jakie przypisujemy użytkownikowi/grupie:

adduser --group --gid GROUP_NUM_ID GROUP_NAME
adduser --gid GROUP_NUM_ID [--add_extra_groups ...] USER_NAME
adduser --ingroup GROUP_NAME [--add_extra_groups ...] USER_NAME

Można by stworzyć system generujący aliasy XMPP (zobacz: JID aliases) i aliasy SIP w oparciu o aliasy pocztowe (virtusertable). Główną wątpliwość budzi fakt iż raczej dość często mogą być potrzebne aliasy tylko jednego z rodzajów a nie wszystkich na raz więc może jednak lepiej utrzymywać niezależne bazy aliasów dla SMTP, XMPP i SIP. Dlatego też jak na razie nie został on prze zemnie przygotowany, ale być może kiedyś to nastąpi i go tu opublikuję.

Oczywiście jak mówimy o konfiguracji to trzeba wspomnieć o programach takich jak chsh i chfn, umożliwiających użytkownikowi odpowiednio zmianę używanego przez niego shella oraz danych zapisanych w polu informacji dodatkowych w /etc/passwd. Za ograniczenie sheli na jakie może być dokonywana zmiana odpowiada plik /etc/shells a za ograniczenie pól opisu w bazie kont które może edytować użytkownik odpowiada wpis CHFN_RESTRICT w /etc/login.defs. O passwd nie będę pisał ;-).

Powiadomienia XMPP/SMTP

Głównym celem prezentowanego przeze mnie systemu powiadomień XMPP/SMTP jest umożliwienie zapewnienia przepływu informacji o nowych wiadomościach pomiędzy tymi dwoma protokołami. System składa się z 4 skryptów:

xmpp2email.sh - Wysyła powiadomienia o wiadomościach IM otrzymanych w trybie off-line na e-mail, wymaga zastosowania łatki na ejabberd zapisującej wiadomości offline również do plików tekstowych (więcej o niej tutaj). Program przetwarza wiadomości wszystkich użytkowników serwera jednak wysyłane są tylko dla użytkowników którzy utworzą w swoim katalogu domowym (informacja pobierana z /etc/passwd) plik .sendofflinexmmp2mail, ponadto ignorowane są wiadomości od systemu pocztowego. Program pełni rolę podobną do serwera powiadomień dla mikrokontrolera, przy czym tamten korzystał z bazy MySQL serwera jabberd2. Natomiast xmpp2smtp wykorzystuje informacje zapisywane przez zmodyfikowany (patch) serwer ejabberd.
smtp2xmpp.pl - Program wysyłający wiadomość IM z specyficznego adresu (podobny w działaniu do jabber.cpp, czy też sendxmpp), wiadomość wysyłana jest domyślnie jako headline, dzięki czemu nie powinna być przechowywana w trybie offline.
mail-bot.pl - bot jabberowy udzielający informacji o nowej poczcie, do pobierania informacji o wiadomościach korzysta z "mail2text.sh"
mail2text.sh - Pomocniczy program odpowiedzialny za konwersję kodowania mailowego znaków non-ascii z 7 lub 8 bitowego w jakiejś stronie kodowej na utf-8. Program oprócz konwersji nagłówków, posiada także funkcjonalność wyciągnięcia treści tekstowej z maila (również z maila typu mime zawierającego część text/plain) i dokonania jej konwersji. Przykład zastosowania razem z smtp2xmpp.pl podany jest w pliku procmailowym .

Można także pobrać te programy w formie archiwum źródłowego paczki *.deb - xmpp-smtp.tgz oraz w postaci gotowej paczki dla Debiana. Zachęcam także do zapoznania się z zestawem moich patch'y do serwera ejabberd implementujących JID aliases.

JID aliases (ejabberd)

Pomimo podobieństw w sposobie adresacji do poczty elektronicznej, w przypadku XMPP trudno jest wymyślić działanie aliasów analogicznych do aliasów pocztowych. Problemem jest czy i jak z aliasów ma być wysyłana widoczność - jeżeli tak samo jak z konta głównego to część zastosowań traci sens oraz to czy ma być wspólna lista kontaktów dla aliasów i konta głównego czy rozdzielne - przy wspólnej także niektóre zastosowania aliasów tracą sens. Natomiast jeżeli zdecydujemy się na oddzielną prezentację i oddzielne listy kontaktów to dochodzimy do przedstawionego tutaj rozwiązania kilku kont o wspólnym haśle i opcjonalnym przekazywaniu wiadomości off-line lub ich kopii na konto główne. W przypadku nielogowania się na takie konta i korzystania z przekazania wiadomości offline, mamy analogiczne rozwiązanie jak opracowane prze zemnie metody uzyskania aliasów w jabberd i jabberd2 (szukaj w archiwum). Warto także zainteresować się stanowiącym część ejabberd'a "mod_shared_roster"

Kontami podstawowymi są konta o nazwach odpowiadających kontu shell'owemu (autoryzacja PAM), ponadto dla każdego z takich kont określona jest domena podstawowa. Aliasy tworzone są na podstawie pliku tekstowego zawierającego wpisy postaci:
aliasname aliasdomain realname realdomain aliasflag
Gdzie można używać * po lewej stronie (dowolny użytkownik/domena) i % po prawej stronie (podstawienie dopasowywanej nazwy nazwy użytkownika/domeny), natomiast aliasflag określa na które z kont mają trafiać wiadomości off-line.

Konta aliasowe umożliwiają logowanie, posiadają własny roadster, natomiast presence wysyłany jest tylko w przypadku zalogowania bezpośrednio na konto aliasowe. Dokładniejszy opis w skrypcie przetwarzającym ten plik na potrzeby ejabberda - ejabberd_alias_check.sh (w skrypcie tym należy także ustalić ścieżkę do pliku aliasów). Na system oprócz wspomnainego skryptu składają się dwa patch'e:

ejabberd_alias_check.diff - umożliwiający logowanie się na aliasowe konta definiowane w stosownym pliku, patch jest przystosowany do łatania http://ejabberd.jabber.ru/pam można go jednak dostosować do innych modułów autoryzacji, patch wymaga "ejabberd_alias_check.sh" i podania ścieżki dostępowej do niego w kodzie
ejabberd_alias_forward.diff - implementuje opcjonalne przekazywanie oryginału lub kopii wiadomości otrzymanej na alias na konto podstawowe, docelowo ma być zastąpiony AMP (XEP-0079), patch wymaga "ejabberd_alias_check.sh" i podania ścieżki dostępowej do niego w kodzie

HTTPS i Apache

Aby uruchomić szyfrowany dostęp do stron WWW (poprzez Apache2) wystarczy uaktywnić moduł SSL, ustawić nasłuch na porcie 443 (standardowy port dla https) oraz skonfigurować vhosta na tym porcie z włączonym szyfrowaniem poprzez umieszczenie w jego konfiguracji:

SSLEngine on
SSLCertificateFile /etc/ssl/server.crt
SSLCertificateKeyFile /etc/ssl/server.key

Następnie musimy również przygotować odpowiednie certyfikaty - więcej na ten temat w części poświęconej szyfrowaniu z wykorzystaniem certyfikatów x509

Jeżeli wygenerowaliśmy niezależnie certyfikat CA warto w konfiguracji Apache także określić jego położenie:

SSLCACertificatePath /etc/ssl/ca/
SSLCACertificateFile /etc/ssl/ca/ca.crt

Należy zaznaczyć iż aby vhosty miały różne certyfikaty SSL należy je uruchamiać na rożnych portach lub adresach IP (jest to ograniczenie wynikłe z samego mechanizmu SSL). Posłużyć się należy dyrektywami: VirtualHost ip.ip.ip.ip:port oraz Listen port i opcjonalnie - gdy na danym ip i porcie ma być kilka vhostow rozróżnianych nazwami (ale z wspólnym certyfikatem !) NameVirtualHost ip.ip.ip.ip:port). Należy też zaznaczyć iż porty możemy użyć w redirectach z http:// (ale z https:// już trudniej - zmiana certyfikatu), najwygodniejsze są adresy IP.

PHP, CGI, suexec - czyli (nie)bezpieczny Apache

Powierzanie dostępu (prawa do odczytu) do poufnych plików (w szczególności plików haseł) użytkownikowi/grupie na prawach której chodzi serwer www (np. apache) jest pomysłem dość kontrowersyjnym, zwłaszcza w systemach wieloużytkownikowych z dostępem do PHP. Problem polega na tym że standardowo PHP działa z tymi samymi prawami co serwer www, zatem jeżeli jakiś plik ukryjemy przed innymi użytkownikami a damy do niego dostęp serwerowi www, to każdy kto może wykonać skrypt PHP przez WWW na tym serwerze będzie miał dostęp do naszego poufnego pliku. Problem ten w szczególności dotyczy też stron zabezpieczanych hasłem przez autoryzację Apache (umieszczaną np. w plikach .htaccess) gdyż nawet gdy plik będzie dostępny dla właściciela i grupy, a będzie maił zabroniony dostęp dla innych użytkowników musi mieć do niego dostęp serwer www (najczęściej przez prawa grupy) a zatem i inni użytkownicy przez PHP.

Pewnym rozwiązaniem tych problemów jest użytkowanie PHP jako CGI (w pierwszej linijce #!/usr/bin/php-cgi oraz prawo wykonywania pliku) wraz z korzystaniem z modułu suexec, wykonującego skrypty CGI z prawami innych użytkowników (dla vhostów ustawianych dyrektywą: SuexecUserGroup nazwa_uzytkownika nazwa_grupy oraz dla stron użytkowników dostępnych przez tyldą z prawami danego użytkownika). Wykorzystywany jest wtedy program /usr/lib/apache2/suexec, który musi mieć właściciela root, grupę www-data (w Debianie) oraz prawa 4750. Oczywiście skrypty cgi są bardziej obciążające dla serwera niż php jako moduł dlatego można stosować równolegle te dwie metody - dla skryptów wymagających poufnych danych odpalamy jako cgi z użytkownikiem mającym dostęp do tych danych (ale nie root ;) dla pozostałych normalnie. Nie rozwiązuje to oczywiście powyższego problemu stron chronionych hasłem (ale stanowi pewne rozwiązanie zabezpieczenia np. haseł do baz danych czy bazy shadow gdy chcemy używać w skryptach autoryzacji PAM (do php można dodać odpowiednie funkcje)), rozwiązanie tamtego problemu wymaga aby nie było w ogóle skryptów php czy cgi chodzących z prawami serwera www.

Na koniec warto zwrócić uwagę że program suexec ma wkompilowaną na stałe w siebie ścieżkę na której musza być uruchamiane z prawami innego użytkownika skrypty (niestety nie jest ona ustawiana żadną dyrektywa konfiguracyjną), jest to ścieżka położenia pliku a nie dojścia do niego więc symlinki z ścieżki do katalogów z root vhostow nie pomogą (w razie wielkich trudności można ustawić przy kompilacji / ale nie jest to zalecane). Warto też zaznaczyć że php przeznaczone do pracy z linii komend w odróżnieniu od wersji kompilowanej dla cgi ma problemy z nagłówkami - nagłówki trzeba wysyłać na samym początku skryptu przez ich wypisywanie (np. echo), a nie przez funkcję header(); wersja cgi domyślnie wysyła też nagłówek określający że jest to html.

Kolejnym problemem jest że skrypty chodzące na prawach serwera www mogą wywołać suexec i odpalić inny skrypt na większych prawach niż posiada serwer www (suexec chodzi z SUID root), zatem zabawa z suexec traci sens gdy pozostaje możliwość odpalenia jakiegokolwiek polecenia z prawamui użytkownika serwera www. Można nawet zaryzykować stwierdzenie że sama obecność suxec w takich systemach stanowi więcej zagrożenia niż pożytku ... .

Inne ustawienia i uwagi

Mogłoby się wydawać iż oprócz logowania ruchu przechodzącego (omawianego w części dotyczącej routingu) warto rozważyć logowanie tablicy arp (odpowiedniości numerów sprzętowych i IP) - realizuje to np. następujący skrypcik - arp_log.sh, jednak po bliższym przyjżeniu się logom ruchu zauważyć w nich można oprócz adresów IP MAC adresy kart, więc jest to zbędne. Na koniec proponuję dodanie do /etc/cron.daily/ skryptu wywołującego ntpdate (uwaga: aby skrypt był wykonywany przez crona konieczne może okazać się zrezygnowanie z niektórych znaków w jego nazwie np. kropki).

Przydatne może być też zmienienie portu na którym słucha SSH ze względu na boty próbujące się logować i zaśmiecające nam logi. Zobacz też w Sieci: Blokowanie ssh po nieudanych próbach logowania.

Zachęcam także do zapoznania się z moimi artykułami o: konfiguracji sieci, konfiguracji linuxa, podstawach linuxa.

Zobacz w Sieci: kravietZ: IPv6 i Linux, Przewodnik po budowie routera IPv6 w Gentoo, MySQL - zapomniane hasło root.

Bridge, VLAN i trunking

W oparciu o komputer z linuxem i kilkoma kartami sieciowymi na pokładzie możemy zrobić nie tylko (opisany powyżej) routing ale także zarządzany switch ("routing" ramek ethernetowskich pomiędzy kartami). Do utworzenia oraz zarządzania mostem składającym się z kilku interfejsów sieciowych (powinny one być zdekonfigutowane od strony IP gdyż od momentu włączenia do bridge'a stają się jego portami) służy komenda brctl. Poszczególne porty w bridge'u można wyłączać i włączać komendą ifconfig ethX down|up. Sam bridge stanowi natomiast pełnowartościowy interfejs sieciowy, umożliwiający normalną konfigurację TCP/IP. Domyślnie most uczy się na którym z portów ma jakie MAC adresy (czas przechowywania takiej informacji możemy ustawić przy pomocy brctl). Jeżeli chcemy uzyskać prawdziwie zarządzany switch powinniśmy się zainteresować pakietem ebtables, który umożliwi filtrowanie ruchu przechodzącego przez bridge (także z wykożystaniem iptables czy arptables). Warto zapoznać się z przykładami użycia ebtables oraz opisem współdziałania ebtables i iptables. Rozdział drugi tego dokumentu przedstawia ogólne zasady podróżowania pakietów przez reguły ebtables. Następnie mamy omówione różnego rodzaju interakcje z iptables i tak:

Rysunek 3c przedstawia trasę pakietu adresowanego (MAC) do któregoś z interfejsów bridge'a (a więc zapewne adresowany także ip do urządzenia bridge'a), ponadto adres na który wykonywany jest routing jest także za bridge'em. W ogólności dolna lewa bądź prawa część schematu nie musi być na bridgeu (oznaczanym na niebiesko) może być na zwykłym eth* lub procesie lokalnym (wtedy inaczej wygląda też górna część schematu).
Rysunek 5 przedstawia trasę pakietu przekazywanego wyłącznie przez bridgea (przechodzi także przez odpowiednie regułki iptables - zależne od ustawień systemu bridge-nf w /proc/sys/net/bridge/), w sytuacji gdy nie korzystamy z physdev
Rysunek 6a przedstawia tą samą sytuację co rysunek 5, ale gdy wykorzystywane jest physdev (iptables -m physdev --physdev-out ethX), które informujące iptables o źródłowym/docelowym porcie na bridge.
Rysunek 6d pokazuje przypadek z rysunku 3c gdy ruch wejściowy jest ruchem lokalnym i użyty jest physdev.

Bridge ma niekiedy problemy z włączonymi do niego urządzeniami wifi. Związane jest to z ograniczeniami tego standardu, a przede wszystkim z wymogiem iż urządzenie klienckie (w trybie client) może prezentować tylko jeden MAC adres. Zatem aby mogło ono być elementem bridge'a należy zastosować odpowiednie maskowanie MAC-adresów w ebtables. Innym ominięciem tego problemu w AP jest tryb Wireless Distribution System.

Kolejnym aspektem związanym z warstwą ethernetową są VLANy, umożliwiające tworzenie wirtualnych sieci w warstwie ethernetowej. Oczywiście możliwa jest przeźroczysta dla komputerów końcowych konfiguracja VLANów (switche wiedzą na którym porcie mają jaki VLAN i pakiety danego VLANu wysyłają tylko do / odbierają tylko z portów które do niego należą. Ma to częste zastosowanie gdy VLANy używane są ze względów bezpieczeństwa. Ciekawym przypadkiem jest jednak gdy komputer otrzymuje znaczniki VLANu i sam może identyfikować z którego VLANu do którego należy jest dany pakiet. Do tworzenia takich VLANów oraz zarządzania nimi służy komenda vconfig. Możliwe jest także wykorzystanie interfejsów v-lanowych w bridgowaniu ni uzyskanie w ten sposób switcha z wsparciem dla VLANów. Zobacz w Sieci: VLAN 2 – Ethernet.

Inną ciekawą możliwością jest port trunking (bonding) polegający na połączeniu kilku interfejsów w jeden o większej prędkości. Wymaga on załadowania modułu bonding z parametrem mode określającym typ tworzonego połączenia interfejsów. Taki wirtualny interfejs uruchamiany jest przy pomocy ifconfig, natomiast do dodawania do niego fizycznych interfejsów służy komenda ifenslave. Utworzenie kilku interfejsów z różnym mode jest możliwe poprzez odpowiednie skonfigurowanie powiązań nazw tworzonych interfejsów z modułem i opcjami w konfiguracji modprobe (/etc/modprobe.d/). Więcej na jego temat znaleźć możemy na LiNUX Horizon - Bonding (Port Trunking).

NAT-PT czyli brama pomiędzy IPv6 a IPv4

Przynajmniej w okresie przejściowym wdrażania IPv6 konieczne może się okazać zapewnienie sieci IPv6-only dostępu do zasobów sieci IPv4. W tym celu stosuje się rozwiązania typu NAT-PT, wykonujące translację adresów pomiędzy IPv6 i IPv4. W odróżnieniu od zwykłych NATów muszą one także podmieniać zapytania i odpowiedzi DNS tak aby mapować adres IPv4 hosta docelowego w przestrzeni adresowej IPv6 i zwracać ten zamapowany adres jako odpowiedź na rządanie AAAA.

Przykładem realizacji takiego mechanizmu jest daemon (mechanizm ten - chyba nawet w BSD oferującym w odróżnieniu od Linuxa NAT dla IPv6 - realizowany jest poza jądrem systemu) naptd. Instalacja i konfiguracja jest szczegółowo opisana w załączonej dokumentacji. Należy jednak zwrócić uwagę blokadę przekazywania prefixu używanego przez NAT-PT na routerach IPv6 - ip6tables -I FORWARD 1 -d 2000:ffff::/96 -j DROP (na wszystkich routerach dających wyjście na świat po ipv6) oraz odrzucanie pakietów innych niż ESTABLISHED oraz NEW na uruchomione usługi (ptrzedewszystkim ssh) na routerze robiącym NAT-PT. Na hostach klienckich należy z koleji ustawić trasę routingu dla sieci wykożystywanej przez NAT-pT - ip -6 route add 2000:ffff::/96 via ipv6:hosta:robiacego:nat::pt dev eth0 oraz ustawić DNS będący adresem DNSu IPv6 zamapowanym na adres IPv6 urzywany przez NAT-PT (2000:ffff::ip.ip.dns.v4). Zamieszczam też łatkę na wersję 0.4 umożliwiającą skompilowanie jej pod Debianem Lenny.

podstawy testowania protokołów sieciowych - telnet i netcat

Większość podstawowych protokołów sieciowych wykorzystuje w komunikacji wiadomości przesyłane zwykłym tekstem (ASCII), dlatego też do ich testowania możemy wykorzystać klienta telnetu (lub bardziej zaawansowany netcat mogący też pełnić rolę serwera przyjmującego połączenia). Do usług takich należy WWW (protokół HTTP) gdzie po połączeniu się z (standardowo) portem 80 serwera i wysłaniu stosownego komunikatu otrzymamy nagłówki HTTP odpowiedzi oraz jej treść (dane tekstowe np. HTML bądź dane binarne np. obrazek). Wspomniana treść żądania może wyglądać następująco (kończy się wysłaniem pustej linii):

GET / HTTP/1.1
Host: www.opcode.eu.org

Podobnie jest w protokołach SMTP (przesył poczty elektronicznej) - tutaj możemy korzystając z tej metody wysyłać listy z np. sfałszowanymi nagłówkami, XMPP (jabber), POP3, IMAP, ... . Szczegółowe opisy składni poszczególnych protokołów znaleźć możemy w dokumentach RFC.