The server is running fine. The cameras are streaming video, nobody has complained about the network, and the equipment hasn’t needed much attention lately. Why change anything?
The trouble is, a device can work perfectly well and still have a serious security flaw. Sometimes these problems stay unnoticed for years. The owner sees a system doing its job. Someone scanning the internet might see an opportunity to get inside.
In October 2026, GreyNoise reported a sharp increase in attempts to attack Hikvision equipment in Ukraine. The attackers weren’t exploiting some newly discovered bug. They were going after a flaw first found in 2021. That’s several years for a known vulnerability to remain a problem, and there’s no reason to think cameras are the only devices affected by this sort of thing.
Why Old Vulnerabilities Are Still Dangerous
GreyNoise recorded the suspicious activity between September 21 and October 1, 2026. The busiest period started on September 23 and lasted nine days. Almost all the attempts came from just four IP addresses.
Three of them, 195.238.124.178, 195.238.124.181 and 195.238.124.188, were PureVPN exit nodes located in Lithuania. The fourth address belonged to a Ukrainian network. GreyNoise didn’t publish it, as the connection between that source and the other three was uncertain. The activity stopped after October 1, and no further attempts from those addresses had been recorded as of October 7.
The vulnerability itself is known as CVE-2021-36260. It affects the web server in certain Hikvision devices. There’s a problem with how the software checks incoming data, and a specially crafted request can make an affected device run commands it wasn’t meant to run. The attacker doesn’t have to know the administrator password. They don’t even need to log in.
NIST gave the flaw a score of 9.8 out of 10 under CVSS 3.1. That’s a critical rating. CISA had already added it to the Known Exploited Vulnerabilities catalog on January 10, 2022, recommending that the manufacturer’s security fixes be installed.
The tools used in the attacks weren’t particularly unusual either. The attackers relied on an existing Nuclei template from ProjectDiscovery, designed to check whether remote command execution was possible.
There is one important distinction, though. GreyNoise found test commands in the requests, not attempts to install malware. The researchers were seeing attempts to exploit the vulnerability, but that doesn’t prove the cameras had actually been taken over.
The same kind of problem can occur with a router, a NAS, or a server management panel. Everything continues working, the software version doesn’t change, and an old security issue remains there until someone decides to test it.
How Attackers Find Exposed Servers and Devices
An attacker doesn’t need to know your company name or where your office is. Most of the initial searching can be done automatically.
Scanning tools check ranges of IP addresses, looking for open ports and services that respond to connections. Sometimes the response is enough to identify the software running on a device. From there, it’s possible to check whether that version has a known vulnerability.
Imagine a company server with RDP enabled. A few years ago, an administrator needed remote access and opened the port to the internet. It was convenient, nobody had any trouble connecting, and the setting was left as it was.
The server may still be working without a single complaint. But that RDP port is visible to anyone who scans the address.
Of course, not every open port is a security problem. A web server needs to accept HTTP and HTTPS connections. Otherwise, the website wouldn’t be accessible.
SSH, RDP, control panels and network equipment management interfaces are different. They’re intended for administrators, not everyone on the internet. When these services are publicly available, attackers have another place to look for weaknesses.
A strong password helps against some attacks, but not all of them. If a vulnerability allows someone to run commands without authentication, the password might never come into play.
This is why checking which services are exposed matters. Sometimes a port is still open simply because nobody remembers why it was opened in the first place.
How to Restrict Access to Servers Over the Internet
For most administration services, there’s little reason to allow connections from every IP address. If SSH is only used by a couple of administrators, access can be limited to the addresses they work from.
A firewall handles this by filtering connections according to the rules you set. The same approach works for RDP and other services that don’t need to be publicly accessible.
Things are less straightforward when administrators work remotely or change locations frequently. Their IP addresses may not stay the same. In that case, using a VPN is often more practical.
Instead of connecting directly to a server’s administration port, the administrator first joins a private network. From there, they can reach the internal services they need. Those services don’t have to be exposed to the public internet.
Servers hosting websites or customer applications need a similar separation. Visitors should be able to reach the website, but they have no reason to connect directly to its database or the server’s control panel.
IPv6 can cause problems if it’s overlooked. Sometimes IPv4 firewall rules are configured properly while the same services remain reachable over IPv6. If both protocols are enabled, both need their own checks.
Why Network Equipment Should Be Separated from Main Servers
A small office network often grows without much planning. First there’s a router and a few computers. Later someone installs cameras, adds a NAS, perhaps connects a server. Everything ends up on the same local network because that’s the easiest way to get it working.
This arrangement may run for years without causing any obvious issues. The downside becomes clear when one of the devices is compromised.
Suppose an attacker manages to gain access to a camera running vulnerable firmware. That alone doesn’t give them control of the server. But if both devices share a network with no restrictions between them, the attacker may be able to use the camera to look for other vulnerable systems.
Separating the network into segments makes that harder.
For example, cameras can be placed in one VLAN, servers in another, and employee computers in a third. Connections between those segments should then be limited to what’s actually required.
One detail is easy to miss here. Creating separate VLANs doesn’t automatically mean the traffic between them is properly restricted. Firewall rules are still needed to control which devices can communicate.
Even in a small office, keeping cameras, guest Wi-Fi and servers apart can make a difference. The aim isn’t to build a complicated network. It’s to prevent a problem with one device from spreading to systems that have nothing to do with it.
How Updates and Monitoring Help Prevent Attacks
Anyone looking after a production server knows why updates sometimes get delayed. The system is working, customers are using it, and nobody wants an unexpected outage because a patch caused compatibility problems.
So the update is left for later. Then something more urgent comes up. A few months pass, and the old software is still running.
The risk doesn’t disappear during that time. Once information about a vulnerability becomes public, tools for checking affected systems may appear fairly quickly. Some of those tools can later be used to find targets automatically.
Updates need a bit of planning, especially on systems that can’t simply be switched off. Before making changes, save the configuration, check whether the new version is compatible and arrange the work for a quieter period. Critical servers also need a way to recover if the update doesn’t go as expected.
Monitoring helps with another part of the problem: noticing when something unusual is happening.
A server with SSH exposed to the internet may record failed login attempts every day. That alone isn’t particularly surprising. Automated scanners are constantly checking public IP addresses.
But an unfamiliar account, changes to the server configuration, or outbound connections nobody can explain deserve closer attention.
System logs can help trace these events. For important servers, monitoring tools can also send alerts instead of leaving someone to search through thousands of log entries manually.
Older equipment is harder to deal with. If the manufacturer has stopped providing security updates, there may be no patch to install. When replacing the device isn’t possible right away, limiting its network access is often the most useful temporary measure.
What to Consider When Hosting Servers in a Data Center
Moving servers into a data center solves several practical problems. Power, cooling and physical conditions are handled in an environment built for running equipment continuously.
Software security is a separate matter.
If a server hasn’t received operating system updates for years, moving it to a data center won’t fix that. The same goes for management ports that are accessible from anywhere on the internet.
Still, a data center can provide the foundation for a better network setup. Depending on the services and equipment involved, it’s possible to use separate network segments, restrict administrative access and control traffic between systems.
At Server.UA, companies can colocate their own equipment or rent dedicated servers. Before putting that equipment into operation, it’s useful to decide who will be responsible for operating system updates, firewall settings and access permissions.
The Hikvision case is a fairly clear example of a problem that can sit unnoticed for years. The vulnerability was already known, yet attackers were still looking for affected devices in 2026.
There’s no need to wait for something similar to happen to your own infrastructure. Start by checking which servers and network devices are reachable from the internet. Look at the ports that are open and the software running behind them. Some of those services may have been exposed years ago and simply never reviewed again.