Какво да направите, ако искате двуфакторна автентикация, но не искате да харчите пари за хардуерни токени и въобще ви предлагат да се държите в добро настроение.
Това решение не е нещо супероригинално, по-скоро е микс от различни решения, намерени в интернет.
И така, ето какво имаме:
Домейн Active Directory.
Потребители на домейн, които работят през VPN, както много хора днес.
VPN шлюзът е: Fortigate.
Запазването на паролата за VPN клиента е забранено от политиката за сигурност.
Политиката Fortinet по отношение на собствените токени не може да се нарече жлъчна – получавате 10 безплатни токена, а останалите са на много неблагоприятни цени. RSASecureID, Duo и подобни не разглеждам, тъй като искам опенсорс.
Предварителни изисквания: хост *nix с инсталиран freeradius, sssd – добавен в домена, домейните потребители могат спокойно да се автентикират на него.
Допълнителни пакети: shellinabox, figlet, freeeradius-ldap, шрифт rebel.tlf от репозитория .
В моя пример – CentOS 7.8.
Логиката за работа е следната: при свързване с VPN потребителят трябва да въведе домейново име и OTP вместо парола.
Настройка на услугите,
В /etc/raddb/radiusd.conf променя се само потребителят и групата, от името на която стартира, freeradiusтъй като услугата radiusd трябва да може да чете файлове в всички поддиректории. /home/.
user = root
group = root
За да можете да използвате групи в настройките, Fortigateтрябва да предавате Vendor Specific Attribute.За това в директорията raddb/policy.d създавам файл със следното съдържание:
group_authorization {
if (&LDAP-Group[*] == "CN=vpn_admins,OU=vpn-groups,DC=domain,DC=local") {
update reply {
&Fortinet-Group-Name = "vpn_admins" }
update control {
&Auth-Type := PAM
&Reply-Message := "Welcome Admin"
}
}
else {
update reply {
&Reply-Message := "Not authorized for vpn"
}
reject
}
}
След инсталацията на freeradius-ldap в директорията raddb/mods-available се създава файл. ldap.
Трябва да създадете символна връзка в каталога raddb/mods-enabled..
ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldapПреобразувам съдържанието му в такъв вид:
ldap {
server = 'domain.local'
identity = 'CN=freerad_user,OU=users,DC=domain,DC=local'
password = "SupeSecretP@ssword"
base_dn = 'dc=domain,dc=local'
sasl {
}
user {
base_dn = "${..base_dn}"
filter = "(sAMAccountname=%{%{Stripped-User-Name}:-%{User-Name}})"
sasl {
}
scope = 'sub'
}
group {
base_dn = "${..base_dn}"
filter = '(objectClass=Group)'
scope = 'sub'
name_attribute = cn
membership_filter = "(|(member=%{control:Ldap-UserDn})(memberUid=%{%{Stripped-User-Name}:-%{User-Name}}))"
membership_attribute = 'memberOf'
}
} В файловете raddb/sites-enabled/default и raddb/sites-enabled/inner-tunnel в секцията authorize допълвам името на политиката, която ще бъде използвана — group_authorization. Важен момент — името на политиката не се определя от името на файла в директорията policy.d, а от директивата вътре в файла преди фигурните скоби.
В секцията authenticate в тези същите файлове трябва да разкоментираме реда pam.
В файла clients.conf определяме параметрите, с които ще се свързва Fortigate:
client fortigate {
ipaddr = 192.168.1.200
secret = testing123
require_message_authenticator = no
nas_type = other
}
Конфигурация на модула pam.d/radiusd:
#%PAM-1.0
auth sufficient pam_google_authenticator.so
auth include password-auth
account required pam_nologin.so
account include password-auth
password include password-auth
session include password-auth
Дефолтните опции за интеграция на пакета freeradius с google authenticator предполага въвеждане от потребителя на данни в формат: username/password+OTP.
Предвид количеството проклятия, които ще се изсипят, в случай на използване на дефолтната комбинация freeradius с Google Authenticator, беше взето решение да се използва конфигурацията на модула pam така, че да проверява само токена Google Authenticator.
При свързване на потребителя се случва следното:
- Freeradius проверява наличието на потребителя в домейна и в определена група и, в случай на успех, се извършва проверка на OTP токена.
Всичко изглеждаше доста добре, докато не се запитах „А как да регистрирам OTP за 300+ потребители?“
Потребителят трябва да влезе на сървъра с freeradius и от своята сметка и да стартира приложението Google authenticator, което ще генерира QR-код за приложението. Тук идва на помощ shellinabox в комбинация с .bash_profile.
[root@freeradius ~]# yum install -y shellinabox
Конфигурационният файл на демона се намира в /etc/sysconfig/shellinabox.
Указвам там порт 443 и мога да укажа своя сертификат.
[root@freeradius ~]#systemctl enable --now shellinaboxdНа потребителя остава само да влезе по линка, да въведе домейн кредите и да получи QR-код за приложението.
Алгоритъмът е следният:
- Потребителят влиза в машината през браузера.
- Проверява се дали потребителят е домейнов.
- Ако не е, не се предприемат действия.
- Ако потребителят е домейнов, се проверява принадлежността към групата на администраторите.
- Ако не е администратор, проверява се дали Google Authenticator е настроен. Ако не е, се генерира QR-код и потребителят излиза.
- Ако не е администратор и Google Authenticator е настроен, просто излизане.
Ако е администратор, отново проверка на Google Authenticator. Ако не е настроен, се генерира QR-код. /etc/skel/.bash_profile.
Цялата логика се изпълнява с използване на
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
# Make several commands available from user shell
if [[ -z $(id $USER | grep "admins") || -z $(cat /etc/passwd | grep $USER) ]]
then
[[ ! -d $HOME/bin ]] && mkdir $HOME/bin
[[ ! -f $HOME/bin/id ]] && ln -s /usr/bin/id $HOME/bin/id
[[ ! -f $HOME/bin/google-auth ]] && ln -s /usr/bin/google-authenticator $HOME/bin/google-auth
[[ ! -f $HOME/bin/grep ]] && ln -s /usr/bin/grep $HOME/bin/grep
[[ ! -f $HOME/bin/figlet ]] && ln -s /usr/bin/figlet $HOME/bin/figlet
[[ ! -f $HOME/bin/rebel.tlf ]] && ln -s /usr/share/figlet/rebel.tlf $HOME/bin/rebel.tlf
[[ ! -f $HOME/bin/sleep ]] && ln -s /usr/bin/sleep $HOME/bin/sleep
# Set PATH env to <home user directory>/bin
PATH=$HOME/bin
export PATH
else
PATH=PATH=$PATH:$HOME/.local/bin:$HOME/bin
export PATH
fi
if [[ -n $(id $USER | grep "domain users") ]]
then
if [[ ! -e $HOME/.google_authenticator ]]
then
if [[ -n $(id $USER | grep "admins") ]]
then
figlet -t -f $HOME/bin/rebel.tlf "Welcome to Company GAuth setup portal"
sleep 1.5
echo "Please, run any of these software on your device, where you would like to setup OTP:
Google Autheticator:
AppStore - https://apps.apple.com/us/app/google-authenticator/id388497605
Play Market - https://play.google.com/stor/apps/details?id=com.google.android.apps.authenticator2&hl=en
FreeOTP:
AppStore - https://apps.apple.com/us/app/freeotp-authenticator/id872559395
Play Market - https://play.google.com/store/apps/details?id=org.fedorahosted.freeotp&hl=en
And prepare to scan QR code.
"
sleep 5
google-auth -f -t -w 3 -r 3 -R 30 -d -e 1
echo "Congratulations, now you can use an OTP token from application as a password connecting to VPN."
else
figlet -t -f $HOME/bin/rebel.tlf "Welcome to Company GAuth setup portal"
sleep 1.5
echo "Please, run any of these software on your device, where you would like to setup OTP:
Google Autheticator:
AppStore - https://apps.apple.com/us/app/google-authenticator/id388497605
Play Market - https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=en
FreeOTP:
AppStore - https://apps.apple.com/us/app/freeotp-authenticator/id872559395
Play Market - https://play.google.com/store/apps/details?id=org.fedorahosted.freeotp&hl=en
And prepare to scan QR code.
"
sleep 5
google-auth -f -t -w 3 -r 3 -R 30 -d -e 1
echo "Congratulations, now you can use an OTP token from application as a password to VPN."
logout
fi
else
echo "You have already setup a Google Authenticator"
if [[ -z $(id $USER | grep "admins") ]]
then
logout
fi
fi
else
echo "You don't need to set up a Google Authenticator"
fi
Настройка на Fortigate:
- Създаваме Radius-сървър

- Създаваме необходимите групи, в случай че е необходимо разделение на достъпа по групи. Името на групата на Fortigate трябва да съответства на групата, която се предава в Vendor Specific Attribute. Fortinet-Group-Name.

- Редактираме необходимите SSL-портали.

- Добавяме групи в политиките.

Плюсовете на това решение:
- Има възможност за удостоверяване чрез OTP на Fortigate отворено решение.
- Изключва се въвеждането на домейн парола от потребителя при свързване чрез VPN, което малко улеснява процеса на свързване. Въвеждането на 6-цифрен парола е по-лесно от това, което е предвидено в политиката за сигурност. В резултат на това намалява броят на тикетите с тема: "Не мога да се свържа с VPN".
P.S. В плановете е да надградим това решение до пълноценна двуфакторна удостоверяване с challenge-response.
Актуализация:
Както обещах, накрая добавих вариант с challenge-response.
И така:
В файла /etc/raddb/sites-enabled/default секция authorize изглежда следния начин:
authorize {
filter_username
preprocess
auth_log
chap
mschap
suffix
eap {
ok = return
}
files
-sql
#-ldap
expiration
logintime
if (!State) {
if (&User-Password) {
# Ако !State и User-Password (PAP), тогава задължително LDAP:
update control {
Ldap-UserDN := "%{User-Name}"
Auth-Type := LDAP
}
}
else {
reject
}
}
else {
# Ако State, тогава прокси заявка:
group_authorization
}
pap
}
Секция authenticate сега има следния вид:
authenticate {
Auth-Type PAP {
pap
}
Auth-Type CHAP {
chap
}
Auth-Type MS-CHAP {
mschap
}
mschap
digest
# Опитайте удостоверяване с директно свързване към LDAP:
Auth-Type LDAP {
ldap
if (ok) {
update reply {
# Създайте произволен атрибут State:
State := "%{randstr:aaaaaaaaaaaaaaaa}"
Reply-Message := "Моля, въведете OTP"
}
# Върнете Access-Challenge:
challenge
}
}
pam
eap
}
Сега проверката на потребителя се извършва по следния алгоритъм:
- Потребителят въвежда домейн креденциалите в VPN клиента.
- Freeradius проверява валидността на акаунта и паролата
- Ако паролата е вярна, изпраща се заявка за токен.
- Извършва се проверка на токена.
- Профит).
Източник: habr.com




