RFC1918 IPs reaching production

One thing I'm still unclear on, is it totally agreed that source IP preservation from 172 is undesired for public wikimedia endpoints?

It's kind of a double-edged sword. The current model allows us to very quickly find out the IP addresses of VMs of abusers residing in WMCS. If the IP addresses were, instead of VM ones, the outgoing NAT ones it would make it a bit more difficult but still doable (e.g. relying on User-Agents if the shared ones are used). On the other hand, seeing RFC1918 address in logs is confusing to say the least. The very first thought that instantly comes to my mind is always 'Spoofing attack and somehow our filters are down, only to be followed by a "ah it's labs^WWMCS"'. If one wants to be pedantic, if WMCS VMs are going to be treated as the internet, then RFC1918 IP addresses should not be used to reach out to production endpoints.Alexandros Kosiaris (talk) 11:59, 14 November 2018 (UTC)Reply

Yes, we may need to clarify what do we really want. It may be worth writting down which problems we see right now. Some quick ideas if we want both identification and isolation:

- having a [transparent] web proxy for the egress traffic heading to our prod Wikis. Also we could do UserAgent enforcement there. And in logs, you will see this IPv4 address (the addr of the proxy).
- allocating a big pool of public IPv4 addresses and giving them to projects/VMs who are going to reach prod Wikis. VMs without public IPv4 address can't reach prod Wikis.
- have egress traffic (to our prod Wikis) using IPv6-only connections. Having a big prefix for CloudVPS and a delegation per-project. Each instance has an unique IPv6 addr.
  - but this may be the same as having 172.16 vs 10.

SSH

This needs some minor rephrasing as reading it gave me the impression the bastions were no more. Probably something alone the lines of.

Access to VMs (ssh tcp/22) is unrestricted.