Steg 5 av 8 · Windows

Windows-servrar

Anslut en Windows-server med installationskoden från appliancen.

Det här behöver ni

En server med Windows Server 2016 eller senare.
Administratörsinloggning till servern och administratörsåtkomst till appliancen.

Installera serviceagenten

Öppna Servrar › Lägg till server › Med serviceagent och välj Windows.
Klicka på Kopiera vid kommandot för direkt anslutning. Koden och adressen är ifyllda.
Öppna PowerShell som administratör på servern, klistra in raden och tryck på Enter. Låt installationsfönstret bli klart.

Kontrollera att det fungerar

Efter en eller två minuter finns servern under Servrar › Alla servrar. På serverns sida uppdateras Senast inrapporterad och tjänsterna visas under Certifikat. Status Ansluten · Inte automatiserad är väntad tills ni har skapat en installationsplan.

Nästa steg

Fortsätt med Visa att domänen är er. Ska ni ansluta många servrar använder ni utrullning med GPO.

Om det inte fungerar

PowerShell visar prompten igen → vänta på installationsfönstret och kontrollera tjänsten med Get-Service sslbrainagent.
Kommandot saknar en kod → gå till Servrar › Lägg till server › Med serviceagent och klicka på Skapa en ny kod och visa kommandot om ingen kod är öppen.
MSI-filen kan inte hämtas eller servern litar inte på appliancens certifikat → följ meddelandet vid kommandot. Ge appliancen ett certifikat som servern litar på och kopiera kommandot igen.
Servern når inte appliancen direkt → följ Servrar utanför ert nätverk.
Ni kan inte köra kommandot lokalt → installera serviceagenten från appliancen.
Servern väntar på godkännande → jämför nyckeln enligt beskrivningen nedan.
En säkerhetspolicy blockerar installationen → gå igenom godkännande i Windows med er säkerhetsadministratör.
Servern dyker inte upp → följ Serviceagenten rapporterar inte in.

Servern väntar på godkännande

En server med installationskod är normalt godkänd. Liknar den en ominstallation visas den under Servrar som väntar på godkännande på Servrar › Lägg till server › Med serviceagent. Jämför Agentnyckel med nyckeln i serviceagentens logg och klicka på Godkänn om maskinen är er.

Loggfiler

Vad	Var
Serviceagentens logg, en fil per dag	`C:\ProgramData\sslbrain\logs\agent-<datum>.log`
Uppdateringar	`C:\ProgramData\sslbrain\logs\update-msiexec-<version>-<tid>.log`

Tjänsten heter sslbrainagent. Lägg till /l*v C:\Windows\Temp\sslbrain-agent.log i installationskommandot för att få en MSI-logg.

Registret

Inställningarna finns i HKLM\SOFTWARE\sslbrain. Värden under HKLM\SOFTWARE\Policies\sslbrain har företräde. Starta om tjänsten med Restart-Service sslbrainagent efter en ändring. Se värdena för GPO.

Godkänn serviceagenten i Windows säkerhetspolicyer

App Control for Business är det nuvarande namnet på Windows Defender Application Control (WDAC). Det är samma teknik. AppLocker är en separat kontroll; antivirus och EDR kan dessutom fatta beslut om filer, skript och beteende.

Här kan er säkerhetsadministratör förbereda avgränsade regler. Ni behöver rätt att administrera relevanta policyer, den faktiskt hämtade MSI-filen och installerade filer, en referensserver med samma Windows-utgåva/build och säkerhetsinställningar samt Windows policyverktyg (ConfigCI eller AppLocker). Behåll er Windows-grundpolicy, en säkerhetskopia av policyn och en återställningsprocedur. Funktioner varierar med OS-versionen. Exemplen nedan skapar lokala XML-förslag och granskar filer; de tillämpar ingen policy. Testa förslagen genom er vanliga audit-/pilot- och tillämpningsprocess före bred utrullning. Audit ensamt bevisar inte att skript fungerar när reglerna tillämpas.

Identifiera de faktiska filerna

Den 9-10-2026 granskade vi den offentliga x64-agent.msi, version 1.4.2. MSI-tabellerna installerar C:\Program Files\sslbrain\sslbrainagent.exe som sslbrainagent, visad som “sslbrain agent”, under LocalSystem. Kontrollera PathName och StartName på er server; en äldre installation eller annan enhet kan skilja sig.

Både MSI-filen och dess extraherade EXE innehåller en Authenticode-signatur vars slutcertifikat har CN=FairSSL A/S, O=FairSSL A/S, C=DK, organisationsnummer 33075782 och utfärdare DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1. Slutcertifikatets SHA-256-fingeravtryck är 8854997a1e37006307ed8f985df5142021f9edfd58422d455078dd5b7ad45dab. Det är en observerad identitet, inte en policysträng att kopiera. Linux-verktyget osslsigncode verifierade båda signaturerna, kedjorna och tidsstämplarna; Windows-status från Get-AuthenticodeSignature är inte verifierad. Verifiera era egna filer i Windows, inklusive certifikattillit och åtkomst för återkallelsekontroll. Godkänn inte en fil med saknad eller ogiltig signatur utan att undersöka den.

Spara den hämtade installeraren som sslbrain-agent.msi i aktuell mapp och granska den och den installerade EXE-filen:

$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 granskade EXE-filen har produkt sslbrain agent, OriginalFilename=SslBrainAgent.dll och filversion 1.4.2.0. Originalnamnet är ett signerat resursattribut, trots att filen på disken slutar med .exe. Hela EXE-filens SHA-256 är ccee898b41b98af4a1382426edb013f0be4bc8e084a84dfdb0d7bcb2698b131c; använd det endast för att identifiera denna granskade build. App Controls hashregler använder Authenticode/PE-image-hash, som skiljer sig från Get-FileHash; låt policyverktyget beräkna dem. Certifikatfingeravtrycket ovan är SHA-256, medan certifikatets visade Thumbprint normalt är SHA-1. Det granskade slutcertifikatets SHA-1-thumbprint är C487B12B87298E601D5CEEEB7239829AC795008A.

MSI-filen innehåller en EXE, inte separata applikations-DLL:er. Dess bundle innehåller managed assemblies, bland annat SslBrainAgent.dll och System.Management.Automation.dll, och fem native DLL:er: getfilesiginforedist.dll, microsoft.management.infrastructure.native.unmanaged.dll, PowerShell.Core.Instrumentation.dll, pwrshplugin.dll och sni.dll. De native filerna innehåller Microsoft-signaturer; deras Windows-tillitsstatus och vilka filer en viss uppgift laddar är inte verifierade. Linux-verifieringen kunde inte bygga deras utfärdarkedjor. Kontrollera faktiskt laddade/extraherade DLL:er var för sig i stället för att behandla dem som FairSSL-signerade filer. Policyer med .NET Dynamic Code Security behöver även separat validering av managed assemblies.

Syfte	Standardplats i den granskade implementationen
Hämtad uppgift och extraherade filer	`C:\ProgramData\sslbrain\work\<task-id>\package.tar` och `extracted\` under samma uppgiftsmapp
Verifierad kopia för EXE-stages och PowerShell-fallback	`.verified-<random>.ps1` eller `.exe` bredvid originalfilen i uppgiftens extraktionsmapp
Verktygssökväg definierad i kod, inte anropad i 1.4.2	`C:\ProgramData\sslbrain\tools\<tool-name>\`
Hook-sökväg definierad i kod, inte anropad i 1.4.2	`C:\ProgramData\sslbrain\hooks\`
Hämtning och tillämpning av uppdatering	`C:\ProgramData\sslbrain\update\staging\`, sedan `apply\`; kopierad updater-EXE: `apply\SslBrainAgent.exe`
Uppdaterings-MSI och återställningskopior	`update\apply\target\`, `update\apply\previous\` och `update\installed\<version>\` under datamappen
Agent- och uppdateringsloggar	`C:\ProgramData\sslbrain\logs\` (Loggfiler)

DataPath kan ändra platsen för uppgifts-/uppdateringsdata. ToolsPath konfigurerar verktygssökvägen definierad i koden; denna hämtningskod och hook-assemblern anropas inte i 1.4.2. .NET-värden för single-file-program extraherar native bibliotek under DOTNET_BUNDLE_EXTRACT_BASE_DIR om den är angiven, annars under tjänsteprocessens %TEMP%\.net. Den slutliga mappen beror på tjänstens miljö och bundle; den är inte observerad i Windows. Hitta den i ert process-/modulinventarium eller en blockeringshändelse. Sökvägarna identifierar filer att undersöka; de rekommenderar inte att tillåta eller undanta hela skrivbara mappar.

Regler i App Control och AppLocker

Granska signaturer och filmetadata ovan. Kopiera endast den verifierade referens-EXE-filen och eventuella separat verifierade beroendefiler till reference-agent i arbetsmappen. Håll andra hämtningar utanför den.
För App Control: skapa FilePublisher-förslag från dessa verkliga filer:
Terminal window
```
New-CIPolicy -ScanPath '.\reference-agent' -FilePath '.\agent-candidate.xml' `
    -Level FilePublisher -Fallback Hash -UserPEs
```
Granska XML-regelns signer, filattribut och minimiversion för varje regel. För denna EXE är standardfilattributet SslBrainAgent.dll, inte namnet på disken. Behåll både utgivare, den enskilda filens identitet och en lämplig minimiversion; det kan följa nyare signerade versioner så länge identitet och utfärdarkedja är samma. Nytt certifikat/kedja eller filidentitet kräver granskning. Granska varje Hash-fallback och förnya reglerna när binärfiler ändras. Ersätt inte saknade filmetadata med en CA-regel eller en regel för allt från FairSSL. Integrera godkända regler i er grundpolicy med ert policyverktyg; skanningen är inte en komplett utrullningspolicy. Behåll grundpolicyns skripttillämpning och granska de genererade policyalternativen; tillämpa inte skanningens XML direkt. Hantera MSI-filen separat i verktygets installerarregler utifrån den faktiskt signerade MSI-filen. Ge aldrig generell tillit till DigiCert eller någon annan CA.
För AppLocker: använd Create New Rule → Publisher → Browse i relevant EXE-, MSI- och, om aktiverad, DLL-regelsamling. Välj den verkliga referensfilen. Behåll utgivare, produkt och binärnamn och välj den testade minimiversionen och senare versioner. Granska wildcardfält från verktygen. Använd tjänstens faktiska konto för EXE-/DLL-regler och installationskontot för MSI-regler. Automatiska uppdateringar kör den kopierade uppdateraren och msiexec.exe som SYSTEM, så MSI-regler måste även omfatta S-1-5-18 när uppdateringar används. Kontrollera att den befintliga Windows-grundpolicyn tillåter nödvändiga systemfiler msiexec.exe och schtasks.exe. Kontrollera om er AppLocker-konfiguration tillämpar regler för tjänster, att Application Identity körs och vilka regelsamlingar som tillämpas. För standard-EXE-filen under LocalSystem skapar följande ett förslag och bedömer 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 kontrollerar filens matchning mot regler; det testar inte PowerShell-beteende, effektiv GPO-sammanslagning eller tjänstekörning. Granska den effektiva policyn och testa den faktiska tjänsten och nödvändiga uppgifter på referensservern. När den kopierade uppdateraren finns, bedöm även C:\ProgramData\sslbrain\update\apply\SslBrainAgent.exe med Test-AppLockerPolicy för S-1-5-18; en regel som endast bygger på installationssökvägen omfattar den inte. Saknar ett beroende en användbar utgivaridentitet, använd ett granskat hashförslag för den enskilda filen och uppdatera det med filen. Tillåt inte hela ProgramData, Temp, arbetsmappen eller allt via powershell.exe som godkännande av deploy-skript.

Integrationernas skript kräver separat godkännande

En EXE-task-stage körs som en separat process från sin .verified-<random>.exe-kopia i uppgiftens extraktionsmapp. Den behöver en egen avgränsad publisher-/FilePublisher- eller filhashregel skapad från det faktiska verifierade programmet och dess beroenden. Tjänstens EXE-regel och sslbrains paketsignatur godkänner den inte i Windows. Använd filidentitet i stället för att tillåta den skrivbara mappen eller slumpmässiga sökvägen.

I den granskade 1.4.2-implementationen skapar det inbyggda PowerShell SDK ett runspace och anropar AddScript(scriptContent) på skripttext. Denna väg kör inte en Authenticode-godkänd .ps1-fil via dess sökväg. En FilePublisher-regel för tjänstens EXE, en paketsignatur eller en Authenticode-signatur på originalskriptet visar därför inte att detta skript i minnet får FullLanguage-godkännande under App Control.

Om den inbyggda värden saknas eller inte kan initialiseras startar fallback powershell.exe med -ExecutionPolicy Bypass och en kodad bootstrap. Den skickar indata via stdin och anropar en tillfällig verifierad skriptfil via sökväg. Bypass är ett val av execution policy för processen; det kan inte åsidosätta en execution policy från Group Policy och ger inte tillstånd i App Control eller AppLocker. Bootstrappens .NET-anrop och skripten kan möta språkbegränsningar. Fallback är inte en genväg till godkännande. Ett skript-runtime-fel, inklusive ett språkbegränsningsfel efter exekveringsstart, utlöser inte automatiskt fallback.

GPO-valet Allow only signed scripts motsvarar AllSigned för skriptfiler. Execution policy är en säkerhetshjälp, inte en säkerhetsgräns för application control: MachinePolicy/UserPolicy har företräde framför processinställningar, men AllSigned ensamt bevisar inte att AddScript-texten kontrollerades som en signerad fil. Under App Control beror PowerShells beteende på OS/API och PowerShell-version: icke godkänd kod kan begränsas eller blockeras. Det inbyggda SDK är PowerShell 7.4.7; fallback är Windows PowerShell. Kontrollera både PowerShell Core- och Windows PowerShell-GPO-inställningar: de administreras separat, med det dokumenterade valet Use Windows PowerShell Policy setting för Core. Under en effektiv GPO AllSigned kräver fallback-skriptfilen en egen giltig Authenticode-signatur och utgivartillit; en separat paketsignatur ger inte detta. Anta inte att resultat i administratörens interaktiva shell beskriver tjänstens runspace.

sslbrains separata paketsignaturer och ScriptPolicy styr paketintegritet och godkännande inom sslbrain. De är separata från Windows Authenticode och Windows-policyer. Behåll signaturkontroll av paket/hämtningar/uppdateringar: version 1.4.2 verifierar uppdateringskatalog och releasemanifest mot inbyggda produktionsankare och kontrollerar MSI mot signerade storlekar/hashvärden. Det är inte ett påstående om att uppdateraren utför Windows Authenticode-validering.

Ni kan förbereda program-/installerarregler nu. Här finns inget verifierat recept för FullLanguage-godkännande av den nuvarande installationsvägen i minnet under en restriktiv skriptpolicy. Validera den faktiska modulens discovery, deployment och verification under er policy före användning; en tjänst som körs eller en lyckad check-in är otillräckligt. Kräver era regler att alla deployments körs som policygodkända signerade skriptfiler behöver denna väg en implementationsändring. Spara kravet och den misslyckade operationen för support; försvaga inte application control, inaktivera inte skripttillämpning och ändra inte execution policy för att få det att fungera.

Antivirus och EDR

Behåll skanning, AMSI och beteendeövervakning. Granska leverantörens faktiska larm, filhash, signatur, processträd och blockerade operation. Föredra ett avgränsat godkännande av den identifierade filen och berörd enhetsgrupp med gransknings-/utgångsdatum enligt leverantörens produktdokumentation. Bedöm igen vid uppdatering. Ett programgodkännande godkänner inte automatiskt underprocesser, skript, ändringar i certifikatlagret eller tjänsteomstart. Det finns ingen garanti för kompatibilitet med alla antivirus-/EDR-policyer.

Microsoft Defender for Endpoint stöder exempelvis filhashbaserade Allow-indikatorer och certifikatindikatorer. En certifikatindikator omfattar flera filer, så en indikator för en enskild fil är mer avgränsad när den räcker. Funktionerna kräver dokumenterad licens, rättigheter, Defender-konfiguration och enhetsavgränsning; använd leverantörsinstruktionerna nedan. Skanningsundantag i Defender Antivirus är inte samma sak som EDR-godkännande. Undanta inte hela agent-, arbets-, uppdaterings- eller .NET-extraktionsmappar och skapa inte breda processundantag. Andra leverantörer kräver en egen dokumenterad godkännandeprocedur.

Nätverksgodkännande är separat: tillåt den konfigurerade appliancens HTTPS-värd/port (normalt 443), namnuppslagning och, när Cloud används, cloud.sslbrain.com:443; installation från den offentliga hämtningen behöver sslbrain.com:443. Uppdateringar i den granskade koden hämtas från den konfigurerade appliancen över HTTPS. För en agent vars sparade destinationslista endast innehåller Cloud avvisar release 1.4.2 staging av uppdatering, eftersom denna Cloud-uppdateringskälla inte är implementerad; anta inte att Cloud-kommunikation även ger denna uppdateringsväg. Kontroll av signaturtillit/återkallelse kan behöva åtkomst till certifikatutfärdarnas tjänster enligt er nätverkspolicy. Agenten behöver ingen inkommande port. Se Så når agenten appliancen för er anslutningstyp.

Hitta en blockering och registrera vad som testats

Jämför samma tidpunkt och fil/process i agentloggen, MSI-loggen och dessa Windows-kanaler:

Event Viewer-kanal	Vad ni kontrollerar
`Microsoft-Windows-CodeIntegrity/Operational`	3076: skulle blockera i audit; 3077: blockerad vid tillämpning; koppla 3089-signaturdetaljer via ActivityID. 3099 visar en laddad policy.
`Microsoft-Windows-AppLocker/EXE and DLL`	AppLocker 8003: skulle blockera i audit; 8004: blockerad. Kontrollera fil, regel och användar-SID.
`Microsoft-Windows-AppLocker/MSI and Script`	AppLocker 8006/8007: audit/blockering. App Control 8028/8029: skriptvärdens audit-/tillämpningsbeslut; 8038: kopplade signaturdetaljer. Värden avgör begränsning eller blockering. Microsoft dokumenterar att kanalen saknas på Server Core.
`Microsoft-Windows-PowerShell/Operational` eller `PowerShellCore/Operational`	Värdfel och, när aktiverat, script-block-händelser som 4104. PowerShell Core behöver en registrerad event provider innan den kan skriva dessa händelser. Jämför med agentloggens meddelanden om inbyggd värd/fallback.
`Microsoft-Windows-Windows Defender/Operational` och EDR-konsolen	Detektion, karantän, ASR eller annan leverantörsåtgärd; följ instruktionerna för det faktiska larmet.

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 dessa läskommandon med relevanta administratörsrättigheter. En tom kanal eller saknad blockeringshändelse bevisar inte godkännande. Kontrollera effektiv policy, signaturstatus, tjänsteidentitet, beroendefil och exakt misslyckad fas. Script-block-loggar kan innehålla känsliga skript/indata; skydda diagnostikbevis med åtkomstkontroll och ta bort känsliga uppgifter före delning.

Artefaktgranskningen och källsökvägarna ovan kontrollerades den 9-10-2026 mot release 1.4.2. Windows säkerhetsbeteende dokumenteras av Microsoft; exekverings- och uppdateringsdetaljerna kommer från releasens implementation. Inget Windows-runtime-test under App Control, AppLocker, antivirus eller EDR utfördes för denna guide. Registrera OS/build, agentversion, policyer, leverantörsinställningar och resultat av installation, tjänstestart, discovery, deployment, verification och uppdatering i er pilot.