Archiwa tagu: Linux

Przechowywanie kluczy SSH programu PuTTY w KeePass

Opublikowany przez
Odpowiedz

Powyżej wersji 0.60 klient SSH PuTTY posiada wsparcie dla tzw. agenta uwierzytelniania. Dołączona do programu wersja – Pageant – pozwala na załadowanie do pamięci wielu kluczy i uwierzytelnianie nimi nie tylko połączeń z lokalnego komputera, ale w przypadku połączeń przez serwery OpenSSH również kolejnych sesji (agent forwarding).

KeeAgent – plugin do KeePass \”podszywający się\” pod Pageanta pozwala na przechowywanie kluczy SSH w rekordach bazy kdbx programu KeePass.

Aby dodać plugin do menadżera kluczy, z pobranego ze strony projektu archiwum kopiujemy plik KeeAgent.plgx do katalogu instalacji. Przy ponownym uruchomieniu, zostanie on skompilowany i załadowany.
Pliki kluczy SSH (ppk) dodajemy do rekordów w \”zaawansowanych\” jako załączniki. Jeżeli są zabezpieczone hasłem – podajemy je jako hasło we wpisie.

Następnie przechodzimy do konfiguracji PuTTY.
\"\"
Wybierając opcję \”Attempt authentication using Pageant\” zapewniamy sobie możliwość logowania kluczem z odblokowanej bazy KeePass z komputera lokalnego.
Opcja \”Allow agent forwarding\” pozwala na użycie Pageanta w uwierzytelnianiu kolejnych połączeń z serwera do którego jesteśmy zalogowani. Nie powinno się używać tej opcji na serwerach, którym nie ufamy – klucze mogą zostać użyte wtedy również przez administratora systemu (podobnie jak hasło, które wpisywaliśmy jak dotąd).

Po właściwej konfiguracji, po połączeniu do serwera który rozpoznaje nasz klucz powinno ukazać nam się powiadomienie jak i gotowa do pracy sesja zdalnej konsoli.

\"\"

Limitowanie zasobów użytkowników przy suPHP z wykorzystaniem stosu PAM

Opublikowany przez
Odpowiedz

Nowy pracownik naszej firmy, administrator Linux Mateusz Małek, w ramach prowadzonych testów podatności przeprowadził udany, a zarazem trywialny atak mający wpływ na stabilność pracy jednego z naszych serwerów hostingowych.

Poniżej prezentujemy sposób częściowy zabezpieczenia serwera przed lokalnymi atakami DoS wykonywanymi przy pomocy funkcji shell_exec() w PHP, jeżeli wykorzystywany jest suPHP.

W przypadku wykorzystywania suPHP, uruchamiane z UID+GID użytkownika procesy nie przechodzą przez stos PAM, tym samym nie dotyczą ich limity pam_limits.so z /etc/security/limits.conf. Opisane poniżej kroki zmieniają to zachowanie.

Patchowanie, rekompilacja i rekonfiguracja suPHP

  1. Nakładamy przygotowany patch na suPHP:

    cd /usr/local/directadmin/custombuild
    cp $(find -type d -name \’suphp-0*\’) suphp-patched;
    cd suphp-patched;
    wget http://mkwm.zielonki.info/suphp_patch.diff -O – | patch -p1

  2. Tworzymy nową usługę PAM – np. \”suphp\”, uwzględniającą moduł pam_limits z dedykowaną konfiguracją – wykorzystanie globalnego pliku konfiguracyjnego stwarza pewne problemy (o czym za chwilę):

    cat << EOF > /etc/pam.d/suphp
    auth sufficient pam_permit.so
    session required pam_limits.so conf=/usr/local/suphp/etc/security/limits.conf
    session required pam_permit.so
    EOF

  3. Konfigurujemy limity dotyczące liczby procesów (tak, serwer uległ \”trzynastu znakom\”). Dedykowany plik konfiguracyjny rozwiązuje problem z sytuacją, w której konta użytkowników nie posiadają żadnej wspólnej grupy – w przypadku ustawienia limitów dla wszystkich (*), nie ma możliwości podniesienia ich dla konkretnego użytkownika/grupy (co powoduje problemy z działaniem usług czy administrowaniem serwerem):

    cat << EOF > /usr/local/suphp/etc/security/limits.conf
    * soft nproc 20
    * hard nproc 20
    EOF

  4. Rekompilujemy suPHP i dodajemy \”pam_service=suphp\” do sekcji global w jego pliku konfiguracyjnym.

Porada dnia: Instalacja UPS\’a APC na Debianie Lenny.

Opublikowany przez
Odpowiedz

1. Opis sytuacji:

1. Serwer Debian Lenny
2. APC Smart UPS 1500

2. Instalacja:

W pierwszej kolejności podłączamy UPS\’a do serwera za pomocą kabla USB.

Aktualizujemy repozytoria:

apt-get update

Instalujemy niezbędne pakiety:

apt-get install apcupsd

2.1 Konfiguracja apcupsd.conf

W pliku konfiguracyjnym:

nano /etc/apcupsd/apcupsd.conf

zamieniamy:

UPSCABLE smart

na

UPSCABLE usb

zamieniamy:

UPSTYPE apcsmart
DEVICE /dev/ttys0

na:

UPSTYPE usb
DEVICE

2.2 Konfiguracja apcupsd

W pliku konfiguracyjnym /etc/default/apcupsd

nano /etc/default/apcupsd

zamieniamy:

isonfigured no

na:

isonfigured yes

3. Uruchamiamy usługę apcupsd oraz sprawdzamy połączenie:

/etc/init.d/apcupsd start
apcaccess

Debian Lenny + AD 2008R2, czyli Samba > 3.4.1

Opublikowany przez
Odpowiedz

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 &amp;&amp; /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