it-swarm-es.com

¿Puedo bloquear según la dirección MAC?

Si bloqueo una IP, el atacante puede solucionar el bloqueo tomando una nueva IP o usando un proxy. ¿Es posible hacer una prohibición basada en la dirección MAC? Quiero bloquear en el nivel del servidor web para que los usuarios no deseados no creen tráfico innecesario al sitio.

¿Se envía la dirección MAC como parte de la solicitud HTTP?

15
Geek

No, la dirección MAC no se envía en los encabezados. Resistente, es posible que desee verificar: https://panopticlick.eff.org/

16

En resumen , la respuesta es no , generalmente no puede bloquear basado en la dirección MAC. Y si pudieras, sería inútil. Para entender por qué, debe saber una o dos cosas sobre cómo funciona Internet.

La comunicación entre dispositivos se realiza comúnmente a través de protocolo Ethernet (wiki) , y a pesar de que el origen y el destino se identifican por IP, la comunicación real se realiza por MAC. Imagine la siguiente red:

Si el cliente desea enviar un paquete al servidor, primero verifica si el servidor está en la misma subred. No, el servidor tiene una IP 10.x, y el cliente una IP 192.168.x. Luego, el cliente lo envía a su enrutador, R1, con la esperanza de que pueda reenviarlo al destino. El paquete contiene:

Source IP:       192.168.1.100     (belongs to: Client)
Destination IP:  10.1.1.1          (belongs to: Server)
Source MAC:      01:01:01:02:02:02 (belongs to: Client)
Destination MAC: 02:01:01:02:02:02 (belongs to: R1)

Luego R1 es como "Oh, esa IP está en algún lugar de Internet". Cambia la IP de origen a la IP pública (para que el servidor pueda devolver un paquete) y lo reenvía a R2. El paquete ahora contiene:

Source IP:       172.16.1.1        (public IP from R1)
Destination IP:  10.1.1.1          (belongs to: Server)
Source MAC:      02:01:01:02:02:02 (belongs to: R1)
Destination MAC: 03:01:01:02:02:02 (belongs to: R2)

Como puede ver, la IP de destino no cambia, pero las direcciones MAC cambian cada vez que se reenvía (por un enrutador) en función de a qué enrutador se reenvía y de qué enrutador proviene.

Avanzando, R2 no alterará ninguna de las IP como R1 lo hizo porque no es un enrutador NAT enrutador (como lo han hecho la mayoría de los consumidores). R2 simplemente reenviará el paquete.

Al final, el servidor solo podrá ver la dirección MAC de R3. Para que la comunicación funcione, eso es todo lo que necesita saber además de la IP original de R1. (Cuando un paquete de respuesta vuelve a R1, otras cosas asegúrese de que el paquete llegue al cliente.) Si desea saber por qué no toda la comunicación se basa simplemente en MAC, eche un vistazo a esta pregunta en serverfault .

Una excepción a esto es cuando el cliente está dentro de la misma LAN que el servidor. Como mencioné, el cliente primero compara la subred IP de sí mismo y el destino. Si es igual (por ejemplo, 192.168.1.101 y 192.168.1.44, cuando se encuentra en una subred/24), la comunicación se basa en la dirección MAC. El cliente transmitirá un mensaje en la LAN, solicitando el MAC que pertenece a la IP del servidor, y luego lo enviará a ese MAC. El paquete aún contendrá la IP de destino, pero no hay un enrutador entre los dos. (Puede haber, pero luego actuará como un conmutador o concentrador, no como un enrutador). Pero probablemente este no sea el escenario que tenía en mente.

Si pudiera determinar el MAC, eso sería una violación de privacidad bastante grande. Dado que su dirección MAC podría identificarlo de manera única en el mundo, las redes publicitarias no tendrían problemas para rastrearlo, también sin rastrear cookies ni ningún otro método.

Bloquear a un atacante por MAC sería lo mismo que bloquearlo por cookie porque es controlado por el cliente. Actualmente casi nunca cambia porque casi nunca hay una razón para hacerlo, pero si pudieras determinar y bloquear a un atacante por MAC, simplemente podría cambiarlo. Las direcciones IP deben ser reconocidas globalmente para ser enrutables, pero una MAC no tiene este problema.

Además, un atacante podría bloquear clientes cuyo MAC conoce al suplantar esa dirección MAC y luego activar el bloqueo. Quien realmente use esa dirección MAC tendría prohibido usar el servicio.

Conclusión: Si fuera posible, sería bastante ineficaz y al introducir una vulnerabilidad DoS, pero dado que no puede hacer que el cliente envíe el MAC junto con Encabezados HTTP o algo así, simplemente no es posible fuera de la misma LAN.

18
Luc

Las direcciones MAC de origen (capa 2) solo mostrarán último enrutador para reenviar el paquete.

7
Bradley Kreider

No estoy seguro de a qué se refiere esta pregunta: ¿bloquear solicitudes HTTP en el servidor web? filtrando el acceso a un punto wifi? Cortafuegos y enrutamiento?

Pero independientemente de si puede o no bloquear en función de la dirección MAC, una mejor pregunta es debería bloquear.
Y la respuesta simple es: No.

En pocas palabras, las direcciones MAC se pueden cambiar y/o falsificar fácilmente, y tienen el control total del usuario final (está bien, casi completamente). Por lo tanto, no tiene sentido tratar de implementar ningún tipo de control basado en eso.

4
AviD