Iptables para redirigir la búsqueda de DNS IP y puerto

21

He descubierto que mi ISP (verizon) está interceptando todo el tráfico de DNS en el puerto 53.

Con iptables, quiero redirigir todo el tráfico de búsqueda de DNS a una IP y puerto específicos (5353). Cualquier intento de que mi computadora se conecte a otra computadora en el puerto 53 debe redirigirse a 23.226.230.72:5353.

Para verificar el servidor DNS y el puerto que estoy tratando de usar, ejecuté este comando.

~$ dig +short serverfault.com @23.226.230.72 -p5353
198.252.206.16

Esta es la regla de iptables que estoy tratando de usar.

iptables -t nat -A OUTPUT -p udp -m udp --dport 53 -j DNAT --to-destination 23.226.230.72:5353

Después de agregar esa regla, no se encuentran todas las búsquedas de DNS. Los pings del sitio web regresan unknown host. Las páginas web dicen 'Servidor no encontrado'.

~$ mtr serverfault.com
Failed to resolve host: Name or service not known

Quiero que mi DNS busque en 23.226.230.72:5353. ¿Cómo puedo hacer que la regla de iptables funcione?

EDITAR

Demostración de la intercepción de DNS (puerto 53) por parte de mi ISP. Rastree la salida desde la excavación hasta 23.226.230.72 a través del puerto 5353 y luego el puerto 53.

~$ dig +trace stackexchange.com @23.226.230.72 -p5353

; <<>> DiG 9.9.5-3-Ubuntu <<>> +trace stackexchange.com @23.226.230.72 -p5353
;; global options: +cmd
.           86395   IN  NS  ns7.opennic.glue.
.           86395   IN  NS  ns4.opennic.glue.
.           86395   IN  NS  ns3.opennic.glue.
.           86395   IN  NS  ns5.opennic.glue.
.           86395   IN  NS  ns2.opennic.glue.
.           86395   IN  NS  ns10.opennic.glue.
.           86395   IN  NS  ns1.opennic.glue.
.           86395   IN  NS  ns6.opennic.glue.
.           86395   IN  NS  ns8.opennic.glue.
dig: couldn't get address for 'ns8.opennic.glue': no more


~$ dig +trace stackexchange.com @23.226.230.72 -p53

; <<>> DiG 9.9.5-3-Ubuntu <<>> +trace stackexchange.com @23.226.230.72 -p53
;; global options: +cmd
.           7440    IN  NS  f.root-servers.net.
.           7440    IN  NS  d.root-servers.net.
.           7440    IN  NS  j.root-servers.net.
.           7440    IN  NS  i.root-servers.net.
.           7440    IN  NS  g.root-servers.net.
.           7440    IN  NS  k.root-servers.net.
.           7440    IN  NS  a.root-servers.net.
.           7440    IN  NS  h.root-servers.net.
.           7440    IN  NS  e.root-servers.net.
.           7440    IN  NS  m.root-servers.net.
.           7440    IN  NS  c.root-servers.net.
.           7440    IN  NS  b.root-servers.net.
.           7440    IN  NS  l.root-servers.net.
;; Received 239 bytes from 23.226.230.72#53(23.226.230.72) in 2948 ms

stackexchange.com.  215 IN  A   198.252.206.16
;; Received 62 bytes from 192.228.79.201#53(b.root-servers.net) in 116 ms

Mis iptables actuales. iptables-save

~# iptables-save
# Generated by iptables-save v1.4.21 on Tue Jul 15 23:06:52 2014
*mangle
:PREROUTING ACCEPT [79950528:41742899703]
:INPUT ACCEPT [78748282:41360159554]
:FORWARD ACCEPT [13:5427]
:OUTPUT ACCEPT [85455483:57472640071]
:POSTROUTING ACCEPT [85480442:57475512901]
-A POSTROUTING -o lxcbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
COMMIT
# Completed on Tue Jul 15 23:06:52 2014
# Generated by iptables-save v1.4.21 on Tue Jul 15 23:06:52 2014
*nat
:PREROUTING ACCEPT [71:18713]
:INPUT ACCEPT [7:474]
:OUTPUT ACCEPT [109:7855]
:POSTROUTING ACCEPT [109:7855]
:DOCKER - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.17.0.0/16 ! -d 172.17.0.0/16 -j MASQUERADE
-A POSTROUTING -s 10.0.3.0/24 ! -d 10.0.3.0/24 -j MASQUERADE
COMMIT
# Completed on Tue Jul 15 23:06:52 2014
# Generated by iptables-save v1.4.21 on Tue Jul 15 23:06:52 2014
*filter
:INPUT ACCEPT [78748139:41360144354]
:FORWARD ACCEPT [13:5427]
:OUTPUT ACCEPT [85454926:57472600172]
:fail2ban-ssh - [0:0]
:fail2ban-vsftpd - [0:0]
-A INPUT -p tcp -m multiport --dports 21,20,990,989 -j fail2ban-vsftpd
-A INPUT -p tcp -m multiport --dports 22,6622 -j fail2ban-ssh
-A INPUT -i lxcbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i lxcbr0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i lxcbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A INPUT -i lxcbr0 -p udp -m udp --dport 67 -j ACCEPT
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A FORWARD -o lxcbr0 -j ACCEPT
-A FORWARD -i lxcbr0 -j ACCEPT
-A fail2ban-ssh -j RETURN
-A fail2ban-vsftpd -j RETURN
COMMIT
iptables  dns 
— Rucent88
fuente
Entonces, ¿está intentando redirigir todo el tráfico del puerto 53 a esa IP (23.226.230.72) y ese Puerto (5353)?
— tachomi
por favor publique su iptables rulesaquí
— Networker
@tachomi Correcto
— Rucent88
O no podría usar el DNS de su ISP ... Los servidores DNS públicos de Google son 8.8.8.8y8.8.4.4
— Creek
@Creek Creo que lo malinterpretas. Mi ISP está interceptando todo el tráfico a través del puerto 53. Incluso si quisiera usar servidores dns de google, no puedo acceder a ellos.
— Rucent88

Respuestas:

12

Realice todas estas instrucciones como root (sudo).

Edita este archivo.

/etc/NetworkManager/NetworkManager.conf

Deshabilite DnsMasq comentando la línea dns=dnsmasq. Pon un #delante de la línea

#dns=dnsmasq

Reinicie su red.

service network-manager restart

Agregue estas reglas de iptable.

iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to 23.226.230.72:5353
iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to 23.226.230.72:5353
— Rucent88
fuente
2
Esta solución se actualiza con el sistema operativo y consume cero recursos, y es un riesgo de seguridad cero, una configuración súper fácil con un script de arranque y cero mantenimiento. La desventaja es que no es muy flexible
— Rucent88
3

Parece que lo que realmente buscas es tener el control de lo que sucede con tus consultas DNS.

No estoy seguro de que usar iptables sea mi solución preferida.

¿Ha pensado en configurar un servidor DNS local que simplemente envíe sus solicitudes al host y al puerto que desee? Un ejemplo: utilizando la opción de reenviadores bind9, puede agregar un puerto a un reenviador.

Tal configuración es mucho más fácil de mantener y solucionar problemas, y puede ser mucho más flexible. Considere la ventaja del almacenamiento en caché, o simplemente considere el caso en que su servidor DNS externo está inactivo. Puede tener múltiples reenviadores en su configuración de DNS, pero solo una IP en las reglas de iptables ....

Hay una buena descripción general de la configuración de bind9 en un tutorial en digital ocean . Simplemente agregue el puerto a los reenviadores y ya debería estar listo.

Bind9 no consume muchos recursos y se configura fácilmente (o al menos: más fácil que iptables :-))

— Vincent De Baere
fuente
Ooh, y no hace falta decir que, en esa configuración, no olvide configurar su (s) dispositivo (s) para usar su servidor DNS de reenvío local.
— Vincent De Baere
Tenía un servidor DNS ejecutándose, pero no era confiable (hardware basura). Mantener la seguridad actualizada fue un dolor. Consumió más tiempo, recursos, electricidad, y finalmente pateó el cubo. Si tuviera cientos de computadoras detrás de una red corporativa, entonces estoy de acuerdo en que el servidor DNS sería una buena idea. Pero solo soy una persona con una computadora portátil. Un par de reglas iptable deberían ser el recurso más fácil y más bajo.
— Rucent88
Simplemente agregue uno en su computadora portátil, casi no consume recursos y se actualizará con su sistema operativo principal (suponiendo que use paquetes de distribución) y haga que escuche en localhost. Casi cero riesgo de seguridad.
— Vincent De Baere
De hecho, en mi humilde opinión, es la mejor manera de mantener el escenario en el 99% de los casos. El único 1% que no se aplica es cuando configura un sistema de Portal cautivo, pero esa es otra historia.
— ivanleoncz
2

Prueba esto:

Primero debe habilitar la opción de reenvío en

/etc/sysctl.conf

Establecer en uno el valor de 

net.ipv4.ip_forward = 1

Habilita los cambios

sysctl -p

Guarde y ejecute lo siguiente:

iptables -t nat -A PREROUTING -p tcp --sport 53 -j DNAT --to-destination 23.226.230.72:5353
iptables -t nat -A POSTROUTING -j MASQUERADE

Si pudiera especificar la interfaz interna (-i eth1) en PREROUTING o / y out-interfect (-o eth0) IN POSTROUTING podría ser útil.

NOTA: la línea MASQUARADE es necesaria mientras que esto enmascara la IP de destino con la IP principal.

— tachomi
fuente
Puse en sysctl net.ipv4.ip_forward=1y las reglas de iptables. DNS funciona, pero mi ISP aún lo está interceptando. Eso me indica que el DNS todavía se está enviando a través del puerto 53.
— Rucent88
Cambié tu regla a udp, pero obtuve los mismos resultados.
— Rucent88
¿Podría por favor poner la salida de iptables-save? Lo que podría ser es que solo enmascara la MASQUERADE especificada: 10.0.3.0/24, por lo que si puede deshabilitar esa línea y dejar la -A POSTROUTING -j MASQUERADE one, podría ser útil
— tachomi
— Agregué
Ok, comprendamos un poco ... ¿Todo el tráfico del puerto 53 ENTRANTE es el que desea redirigir a 23.226.230.72 o el SALIENTE?
— tachomi
1

Prueba esto:

iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to 23.226.230.72:5353;

iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to 23.226.230.72:5353;

iptables -t nat -A POSTROUTING -j MASQUERADE

Significa:
1) Cualquier usuario local que contacte al mundo con el puerto tcp 53 envíe al 23.226.230.72 en el puerto 5353.
2) Igual que 1 pero para udp
3) Configure la información de origen en el paquete saliente que proviene de nosotros.

— George Hidalgo
fuente
0 
iptables -t nat -A PREROUTING -p tcp --dport 53 -j DNAT --to XX.XX.XX.XX:5353
iptables -t nat -A PREROUTING -p udp  --dport 53 -j DNAT --to XX.XX.XX.XX:5353
iptables -t nat -A POSTROUTING -j MASQUERADE
— Zibri
fuente
El hecho de que esta respuesta no mencione "5353" me hace creer que está automáticamente equivocado.
— G-Man dice 'Reincorporar a Monica' el
corregido .........
— Zibri
OK, estoy revisando tu respuesta. Parece ser muy similar a la respuesta de tachomi, excepto (1) que ha cambiado sporta  dport(aparentemente, esto fue un error en la respuesta de tachomi que Battman622 señaló hace tres años , (2) agregó una línea (comando) para udp(esto es una mejora legítima a la respuesta de tachomi, pero una que ya se mencionó en un comentario  ... (Cont.)
— G-Man dice 'Restablecer a Monica' el
(Continuación) ... y varias otras respuestas), y (3) se ha sustituido --to-destinationcon  --to.  La página del manual no dice eso --toy  --to-destinationson equivalentes; por el contrario, dice que --tose usa con el NETMAPobjetivo (en oposición al  DNATobjetivo) y que su argumento no incluye un número de puerto. (Aunque me doy cuenta de que algunas otras respuestas usan --tola forma en que lo hizo). ¿Está seguro de que --tofunciona de la manera en que lo usa (con un número de puerto, con el  DNATobjetivo)? ... (Continúa)
— G-Man dice 'Restablecer a Mónica' el
(Continúa) ... (Si es así, tal vez alguien debería enviar una solicitud de cambio al mantenedor (es) de las páginas del manual). ¿Es  --tomejor que   --to-destinationcualquier otra cosa que no sea breve?
— G-Man dice 'Restablecer a Mónica' el
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.