RSS
 

Archive for the ‘Tutoriales’ Category

Cursos Online en Universidad de Stanford

09 Dec

Cursos Online Gratuitos
Por si les interesa .

http://www.crypto-class.org/

http://www.security-class.org/

 

Como liberar tu PS3

12 Jan

Si eres propietario de un PS3, y deseas probar software de 3ros o desarrollar tu propio software para este sistema, aqui tienes la Guia basica para liberar tu PS3.

Si en 14 simples pasos liberaras tu PS3.

NOTA: Este metodo va sin garantias, usalo bajo tu propio riesgo, nosotros no nos hacemos responsables por fallas o desperfectos despues ocacionados en tu consola…

Guía completa de GeoHot Jailbreak PS3

GeoHot ha decidido además de liberar para cargar con homebrew software casero y nada de copias caseras de los videojuegos.

El método de George Hotz es de momento el primero y por ahora el único de momento, aunque podrán ir saliendo alternativas.

No funcionan sobre antiguos homebrew y funciona sobre el firmware 3.55 (el último conocido).

Los pasos a seguir serán los siguientes:

1. Conecta una memoria USB al PC
2. Crea una carpeta raíz llamada PS3
3. Añade una carpeta llamada ” UPDATE ” que lleve a /PS3/UPDATE/
4. Descarga el Jailbreak de GeoHot ( Descargar aquí )
5. Extrae el archivo PS3UPDAT.PUP y muevelo a UPDATE en la memoria USB
6. Conecta la memoria a tu PS3
7. Navega hasta “Herramientas”
8. Elige “Actualización de sistema”
9. Opción “Actualizar desde la memoria o pendrive”
10. Reconocerá la actualización “Version 3.55-jb”, dale al OK
11. Acepta las condiciones e instala la actualización finalmente
12. Cerca de 1 minuto en actualizar ( pitará varias veces y se apagará )
13. Enciende la consola desde su botón principal
14. Después de todos los pasos ya ha sido la versión modificada firm 3.55

Informacion de Noticias2D

 

Sniffing SSL Traffic using SSLStrip

27 Mar

 

Google Go

21 Nov

Esta semana Google introdujo un nuevo lenguage de programación llamado “Go“.

Por lo cual vamos a ver como instalar el compilador para nuestro Ubuntu.

Paso 1: Editar nuestro .bashrc con lo siguiente:

k001@icemovil$ export GOROOT=$HOME/go
k001@icemovil$ export GOARCH=386
k001@icemovil$ export GOOS=linux
k001@icemovil$ export GOBIN=$HOME/bin
k001@icemovil$ export PATH=$GOBIN:$PATH

Paso 2: Creamos un directorio llamado bin:

k001@icemovil$ mkdir ~/bin
k001@icemovil$ $chmod 755 ~/bin

Paso 3: Instalamos los paquetes necesarios para compilar:

k001@icemovil$ sudo apt-get install python-setuptools python-dev
k001@icemovil$ sudo apt-get install mercurial
k001@icemovil$ hg clone -r release https://go.googlecode.com/hg/ $GOROOT
k001@icemovil$ sudo apt-get install bison gcc libc6-dev ed make

Paso 4: Construir el compilador:

k001@icemovil$ cd $GOROOT/src
k001@icemovil$ ./all.bash

Con eso ya iniciará la compilación para tener nuestro compilador de “GO”.

Pronto daré ejemplos de codigo con dicho lenguaje.

 
 

Metodos Para Obtener el Codigo de Chromium-Based OS

19 Nov

Metodos Para Obtener Chromium Os

 
 

Que es Google Chrome OS?

19 Nov

 
 

Repositorios remotos/locales git con ssh

26 Sep

Actualmente existen varios servicios de hospedaje gratuito para
repositorios git, el único requisito es que nuestros proyectos sean
opensource. Pero si no queremos que algún proyecto sea público, ya
sea porque X o Y razón, tendríamos que pagar una módica
cantidad.

Aunque es un precio accesible, algunos si somos bien
<del>pobres</del> codos y por otro lado, si tenemos otro lugar para
hospedarlo nos podemos ahorrar esos loritos para otra
ocasión.
Esta receta puede llevarse a cabo tanto local como remotamente,
para comenzar necesitaremos únicamente de git y un servidor ssh,
los cuales en debian y derivados se instalan de esta manera:

# apt-get install git-core openssh-server

Para crear los repositorios nos conectaremos al servidor remoto.
En mi caso hice esto localmente y decidí agregar el usuario git, ya
que en mi disco duro tengo una partición dedicada para /home.

$ ssh git@git.kelevra.org

Y ejecutamos los siguientes comandos:

$ mkdir test-project.git
$ cd test-project.git
$ git --bare init   # inicializamos el repositorio remoto

Con eso ya tenemos nuestro repositorio funcionando, ahora vamos
a commitear algunos archivos:

$ cd projects
$ mkdir test-project
$ cd test-project
$ git init                                                      # inicializamos el repositorio local
$ git remote add origin git@git.kelevra.org:test-project.git    # agregamos el repositorio remoto
$ echo 'Hello World!' > README
$ git add README
$ git commit -m 'first push'
$ git push origin master

Si todo ha ido bien, veremos algo como:

git@git.kelevra.org's password:
Counting objects: 3, done.
Writing objects: 100% (3/3), 221 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@git.kelevra.org:test-project.git
           [new branch]      master -&gt; master

Nuestro repositorio está trabajabdo bien, el password obviamente
es el que le hayamos designado al usuario que creamos.

¿Pero que pasa si otros van a colaborar en mi proyecto?

Tienes dos opciones: La número uno sería que les hagas saber el
password de dicho usuario, pero estar escribiendolo cada vez que
vayamos a pushear algo es molesto.

La número dos y la más recomendable: Usar SSH-KEYS.
A saber, existen dos tipos de llaves, DSA y RSA, sea cual sea
nuestra elección, el procedimiento para crear un par de llaves es
la siguiente:

$ ssh-keygen -t dsa                                                             # cambiar por rsa según nuestra elección
Generating public/private dsa key pair.
Enter file in which to save the key (/home/kelevra/.ssh/id_dsa): .ssh/git_dsa   # no es obligatorio especificar ubicación
Enter passphrase (empty for no passphrase):                                     # escribimos una clave para usar la llave
Enter same passphrase again:                                                    # y la escribimos  de nuevo para confirmar
Your identification has been saved in .ssh/git_dsa.
Your public key has been saved in .ssh/git_dsa.pub.

Hemos generado una llave pública y una privada, la pública es la
que copiaremos al servidor remoto:

$ scp .ssh/id_dsa.pub git@git.kelevra.org:.ssh/authorized_keys2
git@git.kelevra.org's password:
id_dsa.pub                                    100%  608     0.6KB/s   00:00

Ahora ya no nos pedirá el password del usuario cada vez que
hagamos push o nos conectemos para crear un nuevo repositorio, en
su lugar nos pedirá la clave que le asignamos a nuestro par de
llaves. Pero aún tenemos que escribir un password, sin embargo
podemos usar ssh-agent que recordará por determinado
tiempo nuestras claves, para iniciar este agente basta con teclear
en la terminal:

$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-RwRst31999/agent.31999; export SSH_AUTH_SOCK;
SSH_AGENT_PID=32000; export SSH_AGENT_PID;
echo Agent pid 32000;

Ya una vez corriendo el agente agregamos nuestra llave:

$ ssh-add .ssh/git_dsa
Enter passphrase for .ssh/git_dsa:
Identity added: .ssh/git_dsa (.ssh/git_dsa)

¡Y listo! Nos conectamos de nuevo vía ssh o hacemos otro push
para comprobar que ya no nos pide el password del usuario y de la
llave ssh. Y ahora si ya tenemos nuestro servidor de repositorios
git bien sencishito y carismático

 
1 Comment

Posted in Tutoriales

 

Richard Bejtlich, Network Security Monitoring Using FreeBSD

22 Apr

 
 

pkg-get en Solaris

15 Nov

#pkg-get en Solaris

(manejador de paquetes para solaris)

Como primer paso le recomiendo se den una vuelta por

http://www.bolthole.com/solaris/pkg-get.html Que es el sitio oficial para el manejador de paquetes que utilizaremos llamado

pkg-get

Usando pkg-get Y el repositorio blastwave podremos instalar software en nuestro Solaris/Open Solaris de manera similar a debían.

Primer Paso instala pkg-get

#pkgadd -d http://www.blastwave.org/pkg_get.pkg

Aceptamos todas las preguntas que nos hará el instalador,el repositorio a usar es www.blastwave.org que contiene 1700 paquetes de sofrware en su mayoria open source todo este repositorio trabaja bajo /opt/csw Y el Fichero de configuracion de pkg-get se encuentra en

/opt/csw/etc/pkg-get.conf

Definimos nuestro mirror a usar

url=http://mirrors.sunsite.dk/csw/stable

Si estamos atrás de un Firewall o algun Proxy

configuramos las lineas correspondientes

# If you are behind a firewall, set one of these as appropriate

#ftp_proxy=http://your-proxy:8023

#http_proxy=http://your-proxy:8023

#export http_proxy ftp_proxy

Guardamos y como primer paso

#/opt/csw/bin/pkg-get -U

Y es todo a instalar el software que necesitemos

Se me ocurre instalar

/opt/csw/bin/pkg-get -i nano

/opt/csw/bin/pkg-get -i bash

/opt/csw/bin/pkg-get -i vim

En el siguiente tutorial sera configuracion de postfix en Solaris Usando Mysql para la BD de usuarios

Dudas a roa@unixmexico.org/roa@tucancunix.net

 

Replicacion de Mysql en FreeBSD Master To Slave

09 Nov

Replicacion de Mysql en FreeBSD

Master To Slave

El punto es.. mantener tus B.D sincronizanadas y no tener perdida de datos , y tener nuestros backups al día.

Manos a la Obra

Requerimientos mínimos

Tener Acceso root tanto en el sistema como en las base de datos.

Servidor 1 FreeBSD 6.3 (será Nuestro servidor Master)

Mysql Server mysql-server-5.0.51a (Corriendo N cantidad de Base de datos)

Servidor 2 FreeBSD 7.0

Mysql Server mysql-server-5.0.67_1 (Sin Bases de datos)

La teoría es replicar las bases de datos del Servidor 1 al Servidor 2 Y ya en el servidor 2 sacarle un backup a todas nuestras base de datos, para no sobre cargar nuestro servidor 1 que se encuentra en producción.

Aquí pueden replicar 1 base de datos o todas las base de datos mi caso es el segundo.

Les recomiendo se lean http://dev.mysql.com/doc/refman/5.0/es/replication.html antes de comenzar todo.

y si por algun motivo algo no les funciona revisen de nuevo sus configuraciones en ambos servidores por que si no pasaran horas tratando de dar con el problema y resultara que se les fue algún carácter raro en los archivos de configuración de mysql “Experiencia Personal” , al mejor cazador se le va la liebre no?.

Manos a la obra.

En nuestro Servidor 1 Que es nuestro servidor Master de Mysql daremos de alta

un usuario que nos servira para replicar las bases de datos con esta sentencia

mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO ‘replicador’@'host_esclavo’ IDENTIFIED BY ‘mi_contraseña’;

Donde replicador=Es el usuario que nos permitira hacer la replica de nuestras bases de datos

hosts_esclavo=la ip o el host de nuestro servidor esclavo

mi_contraseña= Sera igual a la contraseria del usuario que replicara las bases de datos.

En nuestro Servidor 2 Ingresamos la misma sentencia

mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO ‘replicador’@'host_master’ IDENTIFIED BY ‘mi_contraseña’;

El Unico cambio aqui sera el host_master que sera igual a la Ip o el nombre del host.

Siguiente paso configuración de los servidores de Base de Datos tanto en el Servidor 1 (Master) Como en el Servidor 2 (Slave)

Editaremos En el Servidor1 (Master) El archivo my.cnf , si usamos Linux/Unix/Windows usaremos nuestro editor de texto preferido.

nano /var/db/mysql/my.cnf

Agregaremos estas opciones

[mysqld]

server-id = 1

log-bin = /var/log/mysql/bin.log

Donde server-id es un numero con el que se identificare al servidor maestro.

La segunda linea log-bin es la ruta de la bitacora binaria, Asegurarnos que ese directorio exista y que el usuario mysql sea el propietario y tenga

permisos de escritura sobre el mismo directorio.

#mkdir /var/log/mysql; chown mysql.mysql /var/log/mysql

Para Nuestro Servidor Esclavo o Slave, añadiremos unas lineas extras al archivo de configuración de my.cnf

Buscamos la sección

[mysqld]

server-id= 2

master-host = host_maestro,com # o la IP del servidor maestro

master-port = 3306

master-user = replicador

master-password = mi_contraseña

log-bin = /var/log/mysql/bin.log

log-bin-index = /var/log/mysql/log-bin.index

log-error = /var/log/mysql/error.log

relay-log = /var/log/mysql/relay.log

relay-log-info-file = /var/log/mysql/relay-log.info

relay-log-index = /var/log/mysql/relay-log.index

Y ahora que ? Ya tenemos las configuraciones tanto en el servidor 1 (master) como en el Servidor2(Slave)

El siguiente paso sera copiar todas las BD del Servidor 1 Hacia el Servidor2

Pero si el servidor Master esta en produccion si sacamos un respaldo de nuestro servidor master

y lo llevamos al servidor slave, podrian existir inconsistencias en nuestras base de datos

Para eso tendremos que prevenir todo eso.

En nuestro servidor master hacemos esto

mysql> SHOW VARIABLES LIKE ‘max_connections’;

+—————–+——-+

| Variable_name | Value |

+—————–+——-+

| max_connections | 100 |

+—————–+——-+

mysql> SET GLOBAL max_connections = 0;

Lo que hicimos es indicarle a mysql que ya no podran realizarse conexiones a la BD y solo se reserva

1 sola conexion que es para root .

Y procedemos a sacar el dump de todas las bases de datos.

# mysqldump –user=root –password=mi_root_pwd –extended-insert –all-databases –master-data > /tmp/backup.sql

Necesita explicacion? .

Procederemos a llevarnos nuestro backup de nuestras BD hacia el servidor esclavo ya sea usando

scp or ftp como sea de nuestro agrado tranferirlas.

Ok Cuando Establecimos las conexiones a 0 y al sacar el dump de eso

Nos agrega unos datos que probablemente necesitaremos mas adelante.

####

– Position to start replication from

CHANGE MASTER TO MASTER_LOG_FILE=’bin.00046′ ;

CHANGE MASTER TO MASTER_LOG_POS=8827 ;

###

O podemos obtener estos datos en el servidor master

En el servidor maestro visualizamos el estado del servidor:

mysql> SHOW MASTER STATUS\G

File: bin.00046

Position: 8827

Binlog_Do_DB:

Binlog_Ignore_DB:

1 row in set (0.00 sec)

Bueno nos quedamos en la parte de mover el backup hacia nuestro servidor esclavo y restauraremos

todas las bases de datos con la siguiente sentencia.

Siguiente paso

#mysql –user=root –password=mi_root_pwd < /tmp/backup.sql

Si no nos da ningun error eso quiere decir que todas nuestras bases de datos fueron restauradas en nuestro

servidor slave.

Iniciamos con esta sentencia nuestro servidor SLAVE no olviden regresar a 100 la opcion de max_connection.

#mysql>CHANGE MASTER TO MASTER_HOST=’ip-maestro’,MASTER_USER=’slave’, MASTER_PASSWORD=’slaveabdul’,MASTER_LOG_FILE=’bin.00046′, MASTER_LOG_POS=8827;

#mysql> START SLAVE;

Aqui si todo esta bien se empezaran a sincronizar los ultimos cambios del servidor master

al servidor slave.

Facil no?

Ahora si necesitamos sacar un respaldo en nuestro servidor Slave

Solo basta con parar la replicacion

mysql> STOP SLAVE;

Y sacar el dump de cualquier base de datos y luego volver a arrancarlo

mysql> START SLAVE;

O podemos sacar respaldos Automatizados, mediante este script en bash.

#!/bin/sh

fecha=`date +%Y%m%d`

mysqladmin –user=root –password=mi_root_pwd stop-slave

mysqldump –user=root –password=mi_root_pwd –lock-all-tables –all-databases > /roa/mysql/respaldo-$fecha.sql

mysqladmin –user=root –password=mi_root_pwd start-slave

Se le pueden agregar mas opciones pero ya es cuestion de uno. Si son algo paranoicos podremos hacerlo sobre ssh-tunels para Mysql aqui en un tutorial que anteriormente escribi espero que le sirva

Dudas a roa@unixmexico.org,roa@tucancunix.net

 
 
 
Get Adobe Flash player