Potrzeba zapewnienia zdalnego dostępu do środowiska korporacyjnego pojawia się coraz częściej, niezależnie od tego, czy są to użytkownicy wewnętrzni, czy partnerzy potrzebujący dostępu do określonego serwera w twojej organizacji.
W tym celu większość firm korzysta z technologii VPN, która sprawdziła się jako solidnie zabezpieczony sposób na zapewnienie dostępu do lokalnych zasobów organizacji.
Moja firma nie jest wyjątkiem i podobnie jak wiele innych korzystamy z tej technologii. I tak jak wiele innych, używamy jako bramy dostępu zdalnego – Cisco ASA 55xx.
Wraz ze wzrostem liczby zdalnych użytkowników pojawia się potrzeba uproszczenia procedury wydawania danych uwierzytelniających. Jednocześnie jednak trzeba to zrobić bez uszczerbku dla bezpieczeństwa.
Dla siebie znaleźliśmy rozwiązanie w zastosowaniu dwuetapowej weryfikacji do połączeń przez Cisco SSL VPN, przy zastosowaniu jednorazowych haseł. Ten artykuł opisuje, jak zorganizować podobne rozwiązanie przy minimalnym nakładzie czasowym i zerowych kosztach na wymaganego oprogramowania (pod warunkiem, że Cisco ASA już istnieje w twojej infrastrukturze).
Rynek obfituje w gotowe rozwiązania do generowania jednorazowych haseł, oferując jednocześnie wiele opcji ich pozyskiwania, czy to wysyłając hasło przez SMS, czy korzystając z tokenów, zarówno sprzętowych, jak i programowych (na przykład na telefonie komórkowym). Ale dążenie do oszczędności i chęć zaoszczędzenia pieniędzy dla swojego pracodawcy, w obliczu obecnego kryzysu zmusiły mnie do znalezienia bezpłatnego sposobu realizacji usługi generowania jednorazowych haseł. Który, pomimo kosztów zerowych, nie ustępuje wiele komercyjnym rozwiązaniom (należy jednak zaznaczyć, że ten produkt ma również wersję komercyjną, ale umówiliśmy się, że nasze wydatki finansowe pozostaną zerowe).
Zatem będziemy potrzebować:
— Obraz Linux z wbudowanym zestawem narzędzi – multiOTP, FreeRADIUS i nginx, do uzyskania dostępu do serwera przez sieć (http://download.multiotp.net/ – użyłem gotowego obrazu dla VMware)
— Serwer Active Directory
— Właściwie Cisco ASA (ja dla wygody korzystam z ASDM)
— Dowolny token programowy obsługujący mechanizm TOTP (ja na przykład używam Google Authenticator, ale ten sam FreeOTP również się nada).
Nie będę wchodził w szczegóły dotyczące wdrażania obrazu. Na wyjściu otrzymasz Debian Linux z już zainstalowanymi multiOTP oraz FreeRADIUS, skonfigurowanymi do współpracy oraz interfejsem webowym do zarządzania OTP.
Krok 1. Inicjujemy system i konfigurujemy pod swoją sieć
Domyślnie system dostarczany jest z danymi logowania root root. Myślę, że wszyscy się domyślili, że dobrze byłoby zmienić hasło użytkownika root po pierwszym logowaniu. Również trzeba zmienić ustawienia sieci (domyślnie to '192.168.1.44' z bramą '192.168.1.1'). Następnie można uruchomić system ponownie.
W Active Directory stworzymy użytkownika otp, z hasłem MySuperPassword.
Krok 2. Konfigurujemy połączenie i importujemy użytkowników Active Directory
W tym celu będziemy potrzebować dostępu do konsoli, oraz bezpośrednio pliku multiotp.php, używając którego skonfigurujemy parametry połączenia z Active Directory.
Przechodzimy do katalogu /usr/local/bin/multiotp/ i kolejno wykonujemy następujące polecenia:
./multiotp.php -config default-request-prefix-pin=0Określa, czy wymagany jest dodatkowy (stały) pin przy wprowadzaniu jednorazowego pinu (0 lub 1)
./multiotp.php -config default-request-ldap-pwd=0Określa, czy wymagane jest wprowadzenie hasła domenowego przy wprowadzaniu jednorazowego pinu (0 lub 1)
./multiotp.php -config ldap-server-type=1Określa typ serwera LDAP (0 = zwykły serwer LDAP, w naszym przypadku 1 = Active Directory)
./multiotp.php -config ldap-cn-identifier="sAMAccountName"Określa, w jakim formacie przedstawiać nazwę użytkownika (to ustawienie wyświetli tylko nazwę, 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ę określania przynależności użytkownika do grupy
./multiotp.php -config ldap-ssl=1Czy używać bezpiecznego połączenia z serwerem LDAP (oczywiście — tak!)
./multiotp.php -config ldap-port=636Port do połączenia z serwerem LDAP
./multiotp.php -config ldap-domain-controllers=adSRV.domain.localAdres Twojego serwera Active Directory
./multiotp.php -config ldap-base-dn="CN=Users,DC=domain,DC=local"Określamy, od czego zaczynać wyszukiwanie użytkowników w domenie
./multiotp.php -config ldap-bind-dn="otp@domain.local"Określamy użytkownika, który ma prawa do wyszukiwania w Active Directory
./multiotp.php -config ldap-server-password="MySuperPassword"Określamy hasło użytkownika, do połączenia z Active Directory
./multiotp.php -config ldap-network-timeout=10Ustawiamy timeout dla połączenia z Active Directory
./multiotp.php -config ldap-time-limit=30Ustawiamy ograniczenie czasowe dla operacji importu użytkowników
./multiotp.php -config ldap-activated=1Aktywujemy konfigurację połączenia z Active Directory
./multiotp.php -debug -display-log -ldap-users-syncImportujemy użytkowników z Active Directory
Krok 3. Generujemy kod QR dla tokena
Tutaj wszystko jest niezwykle proste. Otwieramy interfejs webowy serwera OTP w przeglądarce, logujemy się (nie zapomnijmy zmienić domyślnego hasła dla administratora!) i klikamy przycisk „Drukuj”:
Rezultatem tej czynności będzie strona, na której znajdują się dwa kody QR. Ignorujemy pierwszy z nich (pomimo atrakcyjnego napisu Google Authenticator / Authenticator / 2 Steps Authenticator), i ponownie skanujemy drugi kod w aplikacji na telefonie:
(tak, celowo zniszczyłem kod QR, aby uczynić go nieczytelnym).
Po dokonaniu tych czynności w aplikacji co trzydzieści sekund zacznie generować się sześciocyfrowe hasło.
Dla pewności można przeprowadzić test w tym samym interfejsie:
Wpisując nazwę użytkownika i jednorazowe hasło z aplikacji na telefonie. Otrzymaliśmy pozytywną odpowiedź? To przechodzimy dalej.
Krok 4. Konfigurujemy i testujemy działanie FreeRADIUS
Jak wspomniałem wcześniej — multiOTP jest już skonfigurowany do pracy z FreeRADIUS, pozostaje tylko przeprowadzić testy i dodać do pliku konfiguracyjnego FreeRADIUS informacje o naszym VPN-gateway.
Wracamy do konsoli serwera, do katalogu /usr/local/bin/multiotp/, wpisujemy:
./multiotp.php -config debug=1
./multiotp.php -config display-log=1Włączając tym samym bardziej szczegółowe logowanie.
W pliku konfiguracyjnym klientów FreeRADIUS (/etc/freeradius/clinets.conf) komentarzujemy wszystkie linie dotyczące localhost i dodajemy dwie pozycje:
client localhost {
ipaddr = 127.0.0.1
secret = testing321
require_message_authenticator = no
}— do testu
client 192.168.1.254/32 {
shortname = CiscoASA
secret = ConnectToRADIUSSecret
}— do naszego VPN-gateway.
Restartujemy FreeRADIUS i próbujemy się zalogować:
radtest username 100110 localhost 1812 testing321gdzie nazwa użytkownika = nazwa użytkownika, 100110 = hasło wydane nam przez aplikację na telefonie, localhost = adres serwera RADIUS, 1812 — port serwera RADIUS, testing321 — hasło klienta serwera RADIUS (które wskazaliśmy w konfiguracji).
Wynikiem tego polecenia będzie wyjście o mniej więcej takiej treści:
Wysyłanie żądania dostępu o id 44 do 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: Pakiet Access-Accept z hosta 127.0.0.1 port 1812, id=44, długość=20Teraz musimy upewnić się, że użytkownik pomyślnie przeszedł uwierzytelnienie. W tym celu zajrzymy do logu multiotp:
tail /var/log/multiotp/multiotp.logI jeśli ostatnim wpisem będzie:
2016-09-01 08:58:17 notice username Użytkownik OK: Użytkownik username pomyślnie zalogowany z 127.0.0.1
2016-09-01 08:58:17 debug Debug Debug: 0 OK: Token zaakceptowany z 127.0.0.1To wszystko przebiegło pomyślnie i możemy wykonać
Krok 5. Konfiguracja Cisco ASA
Załóżmy, że mamy już skonfigurowaną grupę i polityki dostępu przez SLL VPN, skonfigurowane w powiązaniu z Active Directory, i musimy dodać uwierzytelnianie dwuetapowe dla tego profilu.
1. Dodajemy nową grupę serwerów AAA:
2. Dodajemy do grupy nasz serwer multiOTP:
3. Poprawiamy profil połączenia, ustalając jako główny serwer uwierzytelniania grupę serwerów Active Directory:
4. Na karcie Advanced -> Authentification także wybieramy grupę serwerów Active Directory:
5. Na karcie Advanced -> Secondary uwierzytelniając wybieramy utworzoną grupę serwerów, w której zapisany jest serwer multiOTP. Zaznaczamy, że Session username jest dziedziczone z pierwotnej grupy serwerów AAA:
Zastosuj ustawienia i
Krok 6, ostatni
Sprawdzamy, czy nasze uwierzytelnianie dwuetapowe dla SLL VPN działa:
Voilà! Przy połączeniu za pomocą Cisco AnyConnect VPN Client zostanie również poproszona o drugi, jednorazowy, kod.
Mam nadzieję, że ten artykuł pomoże komuś i że da komuś do myślenia, jak można wykorzystać ten darmowy serwer OTP do innych zadań. Podzielcie się w komentarzach, jeśli będzie taka ochota.
Źródło: habr.com
