Як быць, калі двухфактарнай аўтэнтыфікацыі і жадаецца, і колецца, а грошай на апаратныя токены няма і наогул прапануюць трымацца і добрага настрою.
Дадзенае рашэнне не з'яўляецца чымсьці суперарыгінальным, хутчэй - мікс з розных рашэнняў, знойдзеных на прасторах інтэрнэту.
Такім чынам, дадзена
дамен Active Directory.
Карыстальнікі дамена, якія працуюць праз VPN, як многія сягоння.
У ролі шлюза VPN выступае Умацавацца.
Захаванне пароля для VPN-кліента забаронена палітыкай бяспекі.
Палітыку Fortinet у дачыненні да ўласных токенаў менш чым жлобскай не назавеш - бясплатных токенаў аж 10 адзінак, астатнія - па вельмі некашэрнай цане. RSASecureID, Duo і ім падобныя не разглядаў, паколькі жадаецца апенсорса.
Папярэднія патрабаванні: хост * Нікс з усталяваным freeradius, ssd - уведзены ў дамен, даменныя карыстачы могуць спакойна на ім аўтэнтыфікавацца.
Дадатковыя пакеты: shellinabox, філетка, freeeradius-ldap, шрыфт rebel.tlf з рэпазітара
У маім прыкладзе - CentOS 7.8.
Логіка працы мяркуецца такая: пры падлучэнні да VPN карыстач павінен увесці даменны лагін і OTP замест пароля.
Настройка сэрвісаў
В /etc/raddb/radiusd.conf мяняецца толькі карыстальнік і група, ад імя якіх стартуе freeradius, так як сэрвіс radiusd павінен умець чытаць файлы ва ўсіх паддырэкторыях / Галоўная /.
user = root
group = root
Каб можна было выкарыстоўваць групы ў наладах Умацавацца, трэба перадаваць 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 у секцыі дазволіць дапісваю імя палітыкі, якая будзе выкарыстоўвацца - group_authorization. Важны момант - імя палітыкі вызначаецца не назвай файла ў дырэкторыі policy.d, а дырэктывай ўнутры файла перад фігурнымі дужкамі.
У секцыі правяраць сапраўднасць у гэтых жа файлах трэба раскаментаваць радок РАМ.
У файле clients.conf прапісваем параметры, з якімі будзе падлучацца Умацавацца:
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+ОТП.
Прадставіўшы колькасць праклёнаў, якая пасыплецца на галаву, у выпадку выкарыстання дэфолтнай звязкі freeradius с Google Authenticator, было прынята рашэнне выкарыстоўваць канфігурацыю модуля РАМ так, каб правяраць толькі токен Google Authenticator.
Пры падключэнні карыстальніка адбываецца наступнае:
- Freeradius правярае наяўнасць карыстача ў дамене і ў вызначанай групе і, у выпадку поспеху, вырабляецца праверка OTP токена.
Усё выглядала досыць удала да моманту, пакуль я не задумаўся "А як жа зрабіць рэгістрацыю OTP для 300+ карыстачоў?"
Карыстальнік павінен залагініцца на сервер з freeradius і з-пад свайго ўліковага запісу і запусціць прыкладанне Google Authentator, якое і згенеруе для карыстальніка QR-код для прыкладання. Вось тут на дапамогу і прыходзіць shellinabox у камбінацыі з .bash_профіль.
[root@freeradius ~]# yum install -y shellinabox
Канфігурацыйны файл дэмана знаходзіцца ў /etc/sysconfig/shellinabox.
Паказваю там порт 443 і можна пазначыць свой сертыфікат.
[root@freeradius ~]#systemctl enable --now shellinaboxd
Карыстальніку застаецца толькі зайсці па спасылцы, увесці даменныя крэдыты і атрымаць QR-код для прыкладання.
Алгарытм наступны:
- Карыстальнік лагініцца на машыну праз браўзэр.
- Правяраецца ці даменны карыстач. Калі не, то ніякіх дзеянняў не робіцца.
- Калі карыстач даменны, правяраецца прыналежнасць да групы адміністратараў.
- Калі не адмін, правяраецца ці настроены Google Autheticator. Калі не, то генеруецца QR-код і logout карыстальніка.
- Калі не адмін і Google Authenticator наладжаны, то проста logout.
- Калі адмін, то зноў праверка Google Authenticator. Калі не настроены, то генеруецца QR-код.
Уся логіка выконваецца з выкарыстаннем /etc/skel/.bash_profile.
cat /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:
- Ствараем радыус-сервер
- Ствараем неабходныя групы, у выпадку неабходнасці размежавання доступу па групах. Імя групы на Умацавацца павінна адпавядаць групе, якая перадаецца ў Vendor Specific Attribute Fortinet-Group-Name.
- Рэдагуем неабходныя SSL-парталы.
- Дадаем групы ў палітыкі.
Плюсы дадзенага рашэння:
- Ёсць магчымасць аўтэнтыфікацыі па OTP на Умацавацца апенсорз рашэннем.
- Выключаецца ўвод даменнага пароля карыстачом пры падлучэнні па VPN, што некалькі спрашчае працэс падлучэння. 6-лічбавы пароль увесці прасцей, чым той, які прадугледжаны палітыкай бяспекі. Як следства, памяншаецца колькасць тыкетаў з тэмай: "Не магу падлучыцца да VPN".
PS У планах дакруціць гэтае рашэнне да паўнавартаснай двухфактарнай аўтарызацыі з challenge-response.
абнаўленне:
Як і абяцаў, дакруціў такі да варыянту з challenge-response.
Такім чынам:
У файле /etc/raddb/sites-enabled/default секцыя дазволіць выглядае наступным чынам:
authorize {
filter_username
preprocess
auth_log
chap
mschap
suffix
eap {
ok = return
}
files
-sql
#-ldap
expiration
logintime
if (!State) {
if (&User-Password) {
# If !State and User-Password (PAP), then force LDAP:
update control {
Ldap-UserDN := "%{User-Name}"
Auth-Type := LDAP
}
}
else {
reject
}
}
else {
# If State, then proxy request:
group_authorization
}
pap
}
секцыя правяраць сапраўднасць зараз мае наступны выгляд:
authenticate {
Auth-Type PAP {
pap
}
Auth-Type CHAP {
chap
}
Auth-Type MS-CHAP {
mschap
}
mschap
digest
# Attempt authentication with a direct LDAP bind:
Auth-Type LDAP {
ldap
if (ok) {
update reply {
# Create a random State attribute:
State := "%{randstr:aaaaaaaaaaaaaaaa}"
Reply-Message := "Please enter OTP"
}
# Return Access-Challenge:
challenge
}
}
pam
eap
}
Цяпер праверка карыстальніка адбываецца па наступным алгарытме:
- Карыстальнік уводзіць даменныя крэдыты ў VPN-кліенце.
- Freeradius правярае валіднасць уліковага запісу і пароль
- Калі пароль правільны, то адпраўляецца запыт на токен.
- Адбываецца праверка токена.
- Профіт).
Крыніца: habr.com