4 ms·

Out of the box, Windows Server assumes that you don't know what you're doing, probably because many Windows Server deployments are configured by brand-new or am

by qq66 11y ago

Out of the box, Windows Server assumes that you don't know what you're doing, probably because many Windows Server deployments are configured by brand-new or amateur users. If you do know what you're doing and want all those warnings to go away, you can turn them off in the control panel.

dogma1138 11y ago
Considering the costs of most Windows servers i doubt that has anything to do with that. I can guarantee you that the amount of inexperienced people that try to configure a simple LAMP server every day out numbers the people who try to configure a MSFT server by several orders of magnitude. MSFT just tries to harden the server as much as possible from the get go, as it assumes you won't need to use the internet to configure it or to download additional software from the internet. Whether the assumption is correct or not, a server coming out of the box in it's most hardened usable generic state is actually a preferred thing whether your an experienced user or a complete beginner.
- MichaelGG 11y ago
  Yeah it's a CYA move by MS. Same reason they don't ship a telnet client by default. Or why you have to double opt-in for gzip with ASP.NET+IIS. I'm guessing, like SELinux, what users end up doing is just disabling things completely (or enabling all options) instead of figuring out all the specifics. I understand, no one wants to be responsible for shipping a vulnerability by default, like MS products used to be. Also see their terrible HTTP.SYS reservation system. Any program can listen on a socket. But if you want to use that socket for HTTP and use the OS-provided functions? Boom, special ACLs apply; enjoy figuring out a special one off utility. Or just run your service as a local admin.
  - dogma1138 11y ago
    Yeah it's not great, but there's a good reason why there's an ACL for HTTP.SYS name reservations, a malicious application can actually reserve system reserved names, or overwrite the names of other services which already reserved a name such as the IIS or SQL server running on the machine. It's quite an annoying thing to understand Windows permissions, especially when you are using built-in drivers and services such as HTTP.SYS. Also don't forget that when you interact with HTTP.SYS you are interacting with a kernel mode driver, sockets can be bound in user space, so you are dealing with more privileged content. P.S. Network Service can use HTTP.SYS reservations, and pretty much anything else AFAIK.
    - MichaelGG 11y ago
      Right, so deny access to apps trying to listen on reserved ports/namespaces. Instead, if you use sockets, you're free to listen on, say, 6666 just fine. But asking for HTTP on the same port results in a permissions error. This is obviously dumb behavior.
      - dogma1138 11y ago
        Different scopes, HTTP.SYS actually processes and routes HTTP requests in the system, think of it as an HTTP proxy router. This is a kernel mode driver, and a misuse of it can compromise the entire system. It's not dumb behavior, but that's the "price" you have to pay when you have a system component that allows you to handle HTTP requests easily, it also removes the requirement for an HTTP server to have a working socket on the system since HTTP.SYS for example can route requests to multiple virtual servers on the same machine using the same socket based on the URI requested. And more importantly allows applications to communicate over HTTP without implementing a TCP/IP or any other networking stack, they only need to register with HTTP.SYS and it works, heck if you really want too you can instruct HTTP.SYS to strip all the HTTP protocol related stuff from the traffic and then you don't even need to implement "HTTP" in your application either. Sockets require very little permissions to bind because binding a socket cannot have adverse affects on the entire system, if it's in use by another app it wont allow you to do it.

by qq66 11y ago

dogma1138 11y ago

Considering the costs of most Windows servers i doubt that has anything to do with that. I can guarantee you that the amount of inexperienced people that try to configure a simple LAMP server every day out numbers the people who try to configure a MSFT server by several orders of magnitude. MSFT just tries to harden the server as much as possible from the get go, as it assumes you won't need to use the internet to configure it or to download additional software from the internet. Whether the assumption is correct or not, a server coming out of the box in it's most hardened usable generic state is actually a preferred thing whether your an experienced user or a complete beginner.

MichaelGG 11y ago
Yeah it's a CYA move by MS. Same reason they don't ship a telnet client by default. Or why you have to double opt-in for gzip with ASP.NET+IIS. I'm guessing, like SELinux, what users end up doing is just disabling things completely (or enabling all options) instead of figuring out all the specifics. I understand, no one wants to be responsible for shipping a vulnerability by default, like MS products used to be. Also see their terrible HTTP.SYS reservation system. Any program can listen on a socket. But if you want to use that socket for HTTP and use the OS-provided functions? Boom, special ACLs apply; enjoy figuring out a special one off utility. Or just run your service as a local admin.
- dogma1138 11y ago
  Yeah it's not great, but there's a good reason why there's an ACL for HTTP.SYS name reservations, a malicious application can actually reserve system reserved names, or overwrite the names of other services which already reserved a name such as the IIS or SQL server running on the machine. It's quite an annoying thing to understand Windows permissions, especially when you are using built-in drivers and services such as HTTP.SYS. Also don't forget that when you interact with HTTP.SYS you are interacting with a kernel mode driver, sockets can be bound in user space, so you are dealing with more privileged content. P.S. Network Service can use HTTP.SYS reservations, and pretty much anything else AFAIK.
  - MichaelGG 11y ago
    Right, so deny access to apps trying to listen on reserved ports/namespaces. Instead, if you use sockets, you're free to listen on, say, 6666 just fine. But asking for HTTP on the same port results in a permissions error. This is obviously dumb behavior.
    - dogma1138 11y ago
      Different scopes, HTTP.SYS actually processes and routes HTTP requests in the system, think of it as an HTTP proxy router. This is a kernel mode driver, and a misuse of it can compromise the entire system. It's not dumb behavior, but that's the "price" you have to pay when you have a system component that allows you to handle HTTP requests easily, it also removes the requirement for an HTTP server to have a working socket on the system since HTTP.SYS for example can route requests to multiple virtual servers on the same machine using the same socket based on the URI requested. And more importantly allows applications to communicate over HTTP without implementing a TCP/IP or any other networking stack, they only need to register with HTTP.SYS and it works, heck if you really want too you can instruct HTTP.SYS to strip all the HTTP protocol related stuff from the traffic and then you don't even need to implement "HTTP" in your application either. Sockets require very little permissions to bind because binding a socket cannot have adverse affects on the entire system, if it's in use by another app it wont allow you to do it.