Ваш ключ VPN чытае кожны: што выправіць

Першы прыкмета — звычайна папярэджанне, а не збой. Кліент адмаўляецца загрузіць ключ, бо файл даступны для чытання групе або ўсім, або праверка бяспекі знаходзіць client.key з рэжымам 644 у каталогу профілю, дзе таксама ляжаць экспартаваныя пакеты. Пакуль нічога не зламалася, і менавіта таму папярэджанне ігнаруюць. Ключ працуе, тунель падымаецца, а файл чытае кожны ўліковы запіс на машыне.

Сімптом — папярэджанне аб правах, а не аварыя

У Unix-падобнай сістэме прыватны ключ павінен чытацца толькі ўліковым запісам, які запускае службу. Рэжым 600 з правільным уладальнікам — звычайная справа. Рэжым 644 азначае, што кожны лакальны карыстальнік можа скапіяваць ключ, а на агульным зборачным хосце гэта рэальная аўдыторыя.

Кліенты, якія гэта правяраюць, робяць вам паслугу. Тыя, што не правяраюць, не з'яўляюцца доказам бяспекі файла, а паспяховае злучэнне нічога не кажа пра тых, хто яшчэ можа чытаць матэрыял, які зрабіў яго магчымым. Успрымайце папярэджанне як увесь вынік. Яно дакладнае і прыйшло да таго, як хтосьці скапіяваў файл.

Падбярыце рэжым пад ідэнтычнасць службы

Доступ толькі ўладальніку падыходзіць для ключа, які выкарыстоўвае гэты ўладальнік. Службе з наўмысна агульнай групай можа спатрэбіцца іншая кантраляваная схема, напрыклад чытанне групай ключа, якім валодае службовы ўліковы запіс. Сляпое прызначэнне ўсім файлам аднаго лікавага рэжыму ламае падтрымліваныя кліенты, а chmod -R 777 не вырашае нічога.

Праверце ўладальніка і службовы ўліковы запіс, перш чым нешта змяняць. Публічныя сертыфікаты CA і прыватныя ключы ідэнтычнасці маюць розныя патрабаванні да сакрэтнасці, нават калі ляжаць у адным каталогу, таму рэкурсіўны рэжым на ўсю папку ставіцца да іх як да аднаго аб'екта.

ls -l /etc/openvpn/client/
stat -c '%U %G %a %n' /etc/openvpn/client/*.key
id openvpn

На іншых платформах выкарыстоўвайце дакументаванае сховішча ключоў або мадэль кантролю доступу, а не перакладайце Unix-рэжымы ў здагадку. Імя файла, якое заканчваецца на private, — гэта этыкетка, а не механізм прымусу.

Знайдзіце копіі, якія не ахоплівае рэжым

Рэдактары, архівы рэзервовых копій, экспартаваныя профілі і часовыя пакеты могуць захоўваць тую ж ідэнтычнасць. Абараняйце гэтыя копіі паводле іх змесціва, бо ўшчыльненне арыгінальнага файла нічога не робіць для копіі ў архіве мінулага месяца.

Парольная фраза на файле ключа карысная для захаваных матэрыялаў і не апраўдвае публікацыю зашыфраванага файла побач з яго паролем. Дазволы абараняюць бягучы аб'ект файлавай сістэмы; яны нічога не кажуць пра ўліковыя даныя, ужо скапіяваныя ў іншае месца.

Шукайце копіі, перш чым абвясціць задачу выкананай: grep -rl радок загалоўка ключа ў верагодных каталогах і паглядзіце на выключэнні рэзервовага капіравання. Вынік звычайна цікавейшы за файл, з якога вы пачалі.

Пасля выпраўлення праверце і змяніце ключ

Праверце, што патрэбная служба ўсё яшчэ аўтэнтыфікуецца, затым пераканайцеся, што ніякі непатрэбны ўліковы запіс не атрымаў доступу. Абмяжуйце дыягнастычны вывад метаданымі, бо друкаваць ключ не трэба, каб даказаць чытальнасць файла а гэта трапляе ў журнал.

Калі ключ быў выкрыты, ушчыльніце рэжым, затым заменіце ўліковыя даныя і адклічце старыя. Спецыфікацыя POSIX chmod тлумачыць значэнне кожнага біта рэжыму, і гэта варта ведаць перад наступным аўдытам, які папросіць абгрунтаваць абраны лік.