During the last few weeks I published a couple of blogposts concerning routing protocols such as BGP, OSPFv3, and EIGRP. (Use the “Cisco Router” tag on my blog to list all of them.) They are all part of my current Cisco lab that I am using for my CCNP TSHOOT exam preparation. While I depicted only the details of the routing protocols in those blogposts, I am showing my overall lab with all of its Cisco IOS configs here. Just to have the complete picture. There are a couple of not-yet-blogged configs such as VRRP, GLBP, NTP authentication, embedded event manager (EEM), or route-maps and distribute/prefix lists though.
And again: Here comes a pcapng capture taken for the dynamic routing protocol EIGRP. If you want to dig into EIGRP messages, download the trace file and browse around it with Wireshark. Since I used both Internet Protocols (IPv6 and legacy IP), MD5 authentication, route redistribution, etc., you can find many different messages in it.
Yet another routing protocol I played with in my lab. ;) This time: EIGRP, Enhanced Interior Gateway Routing Protocol, the
proprietary distance-vector routing protocol developed by Cisco, which is now public available (RFC 7868). However, no third-party products in here but only Cisco routers. I am using named EIGRP for both Internet Protocols, IPv6 and legacy IP, along with MD5 authentication and redistribution from OSPF.
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.