Hacker Newsnew | past | comments | ask | show | jobs | submit | vlan0's commentslogin

And if I think back to my 30 years of IT, environments with NAT end up with lazy engineering from systems and application folks. It doesn't provide an environment that forces folks to understand their problems holistically. Thus, relying on perimeter firewalling and NAT as a large catch all. It's a bad security practice imo

The correct way is hard. You either have to manage firewalls on each host, or your switches need to have firewalls (I assume that’s a thing?). Hosts on the same subnet never hit layer 3 so IP-based firewalls don’t see them.

You either need very static infrastructure so you can hard-code firewalls on the hosts, or you need a system to dynamically manage the firewalls on each host, or an SDN that can sanely manage layer 2 flows. Little things like moving an app to a new server become a whole project unless you have really good tools to reconfigure the firewalls on everything that touches the app.

Then you need a way to let people self-service those rules or else security has to be involved in like everything just to do firewall rules.

It’s a good idea, but a huge pain and I’ve not seen good solutions


That's why I like mesh overlay networks (things like Tailscale, Nebula, etc.). You can largely set host firewalls to deny all, and access services over the overlay network which is software defined and more easily managed and deployed at scale.

It doesn't solve all problems, but its a good start, and modern MDMs & Group Policy (on the Windows side) make managing host firewalls easy enough.

It doesn't solve your self-service problem, though I'd argue self-service when it comes to host firewalls or otherwise shouldn't be a thing anyway.


Yep, rfc19188 addressing leads to accumulating complexity due to workarounds (end-to-end addressing is simple, there are very good reasons for that design), addressing ambiguity, and various practical security problems.

Do you prefer to install firewalls on smart light switches and kettles?

It's always important to remind one's self that "who you are" is simply the story one is attached to. Things like meditation or psilocybin can help bring that to light.

Can be said about so many things in life. It's almost like we don't learn and just repeat in loops.


That’s interesting. My testing for EAP-TLS and OWE networks has shown modern clients will simply create another profile when it detects the change in the AKM suite. Hard roam between wpa2/wpa3, but still seem less for the client.


Listening and responding is just like singing. If you are "thinking about it while doing it" it feel off to everyone. Like how singing is best when you embody the lessons and move your focus away from "getting it right". It has to feel like you and not you playing a character.


everybody has to learn to sing at some point. same goes for listening.


I can see why someone might have that opinion. I think the author hasn't met himself yet. As one can only meet and understand another as deeply as they have met themselves. I do wonder if he would gain more awareness of his self after a couple 7g mushroom runs.


I hope we see this more at the municipal level. Just thinking about dense neighborhoods with sizable lithium storage solutions raises eyebrows. One house fire could spread so quickly.


The problem is, and always has been, land owners and their ego.


Honestly, none of the comments here coming from a place with enough protocol knowledge to talk about the "whys"

I operate a large enterprise wireless network with 80mhz 5Ghz channels and 160Mhz 6Ghz channels. It is possible if your environment allows.


How do you think speeds effect airtime utilization/optimization? And how does this change with lower PHY rates?


Not linearly. The data may take twice as long to transmit at half the rate, but there's overhead which doesn't change. If you can use half the channel width and transmit at half the rate, you halve the Hz-seconds used for preambles and stuff, while keeping the Hz-seconds used for data the same.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: