Przejdź do 2FA (uwierzytelnianie dwuskładnikowe dla ASA SSL VPN)

Konieczność zapewnienia zdalnego dostępu do środowiska korporacyjnego pojawia się coraz częściej, niezależnie od tego, czy to Twoi użytkownicy, czy partnerzy potrzebują dostępu do konkretnego serwera w Twojej organizacji.

W tym celu większość firm korzysta z technologii VPN, która okazała się niezawodnie chronionym sposobem zapewnienia dostępu do lokalnych zasobów organizacji.

Moja firma nie była wyjątkiem i my, podobnie jak wiele innych, korzystamy z tej technologii. I podobnie jak wiele innych, używamy Cisco ASA 55xx jako bramy zdalnego dostępu.

Wraz ze wzrostem liczby użytkowników zdalnych istnieje potrzeba uproszczenia procedury wydawania danych uwierzytelniających. Jednocześnie należy to zrobić bez narażania bezpieczeństwa.

Dla nas znaleźliśmy rozwiązanie polegające na zastosowaniu uwierzytelniania dwuskładnikowego do łączenia się przez Cisco SSL VPN, przy użyciu haseł jednorazowych. A ta publikacja podpowie Ci, jak zorganizować takie rozwiązanie przy minimalnym czasie i zerowych kosztach niezbędnego oprogramowania (pod warunkiem, że masz już w swojej infrastrukturze Cisco ASA).

Na rynku jest pełno pudełkowych rozwiązań do generowania haseł jednorazowych, oferujących jednocześnie wiele możliwości ich uzyskania, czy to poprzez wysłanie hasła SMS-em, czy za pomocą tokenów, zarówno sprzętowych, jak i programowych (np. w telefonie komórkowym). Jednak chęć zaoszczędzenia pieniędzy i chęć zaoszczędzenia pieniędzy dla mojego pracodawcy, w obecnym kryzysie, zmusiła mnie do znalezienia darmowego sposobu na wdrożenie usługi generowania haseł jednorazowych. Które, choć bezpłatne, nie ustępuje zbytnio rozwiązaniom komercyjnym (tutaj powinniśmy dokonać rezerwacji, zaznaczając, że ten produkt ma również wersję komercyjną, ale zgodziliśmy się, że nasze koszty w pieniądzu wyniosą zero).

Potrzebujemy:

- Obraz systemu Linux z wbudowanym zestawem narzędzi - multiOTP, FreeRADIUS i nginx, umożliwiających dostęp do serwera przez WWW (http://download.multiotp.net/ - użyłem gotowego obrazu dla VMware)
— Serwer Active Directory
— sam Cisco ASA (dla wygody używam ASDM)
— Dowolny token programowy obsługujący mechanizm TOTP (ja na przykład używam Google Authenticator, ale FreeOTP zrobi to samo)

Nie będę wdawał się w szczegóły powstawania obrazu. W rezultacie otrzymasz Debian Linux z już zainstalowanymi multiOTP i FreeRADIUS, skonfigurowanymi do współpracy oraz interfejsem internetowym do administrowania OTP.

Krok 1. Inicjujemy system i konfigurujemy go dla Twojej sieci
Domyślnie system jest dostarczany z poświadczeniami root root. Chyba każdy zgadł, że dobrym pomysłem będzie zmiana hasła użytkownika root już po pierwszym logowaniu. Należy także zmienić ustawienia sieciowe (domyślnie jest to „192.168.1.44” z bramą „192.168.1.1”). Następnie możesz ponownie uruchomić system.

Utwórzmy użytkownika w Active Directory Otp, z hasłem Moje SuperHasło.

Krok 2. Skonfiguruj połączenie i zaimportuj użytkowników Active Directory
Aby to zrobić potrzebujemy dostępu do konsoli i bezpośrednio do pliku multiotp.php, za pomocą którego skonfigurujemy ustawienia połączenia z Active Directory.

Przejdź do katalogu /usr/local/bin/multiotp/ i wykonaj po kolei następujące polecenia:

./multiotp.php -config default-request-prefix-pin=0

Określa, czy przy wprowadzaniu jednorazowego kodu PIN (0 lub 1) wymagany jest dodatkowy (stały) pin

./multiotp.php -config default-request-ldap-pwd=0

Określa, czy przy wprowadzaniu jednorazowego kodu PIN (0 lub 1) wymagane jest hasło domeny

./multiotp.php -config ldap-server-type=1

Wskazany jest typ serwera LDAP (0 = zwykły serwer LDAP, w naszym przypadku 1 = Active Directory)

./multiotp.php -config ldap-cn-identifier="sAMAccountName"

Określa format w jakim ma być prezentowana nazwa użytkownika (ta wartość spowoduje wyświetlenie samej nazwy, bez domeny)

./multiotp.php -config ldap-group-cn-identifier="sAMAccountName"

To samo, tylko dla grupy

./multiotp.php -config ldap-group-attribute="memberOf"

Określa metodę ustalania, czy użytkownik należy do grupy

./multiotp.php -config ldap-ssl=1

Czy powinienem używać bezpiecznego połączenia z serwerem LDAP (oczywiście tak!)

./multiotp.php -config ldap-port=636

Port do połączenia z serwerem LDAP

./multiotp.php -config ldap-domain-controllers=adSRV.domain.local

Adres Twojego serwera Active Directory

./multiotp.php -config ldap-base-dn="CN=Users,DC=domain,DC=local"

Wskazujemy od czego zacząć wyszukiwanie użytkowników w domenie

./multiotp.php -config ldap-bind-dn="[email protected]"

Określ użytkownika, który ma uprawnienia do wyszukiwania w Active Directory

./multiotp.php -config ldap-server-password="MySuperPassword"

Określ hasło użytkownika, aby połączyć się z Active Directory

./multiotp.php -config ldap-network-timeout=10

Ustawianie limitu czasu połączenia z Active Directory

./multiotp.php -config ldap-time-limit=30

Ustalamy limit czasowy operacji importu użytkownika

./multiotp.php -config ldap-activated=1

Aktywacja konfiguracji połączenia Active Directory

./multiotp.php -debug -display-log -ldap-users-sync

Importujemy użytkowników z Active Directory

Krok 3. Wygeneruj kod QR dla tokena
Wszystko tutaj jest niezwykle proste. Otwórz interfejs sieciowy serwera OTP w przeglądarce, zaloguj się (nie zapomnij zmienić domyślnego hasła administratora!) i kliknij przycisk „Drukuj”:

Przejdź do 2FA (uwierzytelnianie dwuskładnikowe dla ASA SSL VPN)
Efektem tej akcji będzie strona zawierająca dwa kody QR. Odważnie ignorujemy pierwszy z nich (mimo atrakcyjnego napisu Google Authenticator / Authenticator / 2 Steps Authenticator), a drugi śmiało skanujemy drugi kod do tokena programowego w telefonie:

Przejdź do 2FA (uwierzytelnianie dwuskładnikowe dla ASA SSL VPN)
(tak, celowo zepsułem kod QR, aby był nieczytelny).

Po wykonaniu tych czynności co trzydzieści sekund w Twojej aplikacji zacznie się generować sześciocyfrowe hasło.

Dla pewności możesz to sprawdzić w tym samym interfejsie:

Przejdź do 2FA (uwierzytelnianie dwuskładnikowe dla ASA SSL VPN)
Wpisując swoją nazwę użytkownika i hasło jednorazowe z aplikacji na swoim telefonie. Czy otrzymałeś pozytywną odpowiedź? Więc ruszamy dalej.

Krok 4. Dodatkowa konfiguracja i testowanie działania FreeRADIUS
Jak wspomniałem powyżej, multiOTP jest już skonfigurowany do współpracy z FreeRADIUS, pozostaje tylko uruchomić testy i dodać informacje o naszej bramce VPN do pliku konfiguracyjnego FreeRADIUS.

Wracamy do konsoli serwera, do katalogu /usr/local/bin/multiotp/, Wchodzić:

./multiotp.php -config debug=1
./multiotp.php -config display-log=1

W tym bardziej szczegółowe rejestrowanie.

W pliku konfiguracyjnym klientów FreeRADIUS (/etc/freeradius/clinets.conf) skomentuj wszystkie linie powiązane z localhost i dodaj dwa wpisy:

client localhost {
        ipaddr = 127.0.0.1
        secret          = testing321
        require_message_authenticator = no
}

- dla testu

client 192.168.1.254/32 {
        shortname =     CiscoASA
        secret =        ConnectToRADIUSSecret
}

— dla naszej bramy VPN.

Uruchom ponownie FreeRADIUS i spróbuj się zalogować:

radtest username 100110 localhost 1812 testing321

gdzie nazwa użytkownika = nazwa użytkownika, 100110 = hasło nadane nam przez aplikację na telefonie, localhost = adres serwera RADIUS, 1812 — port serwera RADIUS, testowanie321 — hasło klienta serwera RADIUS (które określiliśmy w konfiguracji).

Wynik tego polecenia zostanie wyświetlony w przybliżeniu w następujący sposób:

Sending Access-Request of id 44 to 127.0.0.1 port 1812
        User-Name = "username"
        User-Password = "100110"
        NAS-IP-Address = 127.0.1.1
        NAS-Port = 1812
        Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=44, length=20

Teraz musimy się upewnić, że użytkownik został pomyślnie uwierzytelniony. Aby to zrobić, przyjrzymy się dziennikowi samego multiotp:

tail /var/log/multiotp/multiotp.log

A jeśli ostatni wpis to:

2016-09-01 08:58:17     notice  username  User    OK: User username successfully logged in from 127.0.0.1
2016-09-01 08:58:17     debug           Debug   Debug: 0 OK: Token accepted from 127.0.0.1

Potem wszystko poszło dobrze i możemy zakończyć

Krok 5: Skonfiguruj Cisco ASA
Umówmy się, że mamy już skonfigurowaną grupę i zasady dostępu przez SLL VPN, skonfigurowane w połączeniu z Active Directory i musimy dodać uwierzytelnianie dwuskładnikowe dla tego profilu.

1. Dodaj nową grupę serwerów AAA:

Przejdź do 2FA (uwierzytelnianie dwuskładnikowe dla ASA SSL VPN)
2. Dodaj nasz serwer multiOTP do grupy:

Przejdź do 2FA (uwierzytelnianie dwuskładnikowe dla ASA SSL VPN)
3. Edytujemy profil połączenia, ustawiając grupę serwerów Active Directory jako główny serwer uwierzytelniania:

Przejdź do 2FA (uwierzytelnianie dwuskładnikowe dla ASA SSL VPN)
4. W zakładce Zaawansowane -> Uwierzytelnianie Wybieramy także grupę serwerów Active Directory:

Przejdź do 2FA (uwierzytelnianie dwuskładnikowe dla ASA SSL VPN)
5. W zakładce Zaawansowane -> Dodatkowe uwierzytelniania, wybierz utworzoną grupę serwerów, w której zarejestrowany jest serwer multiOTP. Należy pamiętać, że nazwa użytkownika sesji jest dziedziczona z podstawowej grupy serwerów AAA:

Przejdź do 2FA (uwierzytelnianie dwuskładnikowe dla ASA SSL VPN)
Zastosuj ustawienia i

Krok 6, czyli ostatni
Sprawdźmy, czy uwierzytelnianie dwuskładnikowe działa w przypadku SLL VPN:

Przejdź do 2FA (uwierzytelnianie dwuskładnikowe dla ASA SSL VPN)
Voila! Podczas łączenia się za pośrednictwem klienta Cisco AnyConnect VPN zostaniesz również poproszony o podanie drugiego, jednorazowego hasła.

Mam nadzieję, że ten artykuł komuś pomoże i da komuś do myślenia, jak z tego skorzystać, wolny Serwer OTP do innych zadań. Jeśli chcesz, udostępnij w komentarzach.

Źródło: www.habr.com

Dodaj komentarz