Ваш VPN кључ је читљив свима: шта поправити

Први знак је обично упозорење, а не квар. Клијент одбија да учита кључ јер је датотека читљива групи или свима, или безбедносна провера пронађе client.key са режимом 644 у директоријуму профила у ком су и извезени пакети. Ништа још није отказало, и управо зато се упозорење одбацује. Кључ ради, тунел се подиже, а датотеку може да чита сваки налог на машини.

Симптом је упозорење о дозволама, а не испад

На Unix-оликом систему приватни кључ треба да буде читљив само налогу који покреће сервис. Режим 600 са исправним власником је уобичајен распоред. Режим 644 значи да сваки локални корисник може да копира кључ, а на заједничком build хосту то је стварна публика.

Клијенти који то проверавају чине вам услугу. Они који не проверавају нису доказ да је датотека безбедна, а успешна веза не каже ништа о томе ко још може да чита материјал који ју је омогућио. Третирајте упозорење као цео налаз. Оно је тачно и стигло је пре него што је ико копирао датотеку.

Ускладите режим са идентитетом сервиса

Приступ само власнику одговара кључу који тај власник користи. Сервис са намерно заједничком групом може да захтева други контролисани распоред, попут читања групе на кључу који поседује сервисни налог. Слепо постављање једног бројчаног режима на све датотеке квари подржане клијенте, а 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 објашњава шта значи сваки бит режима, што вреди знати пре него што следећа провера затражи да оправдате изабрани број.