Pregunta:
¿Es una buena práctica una lista negra de direcciones IP para prevenir ataques a sitios web?
garik
2010-11-12 04:56:44 UTC
view on stackexchange narkive permalink

Mi sitio web tiene una lista negra de direcciones IP. La aplicación web, de alguna manera, detecta todas las influencias no válidas y sospechosas, recuerda la dirección IP y niega cualquier solicitud de esa dirección IP.

Entonces, mi pregunta es: ¿Es una buena práctica, una forma de prevenir ataques de esta manera?

RESUMEN (AÑADIDO):

Quiero resumir todas las respuestas, como sea posible:

  • lista blanca (ubicaciones confiables)
  • lista gris (lista de atención alta)
  • bloqueo temporal
  • detección de direcciones estáticas y dinámicas
  • detección inteligente y flexible
existen varios servicios comerciales que existen para brindarle inteligencia de geolocalización IP (incluyendo estática / dinámica, velocidad de línea, + más) http://www.quova.com (ahora Neustar) y elemento digital son los proveedores premium http: // www .digitalelement.com /
Seven respuestas:
AviD
2010-11-12 05:06:36 UTC
view on stackexchange narkive permalink

Yo diría que no se moleste en poner demasiadas direcciones IP en la lista negra:

  • Hay demasiados falsos positivos, ya que hay muchas situaciones de IP compartidas: proxies, lugar de trabajo, ISP que utilizan DHCP itinerante, etc. .
  • Es demasiado fácil evitarlo. Un tipo realmente malo simplemente obtendrá una IP diferente, si realmente quiere atacarte.

Sugeriría una "lista gris" de direcciones IP, es decir, si reconoce el tráfico incorrecto, "vigile" esas direcciones.

La lista gris +1 es una solución blanda y con participación humana, pero es más flexible. de cualquier forma es un buen punto. Gracias
Por cierto, la lista gris de @igor, no necesita estar involucrada por humanos; puede ser para poner controles adicionales en solicitudes, limitación / cuota, etc.
VirtuosiMedia
2010-11-12 05:04:16 UTC
view on stackexchange narkive permalink

Una lista negra de IP puede ayudar, pero no confíe en ella como su único medio de seguridad.

También querrá tener mucho cuidado al prohibir bloques de IP o robots de motores de búsqueda. Es posible que también desee mantener una lista blanca de IP que sean falsos positivos para sus influencias sospechosas.

James T
2010-11-12 05:00:05 UTC
view on stackexchange narkive permalink

Siempre que las influencias sospechosas no sean demasiado estrictas. No quieres bloquear a un buen usuario.

a menos, por supuesto, (s) él, no hace influencias tanto tiempo. :)
Mark Davidson
2010-11-12 05:03:48 UTC
view on stackexchange narkive permalink

En principio puede ser bueno.

Sin embargo, depende de cuánto tiempo bloquee las direcciones IP. También debe considerar que algunos usuarios, como los que usan AOL, si mal no recuerdo, vienen a través de servidores proxy, por lo que muchos usuarios compartirán la misma dirección IP y, como resultado, podría bloquear a muchas personas. Otra consideración es que Office, Universidades, etc. también pueden tener muchas computadoras compartiendo la misma IP y esa es otra amplia gama de personas que podría terminar bloqueando para las acciones de un usuario.

Quizás podría bloquear por un período corto de tiempo o bloquear mediante una combinación de agente de usuario y dirección IP para limitar el efecto de bloqueo.

convenido. pero, ¿cómo puedo señalar una mala fuente de impactos y restringirla?
Wikipedia explica su política sobre dicho bloqueo aquí http://en.wikipedia.org/wiki/Wikipedia:WikiProject_on_XFFs probablemente un buen ejemplo para seguir. También ofrecen mucha más información sobre el bloqueo de direcciones IP aquí http://en.wikipedia.org/wiki/Wikipedia:Blocking_IP_addresses
Paweł Dyda
2010-11-12 05:04:21 UTC
view on stackexchange narkive permalink

Depende. Si su aplicación es un servidor SMTP, puede asumir con seguridad que todo el tráfico entrante debe provenir de IP estáticas, es decir, si el mensaje proviene de IP dinámica, probablemente sea spam o virus enviado desde algún tipo de botnet. En tal caso, es muy buena idea evitar que se conecten y creo que es una buena práctica.

Pawel, ¿cómo detectar que la dirección es estática o dinámica?
@Igor: Ese es el problema. En realidad, me refería a mi experiencia (así es como aseguré el servidor de correo hace unos años) y simplemente sabía que, es decir, las direcciones IP de Neostrada (el mayor servicio de ISP polaco) se asignan dinámicamente. Algunos sitios de listas negras parecen saber qué IPs son dinámicas, es decir, este sitio: http://cbl.abuseat.org/ de alguna manera sabía que mi IP es dinámica ...
+1 estuvo de acuerdo. al menos esta información se puede encontrar en las fuentes públicas, espero.
Rory McCune
2010-11-12 05:03:12 UTC
view on stackexchange narkive permalink

En general, diría que sí, puede ser un control bastante efectivo. Un problema que podría tener son los usuarios que ingresan a través de un proxy, que puede parecer que todos provienen de una dirección IP, bloquear una podría bloquearlos a todos. A veces, puede usar el encabezado X-Fordered-For para diferenciar las solicitudes de una dirección IP de origen, pero eso no está necesariamente presente en todas las solicitudes con proxy.

¿Es posible que la dirección IP pueda ser DESCONOCIDA (vacía)? ¿Qué significa (si es así)?
Además, si confía en X-Fordered-For en lugar de la IP de conexión directa, ¿qué impide que el atacante se haga pasar por un proxy y simplemente agregue ese encabezado con IP aleatorias cada vez?
Taipo
2012-02-05 03:57:26 UTC
view on stackexchange narkive permalink

Tenga cuidado con las configuraciones del servidor donde, por ejemplo, en Rackspace, el _SERVER [REMOTE_IP], que suele ser la dirección IP del usuario, es en realidad un servidor proxy que soporta carga.

Sin embargo, el encabezado REMOTE_IP es realmente el único encabezado no falsificable en términos de la IP real del usuario.

HTTP_X_CLUSTER_CLIENT_IP y HTTP_X_FORWARDED_FOR (por nombrar algunos), por ejemplo, pueden ser falsificados por un atacante / sistema de ataque.

Muchos de los complementos de seguridad del complemento CMS que he visto en ese intento de filtrar las entradas utilizando un enfoque en cascada de encabezados potenciales y luego prohibir la dirección IP de las solicitudes incorrectas, tienden a apilar la mayoría de los encabezados enviados por el cliente o proxy común primero, siendo REMOTE_ADDR el último en la lista, esto para un atacante es trivial de pasar por alto, por lo que, en efecto, toda la aplicación se vuelve inútil ya que una nueva dirección IP de cliente puede enviarse potencialmente con cada solicitud no autorizada.

Prohibir la dirección IP incorrecta en un la configuración en clúster podría resultar en la prohibición de su sitio web, y permitir que se prohíban las IP falsificadas puede permitir que un atacante envíe una IP falsificada del servidor web o un proxy de línea ascendente al servidor web, lo que da como resultado el mismo efecto.

O cuando se utilizan IP en la lista blanca, el atacante podría también envíe las solicitudes no autorizadas con la IP incluida en la lista blanca.

El mejor método que se me ocurrió en estas situaciones es: cuando hay otros encabezados presentes además del REMOTE_IP, la regla número uno es siempre filtrarlos para hacer asegúrese de que esos encabezados realmente contengan una dirección IP, luego sí, utilícelos para determinar la dirección IP del usuario, sin embargo, desactive la prohibición de IP (si se está empleando) en esa instancia, y simplemente vaya con un encabezado 403 y una llamada de página die () para bloquear una solicitud maliciosa real en lugar de prohibir la dirección IP.

Después de todo, es la solicitud maliciosa lo que desea evitar completar más que cualquier otra cosa. Prohibir direcciones IP es un problema mayor cuando un atacante está golpeando su sitio a través de múltiples servidores proxy anónimos para crear una denegación de servicio.



Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 2.0 bajo la que se distribuye.
Loading...