jueves, 17 de noviembre de 2016

Livescribe 3 - Best review ever

If you are looking for a good review with stress testing for the Livescribe 3, you are on the right place! Livescribe is a SmartPen that transfer whatever you write on paper* to you phone or tablet, here's the promotional video of the product.  





Like any other gadget in the market you may wonder: Does it work? How reliable it is?
Should I buy it? and I'm hopping to answer all this questions for you today. 

Does it work?
Yes it does, the way it works is by a combination of a camera attached to the pen and a special dotted paper which allows the camera to track the movements while you write, and it tracks the results pretty accurately.


How reliable it is?
I have to admit that it is pretty good tracking your writing, which I will illustrate with the the first to paragraphs of Harry Potter.

Mr. and Mrs. Dursley, of number four, Privet Drive, were proud to say that they were perfectly normal, thank you very much. They were the last people you'd expect to be involved in anything strange or mysterious, because they just didn't hold with such nonsense.

Mr. Dursley was the director of a firm called Grunnings, which made drills. He was a big, beefy man with hardly any neck, although he did have a very large mustache. Mrs. Dursley was thin and blonde and had nearly twice the usual amount of neck, which came in very useful as she spent so much of her time craning over garden fences, spying on the neighbors. The Dursleys had a small son called Dudley and in their opinion there was no finer boy anywhere.

Real version (paper)


Digital version (tablet)

Ignoring my terrible handwriting skills, the digital version of it is extraordinarily good compared to what I have on the paper, once you have it there, you can turn it into digital text to copy, edit, etc. Note some mistakes during the conversion because the app was not able to understand my writing (and I don't blame it).


NOTE: Results may vary according to your handwriting and writing habits, for example I don't put much pressure on the dots above the letter  i  and sometimes the pen was not recording that, but as soon as I noticed it and started adding more pressure to those little dots the problem disappeared. 

Something that I would like to highlight are how to handle writing errors... like with any other pen, if you made a mistake, you either strike out the mistake, use liquid paper or other alternative, well with the Livescribe is similar.

The only way I have found to correct errors -without re-writing the whole page again- is to delete the block where the mistake was made on the app, and then write over, since using liquid paper will prevent the camera to detect the dots on the paper.


Should I buy it?
There is no doubt this is a very particular gadget for a very particular audience with very particular needs, if you are part of this selected group go for it!
If you are planning to uses the Livescribe for quick notes and small messages... you should not buy it since all the setup and syncing process may take longer than using regular paper/pen or sending a quick email.

martes, 5 de abril de 2016

[Cisco IOS] DMVPN Phase 3 with IKEv2

For my own personal reference I include the following information, so I would dive much into details, hope you can find this useful

DMVPN Operation

A Dynamic Multipoint VPN is an evolved iteration of hub and spoke tunneling, it provides a secure network where data exchange between sites is possible without needing to pass traffic through an organization's headquarter virtual private network (VPN) server or router.

DMVPN offers an elegant solution to this problem: multipoint GRE tunneling. Recall that a GRE tunnel encapsulates IP packets with a GRE header and a new IP header for transport across an untrusted network. Point-to-point GRE tunnels have exactly two endpoints, and each tunnel on a router requires a separate virtual interface with its own independent configuration. Conversely, a multipoint GRE tunnel allows for more than two endpoints, and is treated as a non-broadcast multiaccess (NBMA) network.

VPNs traditionally connect each remote site to the headquarters; the DMVPN essentially creates a mesh VPN topology. This means that each site (spoke) can connect directly with all other sites, no matter where they are located.

DMVPN deployments include mechanisms such as GRE tunneling and IPsec encryption with Next Hop Resolution Protocol (NHRP) routing that are designed to reduce administrative burden and provide reliable dynamic connectivity between sites.

For additional information please check the following links:
Cisco.com // Networkhobo.com // Firewall.cx

Below examples are based on the following network diagram, only relevant parts are shown.



#############################################
############# HUB CONFIGURATION #############
#############################################

router eigrp 100
 net 0.0.0.0
!
! crypto policy proposal, policy and key
crypto ikev2 proposal IKEv2_PROPOSAL
 encryption aes-gcm-256
 prf sha256
 group 5
!
crypto ikev2 keyring IKEV2_KEY
 peer DMVPN
  address 0.0.0.0 0.0.0.0
  pre-shared-key local cisco-ABC
  pre-shared-key remote cisco-123
!
crypto ikev2 policy IKEv2_POLICY
 proposal IKEv2_PROPOSAL
!
crypto ikev2 profile IKEV2_PROFILE
 match identity remote any
 authentication remote pre-share
 authentication local pre-share
 keyring local IKEV2_KEY
!
crypto ipsec transform-set TRANS esp-gcm 256
mode transport
!
crypto ipsec profile IKEV2_IPSEC
set transform-set TRANS
set ikev2-profile IKEV2_PROFILE
!
! tunnel configuration
interface Tunnel100
 ip address 172.16.1.1 255.255.255.0
 no ip redirects
 bandwidth 1000
 delay 1000
 tunnel source GigabitEthernet0/0
 ! there is not tunnel destination because is not p2p
 tunnel mode gre multipoint
 tunnel key 100
 tunnel protection ipsec profile IKEV2_IPSEC
 ! ensures longer packets are fragmented before they are encrypted;
 ! otherwise, the receiving router would have to do the reassembly.
 ip mtu 1400
 ip tcp adjust-mss 1360
 ip nhrp authentication CISCO456
 ip nhrp network-id 100
 ip nhrp holdtime 300
 ip pim sparse-dense-mode
 ! enabling DMVPN phase 3, allowing dynamic spoke to spoke
 ip nhrp shortcut
 ip nhrp redirect
 ! only for HUBs
 ip nhrp map multicast dynamic
 no ip split-horizon eigrp 1


Please note that the only change between Spoke1 and Spoke 2 is the IP address of the tunnel.

################################################
########### SPOKE1 & 2 CONFIGURATION ############
################################################

router eigrp 100
 net 0.0.0.0
!
! crypto policy proposal, policy and key
crypto ikev2 proposal IKEv2_PROPOSAL
 encryption aes-gcm-256
 prf sha256
 group 5
!
crypto ikev2 keyring IKEV2_KEY
 peer DMVPN
  address 0.0.0.0 0.0.0.0
  pre-shared-key local cisco-123
  pre-shared-key remote cisco-ABC

!
crypto ikev2 policy IKEv2_POLICY
 proposal IKEv2_PROPOSAL
!
crypto ikev2 profile IKEV2_PROFILE
 match identity remote any
 authentication remote pre-share
 authentication local pre-share
 keyring local IKEV2_KEY
!
crypto ipsec transform-set TRANS esp-gcm 256
mode transport
!
crypto ipsec profile IKEV2_IPSEC
set transform-set TRANS
set ikev2-profile IKEV2_PROFILE
!
! tunnel configuration - SPOKE
interface Tunnel100
 ip address 172.16.1.2 255.255.255.0
 no ip redirects
 bandwidth 1000
 delay 1000
 tunnel source GigabitEthernet0/0
 ! there is not tunnel destination because is not p2p
 tunnel mode gre multipoint
 tunnel key 100
 tunnel protection ipsec profile IKEV2_IPSEC
 ! ensures longer packets are fragmented before they are encrypted;
 ! otherwise, the receiving router would have to do the reassembly.
 ip mtu 1400
 ip tcp adjust-mss 1360
 ip nhrp authentication CISCO456
 ip nhrp network-id 100
 ip nhrp holdtime 300
 ip pim sparse-dense-mode
 ! enabling DMVPN phase 3, allowing dynamic spoke to spoke
 ip nhrp shortcut
 ip nhrp redirect
 !
 ! Repeat the following lines for each HUB
 ! map hub tunnel ip with public accessible ip
 ip nhrp map 172.16.1.1 60.60.60.5
 ip nhrp map multicast 60.60.60.5
 ! next hop server config (hub)
 ip nhrp nhs 172.16.1.1

domingo, 27 de marzo de 2016

Opinion - Batman v Superman



 
"Batman v Superman: Dawn of Justice" fue anunciada en 2013 durante la Comic-Con de San Diego y desde ese día mucha especulación se generó en torno a la película y cada pequeño vistazo que teníamos sobre la misma solo aumentaba las ansias, teorías, y demás elementos que rodeaban una de las batallas más grandes entre superhéroes de todos los tiempos.


Al inicio cundo supe que sería una continuación de los eventos vistos en Man of Steel y no una película centrada en Batman mi interés por la misma no era extraordinario, era una película más... sentir que cambio al saber que Ben Affleck sería el actor en personificar a mi superhéroe favorito, entonces mi interés paso de "normal" a "casi nulo."


Mientras más se acercaba la fecha del lanzamiento y más contenido era revelado, como los primeros dos trailers (#1 & #2) en donde no apreciaba que la película tuviera una trama sólida y que sería una sola ensalada de historias y cameos, mi opinión respecto a la película se iba haciendo cada vez más clara... "va ser mala." 


Luego de mucho tiempo el trailer final vio la luz y eran las piezas del rompecabezas que me hacían falta para tener una idea de que iba a tratar la peli y divise un pequeño rayo de luz.


Llego el día de ver la peli y esto fue lo que sucedido: durante los primero minutos de la película relatan la gran pérdida de Bruce Wayne e intentan de cierta forma resumir sus orígenes, lo cual al ser una película centrada en Superman comprendo que tal relato sea breve, pero como todo buen fanático de Batman no pude dejar de notar todos los errores y fallas de mismo... elementos tan básicos, pero importante en el bati-universo como el callejón, la forma en la que mueren los padres de Bruce, el orden de los sucesos. -Todo mal.- 


La primera mitad de la película es relatada una forma lenta y aburrida, si bien me agrado como justificaron la razón de porque Batman no confía en Superman, no se desarrolla de la misma forma la justificación del porque a Superman no le agrada Batman y los escritores se lavan las manos con un simple chantaje. -Absurdo.- 


Otro falla de proporciones abismales en esta película es el excesivo uso de armas por parte de Batman y peor aún, toda las muertes a sangre fría que se le ve ejecutar. -Un total disparate.- 


Las cosas se ponen entretenidas cuando Bruce se pone la armadura, dejan atrás las conversaciones superfluas y por fin vemos lo que debió haber sido la atracción principal de la película "Batman v Superman." Si quitamos todas las armas de fuego que utilizo Batman, la batalla es bastante aceptable pues en ningún momento hay un vencedor claro y si bien la batalla no acabaría como vimos en "The Dark Knight Returns (1986)" de Frank Miller el que todo termina con una simple palabra... "Martha"... es lo más estúpido que pudieron hacer. -Si una palabra iba a resolver el conflicto, podrían haber dicho "lo siento" desde un buen inicio y problema resuelto.-


Cualquier persona con una pizca de conocimiento acerca del universo de DC desde el segundo trailer ya sabía que el clímax de la película sería derrotar a Doomsday y no la batalla entre Batman y Superman. -Grave error.- Desde que aparece Doomsday la película se convierte en una secuencia de explosiones y destrucción sin sentido y luego de mucho rato y con mis oídos zumbando, todo acaba con la muerte de Superman, tal y como se vio en "The Death of Superman (1992)." -Al menos me gusto la forma heroica en la que muerte Clark.- 


Luego de 151 minutos de película, salí del cine con un sentimiento de frustración, tristeza, resentimiento hacia un película que lo único que hizo bien fue mezclar un montón de elementos de muchos héroes/cómics y presentarlos de la forma más caótica y sin sentido posible.


¿Notaron que no mencione nada acerca de Wonder Woman o los demás integrantes de la JL? Así como no eran necesarios en mi post, no lo eran en la película, pero lamentablemente estuvieron presentes.

jueves, 18 de febrero de 2016

[Cisco IOS] Packet capture on cisco IOS

Pretty much everyone familiar with a cisco ASA know how useful and handy the capture command can be! Have you ever wonder how to do something similar on routers? Well, a embedded packet capture feature was introduced staring at v12.4(20)T for IOS and 15.2(4)S for IOS-XE.


It requires additional steps than his firewall cousin, but the results are pretty much the same. I will not cover the details since you can found a lot of documentation on the web, but pretty much this is wht you need to do:

conf t
!
access-list 177 permit ip 10.20.15.0 0.0.0.255 host 10.60.18.21
access-list 177 permit ip 10.30.16.0 0.0.0.255 host 10.60.18.21
access-list 177 permit ip 10.40.17.0 0.0.0.255 host 192.168.240.100
access-list 177 permit ip 10.50.18.0 0.0.0.255 host 192.168.240.100
end
!
monitor capture buffer holdpackets
monitor capture buffer holdpackets filter access-list 177
monitor capture point ip cef CUSTOMTRACE gigabitEthernet 0/1 both
monitor capture point associate CUSTOMTRACE holdpackets
!
monitor capture point start CUSTOMTRACE
!
! diplay the information capture
show monitor capture buffer holdpackets parameters
show monitor capture buffer holdpackets dump
!
monitor capture point stop CUSTOMTRACE
monitor capture buffer holdpackets clear

In my opinion, this captures aren't that easy to read, this is an example of the output of the capture:



For simplicity I always transfer the capture to a tftp server so I can read it using Wireshark.

monitor capture buffer holdpackets export tftp://10.10.180.55/CustomCapture.pcap

I hope you can find this useful.

[Cisco ASA] Determine unused object-groups

There is not one answer when it comes to network management, and the things gets more difficult when it comes to cleaning tasks.

Fate threw me a few ASA that for better or worse were managed by tooooo many hands before me, and like a really good friend told me once "OCD in the networking world is usually a good thing" and the OCD monster living inside me forced me to start the titanic task of cleaning and standardize the configuration of this firewalls.

At some point I needed to deal with Object-Groups and with the help of a my friend Julio Guevara (@juliogbberry || @MAXxATTAXx) we came up with the idea of count how many time the object-groups is being used, not only to determine those that aren't used, but also get rid of those that are not necessarily needed (used five times or less).

Thanks to a little python script we can determine how many times the objects are being used, to accomplish that we need two files, one with all the names of the objects (List_ASA1), and the lines you want to compare with, for simplicity I narrow it for access control lists (ACL_ASA1).

Is quite simple:
  1. Place the pair of file to compare on the same folder.
  2. The files must be named List_abc & ACL_abc, where abc can be anything.
  3. Open the Python console and once you have the script ready issue the following commands. Remember to change the location where you have your files.
    • firewall = FirewallClean()
    • firewall.workFolder("C:\\firewall") 




If everything works, you should have a file called Results_abc (Results_ASA1) and you can determine what is being used and not.

The script and all the example files can be found here: Download Script.

I hope that many of you can found this helpful.

Regards. 

This is an experimental tool. Backup your config before making any changes suggested by this tool.

domingo, 4 de octubre de 2015

#moocHackingMU - Unidad 2, Tarea 1


La tarea número uno de la segunda unidad consiste en analizar unas capturas de tráfico utilizando Wireshark una herramienta muy potente para el análisis de trafico y además muy popular, por lo que es bastante sencillo encontrar documentación y tutoriales de como utilizarla.

Esta tarea consiste en analizar tres capturas en las cuales fueron utilizadas diferentes protocolos para poder ver las diferencias respecto a seguridad entre unos protocolos y otros.

- Respuestas al final -

Primera parte: analizando un protocolo inseguro - Telnet
Archivo de captura utilizado: Telnet.pcap


¿Qué usuario y contraseña se ha utilizado para acceder al servidor de Telnet?
¿Qué sistema operativo corre en la máquina?
¿Qué comandos se ejecutan en esta sesión?


Segunda parte: analizando un protocolo híbrido - SSL + certificado de seguridad. (ciertos datos de la conexcion van en texto plano, mientras que otros son cifrados)
Archivo de captura utilizado: SSL.pcap


¿Puedes identificar en qué paquete de la trama el servidor envía el certificado?
¿El certificado va en claro o está cifrado? ¿Puedes ver, por ejemplo, qué autoridad ha emitido el certificado?
¿Qué asegura el certificado, la identidad del servidor o del cliente?


Tercera parte: analizando un protocolo seguro - SSH
Archivo de captura utilizado: SSH.pcap

¿Puedes ver a partir de qué paquete comienza el tráfico cifrado?
¿Qué protocolos viajan cifrados, todos (IP, TCP...) o alguno en particular?
¿Es posible ver alguna información de usuario como contraseñas de acceso?


*-*-*-*-*-*-*-*-*-*-

Archivo con las respuestas.

martes, 22 de septiembre de 2015

#moocHackingMU - Unidad 1, Tarea 1

https://mooc.mondragon.edu/courses/INFORMATICA/Seguridad/Hacking-etico/about

Como parte de las actividades detalladas en el curso en linea de hacking ético impartido por Mondragon Unibertsitatea, comparto los resultados de las actividades de la Unidad 1, Tarea 1



Como elementos introductorios se muestra el uso de tres simples herramientas que permiten obtener información básica de una web, para efectos de prueba utilizare como "objetivo" el sitio hackthissite.org


C:\>ping hackthissite.org

Pinging hackthissite.org [198.148.81.137] with 32 bytes of data:
Reply from 198.148.81.137: bytes=32 time=87ms TTL=51
Reply from 198.148.81.137: bytes=32 time=86ms TTL=51
Reply from 198.148.81.137: bytes=32 time=85ms TTL=51
Reply from 198.148.81.137: bytes=32 time=85ms TTL=51

Al igual que muchas otros sitios web, utilizan más de una IP publica.

C:\>nslookup hackthissite.org
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
Name:    hackthissite.org
Addresses:  2610:150:8007:0:198:148:81:139
          2610:150:8007:0:198:148:81:135
          2610:150:8007:0:198:148:81:138
          2610:150:8007:0:198:148:81:136
          2610:150:8007:0:198:148:81:137
          198.148.81.137
          198.148.81.135
          198.148.81.139
          198.148.81.138
          198.148.81.136

Una vez conociendo la(s) IP(s) publica(s) de nuestro objetivo, podemos obtener información adicional por medio del protocolo WhoIS, que para este caso me auxiliare de la herramienta web: http://ping.eu/ns-whois/
La información mas relevante esta resaltada. Al ser un sitio de prueba, la información es poco relevante, pero para un sitio real, la información es sin duda mas significativa. 
Domain Name    HACKTHISSITE.ORG
Domain ID    D99641092-LROR

Creation Date    2003-08-10T15:01:25Z
Updated Date    2015-09-15T12:56:12Z
Registry Expiry Date    2016-08-10T15:01:25Z
Sponsoring Registrar    eNom, Inc. (R39-LROR)
Sponsoring Registrar IANA ID    48
WHOIS Server:   
Referral URL:   
Domain Status    clientTransferProhibited -- http://www.icann.org/epp#clientTransferProhibited
Registrant ID    985ad17d6e34901c
Registrant Name    Whois Agent
Registrant Organization    Whois Privacy Protection Service, Inc.
Registrant Street    PO Box 639
Registrant Street    C/O hackthissite.org
Registrant City    Kirkland
Registrant State/Province    WA
Registrant Postal Code    98083
Registrant Country    US
Registrant Phone    +1.425274066

Registrant Phone Ext:   
Registrant Fax    +1.425974473
Registrant Fax Ext:   
Registrant Email    gqqwgkchj@whoisprivacyprotect.com
Admin ID    985ad17d6e34901c
Admin Name    Whois Agent
Admin Organization    Whois Privacy Protection Service, Inc.
Admin Street    PO Box 639
Admin Street    C/O hackthissite.org
Admin City    Kirkland
Admin State/Province    WA
Admin Postal Code    98083
Admin Country    US
Admin Phone    1.425274066
Admin Phone Ext:   
Admin Fax    1.425974473
Admin Fax Ext:   
Admin Email    gqqwgkchj@whoisprivacyprotect.com
Tech ID    985ad17d6e34901c
Tech Name    Whois Agent
Tech Organization    Whois Privacy Protection Service, Inc.
Tech Street    PO Box 639
Tech Street    C/O hackthissite.org
Tech City    Kirkland
Tech State/Province    WA
Tech Postal Code    98083
Tech Country    US
Tech Phone    +1.425274066
Tech Phone Ext:   
Tech Fax    +1.425974473
Tech Fax Ext:   
Tech Email    gqqwgkchj@whoisprivacyprotect.com
Name Server    B.NS.BUDDYNS.COM
Name Server    C.NS.BUDDYNS.COM
Name Server    E.NS.BUDDYNS.COM
Name Server    D.NS.BUDDYNS.COM
Name Server    NS1.HACKTHISSITE.ORG
Name Server    NS2.HACKTHISSITE.ORG
Name Server    F.NS.BUDDYNS.COM
Name Server:   
Name Server:   
Name Server:   
Name Server:   
Name Server:   
Name Server:   
DNSSEC    Unsigned

Por último podemos obtener información de los puertos y sistema operativa de nuestro objetivo utilizando NMAP 


Starting Nmap 6.00 ( http://nmap.org ) at 2015-09-22 23:31 EEST
Initiating Ping Scan at 23:31
Scanning hackthissite.org (198.148.81.137) [4 ports]
Completed Ping Scan at 23:31, 0.15s elapsed (1 total hosts)
Initiating SYN Stealth Scan at 23:31
Scanning hackthissite.org (198.148.81.137) [100 ports]
Discovered open port 80/tcp on 198.148.81.137
Discovered open port 443/tcp on 198.148.81.137
Discovered open port 22/tcp on 198.148.81.137
Completed SYN Stealth Scan at 23:31, 2.35s elapsed (100 total ports)
Initiating OS detection (try #1) against hackthissite.org (198.148.81.137)
Retrying OS detection (try #2) against hackthissite.org (198.148.81.137)

[+] Nmap scan report for hackthissite.org (198.148.81.137)
Host is up (0.12s latency).
Other addresses for hackthissite.org (not scanned): 198.148.81.139 198.148.81.135 198.148.81.136 198.148.81.138
Not shown: 97 filtered ports

PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https

Aggressive OS guesses: FreeBSD 7.0-RELEASE (98%), FreeBSD 7.1-RELEASE - 9.0-CURRENT (98%), FreeBSD 8.0-RELEASE (98%), FreeBSD 8.1-RELEASE (98%), OpenBSD 4.0 (x86) (97%), OpenBSD 3.9 - 4.2 (96%), OpenBSD 4.1 (96%), OpenBSD 4.1 - 4.7 (96%), OpenBSD 4.4 (96%), OpenBSD 4.9 - 5.0 (96%)
No exact OS matches for host (test conditions non-ideal).
Uptime guess: 0.000 days (since Tue Sep 22 23:31:18 2015)
IP ID Sequence Generation: Busy server or unknown class

OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .

Nmap done: 1 IP address (1 host up) scanned in 10.97 seconds
           Raw packets sent: 290 (16.592KB) | Rcvd: 92 (5.950KB)

-------------------------------------------------------------
Mas información en redes sociales: 
#moocHackingMU
Página en Facebook

Grupo de Facebook