☰

Есть ли еще причина, по которой привязка к порту < 1024 разрешена только для root в системах Unix?

tag-icon • tag-icon security unix ip socket
Есть ли еще причина, по которой привязка к порту < 1024 разрешена только для root в системах Unix?

В системах Unix привязка к порту TCP < 1024 из процесса без привилегий root запрещена.

Какова была первоначальная причина и актуальна ли она до сих пор?

Например, http-серверу не нужны привилегии root для обслуживания html-страницы.

Какой процесс/протокол нужен пользователю Unix, чтобы быть уверенным, что он работает с привилегиями root?

Спасибо

решение1

Этот диапазон портов не должен определяться программистом
.зарезервировано IANA,

Известные порты — это порты от 0 до 1023.

DCCP Well Known Ports НЕ ДОЛЖНЫ использоваться без регистрации IANA. Процедура регистрации определена в [RFC4340], Раздел 19.9.

Для ознакомления с другими мнениями, пожалуйста, посетите:

  1. Изветка linuxquestions(читайте по ссылке для более подробной информации)

    Лимит порта 1024 на самом деле кусает себя за хвост. Он вызывает демоническую практику, которая может открыть дыры в безопасности, которые делают лимит неэффективным в качестве меры безопасности.

    • TheТоп-20 уязвимостей SANSпримечания

      Несколько основных системных служб предоставляют удаленные интерфейсы к клиентским компонентам через удаленные вызовы процедур (RPC). Они в основном раскрываются через конечные точки именованных каналов, доступные через протокол Common Internet File System (CIFS), хорошо известные порты TCP/UDP и в некоторых случаях эфемерные порты TCP/UDP. Исторически в службах было много уязвимостей, которые могут быть использованы анонимными пользователями. При эксплуатации эти уязвимости предоставляют злоумышленнику те же привилегии, которые служба имела на хосте.

В наши дни такие протоколы, какBitTorrentискайпперешли через эфемерные порты в незарезервированное пространство и не беспокоятся о доступе root. Целью являетсяне просто обойти эту старую систему безопасности зарезервированного порта; Сегодняшние протоколы хотятобойти даже периметр сети(Skype — хороший пример). Дело пойдет дальше, поскольку пропускная способность сети и ее доступность возрастут, когда каждый пользователь компьютера, вероятно,запустить веб-сервер самостоятельно-- иможет быть,неосознанно, бытьчасть ботнет.

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

решение2

Ну, насколько я помню, изначальное мышление со времен BSD Unix состояло в том, что порты < 1024 должны были быть зарезервированы для "хорошо известных служб", и предполагалось, что серверы будут относительно редки, и что люди с привилегиями root будут считаться "доверенными" в некотором роде. Поэтому вам нужно было иметь привилегии, чтобы привязать сокет к прослушиванию порта, который будет представлять сетевую службу, к которой будут получать доступ другие пользователи.

Порты 1024-4999 были предназначены для использования в качестве "эфемерных" портов, которые представляли бы клиентскую сторону TCP-соединения. Порты 5000+ были предназначены для некорневых серверов.

Очевидно, все эти предположения довольно быстро вылетели из окна. Проверьте список резервирования номеров портов IANA TCP, чтобы увидеть, насколько все поднялось.

Одним из решений этой проблемы была идея RPC portmapper. Вместо того, чтобы резервировать порт TCP для каждой службы, служба запускалась на случайном порту и сообщала демону portmapper, где она слушает. Клиенты спрашивали portmapper "где слушает служба X" и действовали оттуда. Я не могу вспомнить, какие механизмы безопасности были задействованы для защиты известных служб RPC от подмены.

Я не уверен, что в наши дни есть веская причина для всего этого, но, как и в большинстве случаев в мире *nix, вещи имеют тенденцию накапливаться, а не полностью изобретаться заново.

Кто-нибудь читал Вернора Винджа? Я помню, как он писал в одном из своих романов о компьютерной системе в далеком будущем, которая включала слои и слои кода из далекого прошлого, а время все еще представлялось количеством секунд с какой-то древней даты (1/1/1970, если быть точным). Он, вероятно, не так уж далек от истины.

решение3

В старые времена обычные пользователи входили в Unix-машины. Так что вы бы не хотели, чтобы рядовой пользователь настраивал поддельный ftp-сервис или что-то в этом роде.

В наши дни типичным вариантом использования является то, что доступ к серверу имеют только администратор и несколько других доверенных лиц, поэтому, если бы модель была переделана сегодня, ограничение < 1024 могло бы отсутствовать.

решение4

Имеет смысл запускать службы, принимающие системные пароли, на привилегированных портах. Это означает, что пользователи с учетными записями оболочки не смогут настроить «поддельные» службы на том же порту, чтобы перехватывать учетные данные людей или запрещать доступ, настраивая неработающие службы на тех же портах.

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

Вещи, которые не принимают системные пароли, не так уж и важны, хотя существуют серьезные проблемы безопасности при совместном использовании таких вещей, как веб-серверы, между пользователями на многопользовательском компьютере (как обнаружили провайдеры общего хостинга).

Связанный контент