respuesta_activa.py module implements the active response layer of the IPS. When the IDS engine decides an IP must be blocked, it calls bloquear_ip(), which creates a Windows Firewall inbound rule via PowerShell, schedules automatic unblocking, and logs every action.
Functions
bloquear_ip
respuesta_activa.py
respuesta_activa.py
New-NetFirewallRule to create the rule. The rule display name follows the convention IDS_BLOCK_{ip} (e.g. IDS_BLOCK_192.168.1.50), which is also used as the identifier for removal.
The IP address to block. Passed directly to
-RemoteAddress in the firewall rule.How long (in minutes) to keep the block active. A daemon thread calls
desbloquear_ip() after this duration. The IDS engine always passes 60 minutes.True if the firewall rule was created successfully, False otherwise.
After a successful block, bloquear_ip also:
- Calls
registrar_bloqueo(ip, "BLOQUEO_AUTOMATICO", duracion_minutos)to append tologs_bloqueos.txt. - Starts a daemon thread running
programar_desbloqueo(ip, duracion_minutos).
desbloquear_ip
respuesta_activa.py
bloquear_ip.
respuesta_activa.py
Remove-NetFirewallRule with the same naming convention. If the rule no longer exists (e.g. it was already removed manually), the PowerShell command returns a non-zero exit code. This is treated as a non-fatal warning rather than an error.
Return value: True if the rule was removed, False if the command failed.
After a successful unblock, registrar_bloqueo(ip, "DESBLOQUEO_AUTOMATICO") is called.
programar_desbloqueo
respuesta_activa.py
daemon=True). Sleeps for minutos * 60 seconds, then calls desbloquear_ip(). Because the thread is daemonized, it is automatically killed if the main process exits — the firewall rule will persist until manually removed or the system restarts.
If the application is closed before the timer expires, the firewall rule remains active until removed manually via PowerShell or Windows Defender Firewall UI. To remove all IDS rules at once:
Get-NetFirewallRule -DisplayName 'IDS_BLOCK_*' | Remove-NetFirewallRuleregistrar_bloqueo
respuesta_activa.py
logs_bloqueos.txt in the project root. The accion string is either "BLOQUEO_AUTOMATICO" or "DESBLOQUEO_AUTOMATICO".
Blocking criteria
The decision to callbloquear_ip() is made inside guardar_ataque() in ids.py. The IPS must be enabled (ips_activo = True) and the event must meet the criticality threshold:
ids.py
es_critico is True, the block decision follows this logic:
- If the event label contains
"(ml:"→ block only if ML confidence ≥ 70%. - If the event label contains
"(heurística)"→ block unconditionally (heuristic certainty is sufficient).
Severity levels
The severity string is stored in thebloqueos table and displayed in the IPS panel:
| Severity | Trigger condition |
|---|---|
CRITICA | "exploit" or "sql" in the attack label |
ALTA | "flood" or "ddos" in the attack label |
MEDIA | "escaneo" or "scan" in the attack label |
es_critico), the default severity is ALTA.
Simulated blocking
When the application is not running as Administrator, the PowerShell command fails andbloquear_ip() returns False. The engine handles this gracefully:
ids.py
SIMULADO instead of ACTIVO when no firewall rule was created, so SOC analysts are aware that the block is not enforced at the network level.