Containers and Virtual Machines – How are they different?

By | Cloud, DevOps | No Comments


If a person has been in any technical industry for the last decade they have likely heard of this concept. Multiple software solutions and vendors have their own take on the idea. Names like Docker and Kubernetes have become increasingly well-known throughout the technology world. However, there is often a question that occurs when there are discussions about containers: How are they different from a virtual machine (VM)?

The main difference between a VM and a container is what they are trying to accomplish. A VM will create a software implementation of a computer with its own virtualized hardware and operating system. This is useful is when multiple operating systems need to run on a single machine, or a cloud provider wishes to offer a customer the capability to rent server space. A container will bundle all the necessary dependencies required to run an application and run them on top of an already existing operating system and hardware. This allows for the quick development and deployment of new software and reduces the overhead of managing multiple operating systems.


Securing Your Web Server

By | Cloud, Security | No Comments

Whether you are running a personal website dedicated to pictures of cats or a multi-million-dollar online marketplace, securing your server from hackers remains difficult. Fortunately, there are some common practices that can reduce risk. 3 key practices are listed below:

  1. Restrict access to ports via a firewall. Servers are often misconfigured to allow services to be accessed on the network, but this is bad security practice since it provides bad actors with more points of entry. For SSH access to your server, consider using whitelist rules to prevent clients scanning the server from accessing this service.
  2. Encrypt traffic using SSL/TLS, redirecting all normal HTTP traffic to HTTPS (port 443). This will help prevent data loss via man-in-the-middle attacks.
  3. Keep server software up to date. New software versions often patch against vulnerabilities, so it is important to audit web server software from time to time to ensure the latest patches are installed.


2019 Capital One Breach: A Lesson Offered

By | Cloud, DevOps, Security | No Comments

The Capital One breach wasn’t done through the too-common open or purely misconfigured S3 bucket. It was a hack that serves as a lesson to anyone who deploys production web apps in the cloud. The hacker exploited a Server-Side Request Forgery Request vulnerability in a Web Application Firewall that targeted a tool that AWS itself provides to its EC2 instances. This tool is called the Instance Metadata service, and it allows an EC2 instance to make an HTTP GET request to the link-local IP to retrieve its own metadata. This metadata can include its own AWS security credentials to gain access to other resources in the victim’s AWS infrastructure.

This is a lesson to anyone who deploys applications on cloud platforms such as AWS. The lesson is that it pays to have more than the minimum-to-deployment knowledge of your cloud provider’s architecture and tools. It’s possible for a team to bring an application all the way to production on EC2 machines in AWS without ever knowing its Metadata service exists. Greater knowledge of your particular cloud provider can help you to consider the extra attack vectors that it may introduce.