Self-Hosted Bitrix24 Security Hardening: 25-Point Checklist
Um servidor Bitrix24 on-premise mal configurado expõe dados de clientes, credenciais e estrutura interna a ataques evitáveis. Este checklist de 25 pontos cobre os controles de segurança essenciais - do ambiente de sistema ao monitoramento contínuo - organizados por prioridade de execução.
Why On-Premise Bitrix24 (Alaio) Needs Explicit Hardening
Self-hosted Bitrix24 deployments shift full security responsibility to your team, and audits of live installations consistently reveal seven critical gaps - including outdated OS environments, disabled 2FA, missing HSTS headers, and unrestricted admin panel access - that must be explicitly remediated.
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
This checklist covers five security layers - OS and network, web server, database, application, and access control - ordered from outermost perimeter to innermost controls, with each layer's checks sequenced by priority: Critical first, then High, then Medium and Low.
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 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)
Layer 1 contains 5 controls - upgrading to a supported OS, automating patches, configuring a firewall with an IP blocklist, restricting inbound ports to 80/443 plus trusted-IP SSH, and disabling root SSH login - with checks 1 and 2 rated Critical and checks 3-5 rated High priority.
| # | 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)
Layer 2 covers 5 web server controls - upgrading nginx and Apache, adding HSTS with a 31,536,000-second max-age, enforcing HTTP-to-HTTPS redirects, enabling clickjacking protection, and removing server version tokens - with check 6 rated Critical and checks 7-8 rated High priority.
| # | 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)
Layer 3 contains 5 database controls - upgrading MySQL/Percona, disabling local_infile and Query Cache, increasing innodb_log_file_size to at least 256 MB, and fixing DB structure errors - with check 11 rated Critical and checks 12-15 all rated High priority.
| # | 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)
Layer 4 covers 6 application controls - upgrading PHP, disabling display_errors in php.ini, updating and pruning modules, auditing modified core files, reviewing third-party components, and raising Proactive Protection to High - with check 16 rated Critical and checks 17 and 21 rated High priority.
| # | 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)
Layer 5 contains 4 controls - enabling 2FA for all users, restricting admin panel access to an IP allowlist, configuring RBAC by role, and scheduling recurring Security Scanner runs - with checks 22-24 rated High and check 25 rated Medium priority.
| # | 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
The priority summary table sequences all 25 checks into four tiers: 4 Critical items (checks 1, 6, 11, 16) requiring a planned maintenance window, roughly 20 High items completable in 1-3 days, Medium items running in parallel, and Low items schedulable at convenience.
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 four built-in diagnostic tools - System Check, Security Scanner, Quality Monitor, and Proactive Protection settings - all accessible from the admin panel and should be run both before and after applying the hardening checklist to establish a baseline and confirm remediation.
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
Maintaining a hardened Bitrix24 on-premise posture requires six recurring processes: monthly platform and module patching, web environment upgrades within 90 days of major security releases, weekly IP blocklist reviews, quarterly access reviews, monthly backup restore tests, and an annual full security audit.
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.
Working with a partner on self-hosting. Want the control of self-hosted Bitrix24 without running the server yourself? ACP Group can deploy and operate it for you - see managed self-hosted Bitrix24, support & maintenance plans, or request a turnkey deployment quote.
Frequently asked questions
Com que frequência devo executar uma auditoria de segurança no Bitrix24 self-hosted?
No mínimo trimestralmente em portais em produção. Execute também após cada atualização de módulos, mudança de infraestrutura ou migração de servidor. O scanner nativo do Bitrix24 é o ponto de partida - complementado por revisão manual dos arquivos modificados.
O que acontece se eu não desabilitar display_errors no PHP?
Com essa opção ativa, qualquer erro de runtime exibe no navegador caminhos de arquivos, queries SQL e informações de configuração do servidor. Isso facilita muito o trabalho de um atacante na fase de reconhecimento - é uma das vulnerabilidades mais simples de corrigir e de maior impacto.
Posso restringir o acesso ao painel administrativo por IP sem VPN?
Sim, via regras de firewall ou diretivas no nginx/Apache. Porém, em equipes distribuídas, a VPN corporativa é mais prática e segura - concentra o controle de acesso em um único ponto e evita a necessidade de gerenciar listas de IPs dinâmicos de funcionários remotos.
O 2FA é obrigatório no Bitrix24 self-hosted ou pode ser opcional?
A plataforma permite configurar o 2FA como obrigatório para todos os usuários ou apenas para grupos específicos (ex.: administradores). A recomendação é torná-lo obrigatório para toda a base de usuários, usando aplicativos OTP compatíveis.
Como identificar se arquivos do núcleo do Bitrix24 foram modificados indevidamente?
Use o 'Monitor de Qualidade' no painel administrativo do Bitrix24 - ele compara os arquivos instalados com os checksums originais do fabricante e lista todos os arquivos divergentes. Cada modificação identificada deve ser revisada e documentada.
Qual o risco de usar o Percona/MySQL 5.7 em produção com Bitrix24?
O MySQL 5.7 atingiu fim de vida (EOL) e não recebe mais patches de segurança. Além disso, configurações padrão como local_infile ativo permitem que um atacante com acesso SQL leia arquivos arbitrários do servidor. A migração para a versão 8.x é considerada crítica.
Based on real practice
This article is based on 6 internal documents from ACP Group's practice - work plans, specifications and Bitrix24 implementation cases.
Need help with Bitrix24?
ACP Group is a Bitrix24 Gold Partner. We'll review your task, estimate the effort in hours and propose a plan - free of charge.