Eğer şu anda bir systemctl restart komutunun önünde Permission denied mesajıyla takılıp kaldıysanız veya kaçıncı kez sudo ile işinizi halledip sonra neden her şeyi root ile yapmadığınızı düşündüyseniz, bu metin tam size göre. Sorun root'un iyi mi kötü mü olduğu değil. Sorun, hangi işin gerçekten root gerektirdiği ve hangi işin sadece birinin izinleri ayarlamaya üşendiği için root ile yapıldığıdır.
Hangi iş gerçekten root erişimi gerektirir
Root bir güvenlik özelliği değil; bir güvenlik bypass'ıdır. Linux çekirdeği her işlem için izni UID ve capability'ler üzerinden kontrol eder. UID sıfır, tüm bu kontrollerin atlandığı anlamına gelir. Bu nedenle root olmadan mümkün olmayan işlerin listesi kısa ve nettir:
CAP_NET_BIND_SERVICEayarlamadan 1024 altındaki portları (80 ve 443 gibi) açmak- Dosya sistemini mount ve unmount etmek, bölümlemeyi değiştirmek, mount edilmiş diskte
fsckçalıştırmak chownile dosya sahipliğini başka bir kullanıcıya değiştirmek- Sistem yollarına paket kurmak,
/etcve/usrdizinlerine yazmak - Sistem düzeyinde systemd unit'lerini yönetmek,
journalctlile tam jurnalı okumak - Güvenlik duvarı kurallarını değiştirmek ve çekirdek modülü yüklemek
"Sadece root ile çalışan" diğer her şey neredeyse her zaman bir dosya izni veya dizin sahipliği sorunudur. Örneğin www-data kullanıcısıyla çalışan ve /var/www/site/uploads dizinine yazamayan bir PHP-FPM servisi root ile de düzelmez; sadece sorunu, kötü niyetli bir yüklemenin aynı erişimle çalıştırılacağı güne kadar gizler.
Yaygın hata: izin sorununu çözmek yerine root kullanmak
Burada hata yapılır. Kullanıcı proje dizininde chmod -R 777 ile sorunu çözer, site ayağa kalkar ve üç ay sonra sunucu bir web shell'e dönüşmüştür. Belirtisi her zaman aynı şey değildir, ancak tekrarlayan bir kalıbı vardır: /tmp içinde tuhaf dosyalar, ps aux ile görülen kworker benzeri isimlerle bilinmeyen süreçler ve sitenin ziyaretçisi olmadığı saatlerde yüksek giden trafik.
Doğru yol, sahipliği servis kullanıcısına vermek ve izni kısıtlamaktır:
chown -R www-data:www-data /var/www/site
find /var/www/site -type d -exec chmod 755 {} \;
find /var/www/site -type f -exec chmod 644 {} \;Eğer servisin yazma iznine ihtiyacı varsa, tüm projeyi değil sadece o tek dizini açın. Bu, sınırlı bir güvenlik açığı ile tamamen saldırganın kontrolüne geçmiş bir sunucu arasındaki farktır.
sudo'ya karşı su: hangisini seçmeliyim
SSH üzerinden doğrudan root kullanıcısıyla girişi bir kenara bırakın. Klişe bir tavsiye olduğu için değil, herkesin aynı hesapla giriş yaptığında /var/log/auth.log içinde hangi insanın hangi komutu çalıştırdığını anlayamayacağınız gibi pratik bir nedenden dolayı. sudo ile her çalıştırma gerçek kullanıcı adıyla kaydedilir ve sonradan rm -rf komutunu kimin çalıştırdığını sorabilirsiniz.
| Yöntem | Uygun olduğu durum | Ödediğiniz bedel |
|---|---|---|
Kişisel kullanıcıyla sudo | Çok kişilik ekip, üretim sunucusu | Her komutta fazladan bir adım, /etc/sudoers yönetimi ihtiyacı |
Root parolasıyla su - | Tek kişilik sunucu, acil onarım | Root parolası paylaşılır, kullanıcı izi kaybolur |
| SSH anahtarıyla doğrudan root girişi | İlk kurulum anı dışında hiçbir yerde | Her otomatik betik tüm sunucuyu ele geçirebilir |
Belirli bir betik için parolasız erişim vermek zorundaysanız, onu açık değil kısıtlı hale getirin:
deploy ALL=(ALL) NOPASSWD: /bin/systemctl restart myapp.service/etc/sudoers.d/deploy içindeki bu satır yalnızca belirli bir servisi yeniden başlatma izni verir. Aynı kullanıcı bash'i sudo ile çalıştırmak isterse reddedilir. Bu iki durum arasındaki farkı, bir CI/CD token'ı sızdığında anlarsınız.
Root ve servisler: gerçekten tehlike yarattığınız yer
Bugün çoğu Linux servisi özel bir kullanıcıyla ve root olmadan çalışır. Özel bir unit yazıp içine User=root koyarsanız, Nginx veya Node.js'teki olası bir güvenlik açığını tam bir ele geçirmeye dönüştürüyorsunuz. Doğru unit yapısını ve bağımlılıkları systemd'de unit dosyası sayfasında görebilirsiniz, ancak basit kural şudur: servis 1024 altı bir porta ihtiyaç duyuyorsa, tam root değil capability verin.
[Service]
User=appuser
AmbientCapabilities=CAP_NET_BIND_SERVICE
NoNewPrivileges=trueNoNewPrivileges=true satırını ciddiye alın. O olmadan, her alt süreç yeniden yükselebilir ve tüm kısıtlamayı atlayabilir.
Root'un tek yol olduğu durumlar
Bazen gerçekten başka yol yoktur. Dosya sistemi read-only hale gelmiş bir sunucuyu kurtarmak, bozulmuş bir veritabanının kilidini açmak veya /etc/ssh üzerinde yanlış bir chmod sonrası SSH erişimini geri getirmek. Bu durumlarda acil konsolu veya rescue modunu kullanın, işi bitirin ve hemen ardından neyin bozulduğunu inceleyin. Herhangi bir değişiklikten önce logları alın; her servisin log konumunu Linux log konumları sayfasında listeledik.
Az söylenen pratik bir nokta: root ile yıkıcı bir komuttan önce pwd ile mevcut yolu kontrol edin ve boş değişkenle rm -rf kullanmaktan kaçının. rm -rf "$DIR"/* kalıbı, DIR boş olduğunda rm -rf /* haline gelir. Bu hata üretim sunucularında gerçekten olur ve geri alınması saatler sürer.
Felaketi gerçekten önleyen SSH yapılandırması
/etc/ssh/sshd_config içindeki üç satır en büyük etkiye sahiptir:
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy adminDeğişiklikten sonra, mevcut oturumu kapatmadan önce ikinci bir terminalde anahtarla girişin çalıştığını test edin. Bunu yapmazsanız ve sshd'yi yeniden başlatırsanız, kendinizi sunucudan dışarı atmış olursunuz ve konsoldan girmeniz gerekir. SSH portunu da değiştiriyorsanız, yeniden başlatmadan önce güvenlik duvarı kurallarını ekleyin; komutların hızlı referansı Linux güvenlik duvarı komutları sayfasında mevcuttur.
Üretim sunucularında bu ayarları elle değil, başlangıç imajı veya provisioning betiği şablonuna koyun. Yeni bir özel veya bulut sunucusu teslim aldıysanız, yapmanız gereken ilk iş tam da bu birkaç satırdır. Daha hafif iş yükleri için, bir Linux hosting de çekirdek ve bölümleme ile kendiniz uğraşmadan aynı düzeyde kontrol sağlar.
Sık sorulan sorular
SSH'ten root girişini devre dışı bırakmak yeterli mi?
Hayır. PermitRootLogin no yalnızca doğrudan girişi kapatır. Parolasız sudo yetkisi olan bir kullanıcınız varsa veya başka bir hesapta zayıf bir parola varsa, saldırgan aynı yolu izler. PasswordAuthentication no seçeneğini de etkinleştirmeli ve anahtarları yönetmelisiniz.
Neden sudo'dan sonra oluşturulan dosyaların sahibi root oluyor?
Çünkü komut UID sıfır ile çalıştırılmıştır ve yeni dosyalar aynı sahiple oluşturulur. Bu, servisin sonradan onları okuyamamasına veya değiştirememesine neden olur. Çözüm, komutu sudo -u www-data ile çalıştırmak veya iş sonrası sahipliği düzeltmektir.
sudo ile doas arasındaki fark nedir ve hangisini seçmeliyim?
doas daha hafiftir ve daha basit bir yapılandırma dosyasına sahiptir, ancak sudo ayrıntılı log kaydı ve hassas komut kontrolü gibi daha fazla özellik sunar. Birden fazla operatörün bulunduğu bir üretim sunucusu için sudo'yu seçerim. Yalnızca birkaç komutu yükseltmek istediğiniz kişisel bir makine için doas yeterlidir.
Birinin root erişimini kötüye kullandığını nasıl anlarım?
Önce last ve lastlog komutlarına bakın, ardından çalıştırılan komutlar için grep sudo /var/log/auth.log komutunu kontrol edin. ~/.ssh/authorized_keys içindeki bilinmeyen anahtarlar ve /etc/cron.d içindeki yeni cron job'ları, saldırganın kalıcılık sağlamak için kullandığı iki yaygın yerdir.
Bu metinden tek bir şey kalacaksa, şu olsun: root'u gerçekten ihtiyaç duyan işler için saklayın ve ona her sığındığınızda asıl sorunun ne olduğunu sorun. Cevap neredeyse her zaman bir dosya iznidir, erişim eksikliği değil.