Planeta WordPress

Si quieres evitar que los perfiles de usuario por debajo de un rol determinado tengan acceso al Escritorio de WordPress, a cualquier parte de ‘wp-admin’, o los que no accedan desde una IP concreta, puedes hacerlo de varias maneras.

Como siempre, voy a mostrarte unos cuantos modos, con código, por IP y con plugin, vamos a verlo … 

1. Restringir acceso wp-admin con plugin

Hay muchas maneras de proteger el Escritorio pero el plugin que te ofrece más posibilidades es WP Secure, con el puedes limitar el acceso a wp-admin por IP o por tipo de usuario, tu eliges.

2. Restringir acceso wp-admin por IP

Para este método nos valdremos el fichero .htaccess. Primero editamos el existente en la carpeta raíz de tu sitio desde el cliente FTP que uses habitualmente o el navegador de tu proveedor de hosting. Si no existiera lo creas y, en cualquier caso, le añades lo siguiente:

<Files wp-login.php>
Order Deny, Allow
Deny from all
Allow from xx.xx.xx.xx

Allow from xx.xx.xx.xx
</Files>

Donde las xx.xx.xx.xx son las IP que SI pueden acceder. Si no sabes tu IP puedes comprobarlo aquí.

Pero no hemos terminado, ahora vas a la carpeta ‘wp-admin’ y creas (si no existiera) otro fichero .htaccess en su interior. En el añades lo siguiente:

Order Deny,Allow
Deny from all
Allow from xx.xx.xx.xx
Allow from xx.xx.xx.xx

De nuevo las xx.xx.xx.xx son las IPs autorizadas. Guardas los cambios y ya lo tienes

3. Restringir acceso a wp-admin por código

Para terminar, puedes también conseguir lo mismo añadiendo el siguiente código al fichero functions.php de tu tema activo:

<?php
	function restringir_login(){
		global $current_user;
		get_currentuserinfo();

		if ($current_user->user_level <  4) { //si no es admin no entra
			wp_redirect( get_bloginfo('url') );
			exit;
		}

	}
	add_action('admin_init', 'restringir_login', 1);
?>

En este ejemplo todo usuario por debajo del nivel de Administrador (4) no podrá acceder. Así de fácil.

¿Sabes algún modo más?

A ver, ponte en situación: has creado un sitio, aseguras los máximos de seguridad de tu WordPress, limitas los intentos de acceso, aplicas directivas de seguridad, evitas dar pistas a hackers, incluso blindas tu instalación.

Bien, te dispones a dar acceso a distintos usuarios a tu sitio, les creas contraseñas seguras y, en su primer acceso la cambian por algo como el nombre de su perro, o la fecha de su cumpleaños o los típicos “God”, “contraseña” y cosas así.

Pues bien, si no quieres que la parte más débil en la seguridad informática (el usuario) haga de las suyas puedes quitar de la vista el formulario para el cambio de contraseña, y así te curas en salud.

Solo tienes que añadir el siguiente código al fichero functions.php y todos los usuarios que no sean Administrador no verán y, en consecuencia, no podrán cambiar su contraseña de acceso:

//inhabilitar cambio de claves
if ( is_admin() )
  add_action( 'init', 'disable_password_fields', 10 );
function disable_password_fields() {
  if ( ! current_user_can( 'administrator' ) )
    $show_password_fields = add_filter( 'show_password_fields', '__return_false' );
}

Si alguien quiere cambiar la clave te lo tendrá que solicitar a ti, u otro administrador, con lo que tendrás el control.

Esta pequeña maravilla de código la encontré en WP Engineer

Contenido exclusivo para suscriptores al Feed

¡Gracias por seguirnos a diario!. Premiamos tu fidelidad ofreciéndote habitualmente contenidos exclusivos. Hoy puedes descargar:

Guía Windows Live Writer

En cada actualización de WordPress siempre surge el mismo debate, que si actualizo, que si no, que si no sé si actualizar, que si me romperá algo o me da miedo.

La cosa es que siempre andamos debatiéndonos entre la duda de si tener un WordPress seguro y, quizás, un poco menos compatible con plugins antiguos, o seguir usando programación obsoleta e insegura (si, vale, esto ya es una declaración de intenciones por mi parte).

Y yo, como siempre, recuerdo que la única versión segura, la única que tiene desarrollo y revisiones es la última, que usar una versión antigua de WordPress es caminar solo, sin compañía ni ayuda.

Pero bueno, como aquí todos tenemos alguna excusa, hoy te dejo a ti que cuentes tus motivos para no actualizar, y para los indecisos pongo algunos posibles motivos, que puedes ampliar con los tuyos en los comentarios si no te llega con los que te ofrezco …

Como aún hay muchas dudas en los comentarios acerca de si es está o no infectado por la versión insegura del script TimThumb nunca está de más hacer alguna comprobación adicional.

Si es tu caso, o si simplemente quieres asegurarte que has realizado las acciones para asegurar tu blog contra el TimThumb infectado, puedes instalar un simple plugin que hará el trabajo por ti.

Timthumb vulnerability scanner, una vez instalado y activado, realiza un análisis de los ficheros de tu instalación y, si encuentra una versión insegura te ofrece sustituirla por una versión actualizada y, como no, segura.

Sencillo y genial, como nos gustan las cosas en WordPress.

¿Harto del spam y los spammer en tu blog? Aunque Akismet y otras soluciones antispam nos ayudan no siempre son suficiente, para eso puede usar el fichero .htaccess que te ayudará a reducir el volumen de los robots de spam que acceden de forma directa a tu fichero wp-comments-post.php para lanzar comentarios en tu blog.

Sencillamente tienes que añadir las siguientes líneas en tu .htacces. El fichero como sabes esta localizado en el raíz de tu WordPress. Recuerda realizar antes una copia de seguridad de tu .htaccess antes de editar por si necesitas restaurarla. Y por supuesto no te olvides de cambiar “nombrededominio” en la línea 5 por tu dominio real.

 RewriteEngine On
 RewriteCond %{REQUEST_METHOD} POST
 RewriteCond %{REQUEST_URI} .wp-comments-post\.php*
 RewriteCond %{HTTP_REFERER} !.*nombrededominio.* [OR]
 RewriteCond %{HTTP_USER_AGENT} ^$
 RewriteRule (.*) ^http://%{REMOTE_ADDR}/$ [R=301,L]

Una vez que guardes el fichero .htaccess editado los robots de spam no podrán acceder de forma directa a wp-comments-post.php. De esta forma se reducirá de forma significativa el volumen de spam en tu blog.

Y si además quieres complicarlo un poco más para los robots de spam también puedes bloquear directamente las llamadas de estos a través de .htaccess añadiendo algo así al fichero:

#Bloquear spambots
RewriteCond %{HTTP:User-Agent} (?:Alexibot|Art-Online|asterias|BackDoorbot|Black.Hole|BlackWidow|BlowFish|botALot|BuiltbotTough|Bullseye|BunnySlippers|Cegbfeieh|Cheesebot|CherryPicker|ChinaClaw|CopyRightCheck|cosmos|Crescent|Custo|DISCo|DittoSpyder|DownloadsDemon|\eCatch|EirGrabber|EmailCollector|EmailSiphon|EmailWolf|EroCrawler|ExpresssWebPictures|ExtractorPro|EyeNetIE|FlashGet|Foobot|FrontPage|GetRight|GetWeb!|Go-Ahead-Got-It|Go!Zilla|GrabNet|Grafula|Harvest|hloader|HMView|httplib|HTTrack|humanlinks|ImagesStripper|ImagesSucker|IndysLibrary|InfonaviRobot|InterGET|Internet\sNinja|Jennybot|JetCar|JOC\sWeb\sSpider|Kenjin.Spider|Keyword.Density|larbin|LeechFTP|Lexibot|libWeb/clsHTTP|LinkextractorPro|LinkScan/8.1a.Unix|LinkWalker|lwptrivial|Mass\sDownloader|Mata.Hari|Microsoft.URL|MIDown\stool|MIIxpc|Mister.PiX|Mister\sPiX|moget|Mozilla/3.Mozilla/2.01|Mozilla.*NEWT|Navroad|NearSite|NetAnts|NetMechanic|NetSpider|Net\sVampire|\NetZIP|NICErsPRO|NPbot|Octopus|Offline.Explorer|Offline\sExplorer|Offline\sNavigator|Openfind|Pagerabber|Papa\sFoto|pavuk|pcBrowser|Program\sShareware\s1|ProPowerbot/2.14|ProWebWalker|ProWebWalker|\psbot/0.1|QueryN.Metasearch|ReGet|RepoMonkey|RMA|SiteSnagger|SlySearch|SmartDownload|Spankbot|spanner|Superbot|SuperHTTP|Surfbot|suzuran|Szukacz/1.4|tAkeOut|Teleport|Teleport\sPro|Telesoft|The.Intraformant|TheNomad|TightTwatbot|Titan|toCrawl/UrlDispatcher|toCrawl/UrlDispatcher|True_Robot|turingos|Turnitinbot/1.5|URLy.Warning|VCI|VoidEYE|WebAuto|WebBandit|WebCopier|WebEMailExtrac.*|WebEnhancer|WebFetch|WebGo\sIS|Web.Image.Collector|Web\sImage\sCollector|WebLeacher|WebmasterWorldForumbot|WebReaper|WebSauger|Website\seXtractor|Website.Quester|Website\sQuester|Webster.Pro|WebStripper|Web\sSucker|WebWhacker|WebZip|Wget|Widow|[Ww]eb[Bb]andit|WWW-Collector-E|WWWOFFLE|Xaldon\sWebSpider|Xenu’s|Zeus) [NC]
RewriteRule .? – [F]

Gracias a las referencias de WPRecipes y Allguru.

Reducir spam en WordPress usando .htaccess is a post from: Carrero

Como sé que te gustan las infografías hoy comparto una que está muy bien, no por su diseño sino por su especialización, ya que al haberla hecho un sitio dedicado a seguridad informática hace el hincapié en cuan seguros están los 100 mil principales sitios que usan WordPress.

Como siempre, por si alguien no se maneja bien con el inglés, traduciré los datos que considero más importantes de la misma, a saber …

• El 66% de los sitios de más tráfico de España que usan WordPress no han actualizado a la versión 3.2.1
• El 74,6% usan Apache
• Solo el 45,8% usan WordPress 3.2.x
• Uno de los sitios top usa aún WordPress 1.5
• El hosting más utilizado es Softlayer
• Los más comprometidos con la seguridad (versiones más actualizadas) son los alemanes y los brasileños
• Los menos comprometidos con la seguridad (versiones menos actualizadas) son Japón y España

¿Conclusiones?

Sencilla:

¡Actualiza a WordPress 3.2.x

La única versión realmente segura de utilizar es WordPress 3.2.x, es la única en desarrollo y supervisada, si usas una versión anterior estás solo, no hay actualizaciones de seguridad para versiones antiguas. Lo sabías ¿no?

He hablado muchas veces del fichero .htaccess, un archivo que, aunque no pertenece a la instalación de WordPress, es necesario para que funcionen muchas cosas que seguro necesitaremos, desde los enlaces permanentes hasta la protección de nuestras carpetas.

Pero como andaba todo algo disperso he pensado que, en estos tiempos que corren, no está de mas un recordatorio y, por supuesto, un resumen.

Pero antes vamos a ver lo que ya había por si te has perdido algo, luego escribimos las líneas para que tu .htaccess asegure tu WordPress.

¿Hacemos una recopilación? …

• Qué es el hotlinking y como protegerte (también con .htaccess claro)
• Protege tu .htaccess
• Restringir acceso al Escritorio por IP
• Cómo banear por IP o dominio desde .htaccess
• Redirección por .htaccess mientras actualizas
• Evitar spam blogs (splogs) en BuddyPress y WPMU mediante .htaccess
• Evita comentarios spam desde .htaccess
• Modifica el fichero .htaccess desde el Escritorio
• Como mostrar los mensajes de error de WordPress
• Regala un error 403 a los curiosos
• Proteger la carpeta wp-admin
• Y hasta publiqué un .htaccess perfecto para WordPress

Unos detalles … 

1. La "serversignature" es un texto en los mensajes de error que indica la versión de Apache que usamos e incluso el email del administrador
2. ¡Ojo!, no pegues directamente eso en tu .htaccess, que hay muchas líneas de ejemplo

Ea, a ir seguro por esas webs, que hay mucho Apache suelto

Contenido exclusivo para suscriptores al Feed

¡Gracias por seguirnos a diario!. Premiamos tu fidelidad ofreciéndote habitualmente contenidos exclusivos. Hoy puedes descargar:

Guía Domina tu Blog

Según el blog de Unmask Parasites, más de 4.000 sitios WordPress hackeados estarían inundando de imágenes utilizadas para posicionar sitios de falsos antivirus.

Lo que hacen estos indeseables del Black Hat SEO, usando el exploit en Timthumb del que avisé, es lo siguiente …

Con el siguiente patrón de URL: hxxp:///?[a-f]{3}= , donde [a-f]{3} es una combinación de tres letras desde la "a" a la "f" y las son combinaciones de palabras clave separadas por guiones que contienen o imágenes de palabras o imágenes normales, por ejemplo:

hxxp://ejemplo.com/?fef=imágenes-de-mitzi-mueller-wrestling
hxxp://ejemplo.net/?cda=imagen-frutas-tropicales-index

Para ello usan páginas con puerta trasera que introducen en plantillas normales de sitios WordPress, donde el contenido original se reemplaza con unas veinte miniaturas y pequeños bloques de texto relativos a las palabras clave a posicionar.

Las imágenes no están enlazadas desde sitios externos sino que enlazan a imágenes a "tamaño completo" con URLs como estas:

Por ejemplo:

En la parte superior de las imágenes se muestra una inscripción - el nombre de dominio del sitio hacheado. De este modo los indeseables estos hacen parecer que las imágenes pertenecen al sitio que han hackeado, como si fuera contenido propio, no imágenes insertadas o robadas. Al mismo tiempo, de este modo, es más fácil identificar la imagen envenenada en los resultados de búsqueda.

Los archivos de imágen contienen la siguiente cadena en su interior: < CREATOR: gd-jpeg v1.0 (using IJG JPEG v62), quality = 100. Esto significa que se crearon usando la biblioteca gráfica GD.

Parece ser que los hackers usan un script PHP para coger imágenes bien posicionadas (en los resultados de búsqueda de Google Imágenes), las redimensionan a tamaño de miniatura (un ancho de entre 200 y 300 pixels) y a tamaño completo (algunas a tamaño aleatorio, en algunos casos incluso a tamaños mayores que la original, para posicionarlas mejor al ser más grandes en pixels) y finalmente añaden el sello del nombre del dominio hackeado.

Marcas temporales

Al fondo del código HTML de las páginas puerta trasera puedes ver comentarios como estos:

La marca temporal y las palabras clave. De este modo puedes fácilmente ver cuando se creó la puerta trasera.

Redirecciones

Las páginas puerta trasera tienen buenas posiciones en algunas palabras clave tanto en la búsqueda web de Google como en la de Imágenes (especialmente cuando buscas la frase exacta). Sin embargo, las redirecciones maliciosas ocurren solamente cuando haces clic en el resultado de búsqueda en Google Imágenes, lo que prueba que la meta final es inundar Google Imágenes de estas imágenes, o sea, una campaña pura y dura de black-hat SEO.

La redirección tiene dos etapas. En la primera la redirección va a un servidor intermedio (TDS) que, a continuación, redirige a unas páginas web que lanzan una herramienta antivirus falsa (hay dos variaciones diferentes).

Esta es una cadena real de redirección:

Como puedes ver, el servidor TDS recibe información acerca de las palabras clave, la fuente, y de la URL de referencia.

El dominio intermedio cambia cada día. En realidad pertenecen a otros sitios hackeados (en su mayoría creados con WordPress)

Aquí tienes unos cuantos dominios del TDS intermedio usados en este ataque:

video.bywhy .com
ppopo2.bget .ru
awalstudios .com
demo.hireindians .net
www.privatepilot .hu
footballgirdles .tk

El nombre de dominio de la página web del falso antivirus consiste en un dominio .in que cambia cada día, y unos cuantos subdminios "updateNN" o "scanNN", por ejemplo, "update82.yourscan.in" o "scan73.moomles.in.

Aquí tienes unos cuantos dominios .in de los falsos sitios antivirus usados en este ataque:

spelleit .in
svernick .in
senerino .in
moomles .in
klopster .in
bastandro .in
waspeeds .in
yourscan .in
x-scan .in

La mayoría de los sitios .in apuntan a la dirección IP 193.105.154.31 (Reino unido, con información de contacto de Lituania).

Rango de detección

Los falsos sitios antivirus lanzan ejecutables .exe "scareware" con nombres como InstallSecurityScanner_NNN.exe, o
InstallSecurityScanner_225.exe. Estos archivos se vuelven a re-empaquetar cada día y su rango de detección (según VirusTotal) es bastante bajo. El rango típico de detección para ficheros servidos actualmente es de 8/43 (18,6%). Esto suele mejorar en tanto en cuanto el fichero malicioso no se use y se sirva un nuevo fichero con bajo rango de detección desde el servidor del antivirus.

Como he comentado arriba, y por concretar más, se han detectado 4.358 sitios comprometidos. Actualmente Google ha detectado menos del 5% de los mismos. Si usas la página de diagnóstico de navegación segura de Google te dice algo así:

El software malicioso está alojado en 2 dominio(s), incluyendo bastandro .in/, senerino .in/.

Parece que 3 dominio(s) están funcionando como intermediarios para distribuir malware a los visitantes de este sitio, incluyendo hireindians .net/, awalstudios .com/, bywhy .com/.

Timthumb

Como ya avisé hace unos días, hay que poner al día Timthumb si lo usa tu tema, no hay excusas, más visto lo visto de los resultados ¿no te parece?

.htaccess

Pero no solo Timthumb es el culpable, también se han detectado sitios en los que hackers han creado un .htaccess con reglas de rewrite superiores al directorio raíz del sitio. Las reglas de rewrite mapean las URLs puerta trasera a algún script PHP. Ahí es nada.

Cache

Todas las páginas puerta trasera están cacheadas en alguna parte del servidor. Al contrario que otros ataques de envenamiento SEO estos no se hacen en vivo. Si especificas algunas palabras clave diferentes en la URL obtendrás un error 404. Dicho sea de paso, estas páginas de error 404 son distintas a las normales que tenga el sitio hackeado.

Otra prueba de que el contenido spam está cacheado y de que no se inyecta en la ejecución de páginas activas de WordPress son las marcas temporales en el fondo del código HTML y de las entradas antiguas de la sección de "Entradas recientes". En algunos sitios, en vez de una plantilla real del sitio, usan una plantilla prefabricada de Kubrick con una marca final que no cambia de sitio a sitio sino que es siempre la misma (WordPress 2.3.1, 22 queries, 0.912 seconds).

¿Que hago?

Hay varias comprobaciones y/o acciones que podemos realizar:

1. Pues lo primero repasar tu fichero .htaccess y elimina cualquier regla de rewrite que no sepas que hace. Ante la duda bórralo y vuelve a guardar la estructura de enlaces permanentes en los Ajustes de WordPress para que se vuelva a crear uno limpio.
2. Actualiza TimThumb a la versión segura. Ya te he puesto los enlaces a las maneras de hacerlo más arriba, en la entrada que escribí el otro día tienes los distintos modos de hacerlo
3. Ve a las Herramientas para Webmasters de Google y revisa si tu sitio tiene software malicioso
4. Instala algún plugin detector de exploits y ejecútalo. Hay varios y buenos "en el repositorio oficial", haz una búsqueda por "exploit"

Que no sea nada

Gracias a Juan por el aviso

Si tu tema utiliza este script de redimensionado de imágenes, algo bastante habitual en temas estilo revista, más te vale saber se ha detectado una vulnerabilidad del tipo Zero day en TimThumb. Para asegurar sue tu sitio está seguro deberías hacer algo de lo que te indico a continuación:

Método 1: Actualiza el tema

Descarga la última versión del tema, usando el enlace de descarga de donde lo adquiriste. Todas las versiones nuevas de los temas suelen ya tener la versión segura del script. Un buen ejemplo es Elegant Themes, que ha actualizado todos los temas, aprovechando para incluir mejoras.

Método 2: Reemplaza el script timthumb por FTP

Borra el fichero timthumb.php y reemplázalo con la última versión segura de timthumb en la carpeta de tu tema a través de FTP. Si lo haces así es recomendable hacer también este cambio:

Edita la variable $allowedsites y quita todos los sitios referenciados - debería verse así tras editarlo:

Método 3: Actualiza timthumb desde el editor de WordPress

Sigue estos pasos para actualizar tu fichero timthumb actual:

1. Accede a tu sitio WordPress. Ve a Apariencia => Editor.
2. Abre el archivo timthumb.php y borra todo su contenido.
3. Copia-pega el contenido de la última versión segura de timthumb.. Tambien haz la modificación adicional indicada en el método 2.
4. Haz clic en Actualizar archivo (guarda).

Con cualquiera de estos 3 métodos tendrás tu instalación segura.

Gracias a Gabfire por la guía

Seguro que te preocupas por la seguridad de tu sitio web y de los directorios que necesitan permisos totales CHMOD 777, lo que sin duda podría ser a veces un problema de seguridad. Lo ideal es NO usar plugins que necesites permisos 777 para directorios, pero si estás seguro de usarlos y es totalmente necesario lo mejor es añadir unas líneas a tu .htaccess para mejorar la seguridad. Por comentar algunos caso hay servidores donde para que funcionen plugins tan importantes como W3 Total Cache nos exige tener permisos 777 en los directorio de cache, aunque suele funcionar siempre con un 755.

Entre los directorios de tu servidor que puede necesitar estar protección que te vamos a explicar pueden estar:

• uploads
• upgrade
• backups
• cache, cache-123
• temp, temp-123
• etc..

Suelen ser directorios que no siempre necesitan acceso directo de los usuarios. Entonces, lo que necesitamos es dar acceso para la dirección de tu servidor y de la máquina de la que eres propietario (o hosting compartido). Una vez que tenemos esta información el .htacces deberías añadir estas líneas:

Order Deny,Allow
Deny from all
Allow from 1.2.3.4
Allow from 4.3.2.1

Puedes usar “Allow from” para autorizar sin problemas más direcciones IP. Por ejemplo la dirección de tu ADSL por si necesitas algún acceso. Ahora solo tienes que subir un fichero .htaccess dentro del directorio a proteger y listo, ya estás más protegido que antes contra acceso no autorizado a esos directorios con todos permisos.

Gracias a DigWP por su post.

WordPress: Upload seguro, actualizar y otros directorios con .htaccess is a post from: Carrero