Trin 5 af 8 · Windows

Windows-servere

Forbind en Windows-server med installationskoden fra appliancen.

Det skal I bruge

En server med Windows Server 2016 eller nyere.
Et administratorlogin til serveren og administratoradgang til appliancen.

Installér service-agenten

Åbn Servere › Tilføj server › Med service-agent, og vælg Windows.
Klik på Kopiér ved kommandoen til direkte forbindelse. Koden og adressen er udfyldt.
Åbn PowerShell som administrator på serveren, indsæt linjen, og tryk Enter. Lad installationsvinduet køre færdigt.

Kontrollér, at det virker

Efter et minut eller to står serveren under Servere › Alle servere. På serverens side opdateres Sidst meldt ind, og tjenesterne vises under Certifikater. Status Forbundet · Ikke automatiseret er forventet, indtil I har oprettet en installationsplan.

Næste skridt

Fortsæt med Bevis, at domænet er jeres. Skal I forbinde mange servere, så brug udrulning med GPO.

Hvis det fejler

PowerShell viser prompten igen → vent på installationsvinduet, og kontrollér tjenesten med Get-Service sslbrainagent.
Kommandoen mangler en kode → gå til Servere › Tilføj server › Med service-agent, og klik på Lav en ny kode og vis kommandoen, hvis der ikke er en åben kode.
MSI-filen kan ikke hentes, eller serveren stoler ikke på appliancens certifikat → følg beskeden ved kommandoen. Giv appliancen et certifikat, serveren stoler på, og kopiér kommandoen igen.
Serveren kan ikke nå appliancen direkte → følg Servere uden for jeres netværk.
I kan ikke køre kommandoen lokalt → installér service-agenten fra appliancen.
Serveren venter på godkendelse → sammenlign nøglen som beskrevet nedenfor.
Installationen blokeres af en sikkerhedspolitik → brug godkendelse i Windows med jeres sikkerhedsadministrator.
Serveren dukker ikke op → følg Service-agenten melder sig ikke.

Serveren venter på godkendelse

En server med installationskode er normalt godkendt. Ligner den en geninstallation, står den under Servere, der venter på godkendelse på Servere › Tilføj server › Med service-agent. Sammenlign Agentnøgle med nøglen i service-agentens log, og klik på Godkend, hvis det er jeres maskine.

Logfiler

Hvad	Hvor
Service-agentens log, én fil pr. dag	`C:\ProgramData\sslbrain\logs\agent-<dato>.log`
Opdateringer	`C:\ProgramData\sslbrain\logs\update-msiexec-<version>-<tid>.log`

Tjenesten hedder sslbrainagent. Tilføj /l*v C:\Windows\Temp\sslbrain-agent.log til installationskommandoen for at få en MSI-log.

Registreringsdatabasen

Indstillingerne står i HKLM\SOFTWARE\sslbrain. Værdier under HKLM\SOFTWARE\Policies\sslbrain går forud. Efter en ændring genstartes tjenesten med Restart-Service sslbrainagent. Se værdierne til GPO.

Godkend service-agenten i Windows-sikkerhedspolitikker

App Control for Business er det nuværende navn for Windows Defender Application Control (WDAC). Det er samme teknologi. AppLocker er en separat kontrol; antivirus og EDR kan desuden træffe beslutninger om filer, scripts og adfærd.

Her kan jeres sikkerhedsadministrator forberede målrettede regler. I skal have ret til at administrere de relevante politikker, den faktisk hentede MSI og de installerede filer, en referenceserver med samme Windows-udgave/build og sikkerhedsindstillinger samt Windows-policyværktøjer (ConfigCI eller AppLocker). Behold jeres Windows-grundpolitik, en backup af politikken og en procedure til gendannelse. Funktionerne varierer med OS-versionen. Eksemplerne nedenfor laver lokale XML-forslag og undersøger filer; de anvender ingen politik. Test forslagene gennem jeres normale audit-/pilot- og håndhævelsesproces før bred udrulning. Audit alene beviser ikke, at scripts virker under håndhævelse.

Find de faktiske filer

Den 9-10-2026 undersøgte vi den offentlige x64-agent.msi, version 1.4.2. MSI-tabellerne installerer C:\Program Files\sslbrain\sslbrainagent.exe som sslbrainagent, vist som “sslbrain agent”, under LocalSystem. Kontrollér PathName og StartName på jeres server; en ældre installation eller et andet drev kan afvige.

Både MSI og dens udpakkede EXE indeholder en Authenticode-signatur med et slutcertifikat, der har CN=FairSSL A/S, O=FairSSL A/S, C=DK, virksomhedsnummer 33075782 og udsteder DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1. Slutcertifikatets SHA-256-fingeraftryk er 8854997a1e37006307ed8f985df5142021f9edfd58422d455078dd5b7ad45dab. Det er en observeret identitet, ikke en policystreng til kopiering. Linux-værktøjet osslsigncode verificerede begge signaturer, kæder og tidsstempler; Windows-status fra Get-AuthenticodeSignature er ikke verificeret. Verificér egne filer i Windows, inklusive certifikattillid og adgang til tilbagekaldelseskontrol. Godkend ikke en fil med manglende eller ugyldig signatur uden at undersøge den.

Gem den hentede installer som sslbrain-agent.msi i den aktuelle mappe, og undersøg den og den installerede EXE:

$exe = 'C:\Program Files\sslbrain\sslbrainagent.exe'
Get-CimInstance Win32_Service -Filter "Name='sslbrainagent'" |
    Select-Object Name, StartName, PathName
$files = @('.\sslbrain-agent.msi', $exe)
foreach ($file in $files) {
    $s = Get-AuthenticodeSignature -LiteralPath $file
    [pscustomobject]@{
        File = $file; Status = $s.Status; Detail = $s.StatusMessage
        Subject = $s.SignerCertificate.Subject
        Issuer = $s.SignerCertificate.Issuer
        Thumbprint = $s.SignerCertificate.Thumbprint
    }
}
(Get-Item -LiteralPath $exe).VersionInfo |
    Select-Object ProductName, OriginalFilename, FileVersion
Get-FileHash -LiteralPath $exe -Algorithm SHA256

Den undersøgte EXE har produkt sslbrain agent, OriginalFilename=SslBrainAgent.dll og filversion 1.4.2.0. Originalnavnet er en signeret ressourceattribut, selv om filen på disken ender på .exe. Hele EXE-filens SHA-256 er ccee898b41b98af4a1382426edb013f0be4bc8e084a84dfdb0d7bcb2698b131c; brug den kun til at identificere denne undersøgte build. App Controls hashregler bruger Authenticode/PE-image-hash, som adskiller sig fra Get-FileHash; lad policyværktøjet beregne dem. Certifikatfingeraftrykket ovenfor er SHA-256, mens det viste certifikats Thumbprint normalt er SHA-1. Det undersøgte slutcertifikats SHA-1-thumbprint er C487B12B87298E601D5CEEEB7239829AC795008A.

MSI’en indeholder én EXE, ikke separate applikations-DLL’er. Dens bundle indeholder managed assemblies, blandt andet SslBrainAgent.dll og System.Management.Automation.dll, og fem native DLL’er: getfilesiginforedist.dll, microsoft.management.infrastructure.native.unmanaged.dll, PowerShell.Core.Instrumentation.dll, pwrshplugin.dll og sni.dll. De native filer indeholder Microsoft-signaturer; deres Windows-tillidsstatus og hvilke filer en bestemt opgave indlæser er ikke verificeret. Linux-verifikation kunne ikke bygge deres udstederkæder. Kontrollér de faktisk indlæste/udpakkede DLL’er enkeltvis, i stedet for at behandle dem som FairSSL-signerede filer. Politikker med .NET Dynamic Code Security kræver også særskilt validering af managed assemblies.

Formål	Standardplacering i den undersøgte implementation
Hentet opgave og udpakkede filer	`C:\ProgramData\sslbrain\work\<task-id>\package.tar` og `extracted\` under samme opgavemappe
Verificeret kopi til EXE-stages og PowerShell-fallback	`.verified-<random>.ps1` eller `.exe` ved siden af originalfilen i opgavens udpakningsmappe
Tool-sti defineret i kode, ikke kaldt i 1.4.2	`C:\ProgramData\sslbrain\tools\<tool-name>\`
Hook-sti defineret i kode, ikke kaldt i 1.4.2	`C:\ProgramData\sslbrain\hooks\`
Hentning og anvendelse af opdatering	`C:\ProgramData\sslbrain\update\staging\`, derefter `apply\`; kopieret updater-EXE: `apply\SslBrainAgent.exe`
Opdaterings-MSI og rollbackkopier	`update\apply\target\`, `update\apply\previous\` og `update\installed\<version>\` under datamappen
Agent- og opdateringslogs	`C:\ProgramData\sslbrain\logs\` (Logfiler)

DataPath kan ændre opgave-/opdateringsdataenes placering. ToolsPath konfigurerer tool-stien defineret i koden; denne downloadkode og hook-assembleren kaldes ikke i 1.4.2. .NET-værten for single-file-programmer udpakker native biblioteker under DOTNET_BUNDLE_EXTRACT_BASE_DIR, hvis den er sat, ellers under serviceprocessens %TEMP%\.net. Den endelige mappe afhænger af servicens miljø og bundle; den er ikke observeret i Windows. Find den i jeres proces-/modulinventar eller en blokeringshændelse. Stierne identificerer filer til undersøgelse; de anbefaler ikke at tillade eller undtage hele skrivbare mapper.

Regler i App Control og AppLocker

Undersøg signaturer og filmetadata ovenfor. Kopiér kun den verificerede reference-EXE og eventuelle særskilt verificerede afhængighedsfiler til reference-agent i arbejdsmappen. Hold andre downloads ude af den.
For App Control: generér FilePublisher-forslag fra disse reelle filer:
Terminal window
```
New-CIPolicy -ScanPath '.\reference-agent' -FilePath '.\agent-candidate.xml' `
    -Level FilePublisher -Fallback Hash -UserPEs
```
Gennemgå XML-reglens signer, filattribut og minimumsversion for hver regel. For denne EXE er standardfilattributten SslBrainAgent.dll, ikke navnet på disken. Behold både udgiver, den enkelte fils identitet og en passende minimumsversion; det kan følge nyere signerede versioner, så længe identitet og udstederkæde er de samme. Nyt certifikat/kæde eller filidentitet kræver gennemgang. Undersøg hver Hash-fallback, og forny reglerne ved ændrede binærfiler. Erstat ikke manglende filmetadata med en CA-regel eller en regel for alt fra FairSSL. Integrér godkendte regler i jeres grundpolitik med jeres policyværktøj; scanningen er ikke en komplet udrulningspolitik. Behold grundpolitikkens scripthåndhævelse, og gennemgå de genererede policyvalg; anvend ikke scanningens XML direkte. Håndtér MSI’en separat i værktøjets installerregler ud fra den faktisk signerede MSI. Giv aldrig generel tillid til DigiCert eller en anden CA.
For AppLocker: brug Create New Rule → Publisher → Browse i den relevante EXE-, MSI- og, hvis aktiveret, DLL-regelsamling. Vælg den reelle referencefil. Behold udgiver, produkt og binærnavn, og vælg den testede minimumsversion og nyere versioner. Gennemgå wildcardfelter fra værktøjerne. Brug servicens faktiske konto til EXE-/DLL-regler og installationskontoen til MSI-regler. Automatiske opdateringer kører den kopierede updater og msiexec.exe som SYSTEM, så MSI-regler skal også dække S-1-5-18, når opdateringer bruges. Kontrollér, at den eksisterende Windows-grundpolitik tillader de nødvendige systemfiler msiexec.exe og schtasks.exe. Kontrollér, om jeres AppLocker-opsætning håndhæver regler for services, at Application Identity kører, og hvilke regelsamlinger der håndhæves. For standard-EXE’en under LocalSystem laver følgende et forslag og vurderer filen:
Terminal window
```
Get-AppLockerFileInformation -Path $exe |
    New-AppLockerPolicy -RuleType Publisher -User 'S-1-5-18' -Xml |
    Set-Content '.\agent-applocker-candidate.xml'
Test-AppLockerPolicy -XmlPolicy '.\agent-applocker-candidate.xml' `
    -Path $exe -User 'S-1-5-18'
```
Test-AppLockerPolicy kontrollerer filens match mod regler; den tester ikke PowerShell-adfærd, effektiv GPO-sammenlægning eller servicekørsel. Undersøg den effektive politik, og test den faktiske service og nødvendige opgaver på referenceserveren. Når den kopierede updater findes, så vurder også C:\ProgramData\sslbrain\update\apply\SslBrainAgent.exe med Test-AppLockerPolicy for S-1-5-18; en regel, der kun bygger på installationsstien, dækker den ikke. Mangler en afhængighed en brugbar udgiveridentitet, så brug et gennemgået hashforslag for den enkelte fil og opdatér det med filen. Tillad ikke hele ProgramData, Temp, arbejdsmappen eller alt via powershell.exe som godkendelse af deploy-scripts.

Integrationernes scripts skal godkendes separat

En EXE-task-stage kører som en separat proces fra sin .verified-<random>.exe-kopi i opgavens udpakningsmappe. Den kræver sin egen målrettede publisher-/FilePublisher- eller filhashregel genereret fra det faktiske verificerede program og dets afhængigheder. Service-EXE-reglen og sslbrains pakkesignatur godkender den ikke i Windows. Brug filidentitet frem for at tillade den skrivbare mappe eller tilfældige sti.

I den undersøgte 1.4.2-implementation opretter det indbyggede PowerShell SDK et runspace og kalder AddScript(scriptContent) på scripttekst. Denne vej kører ikke en Authenticode-godkendt .ps1-fil via dens sti. En FilePublisher-regel for service-EXE’en, en pakkesignatur eller en Authenticode-signatur på originalscriptet dokumenterer derfor ikke, at dette script i hukommelsen får FullLanguage-godkendelse under App Control.

Er den indbyggede vært utilgængelig eller fejler initialiseringen, starter fallback powershell.exe med -ExecutionPolicy Bypass og en kodet bootstrap. Den sender input via stdin og kalder en midlertidig verificeret scriptfil via sti. Bypass er et valg af execution policy for processen; det kan ikke tilsidesætte en execution policy fra Group Policy og giver ingen tilladelse i App Control eller AppLocker. Bootstrappens .NET-kald og scripts kan ramme sprogbegrænsninger. Fallback er ikke en genvej til godkendelse. En script-runtime-fejl, inklusive en sprogbegrænsningsfejl efter eksekveringsstart, udløser ikke automatisk fallback.

GPO-valget Allow only signed scripts svarer til AllSigned for scriptfiler. Execution policy er en sikkerhedshjælp, ikke en application-control-sikkerhedsgrænse: MachinePolicy/UserPolicy går forud for procesindstillinger, men AllSigned alene beviser ikke, at AddScript-teksten blev kontrolleret som en signeret fil. Under App Control afhænger PowerShells adfærd af OS/API og PowerShell-version: ikke-godkendt kode kan begrænses eller blokeres. Det indbyggede SDK er PowerShell 7.4.7; fallback er Windows PowerShell. Kontrollér både PowerShell Core- og Windows PowerShell-GPO-indstillinger: de administreres separat, med det dokumenterede valg Use Windows PowerShell Policy setting for Core. Under en effektiv GPO AllSigned kræver fallback-scriptfilen sin egen gyldige Authenticode-signatur og udgivertillid; en separat pakkesignatur leverer ikke dette. Antag ikke, at resultatet i administratorens interaktive shell beskriver servicens runspace.

sslbrains separate pakkesignaturer og ScriptPolicy styrer pakkeintegritet og godkendelse inde i sslbrain. De er adskilt fra Windows Authenticode og Windows-politikker. Behold signaturkontrol af pakker/downloads/opdateringer: version 1.4.2 verificerer opdateringskatalog og releasemanifest mod indbyggede produktionsankre og kontrollerer MSI mod signerede størrelser/hashværdier. Det er ikke en påstand om, at updateren udfører Windows Authenticode-validering.

I kan forberede program-/installerregler nu. Her er ingen verificeret opskrift på FullLanguage-godkendelse af den nuværende installationsvej i hukommelsen under en restriktiv scriptpolitik. Validér det konkrete moduls discovery, deployment og verification under jeres politik før brug; en kørende service eller vellykket check-in er utilstrækkeligt. Kræver jeres regler, at alle deployments kører som policygodkendte signerede scriptfiler, kræver denne vej en implementationsændring. Gem kravet og den fejlende operation til support; svæk ikke application control, deaktivér ikke scripthåndhævelse, og ændr ikke execution policy for at få det til at virke.

Antivirus og EDR

Behold scanning, AMSI og adfærdsovervågning. Gennemgå leverandørens faktiske alarm, filhash, signatur, procestræ og blokerede operation. Foretræk en afgrænset godkendelse af den identificerede fil og berørte enhedsgruppe med dato for gennemgang/udløb efter leverandørens produktdokumentation. Vurdér igen ved opdatering. En programgodkendelse godkender ikke automatisk underprocesser, scripts, ændringer i certifikatlager eller servicegenstart. Der er ingen garanti for kompatibilitet med alle antivirus-/EDR-politikker.

Microsoft Defender for Endpoint understøtter eksempelvis filhashbaserede Allow-indikatorer og certifikatindikatorer. En certifikatindikator dækker flere filer, så en indikator for én fil er mere målrettet, når den er tilstrækkelig. Funktionerne kræver dokumenteret licens, rettigheder, Defender-konfiguration og enhedsafgrænsning; brug leverandørvejledningerne nedenfor. Scanningsundtagelser i Defender Antivirus er ikke det samme som EDR-godkendelse. Undtag ikke hele agent-, arbejds-, opdaterings- eller .NET-udpakningsmapper, og lav ikke brede procesundtagelser. Andre leverandører kræver deres egen dokumenterede godkendelsesprocedure.

Netværksgodkendelse er separat: tillad den konfigurerede appliances HTTPS-vært/port (normalt 443), navneopslag og, når Cloud bruges, cloud.sslbrain.com:443; installation fra den offentlige download kræver sslbrain.com:443. Opdateringer i den undersøgte kode hentes fra den konfigurerede appliance over HTTPS. For en agent, hvis gemte destinationsliste kun indeholder Cloud, afviser release 1.4.2 staging af opdatering, fordi denne Cloud-opdateringskilde ikke er implementeret; antag ikke, at Cloud-kommunikation også giver denne opdateringsvej. Kontrol af signaturtillid/tilbagekaldelse kan kræve adgang til certifikatudstedernes tjenester efter jeres netværkspolitik. Agenten kræver ingen indgående port. Se Sådan når agenten appliancen for jeres forbindelsestype.

Find en blokering, og registrér hvad der er testet

Sammenhold samme tidspunkt og fil/proces i agentlog, MSI-log og disse Windows-kanaler:

Event Viewer-kanal	Hvad I kontrollerer
`Microsoft-Windows-CodeIntegrity/Operational`	3076: ville blokere i audit; 3077: blokeret under håndhævelse; forbind 3089-signaturdetaljer via ActivityID. 3099 viser en indlæst politik.
`Microsoft-Windows-AppLocker/EXE and DLL`	AppLocker 8003: ville blokere i audit; 8004: blokeret. Kontrollér fil, regel og bruger-SID.
`Microsoft-Windows-AppLocker/MSI and Script`	AppLocker 8006/8007: audit/blokering. App Control 8028/8029: scriptværtens audit-/håndhævelsesbeslutning; 8038: tilknyttede signaturdetaljer. Værten afgør begrænsning eller blokering. Microsoft dokumenterer, at kanalen mangler på Server Core.
`Microsoft-Windows-PowerShell/Operational` eller `PowerShellCore/Operational`	Værtsfejl og, når aktiveret, script-block-hændelser som 4104. PowerShell Core kræver registreret event provider, før den kan skrive disse hændelser. Sammenhold med agentloggens indbyggede vært-/fallbackbeskeder.
`Microsoft-Windows-Windows Defender/Operational` og EDR-konsollen	Detektion, karantæne, ASR eller anden leverandørhandling; følg vejledningen til den faktiske alarm.

Get-ExecutionPolicy -List
Get-AppLockerPolicy -Effective -Xml
Get-WinEvent -FilterHashtable @{
    LogName='Microsoft-Windows-CodeIntegrity/Operational'
    Id=3076,3077,3089,3099
    StartTime=(Get-Date).AddHours(-1)
} | Select-Object TimeCreated, Id, Message

Kør disse læsekommandoer med relevante administratorrettigheder. En tom kanal eller manglende blokeringshændelse beviser ikke godkendelse. Kontrollér effektiv politik, signaturstatus, serviceidentitet, afhængighedsfil og den præcise fejlende fase. Script-block-logs kan indeholde følsomme scripts/input; beskyt diagnoseevidens med adgangskontrol, og fjern følsomme oplysninger før deling.

Artefaktundersøgelsen og kildestierne ovenfor er kontrolleret den 9-10-2026 mod release 1.4.2. Windows-sikkerhedsadfærden er dokumenteret af Microsoft; eksekverings- og opdateringsdetaljerne kommer fra releasens implementation. Der er ikke udført Windows-runtime-test under App Control, AppLocker, antivirus eller EDR til denne guide. Registrér OS/build, agentversion, politikker, leverandørindstillinger og resultat af installation, servicestart, discovery, deployment, verification og opdatering i jeres pilot.