RoS version 6.39rc27

Behind WiFi protection networks in Mikrotik are responsible for three tabs: Access List(/interface wireless access-list), Connect List(/interface wireless connect-list), Security Profiles(/interface wireless security-profiles).

Access List - list of rules that restrict connections other devices to your point, and also serve to manage connection parameters. (ap mode).

Example: you want to restrict connections to your access point based on MAC addresses.
Connect List- a list of rules that restrict the connection your device to other access points(station mode).

Example: you want to automatically connect your client station to the access point with the maximum signal strength (if there are several base stations).

Security Profiles - profiles of security methods and, directly, wireless network security keys are configured.

Security Profiles

Let's start with the most interesting - Security Profiles. This is where we configure encryption for our wireless points. The setup will be carried out for a home or office access point. The protection profile is set directly in the properties of the wireless interface.

When you go to the / tab interface wireless security-profiles we see this picture.

You can add your profile, I always use the standard one - why waste it =).

General tab.

Name- profile name.

If we use a standard profile, we leave it as default.

Mode- encryption mode.

• none- encryption is not used. Encrypted frames are not accepted. Widely used in guest access systems, such as providing Internet in a cafe or hotel. To connect, you only need to know the name of the wireless network.
• static-keys-required- WEP mode. Do not receive or send unencrypted frames. Compromised protocol. Cannot be used, or only in extreme cases (for older devices). Main article - .
• static-keys-optional- WEP mode. Support encryption and decryption, but also allow you to receive and send unencrypted frames. Cannot be used, or only in extreme cases (for older devices). Main article - .
• dynamic-keys- WPA mode.

To protect your wireless network ALWAYS use the mode dynamic-keys.

Authentication Types - a set of supported authentication types. The client will be able to connect to the access point only if it supports this type of authentication. Suggested options: WPA-PSK, WPA2-PSK, WPA-EAP and WPA2-EAR. The technical difference between WPA and WPA2 is the encryption technology, in particular, the protocols used. WPA uses the TKIP protocol, WPA2 uses the AES protocol. In practice, this means that the more modern WPA2 provides more high degree network protection. For example, the TKIP protocol allows you to create an authentication key up to 128 bits in size, AES – up to 256 bits. In fact, WPA2 is an improvement over WPA; WPA2 uses the AES protocol, WPA uses the TKIP protocol; WPA2 is supported by all modern wireless devices; WPA2 may not be supported by older operating systems.

The difference between WPA2-PSK and WPA2-EAR is where the encryption keys used in the mechanics of the AES algorithm come from. For private (home, small) applications, a static key (password, code word, PSK (Pre-Shared Key)) with a minimum length of 8 characters is used, which is set in the access point settings, and is the same for all clients of a given wireless network. Compromise of such a key (they spilled the beans to a neighbor, an employee was fired, a laptop was stolen) requires an immediate password change for all remaining users, which is only realistic if there are a small number of them. For corporate applications, as the name suggests, a dynamic key is used, individual for each currently running client. This key can be periodically updated during operation without breaking the connection, and an additional component is responsible for its generation - the authorization server, and almost always this is a RADIUS server.

We don’t use a RADIUS server, our employees are talkative, but we also change passwords often, so our choice is WPA2-PSK. We leave a checkmark only on it, disable all other “unsafe” protocols.

Unicast Ciphers- selection of encryption type. Clients will be able to connect to your point if they support this type of encryption. Two types supported tkip And aes-ccm. AES is a modern and more secure algorithm. It is compatible with the 802.11n standard and provides high data transfer speeds. TKIP is deprecated. It has a lower level of security and supports data transfer rates of up to 54 Mbit/s. In addition, the CCM algorithm standard requires the use of new temporary keys for each newly created session, and this is a plus for security.

We only use aes-ccm.

Group Ciphers- selection of encryption type. Your station will only attempt to connect to access points that support this type of encryption. The description is no different from the previous parameter.

We only use aes-ccm.

WPA-Pre-Shared Key, WPA2 Pre-Shared Key - key value. To set a password, use numbers, uppercase letters AND lowercase, Special symbols(%, *, @, #, $, ~). Don't forget to change your password regularly (for example, once every 15 days). Mikrotik allows you to do this with a script, I change the password in 10 offices at the same time, if you are interested, I can describe it in a separate article.

We use a complex password.

Supplicant Identity- EAP identifier, which is sent by the client at the beginning of EAP authentication. This value is used as the value for the User-Name attribute in RADIUS messages.

We do not use WPA2-EAR - we ignore the value.

Group Key Update- time how often to update the encryption key. The function does not work in station mode. In fact, you can change the value when the device fails incomprehensibly (for example, Android smartphones when going into standby mode).

Leave the value at default - 5 minutes.

Management Protection- protection against deauthentication attacks and MAC address cloning. Your own wireless network protection algorithm from Mikrotik.

• disabled- control protection is disabled.
• allowed- allow the use of protection if it is supported by the remote party.
• required- required. For the base station, establish communication only with clients that support Managment Protection. For clients - establish communication only with access points that support Managment Protection.

We don't use Managment Protection - we leave it disabled.

Management Protection Key- Managment Protection key.

The field is not active if Managment Protection is not used.

RADIUS tab.

MAC Authentication- authorization by mac address. This setting applies to those clients that are not in the access-list. The RADIUS server will use the client's MAC address as the username.

We don't tick the box.

MAC Accounting- enable MAC statistics.

We don't tick the box.

EAP Accounting- enable EAP statistics.

We don't tick the box.

Interim Update- the time interval after which the access point repeatedly requests account information from the Radius server.

The parameter cannot be changed.

MAC Format- the format in which we write MAC addresses. Available formats:

XX: XX: XX: XX: XX: XX

XXXX:XXXX:XXXX

XXXXXX: XXXXXX

XX-XX-XX-XX-XX-XX

XXXXXX-XXXXXX

XXXXXXXXXXX

XX XX XX XX XX XX

Specifies how the client's MAC address is encoded by the access point into the User-Name attribute of the RADIUS server.

The parameter cannot be changed.

MAC Mode- values:

• as-username- use only the name when authenticating with the RADIUS server.
• as-username-and-password- use a name and password when authenticating in a RADIUS server (as the User-Name attribute).

The parameter cannot be changed.

MAC Caching Time- the period of time after which the access point will cache authentication responses. The disabled value disables the cache and all responses are sent directly to the RADIUS server.

The parameter cannot be changed.

EAP tab.

EAP Methods- EAP authentication method. Values:

• eap-tls- use of built-in EAP TLS authentication. The client and server support certificates.
• eap ttls mschapv2- EAP authentication with username and password.
• passthrough- the access point will relay the authentication process to the RADIUS server.

TLS Mode- TLS verification mode. Values:

• verify certificate- check the certificate.
• dont verify certificate- do not check client certificates.
• no certificates- do not use a certificate, use the 2048 bit anonymous Diffie-Hellman key method.
• verify certificate with crl- check the certificate against CRL lists (SSL certificate revocation list).

TLS certificate- here we indicate the TLS certificate directly.

MSCHAPv2 Username- username for authentication eap ttls mschapv2.

MSCHAPv2 Password- password for authentication eap ttls mschapv2.

Static Keys tab.

This section is active if "static keys optional" and "static-keys-required" are used on the "General" tab. It is used to enter keys.

Key 0, Key-1, Key-2, Key-3- hexadecimal representation of the key. The key length must correspond to the selected algorithm (40bit-wep, 104bit-wep, tkip or aes-ccm).

Transmit Key- the access point will use the specified key to encrypt frames for clients, and it will also be used to encrypt broadcast and multicast frames.

St. Private Key- only for use in "station" mode. The access point will use the corresponding key of the selected algorithm (in hexadecimal representation of the key).

Access List

To enable access according to Access List rules, on the Interfaces tab you need to open the properties of the wireless interface, where on the Wireless tab, uncheck the Default Authenticate parameter.

After unchecking the checkbox, go to Access List and create a rule. It can be different for each client, or common to all.

MAC Address- MAC address of the device that will connect to your router. If you uncheck the Default Authenticate box and set the MAC address here, then only this device will be able to connect to the network. This is the connection restriction by MAC addresses in Mikrotik. In order for another device to be able to connect to your point, you need to add its MAC to the list of rules.

Interface- the interface to which the connection will be made. If you specify "all" - the rule will apply to everyone wireless interfaces your device.

Signal Strength Range- signal level range at which connection is possible. The setting is used in networks with seamless roaming between points. Serves to prevent your device from being held by current point access to a critically weak signal level, but re-registered to new point(with the same SSID).

Usually they set a range like “-75..120” if there are several access points in normal availability.

AP Tx Limit- limit the data transfer rate to this client. Value "0" - no restrictions.

Client Tx Limit- transmit client speed limit. Supported only on RouterOS clients.

Authentication- possibility of authorization. If you uncheck the box, the device with this MAC address, will not be able to connect to your network.

Forwarding- the ability to exchange information with other participants in the wireless network. If you uncheck this item, the user of this device will not have access to other clients of the wifi network.

Usually, on a public access point, the checkbox is unchecked to save traffic and security.

VLAN-Mode- Using VLAN Tagging, you can separate the traffic of virtual wireless access points from local clients (for example, to separate a guest network from a working one). Values:

• no-tag- do not use VLAN tagging on the wireless interface;
• use-service-tag- use 802.1ad tagging;
• use-tag- use 802.1q tagging.

VLAN-ID- VLAN identifier.
We do not use VLAN, we leave it at the default - “1”. Private Key- the ability to set a personal encryption key for a device with MAC data address. For WEP modes only.

Private Pre Shared Key- personal encryption key. Used in WPA PSK mode.

Management Protection Key- Managment Protection key. Managment Protection - protection against deauthentication attacks and MAC address cloning. Set on the "General" tab in Security Profiles.

Time- in this section you can specify the time range within which it will be possible to connect this device.

Connect List

Interface- a rule in the connect list can only be applied to one wireless interface. Here we select it.

MAC Address- indicate the MAC AP to which we will connect.

Connect- if the checkbox is checked, they will connect to an access point that matches this rule; if it is not checked, they will not connect.

SSID- will connect only to access points that have the specified SSID, if not active - to any SSID.

Area Prefix- the rule is valid for the interface with the specified prefix. Area - allows you to create a group and enable wireless devices into it, and then use specific rules for that group and all the devices in it, rather than creating separate rules for each device. This value is populated in the access point settings and can be matched with the rules in connect-list.

Signal Strength Range- will connect only to access points within the specified signal level range.

Wireless Protocol- protocol wireless communication. Values:

• any- any supported (auto-select);
• 802.11 - only standard 802.11abgn protocols. Typically used for compatibility with equipment from other manufacturers;
• nstreme- “proprietary” Mikrotik protocol, characterized by a high one-way data flow rate (RX or TX);
7) hide your network's SSID.

8) change the MAC of the wireless interface - to make it difficult to identify the device.

Bonus

A script that analyzes Mikrotik logs. If you receive a connection message with wrong password- a rule is added to the access-list, which prohibits this client (via MAC) from connecting to all of our wireless interfaces. Author EdkiyGluk, for which thanks to him.

:local pop 4
:local mac
:local wifi foreach i in=$wifi do=(
:set mac [:pick 0 ([:len ]-50)]
#:log warning $mac
if ([:len ] >= $pop) do=(
if ( = "") do=(
/interface wireless access-list add mac-address=$mac authentication=no
interface=all
}
}
}
#:log warning "FINISH"

A script in the scheduler that runs every N minutes. To ensure that allowed devices do not get banned, we add them to the Access List in advance.

Another computer post.

I recently built a WiFi network with 802.1x authentication, using certificates to identify users. Among other things, we had to configure Android devices – smartphones and tablets – to work with it. It was then that it turned out that it was impossible to find a normal howto on how to do this - the ones that existed concerned password scenarios, and I wanted to get rid of them. That’s why I decided to combine information on the issue into one post.

There is plenty written about what 802.1x is and how to use it on Windows and Linux, so here we will only talk about setting up the client on Android.

So what's the goal? It is necessary to create a network with decent encryption and reliable authentication, while it is required that the authentication be as convenient as possible for the user, but at the same time protected from the user. That is, I, as an administrator, do not want the user to be able to transfer his password or file with secret key, or connected from a device that I don't want to allow it to connect from - for example, a personal laptop. In general, darkness and dictatorship.

To do this, we do the following: a certificate with a secret key is placed on the device (phone, tablet) (a separate key for each device). Key management in Android is very primitive, but it gives exactly the minimum that we need - it allows you to import the key and use it, but not extract it back (by at least, without a password, which we are not going to give out). These keys will be issued to the access point in response to the requirement to introduce yourself.

The whole procedure fits into 4 steps:

1. Preparing “credential storage”:
Before adding any secret keys to the device, you need to prepare a storage facility for them, where the keys will be stored in encrypted form. Encryption will be based on a password, which is entered only when creating the storage. To use the secret key, you do not need to enter a password - only to export it (which, moreover, cannot be done through the regular Android UI). Therefore, we will keep this password for ourselves, and will not give it out to the user. Evil laughter is included.

[Update: alas, it won’t work. When you turn off the device, the password is lost, and you will have to enter it again to use the keys. This has both good and bad sides:
* It will not be possible to keep the password secret from the user - otherwise you will have to enter it every time you turn it on.
* This means that theoretically the user can copy the secret key from the device - which is bad from an admin point of view. But, as far as I understand, for this he needs root access. Gaining such access is troublesome, but not impossible.
* The good thing is that the password itself is not stored in flash memory - and the crypto keys that are saved are AES encrypted with this password.
* Well, besides, if the password has not yet been entered when turning it on, then this provides protection from someone else who will try to use the key without knowing the password.
]

The password can be changed later - but only if you know the current one. You can also reset the entire storage - in this case the password will be gone, and the user will be able to set his own, but with it the secret key will also be lost irrevocably, just like the secret of heather honey.

The actual process: Settings --> Location and security --> Set password. Enter the password twice. After which the “Use secure credentials” checkbox will turn on automatically.

To change the password: “Set password” again.

To reset everything to zero: “Clear storage” in the same place.

2. Importing a root certificate:
You need to upload a file to your device with a .crt extension (.cer is not accepted) and in PEM format, also known as Base-64. You can do this via USB, or via Bluetooth. The file must be copied to the /sdcard directory - the one that is visible as the root when connecting the device via USB or when viewing files through “My Files”.

Then: Settings --> Location and security -->(even though in this case the certificate is not encrypted). The certificate will be added to the list of trusted ones, and the file in /sdcard will be erased.

More convenient way: publish the certificate on some website and simply open its URL in your native Android browser (for greater reliability, use a well-known web service via https or a purely internal site). It will immediately ask whether to add the certificate to the list of trusted ones or not. In order not to type the URL manually, you can generate a QR code with it, and then simply scan it.

3. Importing a user certificate with a private key:
A file with a secret key in PKCS#12 format and with a .p12 extension is placed in /sdcard (.pfx, again, is ignored). There are many ways to create such a file - I will not list them, but I will note that it is definitely worth setting a one-time password for it, an encryption key.
Then, again, Settings --> Location and security --> Install encrypted certificates. This time you will be asked for a password. This is not the one that was specified when creating the storage, but the one that is needed to decrypt the key from the file. After entering the password, the key will be decrypted and saved again, encrypted - this time, with the vault password. The file will be erased from /sdcard, which suits us perfectly.

You can also drop a .p12 file via a URL, but I wouldn't - unlike certificates, key creep, even if encrypted, should be avoided.

4. Connection to the network itself:
After the key has been set, all that remains is the WiFi network settings. There is nothing secret in this stage; you can leave it to users by sending instructions.
So: Settings --> Wireless and network --> Wi-Fi settings. Find the network in the list, or, if the SSID is hidden, click on “Add Wi-Fi network”.
Then:



On more advanced devices, you can also specify proxy settings for each network, which is very convenient.

All. After this, the user will only have to click on the name of the grid and connect. If, through thoughtlessness, he somehow clicks on “Forget network” and erases the settings, to restore it, you just need to go through step 4 again - the procedure is not secret, the user can do it himself.

Notes:
Basically, there is also a PEAP option. The PEAP-EAP-TLS protocol is considered a little more secure - for example, the user’s certificate is sent in encrypted form over an established TLS tunnel. However, my efforts to get Android to work in this mode came to nothing. I suspect that the point is that the “Phase 2 authentication” field does not contain an option for using a user certificate - so you have to settle for EAP-TLS, which does not need any phase 2. But the difference is minimal and insignificant.

I have no idea why it is needed. In principle, the user must be identified by the CN field in the certificate.

In the first part, we learned why an enterprise should use Enterprise Wi-Fi Protected Access (WPA or WPA2) mode rather than Personal (PSK) mode. We learned that 802.1X authentication in Enterprise mode requires the use of a RADIUS server, which is included in Windows Server.

We have already installed and configured Certificate Service in Windows Server 2008. In this part, we will continue installing and configuring network policy and access services. We will then configure the wireless controllers and/or access points (APs) to use encryption as well as RADIUS settings. Next we will configure the client computers. And finally, we will be able to connect.

Installing Network Policy and Access Services roles

In previous Windows versions Server function RADIUS was provided Internet service Authenticate Service (IAS). Starting with Windows Server 2008, this is provided by Network Policy and Access Services. This includes the previous IAS services along with the new NAP component.

In the window initial setup (Initial Configuration Tasks) scroll down and select Add roles. If you closed and minimized this window, click Start > Server Manager, select Roles, and click Add Roles.

Select Network Policy and Access Services(Figure 1), and press Further.

Figure 1: Selecting to install Network Policy and Access Services roles

Select the following (Figure 2):

• Network Policy Server
• Routing and Remote Access Servers
• Services remote access(Remote Access Services)
• Routing

Figure 2: Selecting the installation of the first four options

Now you can start configuring NPS for the RADIUS function: click Start, enter nps.msc and press Enter.

For option Standard configuration(Standard Configuration) select option RADIUS server for 802.1X Wireless or wired connections(RADIUS server for 802.1X Wireless or Wired Connections)(Figure 3) from the drop-down menu.

Figure 3: Selecting a RADIUS server for 802.1X

Click Configure 802.1X.

For 802.1X connection type, select Protect wireless connections(Secure Wireless Connections)(Figure 4), and click Further.

Figure 4: Selecting wireless security

For each wireless controller and/or access point, click Add, to create new entry RADIUS client. As shown in Figure 5, you need to specify friendly names that will help you identify them among others, IP or DNS addresses and a shared secret (Shared Secret).

Figure 5: Entering information for the wireless controller or access point

These shared secrets are important for authentication and encryption. Make them complex and long, like passwords. They must be unique for each controller/AP. Later you will need to enter the same shared secrets for the corresponding controllers/APs. Remember to keep them secret, keep them in a safe place.

For Authentication Method, select Microsoft Protected EAP (PEAP) since we will be using PEAP.

Click the button Tune", select the previously created certificate and click OK.

In the window for specifying user groups (Figure 6), click Add.

Figure 6: Adding user groups that can connect

In the group selection dialogs, enter groups or click Advanced to search for available groups. If you haven't created additional groups, you may have to select Domain Users to allow users and Domain Computers to authenticate machines if your controllers/APs support them. If you receive an error message that the domain does not exist, restart the Active Directory server Domain Services and try again.

After adding the right groups click Further to continue.

In the VLAN configuration window (Figure 7), if your network (switches and controllers/APs) supports VLANs and they are configured, click Tune" to set the VLAN function.

Figure 7: Click the setup button to define VLAN settings

Review the options and click Ready.

Configuring wireless controllers and/or access points

It's time to configure your wireless controllers or access points (APs). Call the web interface by entering the IP address of access points or controllers into the browser. Then go to your wireless settings.

Select WPA-Enterprise or WPA2-Enteprise. For encryption type, select TKIP if using WPA or AES if using WPA2. Then enter the IP address of the RADIUS server that should be the one you just configured. Windows machine Sever. Enter the shared secret you created earlier for this controller/AP. Save the settings.

Installing a CA certificate on client machines

In the first part of the series, you created your own Certificate Authority (CA) and server certificate. Therefore, you need to install the CA on all client computers. In this case, the client can check the server before authentication.

If you are using a domain network with Active Directory, you may need to deploy this certificate using group policy. However, you can also install it manually.

To view and manage certificates in Windows Server 2008, call the Certificate Manager. If you saved this MMC to your computer in the first part, open it. Otherwise, follow these steps again:

1. Click Start, enter MMC and press Enter.
2. In the MMC console window, select File>Add or remove a snap-in.
3. Select Certificates and press Add.
4. Select Computer account and press Further.
5. Select Local computer , press Ready And OK.

Now expand Certificates (Local Computer Account), expand Personal and press Certificates.

As shown in Figure 8, right-click on the certificate whose "Issued To" value ends with C.A., go to point All tasks and select Export". Then follow the Export Wizard. When the wizard asks you, do not export private key, but use the DER format. You may need to export it to a flash drive so you can take it with you to client machines.

Now on the client computers, double-click on the certificate and click Install Certificate(Figure 9). Use the wizard to import the certificate into the store Trusted Root Certificate Authorities.

Figure 9: Installing a CA certificate on the client.

Configuring network settings on client computers

Now you can configure network parameters. As with installing certificates, you can promote network settings on clients using Group Policy if you are working in a domain network with Active Directory. However, you can also configure clients manually, as in our case for Windows XP, Vista and 7.

First, we manually create a network profile or preferred network entry. For Security Type select WPA-Enterprise or WPA2-Enteprise. For Encryption Type select TKIP if WPA is used or AES if WPA2 is used.

Open your network profile and select the bookmark Safety(in Vista and 7) or Authentication(in XP). In XP, check the option Enable IEEE 802.1x authentication for this network.

For Network Authentication method(in Vista and 7, as shown in Figure 10) or EAP Type(on XP), select Protected EAP (PEAP). In XP, also uncheck the options at the bottom of the window.

Figure 10: Selecting PEAP for authentication method

On Windows 7 (only), click Advanced Settings in the Security tab. Then in the advanced options window, check the option Specify authentication mode, select User Authentication and press OK to return to the Security tab.

Click the button Options(in Vista and 7) or Properties(in XP).

In the Protected EAP Properties dialog, follow these steps (Figure 11):

• Check the first option, Validate server.
• Check the second option, Connect to these servers, and enter the full names of the server computers. If necessary, double-click it in Windows Server by selecting Start > Server Manager.
• In the list window Trusted Root Certification Authorities select the CA certificate you imported.
• Select Secured password (EAP-MSCHAP v2) for the authentication method.

Figure 11: Setting PEAP properties

• Click the button Tune. If you are working in a domain network with Active Directory, it is better to check this option. Otherwise, uncheck this option so that you can enter your username and password when connecting to the network.

Finally, click OK in the windows dialog to save the settings.

And finally, connect and log in!

When the server, APs and clients are configured, you need to try to connect.

On the client computer, select a network from the list of available ones network connections. If you have not configured the client to automatically use Windows login, you will need to enter login credentials, as shown in Figure 12. Use an account on Windows Server that belongs to the group you configured earlier in the Network Policy and Access Services setup section. If you selected the Domain Users group, the Administrator account should be allowed by default.

Figure 12: Login window.

Conclusion

You should now have a network with 802.1X authentication and Enterprise encryption security, thanks to Windows Server 2008 and the RADIUS functionality it provides. We have configured the server, wireless APs, and clients to use PEAP authentication. End users will be able to sign in using their own accounts.

To manage RADIUS server settings, such as adding or removing APs, use the Network Policy Server utility: click Start>All programs> Administration Tools>Network Policy Server.

• Tutorial

From a practical point of view, it would be convenient to manage Wi-Fi networks by issuing a password to each user. This makes it easier to access your wireless network. Using the so-called WPA2 PSK authorization, in order to prevent access to a random user, you need to change the key and also go through the authorization process again on each individual Wi-Fi device. In addition, if you have several access points, the key must be changed on all of them. And if you need to hide the password from someone, you will have to give all employees a new one.

Let's imagine a situation - someone else (client, counterparty?) comes into your office, and you need to give him access to the Internet. Instead of giving him a WPA2 key, you can make a separate account for him, which can then be deleted and blocked after he leaves. This will give you flexibility in account management, and your 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.

A little theory

Once upon a time, IEEE engineers came up with the 802.1x standard. This standard is responsible for the ability to authorize a user immediately when connecting to a data transmission medium. In other words, if for a connection, for example, PPPoE, you connect to a medium (switch) and can already transfer data, authorization is needed to access the Internet. With 802.1x, you won't 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 could be RADIUS, TACACS, TACACS+, etc.

Terminology

In general, user authorization at a point can be of the following types:

• Open - available to everyone
• WEP is the old encryption. Everyone is already convinced that it shouldn’t be used at all.
• WPA - Uses TKIP as the encryption protocol
• WPA2 - AES encryption is used

Now let’s look at the options for how the access point itself finds out whether it is possible to provide the user with access to the network or not:

• WPA-PSK, WPA2-PSK - the key to access is located at the point itself.
• WPA-EAP, WPA2-EAP - the access key is checked against some remote database on a third-party server

There are also quite a large number of ways to connect the end device to the authorization server (PEAP, TLS, TTLS...). I won't describe them here.

General network diagram

For a clearer understanding, let us present general scheme work of our future scheme:

In words, when connecting to a Wi-Fi point, the client is asked to enter a login and password. Having received your login and Wi-Fi password the point transmits this data to the RADIUS server, to which the server responds with what can be done with this client. Depending on the answer, the point decides whether to give it access, reduce the speed, or something else.
Our server with freeradius installed will be responsible for user authorization. Freeradius is an implementation of the RADIUS protocol, which in turn is an implementation of the generic AAA protocol. AAA is a set of tools for doing the following:
Authentication - checks the validity of the login and password.
Authorization - checks for permission 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 him. 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 database of accounts and rights for them does not have to be stored on a RADIUS server, and the database can be anything - niks users, users Windows domain... yes, at least a text file. But in our case everything will be in one place.

Basic setup

In this article, we will be primarily interested in the WPA2-EAP/TLS authentication method.
Almost all modern points Wi-Fi access costing more than 3 thousand rubles support the technology we need. Client devices support this even more so.
In this article I will use the following hardware and software:

• Ubiquiti NanoStation M2 Access Point
• Gentoo and Freeradius server
• Client equipment with installed software Windows 7, Android, iOS

Setting up an access point

The main thing is that the point supports the right way authentication. It may be called differently in different devices: WPA-EAP, WPA2 Enterprise, etc. In any case, 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 Ubiquiti point. The items that need to be changed are marked with a checkmark.

RADIUS server

Let's go to our Linux computer and install a RADIUS server. I took freeradius and installed it on gentoo. To my surprise, there are no materials on the RuNet related to setting up Freeradius 2 for our purposes. All articles are quite old and refer to older versions of this software.
root@localhost ~ # emerge -v freeradius
That's it :) The RADIUS server may already be running :) You can check it like this:
This is debug-mode. All information is dumped onto the console. Let's start setting it up.
As is usual in Linux, configuration is done through configuration files. Configuration files are stored in /etc/raddb. Let's do the preparatory steps - copy the source configs, clean the configuration of 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, let's add a client - an 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 address of the point that will access the radius secret = secret_key #Secret key. The same will need to be installed on Wi-Fi Fi point. require_message_authenticator = no #It’s better this way, with some D-Link I couldn’t do it any other way)
Next, add a domain for users. Let's make it default.
root@localhost ~ # cat /etc/raddb/proxy.conf | sed "/realm DEFAULT/, /^)/!d" realm DEFAULT ( type = radius authhost = LOCAL acchost = LOCAL )

Domains in RADIUS

It should be noted here that you can divide users by domain. Namely, the domain can be specified in the username format (for example, user@radius). DEFAULT means any undefined domain. NULL - no domain. Depending on the domain (you can say the prefix in the username), you can various actions, how to give 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, we can start!
root@localhost ~ # radiusd -fX
Our server is running and waiting for connections!

Setting up clients

Let's go over the basic setup user devices. Our employees have clients running Android, iOS and Windows 7. Let's make a reservation right away: since we use self-created certificates, we need to make various exceptions several times and confirm actions. If we had used purchased certificates, perhaps everything would have been simpler.

Things are easier for everyone on iOS devices. Enter your username and password, click “Accept certificate”, and go ahead.

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 you will have to configure it a little. Let's take the following steps:
Let's go to the wireless connection center.

1. Set the necessary parameters in the properties of your wireless connection
2. Set the necessary parameters in the advanced EAP settings
3. Set the necessary parameters in the advanced settings Additional parameters
4. Connect to the Wi-Fi network in the taskbar and enter your login password, enjoy access to Wi-Fi

Windows screenshots

Step 1


Step 2

Step 3


Step 4

Step 5

Own mini-billing

Now there is only one problem left - if you want to add or remove a new user, you will have to change users and restart radius. To avoid this, let's connect the database and make our own mini-billing for users. Using a database, you can always write a simple script to add, block, or change a user password. And all this will happen without stopping the entire system.

For myself, I used Postgres, but you can choose at your discretion. I'm providing the basic setup of Postgres without going into the various access rights, passwords, and other tricks and conveniences.

First, let's 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, Freeradius comes with documentation on table schemas for various databases, although they are located in different places in different distributions. I personally have this 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’ll add a diagram for Postgres here:

Schema 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 let's configure Freeradius.
If it is not there, add the line to /etc/raddb/radiusd.conf

$INCLUDE sql.conf

Now edit /etc/raddb/sql.conf to suit your reality. For me 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 )

Let's add several 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, we restart freeradius and try to connect. Everything should work!

Of course, the billing turned out to be flawed - we don’t store accounting information (accounting for user actions) anywhere, but we don’t need that here either. To maintain an account, you also need Wi-Fi points that are more expensive than 3 thousand rubles. But already we can easily manage users.
radius Add tags

My goal: Create WiFi EAP configuration including CA certificate in Android program.

Problem: How to programmatically install a CA certificate (and then reference that certificate in WiFi EAP configuration)?

However, this assumes that you have already installed a CA certificate on the device. I would like to install a certificate in my application - either from resources in the application or sent from the server.

Is it possible? (The root is not an option in this case.) If so, how?

Additional Information...

I also found a way to add the certificate to KeyStore:

However, this is used specifically to create a secure socket and connect over HTTPS. I want to use a certificate for WiFi.

Unfortunately, I have yet to find a way to install the CA certificate programmatically - from within the application.

However, it is possible to install the certificate through a web browser on Android. So the solution (for now) is this: Run an intent to open a URL in a web browser that is sent directly to the CA certificate.

This works, but there are some problems:

• The user must provide a certificate. This is a problem because we are adding the WiFi configuration programmatically. So we have to ask the user to provide a certificate with the same name.
• The user must enter a password. If they don't have a password, the user will create one and enter it twice. If they have set a security password, the user will have to remember the same password and enter it.
• Assuming the user has successfully completed these steps, it remains stuck in the browser.

This leads to several questions:

• From my application there is a way to force the certificate name, user installed via browser?
• From my application, is there a way to know when the certificate installation is complete and then return focus to my application?

Just let me know if you need clarification.

3 answers

You can't install it directly because non-system apps don't have access to the keystore. There is an API for this in ICS, KeyChain.createInstallIntent(), which will launch a system dialog asking the user if they want to install the certificate. On pre-ICS, you can achieve the same thing by triggering the install intent directly using the component name (this may or may not work on all devices). Going through the browser is actually a workaround for doing the same thing.

Regarding your questions:

• you cannot specify/force a name. Why are you interested in the actual name?
• Not actually through the browser. If you are using a system intent, you can return to your activity and get a callback if you use startActivityForResult() .

I'm currently looking for solutions to the same problems. The best I've found is KeyChain.choosePrivateKeyAlias() which allows the user to choose which certificate to use for SSL. From there you can get the alias name and pass it to the corporate wifi config.