jueves, 10 de junio de 2010

DD-WRT en el Router Buffalo

Instalación de DD_WRT en el enrutador Buffalo WHR-G54S y WHR-HP-G54 Usa solo v24 SP2
final o posterior. versiones anteriores pueden provocar problemas!

1. Por precaución, resetea a valores de
fábrica presioando el boton de reseeo mientra enchufas el router. Mantenlo presionado *por lo menos* 30 segundos. desconecta el router.

2. Conecta tu computador directamente a uno de los puertos LAN del
router. (puedes usar un Cable cruzado o punto a punto). No conectar al puerto WAN

3. Debido a que el Buffalo comienza con 192.168.11.1(o 192.168.12.1 para
WZR-RS-G54), la IP de tu computador necesita estar en la subred
192.168.11.0/24 subred (ej. 192.168.11.2, mascara 255.255.255.0 o
192.168.12.2, mascara 255.255.255.0 para WZR-RS-G54). Tendras que poner una
IP estática. *Una IP estática es crítica para que el proceso de tftp
funcione; una IP dinámica no funcionará aun cuando esté en la subred
correcta.
El IP estático es obligado. El problema es que el TFTP server del router no funciona luego de haber arrancado 100% (momento que el dhcp le entregaría el IP al PC)

4. Abre una nueva linea de comandos. Inicio->Ejecutar->"cmd".

5. Cambia de directorio al que contiene la imagen del firmware. (Ej. cd
C:\Documents%20and%20Settings\All%20Users\Escritorio (si guardaste el
archivo .bin en el Escritorio)

6. Preparate para enviar el firmware mediante el comando TFTP.

7. Escribe tftp -i 192.168.11.1 PUT (nombre de la imagen de
firmware)como: tftp
-i 192.168.11.1 PUT dd-wrt.v23_generic.bin. (Para WZR-RS-G54 usa
192.168.12.1 como ip del router.). El comando debe ser ejecutado al segundo (1 seg) de haber enchufado el router. NO ESPERAR QUE EL ROUTER ARRANQUE

8. Lee los siguientes pasos para tener una idea de la secuencia.

9. Conecta el cable de poder del Buffalo.

10. Todos los LEDS se iluminarán.

11. Despues de un segundo mas o menos, todos los LEDs excepto el en que
estás conectado se apagarán. Ahora es cuando presionas Enter para ejecutar
el comando.

12. El LED en el puerto LAN comenzará a parpadear rapidamente por unos 6
segundos. El comando se completará con un mensaje de exito, como Transfer
successful: 3602080 bytes in 6 seconds, 720416 bytes/s

13. El router comenzará a cargar DD-WRT, espera hasta que el las luces de
puente/diagnosticos se apaguen.

14. En este punto, el router estara listo para ser usado. No hay
necesidad de reiniciarlo (desenchufar/enchufar), aunque es una saludable
precaución.

15. El router será ahora accesible en 192.168.1.1 mascara 255.255.255.0.
Tendras que cambiar tu IP a este rango para realizar la configuración.

16. El nombre de usuario es 'root' y la contraseña 'admin'. Sin embargo hoy en día al entrar a dd-wrt por primera vez solicita introducir el username que uno desee y el password que uno desee.

miércoles, 19 de mayo de 2010

Almacenar el referer en los logs de Apache

Problema:
Tengo un servidor Apache y deseo almacenar el HTTP Referer

Solución:
Apache por defecto guarda lo que se conoce como "common logs". Estos logs no almacenan la variable Referer que viene en el paquete http al momento de conectarse a tu servidor. La solución es tan sencilla como cambiar la palabra common por combined en la configuración del servidor Web.

Procedimiento:
Dentro del httpd.conf (o donde se guarda la configuración de tu dominio) cambiar:
CustomLog logs/mysite.log common
por
CustomLog logs/mysite.log combined

Lo anterior puede ser hecho por VirtualHost o dentro de todo el servidor Web.

Reiniciar el servicio de Apache y listo!

Suerte!.

lunes, 10 de mayo de 2010

Script en Bash para conseguir errores 404 dentro de un servidor Web

Escenario:
Tengo mi servidor Web Apache sobre Linux y quiero revisar los errores 404 (página no encontrada) o broken link de los usuarios que acceden a mi servidor.

Solución:
Ejecutar un script mediante el crontab cerca de la media noche que revise el archivo access_log del Apache con el contenido 404 y envie un correo a un destinatario.

Script:
#El objectivo de este script es revisar errores 404 dentro de los logs del WebServer
#para de esta manera evitar "broken links". Alejandro Acosta
#Notese que se ejecuta casi a la media noche para conseguir TODOS los errores 404 del dia
FECHA=`date +"%d/%b/%Y"`
cat /usr/local/apache/logs/access_log | grep $FECHA | grep " 404 " > /tmp/404.txt
#Entra en el if unicamente en caso de conseguir errores 404
if [ $? = "0" ]; then
echo $?
mail -s "Errores 404 encontrados" micorreo@miproveedor.com < /tmp/404.txt
fi
\rm /tmp/404.txt

Crontab:
57 23 * * * /root/scripts/check_logs.sh

miércoles, 14 de abril de 2010

Como capturar el bit recursion desired con tcpdump en un query DNS

Problema: El día de hoy escuchando el Podcast de Mr DNS escuché la idea de tomar el Bit de recursividad (recursion desired) en un paquete DNS. En ese momento me pareció buena idea intentarlo y por ello el presente post. Solución: Lo primero que hice fue hacer una captura y analizarla con Tcpdump y adicionalmente averiguar especificamente como es un paquete de pregunta DNS. Para esto último conseguí el siguiente paquete el cual tomé de: An Illustrated Guide to the Kaminsky DNS Vulnerability En este sentido, me interesa tomar el bit RD cuando se encuentre encendido. Debido a que tcpdump permite obtener el encendido/apagado de los bits pero en octetos hay que darse cuenta que el bit RD es el bit menos significativo del octeto numero 10 dentro del paquete UDP. En otras palabras, en el gráfico anterior cada "linea" tiene 4 octetos (32 bits). Si comenzamos a contar desde el Campo Source Port de UDP hasta el campo Query ID (incluyendo) existen 9 octetos. Por ello los próximos 8 bits son los flags del paquete DNS y el último de estos 8 (de izquierda a derecha) es el RD. En un query standard DNS estos 8 bits generalmente vienen de la manera: 00000001, por ello el comando tcpdump que necesitamos es el siguiente: #tcpdump -i eth0 udp[10] == 1 and port 53 Captura del wireshark: Links importantes: http://www.unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html Mr DNS Podcast
check out this page
LEAF DOMICILE Buy Marijuana Online, CBD Oil,Vape Store, Weed For Sale – Leaf Domicile Delivery Buy Weed Online at Leaf Domicile A wide collection of Weed Buds, Isolates, Hash, Vape Pens, Wax, Cartridges,Seeds, Concentrates, Edibles, CBD Oil for sale Buy Marijuana Online,Buy Weed Online,Weed For Sale,Buy kush online,- https://leafdomicile.com/ THC edibles for sale, order edibles, where can I buy edibles, mail order weed, buy wax online, buy cbd vape oil, pre rolled joints for sale, pre rolled joints for sale, buy kush online, where to buy dabs online, weed dabs for sale, wax for sale,

martes, 30 de marzo de 2010

Clave por defecto de root en Ubuntu

Situacion:
Luego de instalar Ubuntu no puedo entrar como root ni hacer un "su" al usuario. El resto de los usuarios funcionan bien

Explicación:
Luego de la instalación, por defecto Ubuntu viene con el usuario root bloqueado, esto se puede verificar en /etc/shadow y ver el signo de exclamación (!) en el usuario root

Solución:
Existen muchas maneras de solucionar la situación. La más sencilla y funcional:

$sudo -i
#passwd root
Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.

Luego de esto el usuario root quedará habilitado

Suerte!

jueves, 25 de marzo de 2010

Utilizando DNSTOP

Objetivo:
Utilizar correctamente DNSTOP

Software utilizado:
Distribución Mandriva
DNSTOP (http://www.rpmfind.net/linux/rpm2html/search.php?query=dnstop&submit=Search+...)

Ejecutando dnstop:
La manera de ejecutar dnstop es: comando interface. Por ejemplo

# dnstop {interface-name}
# dnstop eth0
# dnstop wlan0

Una salida tipica es:

Queries: 53 new, 391 total Thu Mar 25 13:04:37 2010

Sources Count %
--------------- --------- ------
200.xx.xx.5 137 35.0
200.xx.xx.2 46 11.8
200.xx.xx.253 24 6.1
190.xx.xx.2 21 5.4
200.xx.xx.140 18 4.6
200.xx.xx.30 12 3.1
200.xx.xx.141 11 2.8
200.xx.xx.118 10 2.6
200.xx.xx.186 10 2.6
10.xx.xx.162 8 2.0
200.xx.xx.138 8 2.0
200.xx.xx.6 6 1.5

Ahora bien, dnstop no solo genera la salida anterior sino que puede generar MUCHA más información, todo es cuestión de saberlo utilizar.
Por ejemplo, puedes ejecutar dnstop con el siguiente comando:
#dnstop -l 3 eth1

Durante la ejecución presiona el numero "1" o "2" o "3". Podrás ver hasta 3 niveles de resolución de nombres y así saber que nombres generalmente resuelven tus clientes.

Otra opción muy interesante es el tipo de query sobre el DNS Server (A, AAAA, PTR, etc). Para ello durante la ejecución presiona "t".

Opciones típicas de dnstop:

 s - Sources list
d - Destinations list
t - Query types
o - Opcodes
r - Rcodes
1 - 1st level Query Names ! - with Sources
2 - 2nd level Query Names @ - with Sources
3 - 3rd level Query Names # - with Sources
4 - 4th level Query Names $ - with Sources
5 - 5th level Query Names % - with Sources
6 - 6th level Query Names ^ - with Sources
7 - 7th level Query Names & - with Sources
8 - 8th level Query Names * - with Sources
9 - 9th level Query Names ( - with Sources
^R - Reset counters
^X - Exit

? - this

Links:
Este articulo es una traducción y adaptación de experiencia propia de: http://www.cyberciti.biz/faq/dnstop-monitor-bind-dns-server-dns-network-traffic-from-a-shell-prompt/

jueves, 18 de marzo de 2010

Comportamiento de mi blog de visitas antes y despues del terremoto de Chile

Objetivo:
Analisis muy rapido y por encima sobre el comportamiento de trafico a Internet antes de despues del terremoto de Chile (en base a mi modesto Blog).

Como todos sabemos, el 27 de Febrero de 2010 un fuerte sismo sacudió nuestro país hermano Chile, por ello, me preguntaba en estos días que habrá pasado durante esos días y si el acceso al presente blog había variado durante dichas fechas.

Como comentario, mi blog actuamente (Marzo 2010) tiene casi 1000 mensuales provenientes principalmente de países donde habla español.

Por lo anterior, lo que hice fue apoyarme en Google Analytics y construir el pequeño resumen que vemos a continuación:

Premisas:
* Solo se tomó visitas que provienen de Chile
* Las visitas son de lunes a viernes (no se incluyen fines de semana)


Tabla resumen:
































Semana VisitasObservación
15-19 de Febrero242 Semanas antes del
terromoto
22-26 de Febrero26Semana anterior al
terromoto
1 - 5 Marzo15Semana siguiente al
terromoto
8 - 12 MarzoAprox 292 Semanas posterior
al terremoto




Resumen:
Podemos ver que desde Chile el presente blog lo visitan entre 25-30 personas a la semana.
La semana siguiente al terromoto hubo una caída de visitas de 45%
A las 2 semanas del terremoto las visitas se regularizaron

Una mejora práctica en el Transporte DNS sobre UDP en IPv6

Por Hugo Salgado y Alejandro Acosta Introducción y planteamiento del problema En el presente documento queremos discutir sobre un draft (bor...