Much concern and effort today revolves around protecting networks from the the awesome power of a large scale DDoS attack like Mirai. While the spreading of bots can be done in many forms, a good majority are spread by a simple scan to a network range, a response, then a password attempt. This is true for WAN’s and LAN’s and gets to the core of the effectiveness of Mirai. Mirai was so simple and brilliant, the best protected network systems were caught with their pants down.
A simple Google search on “Protecting Yourself Against Bots” turns up many of the expected recommendations:
- Always use a comprehensive security solution.
- Keep your software up to date. Always update your devices.
- Watch where you browse
- Install a firewall
- Use good passwords
- Follow good security practices
Too frequently these common-sense recommendations do not become common practice. Training is important and good practice, but we are a little out of touch if we think these acts will actually solve the problem. Many of these recommendations are from the perspective of a workstation, mobile device, or server and fall on deaf ears of users of IoT devices.
For example imagine your office installs new smart monitors, thermostats, light switches, etc. You successfully install and update them. Several months later a new security warning is put out. The users maybe...at best, update their mobile device and desktops. Good hygiene generally stops there. Why? Most likely because the other devices are working as expected & no second thought is given to those devices. Now your defense posture is compromised because compliance with best practices is lacking. Your devices that are 'working fine' are available to join a botnet.
DDoS is too frequently instantly associated with flooding traffic that destroys services and makes them unavailable. While this is the end result, the beginning of a DDoS attack has everything to do with penetrating, this is what we like to call the infection point. This is when the malware is on the prowl for candidates for the botnet and those other IoT devices that are 'working fine' present optimal targets. Remember a single bot is useless on its own. It only becomes weaponized when they turn into hundreds and thousands and with the surge of IoT devices out there not being properly maintained, there is no shortage of botnet candidates.
Many security vendors claim they have the pulse on bots, but we have to remember “they only know what they know”. Meaning, when any new threats show up, they are just catching up like everyone else. This includes things like OpenDNS, which was not useful against Mirai because the vector was IP based scanning and did not need resolution. Now remember what I mentioned earlier about people slacking off on updating their devices that are 'working fine' and they may get updated eventually, but typically its a few months past when the update really should have happened. This means the hackers have a window of opportunity of roughly 2-3 months to infect IoT devices and recruit them into the botnet. This window of weakness resulting from poor administration from IoT devices allows bot infections to flourish and eventually reap havoc on society.
Today's bot monitoring vendors do have significant data and pattern matching capabilities. But much of this data is from older, dated bots and this is a problem given the rate at which new bots and malware are arriving on the scene. By way of comparison, vaccines are typically developed based on known diseases and work well against those diseases. However, when diseases mutate and new strains come out that are resistant to the vaccines, even the vaccinated are exposed and the race is on to find a new cure. What seemed like a sound proactive approach to personal health suddenly begets a reactive strategy. The key is that a defensive posture based on what is known is only reliable assuming things don't change, which is the hardly the case with cyber threats.
No one, including companies with the latest and greatest cybersecurity tools, understood what Mirai was until it was too late. The Mirai infection reached all four corners of the world, as depicted on the map from Incapsula (below). Eventually Krebs “stumbled” over a message in some hacker forum which resulted in the discovery. Hence, it's safe to assume this bot had time to grow and expand freely for some time. Let's stop and think about this...before October no one had any idea this was happening, and today you can’t stop hearing about this. In fact if you do a search you will find very little historical information on the Mirai threat and the Wiki article was only started in October 2016.
Afterwards DDay +1 everyone is falling over each other to describe the bot and pontificate about solutions. Here are some of my favorites:
- “The solution to this is simple. Manufacturers must do a better job of either ensuring that each device has a unique default password, or they must force users to change the password once the default is entered, when the device is first installed,” he argued.
- "This would go a long way to solving that problem if every device shipped with a different combination of login credentials.”
- “For those manufacturing devices they should consider things like a data-centric security approach that helps prevent data leakage and access”
- “Innovative technologies such as industry-standard format-preserving encryption can protect data, at the data level, in the IoT mobile applications, in connected devices and in the enterprise back-end system.”
My personal favorite:
- “If all it took to create biggest recorded DDoS attack in history was a telnet scanner and 36 weak credentials the net has a huge IoT problem
With everyone pointing fingers accusingly at the IoT device manufacturers, I could not find too many people saying “Maybe I should have stopped this on the firewall before they even got to the user credentials and not provide an opportunity for infection”. Instead, people get these devices and just follow the installation instructions that tell you to create firewall rules. Frequently we find something is wrong and nothing is working right - so in the efforts to save time we create a one to one NAT. This seemingly solves the problem of the moment on the device, and people move on, oblivious to the risk they have exposed themselves to.
This process I just described happens over and over again around the world, every day, providing plenty of opportunities for bots to flourish. And we know they are out there because on a daily basis PacketViper sensors around the world trap and detect thousands of login attempts per day, along with probes testing vulnerabilities. So of course one must conclude that with such a target rich environment, the undiscovered bots out there are having a feeding frenzy. So what is one to do?
PacketViper Virtual Minefields: Proactive Defense
We've hopefully made it clear that, given the rapidly changing threat landscape, a reactive cyber-defense plan overly reliant on known threats and basic recommendations is ultimately a plan to fail. PacketViper has tools and techniques that strengthen defense against the currently unknown, but lurking, cyber threats. PacketViper does this by creating a virtual minefield of traps and sensors which enact harsh penalties onto the offending source address. Now you are probably thinking 'how is the different than a firewall'?
Many firewalls, and next generation firewalls will simply drop the request, but will allow the source to continue scanning. Remember, the firewall is reviewing the signature, reputation and behavior of the connection request. This level of protection still creates vulnerability because one must expose network ports to the world at large, inspect everything and create firewall rules dependent on what is known. By contrast PacketViper is NOT restricted by only what is known. Our filtering logic is tailored to the needs of the business based on the full context of the IP, inbound and outbound. This means PacketViper remains valuable even in the face of new (unknown) malware strains because PacketViper blocks access and stops probing based on our proprietary technology in a way that firewalls simply cannot. Attempts to do what PacketViper does in a firewall (i.e. shunning) results in latency and risk of degrading performance based on the overwhelming complexity, administration time and amount of rules that would be required to even attempt it.
PacketViper Virtual Minefields make probing treacherous and costly for the attacker. It exposes previously unidentified infected sources, thereby protecting any unrealized exposures. For more see our graphic depiction below or contact us directly here: Contact Us