¿Cuándo está bloqueando IP solo el nivel 7 de OSI y cuál es el propósito de hacerlo en múltiples ubicaciones?

A las capas OSI no les importa dónde se realiza la comprobación, pero en qué capa reside la información utilizada en la comprobación. Si la verificación se realiza en la lista blanca solo por la dirección IP, no importa dónde esté configurada la verificación, porque la decisión siempre se basa exclusivamente en la dirección IP, es decir, la capa 3 de OSI.

Pero, dependiendo de la configuración y el código de validación, la verificación podría no probar con la IP de origen real del cliente, sino con una IP de origen reclamada. Este sería el caso si la verificación se hiciera contra la dirección IP desde X-Forwarded-For o un encabezado HTTP similar en la solicitud. Dichas comprobaciones podrían realizarse en PHP y, probablemente, .htaccess y esto sería una verificación basada en la información a nivel de la aplicación, es decir, la capa 7 de OSI.

  

¿Y se puede pasar por alto uno o todos estos métodos con algún tipo de suplantación de IP?

Obviamente, la omisión de las verificaciones basadas en la información de la capa 3 (dirección IP) solo se puede realizar si se puede falsificar la información de la capa 3. Si bien el uso de una IP falsa con UDP se puede hacer fácilmente, usar una dirección IP falsificada con TCP es casi imposible debido al protocolo de enlace de 3 vías, los números de secuencia, etc. Consulte también ¿Es posible pasar el protocolo TCP con una dirección IP falsificada?

La información de la capa 7 de suplantación de identidad (X-Forwarder-For) se puede realizar fácilmente con un cliente personalizado.

Depende de lo que quieras proteger, y cuándo.

Si su servidor aloja una serie de servicios, o una serie de sitios web, entonces querría el control más cercano al objetivo para no denegar la IP de los otros servicios / sitios.

Si tu servidor aloja un sitio web y un servidor de correo electrónico, y alguien que te está invirtiendo correctamente activa un bloqueo, no quieres que se te bloquee el envío de un correo electrónico.

O, si está alojando varios sitios web, y un sitio recibe un impacto de una sola IP, a los propietarios de los otros sitios no les gustará que esa IP también esté bloqueada en su sitio.

Además, los diferentes objetivos pueden querer diferentes niveles de protección. Un sitio puede querer ser permisivo, mientras que otro puede querer errar por el lado de la precaución.

Si vuelca todo el filtrado en el nivel del cortafuegos, perderá el control preciso.

Según el tipo de servicio que esté ejecutando, es posible que desee hacerlo en diferentes lugares.

La ventaja de iptables es que se ejecuta en el kernel de Linux y evita que los datos lleguen a sus procesos. Lo que significa que si algo como Heartbleed o Shell Shock vuelve a suceder, el atacante nunca podrá alcanzar una aplicación vulnerable. Es muy difícil de personalizar y requiere acceso de root.

El uso de htaccess es conveniente cuando se configuran permisos condicionales en direcciones IP y cuando no se tiene acceso de root, lo que se requiere para su uso con iptables. El inconveniente es que tiene que hacer el apretón de manos, y hacer algunas comprobaciones.

El uso de scripts PHP no es un cálculo de tiempo eficiente, ya que antes de que cualquier dato pueda llegar a su aplicación, se debe establecer una conexión que demore un poco y puede causar ataques de DOS si su script requiere mucha CPU. Úselo solo si está haciendo verificaciones adicionales como "Si el usuario es administrador, y tiene ignorar la configuración de IP en la base de datos, déjelo pasar; de lo contrario, bloquee todas las cosas de esas IP".