User Login      + Register  

Securing Your Site and Services  SecureOffice  xoops  29-Nov-2020 17:00  0  315 reads

Table_of_Contents

1      Included Security Measures

2      Change Crucial Passwords from Defaults

2.1                Tech Support Account

2.2                Linux User Passwords

2.3                SecurePBX Passwords

3      Install SSL Certificates on SecureOffice

3.1                Configure Web Server SSL Certificates

3.2                Configure SME Server SSL Certificates

3.3                Configure SecurePBX SSL Certificates

3.4                Configure SecurePBX for Encrypted SIP

3.1                Install Certificate Authority (CA) Files on Clients

3.2                Configure Phones for Encrypted SIP

4      Secure all Remote Access Methods

4.1                Full Remote Access

4.2                Secure Remote Telephony

4.3                Secure PuTTY / WinSCP Remote Access

4.4                Secure Luci GUI Remote Access

5      Other Security Measures

List of Figures

Figure 1:       SecurePBX SSL/TLS Configuration

1      Included Security Measures

In addition to all standard security measures such as firewall, passwords, SecureOffice provides additional security measures.

Logtrigger is used to automatically detect invalid logins to SecureOffice and SecurePBX and automatically block the IP address (using automatically created firewall rules) attempting invalid logins. This prevents dictionary password, etc and toll fraud attacks by hackers.

2      Change Crucial Passwords from Defaults

Choose passwords that are long and hard or impossible for brute force password attacks, but easy to remember. This site has many valid password management tips, including suggesting a sequence of four or more random words (but, with meaning for you) separated by dashes. For example "your-mother-wears-army-boots" was a good password before I made it public. Another example is 'trump-lives-off-the-swamp-so-wont-drain-it". No man or machine can guess such passwords, and they have meaning (are memorable) only to you.

2.1                Tech Support Account

Default SecureOffice installation has a user called "support" which already has a strong password. This account is intended to allow SecureOffice tech support (when enabled by site owner, default disabled) to login to an installation for purposes of providing tech support. Password login to this account is disabled and requires a SSH key which only SecureOffice support personnel have.

Since tech support personnel do not have access to your local LAN and cannot directly login, the "support" account in intended to be accessed using the WAN (internet) using the method in Configure Dropbear for Secure Remote Access with a dropbear instance on port 2222 requiring SSH public key access. Access by support personnel is disabled by default using a disabled firewall entry opening port 2222.

The firewall rule is called "support-2222" and can be enabled (by you, at support request) or disabled using the OpenWrt GUI, or by directly editing "/etc/config/firewall".

When enabled, nobody but SecureOffice support personnel can login to this account due to lack of the SSH key and password required. It is recommended to leave this firewall rule disabled until requested by support and immediately disable it again once support is complete.

Some users will have security issues with the possibility of a support user, even with disabled access and want to remove this possibility. To do so, remove the dropbear instance on port 2222 ("/etc/config/dropbear"), the firewall entry ("/etc/config/firewall"), the SSH key (named "rsa-key-support" in "/etc/dropbear/authorized_keys") and delete user "support".

2.2                Linux User Passwords

Assuming SecureOffice LAN is physically secure (nobody but you and those you trust have LAN access), internal passwords such as database, and service passwords are inherently protected due to inability (strong passwords) of attackers posing as root and other users to login to access these internal accounts.

The only passwords that need changing are root and any other user (created by SecureOffice administrator - site owner) passwords. A default installation needs only the root password changed from default ("admin").

If you have a Linux VM such as SME Server, the same password considerations apply; make root and all user passwords strong.

To change a Linux user password, at a command prompt enter "passwd <user>" and follow the prompts. If <user> is omitted, the root password is changed.

2.3                SecurePBX Passwords

SecurePBX / FusionPBX uses a main password for user "admin", passwords for any additional users created and passwords for all extensions.

To change FusionPBX user passwords, using a web browser on your LAN, navigate to "<LAN IP of SecureOffice>->Services->SecurePBX->Accounts->Users", click the pencil icon of a user, enter and confirm the new password, click "Save".

To change FusionPBX extension (SIP Phone) passwords, using a web browser on your LAN, navigate to "<LAN IP of SecureOffice>->Services->SecurePBX->Accounts->Extensions", click the pencil icon of an extension, enter the new password, click "Save". The same password must be entered on the corresponding SIP device.

It is not recommended to change the FusionPBX PostgreSQL database password. To do so will break backup / restore of your configuration when SecurePBX is removed / re-installed.

If for some reason you want to change the FusionPBX PosgreSQL database password, the access credentials are in "/etc/fusionpbx/config.php".

When the password is changed in the above file, it must also be changed for PostgreSQL. Enter "su - -c "/usr/bin/psql -c \"ALTER USER fusionpbx WITH PASSWORD 'NewPassword';\"" postgres", omitting the outer quotes.

3      Install SSL Certificates on SecureOffice

Domain SSL certificates are used for site identity and encryption, so site visitors and service users can be certain the site is genuine, and communications are secure.

Certificates must be created for www.yourdomain and yourdomain (both in same certificate file). This handles the case of when your website is addressed as www.yourdomain or yourdomain. In general, domain names in certificates must exactly match the URL used to address the site. Otherwise, clients will consider your site insecure and either refuse to connect or ask for a security exception.

If not already done, acquire SSL certificates for your site by following instructions in Domain SSL Certificates.

If SSL certificates other than automatically updating LetsEncrypt certificates using "luci-app-nginx-certificates" are chosen, the certificates must be manually acquired, installed and renewed.

It is assumed that you have acquired certificate, key and certificate authority files from a certificate vendor.

If "luci-app-nginx-certificates" is not used to acquire certificates, rename or link the certificate files to "yourdomain.cer" and "yourdomain.key" and copy them to (SecureOffice) directory "/etc/ssl/domains". These are the same filenames and directory that "luci-app-nginx-certificates" automatically uses and sets. Also copy the certificate authority / chain file to "/etc/ssl/domains/fullchain.cer".

3.1                Configure Web Server SSL Certificates

If you are hosting website(s) and require them to be secure (https), your site(s) must be configured to use SSL certificates.

If the websites are hosted within VM's, the method depends on the VM OS and distribution.

To use SecureOffice SSL certificates with other (not SME-Server) virtual machines, follow section: Share SecureOffice Folders With VM, to map SecureOffice directory "/etc/ssl/domains" (containing certificates) to VM directory "/mnt/hgfs/domains", for the purpose of sharing SecureOffice SSL certificates with the virtual machine.

To use these certificates, "/mnt/hgfs/domains/yourdomain.crt", "/mnt/hgfs/domains/yourdomain.key" and "/mnt/hgfs/domains/fullchain.cer" (certificate authority / chain file) must be specified for the certificates as required by your VM OS and distribution.

If the website(s) are natively hosted (not using VM) by SecureOffice, using the built-in webserver (nginx), the location and filenames of the certificate and key files must be configured by altering the following entries in file " /etc/nginx/nginx.conf". If using "luci-app-nginx-certificates" for certificates, this step is already done.

This is a one-time configuration step. When the certificates in SecureOffice "/etc/ssl/domains" are updated, the same, updated certificates will automatically be used for your website(s).

When SSL certificates are updated, manually or automatically, virtual machines must be restarted to use the new certificates. To do so, enter "/etc/vmachines stop; /etc/vmachines start".

3.2                Configure SME Server SSL Certificates

The SME Server Wiki has an overview of certificates. The following method is adapted from the Wiki "Commercial certificates" section.

During SME-Server installation, section: Share SecureOffice Folders With VM, the SecureOffice directory "/etc/ssl/domains" (containing certificates) was mapped to VM directory "/mnt/hgfs/domains", for the purpose of sharing SecureOffice SSL certificates with SME-Server..

Using a SME Server command prompt, enter the following.

  • "config setprop modSSL crt /mnt/hgfs/domains/<yourdomain>.crt"
  • "config setprop modSSL key /mnt/hgfs/domains/<yourdomain>.key"
  • "config setprop modSSL CertificateChainFile /mnt/hgfs/domains/fullchain.cer"
  • "signal-event console-save; signal-event reboot"

This is a one-time configuration step. When the certificates in SecureOffice "/etc/ssl/domains" are automatically updated by LetsEncrypt, the same certificates will automatically be used for your website(s).

3.3                Configure SecurePBX SSL Certificates

For SecurePBX voice and video calls to be secure, in addition to using ZRTP or SRTP for media (voice/video) encryption, the SIP signaling channel must also be encrypted using SSL/TLS which requires certificates. Otherwise, passwords and SRTP encryption key information will be unencrypted, compromising security. An overview of FreeSwitch encryption and certificates is located in the FreeSwitch Wiki.

SecurePBX (FreeeSwitch) requires two SSL certificates for SSL/TLS:

  • agent.pem: Concatenation of {yourdomain}.crt and {yourdomain}.key domain SSL keys.
  • cafile.pem: The certificate authority (CA) file of your certificate supplier.

These certificates are created from standard SSL Domain Certificates and must be named "/etc/ssl/domains/fs_agent.pem" and "/etc/ssl/domains/fs_cafile.pem".

If using automatic LetsEncrypt certificates, no further configuration is required for certificates. The LetsEncrypt certificate authority certificates come pre-installed with SecureOffice.

If using other certificates, FreeSwitch must be configured to use the certificates and authority files provided by your vendor. Perform the following steps (command prompt):

  • "cat /etc/ssl/domains/{yourdomain.crt} /etc/ssl/domains/{yourdomain.key} > /etc/ssl/domains/fs_agent.pem" This creates the server certificate.
  • "ln -sf /etc/ssl/certs/{your certificate vendor certificate authority file} /etc/ssl/domains/fs_cafile.pem". This configures the FreeSwitch certificate authority (CA) file.
  • "chown -h freeswitch:daemon /etc/ssl/domains/fs_agent.pem /etc/ssl/domains/fs_cafile.pem".
  • "chmod 640 /etc/ssl/domains/fs_agent.pem /etc/ssl/domains/fs_cafile.pem"
  • The last two commands restrict certificate access to user "freeswitch".

Restart FreeSwitch: "/etc/init.d/fs/ restart" to use the new certificates.

Technical note: The FreeSwitch init script ("/etc/init.d/freeswitch") automatically determines your domain from FusionPBX configuration and creates or updates "fs_agent.pem" if it detects that "fs_agent.pem" is older than {"yourdomain.crt"}. When SSL certificates are updated, manually or automatically, freeswitch must be restarted to use the new certificates. To do so, enter "/etc/init.d/freeswitch restart" from a command prompt.

3.4                Configure SecurePBX for Encrypted SIP

Using the OpenWrt configuration GUI, navigate to "Services->SecurePBX->Advanced-Variables" and scroll down to "SIP". Display will be similar to below.

Figure 1: SecurePBX SSL/TLS Configuration

Enter the SSL/TLS version (sip_tls_version). Options are: tlsv1, tlsv1.1, tlsv1.2, sslv2, sslv23, sslv3. It is recommended to initially choose tlsv1.2 and do not change unless you later discover SIP clients which are incompatible with tlsv1.2. The SSL/TLS protocol version selection is totally dependent on client SIP phone requirements. If possible, it is recommended to select phone clients which support tlsv1.2 as opposed to downgrading protocol version (taking a security risk).

Enable "external_ssl_enable" and "internal_ssl_enable" by setting the value to "true" and "Enable" to "True".

Restart FreeSwitch by entering "/etc/init.d/freeswitch restart" at a command prompt to enable the changes.

3.1                Install Certificate Authority (CA) Files on Clients

If client connections fail due to untrusted certificates, this means that they are missing the CA file for your certificate vendor. The Certificate Authority (CA) file of your certificate vendor must be installed on the client (PC, phone). An internet search will be required to find instructions for your SIP clients.

If using LetsEncrypt certificates, the CA file is "/etc/ssl/certs/isrgrootx1.pem" or can be downloaded from LetsEncrypt certificates.

3.2                Configure Phones for Encrypted SIP

Phones which reside on the internet, outside of your local LAN, on WIFI (insecure), or unprotected by VPN need to be configured for encryption. The transport protocol must be set for TLS and it may be necessary to set the SIP port to 5061. Consult the internet or the manual for your phone to do so.

4      Secure all Remote Access Methods

A complete suite of packages is available to remotely access all elements of SecureOffice, including the xorg GUI using NoMachine / nxserver.

4.1                Full Remote Access

Full remote access uses SecureOffice as a VPN server, allowing clients to login remotely and be a client on the SecureOffice LAN, just as if you are logged in locally. This allows remote access to all LAN resources including browsing network neighborhood.

To easily have full remote access to LAN resources, configure SecureOffice as a VPN server using VPN server scripts. Alternatively, search the internet for "Openwrt VPN server".

Once the SecureOffice VPN servers are up, install the OpenVpn client configuration files (generated by above VPN Scripts) on client devices and VPN in to SecureOffice. Full instructions are available in VPN Scripts.

4.2                Secure Remote Telephony

Your local phones (on SecureOffice LAN) are already secure.

Your remote SIP device (cellphone, tablet, PC) will be a routed VPN client of SecureOffice, using full remote access (above).

Having your remote phones connected over VPN to SecureOffice prevents your cellular provider from knowing who you call and when. Assuming your remote phone client is ZRTP capable, your voice and video is already secure.

"In the cloud" SIP devices on cellular networks or connected to wireless providers / hotspots who block ports may run into no or one-way audio / video issues due to providers blocking ports or using symmetric NAT (most do) which badly break multi-port protocols such as SIP. Neglecting the security advantages of VPN, it may be necessary to use VPN to have your remote phones function at all.

Once the SecureOffice VPN server is up, install the OpenVpn client configuration files (generated by VPN Scripts) on client devices and VPN in to SecureOffice. Full instructions are available in VPN Scripts.

4.3                Secure PuTTY / WinSCP Remote Access

An alternative to using VPN for remote access (which makes all SecureOffice resources local) is to configure PuTTY / WinSCP to use SSH keys for remote access. Instructions here.

This will allow you to remotely access the SecureOffice command prompt and freely copy files between SecureOffice and the remote PC / device.

4.4                Secure Luci GUI Remote Access

An alternative to using VPN for remote access (which makes all SecureOffice resources local) is to configure Putty to use SSH keys for remote access and use Putty port forwarding. Instructions here.

5      Other Security Measures

If you want to provide internet for visitors without allowing access to your local network, follow the link to create a guest WIFI access point isolated from your network. An alternative, easier approach is to use SecureOffice custom VPN Scripts, without VPN.

Your Wifi can be further secured by only allowing specific clients to connect.

The OpenWrt Wiki has an article Secure your router's access which describes additional security measures such as port knocking which allows you to keep service ports closed until a user defined packet sequence occurs.

Rating 0/5
Rating: 0/5 (0 votes)
Votes are disable!
Print article
The comments are owned by the author. We aren't responsible for their content.

Technologies Used:

Design by: XOOPS UI/UX Team