Eikö VPN:n laiteprofiilitarkistus estä pääsyä? Jäljitä ensin raportti
Päätepisteen agentti ilmoittaa terveestä tilasta, mutta sisäinen sovellus avautuu silti. Käy läpi kerääjä, ratkaisu ja esto ja todista sitten hylkäys yhdellä pyynnöllä.
Jos kannettava, jonka virustorjuntatunnisteet lakkasivat päivittymästä viikkoja sitten, voi yhä avata sisäisen sovelluksesi, harvoin käytäntöasiakirja on se, mikä on vialla. Kolmen erillisen järjestelmän on oltava samaa mieltä ennen kuin pääsy evätään: jokin mittaa päätepisteen, jokin muuntaa mittauksen salli tai hylkää -ratkaisuksi ja jokin todella pudottaa liikenteen. Kun vaatimustenvastainen laite silti pääsee sisään, täsmälleen yksi näistä lenkeistä puuttuu tai luottaa todisteisiin, joihin sen ei pitäisi. Alla olevat tarkistukset etenevät siinä järjestyksessä, ja jokaisella on pysäytyskohta.
Esto on viimeinen vaihe, ei ensimmäinen
Todennus ja laitteen tila vastaavat eri kysymyksiin. Onnistunut kirjautuminen todistaa, että tunnistetieto esitettiin; se ei kerro mitään koneella pyörivästä ohjelmistosta, joka sen esitti. Juuri tämä aukko mahdollistaa sen, että kopioitu asiakasprofiili voi siirtää terveeltä näyttävän istunnon epäterveeseen isäntään.
Päätepisteiden vaatimustenmukaisuustyöllä on jo sanasto tälle ketjulle. RFC 5209:n informatiivinen NEA-viitemalli jakaa tehtävän kerääjään, arviointivaiheeseen ja toimeenpanopisteeseen ja sanoo suoraan, että asiakas, joka valehtelee omasta tilastaan, on mallin ulkopuolella. Tämä varaus on tärkeämpi kuin kaavio: luotettu alustamoduuli ei muuta itse raportoitua mittausta tosiasiaksi.
Pidä kerääjä rehellisenä laajuudesta. Sen pitäisi raportoida ne attribuutit, jotka käytäntösi nimeää, laitteella, joka pyytää pääsyä, ja vähän muuta. Jokaisen asennetun paketin listaava inventaariagentti on eri työkalu kuin tilankerääjä, ja ero on samalla sekä säilytys- että tarkkuusongelma. Jos raporttia ei voi sitoa yhteen laitetunnukseen, arvioija arvaa, minkä koneen se juuri hyväksyi.
Punainen tila kojelaudassa ei ole valvontakeino. Kysy, mihin hylätty käyttäjä yhä pääsee: wikiin, tiedostojakoon, tietokannan porttiin? Korjaus tarvitsee yhden kapean pinnan, ja kaikki muu kuuluu eston taakse.
Lue raportti ennen kuin luet säännön
Aloita lähteestä, älä asiakkaan vihreästä merkistä. Windowsissa paikallinen mittaus tulee Defenderiltä tai siltä tuotteelta, joka rekisteröi itsensä Security Centeriin, ja molemmat ovat luettavissa ilman toimittajan konsolia:
Get-MpComputerStatus | Select-Object AMServiceEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct | Select-Object displayName, productStateToinen komento palauttaa kokonaisluvun nimeltä productState. Sen bitit on dokumentoitu löyhästi ja toimittajat paketoi käytössäolon ja ajantasaisuuden liput eri tavoin, joten vahvista se sen sijaan että jäsentäisit sen. Kolmannen osapuolen paketit jättävät myös Security Center -merkinnän asennuksen poiston jälkeen, ja se raportoi ohjelmistosta, jota ei enää ole levyllä.
Ikä on kenttä, jonka ihmiset ohittavat. Allekirjoituksen aikaleima merkitsee jotain vain arvioinnin tekevän koneen kelloa vasten, joten muunna se väliksi sen sijaan että arvioisit sitä silmämääräisesti:
$sig = (Get-MpComputerStatus).AntivirusSignatureLastUpdated
[int](New-TimeSpan -Start $sig -End (Get-Date)).TotalHoursNyt käytännöllä on yksi luettava luku. Jos sääntösi sanoo 72 tuntia, se on luku, jota se käyttää, ja viikon nukkunut kannettava epäonnistuu ilman, että kukaan tulkitsee merkintää. Kirjaa kynnys komennon viereen, sillä ne kaksi ajautuvat erilleen, kun päätepistetyökalu vaihdetaan.
Muunna jokainen laitteen tila kirjalliseksi ratkaisuksi
Useimmat tilaa koskevat kiistat ovat oikeastaan kiistoja tuntemattomasta rivistä. Ratkaise se ennen ensimmäistä tapausta taulukossa, joka nimeää todisteen, ratkaisun ja omistajan, jotta kukaan ei improvisoi yhdyskäytävän konsolissa.
| Evidence the assessor has | Verdict | What it protects against |
|---|---|---|
| Timestamp inside the policy window, protective service running | Admit to normal applications | Nothing yet; the other checks still apply |
| Timestamp older than the window | Deny, admit remediation page only | Signature rollback and dormant laptops |
| Service disabled or reporting off | Deny, escalate to the endpoint owner | An agent reporting stale success |
| No report at all for this session | Treat as deny, never as healthy | Agents that fail open under load |
Alarivi on se, missä tuotteet eroavat. Jotkin yhdyskäytävät hylkäävät yhteyden ja selittävät miksi; toiset päästävät tunnelin pystyyn ja soveltavat rajoitettua käytäntöä; harvat palaavat viimeisimpään tunnettuun hyvään raporttiin. Vain kaksi ensimmäistä ovat puolustettavissa, ja kannattaa testata, kumpaa omasi tekee.
Pidä identiteetti ja lupa omilla raiteillaan. Jokaisen tilatestin läpäisevä kannettava tarvitsee silti sovellukselle oikean inhimillisen valtuutuksen, ja laitevarmenne todistaa avaimen hallussapitoa, ei tiedostojärjestelmän tilaa. Kolmen supistaminen yhdeksi boolean-arvoksi on se tapa, jolla tukipalvelun tili saa pysyvän pääsyn tuotantoon.
Tarkista toimeenpanopolku pyynnöllä, älä kojelaudalla
Toimeenpano on pyynnön ominaisuus, joten mittaa sitä yhdellä. Laita vaatimustenvastainen kone tunneliin ja tee kutsu, jonka todellinen käyttäjä tekisi:
curl -sS -o /dev/null -w '%{http_code}
' --max-time 5 https://app.internal.example/healthVastaus 200 laitteelta, joka pitäisi estää, tarkoittaa, että päätös ei koskaan saavuttanut datapolkua. Kaksi tavallista syytä: käytäntö on kytketty ryhmään, johon testitili ei koskaan liittynyt, tai sovellus on tavoitettavissa reitillä, jota VPN ei omista.
Tarkista ensin reititysoletus. Jos sisäinen nimi ratkeaa osoitteeseen, johon asiakas pääsee jo paikallisen LAN:n kautta, tunneli on merkityksetön eikä mitään käytäntöä sovelleta. Vertaa sitä osoitetta reittiin, jota yhdyskäytävä työntää. OpenVPN:ssä asiakaskohtainen käytäntö elää tiedostoissa, jotka on avaimitettu yleisnimellä, joten se on helppo tarkastaa:
ls /etc/openvpn/ccd/
cat /etc/openvpn/ccd/laptop-17Tiedosto, joka sisältää disable, katkaisee kyseisen asiakkaan kokonaan, kun taas push "route ..."-rivi kaventaa sitä, mihin se pääsee. Molemmat ovat toimeenpanoa, ja molemmat näkyvät jokaiselle, joka selvittää raporttia.
Testaa neljä tapausta yhdellä testitilillä
Viimeinen tarkistus on pieni matriisi, ei onnellinen polku. Aja yksi testitili neljän tilan läpi: ajantasainen, vanhentunut allekirjoitus, suojaus pois päältä, agenttia ei asennettu. Kirjaa kustakin ratkaisu arviointilokiin, HTTP-tila, jonka sovellus palauttaa, ja latautuiko korjaussivu.
foreach ($case in 'current', 'stale', 'disabled', 'absent') {
Get-MpComputerStatus | Select-Object AMServiceEnabled, AntivirusSignatureLastUpdated
curl.exe -sS -o NUL -w "%{http_code}
" --max-time 5 https://app.internal.example/health
}Kaksi yksityiskohtaa on helppo jättää huomaamatta. Ensin toisto: raporttia, joka tallennettiin koneen ollessa terve, ei pidä hyväksyä saman laitteen myöhemmälle istunnolle, joten etsi nykyiseen yhteyteen sidottu aikaleima. Sitten poisto: agentin asennuksen poiston pitäisi tuottaa sama hylkäys kuin vanhentunut raportti, ei puhdas läpäisy, ja juuri sitä tapausta ei useimmiten koskaan testata.
Kun matriisi vastaa taulukkoa, luovuta kolme asiaa seuraavalle yhdyskäytävän ylläpitäjälle: komennot, kynnyksen ja neljä odotettua tulosta. Juuri se luovutus on todellinen tuotos, koska vain käytäntöasiakirjassa elävä tilasuunnittelu ajautuu ensimmäisen kerran, kun päätepistetyökalu muuttaa raportointikenttäänsä.