~~~~~

Question

quiero ejecutar una aperturaColinaenrutador.

Mi política de salida será similar aPolítica de salida reducida.

Pero también quiero dificultar que la red Tor abuse de mis recursos.

Casos que quiero evitar que los clientes realicen a través de Tor:

• Martillando un sitio con muchísimos paquetes.
• Escaneos de red agresivos de bloques de IP completos

Casos que NO quiero evitar que los clientes realicen a través de Tor:

• subir algunos cientos de archivos de imágenes a la nube
• sembrando un torrente

Mi pregunta es: ¿se puede hacer esto y cómo?

Lo primero que pensé fue algún firewall (Linux/iptables o *BSD/ipfw/pf), pero probablemente será inútil debido a las propiedades inherentes del enrutador Onion.

¿Hay algún desarrollo en curso del equipo de torproject sobre este tema?

También solicito sugerencias generales sobre cómo proteger los nodos de salida de Tor.

Actualización (septiembre de 2012)

A partir de respuestas útiles y algunas otras investigaciones, creo que esto no se puede hacer.

Lo mejor que puede hacer para evitar que las personas abusen del nodo de salida para contribuir en DDOS es detectar paquetes muy frecuentes dirigidos a una IP.

El umbral "muy frecuente" depende del ancho de banda total del nodo... Si es incorrecto, habrá falsos positivos, bloqueando el tráfico legítimo de aplicaciones TCP en tiempo real y el tráfico proveniente de muchos clientes a un destino.

Actualización (diciembre de 2014)

Obviamente, mis predicciones fueron ciertas: recibí varias quejas de abuso de red por parte de mi proveedor de Internet.

Para evitar el cierre del servicio, tuve que emplear el siguiente conjunto de iptablesreglas ( ONEWes una cadena para paquetes TCP SYN (también conocidos como NUEVOS) salientes:

No estoy seguro de que sea suficiente, pero aquí está:

-A ONEW -o lo -j ACCEPT
-A ONEW -p udp --dport 53 -m limit --limit 2/sec --limit-burst 5 -j ACCEPT
-A ONEW -m hashlimit --hashlimit-upto 1/second --hashlimit-mode dstip --hashlimit-dstmask 24 --hashlimit-name ONEW -j ACCEPT
-A ONEW -m limit --limit 1/sec -j LOG --log-prefix "REJECTED: "
-A ONEW -j REJECT --reject-with icmp-admin-prohibited

Answer 1

Manten eso en mente:

• Los clientes de Tor cambian los circuitos virtuales cada 10 minutos aproximadamente, según tengo entendido actualmente. Esto significa que la IP de origen está cambiando en ese período de tiempo. Es poco probable que pueda evitar cualquier comportamiento que considere malicioso durante más tiempo que ese período.

• Tenga en cuenta que el hecho de que Tor sólo proxies el tráfico TCP y ningún otro protocolo limita bastante las posibilidades de abuso.

iptablespuede permitirle tratar las nuevas conexiones TCP salientes de manera diferente a las existentes. Todo lo que sea ESTABLISHED,RELATEDdebe ACCEPTEDpasar por una cadena de "conexiones TCP existentes", y el TCP saliente que no queda atrapado en ella podría tener una velocidad limitada. Cualquier tráfico Tor saliente debería estar sujeto a esto.

Creo que entre lo anterior y el uso de la "Política de salida reducida" sería lo mejor que puede hacer.

Lo ideal es no ejecutar nada más en tu caja Tor excepto:

• Probablemente al menos tengas SSH activado, colócalo en un puerto diferente al 22.
• Probablemente querrás ejecutar un servidor web simple para mostraresta página. Una instancia chroot mini-httpddebería ser suficiente. No lo uses inetd.

No ejecute Tor en una máquina que se esté utilizando para cualquier otra cosa. Asegúrese de haber leído la sección "Relés de salida" dePreguntas frecuentes sobre cuestiones legales de Tory comprender plenamente sus implicaciones. Tambiénlee y haz todo esto.

Answer 2

Será más difícil de lo habitual prevenir estos ataques ya que la IP de origen no es constante. Sin embargo, que yo sepa, las rutas en Tor solo se cambian cada pocos minutos aproximadamente.

Por lo tanto, aún podría implementar algunas de las reglas estándar de limitación/filtrado pero con un umbral más alto, ya que debe asumir que hay una red completa detrás de sus IP de origen.

Puedes filtrar:

• Paquetes de escaneo/huellas digitales malos o típicos (indicadores TCP/IP incorrectos, XMAS, la mayoría de los tipos ICMP, etc.)
• Paquetes NO VÁLIDOS que no se ajustan a conexiones nuevas o en curso (estado -m)
• NUEVAS conexiones que comienzan en un umbral bastante alto

Sin embargo, tenga en cuenta que este tipo de cosas normalmente se hacen con el tráfico entrante. No sabe qué tipo de protocolos ejecutarán sus "clientes" y puede restringirlos de maneras que pueden resultar molestas o poco claras.

Además, para los paquetes NUEVOS (o sin estado) que limitan la velocidad, es posible que desee considerar algún esquema más complicado en el que los paquetes rechazados (¡nunca DROP a menos que sea obviamente un ataque!) sean aleatorios. De esta manera, un usuario normal puede intentar recargar y tener suerte, aunque la velocidad general esté actualmente en el límite, mientras que un escáner de puertos simultáneo no podrá eludir su límite de velocidad.

Pregunte también en las listas de correo de Tor; probablemente no sea el primero en tener esos pensamientos:https://lists.torproject.org/cgi-bin/mailman/listinfo

Answer 3

En primer lugar, no sugeriría iptables para resolver todo esto; verdaderamente, un nodo Tor de salida ideal equilibraría la carga del tráfico a través de algunos túneles VPN para mantener los ojos del ISP alejados de los paquetes y el destino verdadero y/o utilizaría un proxy de almacenamiento en caché para mantener las solicitudes repetidas salientes. a popularestáticocontenido al mínimo... mientras analiza esas opciones, aquí hay unaapósito adhesivopara los problemas de denuncia de abuso;

Fuentes de información utilizadas

http://www.ossramblings.com/using_iptables_rate_limiting_to_prevent_portscans

http://blog.nintechnet.com/how-to-block-w00tw00t-at-isc-sans-dfind-and-other-web-vulnerability-scanners/

Combinar los dos enlaces de origen en reglas que pueden usarse para frustrar a los robots que intentan usar su nodo de salida de Tor para escanear puertos. Tenga en cuenta que esto puede hacer que los piratas informáticos que utilizan su nodo de salida se sientan muy descontentos, ya que estas reglas provocan un tiempo de suspensión de nmap.

#!/bin/bash
## Network interface used by Tor exit daemon
_tor_iface="eth1"
## Ports that Tor exit daemon binds to, maybe comma or space sepperated.
_tor_ports="9050,9051"
## Time to ban connections out in secconds, default equates to 10 minutes, same as default Tor cercut.
_ban_time="600"
## How long to monitor conections in seconds, default equates to 10 minutes.
_outgoing_tcp_update_seconds="600"
## How many new connections can be placed to a server in aloted update time limits. May nead to increes this depending on exit node usage and remote servers usages.
_outgoing_tcp_hitcount="8"
## How long to monitor connections for in minuets, default is 15 minutes but could be lessoned.
_outgoing_tcp_burst_minute="15"
## Hom many connections to accept untill un-matched
_outgoing_tcp_burst_limit="1000"

iptables -N out_temp_ban -m comment --comment "Make custom chain for tracking ban time limits" || exit 1
iptables -A out_temp_ban -m recent --set --name temp_tcp_ban -p TCP -j DROP -m comment --comment "Ban any TCP packet coming to this chain" || exit 1

iptables -N out_vuln_scan -m comment --comment "Make custom chain for mitigating port scans originating from ${_tor_iface}" || exit 1
for _tor_port in ${_tor_ports//,/ }; do
    iptables -A out_vuln_scan -p TCP -o ${_tor_iface} --sport ${_tor_port} -m recent --name temp_tcp_ban --update --seconds ${_ban_time} -j DROP -m comment --comment "Update ban time if IP address is found in temp_tcp_ban list" || exit 1
    iptables -A out_vuln_scan -p TCP -o ${_tor_iface} --sport ${_tor_port} -m state --state NEW -m recent --set -m comment --comment "Monitor number of new conncetions to ${_server_iface}" || exit 1
    iptables -A out_vuln_scan -p TCP -o ${_tor_iface} --sport ${_tor_port} -m state --state NEW -m recent --update --seconds 30 --hitcout 10 -j out_temp_ban -m comment --comment "Ban address when to many new connections are attempted on ${_tor_iface}" || exit 1
done
iptables -A out_vuln_scan -j RETURN -m comment --comment "Return un-matched packets for further processing" || exit 1

## Add rules to accept/allow outbound packets
iptables -N tor_out -m comment --comment "Make custom chain for allowing Tor exit node services" || exit 1
for _tor_port in ${_tor_ports//,/ }; do
    iptables -A tor_out -p TCP -o ${_tor_iface} --sport ${_tor_port} -m state --state NEW -m recent --set --name limit_${_tor_port} -m comment --comment "Track out-going tcp connections from port ${_tor_port}" || exit 1
    iptables -A tor_out -p TCP -o ${_tor_iface} --sport ${_tor_port} -m state --state NEW -m recent --update --seconds ${_outgoing_tcp_update_seconds:-60} --hitcount ${_outgoing_tcp_hitcount:-8} --rttl --name limit_${_tor_port} -j LOG --log-prefix "TCP flooding port ${_tor_port}" -m comment --comment "Log atempts to flood port ${_tor_port} from your server" || exit 1
    iptables -A tor_out -p TCP -o ${_tor_iface} --sport ${_tor_port} -m state --state NEW -m recent --update --seconds ${_outgoing_tcp_update_seconds:-60} --hitcount ${_outgoing_tcp_hitcount:-8} --rttl --name limit_${_tor_port} -j DROP -m comment --comment "Drop attempts to flood port ${_tor_port} from your server" || exit 1
    iptables -A tor_out -p TCP -o ${_tor_iface} --sport ${_tor_port} -m limit --limit ${_outgoing_tcp_burst_minute:-15}/minute --limit-burst ${_outgoing_tcp_burst_limit:-1000} -j ACCEPT -m comment --comment "Accept with conditions new connections from port ${_tor_port} from your server" || exit 1
done
iptables -A tor_out -j RETURN -m comment ---comment "Reurn un-matched packets for further filtering or default polices to take effect." || exit 1
## Activate jumps from default output chain to new custom filtering chains
iptables -A OUTPUT -p TCP -o ${_tor_iface} -j out_vuln_scan -m comment --comment "Jump outbound packets through vulnerability scaning mitigation" || exit 1
iptables -A OUTPUT -p TCP -o ${_tor_iface} -j tor_out -m comment --comment "Jump outbound packets through conditional acceptance" || exit 1

Ejecute arriba con bashpara realizar magia en variables con ,levas, es decir;

user@host~# bash iptables_limit_tor.sh

Aquí está esa lista de variables nuevamente.

_tor_iface="eth1"
_tor_ports="9050,9051"
_ban_time="600"
_outgoing_tcp_update_seconds="600"
_outgoing_tcp_hitcount="8"
_outgoing_tcp_burst_minute="15"
_outgoing_tcp_burst_limit="1000"

Tenga en cuenta que es posible que también desee filtrar nuevas conexiones salientes por -m state NEW ! --syntipos dedivertidonegocio utilizado por algunos bots para encontrar servidores explotables. Aquí hay una cadena de ejemplo en la que podría preferir las dos anteriores para filtrar aún más este tipo de conversaciones con formato incorrecto.

iptables -N out_bad_packets -m comment --comment "Make new chain for filtering malformed packets" || exit 1
iptables -A out_bad_packets -p TCP --fragment -j out_temp_ban -m comment --comment "Drop all fragmented packets" || exit 1
iptables -A out_bad_packets -p TCP -m state --state INVALID -j out_temp_ban -m comment --comment "Drop all invalid packets" || exit 1
iptables -A out_bad_packets -p TCP ! --syn -m state --state NEW -j out_temp_ban -m comment --comment "Drop new non-syn packets" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ALL NONE -j out_temp_ban -m comment --comment "Drop NULL scan" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ALL ALL -j out_temp_ban -m comment --comment "Drop XMAS scan"|| exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ALL FIN,URG,PSH -j out_temp_ban -m comment --comment "Drop stealth scan 1" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ALL SYN,RST,ACK,FIN,URG -j out_temp_ban -m comment --comment "Drop pscan 1"|| exit 1
iptables -A out_bad_packets -p TCP --tcp-flags SYN,FIN SYN,FIN -j out_temp_ban -m comment --comment "Drop pscan 2" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags FIN,RST FIN,RST -j out_temp_ban -m comment --comment "Drop pscan 3" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags SYN,RST SYN,RST -j out_temp_ban -m comment --comment "Drop SYN-RST scan" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ACK,URG URG -j out_temp_ban -m comment --comment "Drop URG scans" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ALL SYN,FIN -j out_temp_ban -m comment --comment "Drop SYNFIN scan" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ALL URG,PSH,FIN -j out_temp_ban -m comment --comment "Drop nmap Xmas scan" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ALL FIN -j out_temp_ban -m comment --comment "Drop FIN scan" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags ALL URG,PSH,SYN,FIN -j out_temp_ban -m comment --comment "Drop nmap-id scan" || exit 1
iptables -A out_bad_packets -p TCP --tcp-flags RST RST -o ${_tor_iface} --sport ${_tor_port} -m limit --limit 2/second --limit-burst 3 -j out_temp_ban -m comment --comment "Mitigate Smurf attacks from excesive RST packets"
iptables -A out_bad_packets -p TCP --tcp-flags RST RST -o ${_tor_iface} --sport ${_tor_port} -m limit --limit 2/second --limit-burst 2 -j RETURN -m comment --comment "Ban Smurf attacks using excesive RST packets"
iptables -A out_bad_packets -j RETURN -m comment --comment "Return un-matched packets for further processing." || exit 1

Sin embargo, la cadena anterior sería muy restrictiva ya que cualquier paquete coincidente tendrá la IP prohibida (quizás cambiarla -j out_temp_bano -j DROPpara -j REJECTprobarla) durante la cantidad de segundos elegida en las reglas de esa cadena. Este conjunto de reglas también podría causar errores positivos cuando aplicaciones mal codificadas en el lado del cliente se vuelven a conectar a través de un nuevo Tor Cercut.

~~~~~

Software a considerar para mejorar aún más el tráfico. Consulte firejailpara Linux, la fuente está en Github y Source forge y las páginas de manual se pueden encontrar en la página de inicio anterior, un subdominio de wordpress, y DigitalOcean tiene una guía para Nginx con PHP y Firejail que con una pequeña modificación podría brindarle mucha más información sobre dónde se debe reducir la velocidad de la red. Existen otras herramientas, como KVMtambién, que se pueden utilizar para mantener servicios específicos dentro de los límites operativos, de modo quecomercioalrededor para encontrar el que funcione mejor para su sistema.

Otra opción más sería ejecutar fail2bande tal manera que cuando un administrador de sistemas loco intente una conexión http o ssl a su IP, se agregue una regla para desconectar -m state --state NEWlas conexiones a aquellos que solicitan su página de aviso de salida. Esto, si se combina con límites de tiempo sensatos para la eliminación de la prohibición, podría permitirle al servidor remoto un descanso mientras su administrador del sistema murmura sobre la contaminación del registro ;-) Sin embargo, eso está más allá del alcance de esta respuesta actual y depende del software que esté utilizando para servir. páginas de avisos de salida; Sugerencia que tanto nginx como apache servirán el primer bloque de vhost o servidor en sus configuraciones si ahora se solicitó la URL. Si usa algo que no sea Apache o nginx, querrá consultar las páginas de manual, pero para mí fue tan simple como configurar el primer vhost para que inicie sesión en un archivo diferente y hacer que fail2ban agregue cualquier IP de ese registro a una lista de prohibición temporal. ; Esto también funciona muy bien para prohibir bots en servidores públicos porque generalmente usan una dirección IP y al no proporcionar una solicitud de dominio, el servidor entrega la trampa de bot o, en este caso, un aviso de salida.

Me inclinaría por ejecutar una política de salida restringida de Tor (parece que ya lo tienes controlado) y luego impulsar el tráfico a través de túneles VPN, puntos de crédito adicionales por el equilibrio de carga entre múltiples túneles. Porque esto causaría menos interrupciones en el tráfico de la red Tor y mantendría los ojos de su ISP nublados ante el hecho de que está ejecutando un nodo de salida... a menos que deseen admitir haber husmeado y descifrado su tráfico VPN. Esto se debe a que ejecutar reglas que prohíban temporalmente o permitan que el host remoto se autoprohíba podría generar una violación de la privacidad de los clientes de su nodo, mientras que enviar el tráfico a una VPN (o pocas) ayudaría a la privacidad de su cliente y mantendría su ISP de ser acosado conpeticionespara los registros de tráfico de su red por cualquier gobierno capaz de ejecutar whois www.some.domain.

~~~~

Ediciones/Actualizaciones

~~~~

Hice un viaje a mis notas extensas y abrí las configuraciones de los servidores públicos que uso.

Aquí está la jail.localregla de fail2ban

[apache-ipscan]
enabled  = true
port = http,https
filter = apache-ipscan
logpath = /var/log/apache*/*error_ip*
action = iptables-repeater[name=ipscan]
maxretry = 1

Y aquí está el apache-ipscan.confarchivo de filtro.

[DEFAULT]
_apache_error_msg = \[[^]]*\] \[\S*:error\] \[pid \d+\] \[client <HOST>(:\d{1,5})?\]
[Definition]
failregex = \[client <HOST>\] client denied by server .*(?i)/.*
#^<HOST>.*GET*.*(?!)/.*
#   ^%(_apache_error_msg)s (AH0\d+: )?client denied by server configuration: (uri )?.*$
#            ^%(_apache_error_msg)s script '\S+' not found or unable to stat(, referer: \S+)?\s*$
ignoreregex = 
# DEV Notes: 
# the web server only responds to clients with a valid Host: 
# header. anyone who tries using IP only will get shunted into 
# the dummy-error.log and get a client-denied message
#
# the second regex catches folks with otherwise valid CGI paths but no good Host: header
#
# Author: Paul Heinlein

Y aquí está el iptables-repeater.confarchivo de acción.

# Fail2Ban configuration file
#
# Author: Phil Hagen <[email protected]>
# Author: Cyril Jaquier
# Modified by Yaroslav Halchenko for multiport banning and Lukas Camenzind for persistent banning
# Modified by S0AndS0 to combine features of previous Authors and Modders
#
[Definition]
# Option:  actionstart
# Notes.:  command executed once at the start of Fail2Ban.
# Values:  CMD
#
actionstart = iptables -N fail2ban-BADIPS-<name>
              iptables -A fail2ban-BADIPS-<name> -j RETURN
          iptables -I INPUT -j fail2ban-BADIPS-<name>
          ## Comment above line and uncomment bello line to use multiport and protocol in addition to named jails
          #iptables -I INPUT -p <protocol> -m multiport --dports <port> -j fail2ban-BADIPS-<name>
          # set up from the static file
          #cat /etc/fail2ban/ip.blocklist.<name> |grep -v ^\s*#|awk '{print $1}' | while read IP; do iptables -I fail2ban-BADIPS-<name> 1 -s $IP -j DROP; done
          cat /etc/fail2ban/ip.blocklist.<name> |grep -v ^\s*#|awk '{print $1}' | while read IP; do iptables -I fail2ban-BADIPS-<name> 1 -d $IP -j DROP; done
          ## Comment above line and uncomment bellow line to check if there are blacklist files to load before attempting to load them
          # if [ -f /etc/fail2ban/ip.blacklist.<name> ]; then cat /etc/fail2ban/ip.blacklist.<name> | grep -e <name>$ | cut -d "," -s -f 1 | while read IP; do iptables -I fail2ban-BADIPS-<name> 1 -s $IP -j DROP; done; fi
# Option:  actionstop
# Notes.:  command executed once at the end of Fail2Ban
# Values:  CMD
#
actionstop = iptables -D INPUT -p <protocol> -m multiport --dports <port> -j fail2ban-BADIPS-<name>
         iptables -F fail2ban-BADIPS-<name> 
         iptables -X fail2ban-BADIPS-<name>
# Option:  actioncheck
# Notes.:  command executed once before each actionban command
# Values:  CMD
#
#actioncheck = iptables -n -L INPUT | grep -q fail2ban-BADIPS-<name>
actioncheck = iptables -n -L OUTPUT | grep -q fail2ban-BADIPS-<name>
# Option:  actionban
# Notes.:  command executed when banning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    <ip>  IP address
#          <failures>  number of failures
#          <time>  unix timestamp of the ban time
# Values:  CMD
#
#actionban = if ! iptables -C fail2ban-BADIPS-<name> -s <ip> -j DROP; then iptables -I fail2ban-BADIPS-<name> 1 -s <ip> -j DROP; fi
actionban = if ! iptables -C fail2ban-BADIPS-<name> -d <ip> -j DROP; then iptables -I fail2ban-BADIPS-<name> 1 -d <ip> -j DROP; fi
# Add offenders to local blacklist, if not already there
        if ! grep -Fxq '<ip>,<name>' /etc/fail2ban/ip.blocklist.<name>; then echo "<ip>,<name> # fail2ban/$( date '+%%Y-%%m-%%d %%T' ): auto-add for BadIP offender" >> /etc/fail2ban/ip.blocklist.<name>; fi
# Report offenders to badips.com
#        wget -q -O /dev/null www.badips.com/add/<name>/<ip>
# Option:  actionunban
# Notes.:  command executed when unbanning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    <ip>  IP address
#          <failures>  number of failures
#          <time>  unix timestamp of the ban time
# Values:  CMD
#
#actionunban = iptables -D fail2ban-REPEAT-<name> -s <ip> -j DROP
actionunban = iptables -D fail2ban-REPEAT-<name> -d <ip> -j DROP
# Disabled clearing out entry from ip.blacklist (somehow happens after each stop of fail2ban)
#sed --in-place '/<ip>,<name>/d' /etc/fail2ban/ip.blacklist.<name>
[Init]
# Defaut name of the chain
# 
# Defaut name of the chain
name = BADIPS
# Option:  port
# Notes.:  specifies port to monitor
# Values:  [ NUM | STRING ]  Default:
# 
#port = ssh
# Option:  protocol
# Notes.:  internally used by config reader for interpolations.
# Values:  [ tcp | udp | icmp | all ] Default: tcp

Tenga en cuenta que el filtro anterior se ha editado para bloquear OUTPUTlas acciones de inicio/detención, pero aún querrá agregar las -p TCP -m state --state NEWconfiguraciones a cada línea para que solo se prohíban las nuevas conexiones salientes desde la dirección IP registrada.

Lo último es configurar una configuración de Apache vHost que dirige a aquellos que no solicitan un dominio a un registro de errores y acceso específico y establecer el acceso permitido o denegado de manera que siempre haya errores, ni siquiera el loopback debería poder abrir la página sin que aparezcan errores. . Por último, pero no menos importante, está configurar la página de error de Apache con el aviso de salida predeterminado de Tor para que se muestre en lugar de 503mensajes 404insulsos. O si ha agregado las líneas de estado a las acciones de iptables para fail2ban, podría fácilmente señalar el mismo archivo de registro que utiliza su aviso de salida. El resultado sería que su servidor no podría establecer nuevas conexiones con la IP del servidor que verificó su dirección IP, pero las conexiones establecidas y relacionadas aún estarían permitidas, es decir, aún podrían navegar por sus otras páginas pero usted no podría navegar por las suyas. .

Answer 4

Tengo una solución mejor: el servidor de caché Squid. Servidor de caché Squid disponible para configurar definiendo aclusted denyo acceptcada uno acl. Es muy interesante que el equipo de Squid defina un conjunto de reglas en su wiki que encontró tu pregunta.allá iptables,PFu otros no pueden hacer su trabajo porque simplemente trabajan en otras capas.