Here comes a small lab consisting of three Cisco routers in which I used OSPFv3 for IPv6 with IPsec authentication. I am listing the configuration commands and some show commands. Furthermore, I am publishing a pcapng file so that you can have a look at it with Wireshark by yourself.
I already had an OSPFv2 for IPv4 lab on my blog. However, I missed capturing a pcap file in order to publish it. So, here it is. Feel free to have a look at another small lab with three Cisco routers and OSPFv2. Just another pcapng file to practise some protocol and Wireshark skills.
For those who are interested in analyzing basic BGP messages: I have a trace file for you. ;) It consists of two session establishments as I cleared the complete BGP session on two involved routers for it. Refer to my previous blogpost for details about the lab, that is: MP-BGP with IPv6 and legacy IP, neighboring via both protocols as well, with and without password. The involved routers were 2x Cisco routers, one Palo Alto Networks firewall, and one Fortinet FortiGate firewall.
While playing around in my lab learning BGP I configured iBGP with Multiprotocol Extensions (exchanging routing information for IPv6 and legacy IP) between two Cisco routers, a Palo Alto Networks firewall, and a Fortinet FortiGate firewall. Following are all configuration steps from their GUI (Palo) as well as their CLIs (Cisco, Fortinet). It’s just a “basic” lab because I did not configure any possible parameter such as local preference or MED but left almost all to its defaults, except neighboring from loopbacks, password authentication and next-hop-self.
It is widely believed that public/private keys or certificates are “more secure” than passwords. E.g., an SSH login via key rather than using a password. Or a site-to-site VPN with certificate authentication rather than a pre-shared key (PSK). However, even certificates and private keys are not unlimited secure. They can be compromised, too, since the public-key cryptography only implies that private keys won’t be exposed if a brute-force attack is nearly impossible.
So, what’s the real security level of passwords compared to public keys/certificates?
If you are using a Lastline device (Manager, Engine, Sensor or Pinbox) you can reach the machine via SSH after you activated it via monitoring_user_password . However, per default this uses only a password for authentication. If you want to use the key-based authentication for this “monitoring” user account you can add the public key to the authorized_keys file for that user.
This is a small record on how to add a public key to the Lastline device. However, it is quite general since the Lastline appliance is built upon a standard Ubuntu server.
This is really cool. After DNSSEC is used to sign a complete zone, SSH connections can be authenticated via checking the SSH fingerprint against the SSHFP resource record on the DNS server. With this way, administrators will never get the well-known “The authenticity of host ‘xyz’ can’t be established.” message again. Here we go:
Short memo: This is the FTP proxy authentication format of “Check Point” for the FileZilla FTP Client. I needed it for my Cisco WSA (Web Security Appliance) laboratory in the case of an enabled proxy authentication.