Ответ 1

Хорошо, благодаря людям, которые указали систему возможностей и возможность CAP_NET_BIND_SERVICE. Если у вас есть последнее ядро, действительно можно использовать это, чтобы запустить службу как non-root, но связывать низкие порты. Короткий ответ заключается в том, что вы делаете:

setcap 'cap_net_bind_service=+ep' /path/to/program

И затем в любое время program выполняется после этого, он будет иметь возможность CAP_NET_BIND_SERVICE. setcap находится в пакете debian libcap2-bin.

Теперь для оговорок:

• Вам понадобится хотя бы ядро ​​2.6.24
• Это не будет работать, если ваш файл является script. (т.е. использует строку #! для запуска интерпретатора). В этом случае, насколько я понимаю, вам придется применить эту возможность к самому исполняемому интерпретатору, что, конечно же, является кошмаром безопасности, поскольку любая программа, использующая этот интерпретатор, будет иметь возможность. Я не смог найти какой-либо чистый и простой способ обойти эту проблему.
• Linux отключит LD_LIBRARY_PATH на любом program, который имеет повышенные привилегии, такие как setcap или suid. Поэтому, если ваш program использует свой собственный .../lib/, вам, возможно, придется искать другой вариант, например, переадресацию портов.

Ресурсы

• возможности (7) справочная страница. Прочитайте это долго и трудно, если вы собираетесь использовать возможности в производственной среде. Есть некоторые действительно сложные данные о том, как возможности наследуются в вызовах exec(), которые подробно описаны здесь.
• команда man setcap
• "Связывать порты ниже 1024 без root на GNU/Linux" : документ, который сначала указал мне на setcap.

Примечание: RHEL сначала добавила это в v6.

Ответ 2

Стандартный способ - сделать их "setuid", чтобы они запускались с правами root, а затем они отбрасывали эту привилегию root, как только они привязались к порту, но до того, как они начнут принимать к нему подключения. Вы можете увидеть хорошие примеры этого в исходном коде для Apache и INN. Мне говорят, что Lighttpd - еще один хороший пример.

Другим примером является Postfix, который использует несколько демонов, которые обмениваются данными по трубам, и только один или два из них (которые делают очень мало, за исключением принятия или испускания байтов) работают от имени root, а остальные работают с более низкой привилегией.

Ответ 3

Вы можете перенаправить порт. Это то, что я делаю для сервера политики Silverlight, работающего в ящике Linux

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 943 -j REDIRECT --to-port 1300

Ответ 4

Или исправьте свое ядро и уберите проверку.

(Вариант последней инстанции, не рекомендуется).

В net/ipv4/af_inet.c удалите две строки, которые читаются

      if (snum && snum < PROT_SOCK && !capable(CAP_NET_BIND_SERVICE))
              goto out;

и ядро больше не будет проверять привилегированные порты.

Ответ 5

Вы можете настроить локальный туннель SSH, например, если вы хотите, чтобы порт 80 ударил ваше приложение, привязанное к 3000:

sudo ssh [email protected] -L 80:localhost:3000 -N

Это имеет преимущество работы с серверами script и очень просто.

Ответ 6

Возможности файла не идеальны, потому что они могут прерываться после обновления пакета.

Идеальное решение IMHO должно быть способностью создавать оболочку с наследуемым набором CAP_NET_BIND_SERVICE.

Вот несколько запутанный способ сделать это:

sg $DAEMONUSER "capsh --keep=1 --uid=`id -u $DAEMONUSER` \
     --caps='cap_net_bind_service+pei' -- \
     YOUR_COMMAND_GOES_HERE"

capsh утилита может быть найдена в пакете libcap2-bin в дистрибутивах Debian/Ubuntu. Вот что происходит:

• sg изменяет эффективный идентификатор группы на идентификатор пользователя демона. Это необходимо, потому что capsh оставляет GID неизменным и мы определенно не хотим его.
• Устанавливает бит "сохранить возможности при изменении UID".
• Изменяет UID на $DAEMONUSER
• Отбрасывает все кепки (в этот момент все кепки все еще присутствуют из-за --keep=1), кроме наследуемого CAP_NET_BIND_SERVICE
• Выполняет вашу команду ('-' - разделитель)

Результатом является процесс с указанными правами пользователя и группы и CAP_NET_BIND_SERVICE.

В качестве примера, строка из ejabberd startup script:

sg $EJABBERDUSER "capsh --keep=1 --uid=`id -u $EJABBERDUSER` --caps='cap_net_bind_service+pei' -- $EJABBERD --noshell -detached"

Ответ 7

Две другие простые возможности:

Существует старое (немодное) решение для "демона, который привязывается к низкому порту и управления руками к вашему демону". Он называется inetd (или xinetd). Недостатки:

• вашему демону необходимо поговорить на stdin/stdout (если вы не контролируете демон - если у вас нет источника, то это, возможно, showstopper, хотя некоторые службы могут иметь флаг inetd-совместимости )
• новый процесс демона раздвоен для каждого соединения
• это одна дополнительная ссылка в цепочке

Плюсы:

• доступен в любой старой UNIX
• После того, как ваш sysadmin настроил конфигурацию, вы можете продолжить разработку (когда вы заново создаете своего демона, можете ли вы потерять возможности setcap? И тогда вам придется вернуться к своему администратору ", пожалуйста сэр..." )
• daemon не нужно беспокоиться об этом сетевом материале, просто нужно поговорить о stdin/stdout
• может настроить выполнение вашего демона как пользователя, не являющегося пользователем root, в соответствии с запросом

Другая альтернатива: взломанный прокси (netcat или даже что-то более надежный) из привилегированного порта в какой-то произвольный порт с высоким номером, где вы можете запустить своего целевого демона. (Netcat, очевидно, не является производственным решением, а "просто мой бокс", верно?). Таким образом, вы можете продолжать использовать сетевую версию вашего сервера, для запуска прокси (при загрузке) потребуется root/sudo, не будет полагаться на сложные/потенциально уязвимые возможности.

Ответ 8

Обновление 2017:

Использовать authbind

• CAP_NET_BIND_SERVICE предоставляет доверие к двоичному файлу, но не обеспечивает контроль над доступом через порт.
  

• Authbind предоставляет доверие пользователю/группе и обеспечивает контроль доступа к каждому порту, а также поддерживает IPv4 и IPv6 (поддержка IPv6 была добавлена в последнее время).

  1. Установить: apt-get install authbind

  2. Настройте доступ к соответствующим портам, например, 80 и 443 для всех пользователей и групп:

     sudo touch/etc/authbind/byport/80
     sudo touch/etc/authbind/byport/443
     sudo chmod 777/etc/authbind/byport/80
     sudo chmod 777/etc/authbind/byport/443
     

  3. Выполните вашу команду через authbind
     (необязательно указав --deep или другие аргументы, см. --deep страницу):

     authbind --deep /path/to/binary command line args
     

     например

     authbind --deep java -jar SomeServer.jar
     

В качестве продолжения Джошуа невероятная (= не рекомендуется, если вы не знаете, что делаете) рекомендация взломать ядро:

Я впервые опубликовал это здесь.

Просто. С нормальным или старым ядром у вас нет.
Как отмечают другие, iptables может переадресовывать порт.
Как также отметили другие, CAP_NET_BIND_SERVICE также может выполнять эту работу.
Конечно, CAP_NET_BIND_SERVICE потерпит неудачу, если вы запустите свою программу из скрипта, если вы не установите ограничение на интерпретатор оболочки, что бессмысленно, вы также можете запустить свой сервис как root...
например, для Java, вы должны применить его к JAVA JAVA

sudo /sbin/setcap 'cap_net_bind_service=ep' /usr/lib/jvm/java-8-openjdk/jre/bin/java

Очевидно, это означает, что любая Java-программа может связывать системные порты.
Дито для моно /.NET.

Я также уверен, что xinetd не лучшая идея.
Но так как оба метода являются хакерами, почему бы просто не снять ограничение, сняв ограничение?
Никто не говорил, что вам нужно запустить нормальное ядро, так что вы можете просто запустить свое собственное.

Вы просто скачиваете исходный код для последнего ядра (или того же, что у вас есть в настоящее время). После этого вы идете к:

/usr/src/linux-<version_number>/include/net/sock.h:

Там вы ищете эту строку

/* Sockets 0-1023 can't be bound to unless you are superuser */
#define PROT_SOCK       1024

и изменить его на

#define PROT_SOCK 0

если вы не хотите иметь небезопасную ситуацию с ssh, измените ее следующим образом: #define PROT_SOCK 24

Как правило, я бы использовал самый низкий параметр, который вам нужен, например, 79 для http или 24 при использовании SMTP на порту 25.

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

Вот как вы компилируете ядро:

https://help.ubuntu.com/community/Kernel/Compile

# You can get the kernel-source via package linux-source, no manual download required
apt-get install linux-source fakeroot

mkdir ~/src
cd ~/src
tar xjvf /usr/src/linux-source-<version>.tar.bz2
cd linux-source-<version>

# Apply the changes to PROT_SOCK define in /include/net/sock.h

# Copy the kernel config file you are currently using
cp -vi /boot/config-'uname -r' .config

# Install ncurses libary, if you want to run menuconfig
apt-get install libncurses5 libncurses5-dev

# Run menuconfig (optional)
make menuconfig

# Define the number of threads you wanna use when compiling (should be <number CPU cores> - 1), e.g. for quad-core
export CONCURRENCY_LEVEL=3
# Now compile the custom kernel
fakeroot make-kpkg --initrd --append-to-version=custom kernel-image kernel-headers

# And wait a long long time

cd ..

Короче говоря, используйте iptables, если вы хотите оставаться в безопасности, скомпилируйте ядро, если вы хотите быть уверенным, что это ограничение вас больше не беспокоит.

Ответ 9

В моем "стандартном обходном пути" в качестве перенаправителя пользовательского пространства используется socat:

socat tcp6-listen:80,fork tcp6:8080

Остерегайтесь, что это не будет масштабироваться, forking дорого, но это способ, которым работает socat.

Ответ 10

Linux поддерживает возможности для поддержки более мелких разрешений, чем просто "это приложение запускается от имени root". Одна из этих возможностей - CAP_NET_BIND_SERVICE, которая связана с привязкой к привилегированному порту (< 1024).

К сожалению, я не знаю, как использовать это для запуска приложения как не root, но при этом он CAP_NET_BIND_SERVICE (возможно, используя setcap, но для этого существует существующее решение).

Ответ 11

Я знаю, что это старый вопрос, но теперь с последними ( >= 4.3) ядрами, наконец, есть хороший ответ на это - окружающие возможности.

Быстрый ответ заключается в том, чтобы захватить копию последней (пока еще неизданной) версии libcap из git и скомпилировать ее, Скопируйте полученный двоичный файл progs/capsh где-нибудь (/usr/local/bin - хороший выбор). Затем, как root, запустите свою программу с помощью

/usr/local/bin/capsh --keep=1 --user='your-service-user-name' \
    --inh='cap_net_bind_service' --addamb='cap_net_bind_service' \ 
    -- -c 'your-program'

В порядке, мы

• Объявляя, что, когда мы переключаем пользователей, мы хотим сохранить наши текущие наборы возможностей
• Переключение пользователя и группы в 'your-service-user-name'
• Добавление возможности cap_net_bind_service к унаследованным и окружающим наборам
• Forking bash -c 'your-command' (так как capsh автоматически запускает bash с аргументами после --)

Здесь много капель здесь.

Во-первых, мы запускаем как root, поэтому по умолчанию мы получаем полный набор возможностей. В это входит возможность переключения uid и gid с помощью системных вызовов setuid и setgid. Однако, как правило, когда программа делает это, она теряет свой набор возможностей - это так, что старый способ удаления root с помощью setuid все еще работает. Флаг --keep=1 сообщает capsh о выпуске syscall prctl(PR_SET_KEEPCAPS), который отключает удаление возможностей при смене пользователя. Фактическое изменение пользователей на capsh происходит с флагом --user, который запускает setuid и setgid.

Следующая проблема, которую нам нужно решить, - как установить возможности таким образом, что мы продолжаем после exec наших детей. В системе возможностей всегда был "унаследованный" набор возможностей, который представляет собой "набор возможностей, сохраненных в функции execve (2)" [(7)]. Хотя это звучит так, как будто это решает нашу проблему (просто установите унаследованную функцию cap_net_bind_service, правда?), Это применимо только к привилегированным процессам - и наш процесс больше не имеет прав, поскольку мы уже изменили пользователя (с помощью --user флаг).

Новый набор возможностей окружения работает вокруг этой проблемы - это "набор возможностей, которые сохраняются в execve (2) программы, которая не является привилегированной". Поместив cap_net_bind_service в окружающее множество, когда capsh выполните нашу серверную программу, наша программа наследует эту возможность и сможет привязывать слушателей к низким портам.

Если вам интересно узнать больше, возможности справочной страницы объясняют это очень подробно. Выполнение capsh через strace также очень информативно!

Ответ 12

TL;DR: для "ответа" (как я вижу) перейдите к → TL;DR < в этом ответе.

Хорошо, я понял это (на этот раз реально), ответ на этот вопрос, и этот мой ответ также является способом извиниться за продвижение другого ответа (как здесь, так и в твиттере), который я считал "лучшим", но, попробовав его, обнаружил, что я ошибся в этом. Учитесь у детей моей ошибки: не продвигайте что-либо, пока вы сами не попробовали его!

Опять же, я рассмотрел все ответы здесь. Я пробовал некоторые из них (и решил не попробовать других, потому что мне просто не нравились решения). Я думал, что решение должно было использовать systemd с настройками Capabilities= и CapabilitiesBindingSet=. После борьбы с этим в течение некоторого времени я обнаружил, что это не решение , потому что:

Возможности предназначены для ограничения корневых процессов!

Как правильно сказано в OP, всегда лучше избегать этого (для всех ваших демонов, если это возможно!).

Вы не можете использовать параметры, связанные с возможностями, с User= и Group= в systemd единичных файлах, потому что возможности ВСЕГДА reset, когда вызывается execev (или независимо от функции). Другими словами, когда systemd вилки и капли его perms, возможности reset. Нет никакого способа обойти это, и вся эта связующая логика в ядре является базовой вокруг uid = 0, а не возможностей. Это означает, что вряд ли возможности когда-либо будут правильным ответом на этот вопрос (по крайней мере, в ближайшее время). Кстати, setcap, как говорили другие, не является решением. Это не сработало для меня, это не очень хорошо работает со сценариями, а это reset в любом случае, когда файл изменяется.

В моей скудной защите я сказал (в комментарии, который я сейчас удалил), что предложение Джеймса iptables (о котором также упоминает OP), было "второе лучшее решение".:-P

→ TL;DR < <

Решение состоит в объединении systemd с командами iptables на лету, как это (взято из DNSChain):

[Unit]
Description=dnschain
After=network.target
Wants=namecoin.service

[Service]
ExecStart=/usr/local/bin/dnschain
Environment=DNSCHAIN_SYSD_VER=0.0.1
PermissionsStartOnly=true
ExecStartPre=/sbin/sysctl -w net.ipv4.ip_forward=1
ExecStartPre=-/sbin/iptables -D INPUT -p udp --dport 5333 -j ACCEPT
ExecStartPre=-/sbin/iptables -t nat -D PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5333
ExecStartPre=/sbin/iptables -A INPUT -p udp --dport 5333 -j ACCEPT
ExecStartPre=/sbin/iptables -t nat -A PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5333
ExecStopPost=/sbin/iptables -D INPUT -p udp --dport 5333 -j ACCEPT
ExecStopPost=/sbin/iptables -t nat -D PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5333
User=dns
Group=dns
Restart=always
RestartSec=5
WorkingDirectory=/home/dns
PrivateTmp=true
NoNewPrivileges=true
ReadOnlyDirectories=/etc

# Unfortunately, capabilities are basically worthless because they're designed to restrict root daemons. Instead, we use iptables to listen on privileged ports.
# Capabilities=cap_net_bind_service+pei
# SecureBits=keep-caps

[Install]
WantedBy=multi-user.target

Здесь мы выполняем следующее:

• Демон слушает 5333, но соединения успешно принимаются на 53 благодаря iptables
• Мы можем включать команды в файл блока, и, таким образом, мы спасаем людей от головных болей. systemd очищает правила брандмауэра для нас, поэтому удаляйте их, когда демон не запущен.
• Мы никогда не запускаемся от имени root, и мы делаем невозможным эскалацию привилегий (по крайней мере, systemd), предположительно, даже если демон скомпрометирован и устанавливает uid=0.

iptables по-прежнему, к сожалению, довольно уродливая и сложная в использовании утилита. Если демона прослушивает eth0:0 вместо eth0, например, команды немного отличаются.

Ответ 13

systemd - это замена sysvinit, которая имеет возможность запускать демон с определенными возможностями. Опции Возможности =, CapabilityBoundingSet = in systemd.exec(5) manpage.

Ответ 14

Переадресация портов имела для нас наибольший смысл, но мы столкнулись с проблемой, когда наше приложение локально разрешало бы URL-адрес, который также должен был быть перенаправлен; (это означает, что вы shindig).

Это также позволит вам перенаправляться при доступе к URL-адресу на локальном компьютере.

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

Ответ 15

По какой-то причине никто не упоминает о снижении sysctl net.ipv4.ip_unprivileged_port_start значения, которое вам нужно. Пример. Нам нужно привязать наше приложение к порту 443.

sysctl net.ipv4.ip_unprivileged_port_start=443

Некоторые могут сказать, что существует потенциальная проблема безопасности: теперь непривилегированные пользователи могут привязываться к другим привилегированным портам (444-1024). Но вы можете легко решить эту проблему с помощью iptables, заблокировав другие порты:

iptables -I INPUT -p tcp --dport 444:1024 -j DROP
iptables -I INPUT -p udp --dport 444:1024 -j DROP

Сравнение с другими методами. Этот метод:

• с некоторого момента (IMO) еще более безопасно, чем установка CAP_NET_BIND_SERVICE/setuid, поскольку приложение не настроено вообще, даже частично (на самом деле есть возможности). Например, чтобы поймать coredump приложения с поддержкой возможностей, вам нужно будет изменить sysctl fs.suid_dumpable (что приводит к другим потенциальным проблемам безопасности). Также, когда CAP/suid установлен, каталог /proc/PID принадлежит root, поэтому ваш пользователь без полномочий root не будет иметь полную информацию/управление запуском процесса, например, пользователь не сможет (в общем случае) определить, какие соединения принадлежат приложению через /proc/PID/fd/(netstat -aptn | grep PID).
• имеет недостаток безопасности: хотя ваше приложение (или любое приложение, использующее порты 443-1024) по какой-то причине не работает, другое приложение может принимать порт. Но эта проблема также может быть применена к CAP/suid (если вы установите его на интерпретаторе, например java/nodejs) и iptables-redirect. Используйте метод systemd-socket, чтобы исключить эту проблему. Используйте метод authbind, чтобы разрешить специальную привязку пользователя.
• не требует установки CAP/suid при каждом развертывании новой версии приложения.
• не требует поддержки/модификации приложения, например метода systemd-socket.
• не требует перенастройки ядра (если работающая версия поддерживает эту настройку sysctl)
• не делает LD_PRELOAD как метод authbind/privbind, это может потенциально повлиять на производительность, безопасность, поведение (не проверено). В остальном authbind - действительно гибкий и безопасный метод.
• перегружает метод iptables REDIRECT/DNAT, поскольку он не требует перевода адреса, отслеживания состояния соединения и т.д. Это заметно только для высоконагруженных систем.

В зависимости от ситуации я бы выбрал sysctl, CAP, authbind и iptables-redirect. И это здорово, что у нас так много вариантов.

Ответ 16

При запуске:

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

Затем вы можете привязать порт, на который вы перешли.

Ответ 17

С systemd вам просто нужно немного изменить свою услугу, чтобы принять предварительно активированные сокеты.

Вы можете использовать активацию системного сокета.

Никаких возможностей, iptables или других трюков не требуется.

Это содержимое соответствующих файлов systemd из этого примера простого HTTP-сервера python

Файл httpd-true.service

[Unit]
Description=Httpd true 

[Service]
ExecStart=/usr/local/bin/httpd-true
User=subsonic

PrivateTmp=yes

Файл httpd-true.socket

[Unit]
Description=HTTPD true

[Socket]
ListenStream=80

[Install]
WantedBy=default.target

Ответ 18

Существует также "путь djb". Вы можете использовать этот метод для запуска вашего процесса с правами root, выполняющегося на любом порту под tcpserver, затем он будет управлять процессом для пользователя, который вы укажете сразу после запуска процесса.

#!/bin/sh

UID=`id -u yourusername`
GID=`id -g yourusername`
exec tcpserver -u $UID -g $GID -RHl0 0 portnumber   /path/to/your/process &

Для получения дополнительной информации см. http://thedjbway.b0llix.net/daemontools/uidgid.html

Ответ 19

Используйте утилиту privbind: она позволяет непривилегированному приложению связываться с зарезервированными портами.

Ответ 20

Поскольку OP - это просто разработка/тестирование, могут быть полезны менее гладкие решения:

setcap может использоваться в интерпретаторе script для предоставления возможностей скриптам. Если setcaps в бинарнике глобального интерпретатора неприемлемы, сделайте локальную копию двоичного файла (любой пользователь может) и получите root для setcap на этой копии. Python2 (по крайней мере) корректно работает с локальной копией интерпретатора в вашем дереве разработки script. Нет необходимости в suid, чтобы пользователь root мог контролировать, к каким возможностям доступны пользователи.

Если вам нужно отслеживать обновления системы для интерпретатора, используйте оболочку script, как показано ниже, чтобы запустить script:

#!/bin/sh
#
#  Watch for updates to the Python2 interpreter

PRG=python_net_raw
PRG_ORIG=/usr/bin/python2.7

cmp $PRG_ORIG $PRG || {
    echo ""
    echo "***** $PRG_ORIG has been updated *****"
    echo "Run the following commands to refresh $PRG:"
    echo ""
    echo "    $ cp $PRG_ORIG $PRG"
    echo "    # setcap cap_net_raw+ep $PRG"
    echo ""
    exit
}

./$PRG $*

Ответ 21

Я попробовал метод iptables PREROUTING REDIRECT. В старых ядрах кажется, что этот тип правил не поддерживался для IPv6. Но, по-видимому, он теперь поддерживается в ip6tables v1.4.18 и ядре Linux v3.8.

Я также обнаружил, что PREROUTING REDIRECT не работает для подключений, инициированных в машине. Чтобы работать с коннекторами с локальной машины, добавьте также правило OUTPUT - см. перенаправление портов iptables не работает для localhost. Например. что-то вроде:

iptables -t nat -I OUTPUT -o lo -p tcp --dport 80 -j REDIRECT --to-port 8080

Я также обнаружил, что PREROUTING REDIRECT также влияет на пересылаемые пакеты. То есть, если машина также пересылает пакеты между интерфейсами (например, если она действует как точка доступа Wi-Fi, подключенная к сети Ethernet), тогда правило iptables будет также связывать подключенные подключения клиентов к интернет-адресам и перенаправлять их на машина. Это не то, что я хотел - я только хотел перенаправить соединения, которые были направлены на машину. Я обнаружил, что могу сделать это только для пакетов, адресованных ящику, добавив -m addrtype --dst-type LOCAL. Например. что-то вроде:

iptables -A PREROUTING -t nat -p tcp --dport 80 -m addrtype --dst-type LOCAL -j REDIRECT --to-port 8080

Еще одна возможность заключается в использовании переадресации портов TCP. Например. используя socat:

socat TCP4-LISTEN:www,reuseaddr,fork TCP4:localhost:8080

Однако одним из недостатков этого метода является то, что приложение, которое прослушивает порт 8080, затем не знает адрес источника входящих подключений (например, для ведения журнала или других целей идентификации).

Ответ 22

Ответ на 2015/сентябрь:

ip6tables теперь поддерживает IPV6 NAT: http://www.netfilter.org/projects/iptables/files/changes-iptables-1.4.17.txt

Вам понадобится ядро ​​3.7 +

Доказательство:

[09:09:23] [email protected]:~ ip6tables -t nat -vnL
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REDIRECT   tcp      eth0   *       ::/0                 ::/0                 tcp dpt:80 redir ports 8080
    0     0 REDIRECT   tcp      eth0   *       ::/0                 ::/0                 tcp dpt:443 redir ports 1443

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 6148 packets, 534K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 6148 packets, 534K bytes)
 pkts bytes target     prot opt in     out     source               destination

Ответ 23

Современный Linux поддерживает /sbin/sysctl -w net.ipv4.ip_unprivileged_port_start=0.