Desde hace algún tiempo, monitorizo el crecimiento de las particiones del servidor. Curiosamente, desde hace un par de semanas, /usr se ha ido incrementando considerablemente hasta 1GB de más, lo cual no comprendo del todo, pues dicha partición no se usa para “nada”, es decir, los logs, backups… van a otra, así pues, ¿qué puede ser?, ¿alguna idea?.
Por lo pronto ya la estoy vigilando de cerca, así que, en unos días espero saber cuál es la causa.
Desde que salió el bug de OpenSSL para Debian, quería cambiar los certificados SSL del site, así que, aprovechando, los he solicitado a CAcert.org:
Así pues, ya no tengo la chapuza de los certificados autofirmados y, de algún modo, ayudo a la propagación de esta iniciativa.
Aprovecho para agradecer a CAcert (y a los voluntarios que hacen de notarios) el permitir a aquellos usuarios, que nos parecen elevados los precios de los certificados “comerciales”, o no queremos pasar “por el aro”, tener certificados serios.
Quizás alguno se haya dado cuenta, pero desde ayer, la web redirige siempre al .es que Alicia y yo tenemos.
Durante un tiempo, y por compatibilidad, permitiré el acceso a quienes accedan a través de dyndns, así pues, por favor, cambiad los bookmarks y lectores de feeds por el dominio .es cuando tengáis un momentín.
Disculpad las molestias, o mejor dicho, los pequeños cambios que el progreso nos requiere.
… porque las cosas tienen que ir muy mal para que hasta los árboles estén en venta. ¿Posibles clientes?, quizás una pareja de pájaros jovenzuelos que quieran tener un nido:
Últimamente he dado unas cuantas vueltas por Jamendo, una web en la que muchos artistas publican bajo licencia Creative Commons su música. La puedes descargar gratuitamente, y si te gusta, puedes comprarles el CD, hacer una donación…
El caso es que de entre los música que he descubierto, me he encontrado con los que dan título a este post, Lindalou and Michael Ryge, que hacen música folk, completamente acústica y tienen canciones muy interesantes, como Nothing Missing, en la que dan un poco de caña a la polémica de las descargas de música y a dónde quieren llegar los músicos “tradicionales” y sus discográficas (o vendedores de plástico, como ellos dicen).
P.D: Para bajar el disco entero, puedes ir a Jamendo, con descarga directa o torrent.
Tras la serie de posts anywhere, surge un problema: ¿no es un poco peligroso dejar tantas cosas al aire?.
Sí, efectivamente, un atacante con unos buenos scripts y suficiente paciencia podría liar una buena. Para tratar de eviarlo, uso fail2ban (¡gracias Carlos!). Antes usaba denyhosts, pero tiene unos problemas:
1) Sólo sirve para SSH.
2) Usa el fichero /etc/hosts.deny.
3) La experiencia me indica que el proceso muere, así que tenía que estar continuamente revisándolo.
Fail2Ban sin embargo,
1) Sirve para ssh, apache, postfix, ftp… (ahora que tengo el proxy y el acceso remoto, me soluciona todo)
2) Usa IpTables
Respecto al tercer punto, a lo largo del tiempo comprobaré si es igual de inestable que DenyHosts, aunque espero que no
Siguiendo la línea anywhere, hoy hablamos de cómo administrar un servidor desde cualquier sitio, en especial en aquellos en los que sólo tienes acceso por HTTP/HTTPS/FTP.
Lo lógico es usar SSHv2, pero, en muchos sitios, no puedes “salir” por el puerto 22 y mucho menos por uno aleatorio que le habrás puesto a tu SSH con el que evitas la mayoría de los ataques.
En un principio, pensé en SSL-Explorer, pero tiene un problema, levanta su propio servicio en el puerto 443 (por ejemplo), por lo que no depende de Apache (y no permite hacer un VirtualHost). Sé que con mod_proxy podría solucionarlo, pero me da mucha pereza.
Finalmente, encontré AnyTerm y AjaxTerm (que es el que uso). Cualquiera de estos programas te da una “bash” a través del navegador, levantando un servicio más de red en un puerto dado. El problema es cómo publicarlo, pues, ¿vas a dejar tu bash abierta al mundo (tendrán que adivinar el user/pass)? y también, si el problema es que necesito acceder sólo por el puerto 80 o 443, ¿cómo hacerlo? (y ya he dicho que el mod_proxy me da pereza).
Como en el anterior post, con CGIProxy, ya he creado una capa de seguridad, así pues, a través de él accedo a AjaxTerm, encapsulando la sesión a través de mi proxy SSL, por lo que puedo acceder al servicio que yo le indique.
Por tanto, tengo acceso al servidor desde virtualmente cualquier sitio, por muy chapado que esté.
A menos de una hora para ir a comer, me piden una foto vestido de romano para el dichoso artículo que me han hecho escribir. Ante la urgencia, incluso me proponen usar la ropa de otra persona, a lo que no accedo, eso sí, usando como excusa que estoy sin afeitar todo guarrete.
Consigo convencerles para ir en un momento a casa, recortarme la barba y ponerme la parte de arriba del traje.
A la vuelta, me están esperando los de marketing para la foto. No se les ocurre nada mejor que sacar un logo corporativo que abundan por los pasillos, pero no por cualquier pasillo, sino por el que pasa todo el mundo para ir al comedor y ya es la una (avalancha para ingerir alimentos).
De vaqueros, con zapatos de senderismo (estos días llueve…), camisa, corbata y americana… de traca. Todo el mundo intrigado mirando por qué hacen tantas fotos (cerca de 10). Espero que al menos me den el número de la revista, porque después de tanta vejación, no es para menos.
¿Harto de estar detrás de un proxy?
¿Cansado del abuso de los filtros de contenidos?
¿Temeroso de lo que tu jefe vea en tus logs de navegación?
¿Odias dormir en incómodas camas plegables?… ups!, eso es otro anuncio….
Para todo ello, CGIProxy es tu solución (¡gracias Esteban!). Para ello, debes configurar un Apache y tener este CGI basadp en Perl. Para mejorar la seguridad y, SOBRE TODO, el salto del proxy corporativo, debes usar SSL, pues accediendo por HTTPS, lo único que veremos en el proxy es un método CONNECT a tu Apache, nada más. También, es MUY IMPORTANTE, que el acceso sea mediante usuario/password (como mínimo), de lo contrario, tendrás un proxy abierto al mundo.
Ya sabemos cómo eludir el proxy, ¿y los filtros de contenidos?. Sencillo, como el acceso es restringido, no deberían ser capaces de categorizar tu sitio, si llegan a ello, lo categorizarán con toda probabilidad como una categoría no “sospechosa”. Si a alguien le interesa en qué saco lo mete Webfilter, no tengo problema en comentarlo, pero no lo publicaré.
Finalmente, ¿qué mejor que comprobar que todo lo que he dicho es cierto?. La prueba del algodón, pasamos a través de un Bluecoat:
start transaction ——————-
CPL Evaluation Trace: transaction ID=XXXXXX
<Proxy>
miss : condition=xxxx
miss : client.address=xxxxx
MATCH: client.address=ESTA ES MI IP
..
.
miss : category=”XXXXXXX”
connection: service.name=HTTP client.address=ESTA ES MI IP proxy.port=8080
time: FECHA y HORA UTC
CONNECT tcp://URL_de_MI_PROXY:443/
User-Agent: UserAgent de mi browser
url.category: CATEGORIA_NO_SOSPECHOSAstop transaction ——————–
Como se puede ver, sólo se ve el connect al proxy, que es la URL que tengamos. Esto es imporante, pues como la URL que visitamos forma parte de la URL que nos muestra el navegador, siempre queda la duda, que espero haya quedado resuelta.
NOTA: En el caso que el Bluecoat o proxy similar tenga tarjeta aceleradora SSL y hayan pagado la licencia de uso, el túnel SSL es “roto”. En ese caso, tendremos que poner mil ojos en la autoría de los certificados, ya que en caso de ser capaz de entrometerse en la conexión HTTPS, el certificado estará generado por éste.
Ayudando a Alicia con los trabajos de la uni, recopilando información que generalmente está en webs de colegios e instituciones, he llegado a http://www.cplgsfuentes.com
Resulta que permite listar el directorio, y su único html, al cargarlo:
PÁGINA DE PRUEBAS
ESTA SERÁ LA PRUEBA PARA VER SI FUNCIONA O NO EL VÍDEO DE LA LECHE
Parece que está tratando de mostrar un video (flv, de flash) con un reproductor embebido… pero a la vista está que parece no salirle
El Blog de Alberto 