Проверката на състоянието през VPN не блокира? Проследете първо доклада
Агентът на крайната точка съобщава за здраво състояние, а вътрешното приложение все още се отваря. Преминете през събирача, присъдата и блокирането, после докажете отказа с една заявка.
Ако лаптоп, чиито антивирусни сигнатури са спрели да се обновяват преди седмици, все още може да отвори вътрешното ви приложение, документът с правилата рядко е това, което не е наред. Три отделни системи трябва да се съгласят, преди достъпът да бъде отказан: нещо измерва крайната точка, нещо превръща това измерване в присъда за разрешаване или отказ, и нещо действително изхвърля трафика. Когато несъответстващо устройство все пак влезе, точно една от тези връзки липсва или вярва на доказателства, на които не би трябвало. Проверките по-долу вървят в този ред и всяка има точка за спиране.
Блокирането е последната стъпка, не първата
Удостоверяването и състоянието отговарят на различни въпроси. Успешният вход доказва, че е представено удостоверение; той не казва нищо за софтуера, който работи на машината, представила го. Именно тази разлика позволява на копиран клиентски профил да пренесе изглеждаща здрава сесия върху нездрав хост.
Работата по съответствие на крайните точки вече има речник за тази верига. Референтният модел NEA в RFC 5209 разделя задачата на събирач, стъпка за оценка и точка за налагане и казва направо, че клиент, който лъже за собственото си състояние, е извън модела. Тази уговорка е по-важна от диаграмата: довереният платформен модул не превръща самоотчетено измерване в факт.
Пазете събирача честен относно обхвата. Той трябва да докладва атрибутите, които вашата политика назовава, на устройството, което иска достъп, и малко друго. Агентът за инвентаризация, който изброява всеки инсталиран пакет, е различен инструмент от събирач на състояние и разликата е едновременно проблем със съхранението и с точността. Ако докладът не може да бъде свързан с една идентичност на устройство, оценителят гадае коя машина току-що е допуснал.
Табло с червен статус не е контрол. Питайте какво все още може да достигне отказан потребител: уикито, файловото споделяне, порта на базата данни? Поправката изисква една тясна повърхност, а всичко останало принадлежи зад блока.
Прочетете доклада, преди да прочетете правилото
Започнете от източника, а не от зелената отметка на клиента. В Windows локалното измерване идва от Defender или от продукта, който се е регистрирал в Security Center, и двете се четат без конзола на доставчик:
Get-MpComputerStatus | Select-Object AMServiceEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct | Select-Object displayName, productStateВтората команда връща цяло число с име productState. Битовете му са документирани свободно и доставчиците опаковат флаговете за включване и актуалност по различен начин, затова го потвърждавайте, вместо да го разчитате. Страничните пакети също оставят записа в Security Center след деинсталиране и той докладва за софтуер, който вече не е на диска.
Възрастта е полето, което хората пропускат. Времевият печат на сигнатура има смисъл само спрямо часовника на машината, която прави оценката, затова го превърнете в интервал, вместо да го преценявате на око:
$sig = (Get-MpComputerStatus).AntivirusSignatureLastUpdated
[int](New-TimeSpan -Start $sig -End (Get-Date)).TotalHoursСега политиката има едно число за четене. Ако правилото ви казва 72 часа, това е числото, което то използва, и лаптоп, спал седмица, се проваля, без някой да тълкува етикет. Запишете прага до командата, защото двете се разминават, когато инструментът на крайната точка бъде сменен.
Превърнете всяко състояние на устройство в писмена присъда
Повечето спорове за състоянието всъщност са спорове за неизвестния ред. Решете го преди първия инцидент, в таблица, която назовава доказателството, присъдата и собственика, така че никой да не импровизира при конзолата на шлюза.
| 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 |
Долният ред е мястото, където продуктите се различават. Някои шлюзове отказват връзката и обясняват защо; други пускат тунела и прилагат ограничена политика; малцина се връщат към последния известен добър доклад. Само първите две са защитими и си струва да проверите кое прави вашият.
Пазете идентичността и разрешението в собствени ленти. Лаптоп, който минава всеки тест за състояние, все още се нуждае от правилно човешко упълномощаване за приложението, а сертификатът на устройството доказва притежание на ключ, а не състоянието на файловата система. Събирането на трите в един boolean е начинът, по който акаунт на помощния център получава постоянен достъп до продукцията.
Проверете пътя на налагането със заявка, не с табло
Налагането е свойство на заявката, затова го измерете с една. Поставете несъответстваща машина на тунела и направете повикването, което би направил реален потребител:
curl -sS -o /dev/null -w '%{http_code}
' --max-time 5 https://app.internal.example/healthОтговор 200 от устройство, което би трябвало да е блокирано, означава, че решението никога не е достигнало пътя на данните. Две обичайни причини: политиката е прикачена към група, към която тестовият акаунт не се е присъединил, или приложението е достъпно през маршрут, който VPN не притежава.
Проверете първо допускането за маршрутизиране. Ако вътрешното име се разрешава до адрес, който клиентът вече достига през локалната LAN, тунелът е без значение и никаква политика няма да се приложи. Сравнете този адрес с маршрута, който шлюзът избутва. На OpenVPN политиката за всеки клиент живее във файлове, ключовани по общо име, така че е лесно да се инспектира:
ls /etc/openvpn/ccd/
cat /etc/openvpn/ccd/laptop-17Файл, съдържащ disable, напълно изключва този клиент, докато ред push "route ..." стеснява какво може да достигне. И двете са налагане и двете са видими за всеки, който отстранява грешки по доклада.
Тествайте четирите случая на един тестов акаунт
Последната проверка е малка матрица, а не щастлив път. Прекарайте един тестов акаунт през четири състояния: актуално, изтекла сигнатура, защита изключена, агент не е инсталиран. За всяко запишете присъдата в журнала за оценка, HTTP статуса, който приложението връща, и дали страницата за поправка се е заредила.
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
}Два детайла лесно се пропускат. Първо повторението: доклад, заснет, докато машината е била здрава, не бива да се приема за по-късна сесия на същото устройство, затова търсете времеви печат, обвързан с текущата връзка. След това премахването: деинсталирането на агента трябва да даде същия отказ като остарял доклад, а не чисто преминаване, и точно този случай най-често никога не се тества.
Когато матрицата съвпадне с таблицата, предайте три неща на този, който ще управлява шлюза след вас: командите, прага и четирите очаквани изхода. Точно това предаване е истинският резултат, защото дизайн на състоянието, който живее само в документ с правила, се размества първия път, когато инструментът на крайната точка смени полето си за докладване.