ManticoreSearch Publishes Detailed Checklist for Enabling Authentication in Production
ManticoreSearch has published a comprehensive checklist for implementing authentication in production environments. The guide warns that the “set and forget” approach rarely works and outlines a structured process for enabling auth while minimizing disruption.
The document distinguishes between three main topologies: standalone nodes, setups with distributed tables and remote agents, and replication clusters. Each topology requires different preparation steps before authentication is activated.
Inventory and Preparation
Before any configuration changes, administrators are instructed to inventory every client accessing Manticore Search, including search frontends, data-loading workers, cron jobs, BI dashboards, and backup scripts. For each client, teams must record the protocol, target tables, and required permissions.
Additional checks include confirming whether the deployment uses RT-mode or plain-mode, verifying the pid_file setting, and ensuring all nodes support the same authentication protocol. Backups of the data directory, configuration files, manticore.json, and any existing authentication store are mandatory.
User Creation and Least Privilege
The checklist emphasizes creating users for specific tasks rather than broad access. Examples include separate accounts for read-only search operations, data ingestion, schema migrations, and security administration. Each user receives only the minimum rights required, such as GRANT read ON 'products' or GRANT replication ON 'posts'.
Administrators are advised to test both allowed and denied actions for every account. Bearer tokens returned by CREATE USER or TOKEN commands must be stored securely and never left in logs or command history.
Staging Tests and Production Rollout
Testing must first occur in a staging environment that mirrors the production topology. Configuration examples are provided for both RT-mode (auth = 1) and plain-mode (auth = /var/lib/manticore/auth.json).
For production rollout, the guide recommends performing the change inside a planned maintenance window. After enabling authentication, all clients without credentials will be rejected. Teams must update SQL connections with usernames and passwords and configure HTTP clients to use either Basic authentication or Bearer tokens.
Special procedures exist for distributed and replication scenarios to ensure identical authentication stores are deployed across nodes and that cluster users are correctly registered before nodes are restarted.
Related articles
Rostelecom Outage Triggers 29-Minute Mass Disruptions Across Russian Internet Services
A 29-minute failure in Rostelecom's data transmission network on August 6 caused widespread access problems to Russian online services. The operator quickly rerouted traffic to backup equipment, restoring normal operations without revealing the root cause. Users reported issues connecting to marketplaces, banks, social platforms, IT company services and other telecom providers. The majority of complaints originated from Rostelecom's own subscribers who experienced connection and service access failures. Although the incident remained brief and did not escalate into prolonged digital disruption, it highlighted the heavy reliance on a single major provider. The event demonstrated how even a short technical problem at a large operator can simultaneously affect access to stores, financial services and everyday online platforms.
Read-Only Utility Automates Detailed Audits of UserGate NGFW Firewall Policies
A cybersecurity specialist at Gazprom CPS developed a read-only utility to analyze large-scale UserGate NGFW firewall policies without making any configuration changes. The tool connects via the UserGate XML-RPC API to collect rules, statistics, zones, network lists, services, users, and groups, then normalizes the data into a unified model for analysis. It performs eleven independent checks grouped into lifecycle, overly permissive access, observability, and documentation categories, flagging rules that have not fired recently, allow management ports broadly, lack logging, or have empty descriptions. Results are exported to a navigable Excel report featuring a rules-by-checks matrix, human-readable object names, and editable manual verdicts such as OK, requires attention, or false positive. The first full run on a production policy with over 1000 rules and 4500 related objects took 24 minutes and highlighted 39 percent of rules for review, with more than half showing multiple red flags. The approach preserves the original snapshot in JSON for repeatable offline analysis and comparison over time.
Internet Outages Disrupt Access to Russian Websites and Applications Across Multiple Regions
Users in several Russian regions reported widespread connectivity problems where internet access appeared available but failed to load most domestic websites and online services. Affected areas include Saint Petersburg along with Nizhny Novgorod, Rostov, and Tyumen regions according to reports compiled by the Telegram channel Baza. Connections remained technically active yet produced repeated errors when attempting to reach Russian sites, mobile applications, and web-based platforms. The precise scale of the disruption remains undetermined and it is unclear whether the incidents stem from a single technical fault or simultaneous failures among multiple network operators. No official statements have been issued regarding the root causes or expected restoration timelines. Individuals affected continue to refresh pages and restart applications while waiting for services to recover.
Step-Up Authentication vs 2FA: Implementing Additional Verification for Sensitive Operations in Corporate Systems
Traditional two-factor authentication secures only the initial login, leaving active sessions vulnerable to misuse during sensitive tasks such as accessing payroll data. Step-Up Authentication addresses this by requiring extra verification at the moment of critical actions rather than at login. The article details how one project moved beyond standard Identity Provider features in WSO2 by building a dedicated PIN-code service and gateway-2fa microservice. This approach uses signed cookies with TTL controls and JWT cross-checks to enforce elevated trust levels without disrupting normal user flows. The solution aligns with Zero Trust principles and was monitored via Matomo and ELK for usage and performance metrics. Key implementation considerations include balancing TTL duration, encrypting stored PINs, and conducting load testing before deployment.