MiJack – Cuadernos técnicos

Tras mi experiencia de 5 años como sysadmin Linux, he aprendido qué cosas evitar a la hora de tener un servidor Debian relativamente seguro.

Casi todas estos consejos parten de la paranoia y algunos simplemente se rigen por el sentido común, pero merece la pena listarlos y revisarlos de vez en cuando.

Allá vamos:

- Utilizar siempre que sea posible conexiones cifradas cuando vamos a trabajar con datos sensibles:
Protocolos como SSH, SCP y https fijan transmisiones de datos cifradas.
Con ello evitamos ademas de que nos snifen el tráfico, pudiendo acceder a datos sensibles y contraseñas, ataques tipo man in the middle.

- Password robustos y encriptados:
Utilizar siempre password robustos. “Churros” de mínimo ocho caracteres, con al menos un caracter en mayúsculas, uno en minúsculas y uno numérico.
Ejemplo: Ax84jMn4

Es de sentido común que el password de root de nuestro sistema no sea ’12345′.

- Mantener el servidor actualizado.
Debian especialmente y en general las distribuciones derivadas suelen tener un exhaustivo control de actualizaciones y reparaciones de bugs. Para ello, tenemos que tener entre nuestros repositorios, los repositorios oficiales de seguridad
Actualizar un sistema debian es tan facil como teclear:

apt-get update
apt-get upgrade

- Cuidado con el software de origen dudoso .
Vigilar qué tenemos en nuestro fichero sources.list. Intentar utilizar solo repositorios oficiales.

- Desinstalar o deshabilitar servicios innecesarios
Para ello podemos hacer uso del comando chkconfig (originario de distribuciones basadas en rpm, existe también para debian)
La idea es parar y deshabilitar el arranque de servicios que no vamos a necesitar.

- FIREWALL
Intentar filtrar todas las conexiones entrantes mediante un firewall, denegando el acceso a servicios cuya conexión desde el exterior no es necesaria. Si no disponemos de un firewall, más abajo hablo de IPTABLES.

- No instalar el entorno gráfico y mucho menos, ejecutarlo como root:
No tiene sentido tener las X en un servidor en producción. Si tenerlo arrancado de por sí ya es un agujero de seguridad y una fuente de inestabilidad del sistema, no hablemos de arrancarlo con el usuario root.

- Separación de particiones
Separar las particiones siempre es una buena idea. Tanto en lo que a seguridad se refiere, como a la hora de evitar que el disco se llene.

Lo ideal suele ser separar en particiones diferentes los directorios /var/, /home/, /usr/, /boot y /tmp.

- Fijar como Noexec las particiones que no vayan a necesitarlo, sobre todo /tmp

Una vez separadas las particiones, lo ideal es fijar (al menos) el directorio /tmp como noexec.

De esta forma, ante una posible intrusión, no se pueden ejecutar binarios desde /tmp, cosa bastante habitual cuando se intenta ejecutar código malicioso en un servidor.

- Revisar con frecuencia logs y gráficas de rendimiento.

Especialmente las gráficas de cpu y tráfico nos pueden ayudar a localizar comportamientos inapropiados, como un incremento de ancho de banda o de uso de cpu, que pudiera deberse a código malicioso, envíos de emails, shells, etc.

- cuidado con el comando Sudo, que lo carga el diablo:

Si puede ser, que no esté habilitado más que para lo estrictamente necesario.

Una entrada de este tipo en el fichero sudoers:

usuarioxx ALL=(ALL) ALL

puede suponer dar privilegios de root automaticamente al usuario que consiga el password de un usuario regular.

- Shell por defecto de usuarios que no necesiten loguearse:

Si existe un usuario en el sistema con el que vamos a ejecutar algún tipo de proceso, o que van a ser necesarios para conexiones via FTP, pero no van a necesitar loguearse en linea de comandos, podemos fijar su shell por defecto como /bin/false.

El usuario seguirá existiendo, podrá ser propietario de ficheros/directorios, podrá ingresar via FTP, pero jamás ejecutar una shell.

Para ello, editamos el fichero /etc/password, y en la linea donde están definidas las opciones de usuario, al final, definimos su shell como /bin/false:

usuarioFtp:x:3000:3000:,,,:/home/usuarioFtp:/bin/false

Permisos:
- chmod 777 está prohibido:
Nunca nunca nunca, hacer cambios de permiso a lo loco. hacer un chmod 777 sobre un fichero o un directorio está prohibido. Y más aun si se hace para solucionar algún problema de permisos que no sabemos como atajar.

Recomendaciones concretas en diferentes tipos de servicios:

SSh
- prohibir loguearse como root :

en el fichero de configuración (/etc/ssh/sshd_config), podemos deshabilitar la opción PermitRootLogin, fijandola en No:

PermitRootLogin no

De esta forma siempre tendremos que loguearnos como un usuario regular y escalar a root.

- Permitir el acceso sólo a los usuarios indicados

Al igual que para deshabilitar el login con el usuario root, podemos indicar qué usuarios podrán conectarse con la siguiente directiva en /etc/ssh/sshd_config:

AllowUsers mijack operador

De esta forma, permitimos solo al usuario mijack y al usuario operador ingresar en el sistema. Si hubiera más usuarios no podrían acceder via ssh.

Apache:
Uso de mod_secure:
- Para evitar inyecciones de código en nuestros sitios web, podemos activar el módulo mod_secure, que dispone de unas directivas por defecto muy completas que bloquearan URLS sospechosas. En ocasiones es demasiado restrictivo.

proteger con htpasswd
- Todo directorio o ruta sensible a ingresos de usuario no deseados o con contenido sensible, puede ser protegido mediante htpasswd. De esta forma al intentar acceder a una url concreta, nos pedirá user y password.

MySQL:
- Fijar siempre un password de root:
De no fijar un password de root para MySQL (por defecto vacio en muchas distribuciones de linux), cualquier usuario regular podrá loguearse en el sistema tecleando:
$ mysql -u root
- Cada bases de datos con su usuario y password:
Si existen varias bases de datos en nuestro sistema, es recomendable que cada una tenga un usuario y password de acceso. De forma que el usuario de una base de datos no pueda escribir en todas.
- Evitar conexiones externas.
Por defecto MySQL no admite conexiones externas puesto que solo escucha las peticiones desde localhost. Es preferible no cambiar esa configuración si no es necesario cien por cien.

Modo ultraparanoia:

- iptables:
iptables (antiguamente ipchains) es un framework inlcuido en el nucleo de linux que permite filtrar los paquetes de red, denegando o aceptando trafico dependiendo de multiples factores.

Si tenemos un nivel majo de paranoia, podemos configurar iptables para rechazar todo el tráfico que no se adapte al puramente necesario.

El funcionamiento de iptables es complejo puesto que también se puede usar para el enrutado de tráfico y nateo de puertos.

Ejemplo:
Rechazamos todo el tráfico por el puerto 22, y luego establecemos que solo aceptaremos el de una ip en concreto, xxx.xxx.xxx.xxx:
iptables -t filter -I INPUT -p tcp –dport 22 -j DROP
iptables -t filter -I INPUT -p tcp -s xxx.xxx.xxx.xxx –dport 22 -j ACCEPT

- SELinux (del inglés Security-Enhanced Linux, Seguridad Mejorada de Linux):
Creado a imagen y semejanza del control de acceso utilizado por el departamento de defensa de los Estados Unidos, SELinux implementa unas políticas de seguridad y controles de acceso extremadamente flexibles, con la posibilidad de ser a su vez, extemadamente paranoicas.

Algunas distribuciones, como CentOS, lo traen activado por defecto.

SELinux Permite el control total de usuarios, procesos archivos y sockets, de forma que según lo restrictivos que seamos al configurarlo, podemos impedir la ejecucion de servicios o binarios, el login de usuarios que no estén en la lista de permitidos o incluso la escritura en determinados directorios.

Seguiremos añadiendo cosas

Saludos.

MiJacK.

AWStats es una herramienta open source de análisis de tráfico web. Saca los datos de los logs de apache y a partir de esos datos genera los informes.

Awstats puede ser un complemento perfecto a otras herramientas como Google Analytics. Además de las visitas, podremos consultar el tráfico real generado, tamaño de ficheros, tráfico por MIME Type, etc.

Vamos a instalar awstats en un servidor debian que ya tiene un apache funcionando desde hace algún tiempo y vamos a sacar las gráficas del dominio albumdata.com

Comenzamos instalando el paquete awstats

apt-get install awstats

Nos genera una configuración standard en /etc/awstats. Vamos a hacer una copia del fichero y a personalizarlo para nuestro dominio

  cd /etc/awstats
  
  cp awstats.conf awstats.albumdata.com.conf

Editamos el fichero awstats.albumdata.com.conf y modificamos solamente estos tres valores:

El fichero de log de apache para el sitio que queremos analizar

LogFile="/var/log/apache2/albumdata_access.log"

El nombre de dominio

SiteDomain="albumdata.com"

El/los posibles alias. en mi caso, las llamadas a www.

HostAliases="www.albumdata.com"

Por último vamos a configurar el acceso en el virtualhost que queramos. Yo añado al sitio por defecto (el que muestro cuando hago una peticion por ip http://xx.xx.xx.xx)

editamos /etc/apache2/sites-enabled/000-default

y añadimos:

Alias /awstats-icon/ /usr/share/awstats/icon/
        ScriptAlias /awstats/ /usr/lib/cgi-bin/

De esta forma, si llamamos al sitio http://xx.xx.xx.xx/awstats/awstats.pl?config=albumdata.com , veremos las gráficas.

La primera vez que visitemos el sitio las gráficas estarán vacias puesto que aun no hemos recopilado los datos de los logs.

El funcionamiento de awstats se basa en la ejecucion del comando /usr/lib/cgi-bin/awstats.pl, indicandole el dominio que del que queremos extraer las gráficas.

Para ello, lo más práctico es fijar un cron con la frecuencia que deseemos (en mi caso cada hora).

La primera ejecucion la haremos a mano:

# /usr/lib/cgi-bin/awstats.pl -config=albumdata.com -update
Create/Update database for config "/etc/awstats/awstats.albumdata.com.conf" by AWStats version 6.95 (build 1.943)
From data in log file "/var/log/apache2/albumdata_access.log"...
Phase 1 : First bypass old records, searching new record...
Direct access to last remembered record has fallen on another record.
So searching new records from beginning of log file...
Phase 2 : Now process new records (Flush history on disk after 20000 hosts)...
Flush history file on disk (unique url reach flush limit of 5000)
Flush history file on disk (unique url reach flush limit of 5000)
Flush history file on disk (unique url reach flush limit of 5000)
Flush history file on disk (unique url reach flush limit of 5000)
Jumped lines in file: 0
Parsed lines in file: 98320
 Found 0 dropped records,
 Found 16 corrupted records,
 Found 0 old records,
 Found 98304 new qualified records.

Por último, vamos a securizar un poco awstats, configurando un htaccess para que al ver las gráficas nos pida un user y password.

En el fichero del virtualhost de apache donde vayamos a colocar el acceso a awstats (en mi caso 000-default), justo debajo de las lineas que pusimos antes, ponemos estas

 
 <Directory /usr/lib/cgi-bin/>
        AuthName "Acceso restringido a Estadísticas"
        AuthType basic
        AuthUserFile /etc/awstats/.htpasswd
        require valid-user
    </Directory>

Ahora generamos el fichero .htpassword para el usuario “user”

htpasswd -c /etc/awstats/.htpasswd user

Reiniciamos apache, y ahora al acceder a las graficas nos pedira un user y password, que se correspondera con el que acabamos de crear.

Hecho todo esto, obtenemos unas estadísticas muy completas, algo parecido a esto.

Saludos.

MiJacK

En ocasiones nos sera util redirigir la salida de la consola de MySQL para poder procesarla de una forma concreta, por ejemplo, pasandosela al comando head o tail para ver solo las últimas o primeras lineas o a un more o less para poder ver la salida mas comodamente.

para ello existe el comando pager:

mysql>pager more 
PAGER set to 'more'

o

mysql>pager tail 
PAGER set to 'tail' 

y para volver a la salida estandar por defecto:

mysql> nopager 
PAGER set to stdout 

Con el único fin de agrupar máquinas y servicios para tener una visibilidad más clara desde el interfaz web, podemos definir unos grupos de hosts y servicios.

Para ello, vamos a crear un fichero nuevo al que llamaremos gruops.cfg, y lo incluiremos en el fichero principal de configuracion:

Añadimos la última linea:

# Ficheros de configuracion
cfg_file=/usr/local/nagios/etc/objects/commands.cfg
cfg_file=/usr/local/nagios/etc/objects/contacts.cfg
cfg_file=/usr/local/nagios/etc/objects/timeperiods.cfg
cfg_file=/usr/local/nagios/etc/objects/templates.cfg
<span style="color: #ff0000;"> cfg_file=/usr/local/nagios/etc/objects/groups.cfg</span>

y creamos el fichero groups.cfg con este contenido:

define hostgroup{
        hostgroup_name  servidoresLinux
        alias           Servidores Linux
        members         servidor, servidor2
        }

define servicegroup{
        servicegroup_name chequeos http
        alias   Servicios http
        members servidor,HTTP,  servidor2,HTTP
}

de esta forma, creamos unos grupos de hosts y servicios que podremos gestionar desde el interfaz web.

Vamos a añadir el chequeo de dos servicios sencillos asociados a nuestro host “servidor”, que añadimos en el capítulo anterior.

Editamos el fichero servidor.cfg y añadimos:

define service{
        use                             generic-service
        host_name                       servidor
        service_description             HTTP
        check_command                   check_http
        }

Esto establece un chequeo http, ligado a servidor, heredando las opciones de la plantilla generic-service.

Vamos a pasarle al check_command algún parametro extra. Para ello, vamos a fijarnos en la definición del comando en commands.cfg:

# 'check_http' command definition
define command{
        command_name    check_http
        command_line    $USER1$/check_http -I $HOSTADDRESS$ $ARG1$
        }

Vemos que al lamar al comamdo, se le envía los datos de la máquina usando la macro $HOSTADDRESS$, y un parametro extra llamado $ARG1$.

Si ejecutamos el comando desde la linea de comandos, veremos que arguemntos podemos pasarle:

# /usr/local/nagios/libexec/check_http
Usage:
 check_http -H <vhost> | -I <IP-address> [-u <uri>] [-p <port>]
       [-w <warn time>] [-c <critical time>] [-t <timeout>] [-L] [-a auth]
       [-b proxy_auth] [-f <ok|warning|critcal|follow|sticky|stickyport>]
       [-e <expect>] [-s string] [-l] [-r <regex> | -R <case-insensitive regex>]
       [-P string] [-m <min_pg_size>:<max_pg_size>] [-4|-6] [-N] [-M <age>]
       [-A string] [-k string] [-S] [--sni] [-C <age>] [-T <content-type>]
       [-j method]

En este caso, nos interesa hacer el chequeo http, pero al puerto 8083, que es donde tendremos escuchando nuestro servidor web.

# /usr/local/nagios/libexec/check_http -p 8083 xxx.xxx.xxx.xxx
HTTP OK: HTTP/1.1 200 OK - 453 bytes in 0,015 second response time |time=0,014957s;;;0,000000 size=453B;;;0

Para adaptar esta llamada al chequeo de nuestro servicio, editamos servidor.cfg y fijamos el chequeo así:

       check_command                   check_http!-p 8083

de esta forma, llama al binario definido en el comando check_http, pasandole además como $ARG1$, ‘-p 8083′.

Vamos a poner en marcha un ejemplo real y vamos a ver todos los ficheros de configuración y entidades que participan en el proceso.

Queremos que nagios comprube la disponibilidad de la máquina con ip 192.168.183.1 al que denominaremos ‘servidor’. Comprobaremos la disponibilidad de dicha maquina mediante ping.

Se estableceran chequeos cada 5 minutos. Si la maquina estuviera down, volvería a chequear a cada 2 minutos.
Al 3º intento, se envíaria un mail a los operadores.

Al recuperarse la máquina, los operadores también recibirán un email confirmando la recuperación.

creamos el fichero servidor.cfg en el directorio hosts con el siguiente contenido:

define host{
use linux-server
host_name servidor
alias Servidor principal
address 192.168.183.1
}

comprobamos la configuración de Nagios:

/usr/local/nagios/bin/nagios -v /etc/nagios/nagios.cfg

Veremos esto:

[...]
Warning: Host ‘servidor’ has no services associated with it!
[...]
Total Warnings: 1
Total Errors: 0

Simplemente veremos un warning que nos indica que el Host servidor no tiene servicios asociados. Más tarde lo solucionaremos.

Reiniciamos Nagios para que los cambios tengan efecto

/etc/init.d/nagios restart

En la alta de este host ha tomado parte la siguiente entidad:

linux-server (plantilla).

Si editamos el fichero templates.cfg, podremos ver que se define en esa plantilla:

define host{
name linux-server
use generic-host
check_period 24x7
check_interval 5
retry_interval 1
max_check_attempts 10
check_command check-host-alive
notification_period workhours 

notification_interval 120
notification_options d,u,r
contact_groups admins
register 0
}

Vemos que la plantilla linux-server, hereda a su vez la configuración de la plantilla generic-host. La plantilla generic host, define una serie de opciones principales, entre otras, el periodo de notificacion 24×7.

Además, en la plantilla linux-server, definimos el periodo de chequeo 24×7, un intervalo de 5 minutos entre chequeos, intervalo de 1 minuto tras un fallo, un máximo de 10 intentos, tras el que se envíara una alerta, el comando de chequeo, el periodo de notificación, intervalo, opciones, y contactos. Por último, register 0 indica que esta definición no ha de registrarse en el sistema como un elemento, por lo que sólo formará parte de las plantillas.

Todos estos elementos, están definidos en diferentes ficheros de configuración, tal como vimos en los capítulos anteriores.

En el interfaz web de nagios, si vamos a la seccion hosts, veremos el nuevo host creado:

 

Instalación y configuración de Nagios Sobre Debian 6

Según Wikipedia, Nagios es:

Nagios es un sistema de monitorización de redes de código abierto ampliamente utilizado, que vigila los equipos (hardware) y servicios (software) que se especifiquen, alertando cuando el comportamiento de los mismos no sea el deseado. Entre sus características principales figuran la monitorización de servicios de red (SMTP, POP3, HTTP, SNMP…), la monitorización de los recursos de sistemas hardware (carga del procesador, uso de los discos, memoria, estado de los puertos…), independencia de sistemas operativos, posibilidad de monitorización remota mediante túneles SSL cifrados o SSH, y la posibilidad de programar plugins específicos para nuevos sistemas.

Tengo más de un año de experiencia administrando Nagios: Instalación, labor de investigación y mantenimiento, que incluye la creación de script para chequear diferentes tipos de servicios, bocas de switch, procesos lanzados en un servidor, etc.

Dicho sistema chequeaba servicios en una granja de unos 200 servidores, avisando en caso de fallo vía email o SMS al técnico de guardia para proceder a solucionar el error.

Voy a intentar dejar aquí a forma de nota, instrucciones básicas de configuración de Nagios.

El funcionamiento de nagios puede resultar un poco enrevesado y la curva de aprendizaje un poco dura al principio es por ello que es importante comprender su funcionamiento interno.

Hay diferentes entidades relacionadas con la configuración de Nagios. Aunque mi documentación se basa en ficheros, voy a proceder a explicar las diferentes entidades que forman aprte de la misma. Realmente toda la configuración podría estar en un sólo fichero de configuración, pero para hacerla más amigable se despieza la misma en diferentes ficheros y se usan includes para enlazar todos los ficheros en el fichero principal, nagios.cfg.

command: Define un comando de chequeo o de notificación. A esos comandos nos referimos cuando establecemos la configuracion de un nuevo chequeo.
contact: Define un contacto al que le llegará una notificación en caso de cambio de estado de uno de los chequeos.
contactgroup: Sirve para agrupar los contactos de forma que sea más sencillo gestionarlos.
host: Definimos un host, indicando su ip, nombre, etc. Podemos chequear la disponibilidad de ese host o asignarle servicios.
service: Definimos un servicio para chequear. Dicho servicio siempre irá asignado a un host.
template: Define las plantillas que mas tarde heredarán las entidades. Sirve para facilitar la configuración.
timeperiod: Define un periodo de tiempo personalizado, tanto para chequeos como para alertas.

Los ficheros de configuración a tratar en este capítulo serán contacts.cfg, templates.cfg y timeperiods.cfg.

contacts.cfg:

En el fichero contacts podemos definir tanto contactos como grupos de contactos.

Los grupos de contactos aquí definidos podrán ser luego aplicados a las plantillas para establecer quien recibirá las notificaciones.

Ejemplo de contactos y grupo de contacto:

define contact{
        contact_name                    oper1
        use                             generic-contact        
        alias                           Nagios oper number one
        email                           operador.1@dominios.com
        }

define contact{
        contact_name                    oper2
        use                             generic-contact        
        alias                           Nagios oper number two
        email                           operador.2@dominios.com
        }

En este ejemplo, registramos los contactos oper1 y oper2. definimos sus emails. El resto de opciones las va a coger de la plantilla generic-contact.

define contactgroup{
        contactgroup_name       operadores
        alias                   Nagios operators
        members                 oper1,oper2
        }

En este ejemplo, registramos en el grupo operadores, a los usuarios oper1 y oper2.

A partir de este momento, en las plantillas, al definir un fichero, podremos asignarle el grupo operadores, que heredará la configuración definida en el contacto generic-contact, también definido en templates.

templates.cfg:

Templates es un fichero donde podremos definir las plantillas, de todas las entidades con las que trabajamos en Nagios.

Vamos a ver un ejemplo con una plantilla de servicio:

En esta plantilla definimos generic-service:

define service{
        name                            generic-service         
        active_checks_enabled           1                       
        passive_checks_enabled          1                       
        parallelize_check               1                       
        obsess_over_service             1                       
        check_freshness                 0                       
        notifications_enabled           1                       
        event_handler_enabled           1                       
        flap_detection_enabled          1                       
        failure_prediction_enabled      1                       
        process_perf_data               1                       
        retain_status_information       1                       
        retain_nonstatus_information    1                       
        is_volatile                     0                       
        check_period                    24x7                    
        max_check_attempts              3                       
        normal_check_interval           10                      
        retry_check_interval            2                       
        contact_groups                  admins, operadores                
        notification_options            w,u,c,r                 
        notification_interval           60                      
        notification_period             24x7                    
         register                        0                      
        }

Al definir mas tarde un servicio, le diremos que utilice la plantilla generic-service.

Podemos definir diferentes tipos de plantillas para diferentes tipos de chequeo. Por ejemplo, servicio-noche y servicio-dia, en los que definiríamos dos checkperiods diferentes (con diferentes time periods), para que uno tuviera un chequeo de diferente intensidad dependiendo de la hora.

quedaría algo asi:

define service{
        name                            generic-service-day         
        check_period                    dia
        max_check_attempts              3                       
        normal_check_interval           5                      
        retry_check_interval            2                       
        }
define service{
        name                            generic-service-night
        check_period                    noche
        max_check_attempts              10                       
        normal_check_interval           10                      
        retry_check_interval            5                       
        }

De esta forma, tenemos las plantillas generic-service-day y generic-service-night, las cuales podremos aplicar a los chequeos, de forma que por la noche el chequeo sea menos intenso que por el día y ante servicios que se recuperan solos tras una caida, tendremos menos posibilidades de que nos despierten .

timeperiods.cfg

Con lo visto en el ejemplo anterior, ya sabemos que podemos definir diferentes time_periods, aplicables tanto a chequeos de host y servicio, como a envio de notificaciones.

el típico timeperiod 24×7, definido por defecto es así:

define timeperiod{
        timeperiod_name 24x7
        alias           24 Hours A Day, 7 Days A Week
        sunday          00:00-24:00
        monday          00:00-24:00
        tuesday         00:00-24:00
        wednesday       00:00-24:00
        thursday        00:00-24:00
        friday          00:00-24:00
        saturday        00:00-24:00
        }

Pasamos a definir dos timeperiods personalizados: day y night:

define timeperiod{
        timeperiod_name day
        alias           solo durante horario de oficina
        sunday          09:00-16:59
        monday          09:00-16:59
        tuesday         09:00-16:59
        wednesday       09:00-16:59
        thursday        09:00-16:59
        friday          09:00-16:59
        saturday        09:00-16:59
        }

define timeperiod{
        timeperiod_name night
        alias           Fuera del horario de oficina
        sunday          17:01-08:59
        monday          17:01-08:59
        tuesday         17:01-08:59
        wednesday       17:01-08:59
        thursday        17:01-08:59
        friday          17:01-08:59
        saturday        17:01-08:59
        }

Este fin de semana me he hecho con un Iphone 3g de los viejunos. El iphone fue comprado con movistar, por lo que no podía utilizar mi tarjeta de Yoigo. Tras unas cuantas horas documentandome (Mi primer iphone, mi primer Jailbreak), he conseguido actualizar ios, hacer el Jailbreak y el Unlock.

Paso a describir los pasos que he seguido. Primero, un pequeño glosario

Jailbreak:Jailbreak (en español, escaparse de la cárcel o, desbloqueo) es un proceso que permite a los usuarios de los dispositivos iPhone desbloquear el dispositivo para ejecutar aplicaciones distintas a las alojadas en App Store, así como instalar extensiones de aplicaciones y complementos del Sistema Operativo (iOS). En nuestro caso, nos permite instalar la aplicación ‘Cydia’ (http://cydia.saurik.com/), que incorpora mejoras sobre el iOS original.

Unlock: El término unlock se refiere a la eliminación del bloqueo que las compañías telefónicas ponen en los dispositivos que venden, de forma que no el terminal no se pueda utilizar con una tarjeta SIM de otra compañía.

iOS: (anteriormente denominado iPhone OS) es un sistema operativo móvil de Apple desarrollado originalmente para el iPhone, siendo después usado en todos los dispositivos iPhone, iPod Touch e iPad. Es un derivado de Mac OS X, que a su vez está basado en Darwin BSD. Otro sistema *NIX, al fin y al cabo, pero muy propietario.

Baseband: Parte del iOS que se encarga de las comunicaciones. Hasta ahora todas las liberaciones por software implican modificar el baseband.

Firmware: Cambiar el firmware implica, actualizar la versión del sistema operativo, pero no implica actualizar el BaseBand. En nuestro caso, vamos a instalar siempre Firmwares ‘cocinados’, es decir, modificados para que hagan lo que queremos, en nuestro caso, el unlock de la sim.

modo DFU: El modo DFU, es un modo especial de recuperación del iPhone, podemos encontrar el método en el que activarlo en muchos sitios y videos en Youtube, no tiene pérdida. (http://www.esferaiphone.com/tutoriales/modo-dfu/)

Fuente: wikipedia, google, e incluso, Yahoo respuestas.

Procedimiento para el JailBreak + UnLock. (Al menos el que he seguido yo)

1 – Actualizar nuestro firmware a la última versión desde iTunes.

2 – comprobar si nuestra versión de iphone es compatible con los dos metodos. Podemos utilizar esta web: http://jailbreak-me.info/jailbreak-and-unlock-wizard.html

3 – Descargar el firmware cocinado que coincida con nuestra versión desde aqui: http://www.felixbruns.de/iPod/firmware/

4 – Nos descargamos y ejecutamos el programa redsn0w. Nos pedirá el ficheor descargado en el paso anterior. Nos pedirá entrar en modo DFU. El resto ya lo hace él.

5 – El sistema se reiniciará. Parecerá que no ha pasado nada, pero tendremos instalada una nueva app, Cydia. La ejecutamos. Tardará un rato. Una vez que termine, entramos de nuevo. Nos preguntará si somos user, hacker o developer. Decimos que User.

6 – Para instalar la aplicación ultrasnow, que es la que nos liberará el teléfono, necesitamos estar conectados a internet. Recordad niños, wifi on, que no os pase como a mí, que en este paso he estado una hora preguntandome que pasaba . vamos en Cydia a “Manage” – “Sources” – “edit” – “Add” y añadimos http://repo666.ultrasn0w.com. Nos saldran unos avisos que dirán “Imposible enconrar la red movil”, los ignoramos. Una vez hecho todo esto:

7 – Desde la opcion ” ” de Cydia, buscamos e instalamos la última versión de ultrasn0w, reiniciamos el iphone y .. tachán! ya tengo linea con mi tarjeta Yoigo.

Según reinicio el iPhone, introduzco el PIN y llamo al 622 (at. cliente de Yoigo) para comprobar que tengo linea y funciona.

Por último, la activación de datos 3g.

Para yoigo es asín: Ajustes–>General–>Red. Aquí Activamos 3g, Datos Moviles e Itinerancia de Datos. Vamos a red de datos moviles y en punto de acceso escribimos “internet”.

Ya tenemos twitter.

Otros enlaces de ayuda: http://www.arturogoga.com/2010/11/29/liberar-iphone-3gs-3g-con-ios-4-2-1-con-redsn0w-ultrasn0w/ (En el que más me he basado)

Niños, si lo he hecho yo, cualquiera puede.

Un saludo.

MiJacK.