Network Protection Stack

Written By Marissa Fegan (Super Administrator)

Updated at February 18th, 2021

VIPRE Endpoint Security examines files and processes on your endpoints and makes sure no malicious code is present, but that's not all it does: we also include a complete network protection stack to ward off network-based attacks.

Understanding Our Protection

To understand how our technology protects you, we've created the guide below which provides some background on network attacks of various kinds and then explains where and how VIPRE detects and prevents those attacks.


Decision Tree

Networking Basics

Most of the work we do on our computers involves network connections - loading web pages, of course, but even viewing a Word document will often include the program reading content from a remote system. Users visiting web pages, applications checking for updates, and also malware downloading exploit code: these all use the global Internet and DNS to connect to remote systems and retrieve data from them.

How the Internet Works

At the most basic level, almost all network connections start with one key thing: the name of a remote system or host to connect to (such as "www.vipre.com"). Any program that wants to connect to another computer must know the name of the remote host, but the very first thing that needs to happen is that that hostname needs to be converted into a number because computers work in numbers. Converting the hostname into a number, or address, is tricky; there are many millions of them, they change all the time, and there's no way for your local computer to have pre-loaded information about every hostname and IP address. Enter the global DNS (Domain Name System).

Global DNS allows computers to take a name, like 'www.vipre.com', and convert that to a number, or IP (Internet Protocol) address. Because this is a global system, DNS is designed as a hierarchy with many distributed systems (called resolvers) spread across the world that can resolve names to IP addresses for you. Typically, you only need to know one or  two of nearby resolvers. If they don't know the answer, they can forward on the request to other resolvers, closer to the owner of the name, until the answer is discovered. And many companies set up local resolvers, often on their external router, and point all the company's endpoints to that resolver: that resolver will service all the requests from internal computers attempting to look up names, and will also cache the results so that subsequent requests for the same name will be much quicker and more efficient.

Once the program on your computer has the IP address that it needs to connect to, it will then attempt to set up a network connection to the remote host. There are a lot of complexities like ports and routing and connection setup, which we can mostly skip over for the purpose of this discussion. In the end, the program running on your local computer and the service on the remote host have a channel set up within which messages can be exchanged. These messages are wrapped into packets with successive layers of metadata that help the intervening network properly format and route the messages, possibly splitting them into smaller pieces if there are networks between you and the remote host that can't handle smaller packet sizes. If the protocol is encrypted, the message itself is converted into what looks like random noise but which the remote host can decipher, before being embedded in the network packet. A representation of what this looks like might be:

In this representation, the message from the application is encrypted into a TLS (Transport Layer Security, an encryption protocol) message, then this is wrapped in a TCP frame (Transport Control Protocol, which helps manage the control flow of packets back and forth from the remote host), then in an IP frame (Internet Protocol, which tells the network equipment on the wire how to route the packet to and from the remote host), and then an Ethernet frame (Ethernet is a hardware standard that describes how electrical signals are transmitted on the wire and allows one host to communicate to another nearby host). As your message packet transmits from your localhost to the next "hop" on the route between your computer and the remote host, the outer layers of the packet may be unwrapped, interpreted, and even replaced or re-written as your message is transferred to the next hop. But the application message embedded within the innermost frame will remain undisturbed, or at least that's what is supposed to happen—one of the weaknesses of unencrypted protocols is that it could allow attackers to re-write message contents, a man-in-the-middle attack, which could compromise the communications between you and the remote service.

The finer details of how this all works and what the actual messages look like are not important for this discussion, but the key point is this: your computer must first look up the name of a remote host to connect to, and then it will wrap up application data (possibly encrypted) into a multi-layer packet, and send it across the network. This will be unwrapped and interpreted by the remote system, which will then reply in the same way. Or conversely, if someone wants to communicate with you, they, in turn, have to look up your hostname, construct a network packet, and send it to you and then your computer, if it's listening, will receive that packet, unpack it, and reply.


  • Learn about Network Attacks
  • Add Button

Network Attacks

So how do attackers take advantage of your network communications to compromise your computer? Well, the methods used are many, but we will briefly discuss how a few common attack types work.

Buffer Overflow

With this type of exploit, an attacker takes advantage of a flaw in a process that is reading some input (perhaps the contents of a network packet) and makes assumptions about the size of that input. If the size of the input is larger than expected and the process isn't careful, the excess data can overflow the buffer (storage) intended to hold it, with unpredictable results. In some cases, the attacker can cause the receiving program to execute the contents that overflow the buffer, which means they can run untrusted code on the remote host.

Code Injection

This is similar to a buffer overflow but slightly different in that no buffer is overflowed; instead, the attacker tricks the interpreter into executing code that it doesn't intend to—perhaps by inserting special characters into the data, the receiving program is interpreting.

Web Exploit

Web browsers are a special case because they actually intend to execute arbitrary code (such as JavaScript) that is carried along with the webpage contents. There are many security controls in place, but there are just as many clever ways that attackers have found to get around those controls and perform malicious actions on the target system.

Direct Download

If the attacker can arrange somehow to get your computer to execute a tiny little bit of code (perhaps using one or more of the previously listed attacks), it can initiate another network connection to fetch a file from a remote host and execute that file, thus exposing your computer to a much wider range of possible attacks.

Takeaways

The above exploits can occur at any point along the way where the data is being interpreted. Any computer receiving a network packet has to interpret each layer in the packet in order to process it correctly:

  • Ethernet frame by the network driver
  • IP frame by the IP stack
  • TCP frame by the TCP stack
  • TLS decryption algorithm (optionally)
  • Application data by the ultimate receiving program

If any of these interpreters have flaws, the attacker can exploit them.

It's important to note that the malicious network data has to be able to reach its target. This can happen because:

  • Outer layers of the network stack on your computer are vulnerable; this is rare
  • A program on your computer is left listening for unsolicited incoming connections and the attacker sends data to that listener; there are very few listening services that need to be running
  • A network reply to a query from your computer carries with it malicious data
    • Example: data you get back when your web browser goes to fetch a web page

Now, let's learn about VIPRE Network Protection and how it protects you.


  • Learn about VIPRE Network Protection
  • Add Button

VIPRE Network Protection

VIPRE Network Protection has many layers, each of which is designed to protect your computer from the many different flavors and combinations of attacks.

Firewall

One of the most basic forms of protection, the firewall prevents attacks from reaching their target. As mentioned, there are very few listening network services that endpoints need to be running because initial communication is outbound; the firewall blocks access to any unnecessary services. For example, if an attacker tries to connect to your filesharing service on Windows (e.g., Wannacry Ransomware) and you don't have a reason to allow other computers to download files from your computer, the firewall can block that access. Firewalls typically work at the very outer layers of the network stack and prevent unwanted connections from getting to any of the tasty insides of your computer.

Think of a firewall as locking the doors to a building. Refer to Related Articles for information about managing the firewall.

Intrusion Detection System (IDS)

Intrusion Detection Systems are a little different. An IDS looks at the network traffic flowing in and out of a system. It can block network packets if it's warranted, just like a firewall, but the IDS is looking for specific patterns within the network packets that tell it that there's something funny going on. Much like the firewall, the IDS can look for suspicious data in the IP frame portion of the packet, but they can also look at the other frames and within the application data itself. If that application data is encrypted, however, it looks like random noise to the IDS, so it won't be able to catch anything at this level. The IDS operates on an extensible set of rules that tell it what to look for.

The IDS can:

  • Look for attempts to trigger buffer overflows or other flaws within the Ethernet, IP, and TCP stacks
    • This data is always unencrypted

  • Block access to/from specific IP addresses if configured to do so

  • Look for exploits within application data, if it is unencrypted, such as HTTP web pages, FTP traffic, DNS traffic, and many other unencrypted protocols

  • Look for known malicious content within data transferred by unencrypted protocols such as HTTP, FTP, SMTP, IMAP, etc

    • This content may not be explicitly targeting a vulnerability within the network stack but may indicate that someone is attempting to download a malicious file, which may later be executed. For example, this may catch malware downloading additional modules, or malicious files in emails.

You can think of the IDS as a bouncer standing by the door to your club, checking the IDs and looking for suspicious behavior.

DNS Protection

Virtually all network communications start with your local computer looking up a remote hostname to determine an IP address. On any given day, thousands of remote hosts report as delivering malicious content to our global threat intelligence service. Our DNS Protection service helps prevent you from accidentally (or intentionally!) visiting one of those malicious sites by intercepting DNS queries for those known-malicious domains, and replacing the usual IP address response with a redirect to our DNS sinkhole, which is a website that presents a webpage that says "you can't go here!"

You can think of DNS Protection as your mom, who won't let you go to that cool (but dangerous) new club you heard about. Refer to Related Articles to learn more about using DNS Protection.

Malicious URL Blocking

It's not always the case that an entire site can be blocked, mainly if that site hosts content from other people or other sites—think of GitHub, for example. In these cases, the specific page or other web resources may be undesirable, but the rest of the site is perfectly fine, and blocking the whole site would cause disruption. Not to worry, VIPRE can block access to specific URLs and, best of all, it does so by checking all visited URLs against a cloud-based global threat intelligence network that is kept up-to-the-minute updated with the latest list of known-bad URLs.

Refer to our content for more details:

Web Exploit Prevention

This capability is a bit of a special case. Web Exploit Prevention (WEP) is based on the IDS technology but goes deep into any HTTP (web) traffic on your machine, and looks explicitly for potentially malicious code embedded in web pages, including malvertising, exploit kits, etc.

Think of WEP as the guy with the metal detecting wand that scans customers after they get past the bouncer.

Browser Plugins

One of the challenges with encrypted data is that although the outer packet frames are visible to the firewall and IDS, the actual application data is invisible. For most web pages, this means that the content of the page, and even the URL that was retrieved, can't be seen by the IDS. To fill this gap, VIPRE includes a browser extension that runs within the browser itself to extract important content (e.g., the decrypted URLs) and then passes that data to the detection engine for analysis. This allows us to protect your computer against even encrypted web pages that could be malicious.