Чому nginx запускає процес як root?

Я встановив сервер nginx. Я щойно перевірив порти прослуховування і побачив таке:

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

І мене просто цікавить, чому чотири nginx процеси виконуються як "www-data" користувач і один як "root user"?

Процес, який ви помітили, є головним процесом, процесом, який запускає всі інші процеси nginx. Цей процес запускається скриптом init, який запускає nginx. Причина, що цей процес запускається як root, просто в тому, що ви запустили його як root! Ви можете запустити його як інший користувач, але вам доведеться переконатися, що всі ресурси nginx доступні для цього користувача. Зазвичай це буде щонайменше / var / log / nginx та pid-файл під / var / run /.

Головне; Лише кореневі процеси можуть прослуховувати порти нижче 1024. Веб-сервер зазвичай працює у порту 80 та / або 443. Це означає, що його потрібно запускати як root.

На закінчення, головний процес, що запускається коренем, є цілком нормальним і в більшості випадків необхідним для нормальної роботи.

Редагувати: Запуск будь-чого як root несе в собі неявний ризик безпеки. Зазвичай розробники такого типу програмного забезпечення мають багато знань про вектори атаки і дуже уважно ставляться до того, щоб виконати якнайменше як root. Зрештою, ви просто повинні довіряти, що програмне забезпечення хорошої якості.

Якщо ви все ще відчуваєте себе непросто, є спосіб запустити nginx як інший користувач і все ж використовувати порти нижче 1024. Ви можете використовувати iptables для перенаправлення всього вхідного трафіку через порт 80 на інший порт, наприклад 8080, і змусити nginx прослуховувати цей порт.

Більшість серверів (Apache, Nginx тощо) мають батьківський процес, який належить root, який потім розщеплює копії робочих вузлів, використовуючи менш завірених користувачем користувачів. У цьому випадку це www-data.

Приклад

Якщо ви подивитеся на nginxконфігураційний файл /etc/nginx/nginx.conf, ви помітите такі рядки:

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

Більшість серверів мають подібні до цього параметри, які визначають, яким користувачем слід керувати веденими вузлами і скільки їх.

Безпека

Викриття служб, які мають кореневий доступ, часто згадується як потенційна небезпека. Однак вам часто доводиться мати root, щоб прив’язати до портів, що становлять 1-1024, тому насправді нічого не можна зробити, якщо ви хочете, щоб сервер слухав, наприклад, порти 80 або 443.

Крім того, якщо послуга добре написана та налаштована належним чином, вона сама по собі не обов'язково шкодить вашій безпеці. Програми, що працюють на вершині Apache & Nginx, справді є справжніми джерелами переповнення буфера або нападів на ін'єкцію SQL-сервера, оскільки програми - це сервіси, які відкривають точки входу для неправильно сформованих даних, що вводяться у ваш серверний стек.

Apache & Nginx самі по собі, як правило, не приймають жодних даних, окрім методів GET / POST, які вони приймають.

Це спосіб упаковки програми. У більшості * nix налаштування за замовчуванням - це непривілейований користувач, який не може слухати порт <1024, а веб-сервери використовують 80 та 443.

Linux 2.2+, Solaris 10+ та FreeBSD дозволяють користувачам, які не користуються коренем, слухати порти нижче 1024, але не за замовчуванням. Більшість прийняли використання, rootтому воно залишається у використанні.

Крім доступу для прив’язки до привілейованого порту, вам потрібно переконатися, що користувач, що працює з nginx, має доступ до всіх необхідних йому файлів. Напевно , вам не потрібно йти так далеко, але просто встановіть правильний дозвіл на файли / каталоги. Вам також потрібно перевірити, чи сценарії запуску не роблять нічого подібного підступногоulimit зміни (на зразок mysql, здається, завжди).

Можливості Linux

setcapі getcapдозволить вам змінити або переглянути cap_net_bind_serviceможливості для виконуваного файлу. Це буде діяти для всіх, хто виконує двійковий файл.

setcap cap_net_bind_service=+ep /usr/sbin/nginx

SELinux надає можливість налаштувати та керувати можливостями на рівні користувача.

Налаштування системи Freebsd

Параметри зарезервованих портів глобальні для системи

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

Привілеї Соляріса

Solaris забезпечує тонкозернистий контроль над привілеями на рівні користувача. Це привілеї для apache, але вони, ймовірно, можуть працювати і для nginx.

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

Я хотів би додати всім відповіді на всі інші. Хоча nginx запускається як root, він насправді не працює як root. Користувач (nginx, www-data тощо), який він фактично працює так, як це правило, обмежений / засуджений логін (ви не можете входити в нього, можна отримати доступ лише до певних файлів). Це один із плюсів використання Linux для веб-серверів на відміну від Windows. Цей процес називається a fork( ви можете знайти більш детальну інформацію в цій статті у Вікіпедії ), а також він використовує setuidта / або setgid( що також пояснено у статті Вікіпедії) змінити користувача та / або групу. У захищеному налаштуванні хакер не зможе отримати доступ до батьківського процесу та використовувати кореневий обліковий запис. Це не завжди вірно, оскільки хакер може використовувати якийсь подвиг для отримання доступу до коренів (була вразливість у nginx 1.4.0 і нижче, що дозволило хакерам отримати кореневий доступ).