- June 10, 2015
- Posted by: atlantadmin
- Category: Blog
Hardware-level encryption between nodes via built-in encryption in the network cards / other networking equipment is desirable, but not necessary – the same can be achieved via software in budget-oriented organizations.
Network outlets should be properly secured (in an ideal world, with a physical lock of the cable to the network outlet, making it impossible to unplug or connect something else without changing the lock).
The minimum level of security for said network outlets is a strong NAC (network access control) based on a whitelist of allowed devices and vendors mapped to specific network outlets.
Before you buy a device you should have some idea how secure it is, how prone it is to compromise and how well it can integrate with other secure elements in your organization. As you could imagine, someone has already done this work for you at least to some extent:
On this page you could see all components which have already been tested and approved for use in US military environments. I suppose that’s good enough for most organizations.
What comes next is for you to secure your core network services.
DNS is critical to your networking infrastructure. Even so, when setting up the foundation of your core network, you better not rely only on the decisions of your trusted sysadmins as they are mostly focused on functionality and performance and leave security last.
The most widely used DNS server is BIND – it is also the most widely exploited one. It has been plagued with bugs and security holes since its inception. If you are really serious about your security, I suggest you think twice and only use BIND if you are absolutely sure in what it has to offer and are ready to accept the risk.
http://cr.yp.to/djbdns.html – this project is not as flexible or as powerful as most other DNS servers in existence – but it surely is more secure and reliable than most.
If you can afford the time and effort to make the switch – and especially if you are still using BIND – you should.
The attack surface of djbdns compared to BIND is … uncomparable. There maybe was one exploit published for djbdns – compared to hundreds for BIND. If you can, start at least with testing the server and evaluating its capabilities in a test environment.
I will not mention vendors in this part of the book, but you might as well guess who they are. Being the most targeted in the world, you can be certain there are multitudes of 0-day exploits for their devices in the hands of various actors. They might not be your adversaries – nor your country – but being vulnerable can still render your network incapacitated as a collateral damage in somebody else’s battle.
Besides, referring to the all-popular ‘leaks’ we can all be assured with a high level of certainty that many popular network device vendors have released and keep releasing intentionally or non-intentionally backdoored products.
Even if they are not backdoored when leaving the factory, the process for backdooring them on the way to your premises is documented and practiced to perfection. So you cannot rely on their invincibility from any point of view – and if it was my choice, I would never trust my router to a popular vendor.
There are non-commercial, open-source alternatives.
The BSD Router project – thanks, Ivan Natchkov, for pointing this project out!
Most environments don’t need the overly complex and incredibly expensive commercial routing products. Unless there are features which the vendors offer you and you really need them, I suggest you go with the BSD Router Project, as it is very secure, very effective and, well, very free.
From the project’s features page:
Base OS: Embedded FreeBSD 10-stable using NanoBSD, Easy upgrade process using two system partitions
Routing features: All routing protocol supported by quagga: BGP, RIP and RIPng (IPv6), OSPF v2 and OSFP v3 (IPv6), ISIS All routing protocol supported by Bird: BGP, RIP and RIPng (IPv6), OSPF v2 and OSFP v3 (IPv6)
Multicast: DVMRP, IPv6 PIM Dense Mode and Sparse Mode
Multiple FIB: 16 Routing Tables available
High availability with CARP (support also load balancing the incoming connections) and VRRP.
Multi-link PPP: PPTP, PPPoE, L2TP, etc… (all features supported by mpd)
VPN: GRE, GIF, IPSec (IKEv1 and IKEv2) and OpenVPN
IPv6: native 6to4 tunnels and Tayga NAT64
Qos: Traffic shaper with IPFW+dummynet supporting: FIFO, WF2Q+, RR (Deficit Round Robin), QFQ, Alternate queuing with ALTQ supporting: CBQ (Class Based Queuing), RED (Random Early Detection), RIO (Random Early Drop), HFSC (Hierarchical Packet Scheduler), PRIQ (Priority Queuing), Committed Access Rate with netgraph: Single rate three color marker (RFC 2697), two rate three color marker (RFC 2698), RED-like, Traffic shaping with RED
Ethernet features: 802.1q vlan tagging, link aggregation and link failover interface, bridging with support of Rapid Spanning Tree Protocol (802.1w)
Network services: DHCP Relay, DHCP Server
Management: From CLI only: local console, serial and SSH access, Command completion with somes BSDRP tools: config, system, show and upgrade
Monitoring: SNMP v1,v2c and v3, Syslog, Mail, Netflow with native ng_netflow (v5 and v9)
Security: mtree reference files available for system integrity check (sha256)
Building your own router from scratch on OpenBSD
OpenBSD is considered to be more secure than FreeBSD, on which the ORP is based. You can see a full tutorial on building such a router at http://www.bsdnow.tv/tutorials/openbsd-router