Instalar el editor de texto Nano

por el en la categoría Aplicaciones

Cuando queremos modificar algún fichero de configuración desde la consola, utilizamos un editor de texto. Por defecto los sistemas Linux llevan instalado el editor Vi o Vim. Utilizando alguno de estos editores se pueden todos los cambios que necesitemos en los ficheros de configuración de las aplicaciones instaladas en nuestro servidor.El principal problema es su aspecto poco amigable y la multitud de combinaciones de teclas que necesitamos para por ejemplo guardar el fichero. Estas caracteristicas provocan que muchos usuarios busquen alternativas.

Uno de los editores mas utilizados es Nano, ya que se nos muestra en una pequeña barra inferior las teclas a utilizar para realizar las principales acciones.

Si deseas instalar Nano en tu servidor, en el caso de tener un servidor Centos, deberás hacer lo siguiente:

yum install nano

En el caso de contar con un servidor basado en Debian, teclea:

sudo apt-get install nano

Tras unos segundos, ya tendrás el editor Nano listo para ser utilizado.

Instalar el editor de texto Nano

Cual es la diferencia entre Telnet y SSH

por el en la categoría Seguridad, VPS

Cual es la diferencia entre Telnet y SSHEn muchos de los artículos que os mostramos es necesario acceder a nuestro servidor de manera remota y realizar una serie de acciones. Por lo general siempre utilizamos una conexión SSH para realizar estas acciones. Pero, ¿por qué utilizamos SSH en lugar de Telnet? ¿Cual es la diferencia entre estos dos protocolos?

Aparentemente utilizar SSH o Telnet es prácticamente lo mismo. Utilizamos estos protocolos para conectarnos de manera remota a nuestro servidor, para realizar las tareas de mantenimiento que necesitemos.

Por lo general, y si no hemos cambiado la configuración de nuestro servidor, al acceder utilizaremos el puerto 22 si utilizamos SSH y el puerto 23 al conectarnos por Telnet. En ambos casos necesitamos un nombre de usuario y una contraseña para acceder y por supuesto, que el servidor acepte dichos protocolos.

¿Cual el la diferencia? Pues principalmente la seguridad. Con SSH utilizamos una conexión segura hacia nuestro servidor, con lo que la información viaja encriptada. En cambio, utilizando Telnet exponemos toda la información que intercambiamos con el servidor, con el consiguiente riesgo que esto supone. Es por esto que SSH ha sustituido al protocolo Telnet.

Nuestra recomendación si aún utilizas Telnet, es que cambies a SSH que es mas seguro y así evitas que otros usuarios “escuchen” la información que intercambias con el servidor. Y si quieres mejorar aún mas tu conexión SSH, te recomendamos nuestro artículo Securiza tu VPS cambiando el puerto de SSH

Securiza tu VPS cambiando el puerto de SSH

por el en la categoría Seguridad, VPS

Securiza tu VPS cambiando el puerto de SSHEl acceso por SSH es casi un requerimiento esencial para acceder a nuestro VPS. Utilizando este protocolo, podremos controlar y administrar remotamente nuestro servidor. El problema, es que este mismo protocolo será utilizado por hackers para intentar colarse y tomar el acceso de nuestro servidor. Lo que hoy pretendemos es securizar nuestro VPS, simplemente cambiando el puerto SSH.

¿Por qué cambiar el puerto de escucha de SSH?

Tal como hemos comentado, SSH utiliza por defecto el puerto 22. En principio los ataques al servidor se realizan por este puerto, por lo que resulta fundamental para securizar nuestro servidor, modificar dicho valor.

Pasos necesarios para cambiar el puerto SSH del servidor

Deberemos utilizar algún editor de texto como vi, vim o nano,  y editar el fichero sshd_config situado en:

etc/ssh/sshd_config

Una vez abierto, deberemos localizar la línea Port:

# Port 22 
# AdressFamily any 
...

Primero descomentaremos dicha línea eliminando la almohadilla (#), y después sustituiremos el puerto 22 por el que queramos, preferiblemente que sea un numero superior a 1024. Si por ejemplo queremos utilizar el puerto 5055, nos deberá quedar así:

Port 5055 
# AdressFamily any 
...

Guardaremos los cambios, y a continuación, reiniciaremos el servicio de SSH utilizando el comando:

service sshd restart

A partir de ahora, cuando queramos acceder a nuestro servidor, deberemos hacerlo indicando su nuevo puerto.

Error 500 Internal Server por un plugin en WordPress

por el en la categoría Aplicaciones

Error 500 Internal Server tras instalar un plugin en WordPressLamentablemente, es bastante habitual instalar nuevos plugins en nuestra web directamente y sin haberlos testado previamente en un sitio de pruebas. En el caso de que el puglin instalado no funcione correctamente con nuestra instalación de
WordPress, por lo general, obtendremos un error 500 Internal Server.

Tras esto, no podremos ni acceder a la parte publica ni a la de administración, con lo perdemos el control de nuestra web, y si accede algún usuario, se encontrará con el mismo error.

Opciones para solucionar el error 500

Si estamos seguros de que plugin es el que ha provocado el fallo, podemos acceder por FTP a nuestro servidor y buscar la carpeta de plugins. Por lo general dicha ruta es directorio-de-instalación>wp-content>plugins Una vez alli, renombramos o borramos la carpeta del plugin en cuestión.

En el caso de no saber que plugin es el que ha provocado el fallo (si hemos instalado varios a la vez), lo mejor será desactivar todos los plugins y posteriormente ir activándolos uno a uno manualmente. Para esto, deberemos acceder a phpMyAdmin y buscar la base de datos de nuestro WordPress. Una vez dentro, localizaremos la tabla wp_options y dentro de esta buscaremos la columna llamada active_plugins. Sustituiremos el contenido de option_value por a:0:{}

error-500-wordpress

La opción mas drástica, sería restaurar una copia de seguridad de nuestra web bien que tengamos nosotros o bien de nuestro proveedor de alojamiento, con el consiguiente peligro de perder las últimas modificaciones realizadas.

Meta Tags de uso recomendado

por el en la categoría Buscadores, Diseño y Programación

Meta Tags de uso recomendadoCon la expansión de Internet, las páginas comenzaron a utilizar las Meta Tags. Dichas etiquetas son fragmentos de código situados en la cabecera de la página web que permiten obtener información de lo que realmente contiene dicha página.

Lamentablemente, las Meta Tags fueron mal utilizadas por los webmasters de la época, agregando términos o características a la página que poco o nada tenían que ver con ésta, con el único fin de aparecer en la mayoría de búsquedas que se realizaban.

En la actualidad, el principal motor de búsqueda, ha optado por posicionar las páginas por diversos factores, no teniendo en cuenta a las metaetiquetas para estos menesteres. En cambio, las etiquetas si son utilizadas por ejemplo para saber el idioma de la página o para mostrar un resumen de la misma en la página de resultados.

Meta Tags de uso recomendado

Existen unas pocas etiquetas en las que su uso es relativo y recomendado. Estas serian:

Meta Content Language

Para indicar el idioma en el cual está nuestra página web. Es recomendable indicarlo siempre que el idioma sea diferente al inglés. Para indicar la codificación en idioma español escribiremos:

<META HTTP-EQUIV="Content-Language" CONTENT="es-ES">

Meta Content Type

Otro factor importante a tener en cuenta es la codificación de caracteres. En el idioma español es importante debido a la utilización de acentos y caracteres no estandar, que pueden no visualizarse correctamente. Tenemos varios tipos como UTF-8 o ISO-8859-1Para indicar el sistema utilizado escribiremos:

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

Meta Description

El contenido de esta etiqueta será el que normalmente es utilizado para mostrar la breve descripción al listar los resultados de busqueda. Se recomienda que no exceda de 160 caracteres, ya que si se excede, dichos caracteres serán ignorados.

<meta name="description" content="descripción de la página">

Modificar los valores PHP desde el panel Plesk

por el en la categoría Plesk

Modificar los valores PHP desde el panel PleskUna de las muchas posibilidades que ofrecen las nuevas versiones del Panel Plesk, es la de modificar los valores PHP. Si bien es cierto que en versiones anteriores ya había algunos parámetros que se podían modificar, ha sido en las últimas versiones publicadas, en las que se ofrece un mayor control por parte del administrador.

Históricamente, el terminal de nuestro servidor y el administrador, han sido como uña y carne. Cualquier cambio de configuración por mínimo que fuera, ha necesitado del acceso remoto al fichero php.ini, para realizar los cambios necesarios. Conforme se han ido publicando nuevas versiones de Plesk, las opciones de administración han ido aumentando, llegando a un punto en el realizar cambios de configuración de PHP, es una tarea bastante sencilla, puesto que no tenemos que recordar rutas, ni directivas, ni los comandos para el reinicio del servidor.

Acceso a la configuración del servidor mediante Plesk

Si somos administradores de un servidor, y tenemos varios dominios alojados, nos loguearemos en el servidor, pulsaremos en la sección Dominios, y elegiremos el dominio a administrar.

A continuación veremos un listado con el dominios principal y los subdominios asociados en caso de que los haya. Deberemos pulsar en el dominio que queramos administrar.

Una vez seleccionado el dominio (o subdominio), nos aparecerán todas las opciones disponibles para dicho dominio. Deberemos seleccionar la opción Configuración PHP.

Modificar los valores PHP desde el panel Plesk

Una vez dentro de dicho apartado, podremos modificar, entre otras, las siguientes caracteristicas de PHP:

  • memory_limit
  • max_execution_time
  • max_input_time
  • post_max_size
  • upload_max_filesize
  • safe_mode
  • register_globals
  • open_basedir
  • error_reporting
  • display_errors
  • allow_url_fopen

Estas directivas, nos ayudarán en la mayoría de los casos en los que tengamos problemas para la instalación de algún CMS o tienda virtual.

Vulnerabilidad muy grave detectada en el nucleo de Drupal

por el en la categoría Aplicaciones

Vulnerabilidad muy grave detectada en el nucleo de DrupalAyer se publicó la 7.32 de Drupal, la cual corrige una vulnerabilidad muy grave detectada en el núcleo de Drupal.

Cuando decimos muy grave, no estamos exagerando. Según se informa desde la página oficial del proyecto Drupal, este bug permite la posibilidad de inyección SQL, con el consiguiente riesgo para la web atacada.

Drupal se basa en una API, mediante la cual abstrae todas las sentencias SQL y de paso, realiza una verificación de todas dichas sentencias para evitar ataques por SQL. El bug detectado, se encuentra precisamente en esta API, que no realiza correctamente su trabajo y permite a un atacante con suficientes conocimientos, la ejecución de comandos SQL.

El detalle de dicha vulnerabilidad se encuentra en https://www.drupal.org/SA-CORE-2014-005

Como comentamos al principio, el bug detectado tiene la calificación de “altamente crítico“, por lo que se recomienda la inmediata actualización del sitio web a la última versión.

En el caso de no poder actualizar, por seguridad, se recomienda aplicar un parche temporal, del fichero database.inc, para mitigar en lo posible la vulnerabilidad de nuestro sitio. Para aplicar este parche, consulta este enlace https://www.drupal.org/files/issues/SA-CORE-2014-005-D7.patch

Para descargar la última versión, no tenéis mas que acceder a la página oficial del proyecto: https://www.drupal.org/project/drupal

Forzar la descarga de un archivo en lugar de mostrarlo en el navegador

por el en la categoría Apache

Forzar la descarga de un archivo en lugar de mostrarlo en el navegadorBien sea de forma nativa, bien sea por la instalación de algún complemento, los navegadores son capaces de mostrar una serie de archivos como imágenes, ficheros de texto, ficheros pdf, etc. En cambio, hay otros que por lo general son descargados directamente, como los ficheros comprimidos (zip, tar, gzip, rar, etc.). Lo que pretendemos en éste artículo es mostraros la manera de forzar la descarga de un archivo concreto, que por defecto se visualiza en el navegador.

Comentar también, que a parte de la adición de plugins que nos pueden modificar el comportamiento del navegador, es muy probable que ficheros que por ejemplo en Firefox serán descargados (por ejemplo un fichero de Word), en otros navegadores puede que sean interpretados, como en Internet Explorer.

Para asegurarnos que el comportamiento al clicar sobre un enlace de nuestra página web sea el esperado en la mayoría de navegadores, deberemos crear un fichero .htaccess, en el cual indicaremos lo siguiente:

<FilesMatch "\.(?i:extension1|extension2)$">
  ForceType application/octet-stream
  Header set Content-Disposition attachment
</FilesMatch>

Con esta entrada, indicaremos las extensiones que queremos forzar la descarga. En el caso de indicar varias extensiones, por ejemplo doc, docx, pdf, txt, .., deberemos separarlas con una barra vertical “|”.

Una vez creado el fichero .htaccess, lo guardaremos en la carpeta donde se ubiquen los ficheros en cuestión.

Evidentemente, es necesario contar con un servidor Apache para que estos cambios tengan efecto.

Dos nuevas versiones de Joomla en apenas unas horas

por el en la categoría Aplicaciones

Dos nuevas versiones de Joomla en apenas unas horasEl equipo de desarrollo de Joomla ha estado muy ativo en estos dias, ya que tras presentar la versión 3.3.5, tan solo unas horas mas tarde publicó la versión 3.3.6

Se lanzó la versión 3.3.5 para corregir unos errores detectados en el núcleo. Estos errores suponían un fallo de seguridad importante para los usuarios de este popular CMS.

Las mejoras introducidas en la versión de Joomla 3.3.5 corregían dos fallos de seguridad detectados:

  • Inclusión remota de archivos, clasificado como grave y que permitía a otros usuarios subir archivos a nuestra cuenta.
  • Denegación de servicio, clasificado con prioridad media.

Tras la corrección de estos fallos de seguridad y la publicación de la versión de Joomla 3.3.5, el equipo de desarrollo detecto fallos en el sistema de actualización del núcleo, por los que se apresuró a lanzar la nueva versión (3.3.6).

Es recomendable que los usuarios de esta plataforma actualicen de forma inmediata a la última versión, ya que engloba los fallos de seguridad publicados en la versión 3.3.5 y la corrección del sistema de actualización del núcleo, que facilita en gran medida mantener el sistema actualizado.

Para descargar la última versión podéis acceder a la página oficial de descargas de Joomla.

Como siempre, os recomendamos antes de nada, hacer una copia de seguridad tanto de los ficheros del servidor como de la base de datos.

Mejorar el rendimiento de Apache optimizando AllowOverride

por el en la categoría Apache

Mejorar el rendimiento de Apache optimizando AllowOverrideApache posee un fichero de configuración en el que le indican una serie de directivas. Estas directivas pueden ser modificadas en cada directorio gracias a la utilización de los ficheros .htaccess. Estos ficheros, por una parte nos ayudan a realizar configuraciones concretas para cada directorio, pero en cambio, reducen el rendimiento de Apache, ya que debe comprobar su existencia en cada directorio, y esto empeora aun mas cuando existen subdirectorios.

Por norma general, cuando necesitamos utilizar ficheros .htaccess, en el fichero de configuración de Apache, echaremos mano del sufrido:

AllowOverride All

Esto le indica a Apache que si encuentra cualquier fichero .htaccess por cualquiera de las carpetas, que lo lea e interprete, con el consiguiente empleo de recursos en analizar todas las carpetas en busca de alguno de estos ficheros.

Pero lo lógico sería indicar que Apache nos busque los ficheros .htaccess, únicamente en las carpetas donde los tengamos. Por ejemplo:

<Directory /ruta_a_mi_fichero_.htaccess>
   AllowOverride All
</Directory>

Gracias a esto evitaremos sobrecargar de trabajo innecesario a Apache y aumentaremos su rendimiento.