1C-Bitrix Security Services

1C-Bitrix Website Security: Audit, Protection, Monitoring

The last serious mass hack of Bitrix sites was in summer 2022, a vulnerability in the vote module (BDU:2022-05127). Web shells were uploaded in bulk through it. The cause? Site owners hadn't updated the core in six months, and the voting module was installed "just in case." Little has changed in the approach since then: Bitrix releases a patch, and it gets applied three months later. We build security so that the gap between patch release and application is days, not months. And so that even without a patch, the site doesn't go down from a typical attack.

The "Proactive Protection" Module — Powerful, But Not Out of the Box

The security module is installed on almost every Bitrix site, but properly configured — on maybe one in five. What specifically needs to be enabled and tuned:

• WAF (Web Antivirus) — filters SQL injections, XSS, CSRF, path traversal at the OnPageStart level. The key setting is "Active Response" mode: not just logging, but blocking. In /bitrix/admin/security_filter.php, verify that all attack types are enabled and exceptions are minimal
• Activity Control (/bitrix/admin/security_iprule.php) — limits on the number of requests from a single IP. Default is 100 requests per minute. For API endpoints used by mobile apps, exceptions are needed — otherwise you'll block your own users
• 2FA — OTP via Google Authenticator. Enabled in user settings. For the "Administrators" group, we make it mandatory via OnAfterUserAuthorize — no second factor, no admin access
• File Integrity Control (/bitrix/admin/security_file_verifier.php) — hashes of system files. If someone modified a file in /bitrix/modules/ — the system will notice. We run the check daily via cron through the CSecurityFileVerifier::Verify() agent
• Stop List — b_security_filter_stoplist. Automatic IP blocking when the WAF triggers. Manual addition of subnets — when we spot scanners
• Security Log — b_event_log. Who changed what and when in the admin panel. Minimum 90 days retention. Invaluable during incident investigation

Security Audit: What Exactly We Check

Server level — this is where the holes usually are:

• phpinfo() accessible at /info.php or /phpinfo.php — found on every third project. An attacker gets the PHP version, paths, modules, configuration. We remove it
• display_errors = On in production — stack traces with file paths and table names are sent to the user's browser
• PHP functions exec, system, passthru, proc_open not disabled in php.ini. If a web shell does get uploaded — with these functions it gains full control over the server
• PHP version < 8.1 — no security updates. PHP 7.4 died in November 2022, but still lives on a quarter of projects

Application level:

• Outdated modules: vote, forum, blog — often installed but unused, yet with active handlers. We deactivate and remove them
• Custom code: grep for $DB->Query( with $_REQUEST concatenation — classic SQL injection. Should use $DB->ForSql() or D7 ORM
• File uploads: if CFile::CheckFile() isn't called or only checks the extension without MIME type — a .php file can be uploaded through the contact form
• dbconn.php and .env — must be blocked by web server rules. Verification: curl https://site.com/bitrix/.settings.php should return nothing but 403

SSL/TLS:

• Check via SSL Labs — rating A or higher
• HSTS with max-age of at least 31536000 (one year)
• HTTP -> HTTPS redirect at the Nginx level, not at the Bitrix level

Audit result — a report with priorities: Critical / High / Medium / Low. Critical issues are closed on the first day.

Treating Hacked Sites — Action Protocol

The site is already compromised — SEO spam, redirects to gambling sites, web shell in /upload/. Action sequence:

1. Isolation — take the site down, put up a maintenance page. If the malware is encrypting files or spreading — every minute counts
2. Determine the vector — access logs (access.log), error logs, b_event_log. Look for POST requests to atypical files, requests to /upload/*.php, suspicious user agents
3. Find the malicious code — grep -r "eval(base64_decode" /home/bitrix/www/ — the classic. Also look for assert(, preg_replace with the e modifier, ${"_GET"}, obfuscated variables like $GLOBALS['x46x65']
4. Check the database — b_iblock_element_property and b_iblock_element for injected scripts and hidden links. SELECT * FROM b_iblock_element WHERE DETAIL_TEXT LIKE '%<script%' AND DETAIL_TEXT NOT LIKE '%bitrix%'
5. Clean or restore — if the infection is extensive, it's easier to restore from a clean backup and apply only content changes from the database
6. Close the vulnerability — update the core, remove unused modules, fix custom code
7. Request rescanning — Google Search Console → "Request review," Yandex.Webmaster → "I've fixed everything"

DDoS Protection — Infrastructure Level

• Cloudflare / DDoS-Guard / Qrator — traffic proxying. L3/L4 attacks are filtered on their end. L7 — via rules and challenge pages. Important: after connecting, hide the server's real IP, otherwise it defeats the purpose
• Rate limiting on Nginx: limit_req_zone for /bitrix/admin/, /api/, forms. Separate limits for authenticated and anonymous users
• CAPTCHA — \Bitrix\Main\Captcha\CaptchaManager for Bitrix forms or reCAPTCHA v3 for custom ones. v3 doesn't annoy users — it works in the background
• Bot management — allow Googlebot, YandexBot (verified via reverse DNS), block scanners and scrapers by User-Agent and behavior

Backup — The Last Line of Defense

• Daily backups: files via rsync + PostgreSQL/MySQL dump via pg_dump/mysqldump
• Storage in an isolated S3-compatible storage. The key word is isolated. If backups are on the same server as the site, an attacker will delete them too
• Rotation: daily x 7, weekly x 4, monthly x 12
• Recovery testing — once per quarter we deploy a backup on a test server. A backup that can't be restored from is just a file on disk
• Monitoring: if a backup fails — Telegram alert within an hour

Monitoring — Detect Before the Client Calls

• Uptime — check every 60 seconds via UptimeRobot / Zabbix / custom script. Telegram alert + call on downtime > 5 minutes
• File monitoring — inotify (Linux) or cron + md5sum on critical directories. New .php in /upload/? Immediate alert
• Malware scanning — AI-BOLIT or ClamAV on schedule. Checking both files and the database
• SSL certificate — warning at 30/14/7 days before expiration. Let's Encrypt auto-renews via certbot, but certbot can break too
• Blacklists — checking the domain and IP in Google Safe Browsing, PhishTank, Spamhaus. Being listed = traffic loss

152-FZ and Personal Data

• HTTPS everywhere — redirect at the Nginx level
• Database encryption: passwords via \Bitrix\Main\Security\Password::hash() (bcrypt), tokens via openssl_encrypt
• Privacy policy + cookie banner (the main module supports this out of the box via COption::SetOptionString("main", "cookie_agreement", "Y"))
• Personal data access logging — who viewed customer data and when

Timelines

We work on a one-time and subscription basis with a fixed SLA. For subscription clients — a dedicated engineer who knows the project.

Checklist: 15 Points We Check on Every Project

1. 1C-Bitrix core and modules — current version, unused modules removed
2. security module active, WAF in "Active Response" mode
3. 2FA enabled for all accounts with admin access
4. /bitrix/admin/ restricted by IP or behind additional HTTP authentication
5. Password policy: minimum 12 characters, mixed case, digits, special characters
6. SSL/TLS: A+ rating on SSL Labs, HSTS enabled
7. Service files (dbconn.php, .settings.php, .env, backups, logs) — 403 from the browser
8. Permissions: 644 for files, 755 for directories. Web server is not the owner of system files
9. Security headers: Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Strict-Transport-Security, Referrer-Policy
10. File integrity control — daily check via agent
11. Backups: daily, isolated storage, recovery verification
12. b_event_log — minimum 90 days retention, regular review
13. PHP 8.1+, display_errors = Off, dangerous functions disabled
14. Uptime monitoring + alerts on file changes in /upload/
15. Reverse proxy or CDN with DDoS protection for high-traffic projects