Korporacyjny komunikator: OpenFire+Spark.

Dzisiaj pokażę wam jak w 10 krokach zainstalować oraz skonfigurować serwer OpenFire, tak aby uwierzytelniał użytkowników za pośrednictwem LDAP\’a.

Pobieramy interesującą nas wersję instalatora ( Windows, Unix, Mac )  ze strony producenta.  Instalacje serwera OpenFire nie jest trudnym zadaniem – zakładam, że wszystko przebiegło pomyślnie i pod adresem http:\\ip_servera:9090, czeka na was kreator instalatora 🙂 W przypadku systemów z rodziny Windows  z włączoną zaporą pamiętajcie o odblokowaniu portu 9090 ( konsola do zarządzania ) oraz 5222 ( xmpp ).

Wstępna konfiguracja  step by step:

Testowa konfiguracja:

Nazwa domeny: dgm.local

Nazwa kontrolera domeny: zie-srv-pdc

Konto administratora: administrator@dgm

OU grup użytkowników: dgm.local/Zielonki/

Krok 1:

Wybieramy język instalacji – Polski

[singlepic id=8 w=320 h=240 float=center]

Krok 2:

Domena – nazwa kontrolera domeny, Port konsoli – zostawiamy domyślne.

[singlepic id=9 w=320 h=240 float=center]

Krok 3:

Ustawienia bazy danych – Wbudowana baza danych ( najszybsze rozwiązanie ). W przypadku wyboru Standardowe połączenia z bazą danych, należy podać parametry dostępu oraz nazwę hosta, na którym jest uruchomiona baza dancych.

[singlepic id=10 w=320 h=240 float=center]

[singlepic id=11 w=320 h=240 float=center]

Krok 4:

Profile Settings – Directory Server ( LDAP )

[singlepic id=12 w=320 h=240 float=center]

Krok 5:

Profile Settings: Connection Settings:

Server Type: Active Directory

Host: zie-srv-pdc

Base DN: dc=dgm, dc=local

Administrator DN: administrator@dgm

Password: Tutaj wpisujemy hasełko admina 😉

[singlepic id=13 w=320 h=240 float=center]

Testujemy wprowadzone dane, jeżeli wszystko będzie ok to otrzymamy komunikat \”Status: Success!\”

[singlepic id=14 w=320 h=240 float=center]

Krok 6:

Profile Settings: User Mapping:

W najprostszej konfiguracji zostawiamy wszystko tak jak jest.

[singlepic id=15 w=320 h=240 float=center]

Krok 7:

Profile Settings: GroupMapping:

Interesują mnie wszystkie grupy, które w nazwie mają słowo Zielonki

Group filter: (&(objectClass=group)(cn=Zielonki*))

Po kliknieciu Test Settings powinny pokazać się grupy, które spełniają nasze wymagania.

Krok 8:

Jeżeli wszystko udało się poprawnie skonfigurować to będziemy mogli zalogować się do konsoli administracyjnej, przy użyciu konta administrator.

[singlepic id=17 w=320 h=240 float=center]

Krok 9:

Po zalogowaniu, wita nas piękna strona główna, z której przemieszczamy się szybko do zakładki Użytkownicy/Grupy, a następnie przechodzimy do Ustawień Grup. W naszym przypadku mamy 3 grupy, które nas interesują ( Zielonki_Administracja, Zielonki_Telemarketer, Zielonki_Reszta). Listę każdej z tych grup musimy udostępnić dla wszystkich użytkowników, dlatego po kliknięcie w nazwę grupy wybieramy:

[singlepic id=1 w=320 h=240 float=center]

[singlepic id=2 w=320 h=240 float=center]

[singlepic id=3 w=320 h=240 float=center]

Enable contact group sharing, oraz:

Zaznaczamy: Share group with additional users i wybieramy \”All Users\”

[singlepic id=4 w=320 h=240 float=center]

Czynność wykonujemy dla każdej grupy, którą chcemy mieć w u wszystkich na Liście kontaktów by default 😉

Krok 10 – Ostatni:

Instalujemy klienta jabbera – np. Spark, łaczymy się do serwera podając nazwę użytkownika, hasło oraz adres serwera. Po zalogowaniu będziemy można zobaczyć efekt naszej pracy, czyli działający komunikator z pre-definiowaną listą kontaktową dla każdego użytkownika.

Spolszczenie do komunikatora Spark:

Plik ze spolszczeniem spark.jar, trzeba podmienić za \\Program Files\\Spark\\lib\\spark.jar – uruchomić ponownie komunikatora, wybrać język polski i po kolejnym uruchomieniu programu można cieszyć się spolszczoną wersję Sparka 😉

Autorem spolszczenia jest Pan Jacek Piechnik

[singlepic id=18 w=320 h=240 float=center]

[singlepic id=19 w=320 h=240 float=center]

Podsumowanie:

W dzisiejszym wpisie przedstawiłem podstawową konfigurację firmowego komunikatora, które zastępuje komercyjne rozwiązania takie jak Office Communication Server.

Zalety korporacyjnego komunikatora:

– swobodna komunikacja w czasie rzeczywistym

– swobodna wymiana plików, bez konieczności używania poczty, serwera plików, ftp itd…

– prosta konfiguracja i administracja

– blokada komunikacji z serwerami zewnętrznymi

W razie problemów z instalacją bądź konfiguracją zachęcamy do komentowania – postaramy się pomóc 🙂

Rodzaje zagrożeń w sieci

Bezpieczeństwo użytkowników w sieci jest najważniejsze. Niestety nieświadomość zagrożeń wpływa na podatność utraty cennych danych. Zawsze tak było i będzie, że użytkownicy są najsłabszym ogniwem jakichkolwiek zabezpieczeń. To ich brak wiedzy, lenistwo lub zwykła bezmyślność może doprowadzić do niewystarczającej ochrony. Nie jest żadną nowością, że Internet jest najpopularniejszym medium, które pozwala na łątwą i szybką wymianę informacji. Oprócz pozytywnych aspektów używania sieci, istnieje wiele form nieuczciwości i naruszenia bezpieczeństwa danych. Żeby dokładniej przybliżyć niebezpieczeństwa poniżej krótko przedstawiam mój podział ewentualnych ataków na sieć (host/-y).

Podział ataków:

Ataki w warstwie drugiej – łącza danych, modelu OSI:

1) atak na tablicę MAC, czyli MAC flooding wykorzystujący skończoną wielkość tablicy CAM. W momencie przepełnienia tej tablicy, wszystkie ramki, które przychodzą na określony port, będą wysyłane na pozostałe porty switch’a. Do przeprowadzenia ataku może posłużyć Macof z pakietu Dsniff lub Yersinia. Rozwiązanie ochronne to m.in.: port security.

2) atak na protokół ARP, czyli ARP spoofing – łatwość w przechwytywaniu haseł w ruchu między innymi FTP, Telnet, http (czyli np. hasła i loginy z forum lub bloga), POP (czyli loginy i hasła z poczty internetowej)… wystarczy skorzystać z dobrych snifferów (Wireshark, Tcpdump, Ettercap, Dsniff, Snort). Jest to atak typu MITM, czyli popularny Man In The Middle. Atak ARP spoofing polega na podszywaniu się agresora pod jednym z komputerów w sieci poprzez wysłanie wielu sfałszowanych adresów ARP Reply co powoduje (celowe i błędne) zmiany wpisów w systemie odwzorowań ARP pamięci podręcznej. Jednym z rozwiązań bezpieczeństwa jest, na przykład, Dynamic ARP Inspection.

3) MAC spoofing, czyli zmiana adresu MAC u intruza na MAC ofiary co może prowadzić do zmiany w tablicy przełączania. Atak jest mało skuteczny bo prowadzi przeważnie do częściowego przechwytu danych. W przełącznikach zabezpieczeniem prze takim atakiem są statyczne wpisy w tabeli przełączania.

4) DHCP spoofing jest kolejnym typem ataku MITM przeprowadzanym na serwer DHCP, który umożliwia uzyskanie danych do konfiguracji w sieci, czyli adres IP hosta, maski, adres IP bramy, adres serwera DNS. Atak polega na manewrowaniu komunikatami DHCP Offer oraz DHCP Ackonwledge. Narzędziem do przeprowadzenia tego ataku jest Ettercap, który po odpowiedniej konfiguracji będzie fałszywym serwerem DHCP. Jednym z rozwiązań jest DHCP snooping.

5) atak, który wykorzystuje słabość Spanning Tree. Odpowiednim zabezpieczeniem jest BPDU Guard i BPDU Filter.

Ataki w warstwie trzeciej – sieci, modelu OSI:

1)ataki rodziny DoS – można tutaj wypisać niesamowicie wiele informacji, w tym artykule ograniczę się do wymienienia najważniejszych, bez wgłębiania się w ich działanie. Generalnie najlepiej jest podzielić ataki DoS, ze względu na działanie, na trzy grupy
a) ataki, które bazują na implementacji stosu TCP/IP i wykorzystują słabość w specyfikacji TCP/IP w określonym systemie operacyjnym. Do tej grupy zaliczam: Ping Of Death (znany tez jako Long ICMP attaca; zniekształca pakiet ICMP Echo Request), Teardrop (dotyczy fragmentacji pakietów protokołu IP i pól offset field), SMBnuke, WINnuke
b) ataki, które bazują na słabościach standardów stosu TCP/IP. Przykładowo bardzo niebezpieczny SYN Flood, Naptha oraz Land. Są to klasyczne ataki wyczerpujące zasoby systemowe.
c)Ataki, które w swoim działaniu wykorzystują tzw. „brutalną siłę”, czyli brute force. Generują one duży ruch w sieci, który wyczerpuje dostępną przepustowość. Najbardziej znane to: Smurf, UDP Flood, Fraggle, Pingflood oraz Jolt.

2)ataki z rodziny DDoS, taki atak jest przeważnie efektywny a źródła są trudne do wytropienia. Do najpopularniejszych ataków DDoS można zaliczyć: Torinoo (UDP flood), Mstream (TCP ACK Flood + IP spoofing), Shaft (UDP+TCP SYN+ICMP flood i przeprowadzanie statystyk), Stacheldraht (UDP+TCP SYN,ACK,NULL+ICMP flood , IP spoofing, komunikacja w ramach sieci jest szyfrowana), TFN (UDP+ICMP Echo+TCP SYN flood i atak Smurf), TFN2K (UDP+TCP+ICMP flood, atak Smurf oraz Targa3, IP spoofing, komunikacja w ramach sieci jest szyfrowana) . Do zbudowania tak zwanej sieci DDoS wykorzystuje się dodatkowo takie elementy jak: exploity (służą do uzyskania praw administratora), rootkity (służą do ukrywania włamania zaatakowanego systemu), skanery portów (szukanie kolejnych ofiar), sniffery (podsłuch danych) oraz autorootery (konie trojańskie, które wprowadzają automatyzm tworzenia sieci DDoS) i daemony (procesy pracujące w tle bez interakcji z użytkownikiem).

W celu zabezpieczeń i częściowym ograniczeniu zapędów agresora należy stosować:
1) szyfrowanie MD5 wykorzystywane tylko i wyłącznie w celu ochrony protokołów routingu (RIPv2, OSPF itd.) poprzez dodatkowe uwierzytelnienie sąsiadów lub uaktualnień – co zapobiega atakom w warstwie gdzie funkcjonują protokoły routingu.
2) GTSM – czyli Generalised TTL Security Mechanizm – dzięki temu GTSM chroni sesje BGP przed atakami, które mogą nastąpić od oddalonych hostów. Także 2 routery między którymi jest sesja eBGP wymieniają się pakietami IP z polem TTL ustawionym na 255, wszelkie wartości poniżej są odrzucane.
3) filtry prefiksów rozgłaszanych do Internetu i otrzymywanych z Internetu. Właśnie tutaj można zastosować uRPF (unicast Reverse Path Filtering) do automatycznego wykrywania fałszowania adresu źródłowego (adres źródłowy będzie filtrowany po zawartości tablic routingu).
4) do ograniczenia ataków rodziny DDoS można korzystać z Blackholing, który jest wyzwalany zdalnie (RTBH) oraz Anycast Sinkhole.

Ataki w warstwie czwartej – transportowej, modelu OSI:

Protokół TCP i UDP odpowiada warstwie 4 – transportowej. Z definicji: Porty protokołu – pojęcie związane z protokołami transportowymi TCP i UDP używanymi w Internecie do identyfikowania procesów działających na odległych systemach.
Warto zwrócić uwagę na skanowanie portów, które jest szalenie obszernym tematem. Samo w sobie nie jest szkodliwe, ale może być wykorzystane w złych celach. Najpopularniejsze narzędzie do przeprowadzania takich ataków to Nmap. Żeby zebrać dokładne informacje o danym porcie, trzeba przeprowadzic kilka rodzajów skanowania. Niektóre z nich to skanowania: TCP SYN, TCP-connect, UDP, Null, ACK, TCP Window, Maimon, Idle oraz FTP-bounce. Po wykonaniu takich skanowań można bez problemu określić usługi i aplikacje jakie są zainstalowane na hoście, protokołach jakie są wykorzystywane przez usługę i rodzinie systemów operacyjnych. Dodatkowo można określić stan każdego z portów (otwarty, zamknięty, filtrowany, niefiltrowany, otwarty/filtrowany, zamknięty/filtrowany).

Rozwiązaniem bezpieczeństwa jest stosowanie firewall’a. Są różne postacie zaczynając od sprzętowych rozwiązań (Juniper i Cisco) a kończąc na programowych (Outpost, Zonealarm i w szczególności zasługuje tu na uwagę iptables). Na poniższym rysunku widoczne jest porównanie, gdzie działa firewall w stosunku do warstw modelu OSI oraz TCP/IP.
[singlepic id=26 w=320 h=240 float=center]

Ataki w warstwie siódmej – aplikacji, modelu OSI:

Warstwa w której są obsługiwane najważniejsze protokoły (SMTP, FTP, HTTP, TFTP, Telnet). W szczególności aktywne tu są takie niebezpieczeństwa jak oprogramowanie typu malware (wirusy, konie trojańskie i robaki), przepełnienie bufora, SQL injection oraz XSS, czyli Cross-Site Scripting.

Pojęcia takie jak robaki internetowe, wirusy, konie trojańskie, ataki z rodziny DoS, podsłuch ruchu sieciowego (sniffing) lub fałszowanie podstawowych usług lub protokołów sieciowych (spoofing) mogą dać wiele do myślenia, przestraszyć albo, odwrotnie, utwierdzić w przekonaniu, że problem nie dotyczy użytkownika. Zagadnienia związane z bezpieczeństwem rozwijają się w dynamiczny sposób. Istnieje nieustająca potrzeba tworzenia nowych rozwiązań i eliminowaniu słabych punktów systemu operacyjnego lub aplikacji wykorzystujących sieć internetową. W sposób zdecydowany trzeba powiedzieć, że bezpieczeństwo to nieustający proces, który musi być ciągle udoskonalany.

text by Patryk \’Whizz_BANG\’ Bator 🙂

WebsiteSpark firmy Microsoft dla specjalistów od sieci Web

Firmy posiadające do 10 pracowników i właścicieli mogą skorzystać z udziału w programie WebsiteSpark przez okres trzech lat (rodzina programów Spark obejmuje także BizSpark oraz DreamSpark). Uczestnictwo nie niesie ze sobą żadnych ukrytych kosztów ani zobowiązań, a jedyna opłata to 100USD za uruchomienie programu, którą uiszcza się po wystąpienia z programu.

Korzyści z uczestnictwa w WebsiteSpark:
a) Dostęp do narzędzi programistycznych i projektowych Microsoft, które są przeznaczone do sieci Web (3 licencje na Microsoft Visual Studio 2008 Professional Edition, 2 licencje Microsoft Express Web 3, 1 licencja Microsoft Expression Studio 3)
b) Dostęp do 2 licencji produkcyjnych na Microsoft Windows Web Server 2008 lub R2 oraz 2 licencji produkcyjnych Microsoft SQL Server 2008 Web Edition
c) Dostęp do panelu sterowania witryną sieci web stworzoną przez firmę zewnętrzną DotNetPanel
d) Profesjonalne wsparcie i szkolenia (m.in. prawo do 2 zgłoszeń pomocy technicznej)
e) Dostęp do wsparcia społecznościowego dzięki kontaktowi z innymi partnerami sieciowymi, z partnerami w zakresie hostingu oraz tymi, którzy dysponują uzupełniającymi usługami i technologiami
f) Zapewnienie nieograniczonego dostępu do moderowanych i technicznych grup dyskusyjnych w serwisie MSDN
g) Zapewnienie nieograniczonego wsparcia programowego w zakresie zagadnień nietechnicznych

Program Microsoft WebsiteSpark jest dostępny dla firm z całego świata. Zainteresowani kandydaci, zajmujący się zawodowo siecią web, mogą uzyskać więcej informacji na stronie http://www.microsoft.com/web/websitespark.
Dodatkowo Microsoft udostępnił takie produkty jak: Web Platform Installer 2.0 oraz Windows Web Application Galery 2.0, które wchodzą w skład aplikacji Microsoft Web Platform. Zdecydowanie ułatwia to tworzeniu doskonalszych i efektowniejszych projektów internetowych.

Materiał wideo pochodzi ze strony webhosting.pl

Debian Lenny + AD 2008R2, czyli Samba > 3.4.1

Używanie Debian w środowisku Active Directory

Index

Debian Linux jest systemem operacyjnym. To potężne narzędzie, które może przynosić wiele korzyści w sieci. Używanie go w środowisku Windows może być bardzo trudne. Jest tam wiele przeszkód, które nie pozwalają na gładkie wprowadzenie systemu Debian Linux w sieci. Pierwszą rzeczą, i bardzo ważną, jest wprowadzenie autentyczności dla konta użytkownika.

Jeśli stacje robocze są w domenie Active Directory (AD), użytkownicy używają potwierdzenia autentyczności. Gdy nazwa użytkownika i hasło są używanie dla jednej lub drugiej usługi może to stwarzać dużo problemów. Jeśli kiedykolwiek czytelnik próbował postawić system Debian Linux w produkcji, prawdopodobnie napotkał ten problem. Dodatkowo, w środowisko AD, administratorzy mogą logować się do jakiejkolwiek maszyny i rozwiązywać problemy wykorzystując hasło administratora domeny.

Co mamy do tej pory to: aktywna nazwa użytkownika i hasło do bazy danych, które jest ciągle wykorzystywane do potwierdzenia autentyczności w usługach sieciowych. To luksusy, które powinny wyznaczać drogę jaką trzeba podążać. Jeśli nie można ustalić autentyczności użytkowników do domeny AD, wtedy usługi udostępniane na zewnątrz są niepewne i należy stworzyć oraz uaktualnić bazę danych użytkowników.

Potwierdzenie autentyczności AD nie należy do działania Debian’a, więc jest potrzebne jakieś oprogramowanie, które musi być użyte do zezwolenia na współpracę między dwoma programami. Oprogramowanie, które to umożliwia jest nazywane Sambą. Zajmuje się ona udostępnianiem plików i innych cech sieci, co jest charakterystyczne dla komputerów z systemem Windows. Winbind jest składnikiem Samby, który odwzorowuje (mapping) użytkownika i grupy z Active Directory do języka Linux. Kerberos jest nisko-poziomowym protokołem używanym do potwierdzenia autentyczności hasła w sieci, gdzie jest używana nieszyfrowana transmisja z sesją AD.

Instrukcja ta pokaże jak zainstalować udostępniany folder używając do tego systemu Debian z linuxowy serwerem plików. Można przypuszczać, że wystarczy skorzystać z prawa jakie ma konto root. Te parę kroków jest konieczne do wykorzystania potencjału systemu Debian w AD. W skrócie zostanie to przedstawione poniżej.

Instalowanie niezbędnych paczek używanych przez Debian w środowisku Active Directory

Paczki te są potrzebne do zainstalowania prostego serwera plików Samba używanego przez Debian Lenny i przy autentyfikacji w środowisku AD. Instalujemy Sambę oraz Kerberos’s następującym poleceniem:

aptitude install samba ntpdate smbclient winbind krb5-config krb5-user

Niestety w repozytoriach do Lennego, nie znajdziemy odpowiedniej wersji Samby, dlatego skorzystamy z backportów.

Dodajemy do pliku etc/apt/sources.list wpis:

deb http://www.backports.org/debian lenny-backports main contrib non-free

uruchamiamy apt-get update i importujemy klucze do repozytorium:

apt-get install debian-backports-keyring
aptitude -t lenny-backports install samba ntpdate smbclient winbind krb5-config krb5-user

Wstawiamy w Workgroup/domena informacje kiedy ma być wprowadzony. Zostanie zainstalowany jakiś plik .conf do wykorzystania. W tej chwili nie będziemy się martwić o serwer WINS. Gdy proces zostanie zakończony Daemons automatycznie się uruchomi. Potrzebujemy zastopować działąnie tego pliku podczas jego konfiguracji. Żeby zatrzymać działanie Samby oraz Winbind wpisujemy:

/ etc/init.d /samba stop
/ etc/init.d /winbind stop

Tworzenie pliku konfiguracyjnego używanego przez Debian w środowisku AD

Wszystkie pliki konfiguracyjne znajdują  się w folderze /etc/samba. Warto jest przeczytać je i w celu stworzenia odpowiedniej wiedzy – modyfikować (po uprzednim skopiowaniu oryginalnych plików!).

mkdir /etc/samba/copyconf
mv /etc/samba/* /etc/samba/copyconf/

tworząc własny plik /etc/samba/smb.conf dobrze jest upewnić się czy domena jest zgodna

nano /etc/samba/smb.conf
#/etc/samba/smb.cnf[global]workgroup              =       ((DOMAIN))

server string          =       %h server

wins support           =       no

socket options         =       TCP_NODELAY

large readwrite        =       no

log level              =      1

log file               =       /var/log/samba/samba.%m.log

security               =       ads

realm                  =       ((DOMAIN)).COM

encrypt passwords      =       yes

obey pam restrictions  =        yes

winbind use default domain     =      yes

winbind enum users             =      yes

winbind enum groups            =       yes

template shell                 =       /bin/bash

idmap uid                      =       10000-20000

idmap gid                      =       10000-20000

 

Konfiguracja i testowanie Kerberos przy użyciu Debian w środowisku AD

Ponieważ Samba już  wie jaką jest częścią domeny mamy podstawową jej konfigurację. Potrzebujemy teraz autentykacji jej pracy. Kerberos jest oprogramowaniem, które łączy się z domeną AD w celu autentykacji użytkowników. Bardzo ważne jest to, żeby czas na serwerze był  zsynchronizowany z kontrolerem domeny AD.

sync time
ntpdate ((domain controller))

Edytujemy plik konfiguracyjny Kerberos w celu prawidłowego określenia kontrolera domeny.

nano /etc/krb5.conf

ważna część to konfiguracja domeny /etc/krb5.conf :

[libdefaults]default_realm = ((DOMAIN)).COM[realms]

((DOMAIN)).COM = {

kdc = ((domain controller))

kdc = ((backup DC))

admin_server = (domain controller))

}

[domain_realm]

.((domain)).com = ((domain controller)).((domain)).COM

Można testować możliwości Kerberosa sprawdzając hasło użytkownika przez wpisanie:

kinit ((username))

następnie typ:

klist

Jeżeli efekt końcowy wygląda tak jak poniżej, wszystko jest gotowe.

Ticket cache: FILE:/tmp/krb5cc_0Default principal: (username)@(domain).COMValid starting     Expires            Service principal

04/27/09 13:54:23  04/27/09 23:54:26  krbtgt/(domain).COM@(domain).COM

renew until 04/27/09 23:54:23

Numerowanie kont w AD w Linuksie poprzez Winbind używając Debian w środowisku AD

Do numerowania użytkowników w AD najpierw trzeba dokonać aktualizacji pliku nsswitch.conf:

nano /etc/nsswitch.conf

dodajemy “winbind” do passwd i w linii grupy. Jeżeli posiadamy “compat” w lini, można zrobić coś takiego:

passwd:         compat winbindpasswd_compat:  winbindgroup:          compat winbind

group_compat:   winbind

Przyłączenie serwera Debian Linux do AD – użycie Debian w środowisku AD

Gdy już wszystko mamy skonfigurowane uruchamiamy Sambe i Winbind:

/etc/init.d/winbind start && /etc/init.d/samba start

Jeżeli wszystkie pozostałe kroki zostały poprawnie wykonane, można teraz bez problemu przyłączyć komputer do domeny. Dla komputera tworzymy konto w AD.

net ads join -U ((administrative user))

powinniśmy zobaczyć:

Joined ((server name)) to realm ((domain)).com

Możemy przetestować  Winbind oraz poprawność jego działania wpisując:

wbinfo -t

 

Autoryzacja Winbind w celu autentykacji użytkowników na serwerze – użycie Debian w środowisku AD

Pozwoli to na logowanie do hosta na konta AD. Należy edytować następujące pliki, które powinny wyglądać tak:

# /etc/pam.d/common-accountaccount    sufficient    pam_winbind.soaccount    required    pam_unix.so

# /etc/pam.d/common-auth

auth    sufficient    pam_winbind.so

auth    required    pam_unix.so use_first_pass nullok_secure

# /etc/pam.d/common-session

session    required    pam_mkhomedir.so skel=/etc/skel/ umask=0066

session    sufficient    pam_winbind.so

session required    pam_unix.so

Bardzo ważne jest to, żeby w “obey pam restriction” było ustawione „yes” (w pliku smb.conf), żeby powyższe ustawienia były efektywne.

Nadawanie dostępu administracyjnego w AD w Debian Linux Server

Polecenie sudo pozwala administratorowi systemu dopasować autentykacje dla grupy lub użytkownika do nadania odpowiednich możliwości działania. Przypuścimy, że mamy domenę zabezpieczonej grupy nazwanej ‘TCP’. Następujące polecenie nada grupie w AD odpowiednie prawa i dostęp:

aptitude install sudo
visudo

przesuniemy do samego końca i dodamy linie:

%(domain)\\tcp ALL =(ALL) ALL

Po wykonaniu tego polecenia grupa ‘TCP’ pełny dostęp do serwera co z wiadomych względów nie jest bezpieczne.

Tworzenie grupy udostępniającej w domenie grupy przy użyciu Samby – użycie Debian w środowisku AD

Jak tylko dołączyłeś do serwera Samby w swojej domenie i po wywołaniu identyfikacji użytkownika – tworzenie udostępniania i dostępu grupy do plików jest proste. Musimy stworzyć folder, który jest własnością root’a i domeny grupy. Samba odziedziczy dostęp po folderze nadrzędnym. Przykład  dla stwarzania folderu w domenie grupy nazwijmy „corporate_HR ”. Domena jest zatytułowana “ acme ”. Tam jest  administracyjna grupa wsparcia “ admins”. Ustawiając dostęp do folderu na ‘2771’ powoduje, że Root i grupa „corporete HR” ma pełen dostęp. To zmusi wszystkie nowe pliki utworzone pod folderem HR do wzięcia parametru grupowego z tej rodziny. Używając parametru “force group ” należy upewnić się, że pozwolenia są odpowiednio dobrane i członek z grupy „ACME\\admins ” ma dostęp do plików.

Logujemy się jako root

instalacja pliku systemowego

cd /homemkdir HRchgrp corporate_HR HR

chmod 2771 HR

instalacja udostępniania:

[HR]comment    =    share for corporate HR groupreadonly    =   no

inherrit owner    =    yes

inherit permissions    =    yes

authorized users    =    @ACME\\corporate_HR @ACME\\admins

force group    =    ACME\\corporate_HR

Instalacja proFTPD SSL na Debian Lenny

\"proftpd-serwer\"

W tej instrukcji jest używany komputer o nazwie blog.aboo.pl o adresie IP 10.0.0.10. Jest oczywiste, że ustawienia te różnią się od tych, które mają  być stosowane w określonym miejscu.

Index

Instalacja ProFTPd i OpenSSL

OpenSSL jest wymagane przez TLS; w celu instalacji ProFTPd i OpenSSL uruchamiamy:

aptitude install proftpd openssl

Zostanie zadane pytanie:

Run proftpd:

w trybie wolnostojącym ( standalone)

Ze względów bezpieczeństwa można dodać  do pliku /etc/proftpd.conf (więcej informacji można znaleźć na stronie: http://proftpd.org/localsite/Userguide/linked/userguide.html) następujące linie:

nano /etc/proftpd/proftpd.conf

otwieramy ten plik w celu edycji

[…]

DefaultRoot ~

IdentLookups off

ServerIdent on \”FTP Server ready.\”

[…]

Tworzenie certyfikatu SSL dla TLS

Aby używać TLS musimy stworzyć  certyfikat SSL. Tworzymy go w /etc/proftpd/ssl i dlatego najpierw tworzymy katalog

mkdir /etc/proftpd/ssl

Następnie generujemy SSL wpisując i uzupełniając:

openssl req -new -x509 -days 365 -nodes -out /etc/proftpd/ssl/proftpd.cert.pem -keyout /etc/proftpd/ssl/proftpd.key.pem
Country Name (2 letter code) [AU]: <– wpisujemy nazwę kraju

State or Province Name (full name) [Some-State]: <– wpisujemy województwo

Locality Name (eg, city) []: <– wpisujemy misto

Organization Name (eg, company) [Internet Widgits Pty Ltd]: <– wpisujemy nazwę organizacji

Organizational Unit Name (eg, section) []: <– wpisujemy dział organizacji

Common Name (eg, YOUR name) []: <–wpisujemy cała nazwę domeny systemu (np. \”blog.aboo.pl\”).

Email Address []: <– wpisujemy adres email

Umożliwienie działania TLS In ProFTPd

W tym celu otwieramy plik proftpd.conf

nano etc/proftpd/proftpd.conf

… i następujące niezdefiniowane linie w pliku /etc/proftpd/tls.conf :

[…]

#

# This is used for FTPS connections

#

Include /etc/proftpd/tls.conf

[…]

Następnie otwieramy /etc/proftpd/tls.conf i wykonujemy polecenia :

cp /etc/proftpd/tls.conf /etc/proftpd/tls.conf_orig

cat /dev/null > /etc/proftpd/tls.conf

vi /etc/proftpd/tls.conf

<IfModule mod_tls.c>

TLSEngine on

TLSLog                     /var/log/proftpd/tls.log

TLSProtocol                SSLv23

TLSOptions                 NoCertRequest

TLSRSACertificateFile      /etc/proftpd/ssl/proftpd.cert.pem

TLSRSACertificateKeyFile   /etc/proftpd/ssl/proftpd.key.pem

TLSVerifyClient            off

TLSRequired                on

</IfModule>

Jeżeli jest używany TLSRequired, wtedy dozwolone są tylko połączenia TLS (uniemożliwia to połączenia jakiemukolwiek użytkownikowi, który używa klienta FTP bez wspomagania TLS).  Bez wpisania tych linii i używania TLSRequired oba połączenia TLS i non-TLS  są dozwolone i zależą od tego na co pozwala klient FTP.

Restratujemy Proftpd:

/etc/init.d/proftpd restart

Teraz można próbować łączyć  się poprzez korzystanie z klienta FTP. Powinno się dodatkowo skonfigurować klienta FTP z użyciem TLS (to jest konieczne podczas używania TLSRequired).

Jeżeli pojawią się problemy z TLS, najlepiej przejrzeć logi pliku TLS w /var/log/proftpd/tls.log.