Some thoughts about the EOS Ghostbusters/Core Architecture

Within the Core (Ghostbusters) system, VPN software is used to provide one of the security layers. It is important to understand that this is not a VPN network in the commonly understood sense. Many users have experience in corporate VPNs, which are managed by company IT staff, or with commercial retail VPN services, which provide geo-masking or firewall penetration capability. Core is not at all like any of these.

In Core, there is no central authority. There is no routing of packets on a private network. Any new peer may be added by any member. No member needs to use the private tunnels. Any member may open public access. Any member may allow connections from anyone.

Our use of VPN software is indeed VPN in the formal sense. It is Virtual, since it creates a UDP/IP tunnel between two hosts which can encapsulate general IP traffic. It is Private, in that all such encapsulated traffic is strongly encrypted using forward secrecy and Elliptic Curve Diffie-Hellman Ephemeral key agreement (ECDHE) and ChaCha20-Poly1305 block encryption. It is a Network, the smallest one possible, in that it provides layer 3-only connectivity between two IP addresses. There is no layer 2 functionality on this interface.

Wireguard (https://www.wireguard.com/) as used in Core, does exactly one thing. It establishes an encrypted point to point tunnel connection between two hosts, allowing traffic only for packets between those two hosts. There is no larger network. There is no forwarding of traffic (no routers). The Core effort is largely to create tools to assist in managing many such connections. The technique used in wireguard gives very strong spoofing protection, in that my host will establish a connection only when the IP address and public key of the peer exactly match what is configured on my host. Any unmatched connection is dropped immediately, as there is no request/challenge/response type of overhead. There is no protocol negotiation.

If nodeos is configured to listen only on the VPN interface, then only peers correctly connected via that interface can talk to the daemon.

There is no DDOS risk, and no significant DOS risk, for traffic inside the tunnel. The DDOS risk basis comes from the public IP connectivity, in that a targeted attack on upstream links can cause saturation. This is not preventable, except for sophisticated upstream interception. So, one goal is to minimize that risk by obfuscating the real IP address of the host. While we all know "obscurity is not security", this is a factor to significantly increase the difficulty, and thus the cost, of an attack. Everything we do in security is that, we never achieve perfection, we just make the cost of attack higher.

Any given nodeos host does not need to connect to all nodes in the swarm. The goal is to connect to a number of known, stable, trusted nodes, hopefully with low network latency for best performance, and only these trusted peers know the actual public ip of my node.

For nodeos machines configured to support API service, this is basically a nodeos built in web server. To provide general public service, all Internet uses must be able to make TCP connections to the web server, submit API requests, and receive responses.

Nodeos is new software. It is full of "unknown unknowns". We have no way to know what problems and vulnerabilities exist. It has not been audited, it has not been tested with fuzzy input. It has not been scrutinized for corner case overflows. Reviewing the code base briefly gives no comfort, in that secure programming techniques are not readily evident. This code was clearly built quickly, with a focus on functionality. Variable scopes are often unchecked, overflows not tested, error traps are missing, function calls not sanitized. I do not recommend exposing such un-vetted code to the general public. Any compromise of the API server potentially exposes the EOS p2p service, and any peers to which the API server is connected. Even though it does not produce blocks, it is an attractive target.

By placing reverse proxy web servers to be the public facing access nodes, we gain a number of significant benefits.:

1. Proxies may be distributed in multiple cloud services, and load balanced, thus maximizing performance, resilience and reliability.
2. DDOS flood protection is most easily accomplished to shield simple, distributed web servers.
3. Filters may be added (ala Patroneos) to selective exclude many improperly formatted requests, so that they never go to the API server. These filters should become more sophisticated over time.
4. The proxy can easily rate limit requests at the kernel level, mitigating whole ranges of attacks.
5. The proxy may have its own private point to point connection to the API server, somewhat masking the exposure of the public IP address of the API node, and allowing the API node to listen only on the VPN interface connected to proxies, completely blocking service on any other port. The API node is thus not subject to any IP spoofing attacks, as it has absolute certainty of the VPN peer's identity.

These are a few of my thoughts about the architecture proposed by the Ghostbusters/Core team. The software tools are at https://github.com/HKEOS/Ghostbusters-Testnet