Hacker News new | ask | show | jobs
by rewmie 1004 days ago
> These provide a strong lock-in effect when customers spend effort to build the complex infrastructure for them in the name of security, even though in reality they hurt security through unnecessary complexity, addressing ambiguity, etc.

How do you hurt security by preventing external access to your internal services?

2 comments

Was this a jeopardy style reply?

In case not: it's about doing it the wrong way (excess complexity and ambiguity -> hard to understand/analyze/monitor). Using globally addressing is orthogonal to controlling access to your internal services - you can do it using firewalling or various other means. Eg on AWS you get a default-deny firewall.

By making it necessary to use automated tooling and even obtain certifications just to set up everything required for private networking. The complexity of a properly configured service mesh in AWS is staggering, extremely hard for newbies to get right, and easy to fuck up big time down the road. That hurts security.
> By making it necessary to use automated tooling

It isn't.

> and even obtain certifications

No, not really.

> just to set up everything required for private networking.

Frankly, no.

I'm tempted to agree only in one aspect, which is apparently you are completely unfamiliar with the topic, and the degree of confusion you are showing in your comments suggest you would benefit from an introductory course on the topic, or in the very lease a 5-minute read through the service's documentation.

Certification wold only help because you would need to learn the basics to pass those, and learning the basics would be enough to prevent you to fill in the gaps in your understanding with fabricated nonsense.

> The complexity of a properly configured service mesh in AWS is staggering, extremely hard for newbies to get right, and easy to fuck up big time down the road. That hurts security.

People being way over their head because they can't even grasp a FAQ will definitely hurt security, but the root cause of this failure mode is sheer incompetence.

As the saying goes, poor craftsman blame their tools, and here you are with a tool-blaming fest.

Are hundreds of publicly addressable services better?
Yes, because publicly addressable does not mean publicly accessible. Set the ACLs to deny by default.

In the v4 world, one can easily accidentally allow access by inadvertently sending traffic toward the wrong group of colliding addresses or otherwise messing up any of a number of things that ought not to be necessary in the first place.

You need both firewalls and private addresses, of course.

Anything else is amateur hour madness.

Why do I need private addresses?

Okay, in real life I need private addresses because I connect to things that are only available over IPv4. So there’s some negotiation to make sure that my private network does not have an addressing conflict with the other network, there are NATs in the way, and traceroute gives output that is every bit as bad as you would expect. The ACLs that everyone (arguably quite reasonably) sets up suck are fiddly because the clients don’t have well defined address ranges. When people allocate /24 subsets out of IPv4 private space, the probability of collision is annoyingly high. Amateur hour indeed.

I would take globally unique but “private” IPv6 addresses, over private links, with private routes (dynamic or static), and ACLs that actually make sense any day. Heck, I would happily go IPv6 only!

> private addresses

Private addresses offer no security benefit whatsoever. If you have no firewall, nothing at all prevents me from doing `ip route add 10.0.0.0/8 your.routers.ip.here`

Nothing prevents you from doing that, but your martian packets have zero chance of reaching my router.
You don't need private addresses. You may need non-routable addresses, but they do not need to come from a "private" network range.
A distinction without a difference. Private addresses are those that aren't globally routable by definition.