As part of my continuous effort to keep on top of cybersecurity, I was watching a CEH video yesterday which overviewed the various ways in which hackers search for vulnerabilities. It all came down to the same end result – port scanning. I then read this morning about yet another Mirai variant (you know that IoT bot that almost crashed the entire Internet) and, yet again, it all starts with scanning. Can it really be so simple to stop all of these attacks? To be clear, scanning is not just looking for open ports, scanning goes beyond just the ports and into what lays behind the responses – what hosts are running, how things are configured at the lowest levels, and so forth. That stated the first step in ALL of these vulnerability scans is to find and either enter or listen to active/inactive ports. Stop that step and the rest becomes obsolete.
Sounds great, right? “Simply” change port defense technology (more commonly referred to as firewalls) and we are done! Not so fast. The main issue is that firewalls are not currently made to do anything more than open and close ports. In order to overcome these scans, we need to introduce two more types of ports to the mix: Redirect and Obfuscate. Redirect ports would be logical ports that take any incoming requests targeting an inactive port and redirect that traffic somewhere else. Now this redirection has to occur below the TCP level (the layer that performs handshakes) in order to avoid detection. That traffic can be redirected to a honeypot, dark net or, really, anywhere an admin wants. The point is that, during a scan, a would-be attacker gets some level of response back that makes no sense or that indicates the presence of software that does not exist. So much for finding easy points of entry through a backdoor. That stated, there is still the issue of active traffic and looking at the ports used and types of traffic flowing through a device often lead to significant insights into the internals of a given target. To counter these issues, the Obfuscation port can be used. This port can work in two modes – P2P and Port Routing. Peer-to-peer (P2P) mode would work when two such firewalls are directly communicating with one another. In these cases, policies on both sides can transform one type of traffic (say email/SMTP) into another type of traffic (say FTP) during transit and then change it back. This communication protocol wrapping can extend across any type of communication and, since both sides are running policies, the rules can be dynamic and change by time of day, amount of traffic or randomly. The Port Routing mode, which can work in conjunction with the P2P mode, would operate in a similar way to how traditional routing tables work. In this case, outbound traffic flowing over a well-known port (e.g. 1723 for VPN connections) can be routed over another random port to make it more difficult to pattern application activity. These port mappings would remain internal to the firewall and thus neither the application nor the external targets would have any idea that the port routing exists. In fact, taking things further in relation to golden images (e.g., the supposedly thoroughly-tested images admins deploy enterprise-wide), applications can be directly tied to the firewall to lockdown both external and internal communications. Of course, this latter part requires an Ethernet-based admin tool…and that is the topic for another post!