GNU/Linux >> Tutoriales Linux >  >> Linux

Hacer que rpcbind (anteriormente portmap, puerto 111) sea más seguro

Introducción:

A menudo uso el sistema de archivos NFS entre servidores de la misma red interna. Pero debido a que tener rpcbind abierto a Internet se considera inseguro, necesitaba protegerlo. Podría haberlo hecho con el cortafuegos, pero como era el único servicio que quería proteger del acceso a Internet, no quería molestarme con el cortafuegos para esta tarea y decidí usar el viejo sistema TCP Wrappers en su lugar: hosts.permitir y hosts.deny archivos.

Método:

– Denegar el acceso a rpcbind a todos (hecho en /etc/hosts.deny )
– Permitir 2 excepciones:hosts en mi red local (hecho en /etc/hosts.allow )

Supuestos:

El servidor NFS está conectado a Internet y a nuestra LAN interna (192.168.100.0/24) y tiene la IP:12.34.56.78 (solo un ejemplo) y 192.168.100.1.
Los 2 hosts que quiero permitir conectarse al servidor NFS son 192.168.100.2 y 192.168.100.3
Tengo un servidor más (192.168.100.4) en esta LAN privada que no debería poder conectarse al servidor NFS.

Pasos:

Edite (o cree si no existe) el archivo /etc/default/rpcbind y agrega la siguiente línea:
OPTIONS="-w -l -h 192.168.100.1"
Edite el archivo /etc/hosts.allow y agregue la siguiente línea:
rpcbind: 192.168.100.2 192.168.100.3
Edite el archivo /etc/hosts.deny y agregue la siguiente línea:
rpcbind: ALL

Verificando la configuración:

Inicie sesión en cualquier otro servidor en la misma red LAN local (ninguno de los servidores permitidos arriba) digamos desde 192.168.100.4 y emita el siguiente comando:
rpcinfo -p 192.168.100.1
Salida:
rpcinfo: can't contact portmapper: rpcinfo: RPC: Authentication error; why = Client credential too weak
Luego inicie sesión en cualquier servidor de Internet (por ejemplo, a 45.67.78.89) y pruebe el comando:
rpcinfo -p 12.34.56.78
Salida:
rpcinfo: can't contact portmapper: RPC: Remote system error - Connection refused
Ahora inicie sesión en uno de los 2 servidores permitidos (por ejemplo, 192.168.100.3) y emita el comando:
rpcinfo -p 192.168.100.1
Salida:
rpcinfo -p 192.168.100.1
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 49123 status
100024 1 tcp 55198 status
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
....... and so on

Good news: Podemos ver que 192.168.100.4 y cualquier servidor de Internet no pueden conectarse a rpcbind pero 192.168.100.3 sí.

Información adicional:

Solo por diversión, revisemos los registros:
grep rpcbind /var/log/auth.log
Salida:
Oct 7 20:51:30 nfsserver rpcbind: connect from 192.168.100.4 to dump(): request from unauthorized host
Oct 7 20:51:56 nfsserver rpcbind: connect from 45.67.78.89 to dump(): request from unauthorized host
Oct 7 20:53:24 nfsserver rpcbind: connect from 192.168.100.3 to dump()

Ahora vamos a comprobar la configuración de TCP Wrappers para el host 192.168.100.2
tcpdmatch rpcbind 192.168.100.2
Salida:
client: address 192.168.100.2
server: process rpcbind
access: granted

Resultado:
bindrpc El servicio ahora está protegido y solo se puede acceder a él desde los 2 servidores conectados a nuestra LAN interna.


Linux
  1. Descubra hosts en vivo en una red bajo Linux

  2. Cómo asegurar el servicio SSH con Port Knocking

  3. Conexión rechazada a MongoDB errno 111

  4. ¿Qubes OS es más seguro que ejecutar un conjunto de máquinas virtuales relacionadas con la actividad?

  5. Gran cantidad de conexiones TIME_WAIT dice netstat

Haciendo que Vim sea aún más impresionante con estas características geniales

Asegure su red Linux con firewall-cmd

¿Resolver la dirección Mac desde la dirección IP en Linux?

5 prácticas recomendadas de seguridad SSH de Linux para proteger sus sistemas

Resolución de la dirección MAC desde la dirección IP en Linux

¿Puede TCP proporcionar más de 65535 puertos?