{"id":2948,"date":"2018-06-02T10:01:39","date_gmt":"2018-06-02T14:01:39","guid":{"rendered":"http:\/\/chrisgrundemann.com\/?p=2948"},"modified":"2022-05-05T14:46:04","modified_gmt":"2022-05-05T18:46:04","slug":"open-source-network-security-cumulus-linux","status":"publish","type":"post","link":"https:\/\/chrisgrundemann.com\/index.php\/2018\/open-source-network-security-cumulus-linux\/","title":{"rendered":"Open Source Network Security with Cumulus Linux"},"content":{"rendered":"

Networks are changing. More and more we\u2019re hearing terms like whitebox, britebox, disaggregation, NOS, commodity hardware, and open source when we talk about the future of networking. I\u2019ll assume you get that and spare you a description of these terms here. If you do want a crash course on network disaggregation and how it relates to orchestration\/SDN, check out <\/span>my previous post on the Packet Pushers blog<\/span><\/a>.<\/span><\/p>\n

With that bit of housekeeping out of the way, let\u2019s dig right into today\u2019s topic: Open source network security.<\/span><\/p>\n

First, why does security<\/a> matter? If you\u2019re like most network engineers, your primary goal typically is to get bits of data from one place to another. Anything that interferes with the free flow of packets and frames is a potential problem. So the goals of security can at first appear contrary to those of the network. Raise your hand if you\u2019ve ever been frustrated by a firewall rule or some seemingly arcane security policy!<\/span><\/p>\n

Unfortunately, we no longer have the luxury of ignoring security. Today\u2019s network is one of the most crucial pieces of IT infrastructure for any organization and for the economies we operate in. It simply must work, which leaves us no time to deal with interruptions from malicious activities or bad actors.<\/span><\/p>\n

In fact, if we look at security from the highest levels, it\u2019s all about three things: confidentiality, integrity and availability. Even the most hard-nosed network engineer should recognize these ideals. Isn\u2019t that exactly what is needed to design, build and operate a trusted, reliable network?<\/span><\/p>\n

This probably isn\u2019t news to you. The demands for security are mounting just as quickly and forcefully as the demands for a more pervasive, resilient network. So how do you meet these demands? One way to build a flexible, cost-effective and programmable network is to leverage disaggregation and open source software. But is that safe? Can we have security and flexibility? Can we build an open source network for mission critical applications, or do we need to rely on manufacturers who provide proprietary software to ensure the level of security needed in today\u2019s networks?<\/span><\/p>\n

In this post, I\u2019ll use Cumulus Linux as a case study for secure open networking, and answer those exact questions.<\/span><\/p>\n

Open Source Security<\/span><\/h2>\n

Before we can answer the question of open source software\u2019s impact on the security of a network, we need to look at the security of open source itself.<\/span><\/p>\n

As you know, the defining characteristic of open source software is that the source code is made publicly available to all. This is in contrast to proprietary, closed source software where the company who writes the code keeps it a secret.<\/span><\/p>\n

This distinction is also the root of the most contentious security debate between open source and proprietary software in general. <\/span><\/p>\n

Proponents of proprietary software will tell us that publishing the source code of open source software allows bad actors to easily identify, understand and exploit security flaws in the software. Anyone can download and examine it! They will go on to say that proprietary software is thus safer, because the code is a secret, and that it is much harder to reverse engineer security flaws than it is to simply find them in open code repositories. OK, makes sense.<\/span><\/p>\n

On the other side of this debate are the open source proponents who will tell you that sunlight is the best disinfectant. That is, that more eyes on the code means better software because a wide and diverse community of developers is able to review the code, identify flaws and fix them directly. No need to wait for the vendor to accept your request and make the needed changes. Now <\/span>that\u2019s<\/span><\/i> interesting!<\/span><\/p>\n

This open versus closed debate is one that seems to have been largely settled in the cryptography space and captured in what is called \u2018Kerckhoff\u2019s Principle,\u2019 which reads; \u201c<\/span>A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.<\/span><\/i>\u201d Meaning that the best system does not rely on secrets to be secure, but rather on robust engineering. This is essentially the opposite of \u2018security through obscurity\u2019 and was further refined by Claude Shannon into the following maxim: \u201c<\/span>one ought to design systems under the assumption that the enemy will immediately gain full familiarity with them.<\/span><\/i>“<\/span><\/p>\n

Bruce Schneier, a world renowned security expert, <\/span>explained this in a newsletter<\/span><\/a>, back in 1999: \u00a0“<\/span>In the cryptography world, we consider open source necessary for good security; we have for decades. Public security is always more secure than proprietary security. It’s true for cryptographic algorithms, security protocols, and security source code. For us, open source isn’t just a business model; it’s smart engineering practice.<\/span><\/i>” He goes on to push back on the idea that being public is itself a flaw: “<\/span>Public algorithms are designed to be secure even though they are public; that’s how they’re made. So there’s no risk in making them public. If an algorithm is only secure if it remains secret, then it will only be secure until someone reverse-engineers and publishes the algorithms.<\/span><\/i>\u201d Finally he talks about the speed with which flaws can be worked out of open versus closed source systems: \u201c<\/span>So a two year-old piece of open source code is likely to have far fewer security flaws than proprietary code, simply because so many of them have been found and fixed over that time. Security flaws will also be discovered in proprietary code, but at a much slower rate.<\/span><\/i>\u201d<\/span><\/p>\n

There is, however, a potential flaw in this argument when we\u2019re talking about open source code in general. In order for openness to result in additional security (and fewer bugs overall), we need to ensure that it is in fact being reviewed. Luckily for our case study, Cumulus Linux is based on Linux, one of the most reviewed open source code bases on the planet. This is true of most open NOS\u2019s, so it\u2019s worth taking a look more specifically at Linux itself.<\/span><\/p>\n

Linux Security<\/span><\/h2>\n

In addition to being an open source operating system, Linux is one of the most prominent and popular examples of free and open source software ever.<\/span><\/p>\n

Knowing that, it is likely not surprising that the Linux model creates security through transparency. With its large base of developers from all over the world, across many industries, communities and organizations, we can be fairly certain that Linux is getting all of the expert attention needed to ensure swift identification and eradication of security flaws.<\/span><\/p>\n

Debian Linux<\/span><\/h3>\n

One specific detail that is pertinent to our current case study is that Cumulus Linux leverages the Debian distribution of Linux. It is instructive then to take a look at the <\/span>Debian Linux security policies<\/span><\/a>: \u201c<\/span>Debian takes security very seriously. We handle all security problems brought to our attention and ensure that they are corrected within a reasonable timeframe. Many advisories are coordinated with other free software vendors and are published the same day a vulnerability is made public and we also have a Security Audit team that reviews the archive looking for new or unfixed security bugs. Experience has shown that security through obscurity does not work. Public disclosure allows for more rapid and better solutions to security problems.<\/span><\/i>\u201d<\/span><\/p>\n

With a wide community developing, testing and supporting Debian, it becomes nearly impossible for bad actors (think state actors, malicious hackers and others) to insert backdoors or other intentional security flaws because they would simply be caught by the experts who are constantly reviewing the code. Contrast this with proprietary systems, where only a privileged set of employees from one group in one company has access to the code. It appears obvious which system has the potential to be more secure.<\/span><\/p>\n

Linux Security Tools<\/span><\/h3>\n

In addition to all the expert eyes pursuing the code, reviewing changes and providing transparent security announcements, Linux offers many native security tools. These tools are available to any system based on a full and open Linux distribution. Let\u2019s look briefly at a few of them.<\/span><\/p>\n

A <\/span>pluggable authentication module (PAM)<\/span><\/a> is a mechanism to integrate multiple low-level authentication schemes into a high-level application programming interface (API). It\u2019s a one stop shop for authentication that has been available as a stand-alone offering since 1996. Imagine how many expert eyes have reviewed and ensured its robustness in those twenty plus years! Cumulus uses PAM to control the length and strength of passwords and ensure solid defaults. This can be enhanced with packages such as the libpam_pwquality and pam_cracklib, which are available on the Debian repository.<\/span><\/p>\n

Another password related tool is the libsnmp-dev package that can be installed on an open Linux device to prevent the use of cleartext passwords with SNMPv3. <\/span><\/p>\n

While strong passwords can help keep unauthorized users from logging into a network device, we also have to be vigilant of many other forms of attack and malicious traffic. To view and control the ports open on a Linux device, we have tools such as netstat and systemctl. There is also a suite of Linux netfilter tools (iptables, ip6tables, and ebtables) to identify and filter specific IPv4, IPv6 and layer 2 datagrams. Oh, and don\u2019t forget the denyhosts utility (available on the Debian repository) for helping to prevent SSH attacks.<\/span><\/p>\n

Beyond these, there is a list of additional tools too long to dig into here. Things like snort, pfsense and clamav are all available to increase the security of an open network device and the networks it is connected to.<\/span><\/p>\n

Proprietary Linux<\/span><\/h3>\n

Some of you may be thinking, \u201cSo what? My favorite big name IT vendor uses a Linux\/BSD kernel, so I\u2019m already getting all of this, right?\u201d<\/span><\/p>\n

Well, not necessarily. Just because something uses a *nix kernel under the hood does not always guarantee the same advantages that an open NOS provides. In fact, it is quite likely that the very act of making the operating system proprietary actually negates many of these advantages.<\/span><\/p>\n

Right off the bat, you lose the ability to immediately apply community patches to discovered security flaws. Because the system is now proprietary, you are forced to wait for the vendor to identify, accept and test the patch on their modified version of the software. Think of <\/span>the lag<\/span><\/a> between pure vanilla Android updates and those provided by large phone manufacturers that repackage Android into their own particular flavor.<\/span><\/p>\n

Even worse, the folks who implemented the proprietary system could have included old versions of open source packages, or made other mistakes that make the software less secure. And because these proprietary systems are closed source, there is no easy way to examine the code to identify such missteps. We have to just wait for someone to reverse engineer the software, or otherwise exploit the flaw. That is obviously less than ideal. And what about intentional weaknesses? Can you really trust any code that you aren\u2019t allowed to examine for yourself?<\/span><\/p>\n

Another major factor to consider with proprietary software, whether based on Linux or not, is your access. With an open NOS, you have full access to see and change anything you need. The level of visibility and granularity of control is hard to beat in any proprietary system. An open NOS also gives you the ability to install and use the widest array of additional packages and tools. Have you ever tried to run snort on a legacy monolithic networking device? Chances are you couldn\u2019t even attempt it.<\/span><\/p>\n

There are two caveats we need to address here:<\/span><\/p>\n

    \n
  1. Networking vendors are obviously not offering closed source proprietary software with the intention of making it less secure. So why are they? One reason to consider is that by closing the system, offering less visibility and control, they are actually making it less prone to user error. Call this the guardrail effect, and be sure you are ready to own your destiny if you dive into fully open systems.<\/span><\/li>\n
  2. Many traditionally closed operating systems are being opened up to allow more access to run third party tools, use APIs, etc. Rather than a knock against open systems, this seems to be a validation of the model, and an indicator of where the future might lie.<\/span><\/li>\n<\/ol>\n

    Whether a vendor builds proprietary software for more control, more profit or more features, the fact remains that closed source systems are islands that will never be as fully explored as open source systems. There is just no way that more people are using any one proprietary NOS than are using Linux. Thus, there will always be more expert eyes looking out for (and correcting) problems in the latter than in the former.<\/span><\/p>\n

    Cumulus Linux Security<\/span><\/h2>\n

    So far we\u2019ve seen that open source software can be just as secure as proprietary software as long as there is an active community of experts reviewing the code \u2014 and that Linux has such a community. But how does that translate into networking and the security of a network built on open software? I\u2019m glad you asked. Using Cumulus Linux as our case study, we\u2019re going to dive down that rabbit hole right now.<\/span><\/p>\n

    The first thing worth pointing out is what doesn\u2019t change when going from a proprietary NOS to a more open one. Overall, the same security protocols and techniques are used in both. Cumulus Linux uses the industry standard OpenSSH suite, including support for local passwords, LDAP, TACACS+ and private keys. Cumulus makes available, and recommends using SNMPv3 for secure authentication and encryption of management traffic. Need a management VRF to keep that traffic separate? Check mark. And what about routing protocol security? Again, industry standard implementations of BGP, OSPF, BFDS, MD5, TTLs, etc.<\/span><\/p>\n

    Perhaps a bit more interesting and unique is how well Cumulus Linux is hardened by default:<\/span><\/p>\n