Какво може да означава правило за достъп по име на хост на всеки мрежов слой
Име на услуга може да се налага на ниво DNS, браузър, прокси или защитна стена. Изберете слоя, който вижда идентичността, която искате да управлявате.
Трима души искат едно и също с едни и същи думи: блокиране на достъпа до едно име на услуга. Единият има предвид, че браузърът не трябва да отваря сайта, друг — че настолен гласов клиент не трябва да достига до своя сървър, а третият — че група изпълнители не трябва да използва определено вътрешно приложение. Изречението е идентично, а механизмите за налагане почти нямат нищо общо.
Изберете слоя по идентификатора, който той наистина вижда, а след това по клиентите, които покрива. Започването от команда на защитна стена, която вече познавате, е начинът, по който правилата в крайна сметка не блокират нищо или блокират твърде много.
Името не е идентичност, която всеки слой може да провери
Netfilter и подобните филтри на пакети виждат адреси, протоколи и портове. Те не виждат имена на хостове и докато пакетът ги достигне, името вече е разрешено. Правило, написано срещу адрес, е правило за този адрес, независимо какво име е въвел потребителят, за да го достигне.
DNS политиката стои по-рано по пътя и вижда заявката, която е различен обект от следващата връзка. Тя управлява отговорите, които връща контролиран резолвер, а не връзките, които вече са били отворени, и не клиентите, конфигурирани да заобикалят този резолвер. Разрешеният адрес също може да се промени между прегледа на политиката и следващата заявка, затова DNS отговорът не е дълготрайно изявление за оторизация.
По-високите слоеве виждат повече контекст и покриват по-малко клиенти. Тази размяна е цялата тема и тя обяснява защо нито един ред от таблицата никога не е правилният отговор. Изберете реда, който вижда идентификатора, за който всъщност се отнася вашата политика. След това приемете покритието, което този ред предполага.
Какво може да идентифицира всеки слой
Четете таблицата от средната колона навън: идентификаторът, който слоят вижда, определя политиката, която той може честно да наложи.
| Layer | Identifier it sees | What it cannot see |
|---|---|---|
| Packet filter | address, protocol, port | the name, or which other services share that address |
| DNS policy | the queried name and the answer handed back | connections made by clients that ignore the resolver |
| Managed browser | supported URL patterns on managed profiles | non-browser clients, or unmanaged devices |
| CONNECT proxy | host and port for tunnelled requests | the path inside an encrypted request |
Слоят принадлежи на политиката само когато идентификаторът, който вижда, съвпада с идентификатора, който управлявате. Таблицата също обяснява защо правило, написано на един слой, рядко се пренася на друг, без отново да се реши какво защитава.
Къде очевидното правило се проваля
Правилото за адрес е точно правилно за услуга с отделен адрес, който контролирате, и тази собственост трябва да бъде записана в политиката. То е точно погрешно за всичко зад споделен адрес за доставяне на съдържание, където същото правило засяга несвързани услуги и обновеният DNS отговор не превръща правилото в оторизация по име на хост.
Политиката за управляван браузър изразява уеб ограничение по-директно от копиран списък с адреси, но се прилага към браузърите и профилите, които системата за управление контролира.
Това правило за браузър не прави нищо за гласов клиент, който изпраща UDP към друг хост, а шаблоните му се определят от този продукт, а не от конвенции за шаблони, заимствани от другаде. CONNECT проксито също получава хост и порт за тунелирана заявка и не може да прочете пътя вътре в криптираната сесия. Проектирайте правилото около това, което протоколът разкрива. След това запишете какво остава непокрито, защото именно тази празнина ще бъде източникът на следващата заявка.
Избирайте по клиентите, а не по командата
Попитайте кои клиенти политиката трябва да покрива и кои може да пропусне. Политиката за управляван браузър покрива това, което системата за управление достига, и спира на границата на браузъра. Политиката на резолвера покрива всичко, което използва вашия резолвер, което е по-широк набор, и се проваля открито за всеки, който не го използва.
За услуга, която управлявате, оторизацията в приложението е по-силна от всяка мрежова граница, защото следва акаунта, а не пътя. VPN маршрутът е достижимост и нищо повече: възможността да изпратите пакет до услуга не е разрешение да я използвате. Когато идентификаторът, който има значение, е потребител или разрешение за канал, наложете го там и третирайте мрежовото правило като втори слой.
Напишете правилото по отношение на ресурса
Защитима политика назовава ресурса, идентичностите, приложенията в обхвата и пътя, който ги носи, включително двете семейства адреси в употреба. Тя също посочва какво се случва със споделената инфраструктура, която правилото ще засегне случайно.
Тази формулировка създава решение, което някой може да одитира по-късно. Правило, оправдано от днешния разрешен адрес, създава инцидент при първата промяна на адреса и никой няма да може да обясни защо блокирането някога е било правилно.