Jul
07
2011
0

Incluir el password de una conexión SSH en línea de comandos



Para todo aquel que necesite hacer un script en bash y quiera meter la clave de una conexión SSH en línea de comandos para ejecutar scripts, la solución es sshpass. No recomiendo este método, ya que una clave en un script puede ser un problema de seguridad, para ello podemos realizar la conexión SSH con certificados que ya explicaré en otro momento. La idea de esta entrada es para usos puntuales.

wget http://heanet.dl.sourceforge.net/project/sshpass/sshpass/1.05/sshpass-1.05.tar.gz
tar xvf sshpass-1.05.tar.gz
cd sshpass-1.05
./configure
make
make install

Ahora una vez instalado sshpass en nuestro sistema o servidor, la sentencia para conectarnos a ssh es la siguiente:

sshpass -p 'passwd' ssh root@172.25.0.1
Share
Written by Javier Rodriguez in: Linux | Etiquetas: ,
Mar
09
2011
0

Apache 2.4 en desarrollo



El popular servidor web que desde sus inicios adoptó la filosofía Open Source llevaba años sin ser modificado en gran medida, pero ahora se han dado los primeros pasos para llegar a una futura versión Apache 2.4. Los desarrolladores del proyecto Apache han publicado la versión Apache 2.3.11, que es el primer paso de lo que será Apache 2.4, y que llega con mejoras interesantes, sobre todo en el área de la gestión de varias peticiones de forma simultánea.

Seis años después de lanzarse la versión 2.2 del servidor web Apache, los responsables del proyecto han publicado Apache 2.3.11, que se supone es el primer paso hacia una futura versión Apache 2.4.

Las nuevas características de esta versión preliminar afectan por ejemplo a la arquitectura MPM (Multi-Processing Module) que permite múltiples peticiones para ser procesadas de forma casi simultánea. Por primera vez los usuarios no necesitan elegir un MPM cuando compilan el servidor.

Como cualquier otro componente software, los MPM se generan como módulos dinámicos que pueden ser seleccionados al iniciar el servidor. Como indican en The H Open, mientras que antes estos componentes estaban clasificados como “experimentales”, ahora se han unido a la lista de módulos plenamente funcionales.

También nos hablan de la directiva LogLevel, que ahora se puede configurar para mantener distintos tipos de directorios y de módulos. Otro nuevo módulo integra el lenjuaje de scripting Lua para permitir a los desarrolladores implementar los llamados “request habdlers” en este lenguaje.

Además mod_ssl permite que se usen certificados para ser verificados online a través de OCSP. Como suele suceder con este tipo de versiones preliminares, los desarrolladores recomienzan su uso siempre fuera de entornos de producción.

Podéis encontrar más detalles sobre este lanzamiento en el anuncio oficial y en el registro de cambios, y además podéis descargar Apache 2.3.11 desde la página oficial.

Share
Written by Javier Rodriguez in: Linux,Web | Etiquetas:
Nov
30
2010
0

Sobre discos duros y S.M.A.R.T.



Tenemos un comando en Linux que se llama «smartctl» el cual nos da informacion vital sobre el disco duro consultado. Datos tales como temperatura, horas en funcionamiento, promedio de fallo, etc…

equipo ~# smartctl -a -d ata /dev/sda
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 100 253 006 Pre-fail Always - 0
3 Spin_Up_Time 0x0003 097 097 000 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 67
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 084 060 030 Pre-fail Always - 247181777
9 Power_On_Hours 0x0032 076 076 000 Old_age Always - 21179
... ... ...

Tenemos 4 columnas: VALUE, WORST, THRESH y RAW_VALUE

VALUE es el valor actual que nos da el indicador que debe de ser superior a THRESH. En caso contrario vamos mal, ya que quiere decir que hay algo que está fallando (Old_age fallo típico de disco duro, Pre_fail fallo crítico en 24 horas).

WORST es el valor más bajo que nos ha dado este indicador, se cumple lo mismo que con el anterior, si es más bajo que THRESH, malo.

Y ahora viene el rollo del normalizado.

RAW_VALUE es el valor sin normalizar del indicador, la forma más fácil de explicarlo es con el valor de Power_On_Hours, horas que lleva el disco encendido.

Por ejemplo, el disco viene de fábrica con una vida útil de 100.000 horas, puede durar más o menos, pero en estudios que hemos hecho hemos observado unos porcentajes.

Hasta 30.000 horas falla el 1%
Hasta 50.000 horas falla el 5%
Hasta 70.000 horas falla el 15%
Hasta 95.000 horas falla el 30%
Hasta 100.000 horas falla el 55%
Hasta 120.000 horas falla el 80%
Hasta 130.000 horas falla el 100%

El RAW_VALUE puede contener cualquier cosa (horas, segundos, lunas, periodos de 18.3 segundos…) aquí cada fabricante guarda lo que el estima oportuno, pero este RAW_VALUE me lo tiene que traducir a un valor normalizado. Siguiendo el ejemplo anterior el número de horas lo puede traducir a los valores 100,99,98,97,96,95,94 con un THRESH situado en el 96. ¿por qúe de 100 a 94? porque el fabricante lo decide así, podría haber sido de 60 a 54 o de 100 a 0 con intervalos más grandes, logicamente el THRESH se mueve en la misma escala.

¿Y el RAW_VALUE?
Como he dicho el valor del RAW lo decide cada fabricante, que marque 60 en temperatura no indica obligatoriamente que el disco esté a 60 grados, pueden haber comenzado la escala a -10 grados, emplear grados farenheit o cualquier otra medida. Lo importante es que el valor normalizado (43 en tu caso, sean los grados que sean) es inferior al THRESH establecido para ese disco (45)

Hay algunos fabricantes que si que ofrecen la interpretación exacta del RAW_VALUE pero pocas veces necesitamos conocer tanto detalle .

Share
Written by Javier Rodriguez in: Linux | Etiquetas:
Oct
22
2010
0

WordPress y los ataques DoS



De aquí a un tiempo he visto algunos scripts bastante simples que, sorprendentemente, hacen bastante daño a malas configuraciones de sitios con wordpress. El sistema de DoS (Denial of Service, Denegación de Servicio) que se usa para el ataque es de tipo flood (inundación) enviando un número muy alto de peticiones. Por ejemplo: Under Security.

Normalmente, estos scripts se realizan buscando las peticiones más lentas de los sistemas web. Una vez detectadas, se procede a lanzar muchas de estas peticiones en muy poco tiempo. Los servidores web, ante una avalancha de peticiones, normalmente, comienzan a crear forks o workers (según el servidor y modo de funcionamiento) hasta llegar al límite máximo configurado… o a que se sature el sistema y termine no respondiendo.

Los sistemas GNU/Linux, al igual que la mayoría, tienen un uso de memoria limitada por el tamaño de la misma que haya instalada. Estos sistemas manejan una caché bastante grande y por ello, aunque se tenga 1GB o más instalado en el sistema, siempre se anda con una ocupación bastante alta de la memoria del sistema. Cuando esta se agota, se recurre a la memoria de intercambio (swap), que es mucho más lenta que la memoria convencional, por lo que el sistema comienza a ralentizarse.

Para evitar estos problemas, lo ideal es configurar de forma adecuada el servidor web, acorde a la memoria disponible, el número máximo de hilos que se puedan crear y el número máximo de forks o workers que se puedan lanzar para atender peticiones. Con esto evitamos que la memoria se use en exceso y, aunque las peticiones se atiendan más lentas, se asegure que el sistema permanecerá estable.

También habría que revisar la pila de entrada TCP para el puerto 80 (se puede ver a través de netstat en cualquier sistema GNU/Linux), por si acaso se saturase mucho, comenzar a cortar, vía cortafuegos (iptables), las direcciones IP que estén haciendo flood.

Fuente: Bosque Viejo

Share
Written by Javier Rodriguez in: Linux,Web | Etiquetas: , , , , ,
Ago
15
2010
0

Múltiples VirtualHost en SSL en una única IP (SNI)



Resumiendo mucho el funcionamiento de los VirtualHost en Apache, se puede decir que el cliente (nuestro navegador) envía al servidor el nombre del dominio al que deseamos acceder y Apache lo busca en sus configuraciones para entregarte la web. De esta forma en un solo servidor podemos tener alojados múltiples páginas web, cada una con su VirtualHost.

GET /blog/ HTTP/1.1
Host: javirodriguez.com.es
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; es-ES; rv:1.9.0.6) Gecko/2009020911 Firefox/3.0.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: es,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

Pero la cosa cambia si las webs deben ser transmitidas mediante HTTPS, esto es, estableciendo una conexión SSL. Gracias a esta tecnología es posible que todo el tráfico entre el servidor y nuestro navegador vaya cifrado y esta es la raíz del problema. Al tener todos los datos cifrados, el servidor no puede saber que dominio está pidiendo el navegador, por lo que los VirtualHost en base a nombres (dominios) pierden utilidad. Para paliar este problema, se ponían múltiples IPs en el servidor y se asignaba cada IP a un VirtualHost. De esta forma, cada web HTTPS tenia como destino una IP distinta y así el servidor era capaz de darte la web que estabas buscando. Esto es, se pasaba de tener VirtualHost por nombre a tenerlos por IP. Si tenías dos páginas web esto no era problema, pero si tenías 200… acelerarías la implantación de IPV6 y eso no es bueno 😉

Para solucionar este problema se publicó en 2006 el RFC 4366. En resumen, TLS pasaba a tener extensiones a nivel cliente y servidor. Una de las cuales permite que el cliente en el establecimiento de la conexión (antes de comenzar el cifrado) pueda indicar el dominio al que desea acceder. La que nos hace la magia es SNI. Para que esto funcione es necesario cumplir una serie de requisitos:

  • OpenSSL 0.9.8f o posterior con extensiones TLS (enable-tlsext)
  • Apache compilado con dicho OpenSSL
  • Navegadores Mozilla Firefox 2.0, Opera 8.0 Internet Explorer 7.0, Google Chome, Safari 3.2.1

Para activar esta extensión añadimos la siguiente línea a httpd.conf:

SSLStrictSNIVHostCheck on

Una vez hecho configuraríamos nuestros VirtualHost SSL como si fuesen los de toda la vida (sin SSL).

Listen 443
NameVirtualHost *:443
<VirtualHost *:443>
        ServerName test1.javirodriguez.com.es
        ServerAlias test1.javirodriguez.com.es
        DocumentRoot /var/www/test1
        Options FollowSymLinks
        <Directory /var/www/test1>
        AllowOverride All
        </Directory>
        ErrorLog /var/log/apache2/test1error.log
        CustomLog /var/log/apache2/test1access.log combined env=!client-ip-request
        SSLEngine on
        SSLCertificateFile /etc/ssl/test.pem
        SSLCertificateKeyFile /etc/ssl/test.key
</VirtualHost>
<VirtualHost *:443>
        ServerName test2.javirodriguez.com.es
        ServerAlias test2.javirodriguez.com.es
        DocumentRoot /var/www/test2
        Options FollowSymLinks
        <Directory /var/www/test2>
        AllowOverride All
        </Directory>
        ErrorLog /var/log/apache2/test2error.log
        CustomLog /var/log/apache2/test2access.log combined env=!client-ip-request
        SSLEngine on
        SSLCertificateFile /etc/ssl/test.pem
        SSLCertificateKeyFile /etc/ssl/test.key
</VirtualHost>

Si vemos el siguiente error en los logs de Apache es que nuestro navegador no es compatible:

[error] No hostname was provided via SNI for a name based virtual host

Y listo, ya puedes tener múltiples VirtualHost con SSL en una única IP 🙂

Fuente: Miguel Angel Nieto

Share
Written by Javier Rodriguez in: Linux,Web | Etiquetas: , , , ,

Theme: TheBuckmaker.com Blog Themes | Hostpapa customer, Berlin