Свързване на RADIUS с OpenVPN: плъгин или скрипт-кука?

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

Митът: плъгинът е поддържаният път

Плъгинът е споделен обект, зареден в процеса на OpenVPN, затова трябва да съвпада с интерфейса, който този процес предоставя. Сборките се променят, пакетирането се променя и библиотека, компилирана за по-стар интерфейс, просто отказва да се зареди. Нищо в сървърната конфигурация не може да преодолее тази разлика, затова съветът "просто инсталирайте radiusplugin" завършва със сървър, който не стартира.

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

Нито един от двата подхода не е по-сигурен по своята същност. Единият изпълнява чужд код вътре в демона; другият изпълнява вашия код до него с идентификационните данни в ръка. Правилният въпрос е кой от тези два риска всъщност можете да управлявате.

Какво свързваше плъгинът

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

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

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

На какво всъщност се доверява скрипт-куката

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

Всичко, до което скриптът се докосва, наследява това доверие. Той трябва да е собственост на root, да не е записваем за групата или другите, да е посочен с абсолютен път и да е свободен от място, където недоверена стойност достига до shell. Ограждайте всяка променлива в кавички, отхвърляйте неочаквани символи и никога не изграждайте команда от подаденото потребителско име. Скрипт, който работи като root при всеки опит за вход, заслужава едно преглеждане точно заради тези четири свойства.

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

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

Кодовете за изход решават дали ще се провалите отворено

Изходният статус на скрипта е присъдата: нула приема, ненула отхвърля. Моделът, който създава проблеми, е shell скрипт, който приема само когато отговорът на RADIUS съдържа определен токен за приемане и връща отказ за всичко останало, защото това сгъва три различни събития в един отговор. Грешна парола, недостъпен сървър и деформиран отговор стават едно и също отхвърляне.

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

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

Какво губите, когато сертификатът изчезне

Много внедрявания в тази форма изключват изцяло проверката на клиентския сертификат, оставяйки потребителско име и парола като цялото твърдение на клиента. С тази настройка изчезва идентичността, основана на сертификат. Каналът остава криптиран, но единственото, което именува клиента, е присъдата на RADIUS. Всичко надолу по веригата, което преди се е основавало на субекта на сертификата, сега трябва да се основава на потребителското име.

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