Безопасно ли использовать большие номера портов? (re: затемнение веб-сервисов)


9

У меня небольшая домашняя сеть, и я пытаюсь сбалансировать потребность в безопасности и удобство. Самый безопасный способ обезопасить внутренние веб-серверы - это подключаться только с использованием VPN, но это кажется излишним для защиты удаленного веб-интерфейса DVR (например).

В качестве компромисса было бы лучше использовать очень большие номера портов? (например, пять цифр до 65531)

Я читал, что сканеры портов обычно сканируют только первые 10000 портов, поэтому использование очень больших номеров портов немного более безопасно.

Это правда?

Есть ли лучшие способы защиты веб-серверов? (т.е. веб-приложения для приложений)


Нет, это не правда. Современные (даже настольные) многоядерные процессоры с широкополосным доступом могут сканировать все 65535 портов за считанные секунды. И даже если злоумышленник решил разделить их на две секунды, чтобы сорвать ворота DoS, кого это волнует, вы оставляете свою систему более чем на день, верно? Старый принцип гласит, что, как другие уже говорили ниже, «безопасность через мрак» по сути бесполезна в цифровом мире.
msanford

Ответы:


9

Я читал, что сканеры портов обычно сканируют только первые 10000 портов, поэтому использование очень больших номеров портов немного более безопасно.

Многие люди верят в это. Я не.

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

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

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

Попробуйте сами, используя NMAP . Запустите сканирование nmap для портов 1-10 000, найдите сервер HTTP и сравните его со сканированием, которое сканирует все порты 1-65, xxx. Вы увидите, что разница обычно составляет 3-10 минут. Если я делаю детальное сканирование, используя что-то вроде Nessus, разница иногда составляет 20-60 минут.

Хороший взломщик - терпеливый взломщик. Они будут ждать


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

2
+1 «Хороший взломщик - терпеливый взломщик. Они будут ждать».
msanford

@ wag2639 На самом деле вы ничего не делаете, меняя номер порта службы, но заставляя сценария-детишку найти сценарий чуть лучше. Военный набор блока IP-адресов и ТАКЖЕ портов сканировать каждый порт является тривиальным.
msanford

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

3

Использование нечетных номеров портов не обеспечивает никакой безопасности, если только вы не заявляете, что это позволяет вам запускать приложение от имени пользователя без полномочий root.

Подобные вещи можно рассматривать как безопасность по неизвестности, но на самом деле это не безопасность.


Есть ли альтернативы использованию полноценного VPN? Возможно, какой-то обратный веб-прокси, который имеет дополнительную защиту логина / пароля? (squid этого не делает)
SofaKng

@sofakng: вас может заинтересовать оболочка SSL, например Stunnel: stunnel.org
Maxwell,

3

Вы также можете использовать туннель ssh, если вы используете Linux на обоих концах:

ssh -f -N -L 9090:localhost:9090 user@remote-host

Например, это то, что я использую для перенаправления порта 9090 на удаленном хосте на мой локальный порт 9090 cherokee-admin, и я использую аналогичные настройки для других веб-интерфейсов. Вы можете защитить приложения в этом случае, указав в конфигурации приложения , что они работают только на локальном хосте, то есть на 127.0.0.1. Таким образом, они не доступны снаружи, но вы можете переслать их ssh. Проверьте man sshдополнительные параметры, используя переадресацию портов (включая X, которая может полностью решить вашу проблему.)

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


1

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

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


Я использую pfsense, и некоторые из моих веб-сервисов имеют встроенную поддержку SSL (HTTPS). Еще лучше использовать stunnel? Является ли использование stunnel уровнем «аутентификации на брандмауэре»?
SofaKng

1
Как вы делаете «аутентификация на брандмауэре»?
wag2639

Я не знаю, имеет ли pfsense такую ​​функциональность, но на маршрутизаторах Junipers вы можете использовать локальных пользователей (даже RADIUS) для предоставления доступа к HTTP-трафику. Что касается Stunnel, вы можете использовать взаимную аутентификацию с сертификатами, stunnel инкапсулирует HTTP-трафик с SSL и обрабатывает аутентификацию.
Максвелл
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.