MikroTik 2FA dla logowań do routera – WinBox, WebFig i SSH

Jeśli przeszli Państwo przez nasz przewodnik 2FA dla VPN z RADIUS, mają już Państwo wszystko, czego potrzeba, aby ochronić coś jeszcze: logowanie do samego routera. WinBox, WebFig, SSH i API mogą uwierzytelniać się przez RADIUS, a ponieważ Notakey auth-proxy jest przezroczystym RADIUS-em, skierowanie na niego usługi logowania routera sprawia, że każde logowanie administratora wymaga zatwierdzenia na telefonie, a nie tylko hasła.

Przebieg jest identyczny jak w przypadku VPN:

Router login ──RADIUS──▶ Notakey auth-proxy ──RADIUS──▶ your RADIUS server
                                 │
                                 └──▶ push notification ──▶ admin's phone

Po stronie routera zmieniają się tylko trzy rzeczy, omówione poniżej.

Wymagania

Działający auth-proxy przed serwerem RADIUS, skonfigurowany dokładnie tak jak w krokach 1–3 przewodnika po VPN. Sprawdzi się dowolny docelowy serwer RADIUS: FreeRADIUS, Microsoft NPS, własny User Manager MikroTika lub wtyczka RADIUS od Notakey.
Nazwa użytkownika administratora obecna w docelowym serwerze RADIUS oraz w usłudze Notakey, z zarejestrowanym telefonem. Proxy adresuje push według nazwy użytkownika.

Krok 1: Decyzja, jaką wiadomość push zobaczą administratorzy

Proxy wysyła wiadomość ze swojej własnej konfiguracji: te same message_title / message_description, których używa przy logowaniu do VPN. Są dwie możliwości:

Ponowne użycie proxy VPN w niezmienionej postaci. Najszybsze rozwiązanie. Logowania administratorów pokażą na telefonie treść przeznaczoną dla VPN (np. „VPN authentication — allow john login?”). W niewielkim środowisku sprawdza się bez zarzutu.
Uruchomienie drugiej instancji proxy z własną aplikacją Notakey i wiadomością w stylu „Router admin login as {0}?”. Przy skonteneryzowanym proxy to po prostu drugi kontener nasłuchujący na innym porcie (np. 18120) z inną wartością NOTAKEY_ACCESS_ID; proxy wbudowane w appliance jest pojedynczą instancją, więc drugie działa jako kontener obok niego.

Osobna wiadomość jest warta tych pięciu minut: administrator, który widzi „Router admin login”, a nie loguje się właśnie do routera, od razu wie, że coś jest nie tak i odrzuca żądanie.

Na routerze należy dodać proxy jako serwer RADIUS dla usługi login:

/radius
add service=login address=<proxy-address> secret=secret_to_radius_server timeout=30s

To linia /radius z przewodnika po VPN, w której service=ppp zamieniono na service=login. Obowiązuje to samo ostrzeżenie: domyślny limit czasu RADIUS w MikroTiku wynosi 300 milisekund. Człowiek zatwierdzający push potrzebuje co najmniej 30 sekund, więc timeout=30s nie jest opcjonalne. Bez tego każde logowanie kończy się niepowodzeniem, zanim telefon w ogóle zawibruje.

Krok 3: Włączenie RADIUS dla użytkowników routera

/user aaa
set use-radius=yes default-group=full

To wszystko: RouterOS odpytuje teraz RADIUS (przez proxy) przy każdym logowaniu, którego nazwy użytkownika nie ma w lokalnej bazie /user.

Dwie rzeczy trzeba tu zrobić poprawnie:

default-group należy wybrać świadomie. Użytkownicy uwierzytelnieni przez RADIUS otrzymują uprawnienia tej grupy (read, write lub full), chyba że serwer RADIUS zwraca dla danego użytkownika atrybut producenta Mikrotik-Group (vendor ID 14988). Jeśli wszyscy logujący się przez RADIUS to pełnoprawni administratorzy, default-group=full jest w porządku; jeśli nie, należy ustawić najniższe wystarczające uprawnienia i przypisać Mikrotik-Group z RADIUS dla wyjątków.

Lokalne konto administratora należy zachować. RouterOS najpierw sprawdza lokalną bazę użytkowników i pyta RADIUS tylko o nazwy, których nie zna. To lokalne konto administratora jest Państwa zabezpieczeniem awaryjnym, gdyby proxy, serwer RADIUS lub usługa Notakey okazały się niedostępne. Bez niego awaria zablokuje dostęp do własnego routera. Należy nadać mu silne, unikalne hasło i rozważyć ograniczenie go do adresu zarządzającego za pomocą /user set <name> address=<mgmt-subnet>.

Ostrożne testowanie

Działającej sesji nie należy jeszcze zamykać. Należy otworzyć drugą sesję WinBox lub SSH i zalogować się z nazwą użytkownika RADIUS:

Okno logowania czeka, ponieważ proxy utrzymuje wymianę otwartą.
Powiadomienie push pojawia się na telefonie. Zatwierdzenie → dostęp zostaje przyznany, z uprawnieniami grupy. Odrzucenie lub brak reakcji → logowanie kończy się niepowodzeniem po upływie limitu czasu.
Należy się upewnić, że lokalny administrator nadal loguje się w zwykły sposób.

Dopiero po pomyślnym przejściu obu testów można zamknąć pierwotną sesję.

Jeśli logowania kończą się natychmiast niepowodzeniem, mimo że push dociera, należy ponownie sprawdzić timeout=30s w /radius. Domyślne 300 ms to najczęstszy błąd. Jeśli push w ogóle nie dociera, nazwa użytkownika niemal na pewno różni się między RADIUS a usługą Notakey.

Gdzie to znajduje zastosowanie

Jedno proxy, jeden serwer RADIUS, a teraz zarówno VPN, jak i warstwa administracyjna routera wymagają zatwierdzenia na telefonie. Ten sam wzorzec rozszerza się na wszystko inne, co posługuje się protokołem RADIUS.

Powiązane przewodniki

2FA dla VPN z RADIUS: pełna konfiguracja auth-proxy, konfiguracja proxy, na której opiera się ten przewodnik
2FA dla SSH w Linuksie z pam_radius, to samo proxy chroniące SSH, sudo i su
2FA dla VPN MikroTik: pełna konfiguracja oparta na skryptach, alternatywa bez RADIUS dla samego VPN