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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Port    Service
22      SSH
80      HTTP
443     HTTPS

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

Port    Service
2222    SSH
10080   HTTP
10443   HTTPS

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание: я не говорю, что вы должны изменить порт сервера. Я просто описываю разумные причины (IMO) для изменения номера порта.

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

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

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

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

Кроме того, как указывал другой автор, в то время как попытки войти в порт 22, могут быть невежественными сценаристами, зомби-троянами или даже настоящими пользователями, которые неправильно набрали IP-адрес. Попытка войти в порт 12345 почти наверняка будет либо подлинным пользователем, либо серьезным злоумышленником.

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

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

Не само собой. Однако не использование порта по умолчанию для определенного приложения (скажем, SQL Server) в основном заставит злоумышленника сканировать ваши порты; такое поведение может быть обнаружено вашим брандмауэром или другими показателями мониторинга, а IP-адрес злоумышленника заблокирован. Кроме того, средний «скрипт-шутник», скорее всего, будет сдерживаться, когда используемый им простой инструмент или командный скрипт не найдет экземпляр SQL-сервера на вашем компьютере (поскольку инструмент проверяет только порт по умолчанию).