rkn-block-checker 0.6.0 Adds Local Web UI and Reduces False Positives on Anti-Bot Responses
The open-source utility rkn-block-checker has been updated to version 0.6.0, bringing both improved detection accuracy and a new local web interface.
Earlier releases contained a simple list of Russian-language markers used by ISP block pages, including phrases such as “доступ ограничен” and “решению роскомнадзора”. When a target returned HTTP 429 with the text “Доступ с вашего IP временно ограничен”, the tool treated the response as a Roskomnadzor stub and reported a high-confidence block. The issue surfaced most clearly on Avito, whose anti-bot system issues 429 responses to requests lacking proper cookies even when the User-Agent mimics Chrome.
Distinguishing censorship from rate limiting
The fix adds an explicit status-code check inside core.py. If the body matches a known stub marker but the status is 429, the verdict is set to DOWN with LOW confidence and a note explaining the likely anti-bot cause. Only responses that match both the textual marker and an expected block status (200 or 451) receive the HTTP_STUB verdict with HIGH confidence.
Lightweight local Web UI
Although the project began as a pure CLI tool, users requested an easier way to examine individual checks. The new interface is served by Python’s built-in ThreadingHTTPServer and a single static HTML file containing vanilla JavaScript and CSS. No external dependencies are required. Users start the server with the command rkn-check startweb or rkn-check startweb --port 8080; the service listens on 127.0.0.1:7777 by default.
Scan results are delivered as a newline-delimited JSON stream. The browser reads the ReadableStream chunk by chunk, parses each line, and immediately updates the corresponding table row. This approach avoids both WebSocket complexity and repeated polling while still providing live feedback.
Release highlights
- Full local Web UI with charts, Russian/English localization, and on-the-fly addition of custom domains
- Improved filtering of anti-bot false positives (HTTP 429)
- One-click JSON report export directly from the browser
- Zero additional dependencies beyond a standard Python installation
The complete source code remains available under the MIT license on GitHub, and the package can be installed or upgraded via pip install rkn-block-checker.
Related articles
Digital Surveillance in Your Pocket: Audit Uncovers Tracking and Weak Cryptography in 11 Top Russian Android Apps
An independent security researcher conducted a static analysis and passive logcat review of 11 popular Russian Android applications from banks, government services, marketplaces, and navigation tools. The audit identified 237 vulnerabilities in total, including six apps signed with outdated RSA-1024 or DSA-1024 keys that violate current NIST standards. VK led the risk ranking with 11 trackers and a 98/100 surveillance score, while Gosuslugi transmitted analytics signals to VK, Yandex, Google, and Huawei ecosystems. Five apps used WebRTC ICE candidate leaks to detect VPN usage, potentially bypassing user privacy protections. Only Goskluch scored low at 42.4/100 by limiting trackers to two, avoiding VPN detection, and using a compliant RSA-2048 signing key. The methodology relied solely on MobSF, jadx, and logcat without bypassing SSL pinning or requiring root access.
Amnezia VPN Survives Coordinated Russian Censorship Campaign Targeting AmneziaWG Protocol Fingerprints
Amnezia VPN has published a detailed post-mortem on the multi-wave blocking campaign conducted by Russian authorities against its Amnezia Free and Amnezia Premium services during June and July. The company describes a shift from simple protocol blocking to sophisticated fingerprinting of AmneziaWG traffic combined with infrastructure DDoS attacks and automated IP-subnet blacklisting. Engineers closed multiple detection vectors including zero-length UDP packets, fixed-size keepalive messages, handshake timing patterns, and nonce zero bytes. The incident forced accelerated migration to AmneziaWG 2.0, discontinuation of legacy client support, and development of AmneziaWG 3.0 while expanding VLESS infrastructure as a backup. Self-hosted users largely avoided direct protocol blocks but still faced subnet-level restrictions. The report highlights how Roskomnadzor now applies cumulative scoring across multiple traffic features rather than single definitive markers.
Data Masking: 8 Critical Questions Businesses and Developers Ask About Protecting Sensitive Data
Garda expert Dmitry Larin addresses common challenges in data masking during a recent webinar titled 'Data Masking: Battle of Opinions'. The discussion covers why masking remains essential even when encryption is deployed, how to preserve application functionality after anonymization, and the performance trade-offs of processing large databases such as 5 TB PostgreSQL instances. Different masking types including static, dynamic, selective, and streaming are explained with specific use cases for DevOps pipelines, external contractors, and BI systems. The article also examines why machine learning alone is insufficient for discovering personal data and why custom scripts fail at scale across heterogeneous environments like PostgreSQL and Oracle. Practical recommendations include combining masking with encryption, using deterministic transformations for deduplication, and separating replication from masking tasks to avoid production impact.
MAX Desktop Client Tested for VPN Detection on Windows, No Tracking Signs Found
A Habra user named Slava_B conducted an experiment on September 8, 2026, to determine whether the MAX desktop client on Windows could detect or route traffic through a VPN configured at the router level. The setup used a Keenetic router that directed Russian resources directly while sending other connections via an OpenConnect tunnel to a European VPS, with no VPN client or virtual adapter present in Windows itself. Monitoring tools including Process Monitor, Wireshark, TCPView, and tcpdump revealed that MAX.exe and MAX-service.exe processes communicate locally and connect to MAX/ONEME infrastructure along with AppTracer services. The application repeatedly accessed MachineGuid, computer name, proxy settings, device IDs, and microphone/camera information, though these reads may support diagnostics and anti-fraud functions. No connections appeared on the VPN interface, and the client did not attempt to reach IP-checking services, Telegram, or WhatsApp. The researcher noted that TLS traffic was not decrypted, so actual transmission of identifiers could not be confirmed, and results apply only to this router-based configuration.