Rincón Informático

Con el rápido crecimiento de la tecnología, todos los días vamos acumulando más y más información en nuestros discos duros (HD) y se va haciendo necesario que esta transferencia de datos ya sea desde internet o desde un disco a otro, sea cada vez más rápida y confiable.

Cuando hablamos de transferencias de datos a través de una red, se hace necesario que esta me garantice cierto nivel de calidad de servicio (QoS) para que mis datos no se vayan a ver corrompidos o que simplemente se vayan a perder en la transferencia. Ahora cuando hablamos de transferencias de datos por ejemplo de un disco duro a otro, también se necesita que haya cierto grado de confiabilidad, pero esto nos lleva a otro punto interesante, y es que cuando empezamos a llenar nuestro HD, este guarda nuestros datos de una forma no consecutiva, provocando el fenómeno de la fragmentación, este fenómeno produce que cuando se quiera acceder a ciertos archivos le tome mucho tiempo cuando el HD se encuentra muy lleno, porque los datos se encuentran dispersos por todo el HD, el fenómeno de la fragmentación ocurre en cualquier tipo de sistema de fichero sea NTFS, FAT, ext2, ext3, etc. Pero lo que diferencia el problema de un sistema a otro es la regularidad con la que sucede.

Ahora hablando más explícitamente del sistema de ficheros de Linux ext3 utiliza un esquema de mapeado de bloques. Un fichero de 100 MB será mapeado en 25.600 bloques de 4 KB cada uno. Cuanto más grande sea el fichero, más bloques serán mapeados, algo que hará el manejo cada vez más lento. Ext4 introduce el concepto de Extent. Un extent es básicamente un conjunto de bloques. En nuestro ejemplo para un fichero de 100 MB, se dirá básicamente «escribe los datos en los próximos n bloques». En lugar de mapear cada bloque individual por separado, Ext4 soportará extents de hasta 128 MB, de forma que para un fichero de un 1 GB, se mapearán 10 extents en lugar de 256.000 bloques. Esto mejora el rendimiento y reduce la fragmentación.

Explicación: En nuestro ejemplo de 100 MB, Ext3 utiliza un alojador de bloques que decide qué bloques libres van a ser utilizados para escribir los datos. Pero el alojador puede trabajar sólo de bloque en bloque, lo que significa que nuestro fichero de 100 MB necesitará 25.600 llamadas al alojador. Ineficiente, ¿no? Resulta aún peor darse cuenta de que el alojador no puede optimizar sus políticas porque en realidad no sabe cuántas veces va a ser llamado. No sabe el tamaño del fichero para el que se le está pidiendo que aloje bloques. 

Algunas de las mejoras que podrás encontrar en este nuevo sistema de ficheros serán relacionadas en la siguiente tabla.

El popular blog sobre hardware y Linux Phoronix ha ejecutado unas pruebas extensivas sobre el rendimiento de Ext4 contra otros sistemas de ficheros populares como Ext3, XFS, JFS o ReiserFS. El resultado más impresionante se produjo durante la escritura de un fichero de 4 GB, donde Ext4 literalmente borró al resto de sistemas del mapa.

Bueno esto es todo por el momento, en las próximas entradas se hablara de cómo pasarse de ext3 a ext4 sin necesidad de perder los datos, espero y les haya servido y hasta un próximo artículo.

 Fuente

Existen muchas herramientas como w3af, acunetixo el mismo nessus,  que nos ayudan en el proceso de encontrar vulnerabilidades en  aplicaciones web. Sin embargo hace poco encontré un scanner el cual se especializa en portales Joomla(para quienes no saben que es Joomla hacer click aqui). Tuve la oportunidad de probar la aplicacion  y me gusta bastante, entre sus características tenemos:

• Hecho en Perl
• Permite actualizarse.
• Reporte completo.
• Interfaz web y por consola.
• detecta vulnerabilidades como: SQL injection, LFI, RFI, XSS entre otros.
• Se basa en OWASP.

Para descargar el  script pueden hacer click aqui. Obviamente como es hecho en perl, necesitamos tener instalado perl y algunas librerías:

apt-get install perl libwww-perl libtest-www-mechanize-perl

Para actualizarlo  hacemos lo siguiente:

chmod 777 joomscan.pl

./joomscan.pl update

Hacer un simple escaneo:

./joomscan.pl -u url_joomla

El resultado  que nos arroja es muy explicito, dice la vulnerabilidad, la descripción y si es vulnerable o no. Joomscan un buen script que nos ayuda a  descubrir aquellos  fallos que se pueden explotar en nuestro portal Joomla.

Bueno en esta oportunidad quiero compartir con ustedes esta cheatsheet de Nmap que fue creado por la gente de securitybydefault.

Para los que no saben que es Nmap aquí le dejo una definicion de la wikipedia “Nmap es un programa de código abierto  que sirve para efectuar rastreo de puertos. Se usa para evaluar la seguridad de sistemas informáticos, así como para descubrir servicios o servidores en una red informática.”

Espero y les sea de gran utilidad.

CheatSheet –> Aquí

Fuente –> Aquí

Wikipedia:

CakePhp es un framework de desarrollo de aplicaciones web escrito en PHP, creado sobre los conceptos de Ruby on Rails.

Para más información -> página oficial http://cakephp.org/

Lo primero que necesitamos es una versión de CakePhp Descargar.

Nota: Necesitamos un Servidor Apache.

Una vez descargado y descomprimido el archivo, nos quedará una carpeta con un nombre como este: cake_1.X.X  por facilidad es mejor cambiarle el nombre, podríamos colocarle “cake”.

Debemos copiar la carpeta completa en  /var/www

Ahora probamos en el navegador:

http://localhost/cake

Si nos sale algo como esto:

Significa que no esta debidamente configurado el Servidor Apache.

Configurando el apache

Habilitamos el modulo rewrite.

#  a2enmod  rewrite

Modificamos el archivo   /etc/apache2/sites-available/default

# vim  /etc/apache2/sites-available/default

Buscamos estas líneas:

Options Indexes FollowSymLinks MultiViews

AllowOverride None

Order allow,deny

allow from all

Y cambiamos None por All, quedando así:

Options Indexes FollowSymLinks MultiViews

AllowOverride All

Order allow,deny

allow from all

Por último reiniciamos el Apache

#  /etc/init.d/apache2  restart

Probamos de nuevo en el navegador, y nos debe salir algo como esto (con colores):

Ya podemos empezar a cocinar nuestras recetas !!.

Algunas personas se pueden estar preguntando como se puede configurar CakePhp para ser accedido desde el directorio public_html. Esto se logra indicándole a CakePhp la ruta para que pueda ser visible desde dicho directorio:

Agregamos esta línea  RewriteBase  /~user_dir/cake_install/ en  cake/.htaccess  y también en cake/app/webroot/.htaccess:

user_dir = Directorio personal.

cake_install = Nombre de la carpeta que contiene CakePhp.

#  vim  cake/.htaccess

RewriteEngine on

RewriteBase  /~user_dir/cake_install/

RewriteRule ^$ app/webroot/ [L]

RewriteRule (.*) app/webroot/$1 [L]

# vim cake/app/webroot/.htaccess

RewriteEngine On

RewriteBase /~user_dir/cake_install/

RewriteCond %{REQUEST_FILENAME} !-d

RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]

Colocamos en el navegador:

http://localhost/~usuario/cake

Ahora si a cocinar!! Hasta la próxima.

Wake-on-lan o mas conocido como “WOL”, es un estándar que nos permite encender un PC  de forma remota que  se encuentre en nuestra LAN, con tan solo la direccion MAC de dicho computador. El funcionamiento es simple,  la interfaz del PC apagado quedara a la escucha de algun “magic packet”,  el cual sera mandado por nosotros cuando deseemos encender nuestro PC. Para poder implementar esta tecnología, se deben  tener los siguientes requerimientos:

1. El pc debe estar apagado pero no desconectado (suena obvio, pero es mejor aclarar)
2. La tecnología debe estar soportada por la placa base y  la interfaz de red.
3. Igualmente WOL debe estar habilitada en la BIOS del PC que vamos a encender de forma remota
4. Necesitamos 2 paquetes: ethtool y wakeonlan (se pueden instalar desde los repositorios)

Preparando el PC que vamos a encender.

Lo primero que debemos hacer es verificar que nuestra tarjeta de red, soporte y tenga habilitada la opción de WakeOnLan:

ethtool eth0 // en mi caso la interfaz es eth0, la deben cambiar según sea su interfaz

el resultado debe ser algo como esto:

Si en la opción wake-on (la que esta señalada en la imagen) aparece la d, significa que WOL esta “disable”, para habilitarla hacemos lo siguiente:

ethtool -s eth0 wol g

Comprobamos  haciendo de nuevo el comando de verificacion “ethtool eth0″ y ya en el apartado wake-on nos debe aparecer la letra g.

Ahora que ya sabemos que la tecnología WOL esta habilitada, crearemos el siguiente  script:

## /etc/init.d/wol
#
# chkconfig: 2345 99 99
# description: Force NIC into WOL mode
#
ethtool -s eth0 wol umbg
exit

El nombre de mi script es wol, ahora procedemos hacer lo siguiente:

cp wol /etc/init.d/

chmod 755 /etc/init.d/wol

update-rc.d wol defaults

Listo eso es todo, nuestro PC esta preparado para encenderlo de forma remota,  debemos copiar la mac, ya que ese es el dato para encenderlo, copiamos la mac en cualquier parte y lo apagamos.

Por ultimo en nuestro PC que va servir como remitente del “magic packet” (y que también debe tener el paquete wakeonlan instalado)  tecleamos el siguiente comando para encenderlo.

wakeonlan direccion_mac

Esta tecnología tiene muchas mas opciones y características, les recomiendo que lean e investiguen un poco mas, sobre esto que es muy interesante y sobre todo muy funcional

Una de las herramientas indispensables para administrar los servidores es a través de SSH (Secure SHell). Pero antes, un poco de teoría.

Definición

“SSH (Secure SHell) es el nombre de un protocolo y del programa que lo implementa, y sirve para acceder a máquinas remotas a través de una red. Permite manejar por completo la maquina mediante un intérprete de comandos, y también puede redirigir el tráfico de X para poder ejecutar programas gráficos si tenemos un Servidor X (en sistemas Unix y Windows) corriendo.

Además de la conexión a otros dispositivos, SSH nos permite copiar datos de forma segura (tanto ficheros sueltos como simular sesiones FTP cifradas), gestionar claves RSA para no escribir claves al conectar a los dispositivos y pasar los datos de cualquier otra aplicación por un canal seguro tunelizado mediante SSH” (Wikipedia).

Funcionamiento

El cliente inicia la conexión hacia un puerto predeterminado del servidor, en este caso el puerto reservado número 22. Establecida la conexión TCP los extremos se envían, en texto plano, sus identificadores de versión, para ver si la comunicación es posible entre ellos. De ser compatibles entre sí cambian a un modo de transferencia binaria durante el cual se identifican los interlocutores y se negocian los protocolos de cifrado y firma que se usarán.

Esta negociación de protocolos se lleva a cabo de tal manera que la información intercambiada entre cliente y servidor sólo puede ser descifrada por el destinatario legítimo de la misma, y sólo por él. Para ello al principio de esta fase el servidor envía al cliente su clave pública, para que el cliente la use para cifrar todos los mensajes siguientes hacia el servidor, haciéndolos sólo legibles para el propio servidor. Entonces el cliente genera una clave de cifrado para la sesión en curso, que envía cifrada al servidor junto con el algoritmo seleccionado, y a partir de este momento todo el tráfico entre cliente y servidor viaja cifrado y seguro.

Llegados a este punto el cliente y el servidor se han puesto de acuerdo en un cierto algoritmo de cifrado, han acordado una clave para su sesión, y el servidor se ha identificado ante el cliente con su clave pública RSA (u opcionalmente DSA, en la versión 2 del protocolo). Pero aún falta que el cliente se identifique ante el servidor, que deberá decidir entonces si deja o no acceder al cliente remoto. La identificación del cliente podrá ser mediante pareja de usuario y contraseña, rhost, rhost más identificación de máquina mediante clave RSA o simplemente mediante claves RSA o DSA.

De todos los mecanismos sólo nos interesan el primero y el último. En el primero, el servidor nos dará acceso siempre y cuando la pareja de usuario y contraseña introducida por el cliente sean los de un usuario válido en el sistema operativo del servidor, salvo restricciones adicionales. En la identificación por claves el cliente dispone, al igual que el servidor, de su propia pareja de claves, que envía al servidor durante la identificación. Si el servidor confía en el usuario cuya clave ha recibido, entonces le dará permiso de acceso.

A grandes rasgos el mecanismo de conexión y de identificación del protocolo SSH es sencillo, aunque conviene destacar un par de aspectos relevantes de cara al uso y configuración de los programas relacionados:

• Las conexiones las inicia siempre el cliente hacia el puerto TCP número 22 del servidor.
• Las versiones de los protocolos soportados por cliente y servidor deben coincidir, o la conexión no se llevará a cabo.
• El servidor siempre necesita disponer de una pareja de claves, puesto que usa la clave pública para establecer la conexión segura con el cliente. El tipo de clave tiene que estar soportado en el cliente.
• El cliente y el servidor deben tener algún algoritmo de cifrado en común, o la conexión no se establecerá.
• Dependiendo de los mecanismos de identificación soportados por ambas partes, o exigidos por el servidor, la identificación podrá o no fallar.
• Aún cuando haya un mecanismo de identificación soportado por ambas partes, el cliente deberá proporcionar credenciales válidas al servidor, bien sea una pareja de usuario y contraseña, bien una clave pública.

Al margen de todo lo anterior, el servidor del protocolo SSH, sshd podrá implementar restricciones adicionales de acceso, así como el propio sistema operativo donde ejecuta. Por ejemplo, no es infrecuente que sshd esté compilado con soporte de TCP-wrappers, que esté configurado para aceptar o rechazar el acceso a determinados usuarios o máquinas cliente, o simplemente que algún firewall intermedio no permita establecer la conexión.

Instalación y configuración inicial

1.-Abrir una terminal como root y escribir:

# Apt-get install openssh-server

2.-Cuando se termina de instalar viene con una configuración por default que debemos cambiar para tener una mejor seguridad para esto nos vamos al archivo /etc/ssh/sshd_config

# Vim /etc/ssh/sshd_config

El archivo es algo extenso solo se mencionaran las secciones que son de gran importancia:

El servicio SSH por default trabaja sobre el puerto 22 pero se puede cambiar:

Port 22 ## PUERTO POR DEFAULT

El parámetro ListenAddress especifica las direcciones de las interfaces de donde se van a recibir peticiones OJO con esta sección si vamos a accesar desde una red externa como la casa entonces dejarlo como esta sino pues hay que especificar la red:

ListenAddress 0.0.0.0 ## IP por Default para acceder desde cualquier red

Esta es la sección critica a mi manera de ver porque indicamos si el usuario ROOT puede acceder vía ssh yo en lo personal lo deshabilito y entro con un usuario del sistema diferente a root

PermitRootLogin no

También podemos especificar si se va a ejecutar aplicaciones graficas mediante SSH por ejemplo podemos usar VLC a través de SSH por si no son muy dados a usar comandos yo lo dejo como esta:

X11Forwarding no

Otra opción es permitir el acceso a ciertos usuarios de la siguiente manera:

AllowUsers tusuario, miotrousuario, uncolado

En fin son muchas las opciones que trae el archivo seria bueno que le echaran un vistazo y modifiquen lo que mejor crean ustedes que es para su servidor pero siempre pensando en la seguridad y los riesgos que conlleva hacer una mala configuración.

Por último reiniciamos el servicio:

# /etc/init.d/ssh restart

NOTA: Si están detrás de un firewall tienen que abrir el puerto que han especificado pero si están en DMZ pues les recomiendo que pongan reglas IPTABLE por seguridad.

Ahora a hacer un test desde un cliente usando el terminal:

# Ssh usuario@midominio

Cuando se logueen verán lo siguiente:

También se pueden conectar desde un Windows utilizando la herramienta Putty

Mas info sobre configuración: Aquí

Fuente: Aquí

Descargar el Putty: Aqui

Revisando mis feeds me encuentro con un articulo de lo más interesante y quise compartirlo con ustedes, sin más preambulos aqui se los dejo.

Hay que migrar el site foo.com del servidor A al servidor B, no podemos tener el site caido mucho tiempo mas allá de unos pocos minutos (lo que tardamos en hacer un dump de los datos y una copia de ficheros), tampoco queremos cambiar el dominio del site (por ejemplo usando una redirección del estilo.foo.com a new.foo.com).

Resumiendo: queremos que todas las peticiones que entren al servidor A para el virtual host foo.com le lleguen al servidor B que tiene tambien configurado ese mismo dominio en sus virtual hosts.

Afortunadamente Apache 2 es el servidor web del dominio foo.com.

¿Como lo hacemos?

Voy a proponer una solución al problema utilizando mod_proxy:

Añadimos estas 3 lineas a la configuración del servidor A.

ProxyPass / http://192.240.2.93/
ProxyPassReverse / http://192.240.2.93/
ProxyPreserveHost On
Explicamos para que sirven los parametros:

ProxyPass redirige la petición del servidor A a la ip del servidor B.
ProxyPassReverse cambia la URL en las cabeceras Location, Content-Location y URI de las respuestas HTTP redirect. Se utiliza para que la respuesta de la petición vaya al cliente a traves del host A, lo cual es muy util cuando redirigimos peticiones a hosts en una red privada que no tienen acceso a internet. En nuestro caso esta directiva es opcional y podemos decidir que sea el host B el que responda al cliente directamente.
ProxyPreserveHost mantiene la cabecera Host de la petición en la redirección al servidor B, esta pensado especificamente para poder hacer redirecciones a servidores que utilicen virtual hosts basados en nombres de dominio.
En el host B tenemos que tener una configuración similar a esta para que acepte las peticiones que le entran desde el servidor A:
<virtualhost *:80>
ServerName foo.com
DocumentRoot /var/www/foo
<directory “/var/www/foo”>
Order allow,deny
Allow from all
</directory>
ErrorLog /var/log/apache2/foo.err
CustomLog /var/log/apache2/foo.log combined
</virtualhost>

Fuente – Linux para todos

Podríamos definir Google Dorks como búsquedas avanzadas mediante el uso de operadores complejos que google pone a nuestra disposición, mediante el uso de estas facilidades podemos ahorrarnos el trabajo de buscar vulnerabilidades y dejar que google nos muestra las que encontró y tiene indexadas.

Advertencias, estos datos solo se proveen con fines educativos, el mal uso de los mismos es pura responsabilidad de cada uno.

Vamos con unos ejemplos

Dorks para búsqueda de shells

safe-mode: off (not secure) drwxrwxrwx c99shell
inurl:c99.php
inurl:c99.php uid=0(root)
root c99.php
“Captain Crunch Security Team” inurl:c99
download c99.php
download c99.php
download c99.php
inurl:c99.php
inurl:c99.php
allinurl: c99.php
inurl:c99.php
allinurl: c99.php
inurl:”/c99.php”
allinurl: c99.php
inurl:c99.php
inurl:”c99.php” c99shell
inurl:c99.php uid=0(root)
c99shell powered by admin
c99shell powered by admin
inurl:”/c99.php”
inurl:c99.php
inurl:c99.php
inurl:c99.php

Dorks para hacking de contraseñas

Filetype: htpasswd htpasswd

Intitle:”Index of” “.htpasswd” -intitle:”dist” -apache -htpasswd.c

index.of.private (algo privado)

Intitle:index.of master.passwd

inurlasslist.txt (Para encontrar listas de passwords)

intitle:”Index of..etc” passwd

intitle:admin intitle:login

“Incorrect syntax near” (SQL script error)

intitle:”the page cannot be found” inetmgr (debilidad en IIS4)

intitle:index.of ws_ftp.ini

“A supplied argument is not a valid PostgreSQL result” (possible debilidad SQL)

_vti_pvt password intitle:index.of (Frontpage)

inurl:backup intitle:index.of inurl:admin

“Index of /backup”

index.of.password

index.of.winnt

En este archivo podrás encontrar más ejemplos de google dorks: Dorks

En esta web podrás encontrar más recursos –> AQUI

Fuente

El día de hoy vamos a proceder a instalar una sencilla pero potente herramienta para mantener nuestro equipo o servidor a salvo de rootkits.

Primero un poquito de teoría ¿que es un rootkit? según la Wikipedia “Un rootkit es una herramienta, o grupo de ellas que tiene como finalidad esconderse a sí misma y esconder otros programas, procesos, archivos, directorios, claves de registro, y puertos, que permiten al intruso mantener el acceso a un sistema, para remotamente comandar acciones o extraer información sensible. Existen rootkits para una amplia variedad de sistemas operativos, como GNU/Linux, Solaris o Microsoft Windows.”

Ahora vamos a instalar y configurar rkhunter que es probablemente la herramienta más completa para detectar rootkits

# apt-get install rkhunter

Para realizar un escaneo de nuestro sistema:

# rkhunter -c

Para actualizar la base de datos de rkhunter:

# rkhunter – -update

Los logs los podemos encontrar en /var/log/rkhunter.log donde podremos ver con mas calma el resultado del scaneo.

Fuente 1

Fuente 2