Mengapa nginx memulai proses sebagai root?

Saya telah menginstal server nginx. Saya baru saja memeriksa port mendengarkan dan melihat yang berikut:

$ 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)
.
.
.

Dan saya hanya tertarik mengapa ada empat proses nginx dijalankan sebagai pengguna 'www-data' dan satu sebagai 'pengguna root'?

Proses yang Anda perhatikan adalah proses master, proses yang memulai semua proses nginx lainnya. Proses ini dimulai oleh skrip init yang memulai nginx. Alasan proses ini berjalan sebagai root adalah hanya karena Anda memulainya sebagai root! Anda dapat memulainya sebagai pengguna lain, tetapi Anda harus memastikan bahwa semua sumber daya yang dibutuhkan nginx tersedia untuk pengguna ini. Itu biasanya paling tidak / var / log / nginx dan file pid di bawah / var / run /.

Yang paling penting; Hanya proses root yang dapat mendengarkan port di bawah 1024. Server web biasanya berjalan pada port 80 dan / atau 443. Itu artinya perlu dimulai sebagai root.

Kesimpulannya, proses master yang dijalankan oleh root benar-benar normal dan dalam banyak kasus diperlukan untuk operasi normal.

Sunting: Menjalankan apa pun saat root membawa risiko keamanan implisit. Biasanya pengembang perangkat lunak jenis ini memiliki banyak pengetahuan tentang vektor serangan dan sangat berhati-hati untuk mengeksekusi sesedikit mungkin sebagai root. Pada akhirnya Anda hanya perlu percaya bahwa perangkat lunaknya berkualitas baik.

Jika Anda masih merasa tidak nyaman, ada cara untuk menjalankan nginx sebagai pengguna lain dan masih menggunakan port di bawah 1024. Anda dapat menggunakan iptables untuk mengalihkan semua lalu lintas masuk pada port 80 ke port lain, misalnya 8080, dan minta nginx mendengarkan port tersebut.

Sebagian besar server (Apache, Nginx, dll.) Memiliki proses induk yang dimiliki oleh root yang kemudian mem-copy salinan node pekerja menggunakan pengguna yang kurang kredensial. Dalam hal ini www-data.

Contoh

Jika Anda melihat nginxfile konfigurasi /etc/nginx/nginx.conf,, Anda akan melihat baris seperti ini:

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

Sebagian besar server memiliki opsi yang mirip dengan ini yang menentukan pengguna apa yang menjalankan node slave dan berapa banyak dari mereka.

Keamanan

Mengekspos layanan yang memiliki akses root sering disebut sebagai ketidakamanan potensial. Namun Anda sering harus root untuk mengikat ke port yang berkisar 1-1024, jadi benar-benar tidak ada yang dapat Anda lakukan jika Anda ingin server mendengarkan pada katakan port 80 atau 443.

Juga jika suatu layanan ditulis dengan baik dan dikonfigurasikan dengan benar, layanan itu sendiri tidak serta merta merusak postur keamanan Anda. Aplikasi yang berjalan di atas Apache & Nginx benar-benar sumber sebenarnya dari buffer overflow atau serangan injeksi SQL server karena aplikasi adalah layanan yang mengekspos titik masuk untuk data yang cacat agar dapat disuntikkan ke dalam tumpukan server Anda.

Apache & Nginx sendiri, umumnya tidak menerima input apa pun di luar metode GET / POST yang mereka terima.

Begitulah cara aplikasi dikemas. Pada kebanyakan * nix pengaturan default adalah pengguna yang tidak memiliki hak istimewa tidak dapat mendengarkan pada port <1024 dan server web menggunakan 80 dan 443.

Linux 2.2+, Solaris 10+ dan FreeBSD semuanya memungkinkan pengguna non-root untuk mendengarkan pada port yang lebih rendah dari 1024, hanya saja tidak secara default. Sebagian besar telah menerima penggunaan rootsehingga tetap digunakan.

Selain akses untuk mengikat port istimewa Anda perlu memastikan pengguna yang menjalankan nginx memiliki akses ke semua file yang dibutuhkan. Anda mungkin tidak perlu pergi sejauh ini tetapi hanya mengatur izin yang benar pada file / direktori. Anda juga perlu memeriksa bahwa skrip startup tidak melakukan ulimitperubahan licik seperti perubahan (seperti tampaknya mysql selalu).

Kemampuan Linux

setcapdan getcapmembiarkan Anda mengubah atau melihat cap_net_bind_servicekemampuan untuk dieksekusi. Ini akan berlaku bagi siapa saja yang mengeksekusi biner.

setcap cap_net_bind_service=+ep /usr/sbin/nginx

SELinux menyediakan kemampuan untuk mengkonfigurasi dan mengontrol kemampuan di tingkat pengguna.

Pengaturan sistem freebsd

Pengaturan port yang dicadangkan bersifat global ke sistem

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

Hak Istimewa Solaris

Solaris memberikan kontrol halus atas hak istimewa di tingkat pengguna. Ini adalah hak istimewa untuk apache tetapi mereka cenderung bekerja untuk nginx juga.

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

Saya ingin menambahkan jawaban untuk semua orang. Meskipun nginx dimulai sebagai root, itu sebenarnya tidak berjalan sebagai root. Pengguna (nginx, www-data, dll) yang sebenarnya sedang berjalan seperti biasanya login yang dibatasi / dipenjara (Anda tidak dapat login dengannya, hanya file tertentu yang dapat diakses). Ini adalah salah satu kelebihan menggunakan Linux untuk server web dibandingkan dengan Windows. Proses ini disebut fork( Anda dapat menemukan rincian lebih lanjut dalam artikel Wikipedia ini ) dan juga menggunakan setuiddan / atau setgid( yang juga dijelaskan dalam artikel Wikipedia) untuk mengubah pengguna dan / atau grup. Dalam pengaturan yang aman, peretas tidak akan dapat mengakses proses induk dan memanfaatkan akun root. Ini tidak selalu benar karena peretas dapat memanfaatkan semacam eksploitasi untuk mendapatkan akses root (ada kerentanan di nginx 1.4.0 dan di bawahnya yang memungkinkan peretas mendapatkan akses root).