Este es un truco rápido para ejecutar un comando en el momento en que te conectas por ssh a un servidor. Sólo tienes que editar el fichero ~/.bashrc de tu usuario o /etc/bash.bashrc si lo quieres hacer para todos los usuarios del servidor y añadir el código siguiente sustituyendo el echo que he puesto por el comando o comandos que quieras ejecutar.
if [[ -n $SSH_CONNECTION ]] ; then echo "Bienvenido guapetón" fi |
En servidores donde hay un gran trasiego de imágenes puede ser muy útil el instalar un sistema de compresión y optimización de imágenes en batch desde el servidor.
Para hacer la compresión de las imágenes vamos a utilizar jpegoptim para las imágenes jpeg y optipng para los png, otras opciones válidas para los png son pngcrush advancecomp.
La premisa principal del scrip es comprimir lo máximo posible sin pérdida de calidad.
Lo primero es instalar las aplicaciones:
apt-get install jpegoptim optipng |
El script que utilizo para hacer la compresión es este, tened en cuenta que uso un find sin límite superior por lo que comprimirá todas las imágenes de la ruta indicada y de todas las rutas que estén por encima de ella.
p.e.:
comprimir_imagenes.sh /opt/imagenes
comprimirá las imágenes de /opt/imagenes y de /opt/imagenes/a, /opt/imagenes/a/1, /opt/imagenes/a/1/2, etc.
#!/bin/bash echo " " if [ ! -z "$1" ] then INIT_DIR=$1 find $INIT_DIR -type f -name "*.jpg" | xargs -I ARG jpegoptim -p -f ARG find $INIT_DIR -type f -name "*.jpeg" | xargs -I ARG jpegoptim -p -f ARG find $INIT_DIR -type f -name "*.png" | xargs -I ARG optipng -preserve -o7 ARG else echo "" echo "Hay que indicar el directorio a partir del cual se quiere comprimir" echo " " echo "Formato:" echo "./optimizar_imagenes.sh /var/directorio/" fi echo " " |
Tened en cuenta que las imágenes comprimidas tendrán el usuario y grupo del usuario que ejecute el script.
Todos los que tenemos algún wordpress y revisamos los logs periódicamente vemos que continuamente hay accesos por POST al xmlrpc.php. Algunas veces son ataques y otras son simples consultas de bots. En cualquier caso son accesos que no me valen para nada y generan tráfico innecesario.
Hace poco revisando unos logs vi miles de accesos por POST desde una ip de Ucrania y con el user agent de GoogleBot. No se que quería pero seguro que nada bueno. 🙂
Lo que recomiendan en muchos sitios de borrar ese fichero a mi no me convence por que si actualizas el wordpress lo vuelves a tener ahí y hay veces que se hace un uso legítimo de ese fichero para, p.e. publicar post desde programas externos.
Una característica habitual de los bots es que hacen las peticiones por HTTP/1.0 en vez del habitual HTTP/1.1 así que aprovechando esta característica he preparado este pequeño código que bloquea las peticiones por POST y HTTP1.0 al xmlrpc.php. Obviamente si el bot trabaja con HTTP/1.1 esto no funcionará.
Lo más interesante de este código es que para evitar ifs anidados concateno dos valores en una variable. Si se cumple la primera condición el valor de la variable es «bot» y si se cumple la segunda añado a lo que tenga la variable el valor «post», de esa forma sólo devuelve 403 si las dos variables cumplen la condición. Este método permite construir tantos ifs anidados como quieras, simplemente hay que añadir más valores a la cadena.
## Block xmlrpc.php POST http1.0 location ^~ /xmlrpc.php { set $mata_bot 0; if ($server_protocol ~* "HTTP/1.0") { set $mata_bot "bot"; } if ($request_method = POST ) { set $mata_bot "${mata_bot}-post"; } if ($mata_bot = "bot-post"){ return 403; } } |
Espero que le sea útil a alguien más.
Información sobre ataques de fuerza bruta con xmlrpc.php
Este scrip en bash permite cambiar todas las claves de akismet de los blogs de un servidor. Simplemente busca todos los wp-config.php, saca los datos de acceso al mysql, comprueba si la clave que tienen metida es diferente de la nueva y si es así la cambia. Funciona perfectamente con wordpress multisite.
Acordaros de cambiar la clave y la ruta por la de vuestros servidores.
#!/bin/bash CLAVE_AKISMET='mi_clave_akismet' RUTA_WEB='/var/www/html/' for WPCONFIG in $(find $RUTA_WEB -type f -name "wp-config.php") do DBNAME=$(grep "DB_NAME" $WPCONFIG | awk '{split($0,a,","); print a[2]}' | awk '{split($0,a,";"); print a[1]}' | sed -e 's/)//g' | sed -e "s/'//g" | tr -d " ") DBUSER=$(grep "DB_USER" $WPCONFIG | awk '{split($0,a,","); print a[2]}' | awk '{split($0,a,";"); print a[1]}' | sed -e 's/)//g' | sed -e "s/'//g" | tr -d " ") DBPASS=$(grep "DB_PASSWORD" $WPCONFIG | awk '{split($0,a,","); print a[2]}' | awk '{split($0,a,";"); print a[1]}' | sed -e 's/)//g' | sed -e "s/'//g" | tr -d " ") DBHOST=$(grep "DB_HOST" $WPCONFIG | awk '{split($0,a,","); print a[2]}' | awk '{split($0,a,";"); print a[1]}' | sed -e 's/)//g' | sed -e "s/'//g" | tr -d " ") if [ $(mysql -u $DBUSER -p$DBPASS -h $DBHOST $DBNAME -Ns -e "show tables;" | grep -c _options) -gt 0 ]; then for TABLA_OPTIONS in $(mysql -u $DBUSER -p$DBPASS -h $DBHOST $DBNAME -Ns -e "show tables;" | grep "_options") do clave=$(echo "select option_value from "$TABLA_OPTIONS" where option_name='wordpress_api_key';" | mysql -u $DBUSER -p$DBPASS -h $DBHOST $DBNAME -Ns) if [ "$clave" != "$CLAVE_AKISMET" ]; then echo "Actualizando TABLA_OPTIONS:" $TABLA_OPTIONS echo "update "$TABLA_OPTIONS" set option_value='"$CLAVE_AKISMET"' where option_name='wordpress_api_key';" | mysql -u $DBUSER -p$DBPASS -h $DBHOST $DBNAME -Ns fi; done fi; done |
Interesante presentación donde nos muestran todas las posibilidades de AWS S3
A veces es interesante acceder a algún servidor por ssh sin tener que introducir las claves. La forma más sencilla de hacerlo es:
1.- Comprueba si tienes ya creadas tu par de claves. Vete a /home/tu_usuario/.ssh/ y comprueba si existen los ficheros id_rsa y id_rsa.pub . Si no existen genéralos con
ssh-keygen |
2.- Una vez que ya tienes tu par de claves copialas al host destino con
ssh-copy-id usuario@host_destino |
Ahora ya podrás conectarte directamente a ese host sin necesidad de introducir la clave. Ten en cuenta que si hay un problema de seguridad en tu equipo estarás comprometiendo todos los equipos a los que te puedes conectar sin clave, úsalo con mucho cuidado.
Desde este año es obligatorio que todos los trámites que se realicen con el registro mercantil se hagan telemáticamente. Por mi parte todo perfecto por que así nos ahorramos tiempo y viajes pero como siempre que hay que realizar algún trámite online con la administración llegaron los problemas.
Hoy me ha llegado una notificación y al intentar visualizarla me daba el siguiente error: «Error obteniendo certificados de usuario.
Se ha producido un error que impide el correcto funcionamiento de la aplicación
Por favor disculpen las molestias.
Póngase en contacto con nuestro Servicio técnico en el tfno: 902 201 200 / 91 270 17 97.»
y después «Error obteniendo certificados de usuario»
Por supuesto que tanto los certificados como java están funcionando correctamente.
Aunque ya me imaginaba la respuesta he llamado al teléfono de referencia y la respuesta ha sido la típica: «Abra una nueva ventana del Internet Explorer» y cuando le he explicado que no tengo internet explorer ni windows ni nada de eso me ha contestado lo habitual «es que sólo funciona con internet explorer». La verdad es que a estas alturas de la película que alguien desarrolle sólo para internet explorer es de tontos, ya se que no me van a hacer ni caso y que por muchas reclamaciones que presente no van a solucionar nada pero me fastidia que me respondan eso, así que el chaval que me respondió al teléfono me ha tenido que escuchar un ratito despotricar sobre todo este tema.
Revolviendo un poco me he dado cuenta de que si cambias un pequeño parámetro de la url ya puedes acceder al documento sin problemas, concrétamente el parámetro es tipoDetalle y hay que cambiar el valor de 2 a 3, así:
URL original (el código de petición lo he eliminado)
https://www.registradores.org/presentacionTelem/notifComuAvisoDocs.do?dispatch=mostrarDatosDetalle&pantalla=basicPage&tipoDetalle=2&codPeticionEnvioEDoc=xxxxxxxx
Se cambia a este:
https://www.registradores.org/presentacionTelem/notifComuAvisoDocs.do?dispatch=mostrarDatosDetalle&pantalla=basicPage&tipoDetalle=3&codPeticionEnvioEDoc=xxxxxxxx
Y esta es la pantalla final donde ya puedo acceder al documento.
Ahora que lo tengo aquí publicado a ver si no se me olvida para la próxima vez. 🙂
Una forma original de evitar el spam, popups y un montón de basura sin cargar nada el equipo es hacer que los hosts que lo sirven apunten al localhost. En someonewhocares.org he encontrado un listado de mas de 10000 spammers ya preparados para meter en el fichero host.
Se puede guardar en lugar de tu fichero hosts o añadir al que ya tienes. En mi caso lo tengo que añadir por que lo utilizo para mas cosas, así que he preparado este pequeño script que se puede añadir al cron y así actualizar periódicamente.
Este es el script:
#!/bin/bash if [ ! -f /etc/hosts.original ] then #hacemos copia del fichero original si no existe /bin/cp /etc/hosts /etc/hosts.original else #ya tenemos una copia del fichero orginal así que la restauramos /bin/cp /etc/hosts.original /etc/hosts fi #Descargamos el fichero host de http://someonewhocares.org/hosts/ ,filtramos las entradas que nos interesan y lo añadimos al nuestro fichero host curl --silent http://someonewhocares.org/hosts/hosts | grep '^127.0.0.1' >> /etc/hosts |
Si alguna vez necesitáis hacer una redirección de un dominio que no tenga un hosting ya creado lo podéis hacer con Amazon S3 fácilmente. Para este ejemplo voy a redireccionar el subdominio aws.rastreador.com.es a la categoría aws de este blog.
Lo primero es crear un bucket en S3 con el nombre del dominio o subdominio, este detalle es importante, no vale cualquier bucket, tiene que tener el mismo nombre del dominio que se va a redireccionar, en este caso aws.rastreador.com.es
Una vez creado el bucket vamos a propiedades y seleccionamos la opción de Static Website Hosting. Una vez ahí seleccionamos la tercera opción Redirect all requests to another host name e introducimos la url a la que queremos que se haga la redirección.
Finalmente sólo nos queda generar un registro cname en nuestro DNS que apunte al endpoint que he señalado en rojo en la imagen anterior.
Y con esto ya hemos terminado la redirección, para comprobarlo sólo hay que hacer un curl -I aws.rastreador.com.es y vemos que hace una redirección 301 a la url que le hemos indicado.
Acabo de ver esta entrada «evitar hotlinking mediante nginx» en el blog de systemadmin.es y me ha recordado una anécdota similar con la que tuve que lidiar hace un tiempo.
Revisando los logs de un un acortador de urls con yourls me encontré una barbaridad de enlaces desde un foro que redirigían a imágenes con contenido porno, y la verdad es que ni ese era el objetivo del acortador ni me apetecía regalar ancho de banda (por poco que sea) a esas cosas, así que aprovechando la versatilidad que da nginx hice que todas las peticiones de ese foro se redirigieran a otra foto un pelín diferente.
if ($http_referer ~* (foro_malo_malo)) { #return 403; return 301 http://www.photogallery.va/content/dam/photogallery/franciscus/06612_19052013.jpg/_jcr_content/renditions/cq5dam.web.800.800.jpeg; } |
La verdad es que me estuve riendo un buen rato pensando en la cara que le quedaría al chaval que esperaba encontrarse una alegre moza con poca ropa y que de pronto se encuentra a este buen señor con esa cara de cachondeo. 🙂
Al principio había puesto un «return 403;» pero noté que la gente veía el error, recargaba la url del acortador y ya le redirigía a la página de destino correctamente.