See also "It rather involved being on the other side of this airtight hatchway" series by Raymond Chen:
https://devblogs.microsoft.com/oldnewthing/20181219-00/?p=10...
https://devblogs.microsoft.com/oldnewthing/20211207-00/?p=10...
Not a good line in a write up like this. Windows does write n store an awful lot of logs by default. However thanks to circular logging with log sizes from the 1990s on critical logs, you can easily lose information.
I can't remember what the defaults are (connects to 2016 AD DC) ... 20Mb for %SystemRoot%\System32\Winevt\Logs\Security.evtx . On a tiddly setup like mine (20 odd users), that will last ... less than a day.
I ship the logs elsewhere for proper evaluation etc but 20Mb? Yes, you can fiddle with the default sizes via group policy and you probably should but 20Mb really is off of the 1990s. OK so all the "core" logs seem to be 20Mb each and there are the rest under /Microsoft/Windows with varying sizes. I probably ought to look at what a PC logs these days - probably the same silly sizes.
System has 8 months, application has 10 months, and setup has 26 months.
The "airtight hatchway" series is about things being presented as ways to break in, when they actually require you to already be in.
However in fairness they didn't say it was an exploit more that it's just a stealthy 'clever' malware.
The second aspect is how well is w3wp.exe isolated? Can and does it use "AppContainer" (or equivalent) isolation and is it strict? For example, could code executed by w3wp.exe create a new network socket, execute another process, write to a file in any path even though it shouldn't have a need to do so? Perhaps a different process sample123.exe is compromised, which by itself isn't too much of a problem due to its high degree of isolation. However, sample123.exe has permission to write to a pipe shared with w3wp.exe and can use this permission to exploit a bug in w3wp.exe (not exposed remotely) to allow code to execute with different/higher permissions of w3wp.exe, or using a plausibly deniable PAGE_EXECUTE_READWRITE memory page of w3wp.exe to store and execute code from without immediately sounding alarm bells.
_If_ strong process isolation was in place and working for w3wp.exe and/or sample123.exe, the "airtight hatchway" may not have been breached because whilst malicious code may have been executable from a stack, the malicious code wouldn't have been able to achieve much or anything of concern (can't read files from disk, can't access memory of other processes, can't login to a SQL database and start pulling data of other users, etc, etc).
I'm not sure what the equivalent of "systemd-analyze security" is for Windows, but it'd be well worthwhile for Windows system owners to demand similar easy-to-use tools for auditing the level of isolation of and required interfaces between applications (spoiler: just like a typical Linux system, the results will not be comforting, but seemingly with Windows you wouldn't know). Windows process isolation features introduced over the years are poorly documented, hard to use due to lack of tooling and often not used except for a few high profile applications such as Chromium and Adobe Acrobat. Chromium possibly has one of the best overviews of how sandboxing/process isolation can be achieved in Windows because they would have gone through a lot of pain in being amongst the first to figure it out[1].
[1] https://chromium.googlesource.com/chromium/src/+/HEAD/docs/d...
Why, should I not be using IIS?
In the company Slack, I said something like "Serious question; is there something that IIS does better than something like Nginx or any other open source server?"
One of the most senior engineers responded back with "crashing".
It’s an “old-world” web-server (like Apache, etc) which defaults to “filesystem-first” which is great for quickly making a directory available on the web, and its architecture employing recyclable worker-processes (since IIS 6) with limited privileges gives it the performance benefits of in-proc code-execution (vs CGI/FastCGI) without the risk of a vuln compromising the entire web server. Oh, and HTTP.sys is pretty nice and fast too. I’ve never had reliability or crashing issues with IIS: if your worker-process goes down it means your application code has a crashing bug in it, not IIS.
Yeah, nginx is nice - but is also a relatively recent tool (since 2004, I didn’t start seeing people prefer it for projects until after NodeJS gave them a reason to use it - so around 10 years ago). While nginx supports Windows, there’s a big fat caution saying it’s performance is sub-par still: https://nginx.org/en/docs/windows.html
So if you’re on Windows - because you’re a (non-Linux) .NET shop, or want/need to run on on-prem Windows Server boxes (especially SMB scenarios) it just makes sense to use IIS: it’s already there and certainly is not an underperforming, insecure, or otherwise “bad” web-server.
A lot of enterprise software is built in .NET for Windows, and as the expectation of web-based UIs for said software has increased... honestly I'd be surprised if IIS usage wasn't increasing in overall uses (though not in market share, for certain).
I ended up wedging a Samba daemon between that and PCs running Windows 10. I mount the DOS box's share via mount.smbfs and re-export it via Samba. The machine is on a rather sparse VLAN!
I have many other horrors on isolated VLANs across the UK to worry about ...
In common with all web servers, advice found via search varies in quality and unfortunately, being Windows based: IIS really suffers. The GUI is pretty intimidating (IIS Manager - both of them) and there are things that can only be done via registry, config files and dark magic.
IIS gets a lot of undeserved stick in my opinion.
If you already paid for your Windows license, not that much. The way it ties into the OS is a bit concerning to me but, apart from that, it's OK.
I think the question can be formulated in a different way: what's RIGHT with using IIS? What does IIS offer you that other web servers don't? Easy AD integration is the one thing that crosses my mind, and I can't think of anything else besides "it's already there".
If you plan on scaling out, however, licensing costs will grow quickly. If you run .NET Core apps, the built-in HTTP server is very fast and runs on Linux as well. Same story with Spring apps - using Netty/Jetty or even Tomcat is easy and makes your app very self-contained.
I think the big nope for me is that it is from the "Pets" era, before servers were "cattle", which was compounded by containerization and tools like Kubernetes and OpenShift. IIS just doesn't look like it fits into that new model.
There is still no equivalent to Microsoft Exchange, Group Policy, Enterprise PKI, and a bunch of other things in the Linux world. SAMBA copies Active Directory, but it's a direct clone, not a unique product.
Not to mention that SQL Server isn't somehow "copying" UNIX. Its performance and feature set blows most of the open-source databases out of the water, with only Postgres having superior features (but not performance).
Microsoft essentially invented OLAP with SQL Analysis Services, and they still have the most popular products in that space, such as Power BI.
Etc...
UNIX was not an option for most people which is one of the reasons why NT killed the Unix workstation market and Microsoft software like IIS, MS SQL and Exchange was already established when Linux gained mainstream adoption.
Since then, they migrated to .Net "Core"[0] which can run on any OS/web-server. Per [0] they initially kept IIS, but once you're on .Net Core+ that certainly isn't a requirement and there may be good licensing or performance reasons to migrate (even with headless Windows Server/IIS).
I did find an article from last year that said they still had a monolithic architecture and were still on-prem (as opposed to cloud/Azure). So, maybe, still on IIS? They certainly did for YEARS.
[0] https://www.infoq.com/news/2020/04/Stack-Overflow-New-Archit...
I still don't get it.
Plus I don't find the "nobody does [XYZ]" when talking about a supported feature of a popular product reassuring, there's always a somebody or the feature would have been removed since it costs money to support and maintain it.
