Linux Sin Humo (Publicaciones sobre networking)

Introducción a nftables y familia de direcciones

sebelk — Wed, 22 Jan 2025 18:07:44 GMT

Historia e Introducción

Antes de iptables y nftables, existía ipfwadm, una herramienta que se utilizaba en las primeras versiones del kernel de Linux para gestionar el firewall. Aunque ipfwadm sentó las bases para el firewalling en Linux, fue reemplazada debido a su limitada capacidad de manejo de tráfico y escalabilidad. Primero fue sustituida por ipchains y más tarde por el popular iptables.

Comunidad y Grupos Clave

Netfilter Project: La comunidad principal detrás de iptables y nftables. Este grupo ha sido esencial en el desarrollo, mantenimiento y promoción de herramientas de filtrado de paquetes en Linux.
Kernel Contributors: Muchos desarrolladores de kernel han colaborado en la optimización de las capacidades de firewalling en Linux, asegurando su integración fluida y eficiente.

Creación de nftables

nftables fue introducido en 2014 como el sucesor de iptables, diseñado para abordar las limitaciones de su predecesor en términos de rendimiento y escalabilidad.

Si bien eso fue hace más de 10 años, hay cambios tecnológicos que van por ascensor y otros por escalera. En ámbitos corporativos el mero hecho de reemplazar un software que es cardinal en una infraestructura, no es una tarea trivial. Ese cambio se debe a que los tiempos de vida de las distribuciones que las medianas y grandes organizaciones tienen soporte a largo a plazo. A veces es falta de urgencia y otras veces por sencilla negligencia :smile:.

Sin embargo apenas 3 datos para considerar la adopción de nftables:

RHEL9 considera iptables, ipset y ebtables herramientas depreciadas.
iptables no estará disponible en RHEL10 ni en OpenShift 4.16.
Debian Bullseye (a la fecha oldstable) ha depreciado iptables en favor de nftables.

¿Cuál es el problema de iptables?

Aunque ha sido una herramienta extraordinaria que ha servido de base para muchas soluciones de firewall, iptables presenta algunas limitaciones. A continuación, mencionamos tres de las más importantes:

Reprocesamiento completo al modificar reglas:
Cada vez que se agrega o elimina una regla, el kernel debe volver a procesar toda la lista de reglas. Este enfoque resulta ineficiente, especialmente en entornos donde se realizan cambios frecuentes o se manejan firewalls con un gran número de reglas.
Gestión complicada de rangos de direcciones IP:
Manejar rangos de direcciones IP o grandes conjuntos de direcciones en iptables puede ser tedioso y poco práctico. La herramienta ipset fue una solución ingeniosa para optimizar esta tarea, ya que permite manejar conjuntos de IPs, rangos o puertos de manera más eficiente. Sin embargo, su uso añade una capa de complejidad adicional al proceso de configuración y gestión.
Extensiones con sintaxis inconsistente:
iptables cuenta con extensiones como xtables, que amplían sus funcionalidades al incluir capacidades avanzadas como el seguimiento de conexiones o la inspección profunda de protocolos. No obstante, la sintaxis de estas extensiones no siempre es uniforme ni intuitiva, lo que puede dificultar su uso y generar confusiones en configuraciones complejas.

En cambio, desde su incorporación, nftables ha demostrado ser una herramienta eficiente y moderna para la gestión del tráfico de red en Linux. Una de sus principales innovaciones es consolidar las herramientas clásicas como iptables, ip6tables, ebtables y arptables en una única interfaz, simplificando tanto la configuración como el mantenimiento.

Conceptos claves de nftables

Contexto y Familias de Direcciones

En iptables, cada tipo de tráfico o protocolo tenía su propio comando o herramienta específica, que funcionaba de manera independiente:

Comando/herramienta	Propósito
`iptables`	Filtrar y manipular tráfico IPv4.
`ip6tables`	Filtrar y manipular tráfico IPv6.
`arptables`	Filtrar y manipular tráfico ARP.
`ebtables`	Filtrar tráfico en bridges (Ethernet frames).

Cada una de estas herramientas tenía su propia sintaxis y requería comandos separados para manejar diferentes tipos de tráfico, lo que podía ser confuso y propenso a errores.

Problemas del enfoque de iptables

Fragmentación:
- Si querías manejar tráfico IPv4 e IPv6, debías configurar reglas separadas con iptables e ip6tables, incluso si las reglas eran idénticas.
- Lo mismo ocurría si querías gestionar tráfico ARP con arptables o tráfico en bridges con ebtables.
Falta de unificación:
- Cada herramienta tenía su propia lógica, lo que aumentaba la complejidad administrativa.
- No existía una forma centralizada de gestionar tráfico que abarcase múltiples protocolos o tipos de datos.
Mantenimiento difícil:
- Las configuraciones de firewall requerían gestionar múltiples conjuntos de reglas, lo que hacía el mantenimiento y la depuración más complicados.

Cómo nftables mejoró este enfoque:

Introducción de familias: En nftables, las familias permiten manejar diferentes tipos de tráfico dentro de un mismo marco conceptual, con una sintaxis unificada.
- Familia ip: Maneja tráfico IPv4.
- Familia ip6: Maneja tráfico IPv6.
- Familia inet: Unifica IPv4 e IPv6.
- Familia arp: Maneja tráfico ARP.
- Familia bridge: Maneja tráfico L2 en bridges.
- Familia netdev: Maneja tráfico en interfaces específicas.
Unificación de reglas:
- Con la familia inet, puedes escribir reglas que funcionen tanto para IPv4 como para IPv6.
- Esto simplifica significativamente la configuración y el mantenimiento del firewall.
Menor duplicación de configuraciones: En lugar de mantener múltiples herramientas (iptables, ip6tables, arptables, ebtables), todo se gestiona con el comando nft.

Ejemplos en nftables:

# Una regla para IPv4 e IPv6
nft add rule inet filter input ip saddr 192.168.0.0/24 accept
nft add rule inet filter input ip6 saddr fc00::/7 accept

nft add table arp filter
nft add chain arp filter input { type filter hook input priority 0; }
# Permitir solicitudes ARP desde el rango 192.168.1.0/24 en eth0
nft add rule arp filter input iif "eth0" arp sip 192.168.1.0/24 arp op request accept

# Bloquear cualquier otra solicitud ARP
nft add rule arp filter input iif "eth0" arp op request drop

nft add table bridge filter
nft add chain bridge filter forward { type filter hook forward priority 0; }
# Permitir solicitudes ARP desde direcciones MAC específicas en el bridge br0
nft add rule bridge filter forward iif "br0" ether type arp arp op request ether saddr 00:11:22:33:44:55 accept
nft add rule bridge filter forward iif "br0" ether type arp arp op request ether saddr 00:aa:bb:cc:dd:ee accept

# Bloquear cualquier otra solicitud ARP en el bridge
nft add rule bridge filter forward iif "br0" ether type arp arp op request drop

Diferencia entre las familias inet y netdev

La familia netdev puede ser una opción adecuada para implementar policing con nftables, dependiendo del escenario. Esto se debe a que la familia netdev opera en el hook ingress, lo que significa que puede evaluar el tráfico directamente en la interfaz antes de que llegue al stack de red.

Vamos a explorar por qué usar la familia netdev podría ser más apropiado para policing en algunos casos y cuándo es mejor utilizar otras familias.

Por qué usar la familia netdev para policing:

Posición temprana en el flujo del tráfico:
La familia netdev opera en el hook ingress, lo que significa que intercepta el tráfico inmediatamente después de que llega a la interfaz de red y antes de que sea procesado por el stack TCP/IP.
Esto permite implementar políticas de policing directamente en el nivel de la interfaz, evitando sobrecargar el sistema con tráfico innecesario.

Ejemplo de regla de policing en netdev:

nft add table netdev ingress
nft add chain netdev ingress mychain { type filter hook ingress priority 0; }
nft add rule netdev ingress mychain ip limit rate 10 mbps drop

Esta regla limita el tráfico IP entrante a 10 Mbps en la interfaz.
Evitar procesamiento innecesario:
Como netdev actúa antes de que los paquetes sean entregados al stack TCP/IP, los paquetes que no cumplen con las políticas son descartados sin consumir recursos adicionales del sistema.
Ideal para interfaces específicas:
Cuando el objetivo es aplicar policing solo en una interfaz específica (por ejemplo, eth0), la familia netdev es la opción más directa.
Compatibilidad con limit rate:
La familia netdev admite acciones como limit rate, que es esencial para configurar políticas de policing basadas en rates.

¿Cuándo usar netdev frente a otras familias (ip, inet)?

Criterio	Familia `netdev`	Familias `ip`/`inet`
Posición en el stack	Hook `ingress`, antes del stack TCP/IP.	Hook `prerouting`, `forward`, o `input`, después de ingresar al stack.
Eficiencia	Muy alta: paquetes descartados antes de procesarse.	Menor: los paquetes son procesados parcialmente antes de aplicar las políticas.
Tráfico inspeccionado	Solo tráfico entrante en una interfaz específica.	Tráfico en todas las interfaces (dependiendo de la configuración).
Complejidad de las reglas	Más limitada: ideal para políticas simples (policing básico).	Más flexible: soporta reglas complejas (filtrado avanzado, conntrack).
Uso típico	Policing directo en una interfaz (DDoS, límites de ancho de banda).	Filtrado y políticas basadas en estado o dirección IP.

Limitaciones de la familia netdev:

Solo para tráfico entrante:
La familia netdev opera únicamente en el hook ingress, por lo que no puedes aplicar policing en el tráfico saliente de una interfaz.
Falta de seguimiento de conexiones (conntrack):
No puedes usar estados como NEW o ESTABLISHED, ya que netdev opera antes de que el módulo conntrack pueda procesar el tráfico.
Menor flexibilidad:
Si necesitás reglas más complejas basadas en capas superiores (por ejemplo, L7 o estados de conexión), las familias ip o inet son más adecuadas.

¿Cuándo es mejor usar la familia netdev para policing?

Tráfico entrante en una interfaz específica: Cuando necesitás limitar o descartar tráfico directamente en una interfaz antes de que afecte el sistema. Ejemplo: Mitigar un ataque DDoS en eth0.
Simplicidad y eficiencia: Si solo necesitas evaluar tráfico basándote en tasas o direcciones básicas (IP, MAC).

Ejemplo práctico:

Supongamos que queremos limitar el tráfico entrante a 100 Mbps en una interfaz específica (eth0):

nft add table netdev ingress
nft add chain netdev ingress eth0_chain { type filter hook ingress priority 0; }
nft add rule netdev ingress eth0_chain limit rate 100 mbps drop

Diferencia entre la familia bridge y netdev

Dado que la tanto la tabla bridge como la tabla netdev operan en Capa 2 uno podría preguntarse, qué diferencia hay entre estas dos familias, aquí tenemos una tabla comparativa detallada entre las familias bridge y netdev en nftables:

Aspecto	Familia `bridge`	Familia `netdev`
Nivel del modelo OSI	Capa 2 (L2)	Capa 2 (L2), pero en el contexto de interfaces individuales.
Tráfico manejado	Tráfico que cruza un bridge (tramas Ethernet).	Todo el tráfico en una interfaz específica antes de llegar al stack de red.
Propósito principal	Controlar y filtrar tráfico dentro de bridges.	Filtrar tráfico en una interfaz individual (sin importar si forma parte de un bridge).
Ámbito de aplicación	Solo funciona en interfaces que forman parte de un bridge.	Funciona en cualquier interfaz (física o virtual), bridge o no.
Casos de uso típicos	- Aislar tráfico entre puertos de un bridge. - Proteger bridges contra broadcast storms, spoofing de MAC, etc. - Controlar tráfico entre VLANs en un bridge.	- Filtrar tráfico directo en una interfaz (ingress/egress). - Detectar y mitigar DDoS a nivel de interfaz. - Filtrar ARP o IPv4 antes de pasar al stack de red.
Compatibilidad con VLANs	Sí, puede filtrar tráfico basado en etiquetas VLAN (802.1Q).	No trabaja específicamente con VLANs.
Estado de conexión	No tiene integración con `conntrack`.	No tiene integración con `conntrack`.
Posición en el stack	Filtra tráfico que pasa a través de un bridge antes de ser reenviado.	Filtra tráfico directamente en una interfaz, antes de ser procesado por el stack de red.
Soporte de ARP	Sí, puede filtrar tramas ARP.	Sí, puede filtrar tramas ARP.
Soporte de IPv4/IPv6	Sí, puede inspeccionar tráfico IP encapsulado.	Sí, puede inspeccionar tráfico IP encapsulado.
Direcciones MAC	Puede filtrar según direcciones MAC de origen y destino.	Puede filtrar según direcciones MAC de origen y destino.
Uso con interfaces individuales	No, requiere que las interfaces formen parte de un bridge.	Sí, funciona en cualquier interfaz individual.
Reemplaza a...	`ebtables`.	`tc ingress` para ciertas tareas de filtrado.
Limitaciones	- Solo opera en tráfico dentro de bridges. - No puede controlar tráfico de interfaces individuales fuera del bridge.	- No tiene integración con `conntrack`. - No puede manejar tráfico reenviado entre interfaces.

Diferencias clave entre bridge y netdev:

Ámbito del tráfico manejado:
bridge: Filtra tráfico que cruza un bridge, conectando múltiples interfaces dentro del mismo dominio de difusión.
netdev: Filtra tráfico directo en una interfaz individual, antes de pasar al stack de red.
Dependencia de bridges:
bridge: Solo funciona en interfaces que son parte de un bridge.
netdev: Funciona en cualquier interfaz, sin importar si es parte de un bridge o no.
Posición en el stack de red:
bridge: Opera después de que el tráfico ha ingresado al bridge pero antes de ser reenviado a otra interfaz.
netdev: Opera antes de que el tráfico entre al stack de red del sistema operativo, en el hook ingress.
Casos de uso:
bridge: Aislar tráfico dentro del bridge, controlar VLANs, proteger contra ataques L2 como spoofing de MAC.
netdev: Inspeccionar todo el tráfico que entra o sale de una interfaz específica, ideal para mitigación temprana de DDoS o filtros basados en MAC/IP/ARP.

¿Cuándo usar cada una?

Usa la familia bridge si:

Tenemos configurado un bridge que conecta múltiples interfaces.
Necesitamos controlar tráfico entre dispositivos conectados al mismo bridge.
Queremos aislar tráfico entre VLANs o puertos del bridge.
Deseamos implementar políticas de seguridad para tráfico L2 dentro del bridge.

Usa la familia netdev si:

Queremos filtrar tráfico directo en una interfaz individual, incluso si no es parte de un bridge.
Necesitamos mitigar DDoS o ataques en el hook más temprano (ingress), antes de que el tráfico llegue al stack de red.
Deseamos inspeccionar tráfico ARP, IPv4 o IPv6 en una interfaz específica.

Ejemplos prácticos:

Con bridge:

Bloquear tráfico entre dos interfaces en un bridge:

nft add table bridge filter
nft add chain bridge filter forward { type filter hook forward priority 0; }
nft add rule bridge filter forward iif "eth0" oif "eth1" drop
nft add rule bridge filter forward iif "eth1" oif "eth0" drop

Permitir solo tráfico ARP en el bridge:

nft add rule bridge filter forward ether type arp accept
nft add rule bridge filter forward drop

Con netdev:

Bloquear todo el tráfico IPv4 en una interfaz específica (eth0):

nft add table netdev filter
nft add chain netdev filter ingress { type filter hook ingress priority 0; }
nft add rule netdev filter ingress iif "eth0" ip drop

Mitigar ataques DDoS limitando paquetes por segundo:

nft add rule netdev filter ingress iif "eth0" ip limit rate 1000/second drop

Entonces:

Familia bridge: Para manejar tráfico dentro de un bridge, enfocándose en L2 (direcciones MAC, VLANs, tramas Ethernet).
Familia netdev: Para filtrar tráfico temprano en una interfaz específica, independientemente de si forma parte de un bridge.

Ambas familias trabajan en L2, pero con propósitos distintos y aplicables en diferentes escenarios.

Resumen:

En iptables, no existía el concepto de familias. En su lugar, se usaban herramientas separadas para cada protocolo o tipo de tráfico (iptables, ip6tables, arptables, ebtables). Esto hacía que la configuración fuera fragmentada y menos eficiente.

Con la llegada de nftables, se introdujo el concepto de familias para unificar la gestión de diferentes tipos de tráfico, mejorando la flexibilidad, la simplicidad y el mantenimiento de las reglas de firewall. Este cambio fue una de las razones clave por las que nftables es considerado un reemplazo moderno y más avanzado.

Conocer en profundidad nftables y el concepto de las familias, tiene implicancias sumamente prácticas. Por ejemplo: ¿qué familia usarías para poder separar en una misma LAN el tráfico inalámbrico del cableado? Lo dejo para que lo pienses. 😊

Fuentes y más información

Borrar configuraciones de red

sebelk — Wed, 09 Oct 2019 21:42:29 GMT

En Linux a veces nos podemos meter en un embrollo. Los sistemas para configurar y administrar la red son varios:

net-tools
iproute2
Archivos "legacy"
NetworkManager
systemd-networkd, etc

Cuando colisionan y necesitamos blanquear la configuraciones podemos hacer lo siguiente:

for i in $(ip -4 -o link |  cut -f2 -d ":"  | grep -v '^lo$')
        do
           ip addr flush dev  "$i"
           ip route flush dev  "$i"
           ip rule flush dev  "$i"
        done

Listo, a hacer la configuración en limpio ahora!

Obviamente no deberíamos hacer esto con una conexión remota a un equipo no virtualizado :)

Diagrama de netfilter/iptables

sebelk — Thu, 26 Sep 2019 18:11:49 GMT

Claves

Las reglas se organizan en tablas: raw, mangle, nat, filter.
Las tablas tienen cadenas, filter, por ejemplo tiene INPUT, OUTPUT y FORWARD. Y como se puede apreciar las decisiones de routing implican que INPUT y FORWARD son excluyentes. Lo mismo que OUTPUT y FORWARD.
El orden siempre es raw, mangle, nat, filter (si es que están presentes).
Hay 3 lugares en que se decide el ruteo, uno de los cuales es local.
Solamente se filtra en filter, obviamente.

Más?

Iptables Tutorial 1.2.2

Estadísticas generales de sockets

sebelk — Sun, 22 Sep 2019 13:53:25 GMT

El archivo /proc/net/sockstat muestra una síntesis muy útil de cada tipo de socket:

# cat /proc/net/sockstat

sockets: used 435
TCP: inuse 29 orphan 0 tw 10 alloc 58 mem 2
UDP: inuse 101 mem 83
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0

Interesante ¿no?

Skype en la bandeja de sistema de Plasma 5.0

sebelk — Fri, 31 Jul 2015 20:58:01 GMT

Skype proporciona versiones de 32-bit para Linux. Al usarla en una arquitectura x86_64 tenemos un problema al cerrar la ventana de la aplicación… desaparece. Esto es porque Plasma 5.0 no soporta más el protocolo XEmbed. Una de las posibles soluciones es instalar el paquete sni-qt para 32 bit:

sudo dnf install sni-qt.i686

Y ¡Listo!

[caption id="attachment_743" align="aligncenter" width="640"] skype icon en Bande del systema[/caption]

Estaciones Virtuales Inalámbricas

sebelk — Mon, 30 Apr 2012 14:40:40 GMT

Estaciones Virtuales inalámbricas por Sergio Belkin se encuentra bajo una Licencia Creative Commons Atribución-CompartirDerivadasIgual 2.5 Argentina.

A veces es necesario simular una gran cantidad de estaciones (es decir clientes o “supplicants”) ante un Access Point para obtener una estimación de las capacidades del equipo y/o firmware. Seguramente existe algún que otro software con licencia restrictiva que nos permita hacer eso. Pero ¿se podrá hacer eso con una sola notebook con Linux? La respuesta es sí.

Veremos como:

Deshabilitamos cifrado por hardware

echo options ath9k nohwcrypt=1 > /etc/modprobe.d/ath9k.conf

udev

`Editamos /lib/udev/rules.d/75-persistent-net-generator.rules`

Queremos que udev no maneje la interfaz wireless wlan0, entonces sacamos de la siguiente regla a wlan0

KERNEL!=”eth*|ath*|ra*|ctc*|lcs*|hsi*”, GOTO=”persistent_net_generator_end”

Editar el archivo /etc/udev/rules.d/70-persistent-net.rules

Tampoco necesitamos la siguiente la regla, así que la borramos:

SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”68:a3:c4:33:44:55″, ATTR{dev_id}==”0x0″, ATTR{type}==”1″, KERNEL==”wlan*”, NAME=”wlan0″

Recargar la configuración

systemctl restart udev-trigger.service

Detener servicios que interfieren con la creación de intefaces virtuales

systemctl stop NetworkManager.service

systemctl stop avahi-daemon.service

Terminar procesos de wpa_supplicant

killall wpa_supplicant

Agregamos una interfaz virtual inalámbrica

iw phy phy0 interface add sta0 type station

Le cambiamos la mac address, sino NO va a funcionar

macchanger -r sta0

Activamos la interfaz

ip link set dev sta0 up

Lanzamos el cliente wireless

wpa_supplicant -t -ista0 -c /etc/wpa_supplicant/peap.conf -B -f /var/log/wpa-sta0.log

Arrancamos el cliente dhcp

dhclient -v -cf /etc/wpa_supplicant/dhclient.conf sta0

¡Listo!

Se puede hacer un script (de hecho es lo que hice) para automatizar estos pasos y agregar tantas interfaces virtuales como sea posible.

Reconocimiento: El artículo de Candela Technologies en http://www.candelatech.com/vsta.php fue de suma utilidad.

Advertencia: Esta receta funciona en particular para el módulo ath9k, es probable que sea necesario modificar algo con otros drivers o que directamente no funcione. Asimismo, se utilizó Fedora 16 desde el lado cliente, obviamente deberían realizarse las adapataciones pertinentes de acuerdo a la distribución.

El pensamiento instantáneo

sebelk — Sun, 29 May 2011 20:55:40 GMT

Recientemente leí un artículo ¹ de Jon “Maddog” Hall² (Director Ejecutivo de Linux International³). La nota giraba alrededor del tema de la netiqueta, al cual “Maddog” arribó explicando hábilmente lo que el denomina “el factor de retardo” y “transmisión instantánea”.

¿Qué es el factor de retardo? Pues bien hagamos un viaje en el tiempo hacia el siglo XIX por lo menos . Los medios de comunicación y de transporte se desplazaban dificultosa y lentamente. Por lo tanto, en muchos aspectos la comunicación a mediana y larga distancia llevaba mucho más tiempo comparándolo con nuestros días.

Por ejemplo, una persona que hiciese un viaje de largas distancias, podría tener tiempo mientras escribía una carta, para construir, elaborar, descartar y rehacer sus pensamientos y formas en que los volcaba en el papel (o en el soporte físico que tuvieran a mano por esos tiempos). Y mientras el emisor esperaba la respuesta del receptor tendría probablemente tiempo para analizar acerca de lo que él mismo había comunicado. Tanto el emisor como el receptor contaban con ese factor de retardo.

La transmisión instantánea mediante el teléfono celular, el correo electrónico, la mensajería instantánea, y las redes sociales han aminorado ese factor.

Esto puede parecer en principio una obviedad, pero a veces lo evidente es lo primero que se pasa por alto. Sin embargo, omitirlo sería un error en cualquier discusión acerca de Facebook.

No es el asunto, tal vez, determinar si Facebook (se puede aplicar algo similar a Twitter⁴) es una herramienta “éticamente aceptable” o no. Quiero decir: no es preguntarse: ¿Está bien usar Facebook? sino la pregunta tal vez, que se deberíamos hacer es ¿Para qué es útil Facebook?

Este sitio web creado por Mark Zuckerberg ejerce una atracción notable, uno se sienta enfrente del teclado y ¡paf! vuelca todo eso tan importante se tiene que comunicar a su lista de amigos.

No se trata de menospreciar la masividad de Internet. De permitir que grandes fuentes de conocimiento sean accesible a todos. Por supuesto que no. De hecho estimo, mal que le pese a cierta clase sacerdotal del academicismo, que sitios como Wikipedia proporcionan una fuente de información de gran valor para el lego publicada bajo un sistema participativo⁵ y una licencia realmente democrática⁶.

Tampoco la cuestión está por analizar si el ser humano era en el pasado mejor moral y espiritualmente que el de la actualidad.

De lo contrario, se caen en las posturas reduccionistas de quienes esgrimen “que todo tiempo pasado fue mejor” , (y por ende no hay nada mejor y noble que la carta en papel) y entre aquellos que aceptan sin ningún sentido crítico todas las “herramientas” nuevas, no sea que los tilden de obscurantistas.

El problema tal vez sea que si uno se adapta a la herramienta como lo hace un líquido a su recipiente, pasa a ser un objeto utilizado por aquella, lo cual debería ser al revés.

Reducir el tiempo de retardo en la comunicación es en muchos escenarios beneficioso. Por ejemplo, se puede transferir un archivo de un punto al otro del planeta, con un tiempo de espera ínfimo. En muchos casos, la gran caída del factor de retardo puede salvar una vida.

Yendo a casos menos extremos, herramientas como Facebook permiten anunciar eventos culturales, sociales, noticias que los medios tradicionales ocultan o deforman etc. con cero costo e inmediata llegada. ¿Quién se podría oponer a eso? Solamente aquellos que consideren que o bien todo tiempo fue mejor o desestimen el uso de las nuevas maneras en que se muestra la tecnología o quienes tengan interés en conservar algún tipo de poder.

Pero Facebook asimismo (o cualquier red social de internet), elimina durante un debate el contacto cara a cara, poder ver los ojos y escuchar la voz y el tono del otro. Es así que muchas veces se le confiere más importancia al mensaje que al receptor del mismo. Me pregunto una vez más si eso ayuda a mejorar el desarrollo de una polémica por interesante que fuere.

No obstante, no olvidamos la discusión medular aquí (aunque el punto anterior es de gran importancia), por lo tanto los interrogantes cardinales son:

Cuando se quiere comunicar algo que tiene cierta profundidad: ¿Es beneficioso prescindir del factor de retardo?
¿Es el factor de retardo un estorbo que la tecnología viene a eliminar mejorando el intercambio de opiniones? O bien, ¿Internet ha influido tan directa y provechosamente en nuestra capacidad intelectual – es decir las nuevas tecnologías no han salpicado de virtudes intelectuales que nuestros antepasados no tenían – que no vale la pena detenerse a evaluar lo que se quiere comunicar?
¿Merece el mismo tiempo de respuesta, el comentario sobre un chiste, sobre la foto sacada con un amigo de la escuela primaria, hacer catarsis sobre alguna cuestión emocional, que la discusión de algún tema político, científico, teológico o filosófico?

La respuesta a tales preguntas tal vez nos ayude a determinar cuál es el real valor de Facebook y otras redes sociales similares.

1Linux Magazine Nº 125, pág. 87

2 Jon “Maddog” Hall es miembro del directorio de varias empresas y organizaciones de tecnología.

3 Linux International es una organización sin fines de lucro promueve el software libre.

4Twitter agrega un elemento en la comunicación: se trata de la cantidad máxima de caracteres permitidos en cada mensaje. La brevedad puede ser una gran virtud. Pero ¿puede cualquier reflexión reducirse a 140 caracteres?

5Puede leerse más al respecto aquí: http://es.wikipedia.org/wiki/Wikipedia:Consenso

6 http://creativecommons.org/licenses/by-sa/3.0/deed.es

Probando Fedora 15 beta

sebelk — Sun, 24 Apr 2011 16:03:01 GMT

Salió Fedora 15 beta, tiene un núcleo 2.6.38.2-9, mucho más actualizado que su predecesora (que usa una versión de la línea 2.6.35). Esto que implica por ejemplo que el módulo ath9k_htc soporta la placa wireless TP-Link WN821N v3, la cual es económica y soporta la norma 802.11n.

Interesante para ir probando varias cosas, por ejemplo GNOME Shell y Gnome 3

Y también se puede ver algo en este pequeño video:

Escritorio de Fedora 15 Beta

¿Todavía usando Windows? Bueno…. existe VLC, programa libre para ver videos…

Tuve que soportar algún que otro cuelgue en esta versión beta de Fedora, lo cual no es tan alarmante teniendo en cuanto que no está pensada todavía para producción. ¿Quedó claro que es beta?

Guía express Tor+Privoxy

sebelk — Mon, 25 May 2009 10:49:20 GMT

Obviedad: instalar Tor y Privoxy.
Editar el archivo /etc/privoxy/config y sacar el comentario de la línea
```
forward-socks4a   /               127.0.0.1:9050 .
```
Reiniciar el servicio privoxy.
Configurar el navegador para que use la dirección del proxy, es decir 127.0.0.1, puerto 8118.
Comprobar en https://check.torproject.org/?lang=es.
Más información en el sitio de Tor y Privoxy respectivamente.

Acerca del poder de root y permisos de usuarios y grupos II

sebelk — Mon, 18 Aug 2008 20:12:52 GMT

Una manera no tan conocida (tal vez por su relativa inmadurez) son las POSIX CAPABILITIES en Linux. Las PCaps permiten asignar determinados permisos a procesos y archivos ejecutables. La idea es evitar el uso del poderoso pero a la vez peligroso SUID Bit.

El archivo /usr/include/linux/capability.h contiene la descripción definición de las 31 PCaps. Para poder usarlas:

Verificar que esta soportado por el kernel

Habilitar KPROBES y compilar si es necesario

Compilar e instalar las nuevas libreras PCAPS

Se trata de la version 2.x de estas libreras que in

cluyen las herramientas setcap y getcap.

Compilar e instalar capable_probe

Cargar el modulo capable_probe

Este módulo es muy importante para comenzar a usar las PCaps e ir aprendiendo como funcionan. De esta manera, podremos ver los mensajes relativas a las PCaps en el archivo /var/log/messages. Hay que tener en cuenta que dicho archivo crecer notablemente, por lo que se recomienda no tener cargado todo el tiempo el módulo capable_probe.

Una de las primeras cosas que se pueden hacer es probar alguna aplicación y ver que capabilities esta usado. Por ejemplo, vemos que el comando at requiere la facultad para realizar diversas tareas administrativas, pasar por el alto el control de acceso discrecional, cambiar propietarios de archivos, manipulación de SUID y SGID bits.

Espero pronto poder escribir algunas cosas ms sobre este apasionante tema.