显而易见的解决方案是让服务器监听环回地址（例如 127.0.0.1），而不是物理网络地址（例如 192.168.* 或 10.*）。环回地址甚至不接触物理网络接口 – 没有任何网络硬件的设备仍然支持它们 – 并且网络上的任何其他设备肯定无法访问它们。

但是，这是一个显而易见的解决方案，我想知道是否还有其他问题？例如，如果某个特定的其他设备需要通过网络连接到此服务器，那么您将需要继续使用本地地址，而是限制它或验证连接。有多种方法可以同时实现这两种功能，并且对于任何暴露在网络上的东西，即使只暴露在 LAN 上，这两种方法都是绝佳的主意。

限制入站连接：

• 防火墙。这基本上就是网络防火墙的主要作用。您可以限制哪些设备（通过 IP 地址，或者在 LAN 上，甚至通过 MAC 地址）可以连接到您的设备，甚至可以以不同的方式过滤特定端口和/或协议。所有主流的现代通用操作系统都支持入站防火墙（有些比其他的好，但它们都有各自的功能）。移动或嵌入式操作系统并不总是带有防火墙，但在很多情况下可以安装防火墙。
• 服务器限制。当服务器accept发出入站连接请求（或recv通过非面向连接的协议发送数据包）时，操作系统不仅提供已连接的套接字/已接收的数据，还提供客户端/发送者的地址。您的服务器可以简单地筛选受信任的客户端并放弃所有其他尝试，关闭套接字/忽略数据包。

对于身份验证和授权：

• 简单凭证。这可以是密码、访问令牌、API 密钥或其他未经授权方不知道的短期或长期秘密。它通常对每个客户端都是唯一的（因此提供身份验证，可以据此做出授权决定），但有时您不关心对方是谁，只关心他们是否拥有正确的密码（仅限授权）。请注意，这通常是最不安全的方法之一，除非您有办法保护通道本身免受窃听者和冒充者的侵害。即使你有，它也比大多数其他方法更弱。如果通过纯文本通道执行此操作，您应该使用对等方提供的盐（在这种情况下，“对等方”可能意味着“客户端”，尽管对服务器进行身份验证也很重要！）对秘密进行哈希处理，但这有其自身的安全问题，通常您希望使用固定盐或根本不使用客户端哈希处理，而是在服务器上进行哈希处理（使用缓慢、故意昂贵的哈希函数来削弱对存储的哈希摘要的暴力破解）。
• 公钥加密。这描述了所有非对称加密密钥的使用，其中一方提供公钥（通常是已知与特定服务器或客户端相关联的公钥），并证明拥有相应的私钥（通常通过提供对某些数据的签名，有时通过解密使用公钥加密的内容）。常见的实现包括 TLS（通常使用它来验证服务器，并且还可选地支持验证客户端）、SSH（~始终用于服务器，通常用于客户端）和安全聊天程序（如 Signal），尽管还有其他。相对于简单凭证，此类方案的最大优势在于它们可以轻松防止窃听和重放 – 事实上，它们通常是建立安全通道的一部分 – 但此外，任何一方都不需要知道其对等方的任何秘密；公钥不是秘密，私钥永远不会以任何形式离开其设备。
• 经过身份验证（签名）的消息。在这种方案中 – 一些云提供商和各种其他系统使用这种方案，特别是在 TLS 普及之前 – 每条消息的发送者都会在消息本身上计算数字签名或消息认证码并将其发送。这通常通过 HMAC 或其他密钥哈希使用对称密钥（双方都知道秘密，但其他人不知道）来完成，但也可以使用非对称（公钥）加密来完成，并且固有地证明发送者要么拥有相应的私钥（至少，如果签名有效）要么正在重放现有消息（并且消息可以具有时间戳和其他元数据以降低这种风险）。但是，这无法防止窃听，因此最好不要在安全网络协议之外使用它。

最后，如果您仅针对本地设备进程间通信 (IPC)执行此操作…请使用比网络套接字更安全的东西（甚至是环回套接字）！网络套接字是迄今为止最不安全的本地 IPC 常见形式；它们大多不支持限制用户可以在服务器或客户端上创建的内容，操作系统不会告诉您另一端是谁（哪个进程或用户帐户），并且它们很容易被扫描或暴力破解。相比之下，命名管道、域套接字、共享内存部分或类似功能要安全得多。所有主流操作系统都提供至少几个安全的 IPC 通道（有些，如 Unix/域套接字，甚至在 API 级别上是可移植的），这些通道基于操作系统现有的访问控制提供授权，并且至少提供一种可以验证调用帐户和进程的 IPC 方法。

如果您使用网络套接字是因为您需要一个 Web 应用程序与其主机通信，请考虑使用带有“本机消息传递”的浏览器扩展。如果没有，至少要在通信中实现身份验证！