Distributed Denial of Service attacks are nothing new, but they’re becoming more and more common, from politically motivated attacks on financial and government institutions to recent attacks on data centers like Digital Ocean. DDoS attacks are when hackers use hijacked computers to flood servers with incoming requests and essentially shut down services by clogging network traffic or sending mass quantities of junk data. They are increasingly difficult to defend against as they grow in scale, and because they are distributed among various infected machines, it can be difficult to block traffic based on IP address.
Public institutions, financial industries, eCommerce sites, and hosting providers are among the most popular targets, but anyone can be a victim—and if your IT infrastructure is hosted in a data center, you need that facility to provide strong DDoS mitigation to avoid service interruptions of your own.
Read on to learn common DDoS attack methods and mitigation strategies.
One of the most commonly cited obstacles to cloud adoption is security, which itself is an extension of the perceived loss of control over the infrastructure running your applications and storing your data. On the whole, cloud infrastructure is actually more secure than in-house data centers, as providers have dedicated staff, software, and hardware protections in place at a greater level than the majority of on-site facilities.
These protections take the form of many layers of physical security, best practices and documented plans for security responses, industry-leading firewalls, antivirus, antimalware, and monitoring software, and strict access control for users and administrators. But the malleability of the cloud, plus its many forms and applications, means that it is not always clear who should be in charge of securing a cloud deployment.
Do users or cloud providers need to be in charge of security? The answer depends on which part of the cloud stack you’re looking at.
In the IT world, if it isn’t logged or documented, it might as well never have happened. Without properly keeping track of change management, even for routine processes, it can be impossible to discover why a system stopped working, or worse. Technicians might be stuck halfway through a switch upgrade, unable to retrace their steps when they realize the equipment install won’t work. Or an entire organization could be held accountable under the law because they failed in their compliance.
IT documentation, in other words, is an essential if occasionally painstaking piece of data center operations. At Green House Data, we document everything we possibly can. Outside of support or internal emergency responses, which are always tracked in a ticket, planned changes must undergo a five-step process in order to keep track and learn from the change.
Green House Data is making the rounds this spring, attending several industry conferences and hosting events in cities across the country. If you're attending Data Center World or Channel Partners Conference swing by our booth and say hello! We'll also have representatives at the Greater New York Data Center Summit and Datacenter Dynamics Converged.
Green House Data is hosting upcoming Lunch and Learns and Happy Hours in Seattle, Bellevue, and New York. Don't miss CEO Shawn Mills, who is speaking at several events as well.
Find booth numbers, dates, details, and registration links after the jump.
HTTPS is supposed to be secure, right? Of course, nothing on the internet is ever truly safe. This week, a new vulnerability in OpenSSL was uncovered, allowing hackers to access websites secured with SSLv2. Although this security protocol is out of date, over 11 million websites—1/3 of all HTTPS secured servers—are at risk.
Plenty of websites that store sensitive information like credit card details are vulnerable to DROWN, which is an acronym for Decrypting RSA with Obsolete and Weakened eNcryption. Websites can be hacked in just minutes using this attack vector.
Learn how to check your site for DROWN vulnerability and what you should use to replace SSLv2 after the jump.