Conoce la pantalla de las grandes CDN: un segundo de «comprobando» y ya está dentro. Esa pantalla hace dos cosas: no deja entrar a una dirección conocida como mala y hace pasar un obstáculo a la dudosa. Pero lo que la hace funcionar no es la pantalla, sino la lista que tiene detrás.
IP-DB Shield ejecuta esa misma puerta en su servidor y con su nombre. Sin cambiar el DNS, sin enrutar tráfico por nadie, sin cuentas que mejorar: la decisión se toma dentro de su propio proceso PHP, a partir de la copia de la lista de bloqueo que está en su disco. Un archivo, sin dependencias, PHP 7.0 o superior, licencia MIT.
Qué hay en el paquete
ipdb-shield.php— la puerta; un archivo, sin dependencias.config.php— el único archivo que debe editar.theme/screen.htmlytheme/strings.json— las tres pantallas de visitante y sus textos (turco, inglés, alemán, español). Rediséñelas a su gusto.static/ipdb-shield.js— la edición para sitios sin PHP.examples/— fragmentos para .htaccess, nginx, cron y WordPress.
Instalación en tres minutos
Descargue el kit desde la página de Shield y cree la clave de API en el panel.
En config.php solo dos valores son obligatorios: api_key y el secret generado. Después active la puerta, o como la primera línea que ejecuta su sitio:
…o sin tocar una línea de código, con .htaccess:
Por último, añada la línea de cron de examples/cron.txt para que la lista se refresque fuera de la ruta crítica.
El primer día: no bloquee a nadie
El kit viene con 'mode' => 'monitor' y así debería quedarse un día. En modo monitor no se detiene a nadie, pero cada decisión se registra: en la dirección privada del panel que imprime --status verá a quién se habría bloqueado, por qué motivo y cuántas veces. Leer un día de tráfico real y después pasar a 'protect' es mucho mejor que adivinar los umbrales.
Cómo se decide una petición
El orden es fijo y gana la primera coincidencia:
| # | Caso | Resultado |
|---|---|---|
| 1 | No es una página (recursos, XHR, webhooks, wp-cron) | Intacto |
| 2 | Su allow_ips | Pasa |
| 3 | Su deny_ips | Rechazado |
| 4 | Ruta trampa (/.env, /.git/…) | Rechazado y, si lo permite, reportado |
| 5 | Rastreador verificado (DNS inverso confirmado) | Pasa |
| 6 | En la lista o puntuación sobre block_score | Página 403 con su marca |
| 7 | Puntuación sobre challenge_score o avalancha | Pulsar y mantener + prueba de trabajo, captcha opcional |
| 8 | Todos los demás | Un segundo de comprobación y una cookie firmada |
Las peticiones POST nunca se interrumpen —un envío de formulario no sobrevive a una pantalla intermedia—, pero una dirección rechazada lo es con cualquier método.
De dónde sale la lista: feed, api, both
feed (predeterminado): una copia local de la lista de bloqueo, refrescada cada pocas horas. Nada sale de su servidor mientras un visitante espera, no se gasta cuota por visita y la búsqueda es binaria sobre un índice ordenado: memoria constante, microsegundos.
api: una consulta /check por cada dirección que no haya visto hace poco, en caché durante cache_ttl. Más rica (puntuación, país, red) y siempre al día, pero gasta su cuota diaria y añade un viaje de ida y vuelta la primera vez.
both: primero la lista; la API solo para las direcciones que falten, hasta api_daily_budget consultas al día y después solo la lista.
Línea de comandos y panel privado
La URL del panel se deriva de su secreto; trátela como una contraseña y, para rotarla, cambie el secreto. El panel muestra el modo, la edad y el tamaño de la lista local, los contadores de hoy, los últimos siete días y las decisiones recientes con su motivo.
SEO y accesibilidad
Una puerta de visitantes puede sacar un sitio de los resultados de búsqueda, así que los detalles importan. Los motores pasan solo si el nombre de DNS inverso termina en el dominio del operador y resuelve de vuelta a la misma dirección. La pantalla de comprobación responde 503 con Retry-After y lleva noindex: el rastreador entiende que hay una puerta temporal y no indexa una página 200 con su título. Las pantallas se manejan con teclado, se anuncian a los lectores de pantalla, respetan prefers-reduced-motion y el tema oscuro, funcionan en anchura de móvil y, a quien no tiene JavaScript, se lo dicen en su idioma en vez de dejarlo ante un indicador girando.
Privacidad y seguridad
- En modo
feednada sobre el visitante sale de su servidor. Enapiybothse envía solo la dirección IP: ninguna URL, ningún User-Agent, ninguna cookie, ningún contenido. Las pantallas indican cuál es el caso en el idioma del visitante. - Lo único que un visitante puede falsificar son las cabeceras, así que por defecto solo se confía en
REMOTE_ADDR. Una cabecera reenviada se lee cuando la conexión viene de un proxy listado entrusted_proxies; de lo contrario, cualquiera podría declarar la dirección que quisiera y cruzar la puerta. - Cada reto está firmado, caduca en diez minutos, está ligado al navegador y se resuelve una sola vez: una prueba de trabajo capturada no sirve la segunda vez.
- Mantenga
config.phpycache/fuera del alcance por HTTP; el kit deja su propio.htaccessde denegación encache/y enexamples/hay reglas para Apache y nginx.
Devolver datos y cuota
El kit viene con 'report' => true: solo se reportan dos cosas, la petición de una ruta trampa que ningún navegador pide y una dirección que ha fallado una docena de retos en una hora. Como máximo un reporte por dirección cada seis horas; los visitantes normales nunca se reportan y no se envía nada sobre sus páginas. Si prefiere no reportar, póngalo en false en config.php.
Una instalación que reporta sube su cuenta verificada al nivel de contribuyente: 30.000 consultas al día en lugar de 1.000, mientras la instalación haya reportado en los últimos 7 días.
Tres problemas frecuentes
- Mi cron o mi endpoint recibe una página HTML. Añada esa ruta a
skip_paths. Todo lo que llama una máquina pertenece ahí. - La caché de página sirve la pantalla a todo el mundo. Las pantallas envían
no-store, pero algunas cachés lo ignoran; instalada conauto_prepend_file, la puerta corre antes de la caché. - «blocklist: 0 entries». Falta la clave de API, no hay HTTPS saliente o el directorio de caché no tiene permisos:
--statusdice cuál es.
Preguntas frecuentes
¿Mi tráfico pasa por alguien? ¿Debo cambiar el DNS?
No. Shield se ejecuta dentro del proceso PHP de su propio servidor; no cambia ningún registro DNS y no se enruta tráfico por nadie. Con la fuente predeterminada 'feed', la decisión sale de una copia de la lista de bloqueo en su disco, así que nada sale de su servidor mientras un visitante espera.
¿Bloqueará a Google? ¿Perjudica al SEO?
Los motores de búsqueda pasan, pero solo si la dirección es realmente suya: el nombre de DNS inverso debe terminar en el dominio del operador y resolver de vuelta a la misma dirección. Un User-Agent que dice ser Googlebot no prueba nada. Además, la pantalla de comprobación responde 503 con Retry-After y noindex en lugar de una página 200, que es justo lo que un rastreador debe ver ante una puerta temporal.
¿Y si me bloqueo a mí mismo?
Añada su dirección a allow_ips en config.php: por eso la instalación deja el modo en 'monitor' el primer día. Si ya está bloqueado, borre el directorio cache/ y vuelva al modo monitor. Además, todos los caminos de error fallan en abierto: una lista ausente, una API inalcanzable o un directorio de caché sin permisos dejan el sitio en pie y escriben el motivo en el registro de errores de PHP.
Los visitantes ven la pantalla de comprobación en cada página, ¿por qué?
La cookie no vuelve. Revise el reloj del servidor, si alguna caché o CDN elimina Set-Cookie y que pass_hours sea mayor que cero. Si usa caché de página completa, excluya a los visitantes que no lleven la cookie ipdb_pass.
Si usa WordPress, la guía del plugin encaja mejor; para llevar la lista directamente al cortafuegos, vea el artículo sobre bloqueo de IP, y para convertir su servidor en sensor, la guía del honeypot.
Comentarios 0
Comparte una pregunta, tu experiencia o una corrección, registrado o de forma anónima.
Aún no hay comentarios. Sé el primero.