Tabla de contenido:

Cortafuegos de puente con OrangePi R1: 4 pasos
Cortafuegos de puente con OrangePi R1: 4 pasos

Video: Cortafuegos de puente con OrangePi R1: 4 pasos

Video: Cortafuegos de puente con OrangePi R1: 4 pasos
Video: Orange Pi, 7 Configuraciones importantes en Armbian; Personaliza, configura y automatiza 2024, Mes de julio
Anonim
Cortafuegos de puente con OrangePi R1
Cortafuegos de puente con OrangePi R1

Tuve que comprar otro Orange Pi:) Esto se debió a que mi teléfono SIP comenzó a sonar en medio de la noche por números extraños y mi proveedor de VoIP sugirió que se debía a escaneos de puertos. Otra razón: había oído hablar con demasiada frecuencia sobre la piratería de enrutadores y tengo un enrutador que no puedo administrar (Altibox / Noruega). También tenía curiosidad por saber qué estaba pasando en mi red doméstica. Así que decidí instalar un cortafuegos en puente, transparente a la red doméstica TCP / IP. Lo probé con una PC, luego decidí comprar OPi R1: menos ruido y menos consumo de energía. Si tiene su propia razón para tener un firewall de hardware de este tipo, ¡es más fácil de lo que cree! No olvide comprar un disipador de calor y una tarjeta micro SD decente.

Paso 1: SO y cableado

SO y cableado
SO y cableado

Instalé Armbian:

Como tal vez haya notado, utilicé un convertidor TTL USB para tener acceso a la consola en serie, lo cual no era necesario, la configuración de red predeterminada asume DHCP.

El único comentario para el convertidor: en muchos tutoriales no se sugiere ninguna conexión VCC. Para mí, funcionó solo cuando la fuente de alimentación estaba conectada (3.3V es el único pin cuadrado en la placa). E iba a sobrecalentarse si no se conectaba al USB antes de encender la fuente de alimentación. Supongo que R1 tiene pinout compatible con OPi Zero, tengo problemas para encontrar los esquemas de R1.

Después de iniciar Armbian, cambiar la contraseña de root y algunas cosas de actualización / actualización, encontré dos interfaces ('ifconfig -a'): eth0 y enxc0742bfffc6e. Compruébelo porque los necesitará ahora; lo más asombroso es que para convertir su R1 en un puente Ethernet solo necesita ajustar el archivo / etc / network / interfaces. Me sorprendió que Armbian venga con algunas versiones preconfiguradas del archivo, incluidas interfaces.r1switch; parece lo que necesitamos, pero no funciona.

Otra cosa importante fue la identificación adecuada de los puertos Ethernet: enxc0742bfffc6e era el que estaba cerca de los pines seriales.

Antes de hacer que el R1 pierda contacto con Internet (está bien, esto podría haberse configurado mejor) solo instale una cosa:

sudo apt-get install iptables-persistent

Paso 2: / etc / network / interfaces

Si cambia su red local a eth0, entonces necesita el siguiente archivo de interfaces (siempre puede volver a la versión original con sudo cp interfaces.default interfaces; reiniciar):

auto br0iface br0 inet manual

bridge_ports eth0 enxc0742bfffc6e

bridge_stp apagado

bridge_fd 0

bridge_maxwait 0

bridge_maxage 0

Paso 3: Iptables

Iptables
Iptables

Después de reiniciar, su R1 debe ser transparente para la red y funcionar como un conector de cable. Ahora, hagamos la vida más difícil para los malos: configure las reglas del firewall (las líneas hash son comentarios; ¡ajuste las direcciones de red a su configuración de DHCP!):

# flashear todo y cerrar puertas

iptables -Fiptables -P INPUT DROP

iptables -P DROP ADELANTE

iptables -P CAIDA DE SALIDA

# pero permite que la red interna salga al exterior

iptables -A INPUT -m physdev --physdev-is-bridged --physdev-in eth0 -s 192.168.10.0/24 -j ACEPTAR

iptables -A FORWARD -m physdev --physdev-is-bridged --physdev-in eth0 -s 192.168.10.0/24 -j ACEPTAR

# permitir que DHCP pase a través del puente

iptables -A ENTRADA -i br0 -p udp --dport 67:68 --sport 67:68 -j ACEPTAR

iptables -A FORWARD -i br0 -p udp --dport 67:68 --sport 67:68 -j ACEPTAR

# todo el tráfico establecido debe reenviarse

iptables -A FORWARD -m conntrack --ctstate ESTABLECIDO, RELACIONADO -j ACEPTAR

# solo para el navegador local: acceso a herramientas de monitoreo como darkstat

iptables -A ENTRADA -i lo -j ACEPTAR iptables -A SALIDA -o lo -j ACEPTAR

#block spoofing

iptables -A FORWARD -m physdev --physdev-is-bridged --physdev-in enxc0742bfffc6e -s 192.168.10.0/24 -m limit --limit 5 / min -j LOG --log-level 7 --log-prefix NETFILTER

iptables -A FORWARD -m physdev --physdev-is-bridged --physdev-in enxc0742bfffc6e -s 192.168.10.0/24 -j REJECT

Paso 4: Consideraciones finales

Después de una semana, funciona perfectamente. Lo único que inventaré (y enviaré aquí) es el monitoreo de la red y el acceso a través de ssh. Repito: cambiar el archivo de interfaces al contenido que he adjuntado desconectará el dispositivo R1 de la red IP; solo funcionará el serial.

6 de junio de 2018: el puenteo no es mucho trabajo, pero el R1 emite mucho calor, demasiado. Un simple disipador de calor se calienta mucho, extraño y no me gusta. Tal vez esté bien, tal vez alguien tenga una solución que no sea un fan.

18 de agosto de 2018: 'armbianmonitor -m' muestra 38 grados Celsius, muy por debajo de mi percepción personal. Sentí un cambio significativo (hacia abajo) cuando reduje un poco el reloj:

echo 1000000> / sys / dispositivos / system / cpu / cpu0 / cpufreq / scaling_max_freq

Por cierto, he logrado conectarme a la WLAN de mi hogar, pero el R1 no ha recibido ninguna IP a través de DHCP, la asignación estática tampoco funciona. Ese fue mi primer intento de tener una interfaz administrativa, que no sea de serie. Otra idea es tener una IP asignada a uno de los puertos ethernet. Volveré a esto en unos meses.

Recomendado: