We know the infrastructure.
No installation without knowing where the traffic passes, what services are exposed and what constraints must be respected.
Serious protection is activated in stages, not blindly.
We analyse the environment, prepare deployment, observe traffic and activate agreed policies. Each step has a goal, a verification and a way back.
Preliminary verificationChecked RolloutG Tech Group Management
We observe before enforcing stricter controls.
When appropriate, we start to observe, collect events and tune policies against real behaviour.
Protection remains managed.
State, events, rules and updates converge into the console and follow the agreed service.
The path
Six stages, from assessment to ongoing management.
The sequence can adapt to architecture, but no critical phase is skipped.
- 01
Analysis
We collect technical data.
Operating system, panel, web server, DNS, TLS, proxy or CDN, number of sites, traffic, logs, firewalls and required modules.
Result: Scope and compatibility confirmed. - 02
Intervention plan
We define changes, accesses and windows.
We determine what will be installed, where the traffic will pass, which backups or snapshots must be available and how to verify or cancel any changes.
Result: tasks agreed before touching the server. - 03
Installation
We register the server in the fleet.
We install and configure the agent, generate the expected credentials and check the secure mTLS connection to the core.
Result: visible server and verifiable technical status. - 04
Observation
We observe real traffic and events.
When the context requires it, the WAF and watchers start without immediately applying all the most restrictive actions. We identify legitimate traffic, automations and possible false positives.
Result: baseline of the real environment. - 05
Tuning
We set policies, thresholds and allowlists.
We adapt the necessary rules without disabling protection indiscriminately. We test sites, administrative accesses, APIs, webhooks and relevant automatic processes.
Result: Protection tuned to the infrastructure. - 06
Managed protection
We enable the agreed blocking mode and monitor it.
Policies enter the expected mode, events merge into the dashboard and alerts and reports are configured, together with the support arrangements defined by the plan.
Result: Sentinel operating in the ordinary service.
Architecture
The agent defends the server. The console coordinates the fleet.
The operational processing remains close to the protected service, while the core collects status and events, distributes configurations and governs updates.
- Application traffic: is inspected locally by the WAF when this module is enabled.
- IP block: is applied by the firewall backend available on the server.
- Telemetry: agent and central server communicate on the agreed authenticated channel.
- Console: brings together events, fleet, policies, reports and operational activities.
Sites and servicestraffic and log
→Agent SentinelWAF · watcher · firewall
⇄Central consolemTLS · events · policy
Before you start
What it takes for a useful evaluation.
We do not ask for sensitive access in the first contact: just the information that describes the perimeter.
01
Inventory
Number of servers and sites, operating systems, panels and web servers used.
02
Traffic
Monthly HTTP/HTTPS volume, peaks, CDN, proxy and publicly exposed services.
03
Constraints
Maintenance windows, critical applications, allowlists and integrations that must not be interrupted.
04
Contacts
Technical contact and contact authorised to confirm changes and switch to the block.
Clear responsibilities
Who does what during and after activation.
G Tech Group
- Technical verification and definition of the Sentinel deployment.
- Installation and configuration of agreed components.
- Initial policy tuning.
- Maintenance of the platform and agents.
- Support, alerts and reports according to the offer.
Infrastructure client or contact person
- Provides correct environmental information.
- Allows agreed accesses, windows and modifications.
- Reports applications, automations and IP addresses to be preserved.
- It keeps backups, apps and credentials not included in the service.
- It communicates future changes that may alter deployment.
Operational impact
The operational impact depends on the traffic path.
Preparatory operations without interruption
Analysis, recording in the console, preparation of configurations and part of the controls can normally be performed before switching.
Operations that may require a window
Changes to reverse proxy, ports, DNS, certificates, TLS termination or reboot of services are planned and confirmed on the individual environment.
Verification and rollback
We define technical checks and recovery steps before editing. The result is verified on sites, APIs and agreed functions.
Frequently asked questions
What to expect from activation.
Does Sentinel block traffic immediately?
Not necessarily. When the environment requires it we start to observe, analyse events and switch to the block in a controlled way.
Is it necessary to interrupt the sites?
It depends on the architecture. If the proxy, ports or TLS settings must change, we agree with a window and its verification plan before the operation.
How long does the activation last?
The time depends on the number of servers, sites, traffic and complexity. The estimate is provided after the technical verification, not before.
Who approves the move to the block?
The operating mode is agreed with the authorised contact person indicated by the customer and documented in the activation path.
Can I start from one server?
Yes. Each plan refers to a single server and the rollout can start from one machine before extending to the others.
What happens next?
Sentinel enters into the ongoing management included in the plan: automatic monitoring, dashboards, updates, reports and agreed support.
Let's get the first server ready.
Describe the environment: we confirm compatibility, plan, activity and impact before we start.