VPN şlüzünüz ələ keçirilib: əslində nə açıqdır

VPN şlüzü qoruduğu tunelin sonunda yerləşir, yəni o şifrələməni ötürmür, onu terminasiya edir. Əgər hücumçu hosta nəzarət edirsə, tunel kənardan sağlam görünməyə davam edir, ortadakı maşın isə artıq etibarlı deyil. Faydalı sual hər şeyin deşifrə olunub-olunmaması deyil. Sual odur ki, o host nə görə bilirdi, nəyə çata bilirdi və hansı sirlər həqiqətən orada saxlanılırdı. Bu üç cavab bir-birindən çox fərqlənir və cavab tədbirləri də onlarla birlikdə dəyişir.

Şlüz tuneli terminasiya edir, ona görə də içini görür

VPN-də şifrələmə hopbhop, şlüz isə həmin hopdur. O, xarici qatı çıxarır, siyasət tətbiq edir və daxili paketi yönləndirir, buna görə də daşınan hər paket hansısa anda o hostun yaddaşında oxunaqlı formada olur. Bu, qüsur deyil, dizayndır. Buna görə də şlüzün ələ keçirilməsi tunelin kriptoqrafiyasının ələ keçirilməsindən fərqli hadisədir.

Hücumçunun ilk qazandığı şey mövqedir: daşınan trafiki müşahidə etmək, yönləndirməni dəyişmək və ya backend əvəzinə cavab vermək imkanı. Bundan sonra nə qazandığı hostdan asılıdır və burada insanlar həddindən artıq qiymətləndirir. Tək şlüzə çıxış brauzerin TLS sessiya açarlarını vermir, çünki onlar heç vaxt şlüzdə olmayıb.

Eyni ölçüdə olmayan üç məruz qalma

Sualı daşınan trafik, çatıla bilən sistemlər və saxlanan sirlər üzrə bölün, sonra hər birinə ayrıca cavab verin.

Ortadakı sətir atlanan sətirdir. Şlüzün adətən şəxsi şəbəkələrə marşrutu və backendlərin artıq etibar etdiyi mənbə ünvanı olur, ona görə də maraqlı sual həmin backendlərin o ünvandan nəyə icazə verdiyidir. Dar müştəri çıxış siyasəti yaxşı nəzarətdir, lakin hostdakı hücumçu adi müştərinin istifadə edəcəyi interfeyslə məhdudlaşmır.

Alt sətir hadisənin nə qədər davam edəcəyini müəyyən edir. Server açarı ilə CA açarının təsir radiusu tamamilə fərqlidir; yerli admin hesabı ilə yalnız oxuna bilən monitorinq tokeni də belədir.

Tunelin içindəki HTTPS yenə HTTPS-dir

Tətbiq TLS-i VPN şlüzündə deyil, tətbiqdə terminasiya olunur, buna görə də ələ keçirilmiş şlüz həmin axınlar üçün şifrəli mətn görür. Bu, hücumçunun əldə etdiklərinə real məhdudiyyətdir və bunu açıq demək lazımdır, çünki əks iddia panika və pis qərarlar yayır. İki şərt bunu pozur. Yolda etibarlı sertifikat daşıyan yoxlama komponenti varsa, şlüz dizayn üzrə açıq mətn görə bilər. Tətbiqin son nöqtəsi özü ələ keçirilibsə, tunelin əhəmiyyəti qalmır.

Deməli, onların nə gördüyünə dair cavab şərtlidir və hökm kimi elan edilmək əvəzinə şərtlər kimi yazılmalıdır.

Yenidən etibar etməzdən əvvəl nə dəyişməlidir

Hostu yenidən qurmaq zəruridir və nadir hallarda kifayətdir. Hələ də idarəetmə hesabı, yerləşdirmə etimadnaməsi və ya imzalama açarı saxlayan hücumçu hostu istədiyi kimi geri qaytara bilər. Bərpa ələ keçirilmiş maşından asılı olmayan inzibati yoldan başlamalıdır.

Nəyi dəyişdirəcəyinizə qərar verməzdən əvvəl orada nə olduğunu inventarlaşdırın. Açarlar, xidmət hesabları, API tokenləri, yerli istifadəçilər, planlaşdırılmış işlər, etibar əlaqələri və yerləşdirmə boru xətti namizəddir və hər birinin təsdiqləməli olduğu sahibi var.

ss -lntup
getent passwd
crontab -l
ip route show table all

Bu siyahı hostun nə təklif etdiyini və hara çata bildiyini görməyin ən sürətli yoludur. Əvvəlcə sübutları qoruyun, cavab sahibinin prosesinə uyğun olaraq, çünki yenidənqurma məhz istintaqın ehtiyac duyduğu şeyi məhv edir. NIST SP 800-61 Reviziya 3 hazırlıq, aşkarlama, cavab və bərpanı yenidən başlatma təlimatı kimi deyil, vahid risk prosesinin hissələri kimi qəbul edir.

Növbətini daha ucuz edən sərhədlər

Dörd sərhədi ehtiyac duymazdan əvvəl qurmağa dəyər. Şlüzdən keçməyən müstəqil bərpa yolu saxlayın. İmzalama səlahiyyətini trafik xidmət edən hostdan ayrı saxlayın. Şlüzün çata bildiklərini məhdudlaşdırın ki, ələ keçirilmiş şlüz avtomatik olaraq ələ keçirilmiş idarəetmə şəbəkəsi olmasın. Və hər etimadnamənin kimə aid olduğunu qeyd edin ki, rotasiya arxeologiya layihəsi deyil, bir telefon zəngi olsun.

Bunların heç biri ələ keçirilmənin qarşısını almır. Onlar həddi müəyyən edir və pis həftə ilə pis rüb arasındakı fərqi yaradır.