Información blog

Linux, tutoriales, noticias, sistemas, redes y seguridad informática, entre otras cosas.

miércoles, 30 de septiembre de 2015

Rootkits: Qué son y cómo defendernos en Linux

Alguna vez en vuestra vida habréis oído hablar de la palabra rootkit; palabra que siempre ha sido relacionada con un archivo peligroso insertado por un criminal.. ¿Pero qué son exactamente? ¿Qué daño nos pueden llegar a hacer? Un rootkit no es ni más ni menos que un programa que sustituye a un fichero original, con la diferencia de que este sustituto posee ciertos añadidos para realizar tareas delictivas o para otorgarnos privilegios de root (de ahí proviene el nombre rootkit). Obviamente se ha tenido que tener acceso al equipo antes para insertar este elemento, ya sea aprovechando una vulnerabilidad o por una mala gestión de la seguridad...

Estos archivos suelen suplantar archivos de gran importancia, y pueden ser desde archivos de librería hasta binarios de enorme relevancia, tales como sudo, su o login; con lo que se podría decir que su detección no es precisamente sencilla a menos que se recurran a herramientas especializadas o a métodos especialmente creados para determinar la integridad de un fichero.

rootkit_portada

Uno de los métodos más simples para comprobar si la integridad de un fichero ha sido comprometida, es la comprobación de la suma md5, de nuestros ficheros... Esta suma es única y no puede variar a menos que se haya modificado el fichero, cosa que no debería ocurrir; para comprobar dicha suma se utiliza el comando md5sum sobre el fichero o ficheros a analizar, como por ejemplo el binario su.

md5sum /bin/su

De dicho comando obtendríamos una larga lista de caracteres alfanuméricos que siempre deben de ser los mismos a menos que el fichero haya sido modificado. Por ejemplo basándonos en el comando anterior obtendríamos:

md5sum

El valor obtenido (hemos de suponer que el valor es autentico) podría ser usado para guardarlo dentro de una lista o base de datos tras lo cual podríamos comparar el valor almacenado en dicho lugar con el último valor obtenido con el comando md5sum. Algo como:

Con un listado

Para añadir una suma md5 a una lista:

md5sum /bin/su  > /usr/src/listado.txt

Para comprobar si la suma md5 actual es la misma que la que había antaño:

cat /usr/src/listado.txt |grep "$(md5sum /bin/su)"

Con sqlite

Si queremos recurrir a algo más "sofisticado" como el uso de bases de datos, podemos usar una base de datos sqlite (o la que más nos guste). Para ello obviamente deberíamos tener instalado el software en cuestión; en este caso sqlite, el cual se puede instalar desde los repositorios del sistema:

apt-get install sqlite

Comenzaríamos creando la base de datos y la tabla correspondiente:

  1. sqlite db_md5
  2. create table tablamd5(suma varchar(70));

Con la base de datos creada, la inserción de valores se realizaría de la siguiente forma:

sqlite db_md5 "insert into tablamd5(suma) values('$(md5sum /bin/su)');"

Mientras que la consulta sería:

sqlite db_md5 "SELECT '$(md5sum /bin/su)' FROM tablamd5;"


Chkrootkit

El problema de ambos métodos es que son muy laboriosos, requieren añadir valores cada vez que se instala un software importante y además corremos el riesgo de olvidarnos algún fichero importante que puede ser comprometido... Con lo que aunque conceptualmente se trata de algo interesante, no es una solución eficaz que nos pueda garantizar al 100% la integridad de nuestros ficheros. Por ello lo habitual suele ser recurrir a herramientas especializadas para la detección de rootkits, tales como ClamAV que engloba las funciones de antivirus y antirookit, o recurrir a herramientas diseñadas con el único fin de detectar rootkits... Hay dos de ellas que son especialmente conocidas; llamadas: chkrootkit y rootkithunter. Ambas son excelentes herramientas, pero únicamente me centraré en una de ellas: chkrootkit.

Este tipo de herramientas no suelen ir incorporadas por defecto en el sistema, si bien sí que se encuentran disponibles para ser descargadas desde los repositorios oficiales del sistema, con lo cual, si quisiésemos instalar la herramienta deberíamos escribir:

sudo apt-get install chkrootkit

Al ser una herramienta de gran relevancia que analiza ficheros importantes del sistema, hemos de tener en cuenta que cualquier uso de esta herramienta siempre deberá ser realizado como sudo o como root. Una de las virtudes que tiene esta herramienta es que es muy simple de usar ya que solamente posee dos opciones de escaneo destacables: El escaneo "normal" y el silencioso. El escaneo normal es tan simple como escribir:

sudo chkrootkit

Simple y sencillo, aunque personalmente me parece que muestra demasiada información, ya que muestra absolutamente todo lo analizado, ya esté infectado o no... Como generalmente solo nos interesa que se nos muestren los ficheros que han sido comprometidos, recomiendo acompaña al comando chkrootkit del parámetro -q(quiet) para realizar un escaneo silencioso.

sudo chkrootkit -q

Es recomendable usar más de una herramienta de detección de rootkits; por ejemplo podrían combinarse ClamAV con chkrootkit. Esta recomendación se debe a que en algunas ocasiones, estas herramientas de análisis de rootkits pueden dar falsos positivos, con lo que ante la duda siempre es mejor asegurarse de que efectivamente el fichero en cuestión ha sido manipulado,

Espero que os haya resultado útil.

Saludos.

domingo, 27 de septiembre de 2015

Cómo liberar la memoria ram cacheada en Linux

Hoy vengo a hablaros de uno de los problemas más comunes con los que nos podemos encontrar en Linux; especialmente con servidores, si bien si tenemos un equipo constantemente encendido podemos tener el mismo problema. Se trata de la memoria RAM, la cual aunque hoy en día contamos con equipos con grandes cantidades de memoria instalada, no es ilimitada; y es por ello que tenemos que tener en cuenta una de las características más importantes de ésta; la memoria caché o SRAM.

Cada vez que ejecutamos un proceso, éste consumirá cierta cantidad de memoria RAM en nuestro equipo, pero no sólo eso sino que tardará bastante tiempo en cargarse en caso de ser la primera vez que lo ejecutemos, ya que tiene que cargar todos los recursos y consultar todos los datos necesarios para arrancar... Durante dicho proceso, cierta información es guardada en la caché para que así, en caso de que queramos ejecutar dicho proceso de nuevo, la carga sea mucho más rápida, ya que ya hay mucha información disponible en la memoria caché; traduciéndose en un sistema más optimizado y eficiente. Supuestamente dicha caché está diseñada para borrar parte de la información almacenada en ésta en caso de encontrase llena; pero a veces no realiza dicha función correctamente y nos podemos encontrar con sistemas de 4, 8 e incluso 16 GB en los cuales el 90% de la RAM está en uso y de dicha RAM la mayor parte sea información almacenada en la caché.

cache_linux
Es por ello que en equipos que están siempre conectados (generalmente servidores) podemos llegar a encontrarnos con un consumo desmesurado de RAM; lo cual dependiendo de la situación puede ser bueno, ya que tal vez deseemos que las aplicaciones tengan el mayor rendimiento posible. Pero otras veces nos podemos encontrar con que tenemos una cantidad de RAM libre muy ajustada y tal vez nos veamos en la necesidad de liberarla. Dicha necesidad se suele manifestar especialmente en:
  • Equipos de bajas prestaciones.
  • Servidores.
  • Equipos que tengamos siempre conectados.
La liberación de la caché se puede realizar de dos formas. La primera sería apagando el equipo, que podría considerarse como la opción más "brusca" e inefectiva, ya que no queremos apagar ni reiniciar nada, con lo que lo más recomendable suele ser buscar una alternativa; y he ahí donde entra esta opción; La liberación de la caché desde la consola. Dicha liberación tiene la ventaja de que no solo no requiere reiniciar ni apagar función alguna, sino que además no interfiere en el funcionamiento del sistema y no interviene en ninguna labor que esté realizando el sistema.

Para ello habría que escribir uno de estos tres comandos (sólo uno) como root:

  1. sync && echo 1 > /proc/sys/vm/drop_caches
  2. sync && echo 2 > /proc/sys/vm/drop_caches
  3. sync && echo 3 > /proc/sys/vm/drop_caches

Dependiendo del número escogido la eliminación de la caché sería mayor o menor; exactamente estos números implicarían:
  1. Este número implicaría la liberación de caché más suave, ya que únicamente libera la pagecache; también conocida como caché del disco.
  2. Este número sería un poquito más agresivo ya que eliminaría toda la información de los metadatos (pemisos, datos, etc..) almacenados en la caché. 
  3. Este número borraría ambos, tanto caché del disco como metadatos, de la memoria caché; siendo la opción más usada.
Si bien esta última opción puede parecer muy agresiva, es por lo general la más usada ya que se asegura de librar absolutamente toda la memoria caché. Una buena forma de comprobar que en efecto la caché ha sido liberada sería mediante el comando free, el cual mostraría la información referente a la memoria ram, incluyendo la cantidad de ram "cacheada". Generalmente, aún cuando hemos liberado la caché al completo, es normal encontrar siempre algo de información almacenada en la caché, aunque sea muy poca; si bien dicha cantidad de información es muchísima menor que la que teníamos originalmente.

Espero que os resulte útil.

Saludos.

viernes, 25 de septiembre de 2015

Entendiendo el ssh fingerprint

Más de una vez he hablado de las bondades que ofrece ssh; de sus virtudes y sus ventajas con respecto a su antecesor, telnet. Sí, ssh es considerado como un protocolo seguro, pero no por ello es infalible y siempre hay formas de intentar pillarnos desprevenidos y hacernos cometer errores garrafales.

Es por ello que para evitarnos posibles disgustos, vengo a hablaros de uno de los recursos que todo aquel que se ha conectado por ssh desde la consola o desde putty, ha llegado ver; si bien probablemente lo ha ignorado (ya sea por prisas o desconocimiento). Para poneros en situación; imaginemos que una persona nos ha pedido que le echemos un vistazo a un equipo que tiene en red... Al querer tener el máximo control posible hemos entrado por ssh mediante la herramienta putty... ¿A quien no le ha salido siempre un mensaje como éste?


Normalmente los usuarios suelen hacer lo mismo que con los términos y condiciones... Es decir, pulsar sí y punto, sin fijarse siquiera en lo que la pantalla muestra... En este caso el mensaje no es perjudicial para nosotros; o al menos no lo es en un principio, si bien nos muestra información que no es recomendable pasar por algo, ya que muestra nada más y nada menos que la "huella dactilar" de la clave rsa del servidor al que nos conectamos. Dicha clave es única, con lo que podría decirse que ningún otro equipo en el mundo entero debería tener ésta. Evidentemente dicha huella puede ser consultada en el propio equipo con facilidad... Para ello únicamente sería necesario consultar el archivo ssh_host_rsa_key.pub (ossh_host_ecdsa_key.pub dependiendo del tipo de conexión realizada), alojado en el directorio /etc/ssh/. Si hiciésemos una consulta "plana", del fichero, es decir, si hiciésemos un simple cat sobre el fichero, nos aparecería un galimatías ilegible parecido al mostrado a continuación:

  1. root@debian:/etc/ssh# cat ssh_host_rsa_key.pub
  2. ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC4AWN3rg19Z5r0GFAs20UzdFNCPU+RjEfsB9rNsPw/drxoiPOyE6rEQsvQB9wuSOR8hmBr3ac9u+7nqgyW48tQYUV8zc7tmhOPMSV0G4Xfnp0Auk1gyNGEJNcsAPoDCFRInCoWuhKe/P/rGamaJpsxDb8UeizMUKAHNu9M3srbu/Yz09Pn1J15E/8hT8/MdFcdDnQIbRUJOsFc4uDYQcsalik/1Bnpnxp3/ILTr7q+ZlIij5VFoizfXXL9fzOUgUYAm9aWMu4I8puCcZ9ckWZyMeAly5uo3xcfUTaUCCa8QOq6JxzdTK8tl6Ddi6vDj1c8ZDk01raCcQf/ULbjkfej root@debian

Esta marabunta de caracteres no nos es de utilidad alguna, es por ello que habría que recurrir a una utilidad especialmente designada para este tipo de propósitos; utilidad que está instalada por defecto en el sistema: ssh-keygen. Esta utilidad nos ayudará a leer el contenido del fichero de forma mucho más legible... Para ello habría que recurrir al comando ssh-keygen, seguido de los parámetro -l y -f; junto con el nombre del fichero cuya "huella" deseamos observar. La salida del comando en cuestión nos mostraría la huella de la clave rsa:

  1. root@debian:/etc/ssh# ssh-keygen -l -f ssh_host_rsa_key.pub
  2. 2048 d8:70:02:60:85:a6:e0:2e:17:f9:12:aa:36:02:14:e4  root@debian (RSA)

¿Os suena dicha clave? Así es, es la misma que la mostrada en la pantalla cuando nos hemos intentando conectar por ssh al otro equipo...  Ahora bien: ¿Para qué nos puede servir este concepto? El objetivo del mensaje mostrado en pantalla cuando nos conectamos a equipo "desconocido" es informarnos y verificarnos que nos estamos intentando conectar a un equipo cuya huella dactilar de la clave es la que muestra en pantalla. Es por ello que es importante saber que el destino al que nos intentamos conectar posee EXACTAMENTE el mismo fingerprint que el mostrado en nuestra pantalla, ya que sino podríamos estar conectandonos a otro equipo... Dicha conexión puede ser accidental (debido a una mala gestión de la red) o debido a un ataque de Man In the Middle (MiM), con lo que en caso de no coincidir con el fingerprint que debería ser, habría que preocuparse y ver si nuestra seguridad se ha visto comprometida antes de decidir conectarnos a la máquina objetivo. Es decir que este recurso puede servirnos como medida de protección contra ataques de MiM, siempre y cuando prestemos atención al mensaje que nos muestra la pantalla al establecer una conexión ssh.

Todas las claves se almacenan dentro de un fichero especial que varía dependiendo de la herramienta usada o el sistema operativo desde el que hemos realizado la conexión. Por ejemplo, si quisiésemos consultar las conexiones ssh realizadas con el usuario root desde Linux, habría que dirigirse a la carpeta home del usuario con el que nos hemos conectado (en este caso root). Dentro del directorio personal existe un subdirectorio oculto denominado .ssh donde se almacenan los hosts que el usuario "conoce". Dicho conocimiento se alberga dentro de un fichero denominado known_hosts (dentro de la carpeta .ssh)  y es consultado de la misma forma que el fingerprint de las claves almacenadas en /etc/ssh/; es decir que se consultaría así:

ssh-keygen -l -f /root/.ssh/known_hosts

Si deseásemos limpiar algún host de dicho fichero bastaría con eliminar la línea correspondiente o simplemente eliminando todo el contenido del fichero.

En Windows el proceso varía, ya que para empezar se necesita usar sí o sí la herramienta putty, herramienta que guarda los hosts dentro de una lista que se encuentra dentro del registro de Windows. Para acceder a dicha lista habría que escribir en el buscador de programas y archivos la palabra regedit. Dicho comando nos llevaría directamente al registro del sistema, en el cual habría que acceder a esta ruta:

HKEY_CURRENT_USER-->Software-->SimonTatham-->PuTTY -->SshHostKeys

Dentro de dicha ruta veríamos un listado en el cual podríamos consultar, modificar y eliminar los fingerprint a nuestro gusto.

Como podemos ver, el mantener bajo vigilancia nuestros fingerprints es relativamente sencillo y nos hace concluir que, si nos aparece el mensaje de un nuevo fingerprint cuando nos conectamos a un sitio al que accedemos habitualmente... Hay que sospechar...

Espero que os resulte útil.

Saludos.

miércoles, 23 de septiembre de 2015

Creando nuestros propios containers en Debian

Los conceptos "virtualización" y "la nube" están cada vez más y más expandidos, siendo considerados como las "modas" actuales. Hoy vengo a hablaros sobre un concepto parecido a la virtualización, pero al mismo tiempo diferente: Los Linux Containers; también conocidos como LXC. Aunque ambos, máquinas virtuales y containers, son parecidos en algunos puntos, son bien distintos en otros... 

Un container se trata de un entorno virtual completamente distinto al que estamos corriendo actualmente, si bien este container ha sido creado con un Kernel de Linux, con lo que solamente será capaz albergar sistemas operativos de dicha índole. Una de las ventajas de poseer un entorno virtualizado con respecto a una máquina, se trata del gran rendimiento que se obtiene del susodicho, ya que a nivel de potencia de procesador, velocidad, etc... hereda las mismas virtudes que la máquina; con la diferencia de que este entorno está completamente aislado de nuestro sistema y no corremos peligro de que nuestro sistema se infecte en caso de que el entorno haya sido infectado. En resumen: Podría decirse que un container es una especie de híbrido entre una máquina virtual y un entorno enjaulado chroot.
Ahora que tenemos una idea general de lo que es un container, ¿Qué mejor que crearnos uno? Esto requiere que nuestro sistema posea el init systemd. En caso de tener Debian7, aunque por defecto dicho init no está instalado, podría instalarse mediante:

apt-get install systemd systemd-sysv

Si poseyésemos una versión superior a ésta, no deberíamos preocuparnos en cubrir dicha necesidad, ya que con la llegada de Debian8 se ha implantado por defecto este polémico init. Supongamos que hemos arrancado con systemd; esto no sería suficiente para ponernos a trabajar con nuestros containers, ya que necesitaríamos tener una aplicación instalada en nuestro sistema; aplicación que no tenemos instalada por defecto, llamada debootstrap. Afortunadamente se encuentra en los repositorios con lo que habría que escribir:

apt-get install debootstrap

Ahora sí que podríamos crear nuestros containers; creación que se basaría en la siguiente estructura:

debootstrap --arch=${arquitectura} ${versión_debian} ${nombre_container}

La arquitectura haría referencia a las posibles arquitecturas del sistema que podemos estar usando; arquitectura que podemos consultar mediante el comando:

uname -a |awk '{print $8}'

La versión de Debian que deseamos instalar puede ser wheezy(Debian 7), jessie(Debian8) o unstable, dependiendo de nuestras necesidades, si bien yo recomiendo optar por Jessie (aunque esto es una elección personal). Imaginemos que deseamos crear un entorno llamado Micontainer con Debian jessie instalado, en un arquitectura amd64.

debootstrap --arch=amd64 jessie Micontainer/

El proceso llevará bastante tiempo, pero una vez finalizado éste, ya podríamos disponer de un entorno virtual Linux completamente operativo. En caso de querer ejecutar el entorno virtual que hemos creado solo habría que escribir:

systemd-nspawn -D Micontainer/

Gracias a este comando habríamos ejecutado el container, pero no lo habríamos arrancado... Esto se ha hecho aposta, ya que antes de arrancar el entorno y convertirlo en un sistema 100% funcional, queremos cambiarle la contraseña al usuario root del susodicho para poder manejar el sistema con libertad; con lo que una vez dentro de este entorno pondríamos la contraseña que más nos guste y saldríamos de aquí mediante el comando quit. Ahora sí que podríamos arrancar el entorno, lo cual se realizaría mediante el mismo comando escrito anteriormente, pero con el parámetro -b añadido:

systemd-nspawn -D Micontainer/ -b

Al ser un entorno 100% dependiente de la consola, la gestión de diferentes containers se realiza también desde la consola mediante la herramienta machinectl. Para listar todos los containers en ejecución habría que escribir:

machinectl

En cambio para comprobar el estado de un container en concreto deberíamos escribir el comando machinectl status ${nombre_container}; para nuestro container sería:

machinectl status Micontainer

Dependiendo  del container podríamos obtener un resultado u otro, pero el mensaje mostrado sería algo cómo lo siguiente:


Con estos conceptos solo faltaría jugar con los distintos containers e interactuar con ellos para ver hasta cuan lejos se puede llegar. También podemos intentar dar un paso más allá y optar por herramientas más visuales como Docker, si bien siempre es interesante conocer las bases sobre las que se sostiene dicha herramienta con el fin de comprenderla mejor.

Saludos. 

lunes, 21 de septiembre de 2015

Cómo centralizar los logs con rsyslog

Anteriormente ya hemos visto como gestionar de forma más eficiente los logs mediante logrotate, pero en el día de hoy vengo a hablaros de un aspecto que, si bien no es útil cuando se tiene un solo equipo, puede resultar de gran ayuda cuando poseemos un entorno con numerosos servidores. Imaginemos que nos encontramos en la situación de que tenemos numerosos servidores cuyos logs queremos revisar para simplemente controlar qué es lo que ocurre en éstos; una opción podría ser ir servidor por servidor, ya sea físicamente o vía ssh e ir comprobando los ficheros uno por uno, cosa poco práctica y tediosa... Es por ello que en ocasiones puede resultarnos útil agrupar todos los logs en un solo punto, tarea en la que intervendría un servicio en concreto denominado rsyslog.

Portada_rsyslog

Este servicio se caracteriza por ser capaz de ser  capaz de recibir logs de otro servidores al mismo tiempo de que también puede enviarlos a través de la red a otro equipo que esté preparado para dicha recepción. Al ser una comunicación que se va a realizar por red, es recomendable consultar nuestro cortafuegos para evitar que el tráfico entrante/saliente no sea bloqueado por éste, con lo que antes de empezar a configurar nada, hay que tener en cuenta que la comunicación se puede realizar a través del puerto 514 y que se puede realizar mediante tcp o udp; cualquiera de las dos es una opción perfectamente viable, pero yo en mi caso me decantaré por la comunicación udp. A sabiendas de dicha información podemos revisar las reglas de nuestro cortafuegos o (en caso de tener uno muy sencillo) escribir simplemente:

En el servidor de logs centralizado:
  1. iptables -A INPUT -p udp --dport 514 -j ACCEPT
En los equipos que enviarán los logs:
  1. iptables -A OUTPUT -p udp --dport 514 -j ACCEPT

Ahora que sabemos que ambos lados van a ser capaces de establecer la comunicación (o al menos deberían), pasaríamos a configurar el servidor que centralizará todos los logs. Dicha configuración es muy sencilla se establece de tal forma que aceptará cualquier log que se envíe al puerto 514, con lo que no habría que volver a configurarlo de nuevo en caso de querer añadir más equipos que queramos que envíen sus logs a éste. Para ello habría que modificar el fichero /etc/rsyslog.conf, el cual aunque ya tiene una serie de configuraciones establecidas por defecto, pero que no está preparado para recibir logs desde más allá del equipo local, es por ello que habría que remover el caracter # de las líneas referentes a la "escucha", además de añadir una nueva línea que se encargará de crear dinámicamente una carpeta para cada "cliente" que se vaya a conectar.

Antes:
  1. #$ModLoad imudp
  2. #$UDPServerRun 514
Después:

  1. $ModLoad imudp
  2. $UDPServerRun 514
  3. template FILENAME,"/var/log/%fromhost-ip%/syslog.log

Como podéis ver el cambio es rápido y eficaz, faltando únicamente reiniciar el servicio mediante el comando:

  1. /etc/init.d/rsyslog restart

Con esto no sería de por sí suficiente; faltaría configurar los clientes para que sus logs apuntes a nuestro servidor de logs centralizado. Para ello habría que añadir una pequeña línea en el fichero /etc/rsyslog.conf de cada cliente. Dicha línea tendría la siguiente estructura:


*.* @ip_servidor:514

Con lo que si por ejemplo la ip de nuestro servidor fuese 192.168.1.7; la línea a añadir sería:

  1. *.* @192.168.1.7:514

Ahora con únicamente reiniciar el servicio rsyslog tal y como hemos hecho en el servidor, ya podríamos disfrutar de nuestra centralización de logs.

Saludos.

viernes, 18 de septiembre de 2015

Cómo mejorar nuestra privacidad en Windows 10

Hoy os vengo con algo muy curioso que, sin saber muy bien cómo, me he topado por ahí y he estado probando... Se trata de la privacidad en Windows 10 (¿O sería más bien la falta de ella?), la cual ha preocupado a muchas personas, ya sea porque son entendidos del mundo tecnológico o porque simplemente nos preocupa el hecho de estar vigilados. La solución más fácil y definitiva sería: No usar Windows y listo; pero vamos a intentar darle un enfoque menos radical, ya que hay lugares en los que la desinstalación de éste sistema no es una opción ;véase por ejemplo, hogares en los que todo lo ajeno a Windows es impensable.

Cualquiera que haya instalado Windows 10 en sus equipos; ya sea para actualizarlo de una versión anterior o para instalarlo desde 0, se habrá encontrado con uno de los abanicos de opciones más típicos que nos hemos encontrado en los últimos años; abanico que consta de únicamente dos opciones y en el que la mayoría no escoge correctamente: ¿Instalación automática o manual? ¿Cuantas personas de nuestro entorno sabemos que siempre escogen la primera opción? De esto ya se ha hablado mucho en diferentes medios de comunicación, pero al escoger la instalación automática aceptamos políticas abusivas (esto puede recordarle a uno a Richard Stallman, pero es así) en las que prácticamente aceptamos DE TODO: Información personal, actividad en el equipo, aplicaciones usadas, etc... Prácticamente se les estaría entregando en bandeja todo sobre nosotros; entrega de información que nosotros, al escoger la instalación automática, hemos aceptado. Aquí la solución es sencilla: Escoger la instalación manual y desmarcar todas aquellas casillas (que dicho de paso, no son pocas) que tengan relación con la recopilación de nuestros datos... Hasta ahí estaríamos hablando de la práctica de salvaguarda de la privacidad más típica adoptada por aquellos que desean, en medida de lo posible, la mirada de Microsoft. Pero recientemente he descubierto un pequeño truco que nos ayuda a protegernos un poco más.

Este truco evita que nosotros, periódicamente enviemos información sobre nosotros a Microsoft; o al menos evita que enviemos parte de nuestra información. Para ello habría abrir el bloc de notas como administrador y abrir desde éste el fichero: C:\Windows\System32\drivers\etc\hosts. En dicho fichero se pueden especificar las ips pertenecientes a ciertos hosts específicos; hosts que pueden almacenar información sobre nosotros sin que nos demos cuenta; estas líneas harán que dichos hosts sean reconocidos como localhost (127.0.0.1) impidiendo que podamos interactuar con éstos (cosa que deseamos hacer para que no se pueda establecer la comunicación).

  1. 127.0.0.1       a-0001.a-msedge.net
  2. 127.0.0.1       a.ads1.msn.com
  3. 127.0.0.1       a.ads2.msn.com
  4. 127.0.0.1       ad.doubleclick.net
  5. 127.0.0.1       adnexus.net
  6. 127.0.0.1       adnxs.com
  7. 127.0.0.1       ads.msn.com
  8. 127.0.0.1       ads1.msads.net
  9. 127.0.0.1       ads1.msn.com
  10. 127.0.0.1       az361816.vo.msecnd.net
  11. 127.0.0.1       az512334.vo.msecnd.net
  12. 127.0.0.1       choice.microsoft.com
  13. 127.0.0.1       choice.microsoft.com.nsatc.net
  14. 127.0.0.1       compatexchange.cloudapp.net
  15. 127.0.0.1       corp.sts.microsoft.com
  16. 127.0.0.1       corpext.msitadfs.glbdns2.microsoft.com
  17. 127.0.0.1       cs1.wpc.v0cdn.net
  18. 127.0.0.1       df.telemetry.microsoft.com
  19. 127.0.0.1       diagnostics.support.microsoft.com
  20. 127.0.0.1       fe2.update.microsoft.com.akadns.net
  21. 127.0.0.1       feedback.microsoft-hohm.com
  22. 127.0.0.1       feedback.search.microsoft.com
  23. 127.0.0.1       feedback.windows.com
  24. 127.0.0.1       i1.services.social.microsoft.com
  25. 127.0.0.1       i1.services.social.microsoft.com.nsatc.net
  26. 127.0.0.1       oca.telemetry.microsoft.com
  27. 127.0.0.1       oca.telemetry.microsoft.com.nsatc.net
  28. 127.0.0.1       pre.footprintpredict.com
  29. 127.0.0.1       preview.msn.com
  30. 127.0.0.1       rad.msn.com
  31. 127.0.0.1       redir.metaservices.microsoft.com
  32. 127.0.0.1       reports.wes.df.telemetry.microsoft.com
  33. 127.0.0.1       services.wes.df.telemetry.microsoft.com
  34. 127.0.0.1       settings-sandbox.data.microsoft.com
  35. 127.0.0.1       sls.update.microsoft.com.akadns.net
  36. 127.0.0.1       sqm.df.telemetry.microsoft.com
  37. 127.0.0.1       sqm.telemetry.microsoft.com
  38. 127.0.0.1       sqm.telemetry.microsoft.com.nsatc.net
  39. 127.0.0.1       statsfe1.ws.microsoft.com
  40. 127.0.0.1       statsfe2.update.microsoft.com.akadns.net
  41. 127.0.0.1       statsfe2.ws.microsoft.com
  42. 127.0.0.1       survey.watson.microsoft.com
  43. 127.0.0.1       telecommand.telemetry.microsoft.com
  44. 127.0.0.1       telecommand.telemetry.microsoft.com.nsatc.net
  45. 127.0.0.1       telemetry.appex.bing.net
  46. 127.0.0.1       telemetry.appex.bing.net:443
  47. 127.0.0.1       telemetry.microsoft.com
  48. 127.0.0.1       telemetry.urs.microsoft.com
  49. 127.0.0.1       vortex-sandbox.data.microsoft.com
  50. 127.0.0.1       vortex-win.data.microsoft.com
  51. 127.0.0.1       vortex.data.microsoft.com
  52. 127.0.0.1       watson.live.com
  53. 127.0.0.1       watson.microsoft.com
  54. 127.0.0.1       watson.ppe.telemetry.microsoft.com
  55. 127.0.0.1       watson.telemetry.microsoft.com
  56. 127.0.0.1       watson.telemetry.microsoft.com.nsatc.net
  57. 127.0.0.1       wes.df.telemetry.microsoft.com

Solamente con guardar los cambios y reiniciar el equipo, ya estaríamos un poquito más seguros. También existe una herramienta de terceros llamada Destroy Windows 10 Spying, que nos evita hacer esta tarea manualmente, si bien pudiendo hacerlo nosotros mismos, ¿Para qué confiar en herramientas de terceros?

Esto es todo por hoy; como siempre, espero que os haya resultado útil.

Saludos.

miércoles, 16 de septiembre de 2015

Atributos en los ficheros Linux

En esta ocasión vengo a hablaros de una faceta poco conocida de Linux: Se tratan de los atributos de los ficheros y directorios. Es importante no confundir este concepto con los permisos o con los metadatos, ya que son conceptos complemente distintos; pues los atributos se tratan de comportamientos especiales y limitaciones que se le pueden poner a un fichero; ya sea para mantenerlo más seguro o para impedir que se hagan modificaciones innecesaria en éste. Probablemente nos hayamos encontrado a lo largo de nuestra vida con un fichero que posea ciertos atributos, si bien al ser un concepto muy poco conocido no hayamos tenido constancia de éstos. 

Linux_atributos

Primero es importante conocer qué atributos puede tener un fichero para saber a qué nos atenemos. Generalmente todos los ficheros tienen únicamente el atributo e (cuyo significado veremos más adelante) pero pueden llegar a tener alguno más, con lo que antes de optar a modificar sus atributos es recomendable listar éstos para conocer a fondo nuestro fichero. Para ello se hace uso del comando lsattr (List Attributes) que simplemente consta del nombre del comando seguido del nombre del fichero que queremos consultar. Por ejemplo:

lsattr /usr/src/fichero.txt

Tras dicho comando veremos un listado de caracteres en los cuales aparecerá el carácter - (en caso de no tener asignado ningún atributo) o una letra que representaría un atributo en concreto. Un ejemplo de un listado de atributos sería el resultado otorgado por nuestro último comando.

Lista_atributos

Conociendo dicho dato habría que comenzar a añadir o quitar atributos a dicho fichero, ¿pero qué atributos son éstos y qué función posee cada uno? Cada atributo está representado por un carácter alfabético, y he aquí el listado de los caracteres más usados:
  • a: Gracias a este atributos únicamente se pueden añadir datos al fichero, pero no se pueden modificar los datos existentes, cosa muy útil en ficheros críticos en los que únicamente se tienen que añadir datos, tales como los ficheros de log.
  • A: Este atributo hace que el sistema no modifique la última fecha de lectura de un fichero; cosa útil en sistemas con muy pocos recursos en los queremos ahorrar el máximo trabajo posible a la máquina, pero que también puede ser peligroso ya que en caso de que alguna persona no deseada leyese el fichero, no apreciaríamos ninguna modificación en la fecha en la que se ha leído el fichero por última vez.
  • s: Probablemente uno de los atributos más útiles, ya que al borrar un fichero o directorio con este atributo, el espacio que éste ocupaba sería sustituido por bloques de ceros, haciendo un borrado seguro del archivo.
  • u: Otro atributo realmente útil cuando queremos asegurarnos de la inamovilidad de un fichero... El objetivo de este atributo es exactamente opuesto al de s ya que se asegura de que si un archivo es borrado con este parámetro, éste pueda ser recuperado más adelante.
  • i: Uno de los atributos más usados por los amantes de la seguridad. Éste atributo hace que el fichero SIEMPRE esté en modo lectura, independientemente de los permisos otorgados mediante chmod.
  • I: Este atributo está implantado por defecto en los sistemas de ficheros ext3 y ext4 para la indexación de archivos con lo que por lo que en caso de no trabajar con uno de estos sistemas de ficheros debería estar desactivado.
  • c: Activa la compresión de datos en el fichero que tenga este atributo. Dicho fichero estaría (a nivel de tamaño) comprimido de forma transparente para las aplicaciones.
  • t: Un fichero con este atributo es reticente a sufrir fragmentación, cosa rara en sistemas Linux, pero con este atributo adicional la posibilidad de fragmentación con este archivo es muchísima menor.
  • T: Este atributo se aplica sobre directorios y se denomina Orlov block allocator; dicho atributo tiene como objetivo hacer que todo el contenido de un directorio con dicho atributo se escriba en la parte más rápidas del disco.
  • d: Gracias a este atributo, el fichero o directorio serán excluidos de cualquier copia de seguridad realizada con dumpcap.
  • D: Hace que una carpeta sea síncrona; es decir que el contenido del directorio se sincronice de forma automática.
  • e: Se trata de un atributo que está implementado por defecto en todos los ficheros y/o directorios y significa que utilizan extents para el mappeo de bloques en el disco... Se trata de un parámetro que es muy recomendable no alterar a menos que sea estrictamente necesario.
A sabiendas de la mayoría de la opciones que nos pueden ofrecer estos estupendos atributos, solamente faltaría proceder a añadir o quitar éstos a un fichero o directorio... Esto es tan sencillo como hacer uso del comando chattr, seguido del operador + (para añadir un atributo) o - (para eliminarlo) seguido del carácter que corresponde al atributo que deseamos modificar...

Supongamos que deseamos hacer que nuestro fichero (llamado fichero.txt) sea únicamente de lectura, independientemente de lo que digan los permisos de los usuarios... Esto es tan sencillo como escribir:

chattr +i /usr/src/fichero.txt

En cambio si deseásemos eliminar un atributo, habría que escribir:

chattr -i /usr/src/fichero.txt

Como podéis ver, aunque este concepto no es demasiado conocido, es innegablemente útil y puede servirnos para satisfacer un buen número de necesidades.

Espero que os haya resultado útil.

Saludos.