SMB Nedir? Port 445, Dosya Paylaşımı ve SYSVOL

SMB (Server Message Block), bir ağdaki bilgisayarların dosya, klasör ve yazıcı paylaşmasını sağlayan protokoldür. Windows’ta ağ sürücüsü bağladığınızda, paylaşılan bir klasöre eriştiğinizde ya da ağ yazıcısına baskı gönderdiğinizde çalışan şey budur ve 445 numaralı portu kullanır.

Kurumun ortak deposunu düşünün. Raflarda binlerce klasör var ve hiçbiri masanıza taşınmıyor: rafın önüne gidiyorsunuz, klasörü yerinde açıyorsunuz, işinizi görüp yerine bırakıyorsunuz. Depo görevlisi elindeki listeye bakıp hangi koridora girebileceğinizi söylüyor, diğer koridorların kapısı size kapalı.

Bu makale kurumsal network kurulumu hizmetimizin dosya ve paylaşım katmanına odaklanır; SMB’nin içinde yer aldığı protokol zincirinin tamamını kurumsal ağ protokolleri rehberimizde ele alıyoruz.

SMB Nedir, CIFS ile Aynı Şey mi?

SMB, istemci ile sunucu arasında çalışan bir dosya paylaşım protokolüdür. 1980’lerde IBM’de doğdu, Microsoft tarafından geliştirilerek Windows ağlarının paylaşım standardı haline geldi. Bugün Windows, Linux (Samba ile) ve macOS aynı protokolü konuşur. Linux dünyasının kendi paylaşım protokolü olan NFS ise kullanıcıyı bambaşka bir şeyle tanır: isimle değil, sayısal bir numarayla. Aynı klasörü iki protokolle birden paylaştırdığınızda izin çakışmalarının neden çıktığını NFS nedir rehberimizde ele alıyoruz.

CIFS ise ayrı bir protokol değil, SMB’nin 1990’lardaki bir sürümünün adıdır. Açılımı Common Internet File System’dir ve pratikte SMB 1.0’ı işaret eder. Terim hâlâ karşınıza çıkar: NAS cihazlarının arayüzünde “CIFS” seçeneği görürsünüz, Linux tarafında dosya sistemi tipi cifs diye geçer. İkisini eş anlamlı kullanmak günlük konuşmada sorun çıkarmaz, ama bir cihaz size ısrarla “CIFS” diyorsa arkasında eski bir sürüm çalışıyor olabilir ve bu, güvenlik bölümünde göreceğimiz asıl meseleye bağlanır.

Paylaşım ile Aktarım Aynı Şey Değildir

SMB’yi anlamanın en hızlı yolu, onu yapmadığı işle karşılaştırmak. Bir dosyayı bir yerden bir yere taşımak ile bir dosyayı olduğu yerde ortak kullanmak farklı ihtiyaçlardır:

• Aktarımda dosyanın bir kopyası çıkar ve başka bir yere gider. FTP, FTPS ve SFTP ile e-posta eki bunu yapar.
• Paylaşımda dosya olduğu yerde kalır, siz uzaktan üzerinde çalışırsınız, kaydettiğinizde değişiklik doğrudan oradaki dosyaya işlenir.

Depo benzetmesinde aktarım, klasörü koltuğunuzun altına alıp gitmektir. Paylaşım ise rafın önünde açıp okumak, gerekeni yazıp yerine koymaktır.

Bu ayrımın neden önemli olduğu, SMB olmadığında ne olacağına bakınca çıkıyor. Ortak bir dosya paylaşım katmanı yoksa insanlar dosyayı birbirine gönderir. On kişilik bir ekipte bir teklif dosyası e-postayla dolaşmaya başladığında ortaya on ayrı kopya çıkar ve hiçbirinin hangisinin güncel olduğu belli değildir. Kimse yanlış bir şey yapmamıştır; sistem yanlıştır. SMB’nin çözdüğü asıl problem storage değil, tek bir gerçeğin nerede durduğu sorusudur.

SMB Sürümleri: SMBv1’den SMBv3’e

Protokolün üç kuşağı var ve aralarındaki fark hız değil, güvenlik.

Pratik sonuç kısa: bugün kurulan hiçbir ortamda SMBv1 açık olmamalı. SMB 3.x, kabloyu dinleyen birinin dosya içeriğini okumasını engelleyen şifrelemeyi getirdi; öncekilerde bu koruma yok. İkinci ve üçüncü kuşağın tam tanımını Microsoft, açık protokol belgeleri arasında MS-SMB2 adıyla yayımlıyor.

Bağlantının hangi sürümle kurulduğunu Windows’ta Get-SmbConnection komutuyla görürsünüz. Ama burada atlanan bir ayrıntı var: bu komut yalnızca o anda açık olan bağlantıları listeler. Hiçbir paylaşıma erişmemişseniz çıktı boş gelir ve bu bir arıza değildir; ölçülecek bir bağlantı yoktur.

Doğru sıra önce paylaşıma gitmek, sonra sormaktır:

Get-ChildItem \\sunucu01\Paylasim
Get-SmbConnection

İlk satır bağlantıyı kurar, ikincisi onu raporlar. Çıktıdaki Dialect sütunu kullanılan sürümü, Encrypted sütunu trafiğin şifrelenip şifrelenmediğini, Signed sütunu ise imzalanıp imzalanmadığını gösterir.

Dialect değeri 2.0.2 gibi eski bir sürüm gösteriyorsa, ortamda geriye uyumluluk için düşülmüş bir bağlantı var demektir. Bağlantı kapandığında kayıt da listeden düşer, yani bu komut geçmişi değil o anki durumu gösterir.

Aynı bilgiyi sunucu tarafından da alabilirsiniz ve çoğu zaman daha kullanışlıdır, çünkü tek seferde o sunucuya bağlı bütün istemcileri listeler:

Get-SmbSession | Select-Object ClientComputerName, ClientUserName, Dialect

Lab’daki domain controller dc01’de, Ankara’daki ankmuh01 istemcisinde ayse.demir oturum açıkken çalıştırdığımda iki kayıt döndü. İstemcinin genel IPv6 önekini <önek> ile kısalttım:

ClientComputerName                ClientUserName        Dialect
<önek>:8925:c990:b928:aac9        SISTEMKUSU\ANKMUH01$  3.1.1
<önek>:8925:c990:b928:aac9        SISTEMKUSU\ayse.demir 3.1.1

Üç şey okunuyor. Bağlantılar SMB 3.1.1 ile kurulmuş, yani mevcut en güncel sürüm. Aynı istemciden iki oturum var: biri bilgisayar hesabının (ANKMUH01$, computer policy’si için), biri kullanıcının. İstemci de sunucuya IPv6 üzerinden bağlanmış. Eski bir cihazın hangi sürümle bağlandığını merak ediyorsanız bakılacak yer burasıdır: istemcinin başına gitmeniz gerekmez, sunucu kaydını tutuyor. İstemci tarafındaki Get-SmbConnection ise lab’da standart kullanıcıya Access is denied verdi, o komut yönetici oturumu ister.

SMB ve Active Directory: SYSVOL ve Grup İlkesi Dağıtımı

Buraya kadar SMB’yi bir kolaylık gibi anlattık: ortak klasör, ağ sürücüsü, yazıcı. Domain ortamında ise SMB bir kolaylık değil, zorunluluktur, çünkü GPO’lar onun üzerinden dağıtılır.

Mekanizma iki parçalıdır ve bu ayrımı bilmek teşhiste doğrudan işe yarar:

1. Policy’nin tanımı dizinde durur. Hangi policy’nin hangi birime bağlandığı, kimlere uygulanacağı dizinde tutulur ve oraya LDAP ile bakılır.
2. Policy’nin dosyaları SYSVOL’de durur. Ayarların gerçek içeriği, betikler ve şablonlar Domain Controller üzerindeki SYSVOL adlı paylaşımdadır ve oraya SMB ile erişilir.

SYSVOL, her Domain Controller’da otomatik olarak oluşan ve tüm DC’ler arasında eşitlenen özel bir paylaşımdır. Domain’e katılmış her bilgisayar, açılışta ve düzenli aralıklarla oraya bağlanıp kendisine düşen policy dosyalarını okur.

Depo benzetmesinde SYSVOL, sıradan raflardan ayrı duran mühürlü dolaptır: içindeki belgeler kimseye tek tek elden verilmez, her masaya kopyası kendiliğinden ulaştırılır. Hero görselindeki dolaptan masalara giden ince bakır iplikler tam olarak bunu anlatıyor.

Buradan çıkan sonuç, sahada en çok kafa karıştıran arızalardan birini açıklıyor:

Kullanıcı oturum açar ama hiçbir policy uygulanmaz. Kimlik doğrulama ayrı bir protokolle yürüdüğü için giriş sorunsuz tamamlanır; bozuk olan taraf paylaşım katmanıdır. Ekrandaki hata mesajında ne “SMB” ne “SYSVOL” geçer, çoğu zaman hiç mesaj da çıkmaz.

SYSVOL’ün İçi Neye Benziyor?

Lab’daki dc01’de SYSVOL altındaki Policies klasörüne baktığımda yedi klasör çıktı ve hepsinin adı bir GUID’di. Get-GPO -All çıktısıyla yan yana koyunca eşleşme şöyle:

{31B2F340-016D-11D2-945F-00C04FB984F9}   Default Domain Policy
{6AC1786C-016F-11D2-945F-00C04fB984F9}   Default Domain Controllers Policy
{56C95E2E-151A-429D-8FAF-537990D245EB}   PC_ANK_LAPS
{6888FAE9-F1EE-417D-A43F-357BC72215FE}   PC_IZM_LAPS
{6727C790-B03C-46B0-A07E-3E1FB216E294}   PC_DC_LAPS
{9FD2C803-B701-4545-8952-571DF73C37AD}   PC_TIER0_LAPS
{7BB711BF-4AC2-4049-B776-DC017A9319B8}   USER_ARKAPLAN

Soldaki klasör adları, sağdaki okunabilir GPO isimleriyle eşleşir. GPO’nun adı dizinde durur, dosyaları ise bu GUID klasöründe. İlk ikisi her domain’de otomatik oluşan varsayılanlardır. İlk ikisinin GUID’i her domain’de aynıdır, diğerleri oluşturulurken rastgele üretilir. Yedi klasörün yedisi bir GPO’ya karşılık geldi, sahipsiz klasör yoktu.

Eşleşmeyi yönetim konsolundan da doğrulayabilirsiniz. Group Policy Management’ta bir GPO seçilip Details sekmesine geçildiğinde, Unique ID alanında SYSVOL’de gördüğünüz klasör adının aynısı yazar.

Aynı ekran, bu makalenin tezini tek başına özetleyen bir satır daha taşıyor:

• User version: 1 (AD), 1 (SYSVOL)
• Computer version: 0 (AD), 0 (SYSVOL)

Lab’daki USER_ARKAPLAN yalnız kullanıcı ayarı taşıyor, bu yüzden kullanıcı tarafı bir kez değişmiş, bilgisayar tarafı hiç.

Konsol, aynı policy’nin sürüm numarasını iki ayrı yer için ayrı ayrı gösteriyor: biri dizindeki tanım, diğeri paylaşımdaki dosyalar. Sağlıklı bir ortamda bu iki sayı eşittir.

Eşit olmadıklarında ise elinizde doğrudan bir teşhis vardır: dizin tarafı güncellenmiş ama dosyalar o Domain Controller’a ulaşmamış demektir. Policy yönetim konsolunda doğru görünür, istemcide uygulanmaz. GPO’ların yarım uygulandığı arızalarda ilk bakılacak yerlerden biri budur.

Bu göstergenin sahadaki karşılığını bir müşteride bizzat gördüm. İki şubeli bir ortamda şubelerden birinde GPO’lar yarım uygulanıyordu; SYSVOL’e baktığımda GPO klasörlerinin bir kısmının o sunucuya hiç ulaşmadığı ortaya çıktı. Vakanın tamamını, belirtiden hangi katmana inildiğini anlatan akışla birlikte LDAP nedir rehberimizde ele alıyoruz.

Buradan çıkan ve bu makaleye ait olan ders şu: arıza dizinde değil, dosyaların taşınmasındaydı. Dizin tarafı policy’lerin var olduğunu söylüyordu ve yönetim konsolunda her şey normal görünüyordu; eksik olan, o dosyaları Domain Controller’lar arasında eşitleyen replikasyondu. Yukarıdaki iki sayıya bakmak, günler sürecek bir aramayı tek ekrana indirebilirdi.

Bir teşhis ayrıntısı da buradan çıktı ve şaşırtıcıydı: SYSVOL’e sunucunun IP adresiyle erişilemiyor. ankmuh01’de ayse.demir oturumunda aynı paylaşımı üç adla denedim:

\\192.168.1.10\SYSVOL              -> Network access is denied.
\\ad.sistemkusu.com\SYSVOL         -> calisir
\\dc01.ad.sistemkusu.com\SYSVOL    -> calisir

PowerShell’in Test-Path komutu IP’li yolda yalnız False döndürür ve “yol yok” der, asıl hata .NET ile açınca görünür: Network access is denied. NETLOGON da IP’yle aynı biçimde düştü. Paylaşımlar orada: net view \\192.168.1.10 ikisini de listeledi.

Arka planda olan şu. Adla erişimde istemci Kerberos kullanıyor: klist çıktısında cifs/dc01.ad.sistemkusu.com için bir bilet vardı. IP adresi için Kerberos bileti alınamaz, istemci NTLM’e düşer. dc01’in güvenlik kaydında IP’li denemelerle aynı dakikalarda üç NTLM doğrulaması (olay 4776) vardı ve üçü de başarılıydı. Yani kimlik doğrulandı, erişimi reddeden istemcinin kendisiydi. Windows, SYSVOL ve NETLOGON için karşı tarafın kimliğini doğrulayan (mutual authentication) bir bağlantı isteyebilir, NTLM bunu sağlamaz. Bu lab’da o ayarın hangi kaynaktan geldiğini ayrıca okumadım.

Pratik sonucu şu: bir betiği ya da yapılandırmayı IP ile yazdıysanız, ortam sağlıklıyken bile çalışmaz ve hata mesajı sizi yetki aramaya yönlendirir. Doğru yol her zaman domain adıdır.

Herkes Okur, Kimse Değiştiremez

Policies klasörünün izinlerine bakınca SYSVOL’ün neden böyle kurulduğu netleşiyor. dc01’de Advanced Security Settings penceresinde yedi satır vardı, hiçbiri üst klasörden devralınmamıştı (Inherited from: None). Alttaki her GPO klasörü bu izinleri devralır:

Kimliği doğrulanmış her kullanıcının okuma yetkisi olması zorunludur, çünkü policy’yi uygulayan taraf kullanıcının kendi bilgisayarıdır. Şirket duvar kağıdını dağıtan bir GPO düşünün: o duvar kağıdının uygulanabilmesi için oturum açan kullanıcının ilgili klasörü okuyabilmesi gerekir. Okuyamazsa policy sessizce uygulanmaz.

Ama liste aynı zamanda sınırı da çiziyor: Authenticated Users’ın yetkisi okuma ve yürütmeyle biter. Silme, değiştirme ya da yeni dosya ekleme hakkı yoktur; tam denetim yöneticilerde ve sistemdedir. Kurumun yazılı kuralları herkese açıktır ama kuralı değiştirmek herkesin işi değildir.

Üçüncü satır ise yetkilendirmenin ne kadar ince ayarlanabildiğini gösteriyor. Group Policy Creator Owners, adı üstünde, yeni GPO oluşturabilen bir gruptur ve bu yüzden yazma yetkisi vardır; ama tam denetimi yoktur, yani başkasının oluşturduğu bir policy’yi silip yönetemez. Oluşturduğu policy’nin sahibi olarak CREATOR OWNER üzerinden kendi klasöründe tam yetki kazanır. Bir yetkiyi “hepsi ya da hiçbiri” diye vermek yerine, yapabileceği işe göre vermenin somut karşılığı budur.

GPO’ların nasıl tasarlandığını ve hangi birime nasıl bağlandığını Active Directory GPO yönetimi rehberimizde ele alıyoruz.

SMB Güvenliği: SMBv1 Neden Kapatılmalı?

SMBv1, bilgisayar tarihinin en pahalı güvenlik açıklarından bazılarının taşıyıcısı oldu. 2017’de dünya çapında yayılan WannaCry ve NotPetya fidye yazılımları, SMBv1’deki bir açığı kullanarak ağ içinde kendi kendine yayıldı. Kullanıcının bir dosyaya tıklamasına bile gerek yoktu; protokolün kendisi yayılma yolu oldu.

Alınması gereken üç önlem var ve üçü de birbirinden bağımsız:

• SMBv1’i kapatın. Windows Server 2016 ve sonrasında zaten varsayılan olarak kapalı gelir, ama eski sürümlerden yükseltilen sistemlerde açık kalmış olabilir.
• Port 445’i asla internete açmayın. Dış erişim gerekiyorsa VPN kurulur. Bu port kurum ağının dışına çıkmamalıdır.
• SMB imzalamayı zorunlu tutun. İmzalama olmadan, araya giren biri trafiği değiştirebilir.

Sunucunun bu üç konuda nerede durduğunu tek komutla görürsünüz:

Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, RequireSecuritySignature, EncryptData

Lab Domain Controller’ımızda çıkan sonuç şu:

EnableSMB1Protocol       : False
RequireSecuritySignature : True
EncryptData              : False

İlk iki satır iyi haber: SMBv1 kapalı ve imzalama zorunlu. Üçüncü satır ise bu bölümün asıl dersi.

Bağlantının SMB 3.1.1 ile kurulduğunu az önce ölçmüştük, yani sunucu da istemci de şifrelemeyi destekliyor. Buna rağmen EncryptData değeri False, çünkü SMB şifrelemesi kendiliğinden açılmaz; açıkça etkinleştirilmesi gerekir. Desteklemek ile kullanmak aynı şey değil.

Dizin katmanının benzer bir sıkılaştırma ihtiyacı olduğunu ve orada da imzalamanın belirleyici olduğunu Active Directory güvenlik sıkılaştırması rehberimizde ele alıyoruz.

Sahadan: Yetki Geri Alınır, İzin Kalır

Protokolü sıkılaştırmak işin yarısı. Diğer yarısı, o paylaşımın içindeki izinlerin zamanla ne hale geldiği, ve orada gördüğüm en sinsi şey şuydu.

Danışmanlık verdiğim bir kurumda paylaşım izinlerini denetlerken, İnsan Kaynakları’nın maaş dosyalarını tuttuğu klasörde beklenmedik bir kayıt buldum: birisi kendi kullanıcı hesabını, tek tek, o klasöre izinli olarak eklemişti. Grup üzerinden değil, doğrudan kendi adına.

Bunu yapabilmesi için o an geniş bir yetkisi olması gerekiyordu; yönetici yetkisiyle klasöre gidip kendini izin listesine yazmıştı. Tehlikeli olan kısmı ise yetkisini kaybettikten sonra başlıyor.

Şöyle düşünün: bir gün o kişinin yönetici yetkisi geri alınır, sıradan bir kullanıcıya döner, ve herkes sorunun çözüldüğünü varsayar. Oysa domain yetkisi bir grup üyeliğidir, klasördeki tekil izin ise ayrı bir kayıttır. Grubu değiştirmek o kaydı silmez. Kişi sıradan bir kullanıcı olarak, yıllar sonra bile, kurumun maaş dosyalarını açmaya devam edebilir. Kimse fark etmez, çünkü kimse bakmaz.

Bu kaydın bulunması da kolay değil. Bir paylaşımın altında onlarca klasör, onların altında onlarca alt klasör varsa, izin listelerini tek tek gezmek günler alır. Aramayı hızlandıran şey şu: devralmayı kıran klasörleri arayın. Sağlıklı bir yapıda izinler tepeden aşağı devralınır; biri araya elle bir kayıt eklediğinde o klasörde devralma kesilmiş olur. Yukarıdaki ekran görüntüsünde Inherited from sütununun ne işe yaradığı tam da budur: None yazan satır, oraya elle eklenmiş bir izin demektir.

Vakanın bıraktığı iki kural, o günden beri kurduğum her dosya sunucusunda geçerli:

1. Kritik klasörlerde asla tekil kullanıcı ataması yapmayın, grup atayın. Kişiye izin verildiğinde o izin kişiyle birlikte kalır; gruba verildiğinde kişi gruptan çıkarıldığı an erişim de biter. İşten ayrılma, departman değişikliği ve yetki geri alma süreçlerinin tek tek klasör gezmeden yürümesinin yolu budur.
2. Domain admin yetkisi “iş görülsün” diye dağıtılmaz. Sahada bu yetki çoğu zaman teknik bir gerekçeyle değil, pratiklik gerekçesiyle veriliyor: bir kurulum takılıyor, kimse sebebini aramak istemiyor, hesap yönetici grubuna atılıp geçiliyor. O andan sonra o kişinin dokunduğu her klasörde böyle bir kayıt bırakma imkânı var demektir.

SMB Teşhisi: Erişilemeyen Paylaşımlar ve Yetki Sorunları

SMB arızalarının çoğu üç katmandan birinde çıkar ve teşhis sırası bu katmanları alttan üste izlemelidir. Alttaki katman bozukken üsttekini incelemek zaman kaybıdır.

1. Ağ katmanı: port açık mı?

Test-NetConnection -ComputerName sunucu01 -Port 445

TcpTestSucceeded değeri False dönüyorsa sorun paylaşımda değil, ağdadır: firewall kuralı, kapalı sunucu ya da yanlış isim çözümlemesi. Bu adımda başarısızsanız izin ayarlarına bakmanın anlamı yok.

2. İsim katmanı: doğru makineye mi bağlanıyorsunuz?

Paylaşıma kısa adla (\\sunucu01) erişilip tam adla (\\sunucu01.ad.sistemkusu.com) erişilemiyorsa ya da tersi geçerliyse, sorun SMB’de değil isim çözümlemededir. Bu ayrımı DNS nedir rehberimizde ele alıyoruz.

3. Yetki katmanı: iki ayrı izin listesi var.

Bu, sahada en çok yanlış teşhis edilen konudur. Bir paylaşımın iki izin katmanı vardır ve erişim ikisinin kesişimidir:

Kullanıcı ikisinden hangisi daha kısıtlıysa onu görür. Paylaşım izninde tam yetki verip NTFS’te salt okunur bırakırsanız, kullanıcı yazamaz ve hata mesajı hangi katmandan geldiğini söylemez. Depo benzetmesinde bu, koridora girme izniniz olması ama rafın kilitli olması gibidir: kapıdan geçersiniz, klasörü açamazsınız.

Teşhis sırasında bu yüzden her iki listeyi de kontrol edin; yalnız birine bakıp “yetki var” demek en sık yapılan hatadır.

Sonuç: Tek Gerçeğin Nerede Durduğu

SMB’yi sıradan bir kolaylık gibi görmek kolaydır: ağ sürücüsü bağlanır, klasör açılır, iş görülür. Oysa çözdüğü problem storage değil, bir kurumda tek bir gerçeğin nerede durduğu sorusudur. Dosya bir yerde durduğu ve herkes ona gittiği sürece “hangi kopya güncel?” sorusu hiç doğmaz. O tek yeri yetki matrisiyle birlikte kurduğumuz işi dosya sunucusu ve NAS kurulumu sayfasında anlatıyoruz.

Domain ortamında ise rolü sessizce büyür. Kimlik doğrulama başka bir protokolün işidir, dizin sorgusu başka birinin; ama kurumun yazılı kuralları makinelere SMB üzerinden ulaşır. Bu yüzden SMB tarafındaki bir arıza kendini SMB arızası olarak göstermez: kullanıcı oturum açar, her şey normal görünür ve yalnızca policy’ler uygulanmaz.

Depo görevlisi size hangi koridora girebileceğinizi söyler, klasörü yerinde açarsınız, işinizi görüp yerine bırakırsınız. Sistem doğru kurulduğunda kimse onu fark etmez; bozulduğunda ise ortaya çıkan belirti neredeyse hiçbir zaman deponun kendisini işaret etmez.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn