AWS ABCs – Can I Firewall My Compute Instances?

In a previous post, I reviewed what a public subnet and Internet Gateway (IGW) are and that they allowed outbound and inbound connectivity to instances (ie, virtual machines) running in the AWS cloud.

If you’re the least bit security conscious, your reaction might be, “No way! I can’t have my instances sitting right on the Internet without any protection”.

Fear not, reader. This post will explain the mechanisms that the Amazon Virtual Private Cloud (VPC) affords you to protect your instances.

Security Groups

In a nutshell: security groups (SGs) define what traffic is allowed to reach an instance.

“Security group” is a bit of a weird name for what is essentially a firewall that sits in front of an instance, however if you think about it in terms of all servers at a particular tier in an N-tier application (eg, all the web servers) or all the servers that have a common function (eg, all PostgreSQL servers) and how each group would have its own security requirements when it comes to allowed ports, protocols, and IP addresses, then it makes a bit more sense: the security rules appropriate for a group of servers are all put together within the security group construct.

Some more facts about SGs:

  • Each instance you launch must have at least one SG associated with it (the use of SGs is enforced, and that’s a good thing)
  • SGs adopt a default deny policy; you as the admin only define what traffic is allowed
  • You cannot explicitly deny traffic with an SG; you’re only able to create “permit” rules
  • SGs can manage traffic inbound and outbound to/from an instance
  • SGs are stateful; you do not need to write a rule that allows traffic in the opposite direction

An SG operates on traffic as it’s arriving at or leaving an instance. The traffic is evaluated against that instance’s SG or SGs and the resulting action–permit or deny–is taken. Because SGs operate at an instance level, this means they’re not only inspected for traffic between an instance and the Internet, but also between instances as well. SGs can be used to implement a microsegmentation policy where instances in the same VPC and even in the same subnet cannot communicate with each other. For example, you may decide that there’s no reason for the web servers in your web tier to talk with each other.

A very flexible feature of SGs is the ability to reference other SGs in an SG rule. For example, in order to enforce a policy where the PostgreSQL servers only accept connections from the instances in the web tier, it’s possible to write rules that enumerate each web server IP address, however that proves fragile when the web tier scales up or a web instance fails and a new one is launched to replace it. A more flexible approach is to reference the security group that the web servers belong to in the database security group. Any members of the web group will then automatically be permitted to connect to the database; no managing of IP addresses necessary.

AWS VPC security group inheritance

Network Access Control Lists

In a nutshell, Network Access Control Lists (NACLs) are dumb packet filters that operate at the subnet level.

NACLs differ from SGs in three primary ways:

  • They sit at the subnet level, not the instance level
  • They are stateless meaning you do have to write rules that allow traffic in both directions
  • They support “deny” rules

NACLs are great for protecting an entire subnet from certain traffic or certan sources coming in from the Internet or for blocking certain ports/protocols outbound from a subnet. For example if you’ve identified a particular IP address that is hammering your web tier with malicious requests or you know it doesn’t make sense for your web tier to connect outbound on TCP port 22 (SSH), you can enforce either of those policies using an NACL.

AWS VPC Network ACL example

Default NACLs have a “permit all” ruleset for in and outbound traffic. When you modify a default NACL, those “permit all” rules will be removed so remember to add them back as appropriate for your needs. Newly created NACLs have a “deny all” ruleset.

References

Keep in mind that like all things in AWS, SGs and NACLs can be managed via API and/or SDK. When using the CLI SDK, keep these subcommands in mind:

AWS ABCs – EC2 Internet Connectivity

So, you’ve created a compute instance (ie, a virtual machine) on Amazon EC2. Next question: does the instance require access to and/or from the Internet?

Protip: just because you created the instance in the public cloud, i.e. the cloud that you get to over the Internet, it doesn’t mean that your instances all need to sit on the Internet. They can have direct inbound and outbound Internet access, no Internet access, or something in between (which I’ll explain).

The basic building block for networking on AWS is the VPC (Virtual Private Cloud). Within a VPC, you define your IP space, gateways, ACLs, DHCP options, and more. Gateways will be the focus of this article. Continue reading AWS ABCs – EC2 Internet Connectivity

AWS ABCs – Logging Into a New EC2 Instance

Ok, you’ve just launched an Amazon EC2 instance (ie, a virtual machine) and you’re ready to login and get to work. Just once teeeensy problem though… you have no idea how to actually connect to the instance!

This post will walk through how to log into brand new Linux/BSD and Windows instances (the steps are slightly different for different OS families). Continue reading AWS ABCs – Logging Into a New EC2 Instance

Starting a new series: AWS ABCs

I’d be lying if I said that since starting my new job at Amazon Web Services (AWS), I wasn’t looking forward to writing about all the new things I was going to learn. Obviously there’s the technology and services that make up the platform itself. But there’s also the architectural best practices, the design patterns, and  answers to questions like “how does moving to the cloud improve my performance/security/reliability?”

Admittedly, I have a lot to learn. With my background being mostly in the network space for my entire career, stepping out of that and into a software and cloudy world means I’m ramping up on a lot of new skills and knowledge.

I believe I’m not the only one on this journey of learning and that, like me, there a lot of folks who are having to learn the basics of the cloud and specifically, AWS.

This has inspired me to start a new, open-ended series of blog posts that I’ve dubbed AWS ABCs, targeted at people who have a lot of experience designing, operating, and architecting on-premesis systems but are now trying to up-skill by learning how to do the same in the cloud. These posts will focus on basic topics that are relevant to people just getting started on AWS and will provide pointers to resources where they can dive deeper.

You can see the list of posts in this series by clicking on the awsabc tag.

Happy learning!

On Why I’m Shifting my Career Focus to Software

For the past few months I’ve been involved in a case study project with some colleagues at Cisco where we’ve been researching what the most relevant software skills are that Cisco’s pre-sales engineers could benefit from. We’re all freaking experts at Outlook of course (that’s a joke 🤬) but we were interested in the areas of programming, automation, orchestration, databases, analytics, and so on. The end goal of the project was to identify what those relevant skills are, have a plan to identify the current skillset in the field, do that gap analysis and then put forward recommendations on how to close the gap.

This probably sounds really boring and dry, and I don’t blame you for thinking that, but I actually chose this case study topic from a list of 8 or so. My motivation was largely selfish: I wanted to see first-hand the outcome of this project because I wanted to know how best to align my own training, study, and career in the software arena. I already believed that to stay relevant as my career moves along that software skills would be essential. It was just a question of what type of skills and in which specific areas.

Continue reading On Why I’m Shifting my Career Focus to Software

The Anatomy of a Cisco Spark Bot

I spent a long time creating my first Spark bot, Zpark. The first commit was in August and the first release was posted in January. So, six months elapsed time. It’s also over-engineered. I mean, all it does is post messages back and forth between a back-end system and some Spark spaces and I ended up with something so complex that I had to draw a damn block diagram in the user guide to give people a fighting chance at comprehending how it works.

Its internals could’ve been much simpler. But that was part of the point of creating the bot: examining the proper architecture for a scalable application, learning about new technologies for building my own API, learning about message brokers, pulling my hair out over git’s eccentricities and ultimately, having enough material to write this blog post.

In this post I’m going to break down the different functional components of Zpark, discuss what each does, and why–or not–that component is necessary. If I can achieve one goal, it will be to retire to a tropical island ASAP. If I can achieve a second goal, it will be to give aspiring bot creaters (like yourself, presumably) a strong mental model of a Spark bot to aid their development.

Continue reading The Anatomy of a Cisco Spark Bot

Explain Cisco ETA to Me in a Way That Even My Neighbor Can Understand It

Cisco Encrypted Traffic Analytics (ETA) sounds just a little bit like magic the first time you hear about it. Cisco is basically proposing that when you turn on ETA, your network can (magically!) detect malicious traffic (ie, malware, trojans, ransomware, etc) inside encrypted flows. Further, Cisco proposes that ETA can differentiate legitimate encrypted traffic from malicious encrypted traffic.

Uhmm, how?

The immediate mental model that springs to mind is that of a web proxy that intercepts HTTP traffic. In order to intercept TLS-encrypted HTTPS traffic, there’s a complicated dance that has to happen around building a Certificate Authority, distributing the CA’s public certificate to every device that will connect through the proxy and then actually configuring the endpoints and/or network to push the HTTPS traffic to the proxy. This is often referred to as “man-in-the-middle” (MiTM) because the proxy actually breaks into the encrypted session between the client and the server. In the end, the proxy has access to the clear-text communication.

Is ETA using a similar method and breaking into the encrypted session?

In this article, I’m going to use an analogy to describe how ETA does what it does. Afterwards, you should feel more comfortable about how ETA works and not be worried about any magic taking place in your network. 🧙

Continue reading Explain Cisco ETA to Me in a Way That Even My Neighbor Can Understand It

Say Hello to Zpark, my Cisco Spark Bot

For a long while now I’ve been brainstorming how I could leverage the API that’s present in the Cisco Spark collaboration platform to create a bot. There are lots of goofy and fun examples of bots (ie, Gifbot) that I might be able to draw inspiration from, but I wanted to create something that would provide high value to myself and anyone else that choose to download and use it. The idea finally hit me after I started using Zabbix for system monitoring. Since Zabbix also has a feature-rich API, all the pieces were in place to create a bot that would act as a bit of middle-ware between Zabbix and Spark. I call the bot: Zpark.

Continue reading Say Hello to Zpark, my Cisco Spark Bot

2017 End of Year Blog Statistics

Didn’t I just write the 2016 statistics post like…. last week? Another year has flown by and with it another year of attempting to prioritize my writing. I’ll be honest, I’m not optimistic about what I’m going to find when I compare 2017 to 2016. It was a year filled with a lot of change and opportunity so I’ll use that as my excuse as to why I didn’t write as much or as often as I had planned.

I was thinking though: every year I set a goal of writing more posts than the previous year, but that’s only 1 metric to go by. Most of my posts are very detailed and fleshed out. It’s nothing to write a post that’s 1000 words. I regularly eclipse 2000 words and have even hit 3000 words. Perhaps I should be thinking more about word count and not post count? Certainly a 2000 word post takes more effort than a 1000 word post. On the other hand, word count says nothing about quality and could easily lead to excessive wordiness and run-on posts just to tilt the metrics.

Enough musing. Let’s review the data! Continue reading 2017 End of Year Blog Statistics

Networking. Unix. Cloud. Cyber Security. Code. Protocols. System Architecture.