@sofidev/ipc is a minimal protocol made on top of the IPC and TCP protocols (see PROTOCOL), it lacks of cryptography and security like TLS when using the TCP protocol.

In most operating systems, ports are exposed not only in localhost, but also outside the server, this can mean a large security hole if @sofidev/ipc handles sensitive information between processes and/or microservices.

If your @sofidev/ipc server is only supposed to run only in its local machine, we strongly suggest using a Firewall like iptables for Linux ─ For example, considering XXXX is your port, you would need to run the following commands:

# Allow access to the XXXX port in localhost
$ iptables -A INPUT -p tcp -s localhost --dport XXXX -j ACCEPT

# Deny access to the XXXX port elsewhere
$ iptables -A INPUT -p tcp --dport XXXX -j DROP

The iptables command is a root-only command, if you are not using root but a sudoer account, you might need to use sudo.

Inside containers like Docker or equivalents, this can be unnecessary, since the ports are not exposed by default.

For Windows users, SpiceWorks has a nice guide about this process.

If your @sofidev/ipc server connects with other machines, this changes a little more ─ you can whitelist the other machines' IPs with iptables (besides localhost itself) or implement an additional handshake.

Additional handshakes can be made by sending a message from the Server to the Client (or vice versa) and compare certain values, for example an unique key. This approach may take security approaches such as encrypting the "authenticate" payload with a special key and adding a timer to avoid man-in-the-middle attacks, as they usually have latency implications.

There are many techniques that can be used to enhance security between @sofidev/ipc nodes on the public network, involving a little cryptography with it. Some of the most common techniques can include:

• Send the content and a MD5 hash of it, this is exposes the contents but can protect nodes from malicious contents or requests ─ if the content does not generate the same hash as the from the message, the message is invalid. This approach is very simple but also very efective.
• Public-key cryptography, this approach is one of the fundamental security ingredients in modern cryptosystems, applications and protocols assuring the confidentiality, authenticity and non-repudiability of electronic communications and data storage, it is more complex than the previous approach but does not expose the messages contents.