This section describes the suggested guidelines for a Network Layer implementation among a BitCoin infrastructure, either being a new one, or an existing one to be secured.

Public Firewall

As a general rule a Firewall, either phisycal or virtual, should be placed on the edge of the infrastructure. This firewall should have layer 7 capabilities (or UTM) with deep packet inspection capability. Whereas this guide line has been built on a specific UTM device, any capable device could be used as far as having the following functions active and configured:

  • Intrusion Preventions System (IPS) active on the whole incoming traffic
  • HTTPS Deep Packet Inspection function with installed SSL certificates for correct data handling either from inside to outside and vice versa
  • HTTP layer 7 protocol inspection
  • IPsec VPN support with at least AES-256 encryption engine aboard
  • Antivirus engine aboard
  • (preferably) a URL categorization engine aboard (like WebSense)

The firewall shall work as routing device (i.e. not in bridge mode) and give access to internal hosts using a port-forward fashion system or 1 to 1 NAT fashion, i.e. hosts should not have public IP address directly configured on its interface.

The following list explains the various services as described above.

  • Intrusion Prevention System:
    • Incoming Traffic
      • The IPS should take care of the most common pattern-driven attacks. This kind of system should protect your Network from attacks like public exploits, port scans or other well known attacks.
  • HTTP and HTTPS Deep Packet Inspection
    • Incoming Traffic
      • In order to be sure what kind of requests are sent to your application server, the HTTP protocol inspection can be used for two purposes. 1) being sure that the requests are “polite” and well understood by your systems and 2) can be used to block unwanted requests (or verbs) if a breach or bug is found resulting in a quick security response.
    • Outgoing Traffic
      • Incoming traffic alone might not be a problem. It is important to be sure the server does not act “freely” on the Internet, downloading unwanted content or performing unauthorized requests (like using wget to download packages via exploit). All the traffic of a server should be narrowed down and controlled, whereas only an administrator should have the grant to download and/or install content on the server. Any other unnecessary traffic should be denied.
  • AntiVirus Gateway
    • Incoming Traffic
      • If your infrastructure provides upload of data, it should be passed through an Anti Virus system before being deployed on your systems.
      • Even if an administrator is allowed to browse the Net or download content (even updates) all the content itself should be passed for a security scan.
  • URL Categorization
    • Outgoing Traffic
      • Like for AntiVirus control, URL categorization of the outgoing traffic generated by an administrator can help preventing drive by download attacks by blocking unwanted content. This add a relevant level of security and safety when performing administrative tasks on the servers.
  • IPsec VPN and SSL VPN
    • Incoming Traffic When you need to build a secure connection between more hosts on the same network, a LAN to LAN VPN connection should be used. It adds security by encryption of the whole traffic between hosts and reduces administrative effort to mantatin the security levels.

The following scheme shows a typical connections topology that could be adopted.

Network Scheme

Incoming traffic

The incoming traffic is defined as all the connections where the TCP/IP handshake is originated from the Internet and flowing to the hosts inside the perimeter.

Only the relevant and must-be-open ports should be kept open on the hosts running the application server, while the rest shall be closed.

If you need administrative access to your hosts behind the firewall, consider activating a VPN access for mobile users with strong credentials and either a long PSK for IPsec proposal or using SSL certificates of sufficient key length (at least 2048 bits). Also user access should be limited to the minimum required access, i.e. not allowing unused or irrelevant protocols to cross the VPN tunnel to avoid unwanted data streams to get to your BC datacenter.

HTTP and HTTPS traffic should be controlled and limited to the really necessary verbs and URLs for common operations. If your application server exposes administrative panels or controls, lock its access on the edge firewall to reduce the attack surface. If, on the other hand, the AS exposes only one single URI to the web, like “http://myserver/wallet/”, allow the access uniquely to that single URI (and below structure).

If your administrators and/or system operators need to access a web administration portal, you should consider creating a rule to allow access to that specific port through the VPN connection only.

IPS should be active on all incoming requests and process the entire dataflow as it comes through the authorized ports. The IPS signature database should be updated at least every 4 hours.

Outgoing Firewall Traffic

This is usually the most broken configuration in a firewall. All the hosts shall have an inhibited access to the Internet except for the minimum requirements. Before configuring the access of outgoing traffic (i.e. where the TCP/IP handshake is initiated by a host inside the perimeter) define the following configuration components:

  • IP addresses of autorized resolvers
  • IP addresses of authorized and reliable NTP Servers
  • URLs of update sources (like repositories or update servers)

The inside hosts should be enabled to access only the following protocols:

  • DNS for name resolution (ports 53/tcp and 53/udp) allowed only to authorized resolvers
  • NTP for time synchronization (ports 123/tcp and 123/udp) allowed only to authorized NTP hosts
  • HTTP stricly limited to needs (see below, port 80/tcp)
  • HTTPS strictly limited to needs (see below, port 443/tcp)

HTTP and HTTPS traffic should be open only for system upgrade and update purpose. This traffic shall be ruled as follows:

  • if URL categorization present, all categories should be denied except the ones that could be useful for system administration (see note 1)
  • white-list only the URLs that are really responsible for helding update packages
  • enable SSL verification chain in HTTPS DPI feature to ensure SSL crafting or malformation (OCSP enforcement a plus, and disable old certificates)
  • enable Antivirus contro on all the incoming traffic from external hosts
  • disable possibly harmful verbs on connections (for example WebDAV extension should not be required for common operations).

note 1: if the firewall allows it, consider allowing the access to the required categories only for a limited time by authenticating a session on the firewall. In this case the system shall require:

  • authentication mechanism available only inside the perimeter or through the administrative VPN access;
  • the authentication mechanism should allow only one session per host, meaning a second host authenticated by the same user should either be denied or log-off the previous one;
  • the session shall expire forcefully in no more than 4 hours since the authentication

The above guideline should grant the lock-out of the hosts from access to the Internet in case of too long idle time or just ended administration routine.

Host to host connections

Whereas the application servers need to “talk” to other servers over the Internet, following rules shall apply:

  • consider implementing IPsec LAN-TO-LAN VPN tunnels to encrypt and secure the connections between many hosts;
  • if L2L VPN tunnel can not be established or created, consider narrowing down the outgoing connections only to the target remote IP addresses;
  • whether over Internet or encapsulated into a VPN tunnel, narrow down the traffic only to required protocols and ports essential for proper functioning.