Configuración Ubuntu Server 18* Desde 0 (parte 1º)

Sumario

Puede que el servidor de linux, ubuntu server, sea el más popular y el más usado por desarrolladores y administradores de SO (Sistemas Operativos) a nivel global.
En parte por su calidad, excelente, por su código abierto y gratuito, por su gran comunidad de desarrolladores que no paran de mejorarlo y sacar nuevas versiones, etc…

En este post quiero mostraros la configuración que suelo realizar en él para lanzar páginas web a Internet y aplicaciones de servidor. También por qué no decirlo, porque así lo tengo esquematizado y listo para una posible nueva instalación y configuración.

Vamos a preparar un SO U.Server 18.04 desde cero, hasta dejarlo funcionando con varias páginas web, y alguna app.

¡¡¡Comencemos!!!

Paso 1º la primera vez que arranca nuestra máquina

Por lo general, estos servidores se suelen contratar a algún distribuidor de hosting, ya sea un servidor dedicado, un VPS (Sistema Virtual), o similares. Siempre que no hayamos sido nosotros los que hayamos realizado la instalación, nos vamos a encontrar con unos credenciales ya configurados, el password aleatorio que nos han proporcionado.

¿Cómo cambiar el password del usuario root de Ubuntu Server?

Si es así, lo primero que haremos será cambiar esas credenciales por unas que nos sean más familiares. Para ello, una vez que nos hayamos logueado en el sistema y haya arrancado, vamos a teclear los siguientes comandos:

configuracion_ubuntuserver_1

sudo su, para loguearnos con las credenciales que nos hayan dado por defecto, el final del identificador de sesión ha cambiado de $ a #, eso significa que ahora somos usuario administrador con permisos especiales.

No es recomendable cambiar el nombre de usuario que nos hayan proporcionado, ya que esto implica realizar una serie de cambios, carpetas de usuario, grupos, etc… que podrían dar problemas, mi consejo es cambiar únicamente el password por uno nuestro que tengamos bien memorizado.

Tecleamos: “passwd” y seguimos las instrucciones.

configuracion_ubuntuserver_2

OJO; esta contraseña se podría decir que es sagrada para el sistema, aseguraros bien de no perder la u olvidadla porque podría ser un gran problema…

Otro fallo muy común es que, el sistema operativo venga configurado con el teclado en inglés. Lo que significa que cuando pulsamos algunas teclas, sobre todo símbolos y caracteres especiales, éstos no funcionen y en su lugar se marquen otros distintos. Para arreglarlo hay que indicar al sistema que nuestro teclado es en castellano.

¿Cómo cambiar el idioma del teclado de Ubuntu Server?

Como siempre, logueados con usuario root, marcamos lo siguiente: “sudo dpkg-reconfigure keyboard-configuration” nos abrirá una interface gráfica como esta.

configuracion_ubuntuserver_3

Escogeremos la opción marcada en rojo, “PC genérico 105 teclas (intl)”, y con ‘tabulador’ continuaremos.

configuracion_ubuntuserver_4

Escogemos la opción marcada en rojo “Español”, ‘tabulador’ .
Y el resto de pasos, 3, los dejaremos como están por defecto, siguiendo siempre con ‘tabulador’ hasta que termine.

Una vez haya concluido y estemos de nuevo en la terminal, probaremos la tecla ñ, si la escribe es que está todo correcto y nuestro teclado listo para escribir con él en castellano.

Siguiendo con las configuraciones, otra muy común es la hora del sistema, por lo general siempre con dos horas de retraso con respecto a la hora de nuestro meridiano.
Tenemos que ajustarla

¿Cómo cambiar la hora del sistema operativo Ubuntu Server?

El comando $ date, nos va a indicar la fecha y la hora que tiene el sistema, si vemos que está mal tenemos que teclear: “dpkg-reconfigure tzdata” para que nos salga la interface gráfica de configuración.

configuracion_ubuntuserver_5

En ella, las opciones serán “Europa” > “Madrid”, el resto lo hará el sistema de forma automática. Podemos comprobar que realmente se ha ajustado con “date”

configuracion_ubuntuserver_6

Tras estos pasos, estamos casi listos para realizar la primera actualización de paquetes. Pero antes, me gusta instalar el paquete ‘aptitude’ para la gestión de paquetes, de actualización o de aplicaciones instaladas. También con una pequeña interface gráfica que nos puede ser muy útil para manejar aplicaciones o paquetes del sistema.

Tecleamos: “sudo apt-get install aptitude”

configuracion_ubuntuserver_7

Ahora sí, ya podemos proceder a actualizar primero los paquetes instalados en el sistema.
Tecleando: “aptitude update”

configuracion_ubuntuserver_8

Ya tenemos las dependencias de paquetes actualizadas, ahora vendría el paso de ‘upgrade’ que significa instalar nuevas versiones de aplicaciones o del propio sistema operativo.

Estas dos opciones suelen ser bastante seguras, pero antes de hacer un upgrade, vamos a ver cómo está configurado el sistema operativo con respecto a nuevas versiones completas del core del servidor.

¿Cómo marcar qué tipo de versiones queremos instalar en el sistema?

Esto lo podemos ver de la siguiente manera, si hacemos un list sobre la carpeta /etc/update-manager/
$ ls -la /etc/update-manager/

configuracion_ubuntuserver_9

Vemos que en su interior hay un archivo de configuración llamado ‘release-upgrades’. Este archivo es el encargado de avisarnos si hay una nueva versión del SO, o si usamos una ‘lts’ (Long Time Suport) más estable y segura.

Hay que tener en cuenta que un servidor es un sistema que ha de funcionar 24/7 365, día y noche, y que una nueva versión del SO puede traer cambios importantes en las configuraciones internas que dan servicios para la red.

Mi consejo es ese, usar la ‘lts’ para asegurarnos que no nos vamos a llevar sorpresas inesperadas por una simple actualización de paquetes.
Otra práctica que suelo utilizar, es la de hacer una copia previa a la configuración, del archivo que vaya a editar, de esa forma siempre puedo volver atrás en caso de que algo salga mal.

Para hacer esto tecleamos: “cp /etc/update-manager/release-upgrades{,.bck130519}” con la fecha al fina por si tenemos que hacer otra copia posterior.

configuracion_ubuntuserver_10

Ya tenemos copiada la versión original del archivo que vamos a manipular, así que ahora hacemos un “nano /etc/update-manager/release-upgrades”

configuracion_ubuntuserver_11

Donde tenemos que fijarnos en la última línea, ‘Prompt‘ y ver que sea igual a lts, una vez cambiada tan solo tenemos que guardar el archivo mediante “CTRL+X” > “YES” > “Enter”. Y estará listo para hacer el upgrade.

Tecleamos “aptitude upgrade -y” para poner las últimas versiones de los paquetes instalados. Dejamos que trabaje porque por lo general suele descargar una buena cantidad de datos y suele tardar un poco, dependiendo de la velocidad de conexión a Internet, más o menos tiempo.

Por último, es muy habitual que por ejemplo, contratemos un servidor de X Gigas de capacidad de disco duro, pero después en la carpeta raíz del servidor tan solo nos aparecen 4 G disponibles, esto es debido a que no están expandidas las particiones del disco, y lo tenemos que ajustar cuanto antes.

¿Cómo podemos extender el volumen lógico / en Ubuntu Server?

Para comprobar la capacidad de nuestra partición de raíz tecleamos lo siguiente: “df -h”

configuracion_ubuntuserver_13

Si nos fijamos, en mi caso la carpeta raíz está ocupando un 55% ya almacenado, y vemos que tiene una capacidad de 3,9G, algo ridículo teniendo en cuenta que el disco es de 20 G.

Hay que expandir el volumen lógico del disco para que “/” tenga la capacidad adecuada, en este caso la máxima posible. Pensemos que todo absolutamente todo lo que instalemos, creemos o configuremos va a estar bajo esa ruta raíz, bases de datos, páginas web, archivos de caché, de log, etc, etc… De esa forma, cuanto más espacio tenga más cosas podremos programar e instalar.

Para extender la partición haremos lo siguiente. Nos fijaremos en el nombre que le haya dado el sistema al Filesystem, en el ejemplo “/dev/mapper/ubuntu–vg-ubuntu–lv”
para poder teclear el siguiente comando: “lvextend -L +XG /dev/mapper/ubuntu–vg-ubuntu–lv” (donde la X será el número íntegro de Gigas que queremos incorporar)

configuracion_ubuntuserver_14

Vemos que he indicado 10G de extensión, y que se ha aplicado de forma correcta.
Ahora vamos a aplicarlo definitivamente en el disco, tecleando lo siguiente: “resize2fs /dev/mapper/ubuntu–vg-ubuntu–lv”

Tras ello volvemos a marcar: “df -h” para comprobar que realmente hemos extendido nuestro volumen lógico y nuestro directorio raíz del servidor.

configuracion_ubuntuserver_15

Vemos que ahora nuestro directorio raíz cuenta con 14G y está usando un 16% en comparación al 55% de antes.
Todo correcto.

Paso 2º Las primeras instalaciones

Hasta aquí, tenemos el sistema actualizado y versionado, nuestra propia contraseña de acceso, nuestro teclado bien configurado, y el archivo de versiones ajustado para no llevarnos sustos innecesarios, y el directorio raíz con una capacidad de almacenaje adecuada.

Ya podemos comenzar a instalar aplicaciones de servidor imprescindibles para su uso en Internet.

¿Cómo instalar el servidor Apache2 en Ubuntu Server?

Ahora vamos a instalar el paquete ‘LAMP’ (Linux Apache MySQL y PHP) para tener de verdad un servidor instalado. También un servidor DNS (Domain Name Server), un servidor SSH para poder conectarnos al servidor desde cualquier parte y un servidor de correo electrónico por si lo vamos a necesitar.

Para ello, primero vamos a instalar una miniaplicación gráfica llamada ‘tasksel’ que nos va a dar todas estas aplicaciones.

Tecleamos: “aptitude install tasksel”

configuracion_ubuntuserver_12

Una vez esté instalado, bastará con teclear: “tasksel” para que se abra la interface gráfica con la lista de aplicaciones de servidor que podemos instalar.

configuracion_ubuntuserver_16

Para seleccionar las que queramos instalar pulsaremos la tecla “Space” y se marcará con un asterisco.
Vamos a marcar las siguientes aplicaciones:

  • Ubuntu Cloud Image (instance)
  • DNS server
  • LAMP server
  • Mail server
  • OpenSSH server
  • Basic Ubuntu server

Y a marcar ‘tabulador’ > para que el sistema comience la instalación. Os pongo las capturas de pantalla con las opciones que nos va a preguntar y su significado.

1º- Configuración del servidor de correo. “Sitio de Internet” para poder ligarlo a un dominio inverso.

configuracion_ubuntuserver_17

2º – El dominio por defecto en modo local para las direcciones de correo.

configuracion_ubuntuserver_18

Por lo general suele ser igual al FQDN del servidor, (el dominio interno en local del servidor). Como todavía no hemos configurado el FQDN nos aparece el que se ve en la imagen, a mi particularmente me gusta que la terminación de los dominios locales (de testeos por ejemplo) terminen con .loc, por lo que cambiaré el .home por .loc. Más tarde cambiaré también el FQDN a .loc para que todo coincida.

Marco mvcserver.loc y le doy a .

En mi instalación no me ha preguntado nada más, se ha completado la instalación al 100% y he vuelto al promp del sistema. Aun que ahora tengamos que configurar las aplicaciones que hemos instalado. Eso lo veremos más adelante.

A continuación, vamos a revisar la configuración del ‘hostname’ de la máquina.

¿Cómo configurar el hostname de Ubuntu Server?

El hostname, es el nombre que tendrá nuestro servidor dentro de la red interna o local, de esa forma lo podremos identificar por ejemplo en configuraciones de redes o lands.
Para ver el hostname que tenemos actualmente tecleamos: “hostname” y nos devolverá el nombre del servidor dentro de la red.

Yo voy a cambiarlo a tutorialserver para que me sea más fácil identificarlo dentro de la lan. Para poder hacer esto tenemos que editar un archivo alojado bajo “/etc/hostname”, podemos ver su contenido marcando: “cat /etc/hostname”

configuracion_ubuntuserver_19

Como siempre antes de editar su contenido realizo una copia de respaldo del archivo original: “cp /etc/hostname{,.bck130519}”
Después lo edito con: “nano /etc/hostname” y borro el contenido ‘mvcserver’ y escribo el nuevo hostname ‘tutorialserver’, “CTRL + X” > “Yes” > “Enter”.
A continuación tenemos que marcar el siguiente comando: “sudo hostnamectl set-hostname tutorialserver” con el nuevo hostname al final del comando.
Para terminar, tenemos que cambiar un parámetro del archivo “/etc/cloud/cloud.cfg”,
hacemos la backup del archivo: “cp /etc/cloud/cloud.cfg{,.bck130519}” y lo editams con “nano /etc/cloud/cloud.cfg”
Buscaremos
preserve_hostname: false
Cambíandolo por
preserve_hostname: true
Cerramos la sesión de usuario root con “exit” y volvemos a loguearnos con “sudo su” para ver que se ha cambiado el nombre del host.

configuracion_ubuntuserver_20

Una vez ajustado el nombre del host nos falta ajustar el FQDN (Fully Qualified Domain Name) Se trata del nombre de dominio interno que tendrá el servidor para resolver llamadas en la red local al dominio interno del servidor.

El FQDN se encuentra alojado bajo “/etc/hosts” si vemos su contenido con: “cat /etc/hosts”

configuracion_ubuntuserver_21

Para configurarlo de forma adecuada y siguiendo las anteriores configuraciones, tendremos que ver la ip interna que nos ha asignado nuestro router. Tecleando: “ifconfig”

configuracion_ubuntuserver_22

Vemos que la interface ‘ens33’ que proporciona la conexión, marca la ‘inet’ 192.168.1.63, esa es la ip que debemos anotar. También es buena práctica entrar en la configuración del router, normalmente bajo 192.168.1.1, para indicar que esa ip y esa máquina van a tener la dirección interna estática, de esa forma la ip no cambiará cuando apaguemos y encendamos de nuevo el router, si no sabéis cómo hacerlo siempre podéis llamar al proveedor de Internet de turno y preguntarle que cómo se puede marcar una ip interna estática para uno de vuestros equipos conectados, seguro que con gusto os lo explican paso a paso.

Ahora que sabemos la ip, como siempre, copia de respaldo del archivo de configuración, “cp /etc/hosts{,.bck130519}”, y a continuación lo editamos con “nano /etc/hosts”.
Añadimos la ip junto con el nuevo FQDN para esa ip interna.

configuracion_ubuntuserver_23

Justo en la 3º línea, y como siempre “CTRL + X” > “Yes” > “Enter”.
A partir de ahora si abrimos un navegador en cualquier dispositivo (tanto móviles como pcs) y tecleamos la url ‘http://tutorialserver.home’ veremos que nos carga la página por defecto de Apache2, indicando que el servidor está en funcionamiento y que todo ha salido bien.

configuracion_ubuntuserver_24

Para terminar esta primera parte del tutorial de configuración de Ubuntu Server desde cero, vamos a realizar unas comprobaciones de resoluciones de red para asegurarnos que nuestra máquina es capaz de resolver direcciones ip, direcciones con nombre de dominio externo e interno.

¿Cómo hacer comprobaciones de red con Ubuntu Server?

Vamos a hacer una serie de ‘pings’ con el envío de 5 paquetes hacia diferentes resoluciones para ver que en todos ellos nos devuelva un envío exitoso y sin pérdida de paquetes.

1º – Ping hacia el localhost, hacia la propia máquina.
Comando “ping -c 5 localhost”

configuracion_ubuntuserver_25

2º – Ping hacia nuestro loud pack, ip interna del servidor.
Comando “ping -c 5 127.0.0.1”

configuracion_ubuntuserver_26

3º – Ping hacia nuestro hostname interno.
Comando “ping -c 5 tutorialserver”

configuracion_ubuntuserver_27

4º – Ping hacia nuestro FQDN interno.
Comando “ping -c 5 tutorialserver.home”

configuracion_ubuntuserver_28

5º – Ping hacia nuestra ip interna
Comando “ping -c 5 192.168.1.63”

configuracion_ubuntuserver_29

6º – Ping hacia una ip proxy externa
Comando “ping -c 5 4.2.2.2”

configuracion_ubuntuserver_30

7º – Ping hacia una url externa, nombre de dominio
Comando “ping -c 5 http://www.comercialseo.es”

configuracion_ubuntuserver_31

Y con esto hemos concluido y comprobado que nuestro servidor es capaz de resolver tanto ips internas como externas, el hostname, el fqdn, los nombres de dominio, etc…
Importante a la hora de instalar aplicaciones para asegurarnos que no van a fallar en las conexiones que realicen en la red interna, en Internet, o en la propia máquina.


Terminamos aquí esta primera entrega de la configuración del servidor de Ubuntu desde cero hasta dejarlo funcionando con páginas web en Internet, con apps, bases de datos, etc…

Espero que sea de vuestro interés, seguimos pronto. Si tenéis cualquier duda podéis escribir un comentario para que la pueda resolver.

Gracias por la lectura.

WordPress como gestor de contenidos CMS Ventajas y Carencias

Después de más de 10 años en el mundo de la programación del lado del servidor y en general de códigos para la web, cuando nos llamábamos felizmente webmasters y con eso valía para dejar claro nuestro perfil laboral, de haber crecido junto al PHP y MySQL, de haber creado mini gestores de contenidos en la época en la que tener una web con base de datos y zona de administración era como tener un unicornio alado, de conocer la estructura interna y cómo funciona cualquier sistema relacionado a los servidores Apache y de haber utilizado casi la totalidad de frameworks y plataformas de la red. Creo  que estoy en condiciones de hablar sobre uno de esos  sistemas, el que más me atrae en la actualidad y uno de los más demandados, estamos hablando como no de WordPress.

Empecemos por el gran número de ventajas que posee este gestor de contenidos CMS que todos conocen y utilizan:

  1. Lo más importante, código OpenSource con una de las comunidades de desarrollo más grandes del planeta
  2. Documentación online en el codex sobre cualquier aspecto relacionado tanto con su manejo como con su estructura interna de programación
  3. Costes CERO o prácticamente CERO por cualquier implementación o ampliación de arquitectura
  4. Infinidad de plugins, complementos, tutoriales y apoyos para realizar practicamente cualquier acción dentro de nuestro sitio web
  5. Facilidad en desarrollo y posibilidad de ampliar la gran biblioteca de códigos ya existente
  6. Posibilidad de comercialización de diseños y programaciones específicas para la plataforma
  7. Continuo apoyo en actualizaciones de seguridad, rendimiento  y herramientas
  8. Facilidad de uso por usuarios con poca experiencia en el uso general de Intenet

Pero no todo van a ser ventajas, también tiene sus puntos débiles que pasamos a enumerar así:

  1. Grandes problemas de rendimiento y sobre carga de archivos de estilos y programaciones js
  2. Problemas de inseguridad en cada una de las distintas versiones que van saliendo, al ser uno de los gestores de contenidos más utilizado en la red, también es uno de los más vulnerables a ataques maliciosos ya que son un blanco fácil para este tipo de hackers
  3. Problemas en tiempos de carga de los sistemas wordpress
  4. Inerface de administración o dashboard muy mal programada o construida, es lenta, poco intuitiva y encima con un diseño lamentable
  5. Facilidad a la hora de reconocer que una web está programada y diseñada con wordpress, cuando ves uno, los has visto todos
  6. Mala fama entre en el mundo profesional por su trayectoria  errática y poco clara, primero fue un foro, después una herramienta para crear de forma sencilla tu propio blog, y ahora un completo framework de trabajo con el que puedes hacer practicamente lo que se te ocurra
  7. Dificultad para hacer que los motores de búsqueda reconozcan que tu web tiene más calidad técnica que las demás

Y para terminar diremos que naturalmente, otro de los puntos buenos que tienen los sistemas de wordpress es que son totalmente programables y configurables, de esa forma un buen desarrollador no tendría que tener mucha dificultad en corregir los 7 puntos negativos que hemos escrito sobre WP, de hecho uno de nuestros servicios en https://www.comercialseo.es/  es ese, el de hacer completas auditorías, de usabilidad, seguridad y rendimiento de sistemas wordpress y corregir las posibles carencias que encontremos.

 

 

Seguridad en WordPress

Muy buenas a todos, voy a crear esta entrada para que sirva como índice de seguridad para WordPress, siempre que queramos dejar una instalación de wordpress totalmente segura y reforzar de esa forma las capas de seguridad que posee ya de por sí este framework de trabajo. Ya sea por que estemos controlando una tienda online o base de datos sensible, por ejemplo, o por que queramos tener la máxima seguridad en nuestro sistema, seguro que encontraremos interesantes algunos de los puntos que se van a detallar a continuación.
Comencemos!

Antes de realizar ninguna de las acciones que muestro a continuación es importante que realices una copia de seguridad de todo el árbol de archivos de tu página web y de la base de datos, la base de datos compímela en .zip o .gzip, no tienen por que pasar nada pero puede haber incompatibilidades con plugins o themes y de esa forma siempre vamos a poder volver al punto de partida si esto ocurre.

Las cifras de WordPress en 2013

uso-cmsEl fundador del proyecto WordPress hacía públicas las cifras a finales del 2013 sobre el uso y expansión del mismo y la verdad que son totalmente abrumadoras, más de 69Millones de web’s en todo el mundo funcionan con wordpress, lo que supone el 19% del total de páginas del planeta, con más de 10.000 temas disponibles y más de 25.000 plugins en funcionamiento y a nuestra disposición.

Esta posición de clara ventaja con respecto al resto hacen que wordpress sea el CMS con más apoyo a la comunidad del momento, con miles de desarrolladores trabajando en su código y mejoras pero también tiene un lado negativo, es uno de los más atacado por hackers y lammers, al ser como hemos dicho uno de los más usados.

Bien, existen formas para poner trabas a esos posibles malintencionados visitantes, o por lo menos para complicarles las cosas todo lo que podamos como vamos a ver a continuación.

Riesgos potenciales en WordPress


A diferencia de lo que pueda parecer, lo que hace más vulnerable a un sistema wordpress por lo general suelen ser factores ajenos al propio wordpress, por ejemplo.
La seguridad y calidad del hospedaje o servidor en el que esté instalado representa un riesgo de potencial magnitud, y es el principal agujero por el que se van a poder colar en nuestro sistema, por ese motivo serán siempre más fiables los hospedajes de pago con uno niveles de seguridad aceptables que los gratuitos.
Otro punto muy importante será tener el sistema, themes y plugins siempre actualizados ya que cada nueva vulnerabilidad que se descubre por lo general se corrige con una actualización, si alguien conoce las vulnerabilidades de alguna versión en concreto de estos elementos y estamos usando esa misma versión va a tener las puertas abiertas y es algo que debemos controlar.
Otro riesgo potencial sería el de la inyección de código fuente en nuestro sistema a través de alguno de los formularios existentes en el mismo, esto se puede tapar en gran medida haciendo prácticamente imposible la inyección de código como veremos después.
Por último, el acceso al sistema por medio de ataques de fuerza bruta será otro punto a vigilar, estos ataques son por medio de repeticiones e intentos constantes de acceder con nuestra contraseña, es por ello que esta deberá ser siempre lo más robusta posible reduciendo así la posibilidad de que el atacante la descubra.

El prefijo de las tablas en WordPress


Lo primero que hará un atacante para ver si puede manipular nuestro sistema será ver si conoce el prefijo de las tablas de mysql que tenemos instaladas, durante la instalación de WP este nos brinda la posibilidad de cambiar ese prefijo en el archivo wp-config.php concretamente en la línea de código nº62
$table_prefix  = ‘wp_’;
Ahí es importante que cambiemos ese código por algo como lo siguiente

$table_prefix  = ‘wp_Wb1’;
O lo que queramos después del wp_ o incluso sin el wp_ podemos poner un prefijo cualquiera por ejemplo:

$table_prefix  = ‘Wb1_’;
De esa forma será más difícil conocer el nombre de nuestras tablas en mysql y en consecuencia de poder inyectar código en nuestra base de datos o incluso de manipular alguno de los registros.

Si ya teníamos instalado el sistema y no cambiamos el prefijo lo podemos cambiar de forma sencilla con este plugin:
https://wordpress.org/plugins/db-prefix-change/

Tras cambiar el prefijo podemos desinstalar y borrar el plugin para que quede totalmente sellado y no se pueda ver lo que hemos hecho.

Las claves de encriptación del sistema WP


Del mismo modo, cuando realicemos una instalación nueva de WP será muy importante cambiar las claves de encriptación del mismo para que sea prácticamente imposible que puedan encriptar las mismas contraseñas y datos sensibles que estemos usando.
Esto lo podemos hacer antes de realizar la instalación en el archivo wp-config.php, en la línea nº 45 vemos que tenemos un comentario que dice:
* Claves únicas de autentificación.
Bien las líneas de código que se encuentran un poco más abajo son precísamente esas claves:

define('AUTH_KEY', 'pon aquí tu frase aleatoria'); // Cambia esto por tu frase aleatoria.
define('SECURE_AUTH_KEY', 'pon aquí tu frase aleatoria'); // Cambia esto por tu frase aleatoria.
define('LOGGED_IN_KEY', 'pon aquí tu frase aleatoria'); // Cambia esto por tu frase aleatoria.
define('NONCE_KEY', 'pon aquí tu frase aleatoria'); // Cambia esto por tu frase aleatoria.
define('AUTH_SALT', 'pon aquí tu frase aleatoria'); // Cambia esto por tu frase aleatoria.
define('SECURE_AUTH_SALT', 'pon aquí tu frase aleatoria'); // Cambia esto por tu frase aleatoria.
define('LOGGED_IN_SALT', 'pon aquí tu frase aleatoria'); // Cambia esto por tu frase aleatoria.
define('NONCE_SALT', 'pon aquí tu frase aleatoria'); // Cambia esto por tu frase aleatoria.

Donde dice ‘pon aquí tu frase aleatoria’ es donde debemos colocar los caracteres que formen cada una de las llaves de encriptación, WP nos ofrece la posibilidad de generar estas de forma automática desde Internet siendo mucho más seguras al estar formadas por números, caracteres y símbolos, desde la url
https://api.wordpress.org/secret-key/1.1/salt/
Podemos generarlas, si entramos vemos que lo único que aparece en esa pantalla es lo siguiente:

define('AUTH_KEY',         'S:RO+p?Vx4r`co} TdK`(!HZ<+O_4EtanF0d_o/*4%-N-!44rgkr_&se/}W`5EU>');
define('SECURE_AUTH_KEY',  'aN]s=3F1{~!5=zeza#&):oJZM+_KVNmI&6sD!1&||^QD)g~@S(b{N3t|}qIO+Bj-');
define('LOGGED_IN_KEY',    '&pao4+ nD()~lWANorO~|(mXS>UOirdxryrN+np{-vOs~< ,Z9bS?eH+H]aXu4@ ');
define('NONCE_KEY',        'z[vq.;Z,PB/1|#(Syw_:|O9h@q,BbatwFuyzz@b9QaO)ot:W@.GQ@D+ttb8{dokD');
define('AUTH_SALT',        'u]MTiVc6u}^b7QWlvlLk#T0R<,>f1MAdfJepd (p(1 j_|*h8B&zAPl.rbm|{etu');
define('SECURE_AUTH_SALT', '`YS*RQ33184I-~o>=_z9wSKLpOPz!ZB09!rm$F3MoxM[h+4/!S6]$; MEf,m.hD8');
define('LOGGED_IN_SALT',   'tV(*7pHiwW%Uu}uy4q:{Flylg47b}q&jFx{|#g-l7xcN0dcUrPTe{*J1$|!^NG-,');
define('NONCE_SALT',       '{~e9.eP}<fpLde|>`V;x.0K3Qf,>F+lCsE0@cF~heP9QP3C=ewp,/>PG4NkP;Y=!');

Basta con sustitutir unas por otras y ya lo tenemos.

Archivos innecesarios en WordPress que debes elimiar


Existen algunos archivos innecesarios que debemos eliminar tras una instalación de wordpress y después de alguna actualización del core del sistema, veamos cuales:

install.php
Este archivo que se encuentra en la carpeta de wordpress /NombreDeCarpetaDelHosting/wp-admin/ es el que usa el sistema cuando realiza una instalación nueva y cuando realiza actualizaciones, pero es importante que si por ejemplo el servidor de bases de datos se encuentra caído, el primer usuario que entre en la página va a tener a su alcance la interface de instalación de WP y podría causarnos algún problema si rellena todos los datos e intenta realizar la instalación de nuevo. Lo mejor es eliminarlo y proteger después las posibles nuevas creaciones del mismo.
Para eliminarlo basta con acceder a la carpeta y borrar el archivo /NombreDeCarpetaDelHosting/wp-admin/install.php, no hay ningún problema después para posibles actualizaciones lo que vamos a hacer en lugar de estar siempre entrando y borrándolo será protegerlo para que no lo pueda usar ningún visitante de la web.
Para protegerlo haremos lo siguiente, crearemos un archivo .htaccess con el siguiente código dentro de la carpeta /NombreDeCarpetaDelHosting/wp-admin/

<Files .htaccess>
order allow,deny
deny from all
</Files>

<Files install.php>
order allow,deny
deny from all
</Files>

De esa forma aunque se vuelva a crear no será accesible por nadie excepto por el propio servidor de datos.

wp-config.php y wp-config-sample.php
Los archivos de configuración de WP los puedes encontrar en la carpeta general de WP /NombreDeCarpetaDelHosting/ son unos de los más importantes, ya que contienen las claves de encriptación de nuestro sistema y las de conexión con la base de datos, de vital importancia que estos datos no puedan ser accesibles nada más que por el administrador y el propio sistema. El segundo wp-config-sample.php si está en el servidor lo mejor será borrarlo por si tiene los datos reales, no es necesario que esté allí, el primero wp-config.php no lo borraremos bajo ningún concepto, en su lugar protegeremos su acceso y restringiremos sus permisos de la siguiente manera.
Crearemos un archivo .htaccess en la carpeta general /NombreDeCarpetaDelHosting/ o, en caso de que este archivo ya exista incluiremos el siguiente código al final del mismo:

<Files .htaccess> 
order allow,deny deny from all 
</Files>

<Files wp-config.php>
order allow,deny
deny from all
</Files>

readme.html
Este archivo se encuentra en la carpeta raíz del sistema /NombreDeCarpetaDelHosting/ y es totalmente inecesario, es más lo único que podría hacer es mostrar a un posible atacante la versión de WP que tenemos instalado en nuestro sistema, algo que si podemos es mejor que tratemos de evitar, lo eliminaremos sin ningún problema

Protección de archivos y carpetas del sistema WP

Las carpetas y archivos del sistema también deben tener los permisos a nivel de servidor bien configurados, los permisos que debemos mirar son estos:

– Los permisos de la carpeta raíz o general de WordPress deben ser 0755

– Los permisos de archivos:

<<.htaccess>> 0644
<<.readme.html>> 0440 (aunque este archivo como hemos dicho lo mejor es borrarlo también)
<<wp-config.php>> 0644

– Los permisos de las carpetas del sistema:

<<wp-admin>> 0755
<<wp-content>> 0755
<<wp-includes>> 0755
<<wp-content/plugins>> 0755
<<wp-content/uploads>> 0755

Con estos permisos bien asignados estamos protegiendo de mejor manera nuestro sistema.

Roles de usuarios y usuario Super Admin


Es importante que sepamos cómo gestiona WP los permisos o roles de usuarios, en concreto existen cuatro tipos de usuarios en el sistema, cada uno con diferentes tipos de permisos:

Usuario Super Administrador
Este usuario por lo general suele ser el primero que se crea durante la instalación del sistema y es el que más permisos tiene dentro del mismo, tiene todos los permisos que existen, en consecuencia, es el que más tenemos que proteger y con el que más cuidado tenemos que tener.
Como primera medida de protección está la de poner un nombre de usuario específico y creado por nosotros mismos, no vale eso de llamarle por ejemplo admin ya que será muy obvio y nos podría dar problemas después.
Como segunda medida está la de poner una contraseña robusta para evitar ataques de fuerza bruta, una buena contraseña ha de estar formada por números, caracteres y si es posible algún signo.
También es interesante que en las opciones del perfil de usuarios marquemos como nombre visible el nombre y apellidos que hayamos puesto en el formulario, nunca el nombre de usuario que es el que suele dejar WP por defecto, si no lo cambiamos cuando comentemos algo o en el apartado autor de entrada se podrá ver el nombre de usuario y un atacante ya sabrá el 50% de nuestros datos de acceso al sistema. Para cambiar esto basta con ir a Usuarios > Mi perfil y cambiar donde dice:

WpSeguridadElBlogDeMiguelAngel

Administradores
Los usuarios administradores poseen prácticamente los mismos permisos que el SuperAdmin, por ello es preciso que sólo sean administradores aquellos usuarios que realmente puedan trabajar a nivel de programación y edición en la web, si por ejemplo damos de alta como administrador a un autor, este después será capaz de cambiar contraseñas y de administrar algunos puntos delicados del sistema, lo mejor es dar a cada usuario los permisos justos para evitar problemas innecesarios.

Editores
Los perfiles editores son muy interesantes, dado que van a poder controlar internamente los contenidos que muestra la web sin poder acceder a configuraciones o administración de la web, un usuario que no tenga que hacer cambios en diseño o programación pero que sí pueda borrar páginas o cambiar contenido de las mismas debería ser editor de la web.

Autores
Los autores van a tener los mismos permisos que los editores pero sólo en el contenido que hayan creado ellos mismos, no en el de los demás, y sólo en contenido relacionado con entradas o post, nunca en las páginas, enlaces, y demás contenido que puede mostrar WP.

Contribuidores
Los usuarios contribuidores bajo mi punto de vista no deberían existir, están ahí por si queremos dar la opción de que un usuario pueda leer entradas creadas por otro y editar estas entradas o borrarlas, nunca las podrán crear ellos mismos, en concreto los permisos que tendrán serán los de editar, borrar y leer entradas. Como digo es un perfil que no tiene mucho sentido.

Suscriptores
Por último el suscriptor, este perfil lo único que va a permitir es leer entradas o contenidos protegidos por login, es útil si por ejemplo tenemos contenido en la web que puede ser accedido sólo por usuarios que hayan hecho login, estos usuarios tendrán la opción de hacer login y ver los contenidos protegidos por el registro de usuarios, y nada más, no podrán ni crear contenidos y editarlos ni borrarlos.

Si queréis ver más sobre los permisos de usuarios os dejo este enlace en el que están detallados todos los permisos que posee cada tipo de perfil:
http://codex.wordpress.org/Roles_and_Capabilities

También existe un plugin muy útil para aún con los permisos que hemos visto que tienen los usuarios, poder jugar con más características o profundizar más en las capacidades que tendrá cada uno de ellos, yo en concreto lo utilizo mucho para por ejemplo aún siendo Editor del portal un usuario, que este no pueda crear nuevas categorías de post o no tenga acceso a los perfiles del resto de usuarios.
El plugn es Adminimize y aunque en principio pueda parecer que es muy complicado o extenso, si nos fijamos, veremos de forma clara qué es cada uno de los permisos y cómo concederlos o denegarlos, bastará con marcar o no la casilla en la columna del tipo de usuario que deseemos. Un apunte más, si desactivamos los permisos para los usuarios Administradores, estos desaparecerán para los administradores pero no para el SuperAdmin, de esa forma podemos cortar permisos de administradores sin que se pierdan con nuestro usuario SuperAdmin.

Protección de acceso al sistema y ruta de acceso


Atención, esta información sólo será útil en caso de que tu WP tenga el acceso básico que trae por defecto, si estás usando algún plugin como wp-mylogin o similares, o tu theme ya trae incorporado una interface de login personalizada deberás comprobar que los ajustes se adaptan a tu theme o plugins.

Protección de acceso al sistema
WP tiene dos detalles que corregir en cuanto a seguridad en el acceso al panel de administración o sistema de login, uno, el de protección de ese acceso al sistema, nos indica que por defecto, la información que nos muestra en el panel de login cuando marcamos mal algún dato, ya está indicando qué parte es la que está incorrecta.

Seguridad WordPress
Seguridad WordPress

A demás no limita de ninguna forma el número de intentos de login que un visitante puede realizar, esto para la protección de ataques por fuerza bruta se puede corregir de forma sencilla instalando y limitando esos accesos con el plugin Login lockdown, una vez instalado y activo podemos configurar estas opciones en Ajustes > Login LockDown.

WP LockDown
WP LockDown

Esa sería una buena configuración para tener ese bug corregido, el plugin no tiene archivo .po de traducciones y en caso de que algún aviso aparezca en inglés tendremos que traducir esos strings directamente desde el código fuente del archivo: WPContent/Plugns/login-lockdown/loginlockdown.php siempre y cuando tengamos conocimientos de php, el archivo tiene un código bastante sencillo.

Ocultación de ruta de acceso
Otra capa más de seguridad sería la de cambiar la ruta de acceso a nuestro sistema, siempre que está no esté ya personalizada en una url específica, para comprobar esto lo mejor es escribir directamente una de estas dos direcciones url:

http://www.tunombrededominio.es/wp-login
http://www.tunombrededominio.es/wp-admin

Si nos carga la página de login del sistema estaremos dando pistas sobre qué tipo de CMS estamos utilizando y qué página es la que tienen el formulario de entrada al panel de administración, ya que las rutas wp-login y wp-admin son conocidas por cualquier atacante que quiera probar si están disponibles.
Lo mejor para corregir esto es cambiar esas direcciones url por una personalizada por nosotros mismos, para ello una vez más utilizaremos la ayuda del plugin gratuito HC Custom WPAdmin URL

Tras instalarlo y activarlo iremos a Ajustes > Enlaces permanentes y en la casilla que pone:

WPAdminSlug

 

Escribiremos el slug para la url de acceso que queramos poner por ejemplo http://www.nombrededominio.es/acceso-seguro de esa forma no se podrá saber qué dirección url es la que da acceso al panel de login del sistema.

Borrar sistema y versión de WordPress de cara al visitante

Por otro lado es mejor que nadie sepa qué versión usamos de WP y si es posible que tampoco sepan ni siquiera que estamos usando WP para trabajar con los contenidos de nuestra página.
Un paso para ocultar estos datos ya lo hemos hecho borrando el archivo readme.html, pero si vemos el código fuente de la página de inicio por ejemplo encontraremos en el apartado <head> del documento dos líneas de código que muestran la versión de WP que se está usando en la página:

<meta name=”generatorcontent=”WordPress 4.0” />
 <meta name=”generatorcontent=”WooCommerce 2.2.8” />

Para evitar que se muestren estas metas podemos hacerlo introduciendo código php en el archivo functions.php de nuestro theme, para hacerlo abrimos el archivo NombreDeDominio/wp-content/themes/NombreDeNuestroTheme/functions.php y al final del mismo incluimos estas las siguientes líneas de código:

/*Mis Funciones*/
remove_action('wp_head', 'wp_generator');
remove_action('wp_head', 'woocomerce_generator');
remove_action('wp_head', 'wlwmanifest_link');
remove_action('wp_head', 'rds_link');

Con esto estaremos ocultando las versiones de WP y WooComerce (en caso de que estemos usando ese plugin de comercio electrónico) del código fuente de las páginas de nuestro dominio.

Proteger el listado de directorios

</span
Debemos evitar que un usuario / visitante pueda ver el listado de directorios dentro de nuestro dominio, esto es, evitar que puedan ver la configuración de carpetas y archivos que tiene nuestro dominio, WP ya trae una funcionalidad muy elegante y sencilla para poder evitar esto, si nos fijamos, siempre que una carpeta de nuestro directorio no contiene ningún archivo, WP inserta ahí un archivo index.php en blanco, de esta manera evita que ese directorio se pueda listar a través de un navegador o interface de comandos, no está demás echar un vistazo a las carpetas de plugins para ver si todos los directorios sin archivos (solo con carpetas) lo traen y en caso de que no esté crear nosotros un index.php en blanco para que cargue ese archivo y no los directorios si escriben la url del directorio en el navegador.

seguridadwp3

 

Una de las carpetas donde lo podemos incluir es en wp-content/languages y wp-content/uploads.

Otra acción que podemos realizar para evitar esto es incluir en el archivo .htaccess de la carpeta raíz del directorio el código

Options All -Indexes

En la parte inferior del mismo, también para poner un obstáculo más a la hora de poder listar el contenido de nuestras carpetas.

Archivo robots.txt de WordPress


Podemos crear un archivo robots.txt mucho más robusto y restrictivo si le incluimos los siguientes permisos para buscadores y arañas de Internet:

Se puede utilizar el plugin WP Robots TXT una vez esté instalado vamos a Ajustes > Lectura y vemos que nos ha creado un cuadro de texto llamado Robots Content, ahí podemos escribir lo siguiente:

User-agent: MSIECrawler
Disallow: /

User-agent: WebCopier
Disallow: /

User-agent: HTTrack
Disallow: /

User-agent: Microsoft.URL.Control
Disallow: /

User-agent: libwww
Disallow: /

User-agent: *
Disallow: /cgi-bin/
Disallow: /wp-content/cache/
Disallow: /wp-content/themes/
Disallow: /comments/
Disallow: /category/*/*
Disallow: */feed/
Disallow: */comments/
Disallow: /*?
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/
Disallow: /wp-includes/
Disallow: /wp-admin/
Disallow: /?s=
Disallow: /search
Disallow: /wp-
Disallow: /feed/
Disallow: /comments/feed
Disallow: */feed/$
Disallow: */feed/rss/$
Disallow: /trackback/
Disallow: */trackback/ $
Disallow: */*/feed/$
Disallow: */*/feed/rss/$
Disallow: */*/trackback/$
Disallow: */*/*/feed/$
Disallow: */*/*/feed/rss/$
Disallow: */*/*/trackback/$
Allow: /wp-content/uploads/

User-agent: noxtrumbot
Crawl-delay: 50

User-agent: msnbot
Crawl-delay: 30

User-agent: Slurp
Crawl-delay: 10

# Google Image
User-agent: Googlebot-Image
Disallow:
Allow: /*

# Google AdSense
User-agent: Mediapartners-Google*
Disallow:
Allow: /*

# Internet Archiver Wayback Machine
User-agent: ia_archiver
Disallow: /

# digg mirror
User-agent: duggmirror
Disallow: /
# Sitemap permitido, búsquedas no.
Sitemap: http://www.nombrededominio.com/sitemap_index.xml

Evitar la inyección de código SQL


Podemos evitar en parte la inyección de código en nuestra base de datos en gran medida de dos formas.

Mediante el archivo .htaccess de la carpeta raíz del directorio, escribiendo justo al final estas líneas de código:

# Inyecciones sql
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]
RewriteCond %{QUERY_STRING} (;|<|>|’|”|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|cast|set|declare|drop|update|md5|benchmark) [NC,OR]
RewriteCond %{QUERY_STRING} \.\./\.\. [OR]
RewriteCond %{QUERY_STRING} (localhost|loopback|127\.0\.0\.1) [NC,OR]
RewriteCond %{QUERY_STRING} \.[a-z0-9] [NC,OR]
RewriteCond %{QUERY_STRING} (<|>|’|%0A|%0D|%27|%3C|%3E|%00) [NC]
RewriteRule .* - [F]

Mediante la denegación a scripts desde el archivo functions.php de nuestro theme activo, para eso abrimos el archivo /nombredeldominio.com/wp-content/themes/nombredelthemeactivo/functions.php, y escribimos esta línea al final del todo:

add_filter('pre_comment_content','wp_specialchars');

Después no se podrán por ejemplo escribir enlaces ni ningún tipo de código fuente en los formularios de los comentarios.

Los números de 2013

Los duendes de las estadísticas de WordPress.com prepararon un informe sobre el año 2013 de este blog.

Aquí hay un extracto:

La sala de conciertos de la Ópera de Sydney contiene 2.700 personas. Este blog ha sido visto cerca de 50.000 veces en 2013. Si fuera un concierto en el Sydney Opera House, se se necesitarían alrededor de 19 presentaciones con entradas agotadas para que todos lo vean.

Haz click para ver el reporte completo.

Nuevo documental Derren Brown: Los Experimentos (Ep. 1) – El Asesino

Hola a todos/as.
Seguimos con los documentales dedicados al control mental, la hipnosis y en general las habilidades de mentalista tan interesantes y poco habituales.
En esta ocasión vamos a ver un documental del dicovery-max Derren Brown: Los Experimentos (Ep. 1) – El Asesino.
Tratan sobre el propio  Derren Brown (mentalista) y la experimentación con los poderes de la mente y de los individuos y de como ejerciendo un determinado control mental podemos llegar a hacer que la gente haga cosas inesperadas por completo o que en condiciones normales jamás harían.
Espero que os guste.

 

Messiah (Derren Brown special)
Messiah (Derren Brown special) (Photo credit: Wikipedia)

¿Cómo ajustar la nitidez del fondo de nuestras fotografías digitales?

Hola a todo el mundo.
Voy a crear esta entrada para explicar como podemos seleccionar qué partes de la fotografía queremos que se vean nítidas y cuales no dentro de nuestras composiciones fotográficas. De esta forma vamos a poder elegir siempre si queremos que por ejemplo el fondo de una composición se vea nítido, difuminado o borroso para dar mas protagonismo a la composición de primer plano.

¿Cómo podemos seleccionar qué partes se quedan nítidas y cuales no..?
Bien, esto lo podemos conseguir gracias a la selección de enfoque y al control de la apertura del diafragma de nuestra cámara digital.
Lo primero que tenemos que hacer es comprobar que tipo de enfoque estamos utilizando, ya que este ha de ser por lo general manual para primeros planos y automático para fotografías panorámicas, modos AF y MF.

Vamos a tener la posibilidad de asignar las zonas en las que deseamos que tenga acción el enfoque de nuestra cámara gracias a la apertura del diafragma de la cámara digital, a mayor apertura de este mayor será también el punto de enfoque que capte y menor la nitidez del fondo de la fotografía.
Por ejemplo, imaginemos que deseamos tomar una fotografía de un paisaje en una montaña,  el valor adecuado para la apertura del diafragma tendría que ser alto a partir del F16, para lograr captar la mayor nitidez en toda la imagen.

Podemos ver este efecto con estos ejemplos:

Podemos ver que a mayor es la apertura menor es la nitidez que capta en el fondo de la fotografía. Creo que con los ejemplos está bastante claro el efecto.

A partir de ahora cuando realices una nueva fotografía en primer plano vas a poder escoger entre otras muchas opciones, si deseas que el fondo de la imagen se vea nítido, difuminado o directamente borroso para dar mayor protagonismo al primer plano de la composición.

Gracias por la lectura.
Saludos.