9

Я устанавливаю веб-сервер на основе 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? Или что я где-то неправильно настраиваю конфигурационный файл?

2 ответа2

14

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

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

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

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

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

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

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 для более подробной информации.

11

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .