Why On-Premise Bitrix24 Needs Explicit Hardening
Moving to a self-hosted CRM gives you full data sovereignty, but it shifts the entire security responsibility to your team. Cloud deployments benefit from vendor-managed patching and perimeter controls; on-premise portals do not. Based on security audits conducted on live Bitrix24 on-premise installations, the most common critical findings are:
- Outdated OS and web environment (nginx, Apache, PHP, database)
- PHP error display enabled in production
- Two-factor authentication (2FA) disabled for all users
- Missing HSTS headers and incomplete HTTP → HTTPS redirect
- Admin panel accessible from any IP address
- Outdated or unreviewed Bitrix24 modules
- Modified core files without documentation
The checklist below maps directly to these findings and orders items by priority: critical first, then high, then medium/low.
For context on why organisations choose on-premise in the first place, see Self-Hosted CRM: Why Choose Bitrix24 On-Premise for Data Sovereignty.
How the Checklist Is Organised
The diagram below shows the five security layers this checklist covers and how they relate to each other. Each layer's controls appear in priority order within its section.
The diagram illustrates the layered security model for a self-hosted Bitrix24 server: the OS and network form the outer perimeter, the web server and database sit in the middle tiers, and the Bitrix24 application layer — including access control and monitoring — forms the innermost rings.
flowchart TD
OS[1. OS & Network Layer]
WEB[2. Web Server Layer\nnginx / Apache]
DB[3. Database Layer\nMySQL / Percona]
APP[4. Application Layer\nBitrix24 Core & Modules]
IAM[5. Access Control & Monitoring]
OS --> WEB
WEB --> DB
DB --> APP
APP --> IAM
Layer 1 — OS and Network (Checks 1–5)
| # | Control | Priority | Effort |
|---|---|---|---|
| 1 | Upgrade OS to a supported, current release | Critical | High |
| 2 | Apply all OS-level security patches; automate updates | Critical | Medium |
| 3 | Configure a firewall; maintain and regularly update an IP blocklist for known attack sources | High | Medium |
| 4 | Restrict all inbound ports — only 80, 443 (and SSH from trusted IPs) should be open | High | Low |
| 5 | Disable root SSH login; use key-based authentication only | High | Low |
Why it matters: In a representative audit of a production Bitrix24 portal, the server was running CentOS 7 with a web environment versioned 7.5.1 — three major releases behind the current 9.0.7. The OS itself had known CVEs with no available fixes on the end-of-life branch. The recommended path is to migrate to a supported OS release and redeploy using the official Bitrix24 virtual machine image, which ships with a pre-hardened environment.
Layer 2 — Web Server: nginx and Apache (Checks 6–10)
| # | Control | Priority | Effort |
|---|---|---|---|
| 6 | Upgrade nginx and Apache to current stable releases | Critical | High |
| 7 | Add HSTS header (Strict-Transport-Security: max-age=31536000; includeSubDomains) |
High | Low |
| 8 | Enforce HTTP → HTTPS redirect at the nginx/Apache level | High | Low |
| 9 | Enable clickjacking protection (X-Frame-Options: SAMEORIGIN or Bitrix24's built-in frame-usage protection) |
Low | Low |
| 10 | Remove or restrict server version tokens in response headers (server_tokens off in nginx) |
Medium | Low |
HSTS in practice: The absence of HSTS allows protocol-downgrade attacks. Adding the header takes under five minutes — edit the nginx server block for the portal's HTTPS virtual host. Verify the existing HTTP → HTTPS redirect is unconditional; a common misconfiguration leaves direct IP access over HTTP unredirected.
Layer 3 — Database (Checks 11–15)
| # | Control | Priority | Effort |
|---|---|---|---|
| 11 | Upgrade MySQL/Percona to a current supported version | Critical | High |
| 12 | Disable local_infile in the database configuration |
High | Medium |
| 13 | Disable Query Cache (deprecated and a potential information-leak vector in older MySQL) | High | Medium |
| 14 | Increase innodb_log_file_size to at least 256 MB (default 64 MB is undersized for typical Bitrix24 DB workloads) |
High | Medium |
| 15 | Fix database structure errors — run the built-in Bitrix24 DB integrity check and resolve remaining issues manually | High | Medium |
From a real audit: A 28 GB production database was running Percona Server 5.7 (recommended: 8.0), with local_infile = ON, query cache enabled, and innodb_log_file_size set to 64 MB. The Bitrix24 system check reported six database structure errors, five of which could be fixed automatically. The combination of an outdated engine and misconfigured parameters created both a stability and a security risk.
Note: Always take a full database backup before changing InnoDB log file parameters. Resizing
innodb_log_file_sizerequires a clean server shutdown and file removal on older MySQL versions.
Layer 4 — Bitrix24 Application Layer (Checks 16–21)
| # | Control | Priority | Effort |
|---|---|---|---|
| 16 | Upgrade PHP to the current supported version; keep Bitrix24 web environment up to date | Critical | High |
| 17 | Disable display_errors and display_startup_errors in php.ini |
High | Low |
| 18 | Update all Bitrix24 modules via the admin panel; remove unused modules | Medium | Low |
| 19 | Audit all modified core files; document legitimate changes and remove unauthorised ones | Medium | Medium |
| 20 | Review and validate any third-party or custom components (undocumented components should be disabled pending investigation) | Medium | Low |
| 21 | Raise the Bitrix24 Proactive Protection level to "High"; enable the built-in web antivirus if the performance trade-off is acceptable | High | Medium |
PHP error exposure — a critical finding: With display_errors = On in production, a request that triggers an error can leak full file system paths, SQL query fragments, and internal configuration details to any visitor. This is classified as a high-severity finding because it turns routine application errors into active reconnaissance data for an attacker.
Core file integrity: In one audit, 23 files out of 109,188 had been modified (0.02%), spanning the CRM, IM, extranet, location, socialnetwork, tasks, and vote modules. While the overall modification level was rated "low", undocumented core changes are a supply-chain risk — they may break on the next platform update, or conceal backdoor logic. Every modified file should be compared against the vendor baseline and either justified in a change log or reverted.
If you are planning a fresh installation or migration to on-premise, the Bitrix24 Onboarding Questionnaire: 50+ Questions to Ask Before You Start covers the infrastructure decisions that affect your security baseline from day one.
Layer 5 — Access Control and Authentication (Checks 22–25)
| # | Control | Priority | Effort |
|---|---|---|---|
| 22 | Enable two-factor authentication (2FA / OTP) for all users, especially administrators | High | Low |
| 23 | Restrict access to the Bitrix24 admin panel to a defined IP allowlist | High | Medium |
| 24 | Configure role-based access control (RBAC): limit what managers, supervisors, and administrators can see and edit | High | Medium |
| 25 | Re-run the Bitrix24 Security Scanner after all fixes; schedule recurring scans | Medium | Low |
2FA is the highest-ROI single control: It is rated "high importance / low effort" — implementation takes roughly 30 minutes for the whole portal using the Bitrix24 OTP application. Yet in practice it is frequently disabled on production portals, leaving credential-stuffing attacks unblocked.
IP restriction on the admin panel: Limiting /bitrix/admin/ (and ideally the entire portal) to a VPN or office IP range eliminates the entire class of brute-force and exploit-scanning attacks that target exposed admin interfaces. This is straightforward to implement in nginx with an allow/deny block.
RBAC matters beyond security: Proper role configuration — managers see only their own deals, team leads see their department, admins see everything — is also a data governance requirement under most regional data protection regulations. For CRM-specific role setup examples, see the Bitrix24 Implementation Cost & Timeline: Real Data from 1,300+ Projects article, which discusses scope decisions that affect role complexity.
Priority Summary Table
Use this table to sequence remediation work. Address all Critical items before moving to High.
| Priority | Checks | Typical effort |
|---|---|---|
| Critical | 1, 6, 11, 16 | Planned maintenance window; high effort |
| High | 2–5, 7–8, 12–15, 17–18, 21–23 | 1–3 days total |
| Medium | 19–20, 24–25 | Ongoing; can run in parallel |
| Low | 9–10 | Quick wins; schedule at convenience |
Running the Built-In Bitrix24 Security Audit
Bitrix24 on-premise ships with several diagnostic tools accessible from the admin panel:
- System Check (
/bitrix/admin/site_checker.php) — validates web environment versions, PHP configuration, and database structure. - Security Scanner — scans for known threat signatures. Note: if the scanner terminates prematurely with a status error, resolve PHP configuration and cache issues first, then re-run. If the problem persists after environment updates, open a ticket with Bitrix24 support.
- Quality Monitor — detects modified core files across all installed modules.
- Proactive Protection settings — configure WAF-level rules, set the security level for the admin group, and enable the web antivirus module.
Run all four tools before and after applying the checklist to establish a baseline and confirm remediation.
After Hardening: Ongoing Maintenance
Security hardening is a point-in-time activity; maintaining posture requires process:
- Patch cadence: Check for Bitrix24 platform and module updates at least monthly.
- Web environment updates: Track nginx, Apache, PHP, and database release notes; plan upgrades within 90 days of a major security release.
- IP blocklist hygiene: Review and refresh firewall blocklists weekly; consider integrating a threat-intelligence feed.
- Access review: Quarterly review of user roles and admin-panel access lists; disable accounts for departed employees promptly.
- Backup verification: Monthly test restore from backup — a backup you have never restored is unproven.
- Re-audit: Schedule a full security audit annually, or after any significant customisation or infrastructure change.
For teams evaluating whether on-premise is the right choice compared to cloud, the Bitrix24 vs HubSpot: An Honest Comparison for SMBs article includes a total-cost and security-responsibility breakdown that is relevant to this decision.