All Questions(server)

I have two Windows Server 2019 hosts that cannot start the OpenSSH SSSH Server service after the following Windows updates were installed:

.NET Framework 4.8
October 2024 Cumulative Update
Malicious Software Removal Tool

The Date Modified changed to last night on all files in C:\Windows\System32\OpenSSH:

OpenSSH Directory

Attempting to start the service results in:

"Windows could not start the OpenSSH SSH Service on Local Computer. Error 1067: The process terminated unexpectedly"

There is nothing in the SSH log file when attempting to start. The Event Log gives not helpful details that I can find other than saying "The OpenSSH SSH Server service terminated unexpectedly. It has done this 8 time(s)."

I have a Windows 10 PC which serves as the controller of a laser cutting machine. The PC has updates turned off to ensure that nothing ever changes that could cause a future issue or incompatibility with the machine that it is dedicated to.

Since it will not receive windows updates, I therefore do not trust this PC and want to keep it isolated from the rest of my network.

However, it needs to have access to one network share (on a NAS) so it can access its laser cutting programs and related files.

I already have the PC on its own subnet and vlan which is isolated from the rest of the network, and which does not have internet access. But giving it access to the network shared drive of gives it access to this important shared resource.

What are the best practices for allowing access to a shared drive, by an untrusted PC like this?

I run a scientific web site, call it site.org, that is mirrored at three locations, all listed in DNS as site.org so that clients will choose a specific mirror at random. The individual mirrors are server1.site.org, etc. The LetsEncrypt certificate covers site.org plus the mirror names. All of the mirrors are inside universities that are donating bandwidth; I don't have the funding to pay for the bandwidth myself.

One university, univ.edu, recently decided that for "security control of https communication" (their words) all sites inside their network should be behind their *.univ.edu wildcard certificate. Their implementation is that at the firewall, when they see a port 443 connection, they intercept the SSL handshake and substitute their own certificate. My server never sees the certificate handshake. The client browser sees the *.univ.edu certificate and rejects it because it doesn't cover site.org. I asked for my server's IP to be whitelisted for passthrough, and they said doing so was "not possible".

To me, substituting their certificate for mine looks like an adversary-in-the-middle attack. To be fair, I don't know if they're actually sitting there and monitoring traffic, but I don't see anything to prevent them from doing so. I don't give a hoot about the monitoring for my own purposes (everything on the site is public anyway) but it just seems like a Bad Idea to me even though it makes it much easier for them to manage certificates for sites inside univ.edu.

So: is it normal for large organizations to use an AITM approach to managing certificates? Is this really just because they want to snoop on all (incoming, but not outgoing) connections? Are there reasons I haven't though of for why this is a Bad Idea?

Fundamentally I'm looking for strong arguments I can use to talk them out of their position. If they won't bend, I fear I'll have to shut the mirror down, which would be sad for my users because that mirror has much better bandwidth to the continent it is located in. (Alternative suggestions would be appreciated, though!)

I'm setting up an OU GPO for firewall and other settings for CIS SCA recommendations. I've run into a problem with the Firewall Settings. The PC's in the OU are getting all GPO configurations just as you would expect, and everything is working fine; However, After an unknown amount of time, a couple hours or next day, on the Domain Controller the OU's GPO settings for "Windows Defender Firewall with Advanced Security Settings" are back to defaults, as if I had changed nothing - all other GPO setting are set as I had and staying.

So, the problem is with the domain controller, not the client included in the OU.

Computer Configuration\Policies\Windows Settings\Security Settings\Windows Defender Firewall with Advanced Security

Settings: State:

• Turning on all 3 (Domain, Private, Public Firewall)
• Block incoming (default)
• Allow outgoing (default)

Settings:

• Display notification = No
• Rule Merging: Apply local firewall rules = No
• Apply local connecton security rules = No

Logging

• %SystemRoot%\System32\logfiles\firewall\domainfw.log (privatefw.log, and publicfw.log repectively)
• SizeLimit 16,384
• Log Dropped packets = Yes
• Log successful connections

Note* Firewall are successfully writing to all 3 files.

• Windows Server 2019, PC's are Dell Wyse ThinClients Windows 10 Enterprise LTSC
• NO other GPOs are there save Default Domain and Default Domain Controllers...

I'm stuck, any one seen this before or has suggestions?

Thank you for your time,

I am getting the below error - I am doing this in my local machine with docker desktop - fyi

web-1 | 2024/10/08 01:08:24 [emerg] 12#12: bind() to 10.101.121.15:443 failed (99: Cannot assign requested address) web-1 | nginx: [emerg] bind() to 10.111.121.13:443 failed (99: Cannot assign requested address)

http {

      upstream backend {
          server cluster_1.ingress.com:443;
          server cluster_2.ingress.com:443; max_fails=2 fail_timeout=1s;
      }


      server {
            listen cluster_1.ingress.com:443;
            location / {
         resolver dns-default.openshift-dns;
         proxy_pass https://backend;

                   proxy_pass_request_headers on;
                   proxy_ssl_server_name on;
                   proxy_ssl_name cluster_1.ingress.com;
                   proxy_set_header Host cluster_1.ingress.com;
            }
      }

         server {
                  listen cluster_2.ingress.com;
                  location / {
                       resolver dns-default.openshift-dns;
                      proxy_pass "https://cluster_2.ingress.com";        
                   proxy_pass_request_headers on;
                   proxy_ssl_server_name on;
                   proxy_ssl_name cluster_2.ingress.com;
                   proxy_set_header Host cluster_2.ingress.com;
                  }
            }


    server {
         listen 8080 default_server;
         listen [::]:8080 default_server;
         root /usr/share/nginx/html;
         server_name _;

         add_header Access-Control-Allow-Origin * always;
         add_header Access-Control-Allow-Credentials true;
         add_header Access-Control-Allow-Headers Authorization,Accept,Origin,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range;
         add_header Access-Control-Allow-Methods GET,POST,OPTIONS,PUT,DELETE,PATCH;


         location / {
                   resolver dns-default.openshift-dns;
         proxy_pass $backend;
         }

  }
}