Hop Limit Security 101

1. HOPZERO leverages existing capabilities of the Internet Protocol used by ALL communications on the Internet to prevent data theft. Every router and firewall on the Internet inherently enforces this protection today. No large-scale device upgrade or replacement required. This creates a huge cost advantage.
2. HOPZERO complements existing network security tools. If a hacker breaches the firewall or obtains user credentials (both common occurrences today), they still cannot access critical systems unless they launch their attack within a tight network radius. If the hacker attempts to connect from outside that radius, the attack is blocked and an alarm is triggered. There is no indication how far a hacker is from the target or how close they need to be except by probing, which will trigger the alarm.
3. Alerts are high-quality and contain specific, actionable information indicating who attacked, where they were attacking, when the attack occurred and what they were trying to do. No signatures are required, eliminating a weakness of many IDS/IPS systems. Alerts are triggered on specific actions instead of machine learning, which often generates a lot of false positives and imprecise warnings.
4. HOPZERO monitors from the core of the network and out-of-band from normal traffic flow. This protects the components from attacks to disable the security system.
5. Since hop limits are applied to data packets leaving critical servers, there is no overhead beyond normal network forwarding. The approach has no performance impact on network speeds.

HOPZERO provides capabilities found in firewalls, IDS/IPS and DLP systems using an orthogonal approach to detect threats the other tools miss.

GeoIP is a great tool for determining approximately where your customers or web visitors are located. It is very good for identifying country (as long as the country has an assigned IP range). The more precise you want to get on location, the greater the error rate. For fun, look at the Potwin Kansas IP address issues.

A better approach to block countries is to skip geoIP and simply blacklist the IP address ranges for unwanted countries. This assumes people are coming directly from those countries, not leveraging a pivot point in another country.

We use geoIP to show people where their machines are connecting. This is primarily outbound traffic, which indicates machines accessing Internet services. We enrich the geoIP info with details about the endpoint describing threat likelihood. This helps identify whether internal machines are connecting to malicious endpoints.

Hops can protect key data servers. Those machines have private IP addresses. Since private IP addresses are not routable on the Internet, all attacks are “insider attacks”; i.e. they originate from a private IP address within the organization. GeoIP data is not available for private IP addresses so it cannot be used for that purpose. By controlling hops, we are able to prevent attacks from external attackers leveraging a pivot point within the organization and we can prevent true inside attacks. We provide detailed information on those attacks including where the attack originated, which server was attacked and what application they were attempting to compromise. The security team can leverage those details to remediate the compromised machine. Our approach exposes hackers who often remain undetected over 200 days on an enterprise network.

HOPZERO cannot tell if data is going to the correct location. Only the application owner knows that. We provide a lot of information describing risks associated with devices that are communicating. This includes internal machines peering with external machines and even internal-to-internal connections.

For example, we provide information about the location of each external endpoint, the company that owns it, their service provider, whether that machine has engaged in fraud, or is hiding behind a VPN. In the end, only the application owner knows whether a specific machine should be communicating with Russia or whether the user in Sacramento should be connecting to the finance server.

HOPZERO helps application teams and security teams collaborate by making rich information available to both. We start by identifying where data is traveling and enriching that data with information about the endpoints, distance, data volumes, and known threats. Application owners can quickly spot unexpected endpoints; security teams can escalate questionable sessions.

When working with customers we commonly hear something like, “Oh my God! Why is my data going to Kazakhstan?” or “Why is Google crawling my file server.” When an application data owner first sees their data-access patterns, they have a visceral reaction.

We map data travel by data application owner, so that they now know real app behavior. Up to this point, application data owners are “sitting ducks” waiting to get compromised, hoping all those guys in that security operation center are doing a good job, and their data is safe. How can the SOC team enforce security without knowing details about how the app is supposed to function? HOPZERO brings application and security experts together.

HOPZERO provides rich information users can access. The front-end of this helps people see right away:

• Where is my data going?
• Who is it going to?
• What’s my exposure with sending that data?
• How much data went to that device?
• How much data came from that device?
• Am I getting infiltrated, exfiltrated?
• What’s my performance?”

This highlights a critical flaw in most security operations. Application groups develop or purchase tools, give them to DevOps to deploy, and entrust the security group to keep them safe. The security group has no idea whether the app should access Russia or accept connections from Sacramento. Application teams are not experts in dealing with security constraints like firewall rules. HOPZERO provides tools enabling application owners and security teams to collaborate.

That depends on the product. For a snapshot assessment, no special hardware or software is required. Users can use capture software such as Wireshark to create a capture file, that is available for free download (https://www.wireshark.org/download.html). Wireshark is a widely-used and trusted network-analysis tool.

We provide step-by-step instructions on our website on how to use Wireshark to collect and save network data. We also show how to set capture length so that only routing information is collected. The payload information, potentially containing private information, is discarded so customer privacy is protected.

Expert users can collect information using other packet sniffers or operating system utilities like tcpdump. Organizations with packet capture devices already in place can export header information and upload.

For continuous monitoring HOPZERO provides devices to collect and analyze packet information. These can be on-premise hardware and software or machines in the cloud. Cloud connection requires on-premise data aggregation devices like those from Keysight or Gigamon to extract only the routing headers and forward that information to our SaaS software over an encrypted GRE tunnel. This prevents even the routing headers from being exposed on the Internet.

Our snapshot solution uses Citrix ShareFile to receive and post analysis files and post customer reports into their private portal. It is a secure filesharing cloud solution that supports two factor authentication for customers who require it.

Packet analysis is performed in the AWS cloud.

Citrix ShareFile stores your files in secure, SSAE 16 audited datacenters. Their server farm is privately managed and equipped with the latest firewalls and Internet security updates to help keep your data completely safe, and physical security measures from fingerprint scanners to ballistic-proof exteriors protect against theft and natural disaster. You can learn more about ShareFile Security and Compliance at: https://support.citrix.com/article/CTX208317

Clearly, we want to stop data going to or from adversaries and prevent future attacks. There are a variety of tools depending on the specific attack. It might involve closing ports on the firewall, removing routes, adding authentication, or limiting data travel. HOPZERO offers tools to prevent critical information from leaving the organization, which is a useful tool in many situations.

Hop-based cyber-mitigation reduces the TTL(time-to-live)/hop count of packets to the minimum value required. Doing this gives an enterprise a chance to address gaps in existing tools and move toward a more-holistic approach to network security.

When enterprises decompose applications in their data stores, micro-services, middleware and front-ends, each element provides an opportunity to constrain data-travel and increase security exponentially.

In cases where one or two connections require much-higher hop limits than all other connections, exceptions can be applied to retain a tight perimeter, while carving out a higher limit to specific endpoints.

We recommend customers use TTL values that prevent ANY private information from leaving the data center or enterprise. That way only machines within the company’s control can access protected devices.

We listen to every network session to see where your data is going. We harvest the hop information, in both directions, learning the number of route hops between peered devices. This provides a baseline current behavior.

Session information is enriched with details about endpoints and architectural best practices. This highlights system vulnerabilities and any current attacks.

Then we work with customers to:

• Eliminate sessions that should not be allowed
• Set tight hop limits so data can only travel as far as necessary

Create exceptions for required outliers. This offers better security than relaxing hop limits overall.

The Internet protocol has a hop field (TTL in IPv4 and Hop in IPv6) built into the packet header. Every time a data packet crosses a layer 3 device (router, firewall, VPN), the hop count is decremented. If the count reaches zero, that device throws away the packet and sends an alert back to the packet source. This protocol was developed to guarantee that packets would not spin forever if the network contains a loop.

The best part of hop-based security is ALL layer 3 network devices already support hop limits. Devices do not need to be replaced or upgraded to support HOPsphere Radius Security.

When a hacker attempts to contact a protected device from too far away (may only be 1 or 2 hops away), the packet will reach the device and the device will respond. However, that response packet will have a very low hop limit. The packet will expire/die at a layer 3 device when the hop limit reaches 0. That device sends an ICMP packet back to the source device (attacked machine) saying, “Your packet had to be killed because it ran out of hops.” HOPZERO detects that packet and enriches it to add context such as “A user on device 1.2.3.4 tried to communicate with the finance server from beyond the HOPsphere radius. This appears to be a hacking attempt.”

The hacker has no idea that this alarm has been triggered. They just get a failed connection. The security team gets an incident report with very specific threat details to quickly identify and remove the threat.

Yes, with limits. The same way that a database is configured inside a data center, it’s configured in the cloud. We set the hop limit on instances in AWS, Azure or anywhere else the same way. So, you can virtualize that database that’s got your crown jewel servers on it, only this time you’re putting it out on the Internet, one hop away from your adversary. So, we like to protect the cloud and the premise systems in a similar fashion.

When using cloud services, the service provider would have to set the hop limits. We can set hop limits on virtual machines, like EC2 instances, but cannot set hop limits on S3 containers, Amazon RDS databases, or SalesForce.com servers.

No. Data centers and offices are connected using virtual private networks (VPNs) to prevent observers/intruders from accessing data being transmitted. A characteristic of layer 3 VPNs is the VPN link counts as a single hop, no matter how many physical devices were required to support the VPN. Low hop limits can still allow data to move to another data center or office while preventing traffic from traveling on the Internet.

Hop limits can be set by IP address and protocol/port but are not easily set for geographic location. IP address limits are useful when a critical device needs to communicate with its immediate neighbors and one or two more distant machines. Instead of loosening the overall limits, a tight limit can be applied in general with exceptions for those required, more distant connections.

Protocol and port limits are very useful for many public-facing devices. A web server needs to support global access to HTTPS but should not support external connections to administrative services using SSH or RDP. A default hop limit can keep connections within the enterprise and an override applied to allow HTTPS enough hops to serve the world. Even if the firewall was breached, the only port available to hackers would be HTTPS.

Geographic locations are more difficult because Internet hops depend on provider topology more than distance and geoIP locations are often inaccurate. A distant device close to a backbone can often be closer in hops than a nearby residence.

Yes, see “Can you set hops by location?”

Yes. We leverage virtual network hops to connect offices and data centers by VPN tunnels.

Yes. We account for every IP address we see regardless whether it is a virtual or physical machine and establish appropriate thresholds.

HOPZERO enforces distance between devices. Changing routes either increase distance, decrease distance, or leave distance unchanged. When distance is unchanged, there is no impact. When distance decreases, systems continue to operate normally. If the distance remains shorter, hop limits can be reduced to tighten the security radius.

The primary challenge occurs when a route change increases the number of hops between devices beyond the enforced hop limits. In this case data packets will be discarded, and alerts will be issued to the SIEM. The alert indicates that normal operations involving specific clients and servers are being impacted by hop limits. This enables SOC staff to quickly adjust hop limits to re-establish communication.

Note: Routes often change on the Internet, but inside an organization, and particularly inside of a data center, routes are very stable. New addresses and subnets may be added; however, modifying production networks take a lot more planning and caution.

Yes, see how does HOPZERO handle changing routes.

Network TTL can be set in several ways, such as in the Windows registry, using DHCP (Dynamic Host Configuration Protocol), through Active Directory or by modifying /etc/sysctl.conf (Linux). These provide multiple opportunities to set the desired initial TTL value for each computer.

In cases where the initial TTL cannot be set — some legacy systems or IoT devices — a HOPZERO Modifier Appliance can be used near the device to set TTL as desired.

Yes, but resetting the TTL within the network is more difficult than it sounds. TTL can only be changed by devices that forward network packets, these devices must be inline between the source and destination and within the HOPsphere Radius from the source.

Since the initial TTL is set to keep data within the zone/data center/enterprise, an adversary would have to penetrate the network and compromise an internal layer 3 device, such as a router, without being detected.

HOPZERO highly recommends customers leverage tools to monitor and manage their network infrastructure. Any attempt to modify those settings will trigger an alert that exposes the hacker. In addition, hop management protects router configuration in the same way it protects servers. After all, why should routers support connections from outside the organization?

HOPZERO also monitors TTL on network packets to mitigate the threat of someone altering TTL on an intermediate node. Packets from the protected device can be checked, so TTL matches expected range as set forth by the network security team.

A hacker would have to compromise an internal, inline device, between the monitor and the node where TTL expires. Since monitoring is out-of-band, hackers do NOT know where monitoring occurs. That means a hacker must compromise an unprotected router between an unknown-monitoring point and TTL-expiration point; otherwise, the hacker’s presence would be exposed.

Yes. IoT devices are typically cheap, single-purpose devices. They often blend into the background and fall off security checklists. How often do you check for security patches for your security camera, printer, thermostat, refrigerator, Barbie doll?

These devices may have hard-coded passwords like Sony’s video cameras (https://www.pcworld.com/article/3147311/security/backdoor-accounts-found-in-80-sony-ip-security-camera-models.html) or users may forget to set the password. Many of these devices open network connections to central servers to check for updates, stream audio/video, or allow remote commands. These connections create back doors to the Internet, allowing intruders to bypass edge firewalls.

That may not be a concern with a brand-name SMART home device, such as a Nest or Alexa, but maybe more so with a generic toy bought off the discount rack. If that toymaker goes out of business, anyone can buy the Internet domain to take control of the server side. These back doors can then be used as attack vectors bypassing corporate and consumer firewalls.

Since many IoT devices do not support hop limits directly, we put a network device, a bump in the wire, in the network path. This modifier allows us to adjust hop limits to prevent unwanted Internet access.

We protect data that is sent between company offices, data centers and cloud. In this case the networks are typically linked by VPNs, which we fully support. We also support remote users connected to the office through a VPN.

We are not trying to protect data being sent to/from the Internet in general. Externally-facing web servers and user browsers are not limited since their purpose is to communicate with Internet peers. The number of hops on the Internet depends more on distance from Internet backbones than geographic location.

False positives come from having a hop count that is too low for business operations. There are three sources of these:

1. Limit is set too low for the environment
2. Network topology change
3. Users attempt access beyond the security radius

Since limits are set based on observed traffic, it is important to watch traffic in all expected scenarios before establishing hop limits. This includes monitoring during any failover scenarios such as using backup services in another data center. Given appropriate training scenarios to set limits, case #1 should not occur in production.

Topology changes in production environments are typically rare since they cause other business interruptions. Part of the change plan should include relaxing limits on impacted subnets and rechecking after the change is complete.

The most common cause is user error. An administrator, that is supposed to use a bastion server as a jump box within the production zone, attempts to connect from their desktop and triggers an alert. HOPZERO’s system cannot tell if this user made a mistake or their device is being used as an attack launching point so the SIEM will receive an alert.

One important concept to remember: HOPZERO enriches the alert with information about the threat. Instead of receiving a simple ICMP alert, the SIEM receives a notice indicating which device was attacked, where the attack originated, and whether the attack appears to be a topology change or an attack. If our customer provides the data, the attack can include DNS name, map location, type of machine… In the case of an attack alert, the security team could simply call the owner of the machine to see if they made a mistake. Targeted, actionable information eliminates runaround from any false positives.

No. Hop management, within an enterprise, leverages one of the most stable aspects of a network: the number of layer 3 devices between a pair of endpoints. Looking at a network’s design, it’s often easy to see the number of hops between zones. This is a more effective way of looking at networks, than through IP network subnets.

HOPZERO provides tools to monitor network utilization and recommend hop limits to apply. Laptops and desktops expose hop limit parameters. In cases where devices cannot be set directly, HOPZERO provides a “modifier” inline device to adjust hop limits.

However, there’s one issue we’ve found when using hop limits as a security measure. We’ve talked with teams that use internally-facing firewalls, in “monitor” mode, triggering alerts when unexpected traffic exits the network. The goal, in this approach, is to identify unexpected outbound traffic that could be hackers or exfiltration attempts. There is no similar hop-management approach currently.

Hop limits will block any attempt to exceed limits. HOPZERO does not have a corresponding mode, currently, to watch traffic and alert if traffic goes beyond recommend-hop limits. It is possible to build this capability, if we find a compelling business case to do so.

Yes. Hop-based security has no impact on other security solutions because it works on a different principle. Hop-based security complements traditional firewall-based, IDS and IPS approaches by adding a layer of network security based on hop limits.

Firewalls keep intruders out. HOPZERO keeps data in. Combining these tools provides much-greater protection than either by itself.

A common COMPLAINT from application teams is that “network teams are too busy fighting other fires to address their concerns.” With this approach the application team can add their own layer of security to backstop firewalls, IDS (Intrusion Detection System) solutions, IPS (Intrusion Prevention Systems) solutions, as well as other systems managed by the network security team.

No. Firewalls do not provide the same type of security:

• Firewalls live at the edge of a network, the most vulnerable location for attackers.
• Most companies apply specific rules that usually allow “some” incoming traffic.
• Firewalls normally trust outgoing traffic.
• Firewalls may not be able to limit data travel. The combination of trusting outgoing traffic, and no hop limits, means data can be easily exfiltrated and machines compromised through phishing or virus downloads that can easily open backdoors bypassing the firewall.
• Adding rules adds complexity and opportunities for configuration errors/holes.
• Hop limits are applied at the internal endpoint (server) or near the device, which is the most protected part of the network.

Hops are an alternative way of looking at security. It’s often easier to understand how many routers data can traverse, than to build a list of subnet masks. In our experience, the number of routers between devices is less likely to change than the list of subnets.

Using hops and firewalls achieves protection diversity. A current approach is to compartmentalize the network into layers, with firewalls protecting each zone. One company we met with had deployed seven layers of firewalls but used the same type of firewall in each layer. Instead of seven layers of protection, they had one layer of protection, seven times. A hack that penetrated one firewall could compromise them all. Using multiple firewall types/manufacturers would have made their architecture more solid. Hop-based security would leverage the network zones very effectively.

Yes. Identity and Access Management tools restrict access to applications, machines and data based on user credentials. This is a form of keeping unauthorized people out.

The big IAM concerns are:

• Only authorized people should have access to prevent unauthorized access
• Authorized people must have the required access to prevent lockout
• Credentials must be kept secure

Since hackers can easily steal credentials, through phishing attacks or keyloggers, once on the network, multi-factor authentication attempts to prevent the use of stolen credentials.

HOPsphere Radius Security limits how far network packets can travel. This is independent of the access control, which makes the approaches complementary and extremely powerful.

As an example, IAM authenticates that a user has the correct credentials to access a database. HOPZERO verifies they are connecting from within the controlled radius. If a hacker obtained the administrator’s credentials, but tried to connect from the wrong machine, hop limits would block the connection and trigger a silent alarm telling the security team an attack was attempted and where the attack was sourced. The hacker is exposed without ever obtaining a login prompt, while thinking the database must have been taken offline.

No. Since we are monitoring communication between enterprise systems, the number of hops is very stable. We need to see traffic in various failover scenarios. If a database is used by an app in one data center normally and a backup in another data center, we need to observe operations for both scenarios to set the proper hop limits. If there are special end-of-month or end-of-year operations, we would like to observe those operations before setting hop limits.

Please remember that the worst-case scenario when setting hop limits too low is an alert is sent to the SIEM indicating that a connection was blocked. This alert indicates something like FRED_DESKTOP attempted a connection to FINANCE_SERVER protected by HOP LIMIT=3. Contact “John Doe x1234.” where John Doe is the app owner who can tell if the access should be allowed. This is not a difficult issue to resolve. A simple ping can tell the necessary number of hops to enable the connection.

You can go to our website right now. (http://hopzero.com) We have videos showing you how to download Wireshark, set the snap length, and capture packets, in just a matter of minutes.

Note: The snap length removes any data in network packets, leaving only the routing headers. We only want the metadata in the headers, not the private information in the packet payloads.

When you sign up for a free demo we give you an account on our portal, which uses Citrix ShareFile, trusted by 95% of the Fortune 100 to transfer big files. We have integrated ShareFile with our portal, so that you can capture some network traffic for an hour or so, save, and upload to ShareFile. You can do this sitting at Starbucks, a hotel, public Wi-Fi, or at home. The next thing you know, you have a set of maps showing you where your data is going, and some of the risks associated with going there.

We can also process data extracted packet recorders like NetScout InfiniStreams or NetVCR. With these devices there is no need to wait. They already have several days’ worth of data. Harvest that data, send it to us, and we will show you a map where your data is going.

Hop-based security capabilities are packaged in two ways to address the needs of different audiences. Auditors, security, or QA teams can take a data snapshot and upload for analysis. This is an inexpensive offering that provides an immediate analysis of application behavior. No new equipment is required. A customer creates a span port or extracts packet headers from existing capture devices.

The more advanced monitoring solution is used by the SOC with support from application owners. We believe application owners or business line managers also need to be involved. Attempting to throw applications over the wall to the security team is a major problem. Without application/business knowledge the security team is unable to tell some vulnerabilities from normal operation. We are adding tools to facilitate this collaboration.

This would be one of many tools. In day-to-day operations the main interface would be addressing issues sent to the SIEM. Users would only need to go to the HOPZERO customer portal to gather threat details.

We believe that we’re a bridge between the security SOC and the application teams. Application teams get to see where their data is going and work with the SOC to resolve vulnerabilities. SOC team members can ask if an application is supposed to be working a certain way.

The system is running all the time but should not require constant tuning. We are leveraging the slowest-changing aspect of the enterprise (hops between subnets) to identify intruders and attempted data theft.

Not all steps are automated at this point. Hop limits must be set manually using the Windows registry, Active Directory, Linux configuration or DHCP.

Hop expiration events go to your security SIEM to report connection and exfiltration attempts. Those are security events.