4.7.2.9. Node Configuration

In this section, we will see the node configuration for the 2SRA use case. To follow this configuration process, it is necessary that all nodes have been previously deployed for module operation (ON Core, On Analytics, ON Sensor, VPNGW), following the official node deployment guide. See the Deployment and basic configuration section for more information.

4.7.2.9.1. ON Sensor

This section explains how to configure the ON Sensor interface so that it can receive the information sent by the VPN gateway.

4.7.2.9.1.1. Configuring ON Sensor interface - Adapter

1. Access ON Sensor via SSH

2. Execute the script /usr/share/opennac/sensor/scripts/set_vxlan.sh

sh /usr/share/opennac/sensor/scripts/set_vxlan.sh -d <eth0> -l <172.16.1.1> -n 192.168.70.1/24

Where:

• -d <eth0>: use the interface related to the IP of ON Sensor. DMZ network interface for communication with the FE.

• -l <172.16.1.1>: use the ON Sensor IP previously configured. IP of the DMZ network for communication with the FE.

• -n 192.168.70.1/24: network used for VXLAN communication.

3. Check that the FW service is stopped:

systemctl stop firewalld
systemctl disable firewalld

You can verify that the new virtual interface was added by running the following command

ip a

4.7.2.9.1.2. Configuring the ON Sensor Interface - VXLAN Tunnel

1. Access ON Sensor via SSH

2. Edit the file /opt/zeek/etc/node.cfg modifying the “interface” line with the vxlan-tap interface

[zeek]
type=standalone
host=localhost
interface=vxlan-tap

In the case of combining the VPN use case with the Visibility one, in the configuration of the node.cfg file, it will be necessary to configure each of the interfaces used by workers’ modules.

Warning

If this is the case, it is necessary to delete the configuration mentioned before.

##Below is an example clustered configuration. If you use this,
## remove the [zeek] node above.

[logger-1]
type=logger
host=localhost
#
[manager]
type=manager
host=localhost
#
[proxy-1]
type=proxy
host=localhost
#
[worker-1]
type=worker
host=localhost
interface=vxlan-tap
#
[worker-2]
type=worker
host=localhost
interface=ens224

3. Restart the service

systemctl restart zeek

4.7.2.9.2. ON Core

This section explains how to configure ON Core.

4.7.2.9.2.1. QR Code Mail Configuration

The ON Core has to be able to send users the email with the QR code needed for the 2FA (Two-Factor Authentication).

You can configure different email services. For this, you need to have the configuration data of the corporate mail service, with email account, password, server data, etc.

Here we will explain the basic configuration for SMTP Relay, and then Postfix configuration for emailing via Gmail and Office 365. In both cases will use the TCP/587 port.

4.7.2.9.2.2. Configuring SMTP Mail Relay

In this section we will configure the SMTP server in the ON Core so that it can send emails.

1. Connect via SSH to ON Core.

2. Update the system and install the necessary packages:

dnf update && dnf install postfix mailx cyrus-sasl cyrus-sasl-plain

SMTP Configuration:

There are two options for relaying the mail service: with authentication and without authentication.

When relaying without authentication, we utilize the SMTP protocol, and the configuration is as follows:

1. Configure postfix. In the relayhost section, add or modify the following lines in the /etc/postfix/main.cf` file :

relayhost=[smtp.example.com]:25
     myhostname = principal.acme.es

Where:

• relayhost: Specifies the mail relay host and port number. The hostname will be enclosed in parentheses to specify that an MX lookup is not required.

• myhostname: Hostname of the server running the postfix service.

2. Restart postfix service and enable auto startup:

systemctl enable postfix && systemctl start postfix

3. Send a test mail to verify the configuration:

mail -s "Test subject" recipient@domain.com < /dev/null

Where:

• recipient@domain.com: Replace this with the recipient’s email address.

Keep in mind that each email service will have specific configurations. In the following sections, we will provide the Postfix configurations for Gmail and Office 365.

4.7.2.9.2.2.1. Configuring Envelope Rewriting

By default, the envelope sender mail address of messages sent by OpenNAC via postfix service is set to the user apache, which is the user that runs the HTTPD service.

Depending on how the relay host’s administrator has configured it, certain security options or anti-spam rules may check if the sender mail address in the “From:” field matches the address in the envelope of the message. This can cause the relay host to reject mail messages from ON Core servers if the addresses are not identical.

As observed several times in production environments, the rejection of such messages often occurs because the standard mail address of the HTTPD user is not recognized as an authorized sender by the relay host.

To prevent this happen, we strongly recommend you perform additional steps in the postfix configuration.

Note

Perform the following configurations regardless of the type of relay host (Gmail, Office 365 or Microsoft Exchange).

1. Add a new line at the end of the /etc/postfix/canonical file, according to the example below.

// my-fixed-envelope-sender@example.org

• Replace the example email address with the actual sender email address of the organization.

2. Add the following lines to the /etc/postfix/main.cf file:

canonical_maps = regexp:/etc/postfix/canonical
canonical_classes = envelope_sender

3. Restart the postfix service:

service postfix restart

4.7.2.9.2.3. Postfix for emailing via Gmail

1. Update the system and install the necessary packages:

dnf update && dnf install postfix mailx cyrus-sasl cyrus-sasl-plain

2. Set up authentication with Gmail. Edit or create the /etc/postfix/sasl_passwd file and add the following line at the end:

[smtp.gmail.com]:587 <UserName@gmail.com>:<Password>

Where:

• username@gmail.com: mail account

• password: mail password

3. Configure postfix. In the /etc/postfix/main.cf file, apply the following configurations for the relayhost section:

relayhost = [smtp.gmail.com]:587
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_security_options =
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_CAfile = /etc/ssl/certs/ca-bundle.crt

• relayhost: Specifies the mail relay host and port number. The hostname will be enclosed in parentheses to specify that an MX lookup is not required.

• smtp_use_tls: Enables transport layer security.

• smtp_sasl_auth_enable: Enable SASL authentication.

• smtp_sasl_security_options: This should be left empty to ensure that incompatible security options are not used.

• smtp_sasl_password_maps: Specifies the password file to use. This is the file created in the Postfix configuration.

• smtp_tls_CAfile: Specifies the list of certificate authorities to use when verifying the identity of the server.

See an example of this configuration below:

4. If your mail service is NOT authenticated, you should also edit the myhostname attribute of the /etc/postfix/main.cf file with the name of your email domain.

myhostname = mydomain.tld

5. Compile and hash the contents of the /etc/postfix/sasl_passwd file:

postmap /etc/postfix/sasl_passwd
postmap hash:/etc/postfix/sasl_passwd

6. Restart the postfix service and enable autostart:

systemctl restart postfix && chkconfig --add postfix

7. In case of failure, perform the service shutdown and startup manually:

systemctl stop postfix
systemctl start postfix

Note

By default, Gmail only allows logins from secure connections.

To enable sending emails, it is necessary to change the settings in the Gmail account by enabling “Allow less secure applications”. For more information on how to do this, please review the information at the following link: https://support.google.com/accounts/answer/6010255?hl=en

8. Send a test mail to verify the configuration:

mail -s "Test subject" <recipient>@<domain.com> < /dev/null

Where:

• recipient@domain.com: Replace this with the recipient’s email address.

9. To view all mail logs and other message information:

tail -f /var/log/maillog

4.7.2.9.2.4. Postfix for emailing via Office 365

1. Update the system and install the necessary packages:

dnf update
dnf install postfix cyrus-sasl-plain mailx

2. Set up authentication with Office365. Edit or create the /etc/postfix/sasl_passwd file and set the credentials:

[smtp.office365.com]:587 <UserName>@<DomainName>:<Password>

3. Configure postfix. In the /etc/postfix/main.cf file, apply the following configurations for the relayhost section:

relayhost = [smtp.office365.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_generic_maps = hash:/etc/postfix/generic
smtp_tls_security_level = may
smtp_sasl_security_options = noanonymous

• relayhost: Specifies the mail relay host and port number. The hostname will be enclosed in parentheses to specify that an MX lookup is not required.

• smtp_sasl_auth_enable: Enable SASL authentication.

• smtp_sasl_password_maps: Specifies the password file to use. This is the file created in the previous step.

• smtp_generic_maps: Optional lookup tables that perform address rewriting on the Postfix SMTP client, typically to transform a locally valid address to a globally valid address when sending mail over the Internet.

• smtp_tls_security_level: By specifying a non-empty value, this overrides the deprecated smtp_use_tls, smtp_enforce_tls, and smtp_tls_enforce_peername parameters.

• smtp_sasl_security_options: This should be left empty to ensure that incompatible security options are not used.

See an example of this configuration below:

4. Compile and hash the contents of the /etc/postfix/sasl_passwd file:

postmap /etc/postfix/sasl_passwd
postmap hash:/etc/postfix/sasl_passwd

5. Change the file permission:

chown root:postfix /etc/postfix/sasl_passwd
chmod 640 /etc/postfix/sasl_passwd

6. Configure the /etc/postfix/generic file to be able to send email from a valid user:

/.*/ <UserName>@<DomainName.tld>

7. Change the permission of the /etc/postfix/generic file, compile, and hash:

chown root:root /etc/postfix/generic
chmod 0600 /etc/postfix/generic
postmap /etc/postfix/generic
postmap hash:/etc/postfix/generic

8. As an optional configuration, if you want to send all internal system messages to an external mailbox, change the root alias to your email address in /etc/aliases. This way, all messages sent to root will be forwarded to the system reporting address.

mailer-daemon:  postmaster
postmaster:    root
root:         <UserName>@<Domain.com>

9. Save and exit the file. Run the newaliases command to apply the changes.

10. Restart the postfix service and enable autostart:

systemctl restart postfix && chkconfig --add postfix

11. In case of failure, perform the service shutdown and startup manually:

systemctl stop postfix
systemctl start postfix

12. Send a test mail to verify the configuration:

mail -s "Test subject" <recipient>@<dominio.com> < /dev/null

Where:

• recipient@domain.com: Replace this with the recipient’s email address.

13. To view all mail logs and other message information, run:

tail -f /var/log/maillog

4.7.2.9.2.5. Configuring the RADIUS Request Authentication (OpenVPN only)

This section explains the configuration of the RADIUS Request Authentication for the OpenVPN protocol.

1. Connect via SSH to ON Core

2. Edit the file “/etc/raddb/clients.conf”. Delete the configurations that do not correspond to the client scenario and add the following configuration for the addresses that will authenticate via Radius

client <shortname> {
   ipaddr          = <ip>
   secret          = <password>
}

Where:

• ip: IP of the FE configured during the installation of the nodes.

• password: desired password.

Note

This password will be used during the creation of the authentication BackEnd in the VPNGW module.

4.7.2.9.2.6. Configuring the Huntgroups file (OpenVPN only)

In this section, we will configure the huntgroups file, which allows us to recognize VPN-type connections.

1. Connect via SSH to ON Core.

2. Edit the file “/etc/raddb/huntgroups”. Add the following line to the end of the configuration file using the IP of the VPN Gateway

vpn             NAS-IP-Address == <IP _FrontEnd>

Note

The NAS IP Address parameter will be used later, in the following configuration: VPNGW > Farm > OpenVPN > farm configuration.

3. Restart the radiusd service, to apply the latest changes.

systemctl restart radiusd

4.7.2.9.3. Configuration of Web Certificates

This section explains how to configure web certificates.

4.7.2.9.3.1. Creating the web certificate in ON Core

As reflected in the prerequisites, it is necessary to have a Web SSL certificate to avoid the bad user experience of receiving notifications in the user’s web browser and accepting exceptions.

Note

If you already have a company certificate, you can skip this step. In the case of not having a company certificate, see the instructions to obtain it through Let’s Encrypt, that allows you to generate certificates for free.

Let’s Encrypt certificates last for 3 months and must be renewed, either manually or automatically, before they expire. To make the request and generate the certificate, the frontend machine needs to have Internet access and address to port 443 through the domain.

1. Connect to the ON Core via SSH

2. Install the acme.sh script

#Download and install acme.sh
curl https://get.acme.sh | sh -s email=<email_address>

#Update bash configuration
source ~/.bashrc

3. Stop the HAProxy service and create the certificate:

#Stop HAProxy
service haproxy stop

#Generate the certificate
acme.sh --issue --standalone -alpn -d <server_domain>

4. After carrying out the previous process, the certificate and its private key will have been created in a folder with the name of the domain entered when creating it: /root/.acme.sh/<server_domain>/fullchain.cer

Before entering it in the configuration, it’s necessary to create a new file that contains both the certificate and the private key. To create this single file, go to the path where the certificate was generated and execute:

#Access the directory
cd /root/.acme.sh/<server_domain>

#Combination of certificates
cat fullchain.cer <server_domain>.key > cert_emma.pem

4.7.2.9.3.2. Configuring the Web Certificate in the VPNGW

In this step, you must configure the VPNGW HAProxy service to use the previously generated HTTPS certificate.

1. Enter the certificate in the ON Core:

   1. If we use a certificate generated by the company: Enter the certificate in the folder: “/etc/ssl/certs/” with the file name “cert_emma.pem” where the certificate and the corresponding key are located.

   2. If we use a Let’s Encrypt certificate, from the FrontEnd use the file generated at the end of step 2.3.1.

2. Enable HTTPS configuration in HAProxy:

   1. Uncomment (remove # from the start) the following lines inside the “FrontEnd” block of the “/etc/haproxy/haproxy.cfg” file:

#bind emmafront:443 ssl crt /etc/ssl/certs/cert_emma.pem no-sslv3 no-tlsv10 no-tls-tickets
#redirect scheme https code 301 if !{ ssl_fc }
#reqadd X-Forwarded-Proto:\ https

3. Restart the HAProxy service:

systemctl restart haproxy

4.7.2.9.4. ON VPNGW

This section explains how to configure the VPN Gateway.

4.7.2.9.4.1. Configuration of the HAProxy service

In this step, we will configure the HA Proxy service. This service is used to redirect web traffic from the VPN Gateway to the onprincipal component in the backend.

1. Edit the /etc/haproxy/haproxy.cfg file

2. In case you have not configured any certificate, the following lines must be commented out (add # at the beginning), this will force the use of port 80 for the connection:

#bind emmafront:443 ssl crt /etc/ssl/certs/cert_emma.pem no-sslv3 no-tlsv10 no-tls-tickets
#redirect scheme https code 301 if !{ ssl_fc }
#reqadd X-Forwarded-Proto:\ https

Remember to uncomment these lines after obtaining and configuring the certificate, so you can use port 443 with a server certificate.

To give permissions to access the Administration Portal from the public URL (not recommended) uncomment (remove # from the beginning) the following line:

#use_backend app if adminACL

1. Restart the service

systemctl restart haproxy