proxy

Securizando un poco más el acceso

/ arrodas / 2 Comments

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

Acceso al servidor anywhere

/ arrodas / Leave a comment

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é.

Navegación anywhere

/ arrodas / 2 Comments

¿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_SOSPECHOSA

stop 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.