Tengo un cliente al que le tengo que migrar el servicio a un hosting de estos con cpanel y estas mierdas. Para subir los ficheros tengo que subirlos por FTP pero el wordpress que tengo que subir tiene mogollón de ficheros y subirlos uno a uno es para morirse. Además quiero hacer la transferencia de los ficheros directamente desde el servidor.
El cliente ftp básico no me permite subir un directorio completo, así que estoy usando otro cliente ftp, ncftp.
Lo instalo usando
# apt -y install ncftp
Y me posiciono en el directorio donde tengo el wordpress
# cd /var/www/
y lo subo usando
# ncftpput -avR -u -p
directorio_remoto: es el directorio del servidor remoto, en mi caso public_html
directorio_local: donde tengo el wordpress en mi servidor, wp…
Llega el momento de poner a producción un programa que llevas más de un año desarrollando, para montarlo necesito generar unos certificados autofirmados para cuando el dominio apunte a mi servidor generar los certificados de letsencrypt. De mientras el apunte de como generarlos con openssl:
¡Este último mes podríamos decir que he estado muy entretenida! Hace ya casi dos años, un cliente vino a mi harto de que los proveedores de hosting le cerrasen el servidor, durante todo este tiempo de maravilla, hasta que hace un mes y medio Movistar y Vodafone bloquearon el dominio. Ahí es cuando el cliente me contactó de nuevo para realizar un análisis y un informe pericial. El motivo es que el cliente no está realizando ningún acto delictivo que lleve a los proveedores de hosting e ISP a bloquear el servicio, aún así, lo hacen, estamos delante de un caso de Internet Blackout, bloqueo interesado de un servicio en concreto para que los usuarios no puedan acceder a él. ¿Algo ha tenido que ver el recién finalizado y polémico Mundial de Fútbol en Qatar?.
En la fecha del bloqueo del dominio del cliente, mi propuesta al identificar que el bloqueo se estaba realizando a nivel de dominio (que no de DNS, ya que estos si resolvían), le propuse al cliente de registrar otro dominio. La solución funcionó durante 2 semanas más hasta que Movistar y Vodafone bloquearon la dirección IP, como tal, la solución de añadir mas dominios apuntando al servidor, ya no era útil. Por mas INRI, el bloqueo se extendió a más ISP, aislando casi por completo el servidor de Internet (y no sólo en España, otros países de Europa y LatinoAmérica se vieron afectados), pero no todos lo bloquearon!
Hace unos días llegó a mí una de aquellas tareas que en teoría tenía que ser poquitas horas, las poquitas horas han terminado siendo casi un mes entero de trabajo.
La tarea encomendada era la de arreglar la portada de la página web del periódico digital de contrainformación kaosenlared.net.
La web estaba usando el tema publisher y la portada estaba construida con gutenberg, además para cachear la web se estaba usando el plugin W3 total cache. Una combinación del tema y los dos plugins mencionados hacían que se descuadrase toda la página. Por suerte se disponía de una copia de seguridad de un día anterior a que se rompiese la portada. Mi tarea fue pues reestablecer la configuración del tema desde las opciones de exportación y cargar el contenido de la página de la portada. Al arreglarlo y volver a poner la página en producción, a las pocas horas, la portada se volvía a descuadrar. El cliente pidió simplemente dar de baja esta web, hacer algo con los archivos y aprovechar para crear otra nueva que ya estaban usando como web de emergencia.
Así que mi propuesta fue arreglar de nuevo el wordpress y convertir la página web a estática, ya que la página web tenía un pequeño detallito de nada, la friolera de 407.000 entradas, cosa que hacía que el consumo de recursos de la web fuese espectacular, por la gran cantidad de páginas y usuarios que visitaban diariamente el sitio.
Con tanto ransomware, accesos indebidos a sistemas y demás ataques varios a sistemas, la concienciación de tener los sistemas al día está al día y supongo que algo habréis notado queridos lectores que mi actividad éstas últimas semanas ha sido frenética. Mi objetivo es ponerlos a punto y cada vez mas ir mejorando la seguridad sin que se vea afectada la usabilidad.
Está claro que un sistema conectado a la red es victima de intentos de acceso continuos y sólo nos interesan los que han tenido éxito. Es por esto que hoy os traigo un pequeño “tip” para avisar de los accesos a nuestro sistema, sean legítimos o no.
Hace años tenía implantada esta política de seguridad en mis servidores y me sirvió para paliar un ataque aún mayor. La primera reacción fue echar el malhechor de mis sistemas, al mismo tiempo que cambiaba las contraseñas de todos los servidores (ahí aprendí que tenemos que ir con mucho cuidado con nuestra política de passwords).
Lo primero será crear los dos scripts y los pondremos donde ejecutemos los scripts del sistema
root@frontal1-nginx:~# vi /root/scripts/login-notify-pam.sh
#!/bin/sh
/root/scripts/login-notify-script.sh &
root@frontal1-nginx:~# vi /root/scripts/login-notify-script.sh
#!/bin/sh
sleep 3
# Change these two lines:
sender="noreply-valido@capa8.net"
recepient="cuenta-de-notificaciones@capa8.net"
if [ "$PAM_TYPE" != "close_session" ]; then
host="`hostname`"
subject="SSH Login: $PAM_USER from $PAM_RHOST on $host"
# Message to send, e.g. the current environment variables.
message="Algú ($PAM_RHOST) ha entrat al sistema $host per SSH!\n\n`ps aux
Hace unos años hice un post sobre ssmtp. Éste post es exactamente lo mismo pero enseño a configurar msmtp ya que ssmtp ya no está disponible.
Lo primero será instalarlo:
root@asterisk10:~# apt install msmtp
Y lo segundo configurarlo, atención en el /home del usuario que va a ejecutar scripts que requieran mandar correos electrónicos, en el caso de root, su home es /root
root@asterisk10:~# vi .msmtprc
# Set default values for all following accounts.
defaults
auth on
tls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile ~/.msmtp.log
# Noreply
account noreply
host mail.capa8.net
port 587
from noreply@capa8.net
user noreply@capa8.net
password **************
# A freemail service
#account freemail
#host smtp.freemail.example
#from joe_smith@freemail.example
#...
# Set a default account
account default : noreply
Por otro lado instalaremos un cliente de mail, en este caso bsd-mailx
root@asterisk10:~# apt install bsd-mailx
Al ejecutar mailx con el pipe mail, nos sacará un error de que no encuentra sendmail, así que lo engañaremos un poco y le diremos que cuando busque sendmail use msmtp creando en ~ el fichero .mailrc
root@asterisk10:~# vi .mailrc
set sendmail=/usr/bin/msmtp
Ahora para mandar un mail de prueba podremos usar algo similar a ésto
root@asterisk10:~# echo "Blackhold blog rules" | mail correo@dominio.com
Y listos, ahora ya podemos mandar mails sin problemas. A lo mejor te interesa configurar el postmaster (fichero /etc/aliases) del usuario root para que mande los mails del sistema a donde le digas. Más información aquí.…
Y también que al hacer dpkg -i de algun paquete me suelta éste error:
# dpkg -i google-chrome-stable_current_amd64.deb
dpkg: avís: no s'ha trobat «ldconfig» en el PATH o no és executable
dpkg: avís: no s'ha trobat «start-stop-daemon» en el PATH o no és executable
dpkg: s'ha produït un error: no s'han trobat 2 programes esperats al PATH, o no són executables
Nota: el PATH del root normalment ha de contenir /usr/local/sbin, /usr/sbin i /sbin
El motivo es que necesitamos definir los directorios donde se encuentran los binarios del sistema:
Salimos de la sesión de terminal del usuario y la volvemos a iniciar y ta-dá!
Recuerdo que si un paquete no deja instalar las dependencias, tenemos que forzar la instalación manual con apt -f install
root@aspertic01:/home/aspertic/Baixades# dpkg -i teamviewer_14.5.1691_amd64.deb
S'està seleccionant el paquet teamviewer prèviament no seleccionat.
(S'està llegint la base de dades… hi ha 173445 fitxers i directoris instal·lats actualment.)
S'està preparant per a desempaquetar teamviewer_14.5.1691_amd64.deb…
S'està desempaquetant teamviewer (14.5.1691)…
dpkg: problemes de dependències impedeixen la configuració de teamviewer:
teamviewer depèn de libqt5gui5 (= 5.5) | qt56-teamviewer; tot i així:
El paquet libqt5gui5 no està instal·lat.
El paquet qt56-teamviewer no està instal·lat.
[...]
dpkg: s'ha produït un error en processar el paquet teamviewer (--install):
problemes de dependències - es deixa sense
Aquí os dejo uno de los scripts de backup que uso para hacer la copia de seguridad de los servidores con proxmox. Espero que os sea de ayuda :)
#!/bin/bash
## lmdb-backup (proxmox)
#### Loc: ******
#### OS: Debian 9 (container lxc)
#### Up: 2019/08/28 11:45 (Blackhold)
BACKUP_DIR="/mnt/hd_extern/backups_lmdb"
ID[0]="server1:x.x.x.x1"
ID[1]="server2:x.x.x.x2"
for INFO in "${ID[@]}"
do
HOST=`echo ${INFO} |awk -F ':' '{print $1}'`
IP=`echo ${INFO} |awk -F ':' '{print $2}'`
BACKUP_DIR_SERVER="${BACKUP_DIR}/${HOST}"
if [[ ! -e ${BACKUP_DIR_SERVER} ]]; then
mkdir ${BACKUP_DIR_SERVER}
mkdir ${BACKUP_DIR_SERVER}/daily
mkdir ${BACKUP_DIR_SERVER}/monday
mkdir ${BACKUP_DIR_SERVER}/15
mkdir ${BACKUP_DIR_SERVER}/28
mkdir ${BACKUP_DIR_SERVER}/lastmonth
fi
rsync -av --delete root@${IP}:/var/lib/vz2/dump/ ${BACKUP_DIR}/${HOST}/daily/dump/
rsync -av --delete root@${IP}:/var/lib/vz2/template/ ${BACKUP_DIR}/${HOST}/daily/template/
if [[ $(date +%e) -eq 28 ]]; then
echo Backup final de mes
rsync -av --delete ${BACKUP_DIR}/${HOST}/28/dump/ ${BACKUP_DIR}/${HOST}/lastmonth/dump/
rsync -av --delete ${BACKUP_DIR}/${HOST}/28/template/ ${BACKUP_DIR}/${HOST}/lasthmonth/template/
rsync -av --delete ${BACKUP_DIR}/${HOST}/daily/dump/ ${BACKUP_DIR}/${HOST}/28/dump/
rsync -av --delete ${BACKUP_DIR}/${HOST}/daily/template/ ${BACKUP_DIR}/${HOST}/28/template/
fi
if [[ $(date +%e) -eq 15 ]]; then
echo Backup dia 15
rsync -av --delete ${BACKUP_DIR}/${HOST}/daily/dump/ ${BACKUP_DIR}/${HOST}/15/dump/
rsync -av --delete ${BACKUP_DIR}/${HOST}/daily/template/ ${BACKUP_DIR}/${HOST}/15/template/
fi
if [[ $(date +%u) -eq 1 ]]; then
echo Backup dilluns
rsync -av --delete ${BACKUP_DIR}/${HOST}/daily/dump/ ${BACKUP_DIR}/${HOST}/monday/dump/
rsync -av --delete ${BACKUP_DIR}/${HOST}/daily/template/ ${BACKUP_DIR}/${HOST}/monday/template/
fi
done
Y lo añado en cron
root@lmdb-backup:~# vi /etc/cron.d/lmdb
# backup planets - activated on 2019-08-18 - blackhold
30 1 * * * root /root/scripts/backup_nodes_planet_lmdb.sh
Por supuesto, para hacer funcionar el script es necesario instalar rsync y también poner la clave pública del servidor de backups en el autorized_keys (ssh) de los servidores que queramos hacer copia de seguridad. Recomiendo fervientemente que ninguno de los servidores ni contenedores, tenga acceso directo …