Wi-Fi with username and password for each user or do WPA2-EAP / TLS with improvised tools
From a practical point of view, it would be convenient to manage Wi-Fi networks, giving a password to each user. This makes it easy to access your wireless network. Using the so-called WPA2 PSK authorization, to prevent access to a random user, you need to change the key, as well as re-pass the authorization process on each individual Wi-Fi device. In addition, if you have multiple access points, the key needs to be changed on all of them. And if you need to hide the password from someone, you will have to distribute a new one to all employees.
Imagine a situation - someone outside your office (client, counterpart?) Came to your office, and you need to give it access to the Internet. Instead of giving him the WPA2 key, you can make a separate account for it, which then, after its departure, you canremove the block. This will give you the flexibility to manage your account, and users will be very happy.
We will make a convenient scheme, used in corporate networks, but entirely from improvised means with minimal financial and hardware investments. It will be approved by the security service and management.
Once upon a time, IEEE engineers invented the 802.1x standard. This standard is responsible for the ability to authorize a user immediately when connected to the data transfer medium. In other words, if you are connecting to a medium (switch) for a connection, for example, PPPoE, and you can already transfer data, authorization is needed to connect to the Internet. In the case of 802.1x, you will not be able to do anything until you log in. The end device itself will not allow you. The situation is similar with Wi-Fi access points. The decision to admit you is made on an external authorization server. This may be RADIUS, TACACS, TACACS +, etc.
')
In general, user authorization at a point can be of the following types:
And now let's look at the options for how the access point will know for itself whether it is possible to provide the user with access to the network or not:
There are also quite a number of ways to connect the end device to the authorization server (PEAP, TLS, TTLS ...). I will not describe them here.
For visual understanding, we present a general scheme of the work of our future scheme:
If in words, then the client, when connected to a Wi-Fi point, is asked to enter a login and password. Having received a Wi-Fi login and password, the point transfers this data to the RADIUS server, to which the server responds, what can be done with this client. Depending on the answer, the point decides whether to give it access, cut back on speed or something else.
For authorization of users, our server with freeradius installed will be responsible. Freeradius is an implementation of the RADIUS protocol, which in turn is an implementation of the general AAA protocol. AAA is a set of tools to do the following:
Authentication - checks the validity of the login and password.
Authorization - checks for rights to perform certain actions.
Accounting - takes into account your actions in the system.
The protocol itself transmits the user name, a list of attributes and their values for it. That is, for example, the Auth-Type: = Reject attribute - reject this client, and Client-Password == "password" - compare the attribute in the request with the password value.
Generally speaking, the base of accounts and rights for them does not have to be stored on the RADIUS server, and the base can be anything - niksov users, users of the Windows domain ... but at least a text file. But in our case, everything will be in one place.
In this article, we will be primarily interested in the WPA2-EAP / TLS authorization method.
Almost all modern Wi-Fi access points worth more than 3 thousand rubles support the technology we need. Client devices support and even more so.
In the article I will use the following hardware and software:
The main thing is that the point supports the desired authentication method. It can be called differently in different devices: WPA-EAP, WPA2 Enterprise, etc. In any case, we select authentication, set the IP address and port of the RADIUS server, and the key that we entered in clients.conf when setting up Freeradius.
I will give a picture from the configured point Ubiquiti. Marked daws that need to be changed.
Go to our Linux computer and install a RADIUS server. I took freeradius, and I put it on gentoo. To my surprise, there are no materials in Runet related to configuring Freeradius 2 for our purposes. All articles are quite old, refer to the old versions of this software.
That's it :) The RADIUS server can already work :) You can check it like this:
This is debug-mode. All information falls out on the console. Let's start to configure it.
As is usual in Linux, configuration is done through configuration files. Configuration files are stored in / etc / raddb. Let's do the preparatory actions - copy the source configs, clean the configuration from any garbage.
Next, add the client - access point. Add the following lines to the / etc / raddb / clients file:
Next, add a domain for users. Make default.
And finally, add users to the / etc / raddb / users file:
Wow, you can start!
Our server is running and waiting for connections!
Let's go over the configuration of the main user devices. Our employees have clients working on Android, iOS and Windows 7. Let's make a reservation right away: since we use self-generated certificates, we need to make various exceptions and confirm actions several times. If we used the purchased certificates, maybe everything would be easier.
Everything is easier on iOS devices. Enter the username and password, click "Accept the certificate", and forward.
It looks a little more complicated, but in practice everything is also simple on Android. There are a few more input fields.
Well, on Windows 7 will have a little ponastraivat. Perform the following steps:
We go to the center of wireless connections.
Next, I present screenshots of dialog boxes specifically for people like me, whose eyes run from the Windows dialog boxes.
Now there is one problem left - if you want to add-remove a new user, you will have to change users and restart radius. To avoid this, connect the database and make your own mini-billing for users. Using the database, you can always jot down a simple script to add, block, change the user's password. And all this will happen without stopping the entire system.
For myself, I used Postgres, but you can choose at your discretion. I give the basic Postgres setting, without going into various permissions, passwords, and other tricks and conveniences.
First, create the database itself:
Next you need to create the necessary tables. In general, with Freeradius, there is documentation on table schemas for various databases, although they are in different distributions in different distributions. I personally have it in /etc/raddb/sql/postgresql/schema.sql. Just paste these lines into psql, or just run
Just in case I will add the schema for Postgres here:
Great, the base is prepared. Now configure Freeradius.
Add, if it is not there, in the /etc/raddb/radiusd.conf line
Now edit /etc/raddb/sql.conf to fit your reality. I have it looks like this:
Add a few new users test1, test2, test3, and ... block test3
Well, restart freeradius and try to connect. It should all work!
Of course, the billing turned out to be flawed - we do not store information on accounting anywhere (recording user actions), but we don’t need it here either. To keep accounting, you also need Wi-Fi points more than 3 thousand rubles. But even so, we can easily manage users.
In the last section, we collected our own small billing! It remains for the completeness of the picture to screw up some WEB-interface for managing the Database, add a mandatory password change once a month for krone. And if the certificate and the Wi-Fi controller of access points go bust, then you have a full-fledged corporate wireless network in your hands. But even without these costs and with little effort on your part, having made such access to your users, they will thank you so much.
Old, but partially up-to-date instruction on ixbt
WIKI FreeRadius
Used Wi-Fi Point Ubiquiti Nanostation M2
Imagine a situation - someone outside your office (client, counterpart?) Came to your office, and you need to give it access to the Internet. Instead of giving him the WPA2 key, you can make a separate account for it, which then, after its departure, you can
We will make a convenient scheme, used in corporate networks, but entirely from improvised means with minimal financial and hardware investments. It will be approved by the security service and management.
Some theory
Once upon a time, IEEE engineers invented the 802.1x standard. This standard is responsible for the ability to authorize a user immediately when connected to the data transfer medium. In other words, if you are connecting to a medium (switch) for a connection, for example, PPPoE, and you can already transfer data, authorization is needed to connect to the Internet. In the case of 802.1x, you will not be able to do anything until you log in. The end device itself will not allow you. The situation is similar with Wi-Fi access points. The decision to admit you is made on an external authorization server. This may be RADIUS, TACACS, TACACS +, etc.
')
Terminology
In general, user authorization at a point can be of the following types:
- Open - available to all
- WEP is old encryption. Already all the baldness eaten about the fact that it is not necessary to use at all
- WPA - Used by TKIP as encryption protocol
- WPA2 - AES Encryption Used
And now let's look at the options for how the access point will know for itself whether it is possible to provide the user with access to the network or not:
- WPA-PSK, WPA2-PSK - the key to access is at the very point.
- WPA-EAP, WPA2-EAP — the access key is checked with some remote database on a third-party server
There are also quite a number of ways to connect the end device to the authorization server (PEAP, TLS, TTLS ...). I will not describe them here.
General network layout
For visual understanding, we present a general scheme of the work of our future scheme:
If in words, then the client, when connected to a Wi-Fi point, is asked to enter a login and password. Having received a Wi-Fi login and password, the point transfers this data to the RADIUS server, to which the server responds, what can be done with this client. Depending on the answer, the point decides whether to give it access, cut back on speed or something else.
For authorization of users, our server with freeradius installed will be responsible. Freeradius is an implementation of the RADIUS protocol, which in turn is an implementation of the general AAA protocol. AAA is a set of tools to do the following:
Authentication - checks the validity of the login and password.
Authorization - checks for rights to perform certain actions.
Accounting - takes into account your actions in the system.
The protocol itself transmits the user name, a list of attributes and their values for it. That is, for example, the Auth-Type: = Reject attribute - reject this client, and Client-Password == "password" - compare the attribute in the request with the password value.
Generally speaking, the base of accounts and rights for them does not have to be stored on the RADIUS server, and the base can be anything - niksov users, users of the Windows domain ... but at least a text file. But in our case, everything will be in one place.
Basic setting
In this article, we will be primarily interested in the WPA2-EAP / TLS authorization method.
Almost all modern Wi-Fi access points worth more than 3 thousand rubles support the technology we need. Client devices support and even more so.
In the article I will use the following hardware and software:
- Ubiquiti NanoStation M2 Access Point
- Gentoo Server and Freeradius
- Client equipment with installed software Windows 7, Android, iOS
Configure the access point
The main thing is that the point supports the desired authentication method. It can be called differently in different devices: WPA-EAP, WPA2 Enterprise, etc. In any case, we select authentication, set the IP address and port of the RADIUS server, and the key that we entered in clients.conf when setting up Freeradius.
I will give a picture from the configured point Ubiquiti. Marked daws that need to be changed.
RADIUS server
Go to our Linux computer and install a RADIUS server. I took freeradius, and I put it on gentoo. To my surprise, there are no materials in Runet related to configuring Freeradius 2 for our purposes. All articles are quite old, refer to the old versions of this software.
root@localhost ~ # emerge -v freeradius That's it :) The RADIUS server can already work :) You can check it like this:
root@localhost ~ # radiusd -fX This is debug-mode. All information falls out on the console. Let's start to configure it.
As is usual in Linux, configuration is done through configuration files. Configuration files are stored in / etc / raddb. Let's do the preparatory actions - copy the source configs, clean the configuration from any garbage.
root@localhost ~ # cp -r /etc/raddb /etc/raddb.olg root@localhost ~ # find /etc/raddb -type f -exec file {} \; | grep 'text' | cut -d':' -f1 | xargs sed -i '/^ *\t* *#/d;/^$/d' Next, add the client - access point. Add the following lines to the / etc / raddb / clients file:
root@localhost ~ # cat /etc/raddb/clients.conf | sed '/client test-wifi/,/}/!d' client test-wifi { ipaddr = 192.168.0.1 #IP , secret = secret_key # . Wi-Fi . require_message_authenticator = no # , - D-Link } Next, add a domain for users. Make default.
root@localhost ~ # cat /etc/raddb/proxy.conf | sed '/realm DEFAULT/, /^}/!d' realm DEFAULT { type = radius authhost = LOCAL acchost = LOCAL } RADIUS domains
Here it should be noted that you can divide users by domain. Namely, the domain name can be specified in the username format (for example, user @ radius). DEFAULT means any unspecified domain. NULL - without domain. Depending on the domain (you can say the prefix in the user name), you can perform various actions, such as giving the right to authenticate to another host, whether to separate the name from the domain during login verification, etc.
And finally, add users to the / etc / raddb / users file:
root@localhost ~ # cat /etc/raddb/users | sed '10,$!d' user1 Cleartext-Password := "password1" user2 Cleartext-Password := "password2" user3 Cleartext-Password := "password3" Wow, you can start!
root@localhost ~ # radiusd -fX Our server is running and waiting for connections!
Customer setup
Let's go over the configuration of the main user devices. Our employees have clients working on Android, iOS and Windows 7. Let's make a reservation right away: since we use self-generated certificates, we need to make various exceptions and confirm actions several times. If we used the purchased certificates, maybe everything would be easier.
Everything is easier on iOS devices. Enter the username and password, click "Accept the certificate", and forward.
Screenshot from iOS
It looks a little more complicated, but in practice everything is also simple on Android. There are a few more input fields.
Screenshot from Android
Well, on Windows 7 will have a little ponastraivat. Perform the following steps:
We go to the center of wireless connections.
- Set the necessary parameters in the properties of your wireless connection
- Set the necessary parameters in the advanced settings EAP
- Set the necessary parameters in the advanced settings Additional parameters
- We connect in the taskbar to the Wi-Fi network and enter the login and password, enjoy access to Wi-Fi
Next, I present screenshots of dialog boxes specifically for people like me, whose eyes run from the Windows dialog boxes.
Windows Screenshots
Step 1
Step 2
Step 3
Step 4
Step 5
Step 2
Step 3
Step 4
Step 5
Own mini-billing
Now there is one problem left - if you want to add-remove a new user, you will have to change users and restart radius. To avoid this, connect the database and make your own mini-billing for users. Using the database, you can always jot down a simple script to add, block, change the user's password. And all this will happen without stopping the entire system.
For myself, I used Postgres, but you can choose at your discretion. I give the basic Postgres setting, without going into various permissions, passwords, and other tricks and conveniences.
First, create the database itself:
root@localhost ~ # psql -U postgres radius_wifi=> create user radius_wifi with password 1111; radius_wifi=> create database radius_wifi with owner=radius_wifi; radius_wifi=> \q Next you need to create the necessary tables. In general, with Freeradius, there is documentation on table schemas for various databases, although they are in different distributions in different distributions. I personally have it in /etc/raddb/sql/postgresql/schema.sql. Just paste these lines into psql, or just run
root@localhost ~ # cat /etc/raddb/sql/postgresql/schema.sql | psql -U radius_wifi radius_wifi Just in case I will add the schema for Postgres here:
Scheme for Postgres
root@localhost ~ # cat /etc/raddb/sql/postgresql/schema.sql | sed '/^--/d;/\/\*/d;/\*/d;/^$/d;' CREATE TABLE radacct ( RadAcctId BIGSERIAL PRIMARY KEY, AcctSessionId VARCHAR(64) NOT NULL, AcctUniqueId VARCHAR(32) NOT NULL UNIQUE, UserName VARCHAR(253), GroupName VARCHAR(253), Realm VARCHAR(64), NASIPAddress INET NOT NULL, NASPortId VARCHAR(15), NASPortType VARCHAR(32), AcctStartTime TIMESTAMP with time zone, AcctStopTime TIMESTAMP with time zone, AcctSessionTime BIGINT, AcctAuthentic VARCHAR(32), ConnectInfo_start VARCHAR(50), ConnectInfo_stop VARCHAR(50), AcctInputOctets BIGINT, AcctOutputOctets BIGINT, CalledStationId VARCHAR(50), CallingStationId VARCHAR(50), AcctTerminateCause VARCHAR(32), ServiceType VARCHAR(32), XAscendSessionSvrKey VARCHAR(10), FramedProtocol VARCHAR(32), FramedIPAddress INET, AcctStartDelay INTEGER, AcctStopDelay INTEGER ); CREATE INDEX radacct_active_user_idx ON radacct (UserName, NASIPAddress, AcctSessionId) WHERE AcctStopTime IS NULL; CREATE INDEX radacct_start_user_idx ON radacct (AcctStartTime, UserName); CREATE TABLE radcheck ( id SERIAL PRIMARY KEY, UserName VARCHAR(64) NOT NULL DEFAULT '', Attribute VARCHAR(64) NOT NULL DEFAULT '', op CHAR(2) NOT NULL DEFAULT '==', Value VARCHAR(253) NOT NULL DEFAULT '' ); create index radcheck_UserName on radcheck (UserName,Attribute); CREATE TABLE radgroupcheck ( id SERIAL PRIMARY KEY, GroupName VARCHAR(64) NOT NULL DEFAULT '', Attribute VARCHAR(64) NOT NULL DEFAULT '', op CHAR(2) NOT NULL DEFAULT '==', Value VARCHAR(253) NOT NULL DEFAULT '' ); create index radgroupcheck_GroupName on radgroupcheck (GroupName,Attribute); CREATE TABLE radgroupreply ( id SERIAL PRIMARY KEY, GroupName VARCHAR(64) NOT NULL DEFAULT '', Attribute VARCHAR(64) NOT NULL DEFAULT '', op CHAR(2) NOT NULL DEFAULT '=', Value VARCHAR(253) NOT NULL DEFAULT '' ); create index radgroupreply_GroupName on radgroupreply (GroupName,Attribute); CREATE TABLE radreply ( id SERIAL PRIMARY KEY, UserName VARCHAR(64) NOT NULL DEFAULT '', Attribute VARCHAR(64) NOT NULL DEFAULT '', op CHAR(2) NOT NULL DEFAULT '=', Value VARCHAR(253) NOT NULL DEFAULT '' ); create index radreply_UserName on radreply (UserName,Attribute); CREATE TABLE radusergroup ( UserName VARCHAR(64) NOT NULL DEFAULT '', GroupName VARCHAR(64) NOT NULL DEFAULT '', priority INTEGER NOT NULL DEFAULT 0 ); create index radusergroup_UserName on radusergroup (UserName); CREATE TABLE radpostauth ( id BIGSERIAL PRIMARY KEY, username VARCHAR(253) NOT NULL, pass VARCHAR(128), reply VARCHAR(32), CalledStationId VARCHAR(50), CallingStationId VARCHAR(50), authdate TIMESTAMP with time zone NOT NULL default 'now()' ); Great, the base is prepared. Now configure Freeradius.
Add, if it is not there, in the /etc/raddb/radiusd.conf line
$INCLUDE sql.conf Now edit /etc/raddb/sql.conf to fit your reality. I have it looks like this:
My sql.conf
root@localhost ~ # cat /etc/raddb/sql.conf sql { database = "postgresql" driver = "rlm_sql_${database}" server = "localhost" login = "radius_wifi" password = "1111" radius_db = "radius_wifi" acct_table1 = "radacct" acct_table2 = "radacct" postauth_table = "radpostauth" authcheck_table = "radcheck" authreply_table = "radreply" groupcheck_table = "radgroupcheck" groupreply_table = "radgroupreply" usergroup_table = "radusergroup" deletestalesessions = yes sqltrace = no sqltracefile = ${logdir}/sqltrace.sql num_sql_socks = 5 connect_failure_retry_delay = 60 lifetime = 0 max_queries = 0 nas_table = "nas" $INCLUDE sql/${database}/dialup.conf } Add a few new users test1, test2, test3, and ... block test3
root@localhost ~ # psql -U postgres radius_wifi=> insert into radcheck (username, attribute, op, value) values ('test1', 'Cleartext-Password', ':=', '1111'); radius_wifi=> insert into radcheck (username, attribute, op, value) values ('test2', 'Cleartext-Password', ':=', '1111'); radius_wifi=> insert into radcheck (username, attribute, op, value) values ('test3', 'Cleartext-Password', ':=', '1111'); radius_wifi=> insert into radcheck (username, attribute, op, value) values ('test3', 'Auth-Type', ':=', 'Reject'); Well, restart freeradius and try to connect. It should all work!
Of course, the billing turned out to be flawed - we do not store information on accounting anywhere (recording user actions), but we don’t need it here either. To keep accounting, you also need Wi-Fi points more than 3 thousand rubles. But even so, we can easily manage users.
What's next
In the last section, we collected our own small billing! It remains for the completeness of the picture to screw up some WEB-interface for managing the Database, add a mandatory password change once a month for krone. And if the certificate and the Wi-Fi controller of access points go bust, then you have a full-fledged corporate wireless network in your hands. But even without these costs and with little effort on your part, having made such access to your users, they will thank you so much.
useful links
Old, but partially up-to-date instruction on ixbt
WIKI FreeRadius
Used Wi-Fi Point Ubiquiti Nanostation M2
Source: https://habr.com/ru/post/170949/
All Articles