Как я могу заблокировать доступ к localhost с других компьютеров в одной локальной сети?

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

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

Очевидное решение — заставить сервер слушать на адресе обратной связи (например, 127.0.0.1), а не на физическом сетевом адресе (например, 192.168.* или 10.*). Адреса обратной связи даже не затрагивают физический сетевой интерфейс – устройства без сетевого оборудования по-прежнему поддерживают их – и, безусловно, их не может достигнуть никакое другое устройство в сети.

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

Для ограничения входящих соединений:

• Брандмауэры. Это, по сути, то самое, о чем в первую очередь речь идет в сетевых брандмауэрах. Вы можете ограничить, какие устройства – по IP-адресу или, в локальной сети, даже по MAC-адресу – могут подключаться к вашему устройству, и даже фильтровать конкретные порты и/или протоколы по-разному. Все современные операционные системы общего назначения поддерживают входящие брандмауэры (некоторые лучше других, но у всех есть что-то). Мобильные или встроенные операционные системы не всегда имеют брандмауэр, но в многих случаях его можно установить.
• Ограничения сервера. Когда сервер accept принимает запрос на входящее соединение (или recv получает пакет через протокол, не ориентированный на соединение), операционная система предоставляет не только подключенный сокет / полученные данные, но и адрес клиента/отправителя. Ваш сервер может просто фильтровать по доверенным клиентам и сбрасывать все другие попытки, закрывая сокет/игнорируя пакет.

Для аутентификации и авторизации:

• Простые учетные данные. Это может быть пароль, токен доступа, ключ API или другой секрет, который не будет известен несанкционированным лицам. Обычно он уникален для каждого клиента (и, таким образом, обеспечивает аутентификацию, на основе которой можно принимать решения об авторизации), но иногда вам не важно, кто другая сторона, только имеет ли она правильный пароль (только авторизация). Обратите внимание, что это, как правило, один из наименее безопасных методов, если у вас нет способа обеспечить безопасность самого канала от прослушивателей и самозванцев. Даже если у вас есть такой способ, он слабее, чем большинство других. Если делать это через канал в открытом виде, вам следует хешировать секрет с использованием “соли”, предоставленной пиром (в данном случае, вероятно, подразумевается “клиент”, хотя аутентификация серверов также важна!), но у этого есть свои проблемы с безопасностью, и, как правило, вы хотите использовать фиксированную соль или вовсе не хешировать на стороне клиента, а вместо этого хешировать на сервере (с использованием медленной, преднамеренно затратной функции хеширования, чтобы затруднить подбор сохраненных дайджестов хешей).
• Криптография с открытым ключом. Это описывает любое использование асимметричных криптографических ключей, при котором одна сторона представляет открытый ключ (обычно известный как связанный с конкретным сервером или клиентом) и подтверждает наличие соответствующего закрытого ключа (обычно предлагая подписать некоторые данные, иногда, вместо этого, расшифровав что-то, зашифрованное открытым ключом). Обычные реализации включают TLS (который обычно используется для аутентификации серверов и опционально также поддерживает аутентификацию клиентов), SSH (обычно используется для серверов, часто для клиентов) и безопасные чаты, такие как Signal, хотя есть и другие. Самое большое преимущество таких схем по сравнению с простыми учетными данными заключается в том, что их легко можно защитить от прослушивания и воспроизведения – на самом деле, они обычно входят в то, как устанавливается защищенный канал с самого начала – но дополнительно ни одна из сторон не должна знать никаких секретов своего партнера; открытые ключи не являются секретными, а закрытые ключи никогда не покидают свое устройство в какой-либо форме.
• Аутентифицированные (подписанные) сообщения. В этой схеме – используемой некоторыми облачными провайдерами и различными другими системами, особенно теми, что существовали до широкого распространения TLS – отправитель каждого сообщения вычисляет цифровую подпись или код аутентификации сообщения для самого сообщения и отправляет это тоже. Это часто делается с помощью симметричных ключей (обе стороны знают секрет, но никто другой – используя HMAC или другие ключевые хеши), но это также можно сделать с использованием асимметричной (с открытым ключом) криптографии и по сути доказывает, что отправитель либо имеет соответствующий закрытый ключ (по крайней мере, если подпись действительна), либо воспроизводит существующее сообщение (и сообщение может иметь временные метки и другие метаданные, чтобы сократить этот риск). Однако это не защищает от прослушивания, поэтому в идеале вы не должны использовать это вне защищенного сетевого протокола.

Наконец, если вы делаете это только для межпроцессного взаимодействия (IPC) на локальном устройстве… ПОЖАЛУЙСТА, используйте что-то более безопасное, чем сетевые сокеты (даже те, что на обратной связи)! Сетевые сокеты являются, безусловно, наименее безопасной из распространенных форм локального IPC; они в основном не поддерживают ограничение, какой пользователь может создать либо сервер, либо клиент, операционная система не скажет вам, кто (какой процесс или учетная запись пользователя) находится на другом конце, и их легко сканировать или использовать метод подбора. В сравнении, именованный канал, доменный сокет, разделяемый участок памяти или аналогичная функция гораздо более безопасны. Все основные операционные системы предлагают по крайней мере несколько безопасных каналов IPC (некоторые, такие как доменные сокеты Unix, даже портативны на уровне API), которые предоставляют авторизацию на основе существующих контролей доступа ОС и по крайней мере один метод IPC, который может аутентифицировать вызываемую учетную запись и процесс.

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