Nginx neden süreci root olarak başlatıyor?

Nginx sunucusunu kurdum. Sadece dinleme bağlantı noktalarını kontrol ettim ve aşağıdakileri gördüm:

$ sudo lsof -nP -i | grep LISTEN
sshd       614     root    3u  IPv4   7712      0t0  TCP *:22 (LISTEN)
nginx      822     root    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
nginx      827 www-data    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
nginx      828 www-data    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
nginx      829 www-data    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
nginx      830 www-data    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
.
.
.

Ve neden sadece 'www-data' kullanıcısı, diğeri 'root user' olarak çalışan dört nginx işleminin olduğu ile ilgileniyorum?

Fark ettiğiniz işlem ana işlemdir, diğer tüm nginx işlemlerini başlatan işlem. Bu işlem nginx'i başlatan init betiği tarafından başlatılır. Bu işlemin root olarak çalışmasının sebebi sadece root olarak başlamanızdır! Başka bir kullanıcı olarak başlatabilirsiniz, ancak nginx'in ihtiyaç duyduğu tüm kaynakların bu kullanıcı için erişilebilir olduğundan emin olmanız gerekir. Bu genellikle en azından / var / log / nginx ve / var / run / altındaki pid dosyası olacaktır.

En önemlisi; Yalnızca root işlemleri 1024 altındaki portları dinleyebilir. Bir web sunucusu tipik olarak 80 ve / veya 443 numaralı portlarda çalışır. Bu, root olarak başlatılması gerektiği anlamına gelir.

Sonuç olarak, kök işlem tarafından yürütülen ana işlem tamamen normaldir ve çoğu durumda normal işlem için gereklidir.

Düzenleme: Her şeyi kök olarak çalıştırmak, gizli bir güvenlik riski taşır. Normalde bu tür yazılım geliştiricileri, saldırı vektörleri hakkında çok fazla bilgiye sahiptir ve root olarak mümkün olduğu kadar az çalışmasına büyük özen gösterir. Sonunda yazılımın iyi kalitede olduğuna güvenmek zorundasın.

Hala tedirgin hissediyorsanız, nginx'i başka bir kullanıcı olarak çalıştırmanın ve hala 1024'ün altındaki bağlantı noktalarını kullanmanın bir yolu var. 80. bağlantı noktasında gelen tüm trafiği başka bir bağlantı noktasına yönlendirmek için iptables kullanabilirsiniz, örneğin 8080 ve bu bağlantı noktasında nginx'in dinlemesini sağlayabilirsiniz.

Çoğu sunucuda (Apache, Nginx, vb.) Root tarafından sahip olunan, daha sonra onaylanmamış bir kullanıcı kullanarak çalışan düğümlerin kopyalarını çatallayan bir ana süreç vardır. Bu durumda öyle www-data.

Örnek

nginx'In config dosyasına bakarsanız, şöyle /etc/nginx/nginx.confsatırları fark edeceksiniz:

user nginx;
worker_processes 2; #change to the number of your CPUs/Cores
worker_rlimit_nofile 8192;

Sunucuların çoğu, yardımcı düğümleri hangi kullanıcının çalıştırmasını ve kaç tanesini çalıştırmasını şart koşanla benzer seçeneklere sahiptir.

Güvenlik

Kök erişimi olan hizmetleri göstermek, genellikle olası bir güvensizlik olarak adlandırılır. Ancak, genellikle 1-1024 arasında değişen bağlantı noktalarına bağlanmak için kök olmanız gerekir, bu nedenle bir sunucunun 80 veya 443 numaralı bağlantı noktalarını dinlemesini istiyorsanız, yapabileceğiniz hiçbir şey yoktur.

Ayrıca bir servis iyi yazılmışsa ve düzgün bir şekilde yapılandırılmışsa, kendi içinde olması, güvenlik duruşunuza mutlaka zarar vermez. Apache & Nginx'in üzerinde çalışan uygulamalar, gerçek anlamda arabellek taşması veya SQL sunucu enjeksiyon saldırıları kaynağıdır; çünkü uygulamalar sunucu yığınınıza enjekte edilecek hatalı biçimlendirilmiş verilerin giriş noktalarını gösteren hizmetlerdir.

Apache ve Nginx kendileri tarafından genellikle kabul ettikleri GET / POST yöntemlerinin ötesinde herhangi bir girişi kabul etmemektedir.

Uygulamanın paketlenme şekli. Çoğu * nix'te, varsayılan kurulum ayrıcalıklı olmayan bir kullanıcıdır ve <1024 numaralı bir bağlantı noktasında dinleyemez ve web sunucuları 80 ve 443 kullanır.

Linux 2.2+, Solaris 10+ ve FreeBSD'lerin hepsi root olmayan kullanıcıların varsayılan olarak değil, 1024'ten daha düşük portları dinlemelerine izin veriyor. Çoğu, kullanılmaya rootdevam ettiği için kullanımını kabul etti .

Ayrıcalıklı bağlantı noktasına bağlanma erişimi dışında, nginx çalıştıran kullanıcının ihtiyaç duyduğu tüm dosyalara erişebildiğinden emin olmanız gerekir. Muhtemelen bu kadar ileri gitmene gerek yok, sadece dosyalara / dizinlere izin ver. Ayrıca başlangıç ​​komut dosyalarının ulimitdeğişiklik gibi sinsi bir şey yapıp yapmadığını kontrol etmeniz gerekir (mysql gibi her zaman olduğu gibi).

Linux yetenekleri

setcapve bir çalıştırılabilir dosyanın özelliklerini getcapdeğiştirmenize veya görüntülemenize izin verin cap_net_bind_service. Bu ikiliyi yürüten herkes için geçerli olacaktır.

setcap cap_net_bind_service=+ep /usr/sbin/nginx

SELinux, yetenekleri kullanıcı düzeyinde yapılandırma ve kontrol etme yeteneği sağlar.

Freebsd sistem ayarları

Ayrılmış bağlantı noktası ayarları sistem için geneldir

sysctl net.inet.ip.portrange.reservedhigh=0
sysctl net.inet.ip.portrange.reservedlow=0

Solaris Ayrıcalıkları

Solaris, kullanıcı seviyesinde ince taneli ayrıcalık kontrolü sağlar. Bunlar, apache'nin ayrıcalıklarıdır, ancak nginx için de çalışma olasılıkları yüksektir.

/usr/sbin/usermod -K defaultpriv=basic,proc_exec,proc_fork,net_privaddr nginx

Herkesin cevaplarını başkalarına eklemek isterim. Nginx root olarak başlatılmış olmasına rağmen, aslında root olarak çalışmıyor. Kullanıcı (nginx, www-data, etc) aslında çalıştığı gibi genellikle kısıtlı / hapsedilmiş bir giriş yapıyor (bununla giriş yapamazsınız, sadece belirli dosyalara erişilebilir). Bu, Linux'un aksine, web sunucuları için Windows kullanmanın avantajlarından biridir. Bu işleme bir fork( bu Wikipedia makalesinde daha fazla ayrıntı bulabilirsiniz) denir ve ayrıca setuidve / veya setgid( bir Wikipedia makalesinde de açıklanmıştır) kullanılır.) kullanıcıyı ve / veya grubu değiştirmek için. Güvenli bir kurulumda, bir bilgisayar korsanı ana işleme erişemez ve kök hesaptan yararlanamaz. Bu, bir bilgisayar korsanı, kök erişimi sağlamak için bir tür istismardan yararlanabileceği için her zaman doğru değildir (nginx 1.4.0 ve sonrasında korsanların kök erişimi kazanmasına izin veren bir güvenlik açığı vardı).