sábado, 21 de septiembre de 2019

Un poco de calma

Os habréis fijado que desde el día 9 de este mes no hay más artículos en el blog. No, no lo voy a dejar, lo único es que me veo forzado a parar un poco.  Llevo ya unos meses con problemas de salud asociados al estrés, por lo que escribir todos los días en el blog me es imposible por salud. 


Son avisos del corazón, avisos que hacen ver que debo tomarme la vida más tranquila dentro de lo posible. No voy a dejar de escribir, pero sí que me tomaré más tiempo para redactar artículos. No habrá 1 artículo al día pero sí que la calidad subirá-

¿Hackeamos el Mundo?

lunes, 9 de septiembre de 2019

#NoMoreCreditCards Ten tu cuenta del supermercado antes de tiempo con software libre (Parte I)

Tenemos que empezar a dejar de utilizar las tarjetas de crédito. Ya no sólo por temas de privacidad, sino por dejar de dar tanta ventaja a los bancos. Saquemos nuestro dinero y vamos a guardarlo nosotros mismos aunque eso implique riesgos y sacrificios.


Ya explicaré más en otro artículo el por qué no se deben utilizar tarjetas de crédito y cómo funciona un banco y algunas de sus ventajas. Por el momento, daré motivos de por qué utilizar medios alternativos a las tarjetas de crédito.

Cuando digo de dejar de utilizar tarjetas de crédito, siempre hay quien me dice que, si van al supermercado, es más cómoda la tarjeta pues no tienen que preocuparse de llevar suficiente dinero para así no quedarse cortos. No obstante, cuando vamos a comprar, tenemos más o menos una idea de lo que queremos, es decir, tenemos una lista de la compra.

Así pues, podríamos tener una base de datos con lo que hemos comprado en el último año y sus precios (para algo tenemos los tickets) Así pues, con un sencillo programa, podemos hacer consultas a la base de datos que tenemos en función de nuestra lista de la compra y que haga la suma de precios.


Podemos crear una base de datos como esta con distintas tablas, donde cada tabla sea un supermercado.


Este sería un ejemplo pequeño de cómo estaría la base de datos. Probemos alguna query con algún dato más.



Pues solamente tenemos que montarnos un script que consulte nuestra lista de la compra y busque el precio de cada producto en nuestra base de datos y lo almacene para hacer el sumatorio posteriormente (hago el sumatorio con paste -sd+ count.txt | bc).



Con la opción "-s" lo que hacemos es indicarle en qué supermercado vamos a comprar. En el ejemplo vemos cómo con esta lista de la compra, nos sale que tendríamos que pagar 21.33€, algo que después podemos comprobar consultando cada producto y sumando con la calculadora.

Así es como, antes de salir, sabremos con exactitud cuánto nos costará la compra, por lo que la excusa de no llevar dinero encima no sirve. Es muy fácil ir a un cajero y sacar dinero. Si no queremos ir justos, podemos llevar 10€ más, pero que vaya, que no es excusa y menos cuando tenemos al software libre de nuestro lado.

Y antes de terminar, decir que esto me llevaría como mucho, 30-50 minutos de programación contando pasar toda la información a la base de datos.

Aquí el código

#!/bin/bash
if [[  $# -lt 2 ]];then

echo "You must specify at least 1 option with a value"
exit
fi
if [[ $2=="mercadona" ]];then
IFS=$'\n'
for products in $(cat lista.txt)
do
    if [[ $products ]];then
        testing=`mysql -u root -e "SELECT producto FROM gastoComida.mercadona WHERE producto LIKE '%$products%'" | tail -1 `
        product=`mysql -u root -e "SELECT precio FROM gastoComida.mercadona WHERE producto LIKE '%$testing%'" | tail -1`
        #echo $products
        #sleep 3
        echo $product>>count.txt
        #echo $testing>>testing.txt
    else
        echo "$products doesn't/don't exists/exist"

    fi


done

fi
        mycount=`paste -sd+ count.txt | bc`
        echo "Your count is: " $mycount "€"

Como veis noe s muy complejo. Vosotros lo podéis mejorar, porque sé que es mejorable, pero era para la demo y mostrar lo sencillo que es saber lo que nos va a costar la compra antes de salir, eso sí, con software libre.

¿Hackeamos el Mundo?

domingo, 8 de septiembre de 2019

Automatizando la actualización de la distro de nuestros servers

Es frecuente que como Sysadmins nos toque actualizar la distro de nuestros servidores. Es lo ideal para tener los paquetes más actuales y nuestro sistema actualizado y evitar fallos de seguridad. Si desarrollo se queja y dicen que sólo pueden utilizar una versión específica, entonces tendrán que ver qué cambiar, pues la actualización de un sistema es fundamental.


Los sysadmins tenemos que lidiar con muchos servidores, por lo que ir haciéndolo de uno en uno es una tarea poco eficiente y que lleva mucho tiempo. Así pues, nos toca conocer bien nuestros procesos y automatizarlos.


Con este sencillo playbook de ansible tendremos automatizada nuestra tarea. Recuerdo que en hosts podemos seleccionar "all". Yo para según qué tareas no especifico el "all", pues me gusta ver qué errores ocurren y solucionarlos al momento. Pero con esto de hacer un backup del sources.list, pasar uno que tengamos nosotros con las repos de Debian 10 Buster y finalmente indicar que actualice, tendremos nuestra tarea automatizada.

root@mailbox:~# lsb_release -a;date
No LSB modules are available.
Distributor ID:    Debian
Description:    Debian GNU/Linux 8.9 (jessie)
Release:    8.9
Codename:    jessie
mar sep  3 10:18:48 CEST 2019
root@mailbox:~#


------------------------------------------------------------
root@mailbox:~# lsb_release -a;date
No LSB modules are available.
Distributor ID:    Debian
Description:    Debian GNU/Linux 10 (buster)
Release:    10
Codename:    buster
mar sep  3 10:27:59 CEST 2019

Y en menos de 10 minutos tendremos nuestra distro actualizada y simplemente con una línea de comando, el de ejecución del playbook, así de simple se queda nuestra tarea.

¿Hackeamos el Mundo?

sábado, 7 de septiembre de 2019

La facilidad que tienen servicios como Google, Facebook o cualquier plataforma digital para el espionaje

No debería sorprendernos los casos que salen de espionaje en Google o Facebook. Quien se sorprenda o es hipócrita o no sabe cómo funcionan los sistemas. Lo tienen muy fácil porque controlan los medios de producción y pueden hacer lo que quieran. Cuando antes lo entendamos, mejor.


Para explicarlo, vamos a poner ejemplos sencillos. Imaginad una página web que permite crearte un usuario y te da un entorno (una GUI) relativamente sencilla de utilizar en la que puedes subir los archivos que quieras y además chatear con quien quieras. Lo de chatear vamos a dejarlo a un lado, al menos por hoy.

Seguid imaginando, no paréis. Pensad que tenemos los siguientes usuarios:

- usuario1
- usuario2
- usuario3
- usuario4
- usuario5

Cada usuario tiene su cuenta y, si lo pensamos como un GNU/Linux, tendrán su directorio home. A cada directorio home sólo podrían acceder, en principio, cada usuario a su carpeta correspondiente.

Cada usuario, en su carpeta, van guardando sus archivos. Pensad en Google Drive por ejemplo. Por cierto, las backups de tus conversaciones de Whatsapp, acaban en Google Drive (Más adelante seguiremos marcando este punto).

Pues bien, ahora tenemos a un administrador al que le dicen:

"Oye, quiero saber qué están haciendo los usuarios"

Para el sysadmin es tan "complicado" como hacerse root y entrar en la carpeta de cada usuario con un "ultra complicado" 'cd' e ir listando directorios. Si nos piden que le pasemos esa información -por lo que sea- al equipo comercial, solamente tendremos que hacer un scp rsync  y enviar las carpetas con la información.

"Pero Manu, esto se queda en los logs y en el history"


Esta hipotética empresa podría, de una manera tan sencilla y "sin dejar rastro" espiar a sus usuarios.

Pues Google, Facebook, Uber y empresas de este tipo igual. Y no estoy entrando si quiera en que todo esto se puede automatizar muy fácilmente. Por ejemplo, si queremos eliminar todos los "cd" y "ls" más los "rsync" que hayamos hecho a partir de la línea 53646324 que es en la que hemos empezado a actuar hoy, tan complicado como montarse un script con if que lea el número de la línea y a partir de ahí haga un grep con los "cd", los "ls" para quedarse con la línea en la que están y eliminarlas. Nada que lleve más de 1 hora de trabajo como mucho.

Y esto es así porque controlan los medios de producción y pueden hacerlo. Y es que es bastante sencillo, de hecho cuando me ha tocado hacer alguna migración de servidor, una de las cosas era pasar información de un servidor a otro y a veces tocaba comprimir información del home de los usuarios y podías ver con la opción -v los archivos que tenían.

Google y Facebook sólo tendrían que tirar de la lista que seguramente tendrán con sus anunciantes y buscar si existe alguna coincidencia en los archivos. Por ejemplo, imaginad que LucasFilm (los de las pelis de Star Wars) tienen publicidad con Google y de repente, Google ve que un usuario suyo tiene en su Google Drive alguna película de Star Wars. Pues ya saben a quién ponerle publicidad sobre Star Wars.

O mejor, Google puede detectar que hay usuarios con películas de Star Wars en sus servidores y ve que LucasFilm no es cliente, por lo que llaman o escriben a LucasFilm para ver si quieren ser clientes, algo que se hace diariamente en cualquier departamento de comercial. Y sería ideal, porque Google podría decir algo como:

"Hemos detectado que hay un X% de usuarios en nuestros servidores que pueden ser potencial espectadores de Star Wars o, al menos, comprar merchadaising."

Unirían esta información junto a historial de navegación y cookies y así pueden obtener unos resultados bastante más precisos.

Y ahora entremos en otro aspecto importante y que a mucha gente se le ha podido pasar.


Cuando a los usuarios de Whatsapp y Google les llegó este correo no pensaron en ¿Y cómo se va a permitir este envío de información?

En Android, cada app se ejecuta con un user distinto, por lo que se logra cierta independencia. Para compartir datos entre apps tenemos que irnos a los Content Provider (aquí tenéis algo más de info. Referencia1, Referencia2). Vale, pero el problema es que el envío de información no se hace a nivel de app, no hace falta.

Basta con que Google, por ejemplo, habilitase un usuario en sus sistemas que se llame whatsapp y con correo, por ejemplo, whatsapp@google.com. Imaginemos un caso sencillo, envío de información mediante ssh. De esta forma, Google podría solicitar una publick key a Whtatsapp y Whatsapp, implementar en cada usuario una especie de crontab que cada día haga la copia de seguridad y la envíe a Google Drive mediante ssh por ejemplo.

Pero ojo, porque si este usuario whatsapp sólo va a enviar archivos, no tiene mucho sentido (obviamos el interés capitalista y de mercado) que este usuario pueda acceder al servidor (esperamos que, aún en este caso, con privilegios restringidos) y ver otros archivos, cambiarse de carpetas,etc. Todo esto lo podemos limitar introduciendo, en el authorized_keys y delante de la clave, command="".

Esto último lo veremos en un futuro artículo, pero de momento que quede claro que, empresa que controle sus propios sistemas, si trata con información de usuarios, puede obtener esa información y verla sin mayor problema.

¿Hackeamos el Mundo?

viernes, 6 de septiembre de 2019

Fallos por error VS Fallos por no hacer los deberes

Un Sysadmin muchas veces tiene que lidiar con problemas que no son problemas, pero esa bronca la echaré otro día. Hoy vengo a llamar la atención a desarrolladores (otra vez) y a jefes o CEOs.



Vamos a ver, por partes. Muchas veces cuando un sistema falla, se señala al SysAdmin sin más y se le piden explicaciones (ejem, ejem, jefes). Creo que es muestra del analfabetismo informático y tecnológico que existe provocado por el concepto de "la abstracción". Voy a tratar de explicar algunas cosicas que pueden aclarar un poco por qué se originan según qué fallos.

Imaginemos que tenemos un servicio expuesto al público y dicho servicio es, a lo mejor, un servicio de monitorización y no está securizado. Eso es un fallo por error y de los gordos.

Otro caso, imaginemos que se elabora un proyecto de desarrollo para implementar un servicio. Se desarrolla y, cuando está casi terminado, se dice y se pregunta sobre qué servidor se va a montar (aquí ya hay un fallo pues no se puede implementar un proyecto sin consultarlo previamente con el SysAdmin y que sea el Sysadmin la persona que de su opinión e incluso diga qué cosas del desarrollo se deberían quitar). Se monta finalmente y el Sysadmin empieza a elaborar las copias de seguridad que son necesarias. Ocurre un problema, se llena de espacio el servidor porque el proyecto de desarrollo no había tenido en cuenta (como suele ser frecuente) que hay más cosas aparte del propio proyecto como son copias de seguridad, scripts para automatizar tareas, etc.

Esto muchas veces no ocurre de repente, pero si no se ha planeado bien, puede que sí ocurra de repente, sobre todo si cuando se termina el proyecto de desarrollo se dice "compra un servidor, el que sea pero con memoria". Esto es un grave error y no del Sysadmin. Este puede ser el foco de muchos problemas que posteriormente se originen. Pues bien, volviendo al problema de las backups de nuestro ejemplo; esto no es un fallo del sysadmin, es lo que yo llamo un fallo por no hacer los deberes antes. Deberes que desarrollo o jefes deberían tener hechos.

Suele ocurrir cuando hay problemas de este tipo, la persona al mando del proyecto pregunte "¿Cómo se soluciona?". Tendríamos, si queremos hacer bien nuestro trabajo, volver al punto inicial de que desarrollo no puede empezar su trabajo -o al menos dejarlo casi terminado- si no hay un ingeniero de sistemas (sysadmin) revisando y asesorando o incluso inspeccionando.

Sobre el "Esto es que no ha pasado nunca antes", ya hablaré otro día, pues también da mucho juego y se suele mirar (mal) a los administradores de sistemas. Pero que un fallo no se haya originado antes, no significa que no se haya estado generando antes. Pero esto ya son cosas que veremos en otro artículo.

¿Hackeamos el Mundo?

jueves, 5 de septiembre de 2019

Kubernetes: Entrando en el mundo de la moda [Parte III]

Pues como Doors, This is the End de esta trilogía (aunque se ampliará con otro(s) artículo(s) sobre otra tecnología que complementará a esta trilogía). Ya hemos visto cómo instalar kubernetes y cómo configurarlo para tenerlo operativo y funcionando de manera similar a Docker.



Lo primero que tendremos que hacer es descargarnos los componentes necesarios para utilizar el Dashboard de Kubernetes

kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-bet

Lo que nos debería devolver por pantalla debería ser algo similar a este output

namespace/kubernetes-dashboard created
serviceaccount/kubernetes-dashboard created
service/kubernetes-dashboard created
secret/kubernetes-dashboard-certs created
secret/kubernetes-dashboard-csrf created
secret/kubernetes-dashboard-key-holder created
configmap/kubernetes-dashboard-settings created
role.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrole.rbac.authorization.k8s.io/kubernetes-dashboard created
rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
deployment.apps/kubernetes-dashboard created
service/dashboard-metrics-scraper created
deployment.apps/kubernetes-metrics-scraper created

Ahora crearemos nuestro usuario

$kubectl create serviceaccount k8sadmin -n kube-system

Nos debería decir que se ha creado sin problemas

serviceaccount/k8sadmin created

Solo nos quedarían algunas configuraciones más y terminamos

$kubectl create clusterrolebinding k8sadmin --clusterrole=cluster-admin --serviceaccount=kube-system:k8sadmin

El output debería ser el siguiente

clusterrolebinding.rbac.authorization.k8s.io/k8sadmin created

Y con esto hemos terminado


Sólo tendremos que acceder a:

http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

Y ya nos dejará hacer login. Ojo, vamos a acceder mediante Token, por lo que lo tenemos que generar:

$kubectl get secret -n kube-system | grep k8sadmin | cut -d " " -f1 | xargs -n 1 | xargs kubectl get secret -o 'jsonpath={.data.token}' -n kube-system | base64 --decode

Copias y pegamos y estaremos dentro de la Web UI de Kubernetes




Veremos en nuestra interfaz gráfica todo lo que necesitamos saber sobre nuestro Kubernetes, ya es solamente jugar un poco con la interfaz.



Tendremos que saber más o menos qué nos muestra cada ventana y cada opción dentro de la Web UI, pero la implementación de Kubernetes con su Dashboard ya estaría realizada.

¿Hackeamos el Mundo?

miércoles, 4 de septiembre de 2019

Mi artículo en UaD

Nuevamente he escrito en Una al Día, y esta vez traigo un artículo bastante completo y largo explicando las vulnerabilidades que se encontraron en Apache2 para Debian y hago algunas aclaraciones ante algunas confusiones y además aviso que, con la solución aportada, aún podríamos vernos afectados en un tiempo por una vulnerabilidad similar.





¿Hackeamos el Mundo?
Related Posts Plugin for WordPress, Blogger...

Entrada destacada

El server me sabe a poco.

Soy un fanático del Rock y de Debian . (Creo que voy a inventar Rockbian, que suena bien y todo xD) Llevaba tiempo queriendo unir estos 2 c...