From: | Horacio Miranda <hmiranda(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Micky Khan <mcanchas(at)hotmail(dot)com> |
Cc: | pgsql-es-ayuda(at)lists(dot)postgresql(dot)org |
Subject: | Re: Que tan cierto es sobre este virus de postgresql.. |
Date: | 2020-01-15 04:34:52 |
Message-ID: | b4a8a84c-9557-18b4-09ad-df05c5878937@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
On 15/01/2020 12:36 pm, Alvaro Herrera wrote:
> Micky Khan escribió:
>> ALERTA NUEVO VIRUS QUE ATACA LAS BASE DE DATOS POSTGRESQL ELIMINA TODA LA INFORMACIÓN Y CREA UNA TABLA CON EL NOMBRE "WARNING" DONDE ALMACENA LA INFORMACION DE CUANTO SE TIENE QUE PAGAR EN BITCOIN PARA RECUPERAR LA INFORMACIÓN
>> [https://www.bitcoinabuse.com/…/1KnMcEqCTvQfMzEgnvfZvyprLPc2…](https://www.bitcoinabuse.com/reports/1KnMcEqCTvQfMzEgnvfZvyprLPc2bnvMm8?fbclid=IwAR3880p0ZlkR-kWRUg3WjrbJBALF-umrcZsppE54MfkOKgH5vrvAT5iQ2Iw)
> :-( Hace poco tuvimos en esta lista un reporte de alguien a quien le
> tomaron la BD de rehén. La sugerencia obvia es mantener todo el
> software al día (Postgres y el sistema operativo), tener los firewalls
> apropiados, no dejar permisos "trust", restringir lo más posible los
> accesos de superusuario, etc.
Lo unico que se me ocurre es que los usuarios se hagan la idea de
bloquear cuentas donde hay mucho acceso desde afuera (esto si es que hay
que tener la base expuesta ).
cerrar los puertos al pais a donde quieres exponer la base ( hay sitios
donde se sacan la lista de redes de un pais ).
dejar los respaldos afuera de las maquinas con respaldos ciclicos (
diarío, semanal, mensual y anual ), en mi caso esto me salvo cuando un
error de contabilidad agregaron un impuesto por error y se dieron cuenta
un año despues. se recupero la data historica y se recalculo el año en
curso.
Poner alertas o mandar un email cuando hay mucho acceso de IP que no se
conocen.
de mi tool box, tengo estas estadisticas para determinar de donde se
meten los usuarios en un cliente que tiene 10.
stats.sh
> #!/bin/bash
> if [ "$1" == "" ] ; then
> N=0
> else
> N=$1
> fi
>
> echo "Getting stats for postgresql-$(date +%a -d "${N} day").log"
>
> grep host /var/lib/pgsql/10/data/log/postgresql-$(date +%a -d "${N}
> day").log | awk -Fhost= '{print $2}' | awk '{print $1}' | sort | uniq
> -c | sort -n
La salida es algo como Getting stats for postgresql-Wed.log
10 186.11.47.228
34 200.83.220.177
48 190.161.168.165
77 191.126.56.181
105 191.125.18.24
110 191.126.21.19
794 192.168.23.126
2358 190.96.67.242
Todas estas cosas ayudan un poco a darse cuenta que algo esta pasando
pero nada evita que pase si no se parchan las maquinas, tienen claves
faciles y/o permisos muy abiertos. claves como "secret" "Password1"
"qwerty" te las van a pillar y en general uso un generador de claves
para mis sistemas.
Esto lo tengo en mi .bashrc para cuando creo un usuario. hago genpasswd
y lo mejor de todo es que si quiero algo mas largo que 12, genpasswd 20
por ejemplo.
genpasswd() {
tr -dc A-Za-z0-9 < /dev/urandom | head -c ${1:-12} | xargs
}
Y la lata de dejar el sistema que te mande email todos los días ( es
lata pero una lata necesaria ).... cuando algo raro pasa lo vas a saber.
Activar TLS si puedes.
Y si quieres estar bien seguro que tus claves no estan en un
diccionario. revisen las claves usando este diccionario que uso.
https://crackstation.net/crackstation-wordlist-password-cracking-dictionary.htm
En lo personal cualquier sistema que este botado sin parchar sobre 8
meses, es casi seguro que se lo van a violar, es super complicado
exponer algo sin parches a menos que tengas buenos firewall con un buen
WAF en caso que tengan web server super viejos.
Espero que esto ayude un poco dar awareness de que claves faciles son
faciles por algo....
From | Date | Subject | |
---|---|---|---|
Next Message | Diego | 2020-01-15 12:01:46 | Re: saber que filas se actualizaron o insertaron con upsert |
Previous Message | Alvaro Herrera | 2020-01-14 23:36:21 | Re: Que tan cierto es sobre este virus de postgresql.. |