The growing number of application-layer attacks not only brings additional threats to network security but also places further strain on network access control. Enterprises want the capability to precisely identify users, ensure legitimate applications operate normally, and block applications that may bring security risks. However, IP addresses and ports are no longer sufficient to distinguish users and applications. Traditional access control policies based on quintuples cannot adapt to changes in the current network environment.
Example:
- When accessing the Internet, a user needs to enter a user name and a password for authentication.
- After authentication, the firewall starts to authorize the user and grant permissions for access to different resources, such as baidu.com or google.com.
- During user access, accounting is performed to record the user's operations and online duration.
Authentication mode:
- What I know: includes the information that a user knows (password and PIN)
- What I have: includes the information that a user has (token cards, smart cards, and various bank cards)
- What I am: includes unique biometric features that a user has (fingerprint, voice, iris, and DNA)
Authorizes users to access certain services, including public services and sensitive services.
Authorizes users to use certain commands for device management. For example, authorizes users to use only display commands but not delete or copy commands.
The accounting function covers the following aspects:
- How long do users stay online?
- How much money do users spend?
- What operations do users perform?
No authentication:
- No authentication is performed on trusted users. In most cases, this type of authentication mode is not recommended.
Local authentication:
- Configures user information, including the user name, password, and attributes of local users, on a Network Access Server (NAS). Local authentication offers fast processing and low operation cost. However, the capacity to store user information is limited by the hardware.
Server authentication:
- Configures user information, including the user name, password, and attributes, on a third-party authentication server. AAA can remotely authenticate users through the Remote Authentication Dial In User Service (RADIUS) protocol or the Huawei Terminal Access Controller Access Control System (HWTACACS) protocol.
RADIUS is one of the most common protocols used to implement AAA. It is widely applied to the NAS system and defines how user authentication and accounting information and results are transferred between the NAS and RADIUS server. The NAS transfers user authentication and accounting information to the RADIUS server. The RADIUS server receives connection requests from users, authenticates the users, and then returns authentication results to the NAS.
RADIUS uses User Datagram Protocol (UDP) at the transport layer to provide excellent real-time performance. In addition, RADIUS supports a retransmission mechanism and backup server mechanism to ensure high availability.
The process of transmitting RADIUS messages between the server and the client is as follows:
- When logging in to a network device, such as the USG or an access server, the user sends the user name and password to the network device.
- After the RADIUS client (a NAS) on this network device receives the user name and password, it sends an authentication request to the RADIUS server.
- If the request is valid, the server completes authentication and sends the required authorization information to the client. If the request is invalid, the server sends the authorization failure information to the client.
A RADIUS message contains the following fields:
- Code: refers to the message type, such as an access request or access permit.
- Identifier: refers to a string of numbers used to identify a message. Sequential messages use an incremental identifier. A request and its reply must contain the same identifier.
- Length: refers to the total length of all fields.
- Authenticator: used to authenticate the reply from the RADIUS server.
- Attribute: comprises the main content of a message and is user-specific.
The process of exchanging RADIUS messages is as follows:
- A user enters the user name and password.
- Access-Request
- Access-Accept
- Accounting-Request (start)
- Accounting (start)-Response
- The user accesses resources.
- Accounting-Request (stop)
- Accounting (stop)-Response
- Access ends.
Code: indicates the packet type, which occupies 1 byte. The definitions are as follows:
- Access-Request: indicates the authentication request process.
- Access-Accept: indicates the authentication response process.
- Access-Reject: indicates the authentication reject process.
- Accounting-Request: indicates the accounting request process.
- Accounting-Response: indicates the accounting response process.
- Access-Challenge: indicates the access challenge process.
HWTACACS: Huawei Terminal Access Controller Access Control System
The directory service is a system consisting of directory databases and a set of access protocols. The following information can be stored in the directory:
- Information about an enterprise employee, for example, a name, email address, and mobile number
- Physical information of a device, for example, the IP address, location, vendor, and purchase time
- Public certificate and security key
The features are as follows:
- Data is organized in directory mode.
- A unified access point is provided for external systems.
- Data is stored in distributed mode.
- Data query is optimized for fast read operations.
- A DN has three attributes: Common Name (CN), Organizational Unit (OU), and Domain Component (DC).
- For example, take the DN CN=admin, OU=guest, DC=domainname, DC=com. CN=admin indicates a user name, and OU=guest indicates an organizational unit in an active directory. This DN indicates that the admin object is in the guest unit of the domainname.com domain.
The authentication process is as follows:
- A user enters the user name and password to initiate a login request. The firewall establishes a TCP connection with the LDAP server.
- The firewall sends a binding request message carrying the administrator's DN and password to the LDAP server. This message is used to obtain the query permission.
- After the binding succeeds, the LDAP server returns a binding reply message to the firewall.
- The firewall uses the user name entered by the user to send a user DN search request message to the LDAP server.
- The LDAP server searches for the user based on the user DN. If the search succeeds, the LDAP server sends a search reply message.
- The firewall sends a user DN binding request message to the LDAP server. This message contains the obtained user DN and the entered password. The LDAP server checks whether the password is correct.
- After the binding succeeds, the LDAP server returns a binding reply message to the firewall.
- After the authorization succeeds, the firewall notifies the user that the login succeeds.
Local authentication
- A user sends the user name and password that identify the user to the firewall through the portal authentication page. The firewall stores the password and performs authentication. This method is called local authentication.
Server authentication
- A user sends the user name and password that identify the user to the firewall through the portal authentication page. The firewall does not store the password. Instead, the firewall sends the user name and password to a third-party authentication server for it to perform authentication. This method is called server authentication.
SSO
- A user sends the user name and password that identify the user to a third-party authentication server. After the user passes the authentication, the third-party authentication server sends the user's identity information to the firewall. The firewall only records the user's identity information but does not perform authentication. This process is called SSO.
SMS authentication
- A user accesses the portal authentication page and requests an SMS verification code. Authentication succeeds after the user enters the correct verification code on the portal authentication page. This process is called SMS authentication.
In user management, users are allocated to different user groups. They are authenticated, labelled, and assigned with different permissions and applications for the purpose of security.
Example:
Employees (users) are added to user groups. For users and user groups, network behavior control and audit can be performed, and policies can be customized on a GUI. In addition, reports are provided to present user information, and Internet access behavior analysis is performed for tracing and auditing user behavior (instead of IP addresses). This facilitates policy-based application behavior control in scenarios where users' IP addresses frequently change.
Similar horizontal groups can be used for enterprises that use third-party authentication servers to store organizational structures. For policies based on cross-department security groups, the security groups created on the firewall must be consistent with the organizational structures on the authentication servers.
Authentication domain
- Authentication domains are an important concept in the authentication process. Their configurations determine users' authentication modes and organizational structure.
- Authentication domains have different functions for users with various authentication modes
The firewall identifies the authentication domains contained in user names and assigns users that require authentication to the corresponding authentication domains. The firewall then authenticates users based on the authentication domain configurations.
The planning and maintenance of the organizational structure is critical in ensuring that differentiated network access permissions can be properly assigned to users or departments. The firewall provides an organizational structure tree that resembles a common administrative structure, which facilitates planning and management.
A user or user group can be referenced by security policies or traffic limiting policies, so that user-specific access and bandwidth control can be implemented.
If an administrator uses the default authentication domain to authenticate a user, the user needs only to enter the user name for login. If the administrator uses a newly created authentication domain to authenticate a user, the user needs to enter user name@authentication domain name for login.
Administrator: For device management, configuration, and maintenance, an administrator can log in through:
- Console
- Web
- Telnet
- FTP
- SSH
Internet access user
An Internet access user is the identity entity for network access and also a basic unit for network permission management. The device authenticates the user accessing the Internet and performs the control action specified in the policy applied to the user.
A remote access user is mainly used to access intranet resources after accessing the device through:
- SSL VPN
- L2TP VPN
- IPSec VPN
- PPPoE
For device management, and administrator can log in through:
Console
The console port provides the CLI mode for device management. It is usually used when the device is configured for the first time or if the configuration file of a device is lost.
If the device fails to start normally, you can diagnose the fault or enter the BootROM system through the console port to upgrade the system.
Web
The web UI enables you to log in to the device remotely through HTTP/HTTPS for device management.
Telnet
Telnet enables you to perform device management through the CLI.
FTP
The FTP administrator uploads and downloads files in the device's storage space.
SSH
SSH enhances information security and provides powerful authentication functions. It is used to establish a secure channel over an insecure network. In this case, the device serves as an SSH server.
Step 1: User-interface
Console:
- [USG] user-interface console 0
- [USG-ui-con0] authentication-mode aaa
Telnet:
- [USG] user-interface vty 0 3
- [USG-ui-vty0] authentication-mode aaa
Step 2: AAA view
- [USG] aaa
- [USG -aaa]manager-user client001
- [USG -aaa-manager-user-client001]password cipher Admin@123
- [USG -aaa-manager-user-client001]service-type terminal telnet ftp
- [USG -aaa-manager-user-client001]level 3
- [USG -aaa-manager-user-client001]ftp-directory hda1:
Enable the SSH service.
- [USG]stelnet server enable
- Info: The Stelnet server is already started.
Set the password of SSH user sshuser to Admin@123.
- [USG] aaa
- [USG-aaa] manager-user sshuser
- [USG-aaa-manager-user-client001] ssh authentication-type password
- [USG-aaa-manager-user-client001] password cipher Admin@123
- [USG-aaa-manager-user-client001] service-type ssh
- After the preceding configurations are complete, run the client software supporting SSH to establish an SSH connection.
Enable the web management function.
- [USG] web-manager security enable port 6666
Configure a web user.
- [USG] aaa
- [USG-aaa]manager-user webuser
- [USG-aaa-manager-user-webuser]password cipher Admin@123
- [USG-aaa-manager-user-webuser]service-type web
- [USG-aaa-manager-user-webuser]level 3
SSO of Internet access users: Users authenticated by other authentication systems do not need to be authenticated again by the firewall. The firewall can obtain information linking the authenticated users to their IP addresses to implement user-specific policy management.
This method applies to scenarios where an authentication system has been deployed before user authentication is deployed on the firewall.
- AD SSO: A user logs in to the AD domain and is authenticated by the AD server.
- TSM SSO: A user is authenticated by Huawei TSM (Policy Center or Agile Controller).
- RADIUS SSO: A user accesses the NAS which forwards the user's authentication request to the RADIUS server for authentication.
Built-in portal authentication for Internet access users: The firewall provides a built-in portal authentication page (https://Interface IP address:8887 by default) to authenticate users. The firewall forwards the authentication request to the local user database or authentication server. This method applies to scenarios where the firewall authenticates users.
- Redirected authentication: When a user accesses the HTTP service, the firewall pushes the authentication page to the user to trigger user authentication.
- User-initiated authentication: To access non-HTTP services, a user needs to proactively access the authentication page for authentication.
User-defined portal authentication: The firewall interworks with a user-defined portal server to authenticate users. For example, the Agile Controller can serve as an external portal server to authenticate users.
- When a user accesses the HTTP service, the firewall pushes the user-defined portal authentication page to the user to trigger user authentication.
Authentication exemption for Internet access users: Users can be authenticated and access network resources without entering user names and passwords. Authentication exemption does not mean that users are not authenticated. In authentication exemption, users do not need to enter users names or passwords, and the firewall can obtain information for identifying a user via their IP address to implement user-specific policy management.
- User names are bidirectionally bound with IP/MAC addresses. The firewall identifies the bindings to automatically authenticate users. This method applies to top executives.
SMS authentication: The firewall authenticates users based on verification codes. A user obtains an SMS verification code on the SMS authentication portal page provided by the firewall and enters the verification code for authentication. After passing authentication, the user logs in to the firewall as a temporary user.
- Redirected authentication: When a user accesses the HTTP service, the firewall pushes the authentication page to the user to trigger user authentication.
- User-initiated authentication: To access non-HTTP services, a user needs to proactively access the authentication page for authentication.
Remote access user authentication: The firewall authenticates VPN access users during the connection. To authenticate the VPN access users before they access network resources, you can configure secondary authentication.
- Local authentication and server authentication
Users can use AD SSO to trigger authentication on the firewall. The firewall can have SSO enabled to identify the users that have been successfully authenticated by these authentication systems. In doing so, these users do not need to enter their user names or passwords when accessing the network. The firewall supports multiple modes for obtaining user authentication success messages during AD SSO.
The AD monitor can be the AD domain controller or other devices in the AD domain.
The detailed login process is as follows:
- The user logs in to the AD domain. Then the AD server returns a login success message and delivers a login script to the user.
- The user's PC executes the login script and sends the user login information to the AD monitor.
- The AD monitor connects to the AD server to query information about the user. If the user's information is displayed, the user login information is forwarded to the firewall.
- The firewall extracts the user-IP address mapping from the user login information and adds the mapping to the online user list.
If the packets exchanged between the user and the AD server, between the user and the AD monitor, and between the AD monitor and the AD server need to pass the firewall, ensure that the authentication policies do not authenticate the packets and the security policies allow the packets through.
The detailed login process is as follows:
- A user logs in to the AD domain. The AD server records user login information into a security log.
- The AD monitor connects to the AD server through the Windows Management Instrumentation (WMI) interface provided by the AD server to query security logs in order to obtain the user login message.
- The AD monitor regularly queries security logs generated by the AD server from the time when the AD SSO is enabled.
- The AD monitor forwards the user login message to the firewall. The user goes online through the firewall.
When the firewall is deployed between users and the AD server, the firewall can obtain authentication packets. If the authentication packets do not pass through the firewall, the messages carrying authentication results from the AD server must be mirrored to the firewall.
When AD SSO is implemented in this mode:
- The firewall cannot obtain user logout messages. Users go offline only when their connections time out.
- Authentication packets may be maliciously tampered with, and user identifies may be forged. Therefore, exercise caution when using this mode.
- The firewall must use an independent Layer 2 port to receive mirrored authentication packets. This port cannot be used for other services. Management port GigabitEthernet 0/0/0 cannot receive mirrored packets.
In addition to AD SSO, the firewall also provides TSM SSO and RADIUS SSO.
After receiving HTTP packets whose destination port is 80 from an Internet access user, a firewall redirects the user to an authentication web page and triggers identity authentication. The user can access network resources after being authenticated.
The firewall supports user-defined Portal authentication. There are currently two types of user-defined Portal authentication.
SSL VPN
Users log in to the authentication page provided by the SSL VPN module to trigger authentication. After authentication is successful, the users can access the headquarters' network resources.
L2TP VPN
In automatic LAC dial-up mode: At the access phase, the LAC at the branch office triggers authentication through dial-up and establishes an L2TP VPN tunnel with the LNS. At the resource access phase, users in branch offices can trigger userinitiated or redirected authentication. After authentication is successful, the users can access the headquarters' network resources.
In NAS-initiated or client-initiated mode: At the access phase, users trigger authentication through dial-up and establish an L2TP VPN tunnel with the LNS. At the resource access phase, users in branch offices can directly access the headquarters' network resources or trigger user-initiated authentication or
redirected authentication before accessing network resources to enhance security.
IPSec VPN
After a branch office establishes an IPSec VPN tunnel with headquarters, users in the branch office can trigger user-initiated or redirected authentication. After the authentication succeeds, the users can access headquarters' network resources.
The Secure Sockets Layer (SSL) VPN, as a VPN technology based on Hypertext Transfer Protocol Secure (HTTPS), works between the transport layer and the application layer to provide confidentiality. It provides web proxy, network extension, file sharing, and port forwarding services.
The handshake procedure for SSL communications is as follows:
- The SSL client initiates a connection to the SSL server and requests that the server authenticates itself.
- The server authenticates itself by sending its digital certificate.
- The server sends a request for authentication of the client's certificate.
- After the authentication succeeds, the hash function used for the integrity check and as the message encryption algorithm are negotiated. Generally, the client provides the list of all encryption algorithms it supports, and then the server selects the most powerful one.
- The client and server generate a session key as follows:
- The client generates a random number, encrypts it using the public key of the server (obtained from the server certificate), and sends it to the server.
- The server replies with random data (when the client's key is available, the client's key is used; otherwise, data is sent in plain text).
- The hash function is used to generate a key from random data.
As shown in the figure, an enterprise has deployed a firewall as the VPN access gateway that connects the intranet to the Internet. After remote employees access the firewall through an SSL VPN, they can use the network extension service to access network resources.
Redirected authentication: When a user accesses HTTP service and the access data flow matches an authentication policy, the firewall pushes an authentication page to the user.
User-initiated authentication: To access non-HTTP services, a user needs to proactively access the authentication page for authentication. If the user accesses non-HTTP service without being authenticated, access traffic will likely be blocked by the firewall’s authentication policy.
Authentication exemption: A user can access network resources without entering a user name or password if specified in the authentication exemption policy. The firewall identifies these users based their IP/MAC address bindings.
SSO: The login of SSO users is not under the control of authentication policies, but users-pecific policy control can only be implemented when user service traffic matches an authentication policy.
The following types of traffic do not trigger authentication even if they match the specified authentication policy:
- Traffic destined for or originated by the firewall
- DHCP, BGP, OSPF, and LDP packets
- The DNS packet from an HTTP service data flow that triggers authentication. This immunity only lasts until the user is authenticated and logs in.
Portal authentication
- Portal authentication is implemented on data flows that meet conditions.
Authentication exemption
Authentication exemption is implemented on data flows that meet conditions. The firewall identifies user identities by other means. This action applies to the following scenarios:
- For top executives, having to be authenticated to obtain network access is undesirable. However, top executives have access to confidential data and therefore need higher information security than common users. You bidirectionally can bind top executives and IP or MAC addresses and configure the firewall not to implement authentication on the data flows of top executives when they access network resources using the specified IP or MAC addresses. The firewall identifies IP addresses in data flows based on the mappings between users and IP or MAC addresses.
- In an AD/TSM/RADIUS SSO scenario, the firewall has obtained user information from another authentication system and therefore exempts SSO users from authentication.
No authentication
No authentication is implemented on data flows that meet conditions. This action applies to the following scenarios:
- Data flows, such as data flows between intranets do not require to be authenticated by the firewall either.
- In an AD/TSM/RADIUS SSO scenario, a firewall does not implement authentication on the data flows between users and the authentication server.
The firewall has a default authentication policy with all matching conditions set to any and the action set to No authentication
Configure a user or user group: Before implementing user- or user group-based management, you must create a user or user group first. A user or user group can be manually configured, imported locally, or imported from a server.
Manually configure a user or user group:
- The firewall has a default authentication domain. You can create users or user groups as subordinates of the authentication domain. If other authentication domains are required, configure them first.
- This step is mandatory when you need to create user groups based on the enterprise's organizational structure and to manage network permission allocation based on user groups.
- To perform local password authentication, you must create a local user and configure the local password.
Import locally
Local import supports the import of user information in CSV files and database DBM files to the local device.
Import from server
Third-party authentication servers are used in many scenarios. Lots of companies' networks have authentication servers, which store information about all users and user groups. Importing users from the authentication server in batches refers to importing user or user group information on the authentication server to the device through the server import policy.
Configuring authentication options involves the configuration of global parameters, SSO, and customized authentication pages.
Global parameter configuration mainly applies to local authentication and server authentication. The configuration includes:
- Set the password strength, specify password change upon first login, and configure password expiration.
- Configure how to deal with authentication conflicts.
- Configure the page to which authenticated users are redirected.
- Define the protocols and ports used by the authentication interface.
- Define the maximum number of failed login attempts, lock duration after the maximum number of failed login attempts is reached, and online user timeout period.
SSO includes AD SSO, TSM SSO, and RADIUS SSO. This course details only on AD SSO.
You can customize the logo, background image, welcome message, or help message of the authentication page as required.
When an Internet access user or a remote access user who has accessed the firewall uses the redirected authentication mode to trigger authentication, the authentication policy must be used.
An authentication policy contains multiple authentication policy rules. The firewall applies them from top to bottom in a policy rule list. If attributes of a packet match all conditions specified in a rule, the firewall considers that the packet matches the rule and stops applying another rule. If the packet matches no configured rule, the firewall processes the packet based on the default policy.
The firewall has a default authentication policy with all the matching conditions set to any and the action set to not authenticate.
This section uses the RADIUS server and AD server as examples to describe how to configure servers.
When a RADIUS server is used to authenticate the user, the firewall acts as the proxy client for the RADIUS server and sends the user name and password to the server for authentication. Parameters set on the firewall must be consistent with those set on the RADIUS server.
During AD server configuration, the system time and time zone of the firewall must be the same as those on the AD server.
Group/User
Before the device can perform user-specific and user group-specific management, users and user groups must be existing on the device. You can manually create a user or user group at the Group/User node.
Creating a user group
The root group is a default group and cannot be deleted. You cannot rename the root group but can assign it with a description for identification.
All the other user groups have the same ultimate owning group, the root group.
- Choose Object > User > User/Group.
- Select an authentication domain for which the user group is created. By default, only the default authentication domain is available.
- In Member Management, click Add and select Create Group.
Creating a user
Creating a user applies to the circumstance under which users are created one by one instead of in batches. Besides all the configuration items involved in Creating Multiple Users, the operation of creating a user also includes the setting of the display name and the bidirectional IP/MAC address binding. Choose Object > User > User/Group
Expiration time
- Indicates the time when the account expires.
Allow users to share this account to log in
- If you select this option, the login name of a user can be used by multiple users to log in concurrently. That is, this login name can be used concurrently on multiple PCs.
- If you deselect this option, the login name can be used only on one PC at a time.
IP/MAC binding
- Indicates the method of binding the user and the IP/MAC address.
- If you select Unidirectional binding, the user must use the specified IP/MAC address for authentication. However, other users can also use the same IP/MAC address for authentication.
- If you select Bidirectional binding, the user must use the specified IP/MAC address for authentication, and other users cannot use the same IP/MAC address for authentication. If an IP/MAC address and a user are bidirectionally bound, the users that are unidirectionally bound to the IP/MAC address will fail to log in.
IP/MAC address
- Indicates the IP address, MAC address, or IP/MAC address pair bound to the user.
Portal authentication requires a portal server to complete the authentication. The portal server needs to provide and push an authentication page to users. Currently, the firewall can interconnect to Huawei Agile Controller or Policy Center.
If authentication on a pushed web page is used, you need to configure a corresponding security policy to allow data flows with the port being 8887 to reach the firewall.
If a firewall is deployed between the users and the AD domain controller, authentication packets must pass through the firewall. To implement SSO, configure an authentication policy to exempt the data flow from authentication. In addition, authentication packets must pass the security check of the security policy. Therefore, the administrator needs to configure the following security policy on the firewall:
- Source zone: indicates the security zone where the PC resides.
- Destination zone: indicates the security zone where the AD server resides.
- Destination address: indicates the IP address of the AD server.
- Action: indicates the policy action, which is permit in this example
When an Internet access user or a remote access user that has accessed the firewall triggers redirected authentication, the authentication policy must be configured.
The CSV file contains the login name, display name, owning group, description, password, IP/MAC binding information, binding mode, account status, and validity period.
The DBM export function exports user database files from the Ramdisk to a specified directory.
User import refers to importing user information to the device in batches and falls into local import and server import. Local import supports CSV files, and server import supports LDAP and AD server import.
Importing users in batches from a CSV file
- User import from a CSV file is performed as follows: Edit the user information (such as the login name, display name, owning group path, user description, and local password) in a CSV file, and then import the user information in the CSV file to the device memory.
- Import the user information in the CSV file exported from the device to the device memory.
- Choose Object > User > User Import.
- Click the local import tab.
Importing users in batches from the authentication server
- Third-party authentication servers are used in many scenarios. Lots of companies' networks have authentication servers, which store information about all users and user groups. Importing users from the authentication server in batches refers to importing user or user group information on the authentication server to the device through the server import policy.
- The device supports batch import of users from the AD, LDAP, and TSM servers.
- Choose Object > User > User Import. Click the server import tab.
You can view the list of online users that have already been authenticated. You can also manage these users, such as forcing an online user out.
Viewing an online user
- Choose Object > User > Online User.
- Specify the online user to be viewed. You can specify the online user to be viewed using either of the following methods:
- In Organizational Structure, click the user group to which the online user belong. All online users of the user group are displayed in Online User List.
- Use the basic search or advanced search function to find the online user. The search result is displayed in Online User List.
Forcing an online user out
- Choose Object > User > Online User.
- Specify the online user to be forcibly logged out.
- You can specify the online user to be forcibly logged out in either of the following methods:
- In Organizational Structure, click the user group to which the online user belong. All online users of the user group are displayed in Online User List.
- Use the basic search or advanced search function to find the online user. The search result is displayed in Online User List.
- In Online User List, select the online user to be forcibly logged out and click Disconnect.
- If the operation succeeds, the user is no longer displayed in Online User List.
Ref : [1]