• 0 Posts
  • 4 Comments
Joined 2 months ago
cake
Cake day: November 20th, 2024

help-circle
  • Only true if you don’t know what you’re doing. The only reason any network is safe at all is NAT and Firewalls that come with it.

    I don’t have to worry about devices on a local network in as far as firewalls go, I can expose anything I want, in fact I delete iptables at first sight on any new distro install or VM, so long as none of it is port forwarded and everything is behind NAT it’s all okay. My network is my castle. Thanks technology! Thanks smart people for figuring this out!

    NAT is not a security mechanism. If you set up a NAT with an otherwise permissive firewall, your router will happily forward any incoming packets destined for RFC 1918 addresses inside, no questions asked. I use this for a “lab” network that I sometimes want accessible from the bigger LAN - the lab router doesn’t have any rules for dropping incoming packets (only blocks some outgoing traffic), and all I have to do on the main router to get this working is to set a static route to the internal lab network through the lab router’s “external” IP.

    And yes, practically it’s a security nightmare to have any IP of any computer accessible from the internet. If you go around configuring firewalls forever you might get it right but oh boy one mistake and you’re done for. Instead, consider NAT, the solution to all problems. I’m writing this behind quadruple NAT rn and it’s honestly fairly easy to manage, I’ve been too lazy to change it, not that I’d advise anything more than 1 necessarily.

    accept established, related; drop incoming. That’s all you need to get the same security as a NAT with a proper firewall. Outgoing connections will get marked and have return traffic allowed, everything incoming without related outgoing traffic gets dropped. Want to “port forward”? Add a rule that allows incoming traffic to a specific IP/port/protocol triplet. Done. Don’t know how to make sure a client stays reachable on a specific address? Give it that specific IP address in addition to the one it autogenerates. This was always possible with IPv4, too, it’s just that the tiny address space made it impractical to use.

    How do you get the equivalent of NAT punchthrough (which is unreliable with many NAT implementations) when you want to do a VoIP call without having to bounce all the data through a central server? Simple, you can just tell both clients the other one’s IP and port, have them spam each other for a tiny while with messages and eventually a message gets through both firewalls. It is very similar to NAT punchthrough, except you don’t have to guess how the NATs work and it’ll reliably connect.

    Yikes! That’s a lot to type to hammer in a nail that sticks out (Android). Thanks but no thanks. I’ll find some way to cripple mDNS on the non-compliant device instead.

    Not sure why you’d regularly need to type out the whole thing. Also not sure why you picked .local when .lan is also incorrectly used for this purpose and is shorter (and isn’t yet assigned to any conflicting technology)

    So are you saying you run some sort of mDNS server(not sure what the word would be there)/provider? Why? How?

    The point of mDNS is that devices auto discover each other on a network without a central authority. The word multicast in multicast DNS is the key. And the reason I use it is because… it just works. There’s no need to configure it, it works like this by default on pretty much every OS. Set the hostname and you’re done, .local now works. You can even bridge it across networks with a mDNS repeater available on many routers.

    Given the ambiguity of certificates everywhere, malicious devices on the local network posing as a different server are not an issue (and it’s not like they couldn’t hijack the IP address in any flat network anyway).



  • I would hope it’s a special, heavy-duty kind at least.

    I’ve seen an expensive microwave with a capacitive touch panel right above the door (and the door was the classic oven style, so attached by the bottom edge). If you ever had a phone with crappy moisture detection, you know where this is going.

    You put your food in the microwave. Turn it on and let it heat the food up. Open the door, take the food out and close the door again. Congratulations, your microwave has probably just turned itself back on, because it detected the humid hot air rising from the briefly opened door as you touching the screen. And because most of the touch screen is “touchable”, there’s a pretty good chance this gust of humid air can successfully pick a cooking/heating mode and confirm it.

    The microwave randomly navigating its own touch screen happened pretty much every time, passing all the menus and turning on was successful about 10% of the time.

    In short, I wouldn’t expect a microwave interface to have any thought put into it.


  • My two cents: the only time I had an issue with Btrfs, it refused to mount without using a FS repair tool (and was fine afterwards, and I knew which files needed to be checked for possible corruption). When I had an issue with ext4, I didn’t know about it until I tried to access an old file and it was 0 bytes - a completely silent corruption I found out probably months after it actually happened.

    Both filesystems failed, but one at least notified me about it, while the second just “pretended” everything was fine while it ate my data.