Skip to content

Web Facility Security

Security details specific to the web facility.

General security details can be found on the KYNGIN security page

KYNGIN Dedicated Servers

  • All web hosts are held inside dedicated security containers. Each security container is a dedicated server custom assembled and tuned for this facility type, fully independent from other web servers.

  • The PHP and Apache processes change ownership to the respective users during page requests giving each host a dedicated username / password and file ownership permissions.

  • Each Apache and PHP process has dedicated Memory and CPU allocations assigned per host as to not allow for noisy neighbor effects for hosts located on the same server.

  • All file permissions are managed by KYNGIN, proactively safe. If you ever need to update file permissions, please use the convenient file system permission repair utility.

  • All websites hosted within KYNGIN use a free option for TLS provided by Let's Encrypt. Every website needs to be encrypted using TLS, without question. KYNGIN not only makes this very convenient and easy to use, but also handles automated renewals every 60-90 day. Additionally, KYNGIN offers a push button option to force TLS connectivity by automatically redirecting all HTTP requests to HTTPS, an option that also should be used unless a custom alternative is provided within the website.

  • We keep up on the latest standards related to TLS security and always deploy the latest configurations. You can expect that all websites hosted with KYNGIN (by default) support A+ certificate by Qualys SSL Labs. We offer options for reduced security to increase compatibility under certain circumstances, but by design and recommendation, we keep all TLS encryption highly security by using the latest standards.

  • KYNGIN proactively upgrades all website hosting servers very quickly upon locating audit concerns. We provide a custom build server which continuously runs many CPU cores compiling software (80 CPU cores + 256GB ram, at the time of this writing) so we can provide the latest updates for all of our primary architectures. Very often, our update servers provide upgrades days before official repositories have updates in queue.

  • When a compromise or event failure does happen, KYNGIN offers a convenient point-in-time recovery option to restore your website to a previous date. These dates are immutable snapshots performed on an automatic schedule every morning @ 2AM CST, or manually by website administrators using the tools located at KYNGIN.NET.

Per-Host Security Recommendations

  • Disable PHP if possible. This isn't a common option, but for some websites, such as this one www.kyngin.info, PHP is not necessary. KYNGIN.net offers a very quick option to disable PHP inside the PHP settings of each website host. If you can do this, you'll eliminate most exploits.

  • If an SQL database is unnecessary, don't use one. SQL Injection attacks can't exactly happen if there isn't any SQL. This, like the previous option, isn't a common case, but again if possible, please do so.

  • Disable SSH / SFTP access if it's unnecessary. KYNGIN disables all SSH access after 72 hours, and SFTP access can be disabled by 'locking' an account.

  • Validate all form entries with some form of CAPTCHA or login requirements.

  • Reduce your attack surface considerably by only allowing regional connectivity to your website. A vast majority of attacks come from regions outside of the United States where our legal system is of little use or tracking attackers would be too costly in time and resources. KYNGIN offers a GeoIP firewall feature that allows individual websites to be accessed by specific countries or continents. KYNGIN matches connected IP's with a local high speed database provided by MaxMind. This solution is considerably faster than any in-website connectivity GeoIP matching (plugins / .htaccess lists / etc), and also is beneficial in that the databases are all stored locally on-premise at our facility, meaning no 3rd parties can use any of this data to monitor your website visitors.

  • Require a challenge response or other security limiter on website login pages to eliminate brute force attempts. (Mostly necessary for low hanging fruit target CMS such as wordpress.)

  • Require a challenge response or other security limiter on e-mail forms to eliminate spam and reduce the possibility of your website becoming an e-mail relay. (Mostly necessary for low hanging fruit target CMS such as wordpress.)

Security Recommendations

  • Disable any modules specific to Apache or PHP that are unnecessary. This currently is a manual process within KYNGIN, but we do have some automated variants of this in the works.

  • Always stay up to date with core CMS as well as plugins. Out of date, and specifically EoL (end of life) or abandoned software is asking for a security compromise. You can safely assume software past its EoL or software that is abandoned will not pass any security audit. For all security analysis intents and purposes it should be considered 'compromised'.

  • If software is abandoned, or unmaintained, please find a replacement as soon as possible. This software may work fine for awhile, but once compromised you'll be forced to replace the software as well as clean up the mess.

  • Eliminate as many 3rd party 'plugins' or add-ons as possible. These plugins are never audited to the degree of the first party product during rollout. To clarify, if you aren't using them, delete them, now.

  • If possible, build your own plugins or solutions where you can. This requires more maintenance, but by design will allow you to be more intimately involved with the security and performance process.

Security Recommendations specific to Wordpress

  • Prevent brute force for logins - CAPTCHA plugin or IP allowances via .htaccess are the easy solutions.

  • Prevent access to xmlrpc.php if possible, we see a considerable amounts of requests for this file - wasted CPU and limiting website resources. You can use a plugin for wordpress if you are short on time, but a better solution is to use .htaccess for performance, something like:

<Files xmlrpc.php>

order deny,allow

deny from all

</Files>

(This won't slow don't every request to your website like a plugin will.)

  • If you've activated the debug log to find a problem, please deactivate it. These logs grow very quickly and reduce the overall write performance of your website and server.

  • Use a 3rd party security application such as defender security or Wordfence or to watch for and eliminate suspicious activity.

Stability Recommendations

  • Do not use any form of 3rd party auto-upgrade scripts. Upgrade each website plugin manually and tests for changes. Largely, upgrades go cleanly if the websites are running up-to-date software (both front-end and back-end),

  • Proactively watch error logs. KYNGIN has a built-in error log analytic feature, showing which sites are producing the most errors and how often. Or download these logs in the websites home /log directory, and decompress (see next bullet point).

  • Proactively watch access logs. All access/error logs are compressed daily using zstd compression. You can decompress these using command line tools for mac (homebrew/macports) / unix (your distro package manager) / windows (https://github.com/facebook/zstd/releases/ - select release title -> scroll down to download binary zstd.exe), use a 3rd party tool such as peazip.

  • For realtime watching of access logs, which allows determination of many issues as they are happening use apachetop. SSH into your web server, and watch the log using the apachetop command, which provides a very nice list of requests happening in real time:

cd /home/host_uuid/log/

apachetop -f ./*.access.log

apachetop is installed on all KYNGIN web servers)