Три хопа, един хост: как да броим реалните зависимости за поверителност

Вторият хоп се вдигна по график, а диаграмата ви все още показва три отделни доставчика. После пристигат фактурите и две от тях посочват една и съща хостинг компания, същият регистратор държи трите домейна, а всеки акаунт се възстановява към една пощенска кутия, която притежавате. В конфигурацията на тунела нищо не е счупено. Дизайнът просто никога не е броил зависимостите под хоповете, а броят на хоповете описва пътя на трафика, а не броя на страните, които могат да действат по него.

Симптомът се появява във фактурите, не в логовете

Няма да намерите това в лог на тунела, защото тунелът прави точно това, което сте конфигурирали. Доказателствата живеят в публични регистри и настройки на акаунти: имена на организации в whois, които съвпадат между крайните точки, еднакви сървъри за имена, споделен адрес на регистрант, един метод на плащане, един контролен панел. Всяка от тези следи подсказва, че два слоя, които трябва да се провалят независимо, може да се провалят заедно.

Нито една от тези следи не доказва, че някоя отделна страна може да чете трафика ви. Това, което те намаляват, е броят на независимите решения, които трябва да са грешни, преди два защитни слоя да бъдат компрометирани от едно и също събитие.

Сравнете записите, които наистина виждате, и запишете какво сте сравнили. Потърсете организацията на всеки адрес на крайна точка, избройте сървърите за имена за всеки домейн и отворете настройките за възстановяване на всеки акаунт във веригата. Когато две стойности съвпадат, отбележете дали съвпадението е за собственост, за операции или само за фронтенд на реселер. Това са различни констатации и третирането им като една е начинът, по който прегледът на зависимостите се превръща в догадки.

Начертайте логическия път, после картата на зависимостите

Нужни са две диаграми и повечето хора чертаят само първата. Логическият път показва къде завършва всеки защитен слой и какво може да наблюдава тази крайна точка. Картата на зависимостите показва кой управлява и администрира всяка от тези крайни точки, а това е напълно отделен набор от имена.

Оценявайте всеки ред, вместо да го попълвате. „Известно“ означава, че сте видели запис, който го твърди; „изведено“ означава, че едно наблюдение го подкрепя, без да го решава; „неизвестно“ означава, че нищо не е намерено. Споделена хостинг марка е извод за споделена инфраструктура, а не твърдение за споделена клиентска база. Не превръщайте тихо извод в известен факт само защото е удобно за очакваното заключение.

Празният ред е констатация сама по себе си. Той ви казва кой факт би променил решението, ако го научите, и това е по-полезно от още един абзац за това какво би могъл да направи изтънчен противник.

Номерът на AS отговаря само на въпрос за маршрутизация

Автономната система е концепция за администрация на маршрутизацията, набор от адреси, представени на други мрежи като един последователен изглед за маршрутизация. Затова различните номера на AS не казват нищо категорично за корпоративната собственост, отделния персонал или независимия правен контрол. Обратната грешка е също толкова разпространена: две крайни точки в една AS не са автоматично случай на една страна, идентифицираща конкретен потребител.

Ако искате числата, извлечете ги, вместо да ги предполагате. Адресът по-долу е заместител, а флагът кара инструмента да маркира всеки хоп с AS, която го обявява.

mtr --aslookup --report --report-cycles 5 203.0.113.9

Третирайте този изход като измерване на маршрутизацията, а не на собствеността или на пълния път на трафика. Мрежата за достъп, от която започвате, и транзитните зависимости между крайните точки са отделни въпроси, на които адресите на крайните точки не могат да отговорят. Когато маршрут или избор на релей не може да се наблюдава от мястото, където се намирате, маркирайте го като неизвестен, вместо да внасяте общо твърдение за това как конкретна мрежа избира пътища днес. Ненаблюдаваното не е същото като ненаблюдаемото, но също не е доказателство.

Назовете наблюдението, преди да назовете риска

Три констатации се смесват в повечето прегледи на зависимостите и разделянето им е по-голямата част от работата. Пасивната видимост на криптиран трафик е една констатация. Споделеният административен достъп е друга, защото предполага действие, а не гледка. Свързването на акаунти е трета, защото свързва идентичности, без да дава никакъв технически достъп.

Насоките за поверителност в RFC 6973 дават работеща форма за това: избройте какво научава всеки субект, после попитайте как това може да се комбинира с информация, съхранявана другаде. Две точки по пътя, наблюдаващи сходни модели на трафик, могат да обосноват притеснение за корелация, но не ви дават измерена вероятност, че някой е идентифициран. Запишете притеснението, после запишете наблюдението, което би го потвърдило.

Върнете се към верига от две тунелни услуги и нает прокси сървър. Ако административните идентификационни данни на проксито споделят акаунт за възстановяване с един тунелен сървър, един административен компромис може да пресече двете граници. Ако единственото застъпване е, че хостинг компания управлява и двете машини, прегледът трябва да посочи какви правомощия има тази компания и коя информация остава защитена. Същите три хопа, различна констатация.

Регистърът не е сертификат за анонимност и никога няма да бъде. Стойността му е по-тясна и по-практична: показва къде независимостта е установена, къде е предположена и кой един неизвестен ред би преместил решението. Изберете този ред следващ и оставете останалата част от диаграмата на мира, докато не получите отговор за него.