Following is a list of the most common Cisco device configuration commands that I am using when setting up a router or switch from scratch, such as hostname, username, logging, vty access, ntp, snmp, syslog. For a router I am also listing some basic layer 3 interface commands, while for a switch I am listing STP and VTP examples as well as the interface settings for access and trunk ports.
This is not a detailed best practice list which can be used completely without thinking about it, but a list with the most common configurations from which to pick out the once required for the current scenario. Kind of a template. Of course with IPv6 and legacy IP.
Continue reading Basic Cisco Configuration
Second post of this little series. While I was using my CCNP SWITCH lab for testing many different protocols, I “showed” and saved the output of those protocols as well. Refer to the lab overview of my last post in order to understand those outputs.
I basically saved them as a reference for myself in case I am interested in the information revealed by them. I won’t explain any details of the protocols nor the outputs here. Just many listings. Fly over them and reflect yourself whether you would understand anything. 😉 Here we go:
Continue reading CCNP SWITCH Lab show commands
While preparing for my CCNP SWITCH exam I built a laboratory with 4 switches, 3 routers and 2 workstations in order to test almost all layer 2/3 protocols that are related to network management traffic. And because “PCAP or it didn’t happen” I captured 22 of these protocols to further investigate them with Wireshark. Oh oh, I remember the good old times where I merely used unmanaged layer 2 switches. 😉
In this blogpost I am publishing the captured pcap file with all of these 22 protocols. I am further listing 46 CHALLENGES as an exercise for the reader. Feel free to download the pcap and to test your protocol skills with Wireshark! Use the comment section below for posting your answers.
Of course I am running my lab fully dual-stacked, i.e., with IPv6 and legacy IP. On some switches the SDM template must be changed to be IPv6 capable such as
sdm prefer dual-ipv4-and-ipv6 default .
Continue reading Wireshark Layer 2-3 pcap Analysis w/ Challenges (CCNP SWITCH)
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.
Continue reading Lastline SSH Key-Based Authentication for “monitoring” User
This is just a small post on how to enable SNMP on a Lastline Advanced Malware Protection appliance in order to query the basic host and network MIBs from an SNMP monitoring server. Note that this is not the preferred method of monitoring a Lastline device. The Product API (PAPI) should be used instead such as shown in the online docs. However, basic SNMP gives access to the CPU, memory, load average and the network interface statistics incl. the anonymous VPN tunnel interface.
Since all Lastline devices are basically a Ubuntu server, the basic setup for SNMP is quite similar to my tutorial for a generic Linux. The only step missing there is the allow statement for the Uncomplicated Firewall (ufw).
Continue reading Lastline SNMP Monitoring
I migrated an old Juniper SSG ScreenOS firewall to a Palo Alto Networks firewall. While almost everything worked great with the Palo (of course with much more functionalities) I came across one case in which a connection did NOT work due to a bug on the Palo side. I investigated this bug with the support team from Palo Alto Networks and it turned out that it “works as designed”. Hm, I was not happy with this since I still don’t understand the design principle behind it.
However, it was a specific and not business critical case: One Palo Alto firewall with two ISP connections using a destination network address translation (DNAT, an old IPv4 problem) and policy based forwarding (PBF) with the same destination ports. Following are some more details:
Continue reading Palo Alto PBF Problem
This is a cool and easy to use (security) feature from Palo Alto Networks firewalls: The External Dynamic Lists which can be used with some (free) 3rd party IP lists to block malicious incoming IP connections. In my case I am using two free IP lists to deny any connection from these sources coming into my network/DMZ. I am showing the configuration of such lists on the Palo Alto as well as some stats about it.
Continue reading Palo Alto External Dynamic IP Lists
I wanted to configure a weekly email report on a Palo Alto Networks firewall. “Yes, no problem”, I thought. Well, it was absolutely not that easy. ;(
While the PAN firewalls have a great GUI and a good design at all they lack an easy-to-use email reporting function, especially when compared to the FortiGate firewalls which have a great local report feature. –> If you want some stats on a weekly basis you must configure it completely from scratch. Unluckily this is not that easy since you must pass several steps for that. Therefore, I drew an outline of the Palo Alto reporting stages to have an overview of them.
Continue reading Palo Alto Reporting
Yes I know, ScreenOS is “End of Everything” (EoE). However, for historical reasons I am still managing many Netscreen/ScreenOS firewalls for some customers. Similar to my troubleshooting CLI commands for Palo Alto and Fortinet I am listing the most common used commands for the ScreenOS devices as a quick reference / cheat sheet. These are only the commands that are needed for deep troubleshooting sessions that cannot be done solely on the GUI.
Continue reading CLI Commands for Troubleshooting Juniper ScreenOS Firewalls
To solve the chicken-or-egg problem for DNSSEC from the other side, let’s use an authoritative DNS server (BIND) for signing DNS zones. This tutorial describes how to generate the keys and configure the “Berkeley Internet Name Domain” (BIND) server in order to automatically sign zones. I am not explaining many details of DNSSEC at all, but only the configuration and verification steps for a concrete BIND server.
It is really easy to tell BIND to do the inline signing. With this option enabled, the admin can still configure the static database for his zone files without any relation to DNSSEC. Everything with signing and maintaining is fully done by BIND without any user interaction. Great.
Continue reading DNSSEC Signing w/ BIND
To overcome the chicken-or-egg problem for DNSSEC (“I don’t need a DNSSEC validating resolver if there are no signed zones”), let’s install the DNS server Unbound on a Raspberry Pi for home usage. Up then, domain names are DNSSEC validated. I am listing the commands to install Unbound on a Raspberry Pi as well as some further commands to test and troubleshoot it. Finally I am showing a few Wireshark screenshots from a sample iterative DNS capture. Here we go:
Continue reading DNSSEC Validation with Unbound on a Raspberry
This is a basic tutorial on how to install BIND, the Berkeley Internet Name Domain server, on a Ubuntu server in order to run it as an authoritative DNS server. It differs from other tutorials because I am using three servers (one as a hidden primary and two slaves as the public accessible ones), as well as some security such as denying recursive lookups and public zone transfers, as well as using TSIG for authenticating internal zone transfers. That is, this post is not an absolute beginner’s guide.
Continue reading Basic BIND Installation