4 ms·

> if your team runs public web servers, then you need to listen on ports like 80 and 443 while requiring root How common is this case, really? I'd expect most

by wging 5y ago

> if your team runs public web servers, then you need to listen on ports like 80 and 443 while requiring root How common is this case, really? I'd expect most public-facing services, even really high-scale/'special' stuff, to really be instantiated inside a private network (VPC or suchlike, scoped down to just that service if you're lucky) and not internet-accessible, fronted by public-facing load balancers listening on 80/443 that the service team doesn't need or want to control. AWS's ALBs and various equivalents definitely allow for that. In such a situation there's no need for the internal port that your service hosts listen on to match the external port (though having root on those boxes may be desirable for many other reasons). (of course, if your public web servers are the load balancers themselves, that is different...)

pmontra 5y ago
Even in single machine setups, nginx or apache run on ports 80/443 and reverse proxy to the application servers running on unprivileged ports with unprivileged user ids. It's even easier than having to deploy applications as root (ssh often is not configured to allow root logins.)
- 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 wging 5y ago

pmontra 5y ago

Even in single machine setups, nginx or apache run on ports 80/443 and reverse proxy to the application servers running on unprivileged ports with unprivileged user ids. It's even easier than having to deploy applications as root (ssh often is not configured to allow root logins.)

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.