Вопрос: Действительно ли изменение номера порта по умолчанию повышает безопасность?


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

Я не совсем уверен, что может улучшить безопасность, потому что

  1. Существуют портовые сканеры
  2. Если приложение уязвимо, оно остается таким же независимо от его номера порта.

Я что-то пропустил или ответил на свой вопрос?


62
2017-09-28 19:04


Источник


Одна вещь, которую я сделал, это использовать определенные порты по умолчанию (например, SSH-порт 22) в качестве медовых горшков. Любой, кто пытается подключиться к этим портам, полностью заблокирован xколичество времени. Это доказало свою эффективность против сканирования портов. Конечно, это всего лишь один инструмент в панели инструментов безопасности. - Belmin Fernandez
Здесь задается общий вопрос о безопасности через неясность: security.stackexchange.com/questions/2430/... - Tony Meyer
ну это может быть препятствием для «сценариев детей», - Lukasz Madon
@BelminFernandez, «один инструмент в панели инструментов безопасности»? Нет, это для снижения нагрузки на сервер (производительность) и имеет ничего общего с безопасностью кроме простой иллюзии. С точки зрения безопасности, совершенно не нужно, если сервер уже силен, и если сервер уязвим, он не делает его более безопасным. - Pacerier
@Pacerier, согласился с тем, что усилия и внимание должны быть направлены на внедрение более надежных методов безопасности. Однако нет причин, по которым вы не можете обойти оба. - Belmin Fernandez


Ответы:


Он не обеспечивает серьезную защиту от нападения с целью атаки. Если ваш сервер нацелен на то, что, как вы говорите, они сканируют порт и узнают, где находятся ваши двери.

Тем не менее, перемещение SSH с порта по умолчанию из 22 будет сдерживать некоторые атаки типа «без цели» и «любительский сценарий». Это относительно непродуманные пользователи, которые используют сценарии для сканирования портов с большими блоками IP-адресов за раз специально, чтобы узнать, открыт ли порт 22, и когда они его найдут, они начнут какую-то атаку (перебор, атака словаря, и т.д). Если ваш компьютер находится в этом блоке проверяемых IP-адресов и он не запускает SSH на порту 22, он не будет отвечать и, следовательно, не будет отображаться в списке машин для этого сценария kiddie для атаки. Эрго, есть некоторая низкоуровневая безопасность, но только для этого типа оппортунистической атаки.

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

Раньше я запускал Fail2Ban на общедоступном веб-сервере, и это было действительно, очень очевидно, когда я переместил SSH с порта 22. Он сократил оппортунистические атаки на порядки.


64
2017-09-28 19:19



Согласовано. Я видел очень похожее падение при экспериментировании с перемещением SSH на нестандартный порт. К счастью, с отключенным паролем, это действительно не проблема. - EEAA♦
Лучший ответ здесь пока. Все сводится к тому, кто атакует. Я однажды помог администратору систему, которая получила удар с атакой нулевого дня от сканирующего ребенка. Предположительно в MS-RDP, поскольку у нас не было IIS, выставленного брандмауэром. Наш хост не позволит нам изменить порт RDP (управляемый хостинг), поэтому мы в основном должны были сидеть там, пока они работали над новым шаблоном для их фильтрации IDS / IPS. Хотя это может помочь не столько для более известных серверов, сколько SSH, которые, как представляется, имеют меньше проблем с безопасностью, чем некоторые продукты MS. - Matt Molnar
Определенно согласен. Безопасность - все о слоях, и чем больше у вас есть, тем более безопасными вы являетесь. Это может быть слабый слой, но тем не менее слой. До тех пор, пока он не полагается исключительно на него, он может только добавить к безопасности. - Paul Kroon
Еще один момент для перемещения SSH с порта 22 заключается в том, что большое количество SSH пытается плюс услуги, поскольку Fail2Ban может иногда увеличивать значение ЦП. Это может быть незначительно на верхней части аппаратного обеспечения линии, но некоторые старые серверы могут испытывать всплески процессора. Его процессорное время, память и полоса пропускания вы можете использовать для других вещей. - artifex
Я сделал то же самое с RDP на сервере 2003 года - он существенно сократил количество неудачных записей аутентификации в средстве просмотра событий. - Moshe


Очень полезно держать журналы в чистоте.

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

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


41
2017-09-28 22:58



замечательное различие - ZJR
+1 Это лучший аргумент в пользу изменения номеров портов, которые я когда-либо слышал, и пока единственное, что заставило меня это сделать - squillman
+1 Это отличный момент. Целевые угрозы намного опаснее, чем случайные пробники (дети-сценаристы просто переходят к более легким целям, если у вас есть приличная безопасность). Целевой атакующий может знать намного больше об определенных уязвимостях или даже шаблонах паролей. Хорошо иметь возможность распознавать эти атаки за пределами роя спама на порте 22. - Steven T. Snyder
Это неверно. Я видел, как по крайней мере один сервер скомпрометирован путем сканирования на нестандартном SSH-порту. Не существует неотъемлемой причины, по которой злоумышленник не сможет сканировать и другие порты. - Sven Slootweg
@SvenSlootweg, Правда, особенно с компьютерами, которые становятся все быстрее и дешевле, сканирование, занимающее 65535 раз больше, больше не является намного длиннее больше. - Pacerier


Нет, нет. На самом деле, нет. Термин для этого Безопасность от Obscurity и это не является надежной практикой. Вы правы в обоих своих точках.

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

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


28
2017-09-28 19:10



Проектирование (сильных) паролей и шифрование в идею безопасности по неизвестности немного растянуто по моему скромному мнению ... - squillman
Используя только 8 символов с полным диапазоном буквенных и числовых символов (и даже не допускающих специальных символов), число возможных комбинаций составляет 62 ^ 8 (218 340,105,584,896). 65535 даже не в той же вселенной, даже при использовании детекторов сканирования портов. Заметьте, я дисконтирую слабые пароли. - squillman
Еще раз, «это не значит, что нестандартный порт является всем устройством безопасности». Каждый бит помогает. Это 10-секундная настройка, которая, если ничего другого, не остановит ваш сервер, чтобы показать кому-то, кто ищет SSH, чтобы начать стучать в двери. - ceejayoz
Мех. Отслеживание нестандартных портов в моей книге не стоит. Я соглашусь не соглашаться ни с кем ... Добавление дополнительных контрмер, помимо изменения порта, безусловно, является частью уравнения, и я бы скорее отказался от этих частей головоломки. - squillman
Из того, что я видел, нестандартные порты стали вполне стандартными. 2222 для ssh, 1080, 8080, 81, 82, 8088 для HTTP. В противном случае он становится слишком неясным, и вы задаетесь вопросом, что такое сервис на порту 7201 и почему вы не можете подключиться к ssh на 7102. - BillThor


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

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


13
2017-09-28 19:10



+1 для более сложной конфигурации и поддержки. Заставляет вас тратить время, которое можно потратить на защиту двери (вместо того, чтобы искать, где в вашем доме вы положили ее). - Macke


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

Я хотел бы добавить, что изменение номера порта может нанести ущерб вашей безопасности.

Представьте себе следующий упрощенный сценарий. Взломщик сканирует 100 хостов. У девяти девяти из этих хостов есть службы, доступные на этих стандартных портах:

Port    Service
22      SSH
80      HTTP
443     HTTPS

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

Port    Service
2222    SSH
10080   HTTP
10443   HTTPS

Теперь это может быть интересно для взломщика, потому что сканирование предлагает две вещи:

  1. Хозяин хоста пытается скрыть номера портов в своей системе. Возможно, владелец считает, что в системе есть что-то ценное. Это не может быть запущенная система.
  2. Они выбрали неправильный метод для обеспечения своей системы. Администратор допустил ошибку, поверив в обфускацию портов, что указывает на то, что они могут быть неопытным администратором. Возможно, они использовали обфускацию портов вместо правильного брандмауэра или надлежащего IDS. Возможно, они допустили другие ошибки безопасности и могут быть уязвимы для дополнительных атак безопасности. Пойдем немного дальше, не так ли?

Если бы вы были взломщиком, вы бы решили взглянуть на один из 99 хостов, на которых запущены стандартные службы на стандартных портах, или на этом одном хосте, который использует обфускацию портов?


12
2017-09-28 19:45



Я бы посмотрел на 99 хостов, если бы опыт не учил меня иначе. Кто-то, кто перемещает порты вокруг, вероятно, с большей вероятностью будет исправлять и защищать, если вы спросите меня. - ceejayoz
Я бы посмотрел на 1 хост, который выделялся, на случай, что какой-то PFY подумал: «Если я изменю номера портов, я НЕВИДИМО!» но пароль root установлен на «пароль». - Andrew
@Ceejayoz, полностью согласен. Я использую SSH на 2222, не имеет значения безопасности, но сокращает работу с детьми-сценаристами. Я бы подумал, что они с большей вероятностью не обратят на меня внимания, потрудились сменить порт, возможно, приняли и другие меры. Очевидно, что это не вся настройка по умолчанию ... - Chris S
Я понимаю, что не все согласны с моим мнением. Но, по моему опыту, было много системных владельцев, которые использовали бы обфускацию портов, но они допускали бы ошибки, не обновляя OpenSSH после того, как были обнаружены некоторые критические уязвимости безопасности, или использовали бы незашифрованные ключи SSH из общей университетской системы и т. Д. Некоторые из эти системы были сочными целями. - Stefan Lasiewski
Расширяясь: перейдя на нестандартный порт, вы, скорее всего, будете препятствовать детям-сценаристам, но также более интригует опытного хакера. Что вызывает вопрос: чего вы больше боитесь быть нацеленным? - tardate


Я собираюсь пойти против общей тенденции, по крайней мере частично.

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

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

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


9
2017-09-29 01:11



Объедините это с точкой Андреасом Бонини о атаках с целью атаки, и это сильный аргумент в пользу использования альтернативных портов. - JivanAmara


На мой взгляд, перемещение порта, на котором работает приложение, не повышает безопасность вообще - просто по той причине, что одно и то же приложение работает (с такими же сильными и слабыми сторонами) только на другом порту. Если ваше приложение имеет слабость, перемещающий порт, который он слушает в другом порту, не устраняет недостатки. Хуже того, он активно поощряет вас НЕ рассматривать слабость, потому что теперь он не постоянно забивается автоматическим сканированием. Он скрывает реальная проблема которая является проблемой, которая должна быть фактически решена.

Некоторые примеры:

  • «Он очищает журналы». Тогда у вас возникла проблема с обработкой ваших журналов.
  • «Это уменьшает расходы на подключение». Накладные расходы либо незначительны (как и большинство сканирований), либо вам требуется какая-то фильтрация / отказ от обслуживания, выполняемый вверх по течению
  • «Это уменьшает воздействие приложения». Если ваше приложение не может противостоять автоматическому сканированию и эксплуатации, ваше приложение имеет серьезные недостатки в области безопасности, которые необходимо устранить (т. Е. Сохранить его исправленным!).

Реальная проблема - административная: люди ожидают, что SSH будет на 22, MSSQL - на 1433 и так далее. Их перемещение - это еще один уровень сложности и требуемая документация. Это очень раздражает, чтобы сесть в сеть и использовать nmap, чтобы выяснить, где вещи были перемещены. Добавки к безопасности в лучшем случае являются эфемерными, а недостатки не несущественны. Не делай этого. Исправьте реальную проблему.


5
2017-09-29 16:56





Вы правы, что это не принесет большой защиты (поскольку диапазон портов TCP-сервера имеет только 16 бит энтропии), но вы можете сделать это по двум другим причинам:

  • как уже говорили другие: злоумышленники, пытающиеся выполнить много логинов, могут загромождать ваши файлы журналов (даже если словарные атаки с одного IP-адреса могут быть заблокированы с помощью fail2ban);
  • Требования к SSH криптография с открытым ключом для обмена секретными ключами для создания безопасного туннеля (это дорогостоящая операция, которая при обычных условиях не требуется делать очень часто); повторные SSH-соединения могут потерять мощность процессора,

Примечание. Я не говорю, что вы должны изменить порт сервера. Я просто описываю разумные причины (ИМО), чтобы изменить номер порта.

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


2
2017-09-29 00:53



Файлы журналов могут быть легко очищены с помощью соответствующих фильтров. Если вы говорите о производительности сервера из-за сокращения журналов, мы больше не говорим о безопасности. Производительность - совершенно другая тема. - Pacerier
Не когда компьютер становится непригодным из-за чрезмерного использования диска. - curiousguy
Да, это проблема производительности. Производительность также важна, но этот конкретный поток специально обсуждает только безопасность. (Для этой темы просто представьте, что вы размер Google, и Google делает это на самом деле эти данные нужны для анализа и / или продажи). - Pacerier


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

Я сам запускаю sshd на альтернативном порту на своих личных машинах, но это в основном как удобство держать беспорядок в /var/log/auth.log. В многопользовательской системе я действительно не считаю, что небольшое гипотетическое преимущество безопасности, представленное выше, является достаточным основанием для дополнительных проблем, вызванных отсутствием sshd на стандартной части.


1
2017-09-28 19:55



Сценарий будет действителен только в том случае, если все админы (а) абсолютно не возьмут какую-либо свободу с этим «дополнительным временем», когда-либо пойти на ланч и так далее. - Pacerier