Turvariskide v ähendamine PAM ja OpenSSH kasutades

1. LUG @ ITCOLLEGE 2007 Turvariskide vähendamine PAM ja OpenSSH kasutades Viktor Larionov <viktor.larionov@salva.ee>

2. PAM • PAM ehk Pluggable authentication moduleson põhimõtteliselt mehhanism – kus mitu madala-taseme autentimise skeemi on integreeritud ühte kõrgeima taseme API’sse. Sellega rakendused, mis nõuavad autentimist, saavad selleks kasutada PAM API’t sõltumata sellest missugused autentimise mehhanismid on PAM’i taga. • (Wikipedia: http://en.wikipedia.org/wiki/Pluggable_Authentication_Modules) • Faktid: • Välja töötatud SUN Microsystems’i poolt. • RFC ilmunud oktoobris 1995 • Adapteeritud Common Desktop Enviroment’i autentimisraamistikus • Iseseisva pakettina ilmunud Linux-PAM nime all RedHat Linux 3.0.4’is 1996nda aasta augustis. • Standartne pakett mida leiab enamuses *nix tüüpi operatsiooni süsteemis • Ka Mac OS X toetab PAM’i. • Standartiseeritud X/OPEN UNIX standartiseerimise projekti raames. • Viimase tulemusena on saanud ametliku nimetuse “X/Open Single Sign-on standart”. • Kõige tähtsamad tehnilised faktid: • Just oma “pluggable” loomu poolest PAM kasutab dünaamiliselt linkitud koodi. • Samas PAM’is on rakendatud ka tagavara staatiline linkimise algorütm – juhul kui dünaamiline algorütm ei tööta vms. • Mitte kõik PAM realisatsioonid töötavad ühte moodi – nt. Linux’i ja NetBSD PAM’id on suhteliselt erinevad. • - OpenBSD ei kasuta PAM’i väidetavalt just viimase argumendi tõttu. LUG @ ITCOLLEGE 2007

3. PAM Oluline “highlight”: enamus, tänapäeval kasutatavaid daemon’e ühilduvad PAM’iga, kas otseselt, või juurdelaaditava mooduli kaudu. Standartne Linux’i autentimise skeem kasutab PAM’i juurdepääsu õiguste kontrollimiseks. Vaikimisi konfiguratsiooni failid asuvad /etc/pam.d ja /etc/security /ETC/PAM.D – ON SISULISELT KATALOOG, KUS IGA RAKENDUSE KOHTA, MIS KASUTAB PAM’I OMA AUTENTIMISVAJADUSTE RAHULDAMISEKS, ON VÕIMALIK ÄRA MÄÄRATA MIS PAM’I MOODULEID JA MIS JÄRJEKORRAS TA KASUTAB. EHK MÄÄRATA AUTENTIMIS SKEEMI. LIHTNE NÄITE: Paigutades /etc/pam.d kataloogi faili sshd võite määrata et algusest klient autentib parooliga, kui see klappib siis tema rühma ja kasutaja nimi kontrollitakse access_list mooduli kaudu – nimelt kontrollitakse kas IP aadress (kui on) klappivad sellele kasutajale lubatud ligipääsu õigustega. Juhul kui ei – ligipääsu andmisest keeldutakse. Õnnestumise puhul võite kirjeldada ka edaspidiste kontrollimiste algorütmi – nt. pam_time mooduli järgi kontrollimine: s.t. Kontroll kas just sel päeval ja kellaajal on kasutajal õigus ligipääsemiseks. Kõikide kontrollide õnnestumise puhul – kasutaja saab ligipääsu, vastasel juhul, kui vähemalt üks tingimustest ei ole kooskõlas – ligipääsu andmisest süsteem keeldub, vaatamata sellele kas parool on õige või vale. LUG @ ITCOLLEGE 2007

4. PAM /etc/security On kataloog kus iga installeeritud PAM’i mooduli kohta määratakse ära tema parameetrid. Juhul kui see on vajalik, olemas ka moodulid mis ei vaja konfigureerimise nt. pam_passwd on moodul mis sisselülitamisel skeemi kontrollib kas kasutaja eksisteerib /etc/passwd’i failis. Mingit konfigureerimist ei nõua. On ka vastupidiseid näiteid: Näiteks PAM access mooduli kohta failis access.conf on võimalik määrata mis kasutajad, kust terminalist, ja mis IP-aadressilt on lubatud. Nt: + : root : 192.168.200.1 192.168.200.4 192.168.200.9 Kirje failis access_conf näitab et root kasutaja on lubatud ligipääsu aadressitelt 192.168.200.1,192.168.200.4, 192.168.200.9 juhul kui aadress kust kasutaja root küsib ligipääsu ei ole selles nimekirjas: ligipääsu – ei saa. -: ALL EXCEPT @dreamteam : LOCAL Keelab lokaalset ligipääsu kõigile kes, ei ole rühmas “dreamteam” Reegleid – töödeltatakse selles järjekorras milles neid esitatakse failis. Sellega minu jaoks heaks tavaks on algusest määrata kõik kasutajad ja aadressid kust nad peaksid Saama ligipääsu – ja lõpetada see nimekiri kirjega: -: ALL : ALL – mis keelab kõigile teistele ligipääsu ükskõik kust. (vaikimisi kui Teie juhus ei lange ühtegi reegli alla – loetakse seda kui õnnestunud login katset) LUG @ ITCOLLEGE 2007

5. PAM Mõningad tähtsamad PAM’i moodulid: pam_access– ligipääsu mäpp kasutaja/rühm vs. Lokaal ligipääs või IP aadress pam_cracklib– parooli tugevuse kontrollskeem. Juhul kui te vahetate oma parooli Käsuga passwd ja sisestate uueks parooliks “password” – siis pam_cracklib on just see kood mis hakkab Teile ütlema “häbi, häbi, häbi – see on sõnastiku sõna” pam_deny – blacklist kasutajatest, kellele on ligipääs keelatud. pam_securetty– nimekiri konsoolidest kust root on lubatud ligipääsu (üks hea võimalus piirata /etc/securetty kaudu root’le ligipääsu kaugelt. pam_limits – võimalik limiteerida kasutajatele ligipääsu resurssidele (maksimaalse loodava faili Suurus, maksimaalne käivitatavate protsesside arv, maksimaalne kasutatav mälu jne.) Üks hea võimalus piirata ära kasutajale kättesaadavad süsteemi resurssid, lisaks see annab võimaluse piirata neid ära ka kurjategijale – juhul kui ta peaks kasutaja kontot diskrediteerima. Täisnimekiri moodulitest, ja nende kirjeldused on saadaval KERNEL.ORG projektist aadressil: http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/ LUG @ ITCOLLEGE 2007

6. SSH Secure Shell or SSH is a network protocol that allows data to be exchanged over a secure channel between two computers. Encryption provides confidentiality and integrity of data. SSH uses public-key cryptography to authenticate the remote computer and allow the remote computer to authenticate the user, if necessary. Asendas vanu kaugterminale nagu rlogin, rsh ja telnet. SSH-1 välja töötatud 1995ndal aastal Helsinki ülikoolis. Olulisemad momendid: Lubab mitu autentimisviisi: keyboard_interactive, public key, challenge auth, RSA auth etc. etc. etc. SSH-2 on oma loomult pigem protokoll. Laiemas mõttes, SSH’na kirjeldatakse SSHd daemoni, mille kaudu suudetakse juhtida kaugmasinat. Kui olla päris aus – siis terminali kaugjuhtimist võiks nimetada üksikjuhtumiks. SSH’l on sisuliselt tunneli printsiip kus andmete vahendamiseks kasutatakse privaat, ja avaliku võtme alusel krüpteerimise algorütme. (http://en.wikipedia.org/wiki/ssh) LUG @ ITCOLLEGE 2007

7. SSH Turvalisuse parandamise momendid “at a glance”: SSH-1 protokoll on “deprecated” ja “insecure” KeyBoard Interactive autentimine, mida paljud meist eelistavad ei ole just kõige turvalisem viis – eriti juhul kui Te olete “security paranooik” ;) Turvalisem on kasutada public key + võtme parool autentimise. SSHd ja Putty puhul on see ilmelihtne! Tuleb lihtsalt genereerida PUTTYGen (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) utiliidi abil privaat võti, ning selle public-osa tuleb salvestada oma serveris kodukataloogi .ssh/authorized_keys. Nt. kui ma genereerisin võti, ja olen kasutaja viktor salvestan seda faili /home/viktor/.ssh/authorized_keys – nüüd selle võtme privaat osa omades ma pääsen sinna masinasse ligi. Loomulikult tasub failis /etc/ssh/sshd_config lubada public key autentimise.  Juhul kui tegemist on UNIX – UNIX ligipääsemisega siis klient masinas paigaldage oma Privaat võti kataloogi /home/viktor/.ssh/id_rsa ja avalik võti faili id_rsa.pub Juhul kui see on DSA võti, siis vastavalt  LUG @ ITCOLLEGE 2007

8. SSH Võtmed: Võib kasutada nii RSA kui DSA algorütmiga võtmeid. Juhul kui võti on krüpteeritud, selle kasutamisel küsitakse parool, vastasel juhul mitte. Alati on mõtekas krüpteerida võtmeid, minetea mis võib juhtuda. Äkki kaotate mälupulga või läptopi. Alati veenduge et Teie kodukataloogis kataloogi .ssh rekursiivsed õigused on 0700 või 0600 SSHd kontrollib seda samuti ja ei võta võtmeid kasutusele kui õigused ei ole vastavad, kuid See on Teie huvides. LUG @ ITCOLLEGE 2007

9. Mõned näited: PuttyGEN vaikimisi krüpteerib AES-256 algorütmiga. OpenSSL’i puhul enimlevinud on DES krüpteeritud võtmed, Kuigi ise eelistan samuti AES-256 LUG @ ITCOLLEGE 2007

10. SCP vs. FTP over SSL Või SFTP vs. FTPS LUG @ ITCOLLEGE 2007

11. Kokkuvõteks: • Kui me ei kasuta mingit autentimisalgorütmi – lülitame seda välja • Püüame kasutada võtme+võtme parooli alusel autentimise • CHROOT ei ole turvavahend (c) Linus Torwalds • Hea mõte on dubleerida turvameetmeid nii PAM kui SSHd tasemel. • SCP kasutamist piirata nii lihtsalt ei ole võimalik – ja ega vist ei • tasu seda teha. Tundub et lõppkokkuvõttes kahjum mis tuleneb selle piiramisest tuleb suuremaks kui kasu... LUG @ ITCOLLEGE 2007

12. TÄNAN TÄHELEPANU EEST !!! küsimused LUG @ ITCOLLEGE 2007