Безопасно ли обслуживать HTTP / HTTPS через порты 8080/8443?

Из-за ограничений инфраструктуры, одно из предложенных решений для обслуживания сервиса HTTP в мире состоит в том, чтобы предложить его через порты 8080 и 8443.

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

Итак ... какова вероятность того, что пользователь из Интернета в целом не сможет получить доступ к этим услугам?

web-server http https port расточитель
источник

Вы не можете прокси адрес на порт 80 и 443?

Фроггиз

Мы используем веб-роли и рабочие роли в облачных службах Azure. Насколько я могу судить, невозможно указать второго VIP на другой машине, если мы не переключимся на виртуальные машины Azure. Другие варианты включают замену всего интерфейсного веб-сервера прокси-сервером, но очевидно, что использование других портов решит эту проблему с меньшими затратами.

спонсор

я имею в виду вот так: azure.microsoft.com/en-us/documentation/articles/…

Фроггиз

Я хотел бы обратиться к проблеме, которая, кажется, здесь отсутствует. Тот факт, что вы не можете использовать порты 80или 443может указывать на то, что вы работаете на общем сервере. Если это так, существует вероятность того, что другой пользователь может подключиться к этим портам, если ваш когда-либо перестал работать . Затем этот пользователь может выдать себя за ваш сайт (хотя SSL может помочь смягчить это).

Натан Осман

@NathanOsman, я думаю, он беспокоится о доступе пользователей и пользовательских брандмауэрах.

Pacerier

Ответы:

Корпоративные сети обычно по умолчанию придерживаются таких правил:

deny all; allow 80; allow 443; allow 21; allow 22; etc...

Гораздо проще настроить этот способ, чем явно запретить 99% из 65 535 доступных портов.

С учетом сказанного, я взял на себя клиентский портал, который использовал нестандартный порт из-за сетевых ограничений; Я не знаю деталей NAT. В любом случае, это сделало невозможным доступ примерно 50% наших пользователей / посетителей к сайту, и всякий раз, когда они звонили нам, чтобы сообщить об этой проблеме, нам приходилось координировать свои действия с их несуществующими ИТ-отделами, чтобы попытаться внедрить правило разрешения.

Я не знаю деталей ваших ограничений инфраструктуры, но я бы предположил, что что-то еще работает на 80/443

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

TL; DR

Не используйте нестандартный порт для общедоступных служб, у которых уже есть стандартный порт.

MonkeyZeus
источник

«Гораздо проще настроить этот способ, чем явно отрицать 99% из 65 535 доступных портов». - даже если бы они явно запретили 99% портов, это имело бы тот же эффект.

user253751

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

спонсор

@spender Я рад слышать, что вы, ребята, смогли решить эту проблему, не используя нестандартные порты для

клиентов

Весьма вероятно, что они будут заблокированы, особенно в корпоративных сетях или в общественных местах. Менее вероятно на обычном домашнем интернет-соединении.

Это наверняка будет заблокировано в моей рабочей сети.

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

Грант
источник

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

спонсор

Вы можете объяснить, почему это будет заблокировано? Я использовал порт 800 в течение долгого времени без каких-либо проблем, даже с инструментами Google SEO и ссылками ..

Froggiz

Одной из моих задач является создание веб-сайта, который индексирует потоки shoutcast, и часто жалуются на то, что некоторые пользователи в корпоративных сетях не могут прослушивать потоки, которые работают через нестандартные порты. Тем не менее, 8080 и 8443 кажутся немного особенными, но, вероятно, недостаточно особенными. Я бы сказал, что запуск службы на 800 является особенно рискованным, поскольку он попадает в «хорошо известные» порты, которые с большей вероятностью будут заблокированы.

спонсор

Простое решение - оставить сервер работающим на порте 8080/8443, а на брандмауэре порты NAT / forward от 80/443 до 8080/8443.

SnakeDoc

@SnakeDoc Согласен, я рассмотрел вариант прокси в своем ответе :-)

MonkeyZeus

Не сложно заставить ваш браузер нажимать, скажем, http://example.com:8080/index.html , но когда вы говорите о корпоративных политиках, блокирующих нестандартные порты, это кажется довольно сложным.

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

Внутренне пользователи могут получить доступ через нечетный порт (если это не является частью вашей корпоративной политики для блокировки), внешне они видят http://example.com .

Есть много способов сделать это, вам придется проявить немного креативности в зависимости от типов препятствий, с которыми вы сталкиваетесь. Это всегда вызов!

Бретт Салмиери
источник