Ivan Pepelnjak

Author Archives: Ivan Pepelnjak

Considerations for Host-based Firewalls (Part 1)

This is a guest blog post by Matthias Luft, Principal Platform Security Engineer @ Salesforce, and a regular ipSpace.net guest speaker.

Having spent my career in various roles in IT security, Ivan and I always bounced thoughts on the overlap between networking and security (and, more recently, Cloud/Container) around. One of the hot challenges on that boundary that regularly comes up in network/security discussions is the topic of this blog post: microsegmentation and host-based firewalls (HBFs).

Example: Securing AWS Deployment

Nadeem Lughmani created an excellent solution for the securing your cloud deployment hands-on exercise in our public cloud online course. His Terraform-based solution includes:

  • Security groups to restrict access to web server and SSH bastion host;
  • An IAM policy and associated user that has read-only access to EC2 and VPC resources (used for monitoring)
  • An IAM policy that has full access to as single S3 bucket (used to modify static content hosted on S3)
  • An IAM role for AWS CloudWatch logs
  • Logging SSH events from the SSH bastion host into CloudWatch logs.

Docker Services 101

Last week I published an overview of how complex (networking-wise) Docker Swarm services can get. This time let’s focus on something that should have been way simpler: running container-based services on a single Linux host.

In the first part of this article I’m focusing on the basics, including exposed ports, and published ports. The behind-the-scenes details are coming in a week or so; in the meantime you can enjoy (most of them) in the Docker Networking Deep Dive webinar.

Review Questions: Switching, Bridging and Routing

One of the most annoying part in every training content development project was the ubiquitous question somewhere at the end of the process: “and now we’d need a few review questions”. I’m positive anyone ever involved in a similar project can feel the pain that question causes…

Writing good review questions requires a particularly devious state of mind, sometimes combined with “I would really like to get the answer to this one” (obviously you’d mark such questions as “needs further research”, and if you’re Donald Knuth the question would be “prove that P != NP").

Docker Swarm Services behind the Scenes

Remember the claim that networking is becoming obsolete and that everyone else will simply bypass the networking teams (source)?

Good news for you – there are many fast growing overlay solutions that are adopted by apps and security teams and bypass the networking teams altogether.

That sounds awesome in a VC pitch deck. Let’s see how well that concept works out in reality using Docker Swarm as an example (Kubernetes is probably even worse).

MUST READ: What I’ve learned about scaling OSPF in Datacenters

Justin Pietsch published a fantastic recap of his experience running OSPF in AWS infrastructure. You MUST read what he wrote, here’s the TL&DR summary:

  • Contrary to popular myths, OSPF works well on very large leaf-and-spine networks.
  • OSPF nuances are really hard to grasp intuitively, and the only way to know what will happen is to run tests with the same codebase you plan to use in production environment.

Dinesh Dutt made similar claims on one of our podcasts, and I wrote numerous blog posts on the same topic. Not that anyone would care or listen, it’s so much better to watch vendor slide decks full of latest unicorn dust… but in the end, it’s usually not the protocol that’s broken, but the network design.

Which Public Cloud Should I Master First?

I got a question along these lines from a friend of mine:

Google recently announced a huge data center build in country to open new GCP regions. Does that mean I should invest into mastering GCP or should I focus on some other public cloud platform?

As always, the right answer is “it depends”, for example:

Worth Reading: Seamless Suffering

When someone sent me a presentation on seamless MPLS a long while ago my head (almost) exploded just by looking at the diagrams… or in the immortal words of @amyengineer:

“If it requires a very solid CCIE on an obscure protocol mix at 4am, it is a bad design” - Peter Welcher, genius crafter of networks, granter of sage advice.

Turns out I was not that far off… Dmytro Shypovalov documented the underlying complexity and a few things that can go wrong in Seamless Suffering.

MUST READ: IPv4, IPv6, and a Sudden Change in Attitude

Avery Pennarun continued his if only IPv6 would be less academic saga with a must-read IPv4, IPv6, and a sudden change in attitude article in which he (among other things) correctly identified IPv6 as a typical example of second-system effect:

If we were feeling snarky, we could perhaps describe IPv6 as “the String Theory of networking”: a decades-long boondoggle that attracts True Believers, gets you flamed intensely if you question the doctrine, and which is notable mainly for how much progress it has held back.

In the end, his conclusion matches what I said a decade ago: if only the designers of the original Internet wouldn’t be too stubborn to admit a networking stack needs a session layer. For more details, watch The Importance of Network Layers part of Networks Really Work webinar

OMG, Not Again: New Mobile Internet Protocol Vulnerabilities

Every now and then a security researcher “discovers” a tunneling protocol designed to be used over a protected transport core and “declares it vulnerable” assuming the attacker can connect to that transport network… even though the protocol was purposefully designed that way, and everyone with a bit of clue knew the whole story years ago (and/or it’s even documented in the RFC).

It was MPLS decades ago, then VXLAN a few years ago, and now someone “found” a “high-impact vulnerability” in GPRS Tunnel Protocol. Recommended countermeasures: whitelist-based IP filtering. Yeah, it’s amazing what a wonderful new tool they found.

Unfortunately (for the rest of us), common sense never generated headlines on Hacker News (or anywhere else).