Rincón Informático

Cuando instalamos por primera vez en un computador portátil o en cualquier otro tipo de computador nuestro Debian/Squeeze se hace casi que necesario empezar a personalizarlo y eso incluye que nuestro computador arranque de una manera más eficiente y más rápida, para esto. Navegando por la web de esdebian.org me he encontrado con este tutorial que nos dice lo que debemos hacer para lograr este cometido, quise compartirlo con ustedes,  el tutorial es muy sencillo, aunque en la pagina hablan de que es para Debian/lenny yo lo he probado en Debian/Squeeze y funciona muy bien logró arrancar mi sistema en 23 segundos ya ustedes tomarán la decisión de seguir el tutorial o no. Así que no más carreta y manos a la obra.

Paralelismo en los scripts de init.d

Nota: Esta opción sólo proporciona una mejora notable en procesadores de más de un núcleo

Cuando arrancas algún sistema Debian este busca en /etc/init.d/rc para ejecutar los servicios que hayas configurado.

El problema es que no es muy efectivo que se ejecuten uno por uno. Por ejemplo, si tienes un servicio dhcp que tiene que esperar a que se te asigne una IP, retrasaría todo el proceso.

Pero hay que tener cuidado ya que muchos servicios dependen de otros para arrancar, entonces necesitamos un script que organice el arranque para que se puedan iniciar procesos en paralelo. Dicho script se consigue instalando el paquete insserv:

Atención: Este script modifica automáticamente el sistema de arranque de Debian, úsalo bajo tu propia responsabilidad.
#apt-get install insserv
#dpkg-reconfigure insserv

Por último queda decirle al script rcS que utilice esta opción:
CONCURRENCY=startpar >> /etc/default/rcS

Quitar servicios innecesarios

Suena lógico que, si no usas compartición de archivos, o que si tu máquina no tiene bluetooth, quites esos servicios. ¿Pero cómo hacerlo? En Debian hay dos maneras uno ir a /etc/init.d/ y quitas los permisos de ejecución a los scripts de servicios que consideres innecesarios:

#chmod -X nombre-del-servicio

Obviamente debes estar trabajando en el mismo directorio donde esta el servicio.
Ahora la otra manera es con la herramienta Smart Boot Manager, se instala
#apt-get install bum

La ejecutas y tendrás una GUI muy linda para configurar los servicios de arranque incluso, en la mayoría de los casos, te explica para qué sirve cada servicio.

Readahead

Usar Readahead es un herramienta que guarda un registro de ciertos archivos del proceso de arranque de forma que cuando se inicie Debian, el sistema leerá sólo el registro y no buscará los archivos, obteniendo una ligera reducción del tiempo de carga.
#apt-get install readahead
#touch /etc/readahead/profile-once

Con ello instalas readahead, lo segundo es para crear un perfil (profile) optimizado del proceso de arranque de nuestra máquina y servicios

Después de todo este relajo reinicias y no te asustes la primera vez que reinicies durará más de lo normal porque readahead está creando el perfil (profile). Luego de esto vuelve a reiniciar una vez más y verás cómo el proceso de arranque se reduce.

Bueno eso es lo que quería compartir con ustedes espero y les sea de utilidad, hasta la próxima.

Fuente

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.

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

Algunas veces resulta muy molesto trabajar con archivos  de texto  demasiado grandes, ya que para visualizarlos el sistema debe cargar  el archivo completo en la memoria de nuestra maquina,  si estamos trabajando con archivos  de 10 millones de lineas en adelante,  al abrirlo este consumira demasiada memoria y hará que nuestro sistema colapse por completo.

Para solucionar este incomodo problema, los entornos unix traen una utilidad llamada split, la cual nos ayuda como su nombre lo indica a dividir o partir un archivo de texto el cual sea demasiado grande.

La sintaxis de split es:

split [parámetros opcionales] [archivo de entrada] [archivo de salida]

Entre los parámetros tenemos:

• -l -> numero de lineas en las que se va a dividir o partir el archivo por defecto son 1000
• -b -> divide el archivo no por lineas, sino por tamaño (expresado en bits)
• -b k n -> divide el archivo no por lineas, sino por tamaño (donde n es un multiplo de 1024 bytes)

Después de los parámetros,  le damos el archivo de entrada y un nombre de salida,  hay que aclarar que el archivo de salida tendrá la siguiente notación:

nombrea nombreb nombrec nombred nombree nombref etc……

Algunos ejemplos:

split -l 5000 diccionario.txt parte-

Esta sentencia me arrojara  lo siguiente:

parte-a parte-b parte-c  hasta que el archivo quede completamente dividido-

Algo muy sencillo pero util,  trabajar con backups o archivos de textos que este en el orden de los millones. Por ultimo si alguien posteriormente desea  pegar las partes lo puede hacer muy facilmente usando cat.

cat parte-a parte-b parte-c > todocompleto.txt

Trabajando en un proyecto personal (que pronto les contare en que consiste),  me surgió la necesidad de optimizar al máximo el servidor MySQL, es decir, necesitaba configurar el servidor MySQL  de una forma adecuada para que soportara todo el trabajo necesario.  Navegando en la red, me encontré con este articulo,  en el cual nos comparten una configuración óptima para nuestro servidor  MySQL (lo que estábamos buscando).  Implemente este archivo de configuración,  y desde ese momento mi servidor ha mejorado en cuanto a rendimiento, disponibilidad y eficiencia.

Por esta razón comparto el archivo de configuración por si  alguno tiene el mismo problema, en este archivo se hacen modificaciones principalmente, en el tamaño de la memoria,  conexiones concurrentes y otros aspectos:

[mysqld]
 socket=/path/to/mysql.sock
 datadir=/var/lib/mysql
 skip-locking
 skip-innodb
 # MySQL 4.x has query caching available.
 # Enable it for vast improvement and it may be all you need to tweak.
 query_cache_type=1
 query_cache_limit=1M
 query_cache_size=32M
 # max_connections=500
 # Reduced to 200 as memory will not be enough for 500 connections.
 # memory=key_buffer+(sort_buffer_size+read_buffer_size)*max_connections
 # which is now: 64 + (1 + 1) * 200 = 464 MB
 # max_connections = approx. MaxClients setting in httpd.conf file
 # Default set to 100.
 #max_connections=200
 #interactive_timeout=180
 interactive_timeout=100
 #wait_timeout=180
 #wait_timeout=100
 # Reduced wait_timeout to prevent idle clients holding connections.
 #wait_timeout=30
 wait_timeout=15
 connect_timeout=10
 # max_connect_errors is set to 10 by default
 #max_connect_errors=10
 #table_cache=256
 #table_cache=1024
 # Checked opened tables and adjusted accordingly after running for a while.
 table_cache=512
 #tmp_table_size=32M by default
 #thread_cache=128
 # Reduced it to 32 to prevent memory hogging. Also, see notes below.
 thread_cache=32
 # key_buffer=258M
 # Reduced it by checking current size of *.MYI files, see notes below.
 key_buffer=128M
 # Commented out the buffer sizes and keeping the default.
 # sort_buffer_size=2M by default.
 #sort_buffer_size=1M
 # read_buffer_size=128K by default.
 #read_buffer_size=1M
 # read_rnd_buffer_size=256K by default.
 #read_rnd_buffer_size=1M
 # myisam_sort_buffer_size=8M by default.
 #myisam_sort_buffer_size=64M
 # thread_concurrency = 2 * (no. of CPU)
 thread_concurrency=2
 # log slow queries is a must. Many queries that take more than 2 seconds.
 # If so, then your tables need enhancement.
 log_slow_queries=/var/log/mysqld.slow.log
 long_query_time=2
 [mysql.server]
 user=mysql
 basedir=/var/lib
 [safe_mysqld]
 err-log=/var/log/mysqld.log
 pid-file=/var/run/mysqld/mysqld.pid
 open_files_limit=8192

[mysqldump]
 quick
 max_allowed_packet=16M
 [mysql]
 no-auto-rehash
 # Remove the next comment character if you are not familiar with SQL
 #safe-updates
 [isamchk]
 key_buffer=64M
 sort_buffer=64M
 read_buffer=16M
 write_buffer=16M
 [myisamchk]
 key_buffer=64M
 sort_buffer=64M
 read_buffer=16M
 write_buffer=16M
 [mysqlhotcopy]
 interactive-timeout 
 [client]
 socket=/path/to/mysql.sock

Para  aplicar esta configuración,  lo podemos hacer de varias formas:

• Abrimos el archivo /etc/mysql/my.cnf borramos todo su contenido y por ultimo pegamos el contenido de esta configuracion. ( No sobra decir que debemos guardar).

• Por otro lado  podemos borrar el archivo /etc/mysql/my.cnf, descargamos el nuevo archivo desde aca y lo copiamos en la misma ubicacion.

nota: cabe aclarar que no soy un experto en el tema, simplemente doy mis comentarios apartir de la experiencia que tuve usando esta configuracion,   si alguien tiene un archivo my.cnf mas optimizado seria esplendido que lo compartiera con todos nosotros

Para mas informacion pueden ir a este enlace

Es una pregunta que ya me había hecho hace tiempo, si era posible usar una imagen iso como repositorio y no tener que estar usando los CD’s/DVD’s  (Algo muchas veces molesto, más si se trata de CD’s).

Pues bueno las ventajas que presenta usar las imágenes iso son bastante claras, ya que no tendremos la necesidad de estar insertando y sacando los CD’s/DVD’s de la unidad, a demás de ahorrarnos unos cuantos CD’s/DVD’s.

Preparando lo necesario

- Necesitamos un directorio por cada CD’s/DVD’s. Podríamos crear una directorio llamado ‘repositorio‘ en /media que contenga a los demás.

# mkdir  /media/repositorio

Ahora dentro de ‘repositorio’ creamos el resto de carpetas donde serán montadas las imágenes iso.

# mkdir  /media/repositorio/[CD1 o DVD1]

# mkdir  /media/repositorio/[CD2 o DVD2]

…

# mkdir  /media/repositorio/[CDn o DVDn]

En mi caso los directorios quedarían así:

# ls  /media/repositorio

cd1 cd2  cd3  cd4  cd5  cd6  cd7  cd8

- Debemos conocer la ubicación de las imágenes iso (La ubicación realmente no importa).

En mi caso: /media/repositorio-isos

Modificando el archivo fstab

#vim  /etc/fstab

Al final del archivo añadimos los siguiente:

/media/RUTA/IMAGEN1.iso  /media/repositorio/[CD1 o DVD1]  iso9660  loop,user,auto  0  0

Para cada imagen debe haber una línea como esta indicando respectivamente la imagen iso y el directorio donde será montada.

Ejemplo:

#Repositorio imagenes-iso
/media/repositorio-isos/debian-testing-i386-CD-1.iso  /media/repositorio/cd1  iso9660 loop,user,auto  0  0
/media/repositorio-isos/debian-testing-i386-CD-2.iso  /media/repositorio/cd2  iso9660 loop,user,auto  0  0
/media/repositorio-isos/debian-testing-i386-CD-3.iso  /media/repositorio/cd3  iso9660 loop,user,auto  0  0
/media/repositorio-isos/debian-testing-i386-CD-4.iso  /media/repositorio/cd4  iso9660 loop,user,auto  0  0
/media/repositorio-isos/debian-testing-i386-CD-5.iso  /media/repositorio/cd5  iso9660 loop,user,auto  0  0
/media/repositorio-isos/debian-testing-i386-CD-6.iso  /media/repositorio/cd6  iso9660 loop,user,auto  0  0
/media/repositorio-isos/debian-testing-i386-CD-7.iso  /media/repositorio/cd7  iso9660 loop,user,auto  0  0
/media/repositorio-isos/debian-testing-i386-CD-8.iso  /media/repositorio/cd8  iso9660 loop,user,auto  0  0

Modificando el archivo sources.list

Ahora para que apt use las imágenes como repositorio debemos indicar en este archivo donde esta montado cada CD’s/DVD’s de nuestro repositorio.

# vim  /etc/apt/sources.list

Agregamos lo siguiente:

deb file:///media/repositorio/[CD1 o DVD1] squeeze main contrib

Cambia ’squeeze’ por la versión de Debian que uses.

Ejemplo:

#Repositorio imagenes-iso
deb file:///media/repositorio/cd1 squeeze main contrib
deb file:///media/repositorio/cd2 squeeze main contrib
deb file:///media/repositorio/cd3 squeeze main contrib
deb file:///media/repositorio/cd4 squeeze main contrib
deb file:///media/repositorio/cd5 squeeze main contrib
deb file:///media/repositorio/cd6 squeeze main contrib
deb file:///media/repositorio/cd7 squeeze main contrib
deb file:///media/repositorio/cd8 squeeze main contrib
##END

Si no lo has hecho debes montar las imágenes:

# mount  -a

Y por último:

# aptitude  update

A mí me han aparecido varios errores como este, después de actualizar los repositorios:

Err file: squeeze/contrib Packages
Fichero no encontrado

Pero esto no perjudica el funcionamiento correcto de el repositorio.

Compartir este repositorio para toda la red local

Este punto ofrece una utilidad enorme, imagínate actualizar todos los computadores de una red local a través de un solo computador que actúe como servidor del repositorio. Pues es muy sencillo:

Supongamos que con los pasos de arriba configuramos el repositorio y que ese computador será el servidor.

Ip: 192.168.1.1

Nota: Debemos tener configurado un servidor Apache.

En el servidor

Aquí crearemos enlaces simbólicos a cada uno de los directorios en donde se encuentran montadas las imágenes iso. Esto lo hacemos en el directorio /var/www de Apache.

#cd  /var/www

Cambias si es necesario la ruta del directorio por la tuya.

/var/www# ln  -s  /media/repositorio/cd1

/var/www# ln  -s  /media/repositorio/cd2

…

Recuerda un enlace por cada directorio.

En los clientes

En cada uno de los clientes debemos modificar el archivo /etc/fstab

#vim  /etc/fstab

Agregamos por cada enlace simbólico una línea como esta:

deb http://192.168.1.1/[NOMBRE_ENLACE] squeeze main contrib

Como puedes ver accedemos al repositorio con la ip del servidor y el nombre del enlace simbólico que apunta a cada una de los directorios donde montamos las imágenes.

Ejemplo

deb http://192.168.1.1/cd1 squeeze main contrib
deb http://192.168.1.1/cd2 squeeze main contrib
deb http://192.168.1.1/cd3 squeeze main contrib

Actualizamos repositorios y listo . Hasta la próxima!!

Siguiendo con los ataques de fuerza bruta. Hemos hablado anteriormente de medusa, la herramienta que nos permite realizar el ataque, sin embargo  hay algo fundamental que  sin el, no seria posible realizar el ataque. ¿Que es?  Si estoy hablando de los diccionarios.  estos archivos de texto son muy importantes a la hora de  lanzar un ataque de fuerza bruta de este tipo, con un robusto y amplio diccionario muy pocas contraseñas se escaparan, ya que   según las estadísticas  muy pocas personas asignan contraseñas dificiles, mezclando  letras números y caracteres especiales, la mayoría se sienten demasiados seguros con una  palabra en minúsculas como contraseña.

En esta ocasión quiero compartir con ustedes  una recopilacion de diccionarios en español,  para  realizar los ataques de fuerza bruta. Consta de dos paquetes, a continuación se encuentran los links de descarga:

Parte 1
Parte 2

Cada parte consta de 5 diccionarios de todos los colores y sabores, espero que les sirvan y los aprovechen y recuerden la regla de oro para un ataque de fuerza bruta con diccionario:

la efectividad de un ataque con diccionario es directamente proporcional al tamaño del diccionario, es decir, entre mas grande sea el diccionario mayor sera la probabilidad de encontrar la contraseña.

Seguramente muchos conocen  hydra: una aplicacion para atacar con fuerza bruta  usando diccionarios,  a diferentes servicios como: ssh, ftp,  mysql entre otros,  sin embargo hydra  no se volvió actualizar, su ultima versión fue  lanzada en el 2006 y aunque todavía funciona muy bien,   tiene muchos problemas en la instalación, debido a las dependencias y sus versiones.

No obstante, existe una aplicacion llamada  medusa que es muy similar ( no exactamente igual) a hydra, la cual nos permite crackear por diccionario de forma rápida, masiva y paralela  los siguientes servicios:

• AFP
• CVS
• FTP
• HTTP
• IMAP
• MS-SQL
• MySQL
• NetWare NCP
• NNTP
• PcAnywhere
• POP3
• PostgreSQL
• REXEC
• RLOGIN
• RSH
• SMBNT
• SMTP-AUTH
• SMTP-VRFY
• SNMP
• SSHv2
• Subversion (SVN)
• Telnet
• VMware autenticación Daemon (vmauthd)
• VNC
• Genérico Wrapper
• Web Form

Algunas de las caracteristicas que nos tiene medusa son:

• Velocidad
• Estabilidad
• Organizacion del código, para comprenderlo facil
• diversidad de servicios (como vieron anteriormente)

Instalación de  Medusa

Antes de instalar  medusa, debemos revisar  que se cumplan las siguientes dependencias:

• OpenSSL
• LibSSH2
• NCPFS
• Libpq
• Subversion
• afpfs-ng

Para los usuarios de debian, esta herramienta se encuentra en los repositorios:

apt-get install medusa

Para los demás usuarios descargan las fuentes desde aca, y compilan:

./configure
make
make install

¿Como crackear password con diccionarios usando medusa ?

Lo primero que debemos hacer es  ver los módulos disponibles,  los módulos son los servicios los cuales podemos atacar, para visualizar los módulos:

medusa -d

Después de estar seguros de que tenemos el modulo adecuado al servicio que deseamos atacar, procedemos a lanzar el ataque. Medusa posee una gran cantidad de parámetros (ojala se tomaran el tiempo para leer el man  con detenimiento).  Los parámetros mas importantes son:

-h -> el host víctima
-H -> si tenemos un archivo txt con una lista de hosts
-u  -> el usuario al cual deseamos hacerle el cracking
-U ->  un archivo txt con la lista de posibles usuarios (muy útil si no sabemos que usuarios existen en el sistema)
-P ->  Ubicación del diccionario
-O  -> Crea un archivo log
- e  ns -> Verifica el password vacio o que ambos datos sean lo mismo
-M  -> El modulo que deseamos emplear (sin la extension .mod)
-n -> por si el servicio esta corriendo en otro puerto diferente al default
-s -> Habilita ssl
-f -> detiene el ataque en el instante de encontrar un password valido
-b -> suprime los banners
-v  -> modo verbose (mas informacion level de 0 a 6 siendo el 6 mas alto)

Ahora practiquemos un poco:

medusa -h 127.0.0.1 -u rincon -P /diccionario.txt -M mysql -L -f -b -v 6

Como pueden ver me estoy atacando yo  mismo obviamente me he asegurado que el password se encuentra en el diccionario, el resultado es sorprendente tardo muy poco (10 segundos aproximadamente), el tiempo depende de varios factores como el tamaño del diccionarios y la ubicacion del password encontrado, ya que se va a demorar mucho menos si el password esta al inicio del diccionario de 36000 palabras.

Ahora muchos diran que no es lo mismo hacer un ataque de fuerza bruta con diccionario de forma local  que de forma remota y tienen mucha razon, sin embargo hicimos  la prueba de forma remota  y los resultados fueron muy aceptables, se demoro 6 minutos en encontrar el password en un diccionario de 500 palabras (con esos datos ya pueden hacer la simple regla de 3) atacando  el ssh

Algunos inconvenientes

Todo no es color de rosa, existen algunos inconvenientes que debemos tener en cuenta antes de realizar un ataque de este tipo:

• No  hay total certeza de encontrar el password, sin embargo la efectividad de un ataque con diccionario es directamente proporcional al tamaño del diccionario, es decir, entre mas grande sea el diccionario mayor sera la probabilidad de  encontrar la contraseña.

• Otro inconveniente, consiste en que algunos sysadmin inteligentes restringen  el numero de intentos de autenticacion a un numero no mayor a 3, asi que si nos topamos con un servidor serio, no podremos aplicar el ataque por fuerza bruta.

• Cuando nos encontramos un servidor “vulnerable” a un ataque de fuerza bruta con diccionario, debemos tener muchisimo cuidado, ya que un ataque de esta naturaleza  hace demasiado “RUIDO” es decir, todos los intentos de conexion quedaran guardados en los logs del servidor, por eso es pertinente usar un proxy para hacer el ataque, o  en su defecto borrar los logs, inmediatamente despues de entrar al server.