Я хотів би оновити свій WiFi з "WPA2 Personal" до режиму "WPA2 Enterprise", тому що я знаю, що в принципі, на Wi-Fi, захищеному "WPA2 Personal", пристрої, які знають, що PSK може нюхати трафік один одного, коли вони захоплені асоціація між станцією та АП. З метою зменшення ефекту, який мав би один компрометований пристрій у Wi-Fi (у режимі "WPA2 Personal", він мав би змогу розшифрувати інший, безкомпромісний трафік клієнта WiFi, якби раніше він захоплював "пов'язані запити" з іншого клієнти в безладному режимі / моніторі) Я хотів би оновити свій WiFi до "WPA2 Enterprise" безпеки, де, на моє розуміння, це вже неможливо.

На жаль, для "WPA2 Enterprise" вам потрібен сервер RADIUS.

Тепер, наскільки я розумію, сервер RADIUS виконує лише автентифікацію, але не здійснює шифрування або обміну ключовими матеріалами. Так, в основному, AP отримує запит на асоціацію від STA, клієнт надає облікові дані, потім AP передає їх на сервер RADIUS, сервер RADIUS каже, що "облікові дані в порядку", тоді AP дозволяє асоціювати STA, інакше ні.

Це правильна модель? Якщо так, то RADIUS-сервер - це не що інше, як база даних, повна облікових даних користувачів (імені користувача та паролів). Якщо це так, то мені цікаво, чому для цього потрібна повномасштабна серверна машина, оскільки навіть для тисяч користувачів, імена користувачів і паролі - це не так багато даних для зберігання та перевірки облікових даних, є досить базовим завданням, тому здається, що це річ, яку також легко може зробити сама AP. То чому для цього потрібен виділений сервер?

То, можливо, я помилився, і сервер RADIUS використовується не тільки для аутентифікації, але і для власне шифрування? Якщо STA надсилає дані в мережу за допомогою "WPA2 Enterprise", вона зашифровує її деяким ключем сеансу, то AP отримує зашифровані дані, але, всупереч "WPA2 Personal", він не може їх розшифрувати, тому передає дані на на сервер RADIUS, який має ключовий матеріал (та обчислювальну потужність) для його розшифрування. Після того, як RADIUS отримав чіткий текст, він передає незашифрований матеріал назад на провідну мережу. Це, як це робиться?

Причина, яку я хочу знати про це, полягає в наступному. У мене тут досить старий пристрій, на якому працює RADIUS-сервер. Але, як я вже говорив, пристрій досить старий і тому реалізує стару версію RADIUS з відомими недоліками безпеки. Тепер я хотів би знати, чи це може поставити під загрозу мою безпеку Wi-Fi, якщо використовується для шифрування режиму "WPA2 Enterprise". Якщо зловмисник може розмовляти з сервером RADIUS, коли він не підтверджено автентифікацію, це може поставити під загрозу безпеку моєї мережі, тому я не повинен цього робити. З іншого боку, якщо зловмисник може розмовляти лише з AP, який, в свою чергу, розмовляє з сервером RADIUS для перевірки облікових даних, то "вразливий сервер RADIUS" не може бути великою проблемою, оскільки зловмисник не отримає в мережу WiFi, і, таким чином, не вдалося б спілкуватися з сервером RADIUS, в першу чергу. Єдиним пристроєм, що розмовляє з сервером RADIUS, буде сама AP для перевірки облікових даних, з усім створеним ключовим матеріалом та криптографією, виконаною на самому (безкомпромісному) AP. Зловмисник буде відкликаний і, таким чином, не зможе приєднатися до мережі та використовувати слабкі сторони на потенційно вразливому сервері RADIUS.

То як саме RADIUS-сервер бере участь у захисті "WPA2 Enterprise"?

WPA2 Enterprise базується на частинах 802.11i, які базуються на 802.1X. 802.1X НЕ вимагає сервера RADIUS, але саме так це робиться для застарілих причин.

Роль сервера RADIUS лише на початку з'єднання, але це робить одну дрібницю більше, ніж ви згадали. Як частина механізму аутентифікації, матеріал клавіші надійно генерується на сервері RADIUS (а той самий матеріал клавіатури також генерується на клієнті WPA2). Після того, як сервер RADIUS скаже AP, щоб він прийняв цей запит на з'єднання, сервер RADIUS надсилає цей ключний матеріал у повідомленні "ключ" RADIUS (вони повторно використовували повідомлення / атрибут RADIUS MPPE-KEY, який Microsoft вперше ввійшов) в AP, тому AP знає, які ключі на сесію за користувачем (включаючи Pairwise Temporal Key або PTK) використовувати для цього сеансу. На цьому завершується залучення сервера RADIUS.

Ви абсолютно праві, що для запуску RADIUS-сервера дійсно не потрібно великих кінських сил. Так само, як DHCP-сервер або DNS-сервер для невеликої мережі або домену, для його запуску вам дійсно не потрібно апаратне забезпечення класу "сервер". Можливо, будь-який невеликий вбудований мережевий ящик з малою потужністю зробить це. У сучасних мережах існує багато протоколів, де "серверний" кінець за сучасними мірками не потребує великих кінських сил. Тільки тому, що ви чуєте термін "сервер", не припускайте, що він вимагає жорсткого обладнання сервера.

---

Попередня історія

Розумієте, RADIUS спочатку був способом перемістити автентифікацію з ваших модемних PPP-серверів модему та на централізований сервер. Ось чому він розшифровується як "Віддалене сервісне обслуговування користувачів Dial-In" (це повинно бути "Служба віддаленої автентифікації користувача Dial-In", але DIURAS не так добре, як RADIUS). Коли PPP почали використовуватися для аутентифікації DSL (PPPoE, PPPoA) та VPN-аутентифікації (PPTP і L2TP-over-IPSec - це "PPP всередині зашифрованого тунелю"), було природно продовжувати використовувати ті самі сервери RADIUS для централізованої аутентифікації для всі "сервери віддаленого доступу" вашого підприємства.

Оригінальних механізмів аутентифікації PPP бракувало, і для створення нових було задіяно багато стандартів, тому зрештою, протокол розширюваної автентифікації (EAP) був створений як система підключення типу аутентифікації для аутентифікації, подібної до PPP. Звичайно, сервери RADIUS та клієнти PPP були першими місцями, які потребували підтримки EAP. Звичайно, ви можете мати свій модем / сервер PPP, або ваш VPN сервер, або ваш сервер PPPoE / PPPoA (справді, L2TP PPP), або будь-що інше, впроваджувати EAP локально, але на сьогоднішній день RADIUS був настільки широко розгорнутий що в основному це були реалізовані сервери RADIUS.

Врешті-решт хтось захотів спосіб вимагати автентифікації, коли хтось підключається до не охороняється Ethernet-порту у вестибюлі або конференц-залі, тому для цього було створено "EAP через локальні мережі". Як відомо, EAPoL був стандартизований як 802.1X. Пізніше 802.1X застосовано до мереж 802.11 в IEEE 802.11i. І Wi-Fi Alliance створив програму сертифікації / брендингу / маркетингу інтероперабельності близько 802.11i і назвав її захищеним доступом Wi-Fi 2 (WPA2).

Отже, хоча ваш AP 802.11 сам може виконати всю роль аутентифікатора 802.1X (WPA2-Enterprise) "(без допомоги сервера RADIUS)", це просто не робиться зазвичай. Насправді, в деяких AP-програмах, які здатні зробити 802.1X автономними, вони фактично вбудовували та відкривали вихідний сервер RADIUS у свою прошивку та робили 802.1X аутентифікацію через RADIUS через петлю, тому що це простіше підключити таким чином, ніж намагатися реалізуйте свій власний код автентифікатора EAP або скопіюйте код з якогось сервера програмного забезпечення RADIUS з відкритим кодом та спробуйте безпосередньо інтегрувати його в демони, пов’язані з 802.11 програмного забезпечення AP.

---

З огляду на цю історію та залежно від того, скільки років пропонується ваш сервер RADIUS, важливим питанням є те, чи реалізує він тип (и) EAP, який ви хочете використовувати для аутентифікації у вашій мережі. ЛИСТ? TTLS?

Також зауважте, що RADIUS традиційно використовує "Спільний секрет", відомий клієнту RADIUS (клієнтом RADIUS є "Сервер мережевого доступу": AP в цьому випадку, або VPN, або PPP-сервер, або інший "Сервер віддаленого доступу" в іншому випадків) і RADIUS-сервер, щоб ідентифікувати клієнт RADIUS і сервер один для одного, і зашифрувати їх зв’язок. Більшість серверів RADIUS дозволяють вказувати різні спільні секрети для кожного AP, виходячи з IP-адреси AP. Тож зловмисник у вашій мережі повинен був би мати можливість перейняти цю IP-адресу та здогадатися, що ця загальна таємниця, щоб сервер RADIUS спілкувався з ним. Якщо зловмисник ще не був у мережі, зловмисник зможе лише спробувати надіслати спеціально створені / пошкоджені повідомлення EAP, які AP передаватиме через RADIUS на сервер RADIUS.

WPA Enterprise (WPA з EAP) дозволяє мати безліч інших методів аутентифікації, таких як цифрові сертифікати, маркери RSA і т. Д. Він повинен бути реалізований з радіус-сервером, оскільки всі ці методи виходять за рамки простих імен користувачів + паролів, а протокол радіусу - це фактично стандарт для більшості систем, які потребують AAA (автентифікація, авторизація, облік).

Це сказано,

1) радіус-сервер може бути легко захищений правилами брандмауера, приймаючи пакети тільки від AP (клієнт wifi ніколи не буде спілкуватися безпосередньо з радіус-сервером)

2) використання старого радіуса може не спрацювати, я рекомендую один з останніх серверів freeradius

Детальніше про те, як це працює і що потрібно зробити: http://wiki.freeradius.org/guide/WPA-HOWTO#Why-Would-I-Want-WPA ?

FreeRadius буде швидко працювати на Raspberry PI. Звичайна ОС - це Raspbian, яка є смаком Debian - тому вона буде робити все те, що ви хочете зробити на сервері, наприклад, DHCP / DNS. Це дешево - 40 доларів за голову дошку - але бюджет 80 або 90 доларів, щоб мати додаткові додаткові опції - такі як футляр і джерело живлення ... Я працюю на радіусі Pi на пару років -24 / 7. Він також має zenmap та Wireshark. Це платформа створення для випробування речей, коли вона закінчується SD-карткою, і ви можете скопіювати SD-карту на свій ПК. Спробуйте щось, і відновіть SD з ПК, якщо ви його вимкнули.