Hola Visitante

Mostrar Mensajes

Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.


Temas - Berni69

Páginas: [1]
1
Noticias del Blog / Toshiba Qosmio X305-Q708
« en: Abril 29, 2017, 11:18:42 am »


 


Visitando TechPowerUp encontramos un portátil impresionante elToshiba Qosmio X305-Q708.


Un portátil básicamente para jugones con sus tres gráficas y bastante potencia. Tenemos una pantalla de 17″ y una gráfica NVidia GeForce 9400M con memoria integrada y dos 9800M GTSdedicadas, cada una con 512 MB de memoria GDDR3, tambien cuanta con un procesador bastante potente  un Core 2 Extreme QX9300 a 2.53 GHz, cuenta con 4gb de RAM DDR3 de serie, en´cuestión de almacenamiento  tiene unos discos duros un SSDde 128 GB y uno tradicional de 320. Las conexiones son Chip WiFi Atheros (802.11 b/g/n), Bluetooth 2.1.


Opinión: yo tengo un toshiba qosmio f30 y la verdad esque no tengo casi ninguna pega la resolución de la pantalla es inigualable  la gráfica aguanta bastante bien los juegos el sonido se escucha bastante bien.


Algunos fallos que no me gustan es la batería que no me a durado mucho la verdad y el peso que la verdad los4kg que pesa se nota a la hora de transportarlo



2
Noticias del Blog / Actualizar DNS con DHCP
« en: Abril 29, 2017, 11:00:47 am »

En la entrada anterior vimos como montar un servidor bind y un server dhcp en linux para bloquear la resolución de algunas webs en nuestra red de área local. (Suplantando nuestros dns en la red local). Ya que tenemos el laboratorio montado en casa, podemos mejorar sus funcionalidades haciendo que todos los dispositivos que reciban una dirección DHCP de nuestro servidor queden registrados en el DNS con una entrada dinámica. Hacerlo a mano sería bastante laborioso y en breves tendríamos la zona dns desactualizada.


Para ello me he creado una zona a la que llamaré “canostra.local”, esta zona engloba mi red local. Siguiendo con el ejemplo anterior, tendremos 3 dispositivos en la red:



192.168.22.1  --> Gateway
192.168.22.2  --> Equipo Windows con reserva de DHCP
192.168.22.11 --> DNS + DHCP.

Para poder crear el dynamic dns, el primer paso es editar el archivo para crear las nuevas zonas:



sudo vi /etc/bind/named.conf.local


Se van a crear 2 zonas, la primera de resolución directa (cuando haces un nslookup de un dominio para que te devuelva la ip) y la segunda zona de resolución inversa (al hacer un nslookup de una ip el dns puede devolverte el dominio asociado). Además de estas zonas, debemos decir que solo se permita actualizar dinámicamente una zona desde el servidor dhcp, en este caso la misma raspberry pi (127.0.0.1), además de especificar la clave que se debe usar para realizar el update.



include "/etc/bind/rndc.key";
controls {
    inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; };
};

### dynamic zones (updated by DDNS) #########

zone "canostra.local" {
    type master;
    file "/etc/bind/db.canostra.local";
    allow-update { key "rndc-key"; };
};

zone "22.168.192.in-addr.arpa" {
    type master;
    notify no;
    file "/etc/bind/db.192.168.22";
    allow-update { key "rndc-key"; };
};

Si os fijáis en la segunda zona tiene un nombre un poco extraño, esto es una zona “legacy” de los principios de Internet. El formato del nombre de la zona viene especificado por la red a la que va a resolver con sus octetos en orden inverso.


Los siguiente que neceistamos hacer es crear los archivos



/etc/bind/db.canostra.local
/etc/bind/db.192.168.22

En estos archivos especificaremos la zona y sus propiedades:



$ORIGIN .
$TTL 86400      ; 1 day
canostra.local            IN SOA  ns.canostra.local. root.localhost. (
                                3          ; serial
                                604800     ; refresh (1 week)
                                86400      ; retry (1 day)
                                2419200    ; expire (4 weeks)
                                604800     ; minimum (1 week)
                                )
                        NS      ns.canostra.local.
                        A       192.168.22.1
$ORIGIN canostra.local.
mi-pc                   A       192.168.22.2
ns                      NS      192.168.22.11

Fijaos bien en la notación de “canostra.local IN SOA ns.canostra.local. root.localhost. ” y los puntos al final del ns, si no los ponemos no funcionará y dará un error de carga. El otro punto importante es que el “email” debe existir, en nuestro caso root.localhost existe por defecto. Con esta configuración conseguiremos que al registrarse nuevas máquinas en la red, vayan apareciendo entradas del tipo A en esta zona.



$ORIGIN .
$TTL 907200     ; 1 week 3 days 12 hours
22.168.192.in-addr.arpa IN SOA  ns.canostra.local. root.localhost. (
                                2014071403 ; serial
                                28800      ; refresh (8 hours)
                                604800     ; retry (1 week)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                                )
                        NS      ns.canostra.local.
$ORIGIN 22.168.192.in-addr.arpa.
$TTL 3600       ; 1 hour
1                        PTR     canostra.local.
6                        PTR     mi-pc.canostra.local

Igual que antes tened cuidado con los puntos al final de los dominios. Con esta configuración se ha conseguido crear la zona inversa de resolución para el dominio canostra.local.


Para comprobar que todo funciona se debe reiniciar el servicio de dns:



sudo service bind9 restart

Si todo va bien, podemos probar la resolución directa y la resolución inversa:



$nslookup mi-pc.canostra.local
Server:         127.0.0.1
Address:        127.0.0.1#53

Name:   mi-pc.canostra.local
Address: 192.168.22.6

Inversa:



$ nslookup 192.168.22.6
Server:         127.0.0.1
Address:        127.0.0.1#53

6.22.168.192.in-addr.arpa       name = mi-pc.canostra.local.22.168.192.in-addr.arpa.

$ nslookup 192.168.22.1
Server:         127.0.0.1
Address:        127.0.0.1#53

1.22.168.192.in-addr.arpa       name = canostra.local.

Si el DNS ha conseguido resolver estas direcciones es que lo hemos creado correctamente. Como siempre es recomendable ir revisando el syslog ya que da pistas sobre los errores que podemos tener en la configuración.


Si en el syslog vemos que aparecen errores del tipo



zone canostra.local/IN: MI_PC.canostra.local/A: bad owner name

Es debido a que la barra baja no está permitida por defecto, para habilitarla deberemos editar el archivo:



sudo vi /etc/bind/named.conf.options

Y añadir las entradas:



check-names master warn;
check-names slave warn;

Si vemos errores de que hay problemas de integridad con dnssec, será necesario añadir las siguientes opciones al mismo archivo:



dnssec-enable yes;
dnssec-validation no;
dnssec-lookaside auto;

Para que DHCP pueda actualizar las entradas DNS será necesario un último paso, dar permisos de escritura al usuario bind a la carpeta donde están las zonas:



chown -R bind:bind /etc/bind/

En este punto del manual, ya podemos pasar a editar la configuración de DHCP:



sudo cat /etc/dhcp/dhcpd.conf

En este archivo debemos comentar la línea:



#ddns-update-style none;

Y añadir las siguientes justo abajo:



#Configuracion para integrar con dns#

ddns-update-style interim;
include "/etc/bind/rndc.key";

zone canostra.local. {
        primary 127.0.0.1;
        key "rndc-key";
}

ddns-domainname "canostra.local";

Con estas líneas especificamos que zona se debe utilizar para actualizar el dns, y con que  clave. Además en la configuración del rango de DHCP debemos volverlo a especificar (además de especificar la zona inversa):



# Rangos
subnet 192.168.22.0 netmask 255.255.255.0 {
      range 192.168.22.15 192.168.22.250;
      option subnet-mask 255.255.255.0;
      option routers 192.168.22.1;

      #integracion ddns
      # DNS zones to update

      zone 22.168.192.in-addr.arpa. {
            primary 192.168.22.11;
            key "rndc-key";
      }

      zone canostra.local. {
            primary 192.168.22.11;
            key "rndc-key";
      }

}

Ya solo queda reiniciar el servidor dhcp y revisar que se añaden entradas en el dns, para ello basta con observar el archvio de syslog. En este punto he conectado mi teléfono a la red local:



tail -200f /var/log/syslog
Apr 29 09:35:03 raspberrypi named[3036]: client 192.168.22.11#42676/key rndc-key: updating zone 'canostra.local/IN': adding an RR at 'MI-TELEFONO.canostra.local' A
Apr 29 09:35:03 raspberrypi dhcpd: Added new forward map from MI-TELEFONO.canostra.local to 192.168.22.200
Apr 29 09:35:03 raspberrypi named[3036]: client 192.168.22.11#42676/key rndc-key: signer "rndc-key" approved
Apr 29 09:35:03 raspberrypi named[3036]: client 192.168.22.11#42676/key rndc-key: updating zone '22.168.192.in-addr.arpa/IN': deleting rrset at '200.22.168.192.in-addr.arpa' PTR
Apr 29 09:35:03 raspberrypi named[3036]: client 192.168.22.11#42676/key rndc-key: updating zone '22.168.192.in-addr.arpa/IN': adding an RR at '200.22.168.192.in-addr.arpa' PTR
Apr 29 09:35:03 raspberrypi dhcpd: Added reverse map from 200.22.168.192.in-addr.arpa. to MI-TELEFONO.canostra.local

Si hicieras un ping a MI-TELEFONO.canostra.local debería contestarte:



ping MI-TELEFONO.canostra.local
PING MI-TELEFONO.canostra.local (192.168.22.200) 56(84) bytes of data.
64 bytes from MI-TELEFONO.canostra.local (192.168.22.200): icmp_seq=1 ttl=64 time=279 ms
64 bytes from MI-TELEFONO.canostra.local (192.168.22.200): icmp_seq=2 ttl=64 time=220 ms
64 bytes from MI-TELEFONO.canostra.local (192.168.22.200): icmp_seq=3 ttl=64 time=156 ms

Si quisiéramos poder resolver los nombres de hosts sin tener que especificar el dominio, deberíamos añadir la siguiente linea en el  archivo de configuración de dhcp:



option domain-search "canostra.local";

Pues con esto la entrada de hoy, espero que os haya gustado.



3
Noticias del Blog / Suplantando nuestros DNS en la red local
« en: Abril 29, 2017, 12:06:09 am »

Desde hace un tiempo, es muy común que la gente utilice su teléfono indiscriminadamente a todas horas. Esta mañana cuando desperté me dirigí a la cocina a saludar a mis padres y como es costumbre tras varios minutos apareció mi hermana escuchando un servicio de streaming de audio a todo volumen, le pedí por favor que lo desconectara y como es pasó de mi, así que esto basto para encender mi creatividad. Como no tengo el hardware necesario para montar un Firewall + Squid para que me aplique control parental, he decidido montar un aproximación con mi Raspberry (Ya os aviso de que es muy rudimentario, pero de momento efectivo). La finalidad de este post es poder bloquear el acceso a una serie de dominios en determinadas horas del día.


Evidentemente, para alguien que sepa algo de redes este procedimiento no sirve de nada, bastaría con forzar los dns de la máquina en la que se está trabajando a los de nuestro ips/google/opendns para que nos sirviera las entradas reales, pero creo que para mi propósito me sirve sobrado.


Antes de empezar supondremos que tenemos una RED de área local que corresponde con el rango 192.168.22.0/24 dónde



192.168.22.1  --> Gateway
192.168.22.2  --> Equipo Windows con reserva de DHCP
192.168.22.11 --> DNS + DHCP.

En la siguiente imagen os presento una aproximación (en este caso no sería ROGUE DNS porque nosotros lo permitimos con nuestro servidor DHCP, ya que es nuestra red, pero si montáramos este escenario intentando suplantar el DHCP real se podría considerar un ataque) de lo que realizaremos:


Rogue DNS


En mi caso el Router del ISP no me permite configurar que servidores DNS serán servidos con este protocolo por lo que tendré que instalar un servidor de DHCP en la Raspberry y desactivar el propio del router.




El primer paso consiste en instalar Raspbian en nuestro dispositvo, acto seguido instalaremos el servidor DNS (bind9) y DHCP (isc-dhcp-server):



sudo apt-get install bind9 dnsutils
sudo apt-get install isc-dhcp-server

Una vez se han terminado de instalar estos paquetes, debemos configuramos servidor DNS para hacer de relay (El relay permite resolver Zonas DNS que no son nuestras. P.E google.es). Para ello debemos editar:


	
sudo vi /etc/bind/named.conf.options

Dentro de la sección options añadimos los forwarders esto permite utilizar DNS externos para que nos resuelvan consultas que no tenemos en cache ni somos maestros de la zona. En este ejemplo se añadirán los un servidor de nombres de Opendns (Cisco) y un servidor de nombres de Google (en la práctica son muy utilizados). Notad que utilizo vi para editar el archivo si no estáis acostumbrados a este editor quizá sea mejor que utilicéis nano.



forwarders {
       208.67.222.222;
       8.8.8.8;
};
dnssec-enable yes;
dnssec-validation no;
dnssec-lookaside auto;

Una vez hemos terminado de hacer cambios, reiniciamos el servicio:



sudo service bind9 restart

Para probar si los cambios se han aplicado bien, utilizaremos la utilidad nslookup para resolver direcciones en nuestro servidor de DNS, para ello es necesario especificar que el server que usaremos es el 127.0.0.1.



$ nslookup
> server 127.0.0.1
Default server: 127.0.0.1
Address: 127.0.0.1#53
> google.es
Server:         127.0.0.1
Address:        127.0.0.1#53
Non-authoritative answer:
Name:   google.es
Address: 216.58.201.131

Si resuelve correctamente significa, que los forwarders de dns se han configurado correctamente.


El siguiente paso es crear una zona maestra para hacer un “override” de un dominio determinado. Como el servidor de nombres DNS primero revisa si tiene una zona (un dominio y todas sus entradas asociadas) y si no la tiene la pregunta a los forwarders, podemos aprovechar este comportamiento para sobrescribir el dominio que no queremos que sea accesible desde la red.


Cuando estás realizando un ataque, este montaje es muy común en redes en la que los elementos de red no controlan por donde les debe venir la información del servidor DHCP, esto se conoce como suplantación de DHCP y rogue/suplantación de DNS.


Para hacer esta configuración, lo primero que hay que hacer es editar el archivo:



sudo vi /etc/bind/named.conf.local

Y crear la zona para la web que queremos servir. En mi caso me interesa bloquear/suplantar la web: “miwebbloqueada.com”



zone "miwebbloqueada.com" {
type master;
file "/etc/bind/db.miwebbloqueada.com";
};

El siguiente paso es crear la base de datos de información del dominio. Este fichero contendrá todas los “Resource Records” (entradas del DNS asociadas a un dominio). Estas entradas nos facilitan información sobre los servidores de nombre de un dominio, la dirección ip que debe resolver un subdominio de ese dominio, los servidores de correo de un dominio, y mucha más información que no viene al caso.


	
sudo cp /etc/bind/db.local /etc/bind/db.miwebbloqueada.com

Editamos el archivo para que quede con la información mínima para que resuelva una ip distinta a la original (como localhost), con esto podríamos hacer un ataque de “fishing” o un bloqueador de publicidad, o de servicios molestos por la mañana…


	
sudo vi /etc/bind/db.miwebbloqueada.com
;
; BIND data file for local loopback interface
;
$TTL    604800
@       IN      SOA     ns.miwebbloqueada.com root.localhost. (
 2         ; Serial
604800         ; Refresh
 86400         ; Retry
2419200         ; Expire
604800 )       ; Negative Cache TTL
;
@   IN  NS  ns.miwebbloqueada.com.
ns      IN      NS      192.168.22.11
@       IN      A       127.0.0.1

Una vez configurado debemos reiniciar el servicio de DNS.



sudo service bind9 restart

Si todo ha ido bien deberíamos ver en el syslog que la zona ha sido cargada correctamente



$ tail -f /var/log/syslog
Apr 28 20:39:11 raspberrypi named[15686]: managed-keys-zone: loaded serial 2
Apr 28 20:39:11 raspberrypi named[15686]: zone 0.in-addr.arpa/IN: loaded serial 1
Apr 28 20:39:11 raspberrypi named[15686]: zone 127.in-addr.arpa/IN: loaded serial 1
Apr 28 20:39:11 raspberrypi named[15686]: zone 255.in-addr.arpa/IN: loaded serial 1
Apr 28 20:39:11 raspberrypi named[15686]: zone miwebbloqueada.com/IN: ns.miwebbloqueada.com/NS '192.168.22.11.miwebbloqueada.com' has no address records (A or AAAA)
Apr 28 20:39:11 raspberrypi named[15686]: zone miwebbloqueada.com/IN: loaded serial 2
Apr 28 20:39:11 raspberrypi named[15686]: zone localhost/IN: loaded serial 2
Apr 28 20:39:11 raspberrypi named[15686]: all zones loaded

Sale una advertencia que no es del todo correcta, nos viene a decir que solo hay configurado el subdominio “.” y no hay ninguno más por lo que todos los subdominios se resolverían igual. La prueba de fuego igual que antes, es ejecutar nslookup. Con esta utilidad, deberíamos poder ver la web en cuestión apuntando a la IP que hayamos puesto



$ nslookup
> server 127.0.0.1
Default server: 127.0.0.1
Address: 127.0.0.1#53
> miwebbloqueada.com
Server:         127.0.0.1
Address:        127.0.0.1#53

Name:   miwebbloqueada.com
Address: 127.0.0.1

Si resuelve bien, aquí termina la configuración del DNS.


Como ya os comenté antes, mi router no me permite modificar las propiedades básicas del protocolo DHCP por lo que tendré que desactivarlo y montar mi propio server. Si vuestro router lo permitiese, bastaría con cambiar los DNS por defecto y poner que resuelva la IP de vuestra Raspberry. Dicho esto, pasamos a la configuración del DHCP.


Editamos configuración para poner la IP de la Raspberry manualmente para que sea estática ya que el servidor DHCP será la propia Raspberry (cuidado cuando se edite esta configuración, si no es correcta o acorde con vuestra red puede dejar inaccesible por red la raspberry en el próximo reinicio). Para ello debemos editar el archivo:



sudo vi /etc/network/interfaces

Una vez abierto debemos comentar la linea



#iface eth0 inet manual

Y a continuación escribir (adaptando las ips a vuestra red):



allow-hotplug eth0
iface eth0 inet static
address 192.168.22.11
netmask 255.255.255.0
gateway 192.168.22.1
nameserver 8.8.8.8

Creamos una copia de seguridad de la configuración inicial del DHCP:



cp /etc/default/isc-dhcp-server  /etc/default/isc-dhcp-serverold
cp /etc/dhcp/dhcpd.conf  /etc/dhcp/dhcpd.confold

Editamos el server DHCP para que escuche en eth0 que, es la única interfaz de la Raspberry:



sudo vi /etc/default/isc-dhcp-server

Y buscamos la línea:



INTERFACES=”″

Y la reemplazamos por esta otra:



INTERFACES=”eth0″

Una vez hemos hecho que el server escuche en eth0 hay que indicarle el comportamiento que debe tener el DHCP:



sudo vi /etc/dhcp/dhcpd.conf

A continuación os pego una copia de mi configuración del DHCP, lo importante aquí es configurar el campo “option domain-name-servers 192.168.22.11;” para que apunte a la raspberry y los rangos de IPs. Adicionalmente, he creado un elemento con IP reservada, en este caso mi equipo, os será útil cuando tengáis que abrir los puertos. Como punto extra, os diré que tener reservada la IP en este DHCP me permite llevar un control de mis dispositivos ya que en el router no podía ponerles nombres. Cuando vayáis a configurar vuestro DHCP aseguraos de que dentro de subnet esté la “option routers” apuntando a vuestro Gateway, sino perderéis conectividad con Internet.



#Configuracion del servifor DHCP
ddns-update-style none;
option domain-name "micasa";
option domain-name-servers 192.168.22.11;
default-lease-time 7200;
max-lease-time 21600;
authoritative;
log-facility local7;

# Rangos
subnet 192.168.22.0 netmask 255.255.255.0 {
      range 192.168.22.15 192.168.22.200;
      option routers 192.168.22.1;
      option subnet-mask 255.255.255.0;
}


# ASIGNACIONES ESTATICAS  #
host mipc {
   hardware ethernet 00:11:22:33:44:55;
   fixed-address 192.168.22.2;
}

Una vez hemos hecho estos cambios, para que surjan efecto, debemos reiniciar el server dhcp:



sudo service dhcpcd restart

Pasados unos segundos, podemos comprobar si el servicio haya arrancado sin errores en los eventos del sistema:



tail -20f /var/log/daemon.log  
Apr 28 21:22:33 raspberrypi dhcpcd[1021]: sending signal TERM to pid 991
Apr 28 21:22:33 raspberrypi dhcpcd[991]: received signal TERM from PID 1021, stopping
Apr 28 21:22:33 raspberrypi dhcpcd[991]: eth0: removing interface
Apr 28 21:22:33 raspberrypi dhcpcd[1021]: waiting for pid 991 to exit
Apr 28 21:22:33 raspberrypi dhcpcd[1021]: dhcpcd[1021]: waiting for pid 991 to exit
Apr 28 21:22:33 raspberrypi dhcpcd[991]: exited
Apr 28 21:22:33 raspberrypi systemd[1]: dhcpcd.service: main process exited, code=exited, status=1/FAILURE
Apr 28 21:22:33 raspberrypi systemd[1]: Unit dhcpcd.service entered failed state.
Apr 28 21:22:33 raspberrypi systemd[1]: Starting dhcpcd on all interfaces...
Apr 28 21:22:33 raspberrypi dhcpcd[1025]: version 6.7.1 starting
Apr 28 21:22:33 raspberrypi dhcpcd[1025]: dev: loaded udev
Apr 28 21:22:33 raspberrypi dhcpcd[1025]: DUID 00:01:00:01:20:7e:13:db:b8:27:eb:e4:b0:68
Apr 28 21:22:33 raspberrypi dhcpcd[1025]: eth0: IAID eb:e4:b0:68
Apr 28 21:22:34 raspberrypi dhcpcd[1025]: eth0: soliciting an IPv6 router
Apr 28 21:22:34 raspberrypi dhcpcd[1025]: eth0: rebinding lease of 192.168.22.11
Apr 28 21:22:34 raspberrypi dhcpcd[1025]: eth0: changing route to 192.168.22.0/24
Apr 28 21:22:34 raspberrypi dhcpcd[1025]: eth0: changing default route via 192.168.22.1
Apr 28 21:22:34 raspberrypi dhcpcd[1025]: forked to background, child pid 1040
Apr 28 21:22:34 raspberrypi systemd[1]: Started dhcpcd on all interfaces.
Apr 28 21:22:46 raspberrypi dhcpcd[1040]: eth0: no IPv6 Routers available

El siguiente paso es desactivar el dhcp del router principal y renovar las IPs en nuestros dispositivos para ver que nos nos sirve nuestro DHCP:



Adaptador de Ethernet Ethernet:

   Sufijo DNS específico para la conexión. . : micasa
   Descripción . . . . . . . . . . . . . . . : Realtek PCIe GBE Family Controller
   Dirección física. . . . . . . . . . . . . : 00-11-22-33-44-55
   DHCP habilitado . . . . . . . . . . . . . : sí
   Configuración automática habilitada . . . : sí
   Vínculo: dirección IPv6 local. . . : fe80::bc04:e853:fee7:e419%26(Preferido)
   Dirección IPv4. . . . . . . . . . . . . . : 192.168.22.2(Preferido)
   Máscara de subred . . . . . . . . . . . . : 255.255.255.0
   Concesión obtenida. . . . . . . . . . . . : viernes, 28 de abril de 2017 19:54:24
   La concesión expira . . . . . . . . . . . : sábado, 29 de abril de 2017 1:38:34
   Puerta de enlace predeterminada . . . . . : 192.168.22.1
   Servidor DHCP . . . . . . . . . . . . . . : 192.168.22.11
   IAID DHCPv6 . . . . . . . . . . . . . . . : 253521765
   DUID de cliente DHCPv6. . . . . . . . . . : 00-01-00-01-1A-ED-3C-DE-1C-6F-65-90-30-42
   Servidores DNS. . . . . . . . . . . . . . : 192.168.22.11
   NetBIOS sobre TCP/IP. . . . . . . . . . . : habilitado

Como podéis observar, el servidor DHCP y el servidor DNS apuntan a nuestra Raspberry Pi por lo que entrada de DNS que no queramos entrada que podemos bloquear.


Ya solo quedaría crear un cron para que copie una config con las db que queremos y lo restablezca pasado X tiempo. Por ejemplo, a mi solo me interesa que esto este activo de 7:00-9:00.


Así que crearé 2 archivos:



/etc/bind/named.conf.local.block
/etc/bind/named.conf.local.noblock

El archivo block contendrá las entradas a las zonas bloqueadas mientras que el noblock no contendrá ninguna zona. Además crearé un pequeño script en bash para hacer el cambio de archivos (como root debemos ejecutar):



touch /root/change-dns.sh
chmod +x /root/change-dns.sh
vi /root/change-dns.sh

Y pegamos el siguiente código:



#!/bin/bash
if [ -f "/etc/bind/named.conf.local.$1" ]; then
        cp -f "/etc/bind/named.conf.local.$1" /etc/bind/named.conf.local
        /usr/sbin/service bind9 restart
else
        echo "File doesn't exist"
fi

Guardamos los cambios y ejecutamos



crontab -e

Dentro del crontab podemos añadir las siguentes lineas:



0 7 * * * bash /root/change-dns.sh "block" > /tmp/block 2>  /tmp/block.err
0 9 * * * bash /root/change-dns.sh "noblock" > /tmp/block 2>  /tmp/block.err


4
Noticias del Blog / Let’s Encrypt la CA Open Source
« en: Abril 24, 2017, 03:19:52 pm »

Para todos aquellos que no conozcáis Let’s Encrypt os invito a que visitéis su Web  .  Esta entidad certificadora es Open Source y expide certificados gratuitamente siempre que podamos verificar la propiedad del sitio web mediante el protocolo ACME (automatic certificate management environment).  Este protocolo nos permite administrar y expedir certificados de manera automática.


La única pega de esta entidad es que la validez de los certificados es de 90 días. Por lo que cada 3 meses hay que renovarlos en el servidor. Existen varios mecanismos de autenticación de un dominio, el más sencillo es la comprobación web donde la entidad certificadora nos solicita que creemos un .html con un contenido específico en nuestro dominio. Para automatizar el uso de ACME se creó un proyecto que se llama  dehydrated en el que se gestionan en bash las llamadas a letsencrypt. Este proyecto es modular y permite parametrizar fácilmente las opciones de despliege de los certificados:


https://github.com/lukas2511/dehydrated


Este tipo de autenticación vía http presenta un problema, no puedes autenticar subdominios no publicados en Internet ya que la CA no podría conectarse a comprobar el challenge. Para este tipo de escenarios podemos utilizar la autenticación DNS01, donde se publica la información en un registro TXT del DNS que nos gestiona el dominio. Para usar este tipo de challenge, hay que especificar un “hook” a dehydrated para indicarle como tiene que interactuar con nuestro DNS.


En mi caso dispongo de una solución DNS de EfficientIP solid server, he creado un hook para usar dehydrated con SolidServer. Se puede encontrar en github:


https://github.com/berni69/solidserver-challenge


Para usarlo bastaría con descargarlo junto con dehydrated:



$ cd ~
$ git clone https://github.com/lukas2511/dehydrated
$ cd dehydrated
$ mkdir hooks
$ git clone https://github.com/berni69/solidserver-challenge.git hooks
$ chmod +x dehydrated
$ ./dehydrated --challenge dns-01  --cron --domain "test.example.com" --hook "hooks/solid-hook.py"

Saludos!



5
Noticias del Blog / Nuevo Swifi Keygen: 1.0.0.1
« en: Abril 21, 2017, 09:13:38 am »

Como ya dije hace tiempo, tengo lista la nueva versión del SWifi con varias mejoras tanto de rendimiento como de aspecto, además de incorporar nuevos algoritmos de generación.



Versión: 1.0.0.1

-Optimizado el generador de Stkeys

-Optimizado generador magic-wlan

-Añadido control de versiones, informa si hay una version mas actual disponible.

-Añadido algoritmo experimental para las JAZZTEL 00:1A:2B

-Añadido mensaje de confirmación antes de generar todo el diccionairo de genTekom

-Añadido segundo patron para 00:19:15 (Comtrend)

-Añadido la utilización de Threads

-Cambio por completo del Skin del programa

-Añadidos Forms de error, barra de progreso

-Añadido form de Acerca de

-Añadido GenTekom WLAN_XXXX MAC 00:19:15

-Añadido segundo patrón para WLAN_XXXX 00:1A:2B

-Añadido segundo patrón para WLAN_XX 40:4A:03

-Añadido segundo patrón para 50:67:F0 (WLAN_XX experimental)


Fecha: zz-xx-yyyy

Version: <1.0.0.0


Redes compatibles:

WLAN_XX

“00:60:B3”

“00:01:38”

“00:03:C9”

“00:A0:C5”

“00:16:38”

“00:13:49”

“00:02:CF”

“00:1A:2B”

“00:19:CB”

“00:19:15”

“00:30:DA”

“00:1D:20”

“00:23:F8”

“00:01:36”

“00:03:DA”

“00:1F:9F”

“E0:91:53”

“40:4A:03”

“50:67:F0”

“C8:6C:87”

JAZZTEL_XX

“00:1A:2B”

ThomsonXXXXXX

SpeedTouchXXXXXX

WLANXXXXXX

WifiXXXXXX

YaComXXXXXX

ONOXXXX

Dlink

Rwlan

Tele2

Orange XXXXXX

VerizonXXXXX

mac2wepkey Infinitum

discus

JAzztel_XXXX

“64:68:0C”

“00:1F:A4”

“64:68:0C”

WLAN_XXXX

“64:68:0C”

“00:1D:20”

“00:1F:A4”

“38:72:C0”

“00:1A:2B”

“F4:3E:61”

SkyV1


Descarga


Código fuente:


https://github.com/berni69/SwifiKeygen



6
Sección Wireless / Nuevo Swifi Keygen: 1.0.0.1
« en: Octubre 17, 2012, 10:32:52 pm »
Como ya dije hace tiempo, tengo lista la nueva versión del SWifi con varias mejoras tanto de rendimiento como de aspecto, además de incorporar nuevos algoritmos de generación.



Versión: 1.0.0.1
-Optimizado el generador de Stkeys
-Optimizado generador magic-wlan
-Añadido control de versiones, informa si hay una version mas actual disponible.
-Añadido algoritmo experimental para las JAZZTEL 00:1A:2B
-Añadido mensaje de confirmación antes de generar todo el diccionairo de genTekom
-Añadido segundo patron para 00:19:15 (Comtrend)
-Añadido la utilización de Threads
-Cambio por completo del Skin del programa
-Añadidos Forms de error, barra de progreso
-Añadido form de Acerca de
-Añadido GenTekom WLAN_XXXX MAC 00:19:15
-Añadido segundo patrón para WLAN_XXXX 00:1A:2B
-Añadido segundo patrón para WLAN_XX 40:4A:03
-Añadido segundo patrón para 50:67:F0 (WLAN_XX experimental)

Fecha: zz-xx-yyyy
Version: <1.0.0.0

Redes compatibles:
  WLAN_XX
                       "00:60:B3"
                       "00:01:38"
                       "00:03:C9"
                       "00:A0:C5"
                       "00:16:38"
                       "00:13:49"
                       "00:02:CF"
                       "00:1A:2B"
                       "00:19:CB"
                       "00:19:15"
                       "00:30:DA"
                       "00:1D:20"
                       "00:23:F8"
                       "00:01:36"
                       "00:03:DA"
                       "00:1F:9F"
                       "E0:91:53"
                       "40:4A:03"
                       "50:67:F0"
                       "C8:6C:87"
JAZZTEL_XX
                       "00:1A:2B"
ThomsonXXXXXX
SpeedTouchXXXXXX
WLANXXXXXX
WifiXXXXXX
YaComXXXXXX
ONOXXXX
Dlink
Rwlan
Tele2
Orange XXXXXX
VerizonXXXXX
mac2wepkey Infinitum
discus
JAzztel_XXXX
           "64:68:0C"
          "00:1F:A4"
          "64:68:0C"
WLAN_XXXX
                    "64:68:0C"
          "00:1D:20"
          "00:1F:A4"
          "38:72:C0"
          "00:1A:2B"
          "F4:3E:61"
SkyV1


Páginas: [1]