4 ms·

I'd even argue that you always always want to use some common webserver or proxy (nginx, apache, haproxy, ...) on 80/443 proxying to the application running on

by corty 5y ago

I'd even argue that you always always want to use some common webserver or proxy (nginx, apache, haproxy, ...) on 80/443 proxying to the application running on 127.0.0.1:8080. Why? Multiple reasons: - Unified TLS config and certificate deployment to your chosen common webserver. Never again having to fiddle with yet another crappy vendor configuration not knowing about anything beyond DES, Java crapping itself with larger certificates, vendors not patching TLS library problems for ages. - Unified log format: Vendors never stick to a proper format, but everyone can read and parse apache logs. Also, easier handling through unified output to syslog/logstash/whatever. - Unified authentication: No need to wait for all your vendors to support your orgs chosen SSO scheme. Just let your common webserver handle things and pass on some 'X-Authenticated-User: joe'. Most vendors do handle those. - Additional authentication: Afraid of pre-auth exploits in a vendor's crappy application or whatever SQL injection in the login form some internal department concocted? Just have the proxy do an additional authentication step (e.g. negotiate/kerberos/AD auth), then unauthenticated users cannot harm you and authenticated evil users will be plainly visible in the logs. - Fixing crap: Vendor changed the URL scheme of some webapp again? All the links from the internal wiki are broken now? Have the proxy do some regex-rewriting. As for the various grandparents talking about whatever they did at FAANG: I don't believe it, because the above concept is (almost) the same as what e.g. Google is doing with https://cloud.google.com/beyondcorp https://cloud.google.com/beyondcorp

wging 5y ago
I'd say you don't even need to run your local proxy on 80/443 unless it's your public-facing endpoint. Client -> load balancer:80 -> [proxy:8080 -> application:8085] or something is fine. > As for the various grandparents talking about whatever they did at FAANG: I don't believe it I promise you there's a lot of stuff that by-design lives in its own private network (VPC, etc.), and that won't change even with efforts to reduce reliance on corporate intranets. Your laptop gets treated differently from some application server in a cloud provider's datacenter. The latter probably has no reason ever to reach out over the Internet, it has no business even accepting connections from anyone but the (very small) set of allowed clients (probably just your load-balancer layer, plus whatever management stuff). So why allow it? The only argument I've seen for this is that by knowing your hosts are exposed to the internet, you're forced to build for that high-threat environment, but that doesn't seem to outweigh the additional layer of defense-in-depth. This is not to say that anyone should use that private networking layer as their only security control. So: build as if you're on the public internet, but then don't be, to the maximum extent possible.

by corty 5y ago

wging 5y ago

I'd say you don't even need to run your local proxy on 80/443 unless it's your public-facing endpoint. Client -> load balancer:80 -> [proxy:8080 -> application:8085] or something is fine. > As for the various grandparents talking about whatever they did at FAANG: I don't believe it I promise you there's a lot of stuff that by-design lives in its own private network (VPC, etc.), and that won't change even with efforts to reduce reliance on corporate intranets. Your laptop gets treated differently from some application server in a cloud provider's datacenter. The latter probably has no reason ever to reach out over the Internet, it has no business even accepting connections from anyone but the (very small) set of allowed clients (probably just your load-balancer layer, plus whatever management stuff). So why allow it? The only argument I've seen for this is that by knowing your hosts are exposed to the internet, you're forced to build for that high-threat environment, but that doesn't seem to outweigh the additional layer of defense-in-depth. This is not to say that anyone should use that private networking layer as their only security control. So: build as if you're on the public internet, but then don't be, to the maximum extent possible.