On 2011-03-30 at 14:08 -0400, Derek J. Balling wrote: > Not at all. Firewalls get misconfigured by accident. It happens, we're all > human. And then you *think* you've got security, because you're trusting your > broken firewall, but you don't. > > Unroutable addresses like RFC1918-space don't suddenly manage to be routable > across the world to my servers. It takes a MUCH more heinous misconfiguration > (static NATs, port-forwarding, etc.) for a misconfigured NAT to open a server > up to attack.
Part of this will be solved as either application developers increase their IPv6 clue or host-based desktop firewalls improve to distinguish "open to local network" from "open to general Internet". With IPv6, you get multiple addresses assigned to an interface, with differing scopes. Your private stuff should only listen to an fe80::/16 address, so is fundamentally protected against packets from across the Internet. Your public stuff listens on a publicly routed IP. If your app can't tell the difference, the desktop firewalls will. After all, what's the difference between "choosing to bind to a globally routable address (or ::)" and "choosing to use NAT-PMP/UPnP to provide a globally-reachable endpoint (sometimes, maybe, depending upon the presence of Carrier-Grade NAT outside the local network)" ? They're both equally exposed, but people may have more of a false sense of confidence with the latter. Well, the former involves a lot less code, so fewer chances for security issues to creep in. But it does mean that in6addr_any is not a suitable default in the way that INADDR_ANY was and so there's a little more code than there used to be. As sysadmins, some of us often evangelise good practices to software developers, explaining what makes systems maintainable. It's incumbent upon those of us working/associating with such folks to explain to them why they should consider whether a local-only bind/listen is a good default. -Phil _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
