You are here
Best Practices
MyConnection Server (MCS) is designed to be very secure out of the box, however we definitely recommend some best practices to further enhance security.
Restrict ports on the server to only those required by MCS to run both the admin interface and testing.
By default, MCS tries to bind to port 80, or 443 for HTTPS. If MCS uses another port instead you can view it in the General Configuration section.
Each test type has its own port requirements, which can also be viewed in the General Configuration section.
The defaults ports MCS uses for testing are as follows:
MCS supports the use of an SSL certificate to enable HTTPS. This tutorial will explain how to generate and apply a certificate to MCS.
It's important to note that MCS still requires HTTP access even if HTTPS is enabled. MCS network connection satellites (NCS) communicate over HTTP only as the overhead required for HTTPS affects the accuracy of testing. This does not affect the security of the admin interface or data. MCS essentially operates on the principles of a custom WAF-based web server. Meaning that MCS will validate all inbound URLs rejecting those not compliant with MCS whitelist policy rules (this includes user defined Access Control List (ACL) rules) independently of the browser conformance rules. Any non-satellite HTTP request will get redirected to HTTPS automatically.
To enable 2-factor authentication in MCS check the box in the security settings section of MCS.
When new users are created in MCS an email address is required. This email address is used to verify the 2FA OTP code.
The ACL can be used to control access to specific sections of MCS based on IP addresses or IP ranges. The ACL is also found in the security settings.
The most common usage is to enforce a login requirement. By default, MCS allows public access for non-administrative requests.
The configurations below can be applied to enforce a login requirement for all pages. The initial 6 lines grant access to the login page and its associated resources. However, access to all other pages necessitates user authentication.
MCS has the capability to host test pages. For instance, you can direct users to your MCS for conducting a VoIP test. The modification to the ACL below would enable public users to access test pages but would still mandate login for all administration pages.
The screenshots above show the full IP range being used. Mandating that only certain IPs are allowed access would further enhance security.
The MCS satellite deliberately employs HTTP as its protocol to efficiently handle a satellite infrastructure capable of scaling to over 100,000 test locations. The data gathered and reported by an MCS test is purposefully structured to exclude private information from the results dataset. For instance, all test metrics are reported solely as simple numerical values without any ownership context. Moreover, any non-result data elements, such as the public IP address, network ISP name, network type (Wi-Fi or Wired), and the session identifier (session ID), are also structured to inherently lack any ownership context. The session ID serves as an alias tag-name, providing a consistent label across one or several test results for selecting a common set of results for a unified report. For example, a session ID might be an airport's name where testing began. In automated tests that conduct multiple tests over time for baseline assessments, the session ID helps incorporate individual tests, which may span days, weeks, or months, into a single report.
Although session IDs are designed to, by default, be TAG-aliases devoid of private information, it is vital to recognize that they are also user-defined and can therefore include additional, potentially private, information. For instance, a browser-initiated test might request an email address from the user before starting, intending to send the report upon completion. If the email address is partially or entirely included in the session ID, then it would contain an element of private information. While the session ID is crucial for aggregating and reporting a common set of test results, as a best practice, it is advisable to obfuscate or omit private data.