- August 30, 2018
-
Justin Penchina
- 9 min
Moving into our new space has afforded us with the opportunity to completely rebuild our network. While we don’t have the most complex requirements, we do want to make our network as simple, stable, and secure as possible.
The Firewall
Network security starts with the firewall. We chose a pair of SonicWall NSA 2650’s configured for high availability. High availability links two firewalls together so that if one of them is offline the other one kicks in and keeps the network online.
SonicWall NSA 2650 Firewalls
Get in the Zone
SonicWall devices use a zone based approach to security. When designing a network, you define different zones of the network within the firewall. You then create rules to govern how traffic can move between the zones. Valiant’s network contains 5 distinct zones. The two most common are WAN and LAN, representing the wild Internet and our trusted internal network. We also have zones to isolate traffic for our wireless guest network, our phone system, and our door access security system.
Our lab network is physically isolated behind its own firewall, so it does not come into play here.
With the zones defined, the next thing to do is create rules to allow or deny traffic. The most important rules to define are the rules between the WAN zone, and the other zones as the WAN is the wide-open internet. By default, we want to lock down anything that is unexpected and then explicitly allow traffic that we know to be safe.
At the most basic level, all traffic coming in from the WAN is blocked. We also locked outbound DNS requests to specific, known-good DNS servers (to prevent DNS hijacking attacks) and blocked non-necessary services such as SMB and SSH (these will be allowed as needed.) These steps alone can prevent a host of malware and ransomware attacks – even without advanced filtering.
Deep Impact
One of the major draws for SonicWall products is the Deep Packet Inspection engine. The firewall examines packets coming in and out of the network and can apply rules or policies on the traffic. Some basic rules are: don’t allow known viruses through the firewall and don’t let users access adult-oriented sites.
These rules can get pretty granular. For example, we set a rule that blocks “pornography” content outright. The “drugs” category is blocked, but users can temporarily unblock and access the content by clicking on a link that logs the request. This is especially useful for the “grey area” categories that may have legitimate uses, particularly when related to our healthcare clients.
There are also application rules blocking services such as Tor or P2P clients from the main network. Non-business applications such as Facebook and Spotify aren’t blocked outright, but bandwidth shaping policies make sure that these sites don’t hog the internet and choke out users trying to get work done.
Handling the Unknown Unknowns
The firewall runs a series of signature-based filters such as an antivirus filter, a botnet filter, and an antispyware filter. Known malicious sites or programs are blocked from coming into (or going out of) the network. But what about new or undiscovered malware?
Zero-day exploits are becoming more and more prevalent with exploits such as Spectre, Meltdown, and Petya making headline news. SonicWall protects against these with a subscription service that automatically uploads any unknown Office, PDF, and executable files to a SonicWall datacenter, where it is run through four different sandboxing engines. These engines run a multitude of antivirus scans, real time data scans, and behavioral analysis. If the file is considered safe, the download completes, and the file is saved.
Inspect ALL the Packets
One major challenge to securing a corporate network is the prevalence of encrypted web traffic. SSL encryption is good for security overall, especially for home users – and services such as CloudFlare and Let’s Encrypt have made it easier than ever for small website developers to cheaply secure their sites. Google’s Chrome browser showing HTTP sites as “insecure” and plugins such as HTTPS Everywhere have made users used to checking for the green address bar. As a result, between 60% and 70% of all web traffic passing through corporate firewalls is encrypted. While our approaches are designed to encrypt traffic for an entire office, there are many steps individuals can take to ensure their Internet traffic is encrypted as well.
The challenge for corporate security is that all this encrypted traffic is normally unreadable by the firewall. All those fancy filters see encrypted as gibberish and have no choice but to let it through to the network. Malware-makers are wise to this and have begun encrypting their command and control sites, making them pass straight through these filters.
To combat this, SonicWall has a service called DPI-SSL. Essentially, this allows the firewall to decrypt SSL traffic and then re-encrypt it before passing it to the end user. With this in place, all traffic passing through the firewall can be run through the filters, severely limiting the ability for malware to make it into the network. This filtering can be coupled with the content filter engine so that known-good sites are exempt from extra filtering. This is important both to preserve CPU power on the firewall, but also to enhance privacy. For example, healthcare and banking sites can be easily excluded from the DPI-SSL engine. For our network, we have also excluded sites like Microsoft, Meraki, Apple, Dell, and Datto that we use on a regular basis as we know them to be trustworthy sites.
Patch Cables and ARP Tables
With the SonicWall at the head of the network, the next thing to secure is client access. The most basic of client access is a simple wired connection. Powering our wired network are three Meraki switches – one 24 port switch for in-rack connections and two 48 port PoE switches for end user access. The Meraki dashboard makes it simple to extend the security we started in the SonicWall to the rest of the network.
Each of the SonicWall’s Zones has its own dedicated VLAN on the rest of the network. This allows traffic from different zones to run through the same switches without the zones gaining access to each other. For example, the Security zone for the security system is locked down so that it can only access the web-based controller. Computers, servers, and phones cannot see that the Security system exists, even though they are plugged into the same switch.
As added security, the Security ports are locked down so that only the keyfob readers can be connected. If you disconnect a key reader and plug in a laptop the Meraki switches will block access.
The port numbering and wire management is also key to security. Each network port in the office is labeled with a letter and a number, which directly corresponds to a switch and port in the Meraki console. For example, the A9 port in the wall is port 9 in switch “A.” This means that there is never a need to trace cables or move plugs to make sure a device is on the right network.
Neatly organized patch panel and CAT5 cables
This is especially useful for IOT devices such as presentation devices or Raspberry Pi boards to control lighting. As long as you know the port number on the wall you can use the Meraki dashboard to modify the correct port and put the device on the guest network. This keeps potentially insecure devices off the main network without needing to re-patch network cables into a “guest” switch.
Since there is no need to re-patch cables we can keep the network equipment in a locked cabinet and in a locked room. This prevents someone from accidentally unplugging a cable or disrupting something when working on the network.
For phones, the Meraki switches will auto-detect that a phone is connected to a port and automatically put it on the voice VLAN. With every port running PoE this means that desk phones can get plugged in wherever they make the most sense. It also means we can make use of the passthrough port on the back of the phones, effectively doubling the number of devices we can connect.
The switches also block unsanctioned DHCP servers from the network. From the dashboard we are able to tell the switches what ports DHCP servers are allowed to be connected. If the switches detect DHCP on another port they send up an alert. This is especially easy as there is a dedicated “core” switch for all the equipment our rack. The wall ports in the office all run through dedicated “access” switches that should never have DHCP servers. It is surprising how many times a network is brought down because someone has plugged in a home router to a corporate network.
Cutting the Cord
While desktops and servers will be connected to wired connections, most devices in the office are going to be connected to Wi-Fi. Laptops, tablets, and mobile phones all connect to the wireless network. To make sure there is always enough signal, we have four Meraki MR33 wireless access points.
Cisco Meraki WAP
These broadcast both the main Wi-Fi and the Guest network in 802.11ac. By combining the Meraki WAPs with the Meraki Switches we are able to create some cool rules. For example, the rogue AP settings protect the network against unsanctioned access points that someone might plug in.
Eye in the Sky
The last piece of network security is in some ways the simplest: physical security. Aside from multiple locked doors between the outside and our network cabinet we have installed a series of Meraki cameras.
Meraki Cloud-based Camera
These cloud-controlled cameras record motion at the two entrances to the office and the door to our Lab and network cabinet. Time based notification rules send out alerts if anyone goes in or out of the office outside of normal operating hours.
The camera dashboard has some cool features too like motion search. This lets you highlight a section of screen and search for motion in that area. The motion capture system also helps extend the recording time of the cameras. All footage is kept for a few days, but then after that anything without motion is dropped to save space. This way we can go further back in time for motion events and don’t have to keep the hours of nothing that gets recorded overnight.
The Lab
Our lab has its own dedicated network environment. It is physically segmented from the rest of our network with its own SonicWall, Meraki switch and Meraki WAP. This protects our corporate network from potentially dangerous traffic such as malware infected machines or system image servers.
Jeremiah and Paul in the lab
The Meraki Dashboard makes it easy to create isolated network VLANs within the lab. This is especially useful for isolating malware infected machines. We can connect an infected machine to a dedicated SSID to allow it internet access but ensure that it is isolated not only from our network but also from any other machines being serviced in the lab.
Stability Starts Here
The network is at the core of a stable work environment. It touches and connects every piece of technology. The rise of cloud services and computing makes stable network access even more important as fewer programs run on local machines and more services rely on the internet.
Georg Dauterman and Tommy Madsen
What are some of the techniques your company uses to keep your network running? Where do you draw the line between securing your systems and ease of access? Let us know in the comments below.
