Bloquear el tráfico RPCBIND

Publicado 05-04-2016

Esta semana recibíamos un aviso de “German Federal Office for Information Security (BSI)” acerca de unas máquinas que tenemos en un centro de datos en Alemania. En dicho aviso se nos alertaba acerca de un puerto, el 111, que estaba abierto a Internet y que podría ser objeto de utilización maliciosa para ataques DDoS, es decir, denegación de servicios distribuida.

A continuación un extracto de dicho aviso:

The Portmapper service (portmap, rpcbind) is required for mapping RPC requests (remote procedure calls) to a network service. The Portmapper service is needed e.g. for mounting network shares using the Network File System (NFS). The Portmapper service runs on port 111 tcp/udp [1].

In addition to being abused for DDoS reflection/amplification attacks, the Portmapper service can be used by attackers to obtain information on the target network like available RPC services or network shares.

In the past months, systems responding to Portmapper requests from the Internet have been increasingly abused for participating in DDoS reflection/amplification attacks [2].

The Shadowserver 'Open Portmapper Scanning Project' identifies systems responding to Portmapper requests from the Internet which can be abused for DDoS reflection/amplification attacks if no countermeasures have been implemented.

Sólo una máquina de un cliente estaba afectada, y por suerte disponemos de un firewall previo a dicha máquina. Desconocemos exactamente a qué vulnerabilidad se refieren, parece ser una que aprovecha este servicio para reenviar tráfico, y tras un examen de dicha máquina concluimos que su seguridad no había sida comprometida, pero en estos casos siempre es mejor curarse en salud y tras hablar con el cliente comprobamos que efectivamente no estaba utilizando para nada el servicio portmap, rpcbind o NFS.

Tras dichas comprobaciones sólo quedaba cerrar el puerto en nuestro firewall, que no es otra cosa que un sistema GNU/Linux con el famoso software Shorewall, un magnífico firewall que se configura con unos sencillos ficheros y que no nos cansaremos de recomendar.

La regla que añadimos es muy sencilla:

SECTION ALL
# Deny all the RPC traffic
DROP all all tcp,udp sunrpc,nfs

Esta regla lo que hace es descartar, DROP, cualquier tráfico desde y hacia cualquier parte por los puertos sunrpc y NFS, si queremos saber cuales son:

#> cat /etc/services | egrep "sunrpc|nfs"
sunrpc		111/tcp		portmapper	# RPC 4.0 portmapper
sunrpc		111/udp		portmapper
nfs		2049/tcp			# Network File System
nfs		2049/udp			# Network File System

Por supuesto hay que reiniciar de forma controlada el firewall:

#> shorewall safe-restart
Do you want to accept the new firewall configuration? [y/n] y
New configuration has been accepted

Y ya estamos a buenas con el BSI.

Ni qué decir tiene que podríamos hilar mucho más fino, pero si en alguna máquina necesitamos esos puertos, lo que no es común, podremos aceptarlos con otra regla de firewall.

Fallece Ian Murdock, el fundador de Debian

Publicado 02-01-2016

Nos hacemos eco de esta lamentable noticia. Hay muy poca información sobre el suceso y esperamos que se vaya ampliando estos días, pero al parecer falleció durante la noche del día 28 de diciembre de este año 2015.

Todo indica que se ha tratado de un suicidio pero su cuenta de Twitter, ahora borrada, apunta algunas extrañas circustancias que ójala se aclaren muy pronto.

Nosotros tuvimos oportunidad de conocerlo en Madrid, hace ya muchos años, y era una buena persona además de un tipo tranquilo y simpático.

Ian fundó Debian la distro más famosa de GNU/Linux y una de las más utilizadas en servidores de todo tipo. Muchas otras distros derivan de ella, como Ubuntu.

Toda la comunidad del software libre está de luto por este terrible suceso, muchos no seríamos quienes somos si no fuera por él.

Sólo esperamos que su familia y amigos sientan todo el apoyo de la comunidad y constaten cuan importante y querido era.

Hasta siempre Ian, has dejado huella y te echaremos de menos.

Relacionado:

Por ahora, sábado 2 de Enero de 2016, no han sido aclaradas las circustancias de su muerte. Dados los tuiteos que emitió y entendiendo el dolor de la familia, consideramos que sería positivo que se arrojase un poco de luz sobre los hechos.

Entendiendo conceptos de Javascript: Closures, Duck Typing, Prototypes y References

Publicado 09-10-2015

Últimamente, cuando tengo que hacer cosas con Javascript he utilizado Coffeescript, para que fuera un poco más a la Ruby y tener menos dolores de cabeza. Por otro lado siempre he sentido que cuando hago cosas en Javascript estoy haciendo pequeñas chapuzas que funcionan pero que no me acaban de gustar. En realidad puedo decir que aprendí jQuery, pero no mucho más.

Buena praxis

No es que sea una sensación infundada, porque Javascript se presta mucho a la chapuza y es complicado saber cual es la buena praxis en este lenguaje, básicamente, y por mucho que alguno me lo va a discutir o por mucho que te cuenten, en la práctica no existe.

Pros

Esto tiene sus pros y sus contras, centrémonos en los pros, el lenguaje es tan maleable que permite hace cosas bastante potentes y curiosas, que quizá requerirían de mucho más código en otros lenguajes. Además, para ser interpretado, es bastante rápido, sobre todo con los nuevos motores, y si tenemos más o menos claro que es lo que carga y lo que no (y pocos escrúpulos) podemos conseguir una buena velocidad.

Mi problema

Mi problema fundamentalmente es que no quería leerme veinte libros sectarios sobre patrones y opiniones peregrinas de buena praxis, a mi modo de ver eso será interesante en un ámbito académico. En el mundo real necesitamos hacer las cosas bien pero sin perder productividad, y leer un porrón de libros, seleccionar la religión que más nos guste, es un tiro en toda la línea de flotación del barco de la productividad para aprender un lenguaje que, lo que es la intuición del programador con experiencia previa, se la pasó por la quilla antes de salir al mercado.