Hallo ich schon wieder
Erstmal großes Lob, echt toll dass die 1711+ jetzt den RADIUS haben. Aber das bringt gleich 2 neue Ideen.
1. Dass man die Methoden des RADIUS auf z.b. PEAP oder PEAP und EAP-TTLS einschränken kann. So dass EAP-MD5 beispielsweise dann nicht möglich wäre.
2. Dass man für RADIUS-User Login Sperren nach z.B. 3 Fehlversuchen für z.B. 60 Minuten einstellen kann. Wie beispielsweise auch bei den Management Einstellungen bereits möglich für die Verwaltungs Konten des Lancom.
Bis auf die zwei Wünsche sind die Lancom Router, hauptsächlich 1811n und einige 1711+, absolut geniale RADIUS-Server. echt spitze!
MfG
1711+
noch zwei kleine Wünsche zum RADIUS-Server
Moderator: Lancom-Systems Moderatoren
Moin,
Methoden (PAP/CHAP/...) können ja per Benutzeraccount eingestellt werden, also sollte das
*eigentlich* auch bei den EAP-Methoden so sein. Bei einigen EAP-Methoden (speziell TTLS und
manchmal auch PEAP) bekommt man den Benutzernamen aber erst mitten in der Verhandlung
mitgeteilt, also lange nachdem der RADIUS-Server die Methode sinnvoll hätte ablehnen können.
Und im Extremfall bekommt die 'äußere' Methode wie PEAP oder TTLS anstelle des echten
Benutzernamens immer nur ein 'anonymous' zu sehen.
Und selbst wenn man sich auf globale Schalter beschränkt, ist die Sache immer noch nicht so
einfach: EAP-MD5 ist vielleicht 'böse' weil zu ungesichert und man will es abschalten, aber was
ist mit EAP-MD5 als Phase 2 von EAP-TTLS? Da ist es sicherheitstechnisch wieder unbedenklich,
weil durch den (T)TLS-Tunnel verschlüsselt.
bei den Admin-Konten. Was allzu häufig passiert, ist daß man eine Brute-Force-Attacke auf
das Root-Paßwort hat und der Account gesperrt ist - man selber kommt dann auch nicht mehr
aufs Gerät. So eine Login-Sperre läßt sich mit wenig Aufwand als Mittel für eine Denial-
of-Service-Attacke benutzen.
Viel sinnvoller finde ich in diesem Zusammenhang den 'Teergrubenmodus', wie man ihn bei
Unix-Systemen vorfindet: Ein Login mit einem falschen Paßwort wird um ein paar Sekunden
verzögert beantwortet. Auf diese Weise bremst man Wörterbuchattacken aus und Logins
mit dem richtigen Paßwort bleiben unbehindert. Das könnt man auch noch mit einem exponential
backoff kombinieren...
Gruß Alfred
Das ist nicht ganz so einfach, wie's sich auf den ersten Blick anhört.Die anderen RADIUS-Auth-1. Dass man die Methoden des RADIUS auf z.b. PEAP oder PEAP und EAP-TTLS einschränken kann. So dass EAP-MD5 beispielsweise dann nicht möglich wäre.
Methoden (PAP/CHAP/...) können ja per Benutzeraccount eingestellt werden, also sollte das
*eigentlich* auch bei den EAP-Methoden so sein. Bei einigen EAP-Methoden (speziell TTLS und
manchmal auch PEAP) bekommt man den Benutzernamen aber erst mitten in der Verhandlung
mitgeteilt, also lange nachdem der RADIUS-Server die Methode sinnvoll hätte ablehnen können.
Und im Extremfall bekommt die 'äußere' Methode wie PEAP oder TTLS anstelle des echten
Benutzernamens immer nur ein 'anonymous' zu sehen.
Und selbst wenn man sich auf globale Schalter beschränkt, ist die Sache immer noch nicht so
einfach: EAP-MD5 ist vielleicht 'böse' weil zu ungesichert und man will es abschalten, aber was
ist mit EAP-MD5 als Phase 2 von EAP-TTLS? Da ist es sicherheitstechnisch wieder unbedenklich,
weil durch den (T)TLS-Tunnel verschlüsselt.
Dem Thema 'Login-Sperren' stehe ich grundsätzlich eher kritisch gegenüber, und zwar auch2. Dass man für RADIUS-User Login Sperren nach z.B. 3 Fehlversuchen für z.B. 60 Minuten einstellen kann. Wie beispielsweise auch bei den Management Einstellungen bereits möglich für die Verwaltungs Konten des Lancom.
bei den Admin-Konten. Was allzu häufig passiert, ist daß man eine Brute-Force-Attacke auf
das Root-Paßwort hat und der Account gesperrt ist - man selber kommt dann auch nicht mehr
aufs Gerät. So eine Login-Sperre läßt sich mit wenig Aufwand als Mittel für eine Denial-
of-Service-Attacke benutzen.
Viel sinnvoller finde ich in diesem Zusammenhang den 'Teergrubenmodus', wie man ihn bei
Unix-Systemen vorfindet: Ein Login mit einem falschen Paßwort wird um ein paar Sekunden
verzögert beantwortet. Auf diese Weise bremst man Wörterbuchattacken aus und Logins
mit dem richtigen Paßwort bleiben unbehindert. Das könnt man auch noch mit einem exponential
backoff kombinieren...
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
Ja der Teergrubenmodus wäre ja noch besser, das wäre schon ein cooles Feature. Womöglich dann auch für die Admin-Konten.
Wegen den Radius Methoden verstehe ich schon was du meinst. Aber^^ meistens richtet man 802.1X gezielt für eine Infrastruktur ein.
Man legt sich also gezielt auf z.b PEAP und innen Mschapv2 fest. Dann stört es ja nicht wenn MD5 ganz weg vom Fenster ist.
Quasi wie beim IAS oder auch Freeradius. Es geht dann eben nur das was soll. Zu verhandeln gäbs da ja nichts.
Schönen Sonntag!
1711+
Wegen den Radius Methoden verstehe ich schon was du meinst. Aber^^ meistens richtet man 802.1X gezielt für eine Infrastruktur ein.
Man legt sich also gezielt auf z.b PEAP und innen Mschapv2 fest. Dann stört es ja nicht wenn MD5 ganz weg vom Fenster ist.
Quasi wie beim IAS oder auch Freeradius. Es geht dann eben nur das was soll. Zu verhandeln gäbs da ja nichts.
Schönen Sonntag!
1711+
Moin,
'mit sich selber', weil die Phase 2 wie bei TTLS theoretisch auf einem anderen Backend-Server
laufen kann. Deshalb bräuchte man an dem Schalter neben an/aus noch eine dritte Einstellung
a la 'loopback-only'.
Tunnels geht? Denn prinzipiell kann ein RADIUS-Server einer Anfrage mit EAP-Message erstmal
nicht ansehen, ob das MSCHAPv2 darin direkt von einem Authenticator kommt (was man
möglicherweise nicht will) oder von einem anderen RADIUS-Server, der selbiges in PEAP
einbettet...
Gruß Alfred
Und das mit dem 'innen' ist genau der Haken. In der Phase 2 redet der RADIUS-Server quasiWegen den Radius Methoden verstehe ich schon was du meinst. Aber^^ meistens richtet man 802.1X gezielt für eine Infrastruktur ein.
Man legt sich also gezielt auf z.b PEAP und innen Mschapv2 fest.
'mit sich selber', weil die Phase 2 wie bei TTLS theoretisch auf einem anderen Backend-Server
laufen kann. Deshalb bräuchte man an dem Schalter neben an/aus noch eine dritte Einstellung
a la 'loopback-only'.
Wie kann ich z.B. bei einem IAS einstellen, daß EAP-MSCHAPv2 nur innerhalb eines PEAP-Quasi wie beim IAS oder auch Freeradius. Es geht dann eben nur das was soll. Zu verhandeln gäbs da ja nichts.
Tunnels geht? Denn prinzipiell kann ein RADIUS-Server einer Anfrage mit EAP-Message erstmal
nicht ansehen, ob das MSCHAPv2 darin direkt von einem Authenticator kommt (was man
möglicherweise nicht will) oder von einem anderen RADIUS-Server, der selbiges in PEAP
einbettet...
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
Beim IAS wählt man aus zwischen EAP-TLS oder PEAP oder beidem. Wenn man PEAP wählt geht auch nur PEAP. EAP-MSCHAPv2 nicht. Und das wäre der Traumzustand. Dann wäre der RADIUS perfekt.^^ Wie das relaisierbrar ist.. da schweige ich.. wäre sicher ein Lacher.
Aber iwie muss es funzen dass man sich auf beipielsweise PEAP beschränkt oder?
Nacht^^
1711+
Aber iwie muss es funzen dass man sich auf beipielsweise PEAP beschränkt oder?
Nacht^^
1711+
Moin,
für LCOS 8.60 (oder wie der 8.50-Nachfolger auch immer heißen wird):
Gruß Alfred
für LCOS 8.60 (oder wie der 8.50-Nachfolger auch immer heißen wird):
Code: Alles auswählen
root@lc7011srv:/Setup/RADIUS/Server/EAP/Allow-Methods
> l
Method Allow
----------------------------
MD5 On
GTC On
TLS On
TTLS On
PEAP On
MSCHAPv2 Internal-Only
root@lc7011srv:/Setup/RADIUS/Server/EAP/Allow-Methods
> set ?
Possible Entries for columns in Allow-Methods:
[1][Method] : MD5 (4), GTC (6), MSCHAPv2 (26), TLS (13), TTLS (21), PEAP (25)
[2][Allow] : Off (0), On (1), Internal-Only (2)
root@lc7011srv:/Setup/RADIUS/Server/EAP/Allow-Methods