Почему sudo требуется для запуска веб-сервера по указанному ip: порту?

Я устанавливаю веб-сервер на основе Python на своем компьютере с Debian.

Настроить:

• ОС Debian основана на виртуальных машинах, но я переключил VirtualBox с NAT на Bridged.
• IP настройки виртуальной машины = 192.168.1.7(согласно окну администратора моего маршрутизатора или ifconfig).
• Я успешно настроил переадресацию портов моего маршрутизатора для ssh и HTTP.
• Я успешно настроил динамический DNS моего маршрутизатора с помощью dyndns.com.

Независимо от того, какой конкретный веб-сервер Python я использую (Django, CherryPy, стандартная библиотека), я должен запустить веб-сервер @ 192.168.1.7:80, используя sudo. В противном случае я получаю ошибку об отсутствии разрешения на доступ к порту. Ни в одном руководстве по веб-серверу не упоминается необходимость использования sudoпри указании порта ip :.

Вопрос: почему я должен использовать sudoдля запуска этих веб-серверов? Это признак того, что я не должен использовать 192.168.1.7? Или что я где-то неправильно настраиваю конфигурационный файл?

Только процессы с правами root могут прослушивать привилегированные порты. Это стандартное соглашение о безопасности Unix.

Это стандартное поведение, когда непривилегированным пользователям не разрешается привязываться к привилегированным портам (номера портов ниже 1024). Поэтому приложение, которое хотело бы привязаться к порту 80, например, должно будет запускаться с привилегиями (обычно это означает запуск от имени пользователя root) для привязки к этому порту.

Обычный подход заключается в запуске небольшого процесса «слушателя» с привилегированным пользователем, который принимает соединение, а затем порождает непривилегированный процесс для обработки запроса. Отмена привилегий для обработки запроса производится по соображениям безопасности. Если кто-то может использовать процесс, который обрабатывает запрос, то обычно он позволяет злоумышленнику выполнять команды, используя те же привилегии, что и процесс обработки. Поэтому было бы плохо обрабатывать весь запрос, используя привилегированный процесс.

Однако для многих приложений в настоящее время принято работать без полномочий root; но такие процессы, конечно, не могут связываться с привилегированными портами в стандартной конфигурации. Таким образом, серверы, такие как Tomcat или JBoss, вместо этого связывались с высокими портами, такими как 8080, поэтому им не нужен привилегированный слушатель.

Конечно, если вы предоставите такой процесс Интернету, вы, вероятно, предоставите доступ к порту 80, поскольку каждый браузер сначала попытается подключиться к порту 80, когда используется протокол HTTP. Для решения этой проблемы обычно используется межсетевой экран или порт-транслятор между приложением и общедоступным Интернетом. Таким образом, запросы попадают в брандмауэр, запрашивающий порт 80, но брандмауэр передает запрос некоторому внутреннему хосту через порт 8080. Таким образом, настоящий веб-сервер может работать на высоких портах, в то же время общедоступный на порту 80.

- (internet request) ----> (port 80)[Firewall] ------> (port 8080)[Webserver]

Иногда это перенаправление просто выполняется с использованием iptablesправила NAT:

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

Это позволяет запускать непривилегированное приложение, прослушивающее порт 8080, в то время как все входящие запросы на порт 80 просто перенаправляются на порт 8080.

Однако, используя современные ядра Linux, есть еще одна возможность: использовать возможности.

setcap CAP_NET_BIND_SERVICE=+ep /some/webserver/binary

Это позволит binaryсвязываться с привилегированными портами даже при запуске от имени пользователя без полномочий root. Смотрите man capabilitiesдля более подробной информации.