Поврзување на RADIUS со OpenVPN: приклучок или скрипт-кука?

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

Мит: приклучокот е поддржаната патека

Приклучокот е заеднички објект вчитан во процесот на OpenVPN, затоа мора да одговара на интерфејсот што тој процес го изложува. Сборките се менуваат, пакувањето се менува, а библиотека собрана за постар интерфејс едноставно одбива да се вчита. Ништо во серверската конфигурација не може да го премости тој јаз, затоа советите „само инсталирај radiusplugin“ завршуваат со сервер што не стартува.

Скрипт-куката наместо тоа стои надвор од процесот. OpenVPN извршува програма, ѝ ги дава акредитивите и чита пресуда назад. Токму тоа одвојување ѝ овозможува да преживее надградби, а исто така ја прави ваша одговорност на начин на кој приклучокот никогаш не бил.

Ниту еден пристап не е побезбеден по својата конструкција. Едниот извршува туѓ код во демонот; другиот го извршува вашиот код покрај него со акредитивите во рака. Вистинското прашање е кој од тие два ризика навистина можете да го управувате.

Што поврзуваше приклучокот

Приклучокот носеше сопствена конфигурациска датотека со RADIUS домаќин, заедничка тајна, број обиди и временско ограничување, а серверската конфигурација го наведуваше со еден ред. Ракувањето со акредитивите остануваше во серверскиот процес, што значеше дека лозинката никогаш не премина граница на процес што администраторот требаше да ја обезбеди.

Цената беше поврзаноста. Секоја надградба на OpenVPN ризикуваше некомпатибилен интерфејс, а секоја дистрибуција што пакетот го преработуваше ризикуваше да создаде библиотека што повеќе не одговара. Кога тоа ќе се случи, дефектот е гласен и веднаш, и тоа е единствената милост на дизајнот.

Ако таков приклучок се уште се вчитува на вашата сборка, тој може да биде помалата оперативна површина. Потврдете за кој интерфејс е изграден, држете го прикован за сборката што сте ја тестирале и третирајте секоја надградба како промена што бара целосен тест за најавување, а не како рутинско ажурирање на пакетот.

На што всушност се потпира скрипт-куката

Куката се конфигурира со auth-user-pass-verify и механизам за доставување: променливи на околината или привремена датотека. Во формата со околина OpenVPN бара script-security 3, документираното ниво што дозволува изложување на лозинката на скрипти. Тоа ниво е намерно слабеење на стандардната поставка и треба да се третира како дозвола со приложено образложение.

Се што ќе допре скриптата ја наследува таа доверба. Мора да биде во сопственост на root, да не биде запишлива за групата или другите, да се наведува со апсолутна патека и да биде без место каде недоверлива вредност стигнува до школка. Ставете ја секоја променлива во наводници, одбијте неочекувани знаци и никогаш не градете команда од даденото корисничко име. Скрипта што работи како root при секој обид за најава заслужува еден преглед токму поради тие четири својства.

ls -l /usr/local/sbin/radius-auth.sh
stat -c '%U %a' /usr/local/sbin/radius-auth.sh

Формата со доставување преку датотека го избегнува проблемот со наследување на околината и ги предава акредитивите на скриптата преку привремена датотека со ограничени права. Ако вашиот клиент го поддржува тоа, тоа е обично подобрата стандардна поставка, иако додава уште еден објект за чистење при неуспех.

Излезните кодови одлучуваат дали ќе пропаднете отворено

Излезниот статус на скриптата е пресудата: нула прифаќа, не-нула одбива. Моделот што создава проблеми е школка-скрипта што прифаќа само кога одговорот од RADIUS содржи определен токен за прифаќање и враќа неуспех за се друго, бидејќи тоа спојува три различни настани во еден одговор. Погрешна лозинка, недостапен сервер и деформиран одговор сите стануваат исто одбивање.

Одвојте ги тие случаи во скриптата дури и ако куката може да врати само прифаќање или одбивање. Запишете го резултатот од задниот дел одделно, алармирајте за временски ограничувања и транспортни грешки и направете јасно во мониторингот кога автентикацијата пропаѓа затоа што услугата е падната, а не затоа што корисниците погрешно пишуваат.

Две навики го држат остатокот разумен. Ако RADIUS е авторитет, треба да биде единственото место каде се проверува лозинка, бидејќи сенка-табела создава два одговори на исто прашање, а вториот е нападна површина што никој не ја набљудува. И запомнете дека куката се повикува повторно при секој обид, па бавна скрипта со нетрпелив клиент станува засилувач за погодување лозинки, освен ако не додадете одложување или политика на страната на RADIUS.

Од што се откажувате кога сертификатот исчезнува

Многу распоредувања од овој облик целосно го исклучуваат проверувањето на клиентскиот сертификат, оставајќи корисничко име и лозинка како целото тврдење на клиентот. Она што исчезнува со таа поставка е идентитетот заснован на сертификат. Каналот останува шифриран, но единственото што го именува клиентот е пресудата на RADIUS. Се низводно што порано се потпираше на субјектот на сертификатот сега мора да се потпира на корисничкото име.

Задржете ја заштитата на контролниот канал за неавтентифициран партнер да не може да го испитува или поплавува ракувањето, и користете username-as-common-name кога конфигурацијата по корисник зависи од заедничкото име. Управуваните порти често го решаваат ова поинаку, завршувајќи ја автентикацијата со сертификат на порта што зборува EAP-TLS со RADIUS, и во тој случај ниту една од овие серверски директиви не важи. Копирајте го моделот што го документира вашата платформа, а не оној од соседен производ. Директивите што се важни се разликуваат доволно што нивното мешање дава конфигурација што се парсира и потоа не автентифицира никого.