wollomatic
[Bug] `defaultAllowFrom` should also include `::1`
Describe the bug
defaultAllowFrom is set to 127.0.0.1/32 but this is an IPv4 address and excludes IPv6 addressing.
Additional context
Include ::1/128 as well to support either stack (or in some cases some Docker installations that are IPv6-only).
The same goes for the listening IP. In case anyone is wondering a use-case for IPv6 addresses: some of our installations use fc00::/7 addresses (fd80:...).
Correct me if I'm wrong, but I had the impression that socket-proxy does support IPv6 for allowfrom and listenip, just that it isn't the default. I think that changing defaultAllowFrom to 127.0.0.1/32,::1/128 is probably a correct approach, but from what I see in the code, socket-proxy is currently structured around a single listener, so I don't think it is trivial to support listening on both 127.0.0.1 and ::1 simultaneously (although listening on 0.0.0.0 should also listen on IPv6 if available, if I'm reading the Go docs right).
0.0.0.0 is strictly IPv4, so it shouldn't listen on IPv6 addressing. :: on some libraries implies IPv4 but I've found in the past that isn't always the case. I don't do Go code, but I wonder if a single listener can listen to both (maybe as :: or using the CIDRs you mentioned)? Not a Go developer, so I wouldn't know.
It seems that Go's net package does listen for IPv6 when 0.0.0.0 is specified with tcp as the network parameter, and if IPv4 only is intended, tcp4 should be specified, and then vice versa with :: and tcp6 respectively. I even found a bug report to which this was clarified as intended behaviour. wollomatic/socket-proxy specifies tcp for that parameter, so I expect that you can use either 0.0.0.0 or :: as a listenip workaround if you need dual stack and don't mind the somewhat less secure configuration. Alternatively, I guess there's the option of two differently configured socket-proxy containers, but to me that's not ideal.
For me, this is interesting because the next idea I'd like to propose to wollomatic or even work on myself if he's okay with it is to try to get both TCP and Unix socket options to work concurrently, and I suspect a solution to that will also open the door to being able to specify particular IPv4 and IPv6 listen addresses at the same time.
It isn't less secure if you're only getting fc00::7 ULA addresses (site-local), though it's up to the deployment administrator to make sure they're not running something publicly-accessible (something warned against already). Edit: I'd like to note that it's common practice to firewall ULA site-local addresses to prevent any leakage, just to be certain.
I'd also like to second the notion of simultaneous sockets (IPv4, IPv6, Unix), I've a few containers that need certain information but they either support TCP or Unix.