Чи безпечно обслуговувати HTTP / HTTPS через порти 8080/8443

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

Мене хвилює те, що деякі користувачі можуть не мати доступу до цих послуг, оскільки вони не працюють на стандартних портах, а вміст може бути відфільтровано (наприклад) як частина корпоративної політики мережі.

Отже ... наскільки ймовірно, що користувач з Інтернету взагалі може не мати доступу до цих послуг?

— витрачати
джерело

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

— Froggiz

Ми використовуємо ролі Web і Worker у службах Cloud Azure. Наскільки я можу сказати, вказати другу VIP на іншу машину неможливо, якщо ми не перейдемо на віртуальну машину Azure. Інші варіанти включають в себе заміну всього переднього веб-сервера на проксі, але очевидно, що використання різних портів вирішить цю проблему з меншими витратами.

— витрачається

я маю на увазі так: azure.microsoft.com/en-us/documentation/articles/…

— Froggiz

Я хотів би вирішити проблему, яка, здається, тут відсутня. Те, що ви не можете використовувати порти 80або 443може підказати, що ви працюєте на спільному сервері. Якщо так, то існує можливість, що інший користувач міг би прив’язатись до цих портів, якщо ваш коли-небудь перестав працювати . Потім користувач може представити себе за ваш веб-сайт (хоча SSL може допомогти це пом'якшити).

— Натан Осман

@NathanOsman, я думаю, що він турбується про доступ користувачів та брандмауери користувачів.

— Pacerier

Відповіді:

Корпоративні мережі, як правило, не застосовуються до таких правил:

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

Налаштувати цей спосіб набагато простіше, ніж явно заперечувати 99% з 65535 доступних портів.

Зважаючи на це, я перебрав клієнтський портал, який використовував нестандартний порт через мережеві обмеження; Я не знаю подробиць NAT. У будь-якому випадку це унеможливило доступ близько 50% наших користувачів / відвідувачів до сайту та кожного разу, коли вони зателефонували б нам повідомити про цю проблему, нам доведеться узгоджувати їх з неіснуючими ІТ, щоб спробувати втілити правило дозволу.

Я не знаю подробиць ваших обмежень щодо інфраструктури, але я б міг уявити, що щось інше працює на 80/443

Якщо це так, то вашим єдиним знімком може бути використання внутрішнього проксі-сервера або оновлення комутатора до чогось із більш досконалими NAT-можливостями, які можуть направляти запити відповідним чином.

TL; DR

Не використовуйте нестандартний порт для публічних служб, які вже мають стандартний порт.

— MonkeyZeus
джерело

"Налаштувати цей спосіб набагато простіше, ніж явно заперечувати 99% з 65535 доступних портів." - навіть якби вони явно заперечували 99% портів, це матиме такий же ефект.

— користувач253751

Ми в основному використовували основний веб-сервер для проксі-запитів до послуг, пропонованих в інших портах. Оскільки інші сервіси потребують масштабування для додаткової потужності обробки, а не через те, що вони досягають обмежень в мережі, а розмір запитів і відповідей порівняно низький, це розташування дуже добре працює з основним веб-сайтом, збалансованим завантаженням, легко поглинаючи витрати на надання доступу.

— витрачається

@spender Я радий почути, що ви, хлопці, змогли це розробити, не використовуючи нестандартні порти, спрямовані на клієнта :)

— MonkeyZeus

Цілком ймовірно, що вони будуть заблоковані, особливо в корпоративних мережах або на публічному wifi. Менш вірогідний при звичайному домашньому підключенні до Інтернету.

Це, безумовно, буде заблоковано в моїй робочій мережі.

Крім того, людям доведеться пам’ятати, щоб набрати номер порту, щоб потрапити на ваш сайт, що є додатковим головним болем, з яким ви не хочете мати справу. Для внутрішніх або приватних сайтів це не велика проблема, але якщо це для широкої публіки, ви матимете набагато більший успіх, використовуючи стандартні порти.

— Грант
джерело

Служби, про які йдеться, ніколи не вводяться у браузер ... скоріше на них вказують ресурси, що надходять через звичайні порти. Однак здається, що мої побоювання щодо надійності мого підходу цілком виправдані.

— витрачається

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

— Froggiz

Однією з моїх робочих місць є веб-сайт, який індексує потоки криків, і це звичайна скарга на те, що деякі користувачі корпоративних мереж не можуть слухати потоки, що працюють над нестандартними портами. Однак 8080 та 8443 здаються трохи особливими, але, ймовірно, недостатньо спеціальними. Я б сказав, що запускати службу на 800 особливо ризиковано, оскільки вона потрапляє під "відомі" порти, які значно ймовірніше будуть заблоковані.

— витрачається

Просте рішення - залишити ваш сервер працює на порту 8080/8443, а на брандмауері - портами NAT / forward 80/443 до 8080/8443.

— SnakeDoc

@SnakeDoc Погодився, я відповів проксі-опціоном у своїй відповіді :-)

— MonkeyZeus

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

Якщо у вас налаштовано балансування навантаження, ви все одно можете налаштувати свої програми на стандартний порт і перенести порт балансира навантаження на непарний порт внутрішньо. Навіть якщо у вас немає балансування навантаження, я впевнений, що ви зможете знайти спосіб переадресації до внутрішнього порту, який є нестандартним.

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

Існує багато способів зробити це, вам доведеться трохи проявити творчість залежно від типів дорожніх блоків, з якими ви стикаєтесь. Це завжди виклик!

— Бретт Солмері
джерело