Bu dosyadaki kayıtların formatı şu şekildedir:
[KullanıcıAdı]:[ParolaHashi]:[KullanıcıIDsi]:[GrupIDsi]:[HomeDizini]:[ÖntanımlıShell]
Kullanıcı adı kullanıcıyla ilgili işlemlerde kullanılır, ancak işletim sistemi için kullanıcıyı ifade eden asıl bilgi “Kullanıcı ID” bilgisidir ve erişim hakları bu ID değerine göre değerlendirilir. Aynı ID değerine birden fazla kullanıcı sahip olabilir. Buna göre ID değeri “0” olan bir başka kullanıcı adı da bulunabilir ve “root” kullanıcı adıyla kullandığımız kullanıcı ile aynı erişim haklarına sahip olacaktır. Bu özellik genellikle Unix sistem yöneticileri tarafından “root” kullanıcısının şifresinin unutulmasına karşı yedek yönetici hesabı amacıyla kullanılır.
Kali üzerinde pek çok öntanımlı kullanıcı gelir. Ancak bunlardan sadece “root” kullanıcısı sisteme interaktif shell bağlantısı kurabilir. Bu da Unix sistem yöneticilerinin eskiden beri uyguladığı geçersiz öntanımlı shell ayarı ile sağlanır. “/etc/passwd” dosyasında tanımlı öntanımlı shell uygulamalarını incelediğimizde aşağıdaki listeyi görüyoruz:
Görünen o ki root kullanıcısı dışında “couchdb” ve “postgres” kullanıcıları için öntanımlı shell olarak bash tanımlanmış. Ayrıca “arpwatch” ve “speech-dispatcher” kullanıcıları için de “/bin/sh” shell’i tanımlanmış. Bu durum “root” dışında yukarıda sayılan kullanıcıların da sisteme shell erişimi yapabileceği anlamına geliyor olabilir mi? Bunun cevabını verebilmek için bir de “/etc/shadow” dosyasına göz atmamız gerekiyor.
“/etc/passwd” dosyasındaki kayıtların formatını açıklarken 2. alanda parola hash’inin bulunduğunu söylemiştik. Ancak bu dosyadaki bu alan tüm kullanıcılar için “x” karakteri ile tanımlanmış. Bunun nedenini birazdan açıklayacağım. Parola hash’leri eğer “/etc/passwd” dosyasında bu şekilde tanımlanmışsa asıl “hash” değerleri “/etc/shadow” dosyasında tanımlanmaktadır.
Yukarıda geçerli bir öntanımlı shell’e sahip olan kullanıcılar arasında sadece “root” kullanıcısının bir parola hash’ine sahip olduğunu görebilirsiniz. Hiçbir hash değeri “!” veya “*” olamayacağına göre diğer kullanıcı hesaplarına login olmak mümkün değildir. (“*” hiç parola oluşturulmamış, “!” ise hesap kilitlenmiş anlamına gelmektedir.) Dolayısıyla Kali dağıtımı öntanımlı olarak sadece “root” kullanıcısı ile login olabilecek şekilde dağıtılmaktadır.
“/etc/shadow” dosyasının varlık amacını açıklayabilmek için öncelikle “/etc/passwd” ve “/etc/shadow” dosyalarının erişim haklarını inceleyelim.
Yukarıda gördüğünüz gibi “/etc/passwd” dosyasının erişim hakları tüm kullanıcıların bu dosyayı okuyabileceği biçimde ayarlanmıştır. Bunun nedeni tüm kullanıcıların kullandığı komutların bir kısmının passwd dosyasındaki bilgileri kullanma ihtiyacıdır, örneğin komutu çalıştıran kullanıcının home dizininin bilme ihtiyacı, dosya erişim izinlerini anlaması gereken komutların kullanıcı ID’si ve kullanıcı adı arasındaki dönüşümü yapabilmesi ihtiyacı gibi. Eğer parola hash değerleri bu dosya içinde tutulursa sisteme erişebilen tüm kullanıcılar kendi kullanıcılarının ve diğer tüm kullanıcıların parola hash’lerini elde edebilirler. Parola hash’leri elde edildikten sonra çevrimdışı parola kırma saldırılarına tabi tutulabilirler. İşte bu nedenle parola hash’leri sadece “root” (yani user ID’si “0” olan kullanıcı veya kullanıcılar) tarafından erişilebilecek olan “shadow” dosyasında saklanırlar.
Bununla birlikte her kullanıcının kendi parolasını değiştirebilmesi gerekmektedir. “passwd” komutuyla yapılan bu işlemin gerçekleştirilebilmesi için bu komutun erişim haklarının çalışma anında “root” kullanıcı seviyesine yükselmesi gerekmektedir. Bu hakkın “s” bit tanımı ile yapıldığını daha önce açıklamıştık. Bu komutun erişim haklarında execute yetkisinin yerinde “s” harfini görmemizin sebebi budur, çünkü “passwd” komutu “shadow” dosyasında değişiklik yapabilmelidir.
Kullanıcı yönetimi ile ilgili bir başka önemli dosya da “/etc/group” dosyasıdır.
[GrupAdı]:[GrupParolaHashi]:[GrupIDsi]:[GrupÜyeleriListesi]
Grup parolası nedir derseniz, var olma sebebi “newgrp” komutu ile başka bir grubun da haklarına sahip olabilmektir. Ancak grup parolası paylaşılan bir parola olduğundan ve pek de kullanım ihtiyacı doğmadığından genellikle tanımsız olur.
Her kullanıcının passwd dosyası kaydında bir grup ID’si bulunur. Ancak bir kullanıcı birden fazla grubun üyesi olabilir ve bu tanımlama group dosyasında yapılır. Yukarıdaki örnekte sadece “audio” grubu için “pulse” kullanıcısı belirtilmiş.”pulse” kullanıcısının “passwd” dosyasındaki tanımına baktığımızda ise bu kullanıcının grup ID’sinin 126 olduğunu görüyoruz.
Kali dağıtımının genel amaçlı Unix / Linux sistemler gibi ciddi bir kullanıcı ve grup yönetimine ihtiyaç bulunmadığından neredeyse hiç grup mantığı kullanılmamış kullanıcılar için.
Öntanımlı Kali dağıtımında shell erişimi mümkün olarak bulunan tek kullanıcı olan “root” kullanıcısının parola hash’ini ve “shadow” dosyasındaki diğer kayıt alanlarını inceleyelim.
“shadow” dosyasındaki kayıt formatı aşağıdaki gibidir:
- Kullanıcı adı: “root”
- Parola hash’i ve diğer hash bilgileri: $6$VcS1CHvP$UYi9fhLxsvVB7bVz8E06yPaBkseiJ8UlPHqphUeEgpZnxDqZx5bJFpDw3aM4gnSj0079Wbj15XFJG6gRHUfBh/
- Parola’nın son değiştirildiği tarih (Unix epoch’tan itibaren gün cinsinden): 16925 (4 Mayıs 2016)
- Parola’nın değiştirilebileceği en yakın gün (0 herhangi bir zaman değiştirilebileceği anlamına gelir): 0
- Parola’nın kaç gün sonra değiştirilmeye zorlanacağı (99999 sınırsız süre boyunca değiştirilmeyebileceği anlamına gelir): 99999
- Kullanıcının kaç gün önceden parola değişikliği hakkında uyarılacağı: 7
- Parola kullanım süresi dolduktan kaç gün sonra hesabın kilitleneceği: Tanımsız
- Hesabın kilitlendiği tarih (Unix epoch’tan itibaren gün cinsinden): Tanımsız
- Rezerve alan (daha sonra kullanılmak üzere ayrılmıştır)
- Hash türü
- $1 = MD5
- $2 =Blowfish
- $2a=eksblowfish
- $5 =SHA-256
- $6 =SHA-512
- Salt değeri
- Hash değeri
Kali’nin öntanımlı olarak sadece “root” kullanıcısının interaktif kullanabileceği şekilde geldiğini söylemiştik. Şimdi yeni bir kullanıcı ekleyelim.
Yukarıda öncelikle “btrisk” adlı bir kullanıcıyı ekledik, ancak bunu yaparken “-u” opsiyonuyla kullanıcı id’sini “0” olarak belirledik. User id’si zaten “0” olan bir kullanıcı olduğu için “-o” opsiyonunu da kullandık, aksi takdirde “useradd” uygulaması bizi uyarıyor ve kullanıcıyı oluşturmuyor.
“passwd” ve “shadow” dosyalarında “btrisk” kullanıcı kayıtlarının oluşturulduğunu görüyoruz. Öntanımlı olarak “/bin/sh” shell’i ve “/home/btrisk” home dizini tanımlandı. Elbette kullanıcıyı eklerken bunları da belirleyebilirdik. Daha sonra “btrisk” kullanıcısıyla sisteme logon olabilmemiz için home dizininin mevcut olması lazım, bu nedenle bu dizini de oluşturuyoruz.
“btrisk” kullanıcısının user id’sini “0” olarak belirlememin sebebi birazdan size Linux’un erişim haklarını kontrol ederken kullanıcı adının değil user id’nin esas alındığını göstermek. Bunu yapmak için bunca zahmete katlanmaya da gerek yok. “passwd” dosyasında manuel olarak user id bilgisini “0” yapmam yeterli olurdu.
Şimdi “btrisk” kullanıcısı olarak Kali’ye logon olalım.
“btrisk” kullanıcısı ile login olduktan sonra bir shell açtığımızda “btrisk” kullanıcı için tanımlandığı gibi “/home/btrisk” dizinine yerleştik ve “shell” olarak da “sh” shell’ini kullanıyoruz. Ancak “id” ve “whoami” gibi komutların kafası karıştı ve bizi “root” olarak gösteriyor. Sistem açısından ise biz gerçekten “root” haklarına sahibiz, çünkü kullanıcı adının değil user id’sinin önemi var.
Genel olarak kullanıcı erişimi veya kullanıcı yönetimi konularından bahsederken atlanmaması gereken konulardan birisi de “switch user” (su) komutudur. Tabi bir de bununla bağlantılı olan “sudo” komutu var.
Bildiğiniz gibi bir sisteme yönetici hakları ile bağlandığınızda ne yaptığınızı iyi bilmeniz gerekir. Sürekli olarak sistem yöneticisi olarak sistemde işlem yapmayı istemezsiniz, çünkü yapacağınız bir hata veya çalıştırabileceğiniz bir kodda bulunan zararlı yazılım sisteme ciddi zarar verebilir. Bu nedenle prensip olarak sisteme düşük haklara sahip bir standart kullanıcı olarak bağlanıp sadece gerektiğinde haklarınızı yükseltmeniz gerekmektedir. Tabi bu bir iş amacıyla kullanılan ve hatta bir ağ servisi veren kritik sunucular için doğru, ancak Kali’nin böyle bir amacı yok. Eğer siz Kali üzerinde uygulama geliştirme veya yeni araçlar geliştirme işlemleri yapmayacaksanız Kali’ye zarar verseniz de yapacağınız tek şey sıfırdan bir kurulum yapmak veya Kali’nin canlı dağıtımını kullanmak olacaktır. Bu nedenle bu genel prensibe uymuyoruz. Ama yine de Linux için önemli olan bu konuyu atlamayacağız.
“su” ve “sudo” komutlarını anlatmak için sistem üzerinde sıradan bir kullanıcı tanımlayalım. Bu defa “adduser” adlı farklı bir komutu kullanacağım, çünkü bu komut home dizinini de oluşturmak dahil pek çok işi bir defada yaparak bizi biraz işten kurtarıyor (yukarıda “useradd” komutunu kullanmıştık).
Gördüğünüz gibi “btriskblog” adlı bir kullanıcı oluşturduk. Bu kullanıcının id’si sistem tarafından 1000 olarak verildi, grup id’si de 1002. Her iki açıdan da sıradan bir kullanıcı. Şimdi “btriskblog” kullanıcısıyla sisteme erişelim ve daha sonra “root” kullanıcısına “su” komutuyla geçelim.
“btriskblog” kullanıcısı ile logon olduktan sonra “su” komutu ile “root” kullanıcısı oluyoruz. Bunun için “root” kullanıcısının parolasını girmemiz lazım. “su” komutu sadece “root” kullanıcısına geçmek için kullanılmıyor, bu nedenle “su root” da diyebilirdik, ancak öntanımlı olarak bir parametre verilmediğinde “su” komutu “root” kullanıcısına geçilmek için kullanılıyor.
Shell içinde “su” komutu ile “root” kullanıcısı olarak tekrar logon oluyoruz. Proses listesinde “su” komutunun parent proses’inin 1715 numaralı ve “btriskblog” kullanıcısının hakları ile çalışan “bash” prosesi olduğu görülüyor. Bu proses’ten hemen sonra da “root” kullanıcısına ait “bash” proses’i başlıyor. Yani bu yeni shell prosesi btriskblog kullanıcısının bash shell proses’inden farklı. Bu nedenle yeni shell’den “exit” komutuyla çıktığımızda bir önceki shell’e dönüyoruz.
“sudo” komutu “su” komutu ile ilişkili ancak birçok açıdan çok farklı. Kali dağıtımının diğer Linux dağıtımlarından farklı olduğunu ve aslında Linux işletim sistemini öğrenmek için diğer platformların daha uygun olduğunu makalemizin başında belirtmiştik. Örneğin Ubuntu linux bir “root” kullanıcısı içerir ancak öntanımlı olarak bu kullanıcının parolası atanmamıştır (tabi siz kendiniz bu parolayı belirleyebilirsiniz).
Fakat sistem yöneticisi hakları ile bir işlem yapılması gerektiğinde “sudo” komutu kullanılarak sadece o işleme özel sistem yöneticisi hakları ile işlem gerçekleştirilir. Kali üzerinde normal bir kullanıcı (btriskblog) ile sistem yöneticisi hakları gerektiren bir işlem yapmaya kalkalım.
“adduser” uygulaması sıradan kullanıcımızın path tanımı üzerinde dahi bulunmadığından bu uygulamanın tam yolunu yazarak uygulamayı çalıştırıyoruz. Ancak uygulama yeterli hakka sahip olmadığımız hakkında bizi uyarıyor. Bunun üzerine “sudo” komutu ile bu uygulamayı çalıştırmayı deniyoruz. “sudo” komutunun “su” komutundan en büyük farkı şu; “su” komutunda farklı bir kullanıcı profiline geçiş yaparken geçiş yaptığımız kullanıcının parolasını girmemiz gerekiyor, “sudo” komutunda ise mevcut kullanıcı parolamızı girmemiz yeterli. Ancak bu işlemi de her kullanıcı yapamıyor. Bunu yapabilecek kullanıcıların “/etc/sudoers” dosyasında tanımı olması gerekiyor.
Öncelikle “su” yaparak “btriskblog” kullanıcımızın başarısız “sudo” denemesinin log kaydını “/var/log/auth.log” dosyası içinde görelim. Log kaydında “btriskblog” kullanıcısının “adduser” komutunu “sudo” yaparak çalıştırmak istediği ancak “sudoers” dosyası içinde tanımlanmadığı için başarılı olamadığını görebiliyoruz.
Şimdi “root” kullanıcısı olarak “btriskblog” kullanıcısını “/etc/”sudoers” dosyasına ekleyelim.
Diğer pek çok konfigürasyon dosyası gibi “sudoers” dosyasının da açıklanmaya muhtaç pek çok özelliği var. Ancak burada sadece “btriskblog” kullanıcısına verdiğimiz “sudo” yetkisini açıklayacağım.
Birinci ALL ifadesi “btriskblog” kullanıcısının herhangi bir terminalden (uzaktan veya konsoldan) sudo komutunu çalıştırabileceğini, ikinci ve üçüncü ALL ifadeleri herhangi bir kullanıcı veya grup adına bunu yapabileceğini, dördüncü ve son ALL ifadesi de bu işlemi tüm komutlar için yapabileceğini ifade ediyor. Eğer isteseydik tüm bu kriterler bazında kısıtlama yapabilirdik.
Bu tanımın altında “%” işareti ile başlayan tanımda “sudo” grubuna dahil olan kullanıcılarında bizim tanımladığımız haklara sahip olacağı belirtiliyor. Bu durumda “btriskblog” kullanıcısı için ayrıca bir hak tanımlayacağımıza bu kullanıcıyı “usermod” komutuyla “sudo” grubuna dahil edebilirdik.
Şimdi bu tanımınızı yaptıktan sonra kullanıcı ekleme işlemini tekrar deneyelim.
Bu defa “btriskblog” kullanıcısının parolasını girmemiz bu işlemi gerçekleştirmek için yeterli oldu.
Yine sudo hakkımızı kullanarak “sudo” işlemiyle ilgili “başarılı” işlem kayıtlarını görebildik. “sudo” komutu görüldüğü gibi sadece başarısız denemeleri değil başarılı “sudo” işlemlerini de loglayarak hesap verebilirliği de destekliyor. Böylece sistem yöneticisi “sudo” hakkını verdiği kullanıcıların gerçekleştirdiği yüksek yetkili işlemleri de izleyebilir.
<<Önceki Bölüm Sonraki Bölüm>>
