Certification Goals Reviewed
CCNA Certified – 1st October 2011 Completed Dec 2012, (better late than never)
CCNP Switch – Rescheduled to from Dec 2011 to Feb 2012
CCNP Route and Tshoot – Mid 2012

Adios amigos…

Enable Netflow
Switch(config)#mls netflow interface
Switch(config)#mls flow ip interface-full
Switch(config)#mls nde sender version 5

Start Netflow On Vlan 10
Switch(config)# interface vlan 10
Switch(config-if)# ip flow ingress
Switch(config-if)# ip flow egress

Verify Netflow Entries
Switch# show mls netflow ip
Switch# show mls netflow ip count

Configure NDE (Netflow Data Export)
Switch(config)# ip flow-export source vlan 5
Switch(config)# ip flow-export version 5
Switch(config)# ip flow-export destination 192.168.1.10 65000

Verify NDE

Switch# show mls nde
Netflow Data Export enabled
Exporting flows to 192.168.1.10 (65000)
Exporting flows from 10.1.1.1 (54677)
Version: 5
Layer2 flow creation is disabled
Layer2 flow export is disabled
Include Filter not configured
Exclude Filter not configured
Total Netflow Data Export Packets are:
282455 packets, 0 no packets, 8191195 records
Total Netflow Data Export Send Errors:
IPWRITE_NO_FIB = 0
IPWRITE_ADJ_FAILED = 0
IPWRITE_PROCESS = 0
IPWRITE_ENQUEUE_FAILED = 0
IPWRITE_IPC_FAILED = 0
IPWRITE_OUTPUT_FAILED = 0
IPWRITE_MTU_FAILED = 0
IPWRITE_ENCAPFIX_FAILED = 0
IPWRITE_CARD_FAILED = 0
Netflow Aggregation Disabled

The first step is to stop apache, mysql and backup our current cacti environment.
my_account@CactiServer:~$ sudo service apache2 stop
my_account@CactiServer:~$ sudo service mysql stop
my_account@CactiServer:~$sudo cp -r /usr/share/cacti/site/ /home/my_account/cacti_bk

Next we download the plugin architecture using wget and extract the files.
my_account@CactiServer:~/downloadds$ wget ftp://10.10.10.10/cacti-plugin-0.8.7g-PA-v2.8.tar.gz
my_account@CactiServer:~/downloadds$ tar -zxvf cacti-plugin-0.8.7g-PA-v2.8.tar.gz

Now we need to install the cacti files using the patch method.
Jump to the plugin arch directory and copy the cacti-plugin-arch.diff file to /usr/share/cacti/site
my_account@CactiServer:~/downloadds$cd cacti-plugin-arch/
my_account@CactiServer:~/downloadds/cacti-plugin-arch$ sudo cp cacti-plugin-0.8.7g-PA-v2.8.diff /usr/share/cacti/site/

Run the patch files as a dry run to report back any errors.
my_account@CactiServer:~/downloadds/cacti-plugin-arch$ cd /usr/share/cacti/site/
my_account@CactiServer:/usr/share/cacti/site$ patch -p1 -N --dry-run < cacti-plugin-0.8.7g-PA-v2.8.diff

According to the Cacti Documentation
Your config.php file will almost always fail to be patched if you have either already configured your database or you are using an RPM/DEB install.
We shall continue proceeding with the patch even though we received Hunk #6 FAILED at 1323.
my_account@CactiServer:/usr/share/cacti/site$ sudo patch -p1 -N < cacti-plugin-0.8.7g-PA-v2.8.diff

Next we import the pa.sql file to the cacti database.
my_account@CactiServer:~$ cd downloadds/cacti-plugin-arch/
my_account@CactiServer:~/downloadds/cacti-plugin-arch$ /usr/bin/mysql --user=root --password= cacti < pa.sql
..
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

We received the above error message re: sqld sock as we need to start mysql before importing the pa.sql file
my_account@CactiServer:~/downloadds/cacti-plugin-arch$ sudo service mysql start
mysql start/running, process 13203
..
my_account@CactiServer:~/downloadds/cacti-plugin-arch$ /usr/bin/mysql --user=root --password= cacti < pa.sql

We now need to make the finishing touches to our configuration
Change /usr/share/cacti/site/include/global.php as follows:
/* Line 37 $database_username = "cactiuser"; */
$database_username = "cacti";
/* Line 38 $database_password = "cactiuser"; */
$database_password = "enter your pass given during installation(not cactiuser)";
/* Line 105 $url_path = "";
$url_path = "/cacti/";


Change /usr/share/cacti/site/include/config.php
Ensure the following for the url path
$url_path = "/cacti/";

Change /etc/cacti/debian.php to include the following line
$plugins = array();

Start apache and restart mysql
my_account@CactiServer:~/downloadds$sudo service apache2 start
my_account@CactiServer:~/downloadds$sudo service mysql restart

We can now proceed with installing the plugins (thold and weathermap)
We must first install the Settings Plugin as this is a prerequisite to the thold plugin.

Download and uncompress settings plugin
my_account@CactiServer:~/downloadds$ wget ftp://10.10.10.10/settings-v0.7-1.tgz
my_account@CactiServer:~/downloadds$ tar -zxvf settings-v0.7-1.tgz

Copy the settings plugin into your Cacti install’s Plugin directory
my_account@CactiServer:~/downloadds$ sudo cp -r settings /usr/share/cacti/site/plugins/

To Activate The Settings Plugin -
Go to Console/Utilities/User Management within your Cacti web interface – http://CactiServerIP/cacti/ and enable the ‘Plugin Management’ realm for your admin user, then go to Console/Configuration/Plugin Management and click the ‘Enable Plugin’ icon

Download and install the thold plugin
my_account@CactiServer:~/downloadds$ wget ftp://10.10.10.10/thold-latest.tgz
my_account@CactiServer:~/downloadds$ tar -zxvf thold-latest.tgz
my_account@CactiServer:~/downloadds$ sudo cp -r thold-0.41/ /usr/share/cacti/site/plugins

For some reason cacti doesn’t like the folder name thold-0.41 so we must rename it before we can enable the plugin
my_account@CactiServer:~/downloadds$ cd /usr/share/cacti/site/plugins
my_account@CactiServer:/usr/share/cacti/site/plugins$ sudo mv thold-0.41/ thold

Go to Console/Configuration/Plugin Management within your Cacti web interface – http://CactiServerIP/cacti/ and enable the thold plugin

Install the weathermap plugin
I had no utility to unzip zip files on my Ubuntu server so I used –r flag on wget to download a directory
my_account@CactiServer:~/downloadds/10.10.10.10$ wget -r ftp://10.10.10.10/weathermap
my_account@CactiServer:~/downloadds/10.10.10.10$ sudo cp -r weathermap/ /usr/share/cacti/site/plugins/

Go to Console/Configuration/Plugin Management within your Cacti web interface – http://CactiServerIP/cacti/ and enable the weathermap plugin

The final thing I noticed was that Cacti was reporting the incorrect time in Syslog.
To fix the issue we need to include date.timezone = “<your_location>” in the following php.ini files
/etc/php5/apache2/php.ini
/etc/php5/cli/php.ini

Update – Cacti Error Messages
I was receiving a couple of error messages in the Cacti logs after installing the plugins.

The first was regarding access to the directory /usr/share/cacti/site/plugins/weathermap/output. To resolve the problem I needed to change the group owner of the directory from root to www-data, then grant write access to the www-data group.
myAccount@CactiServer:/usr/share/cacti/site/plugins/weathermap$ sudo chgrp www-data output/
myAccount@CactiServer:/usr/share/cacti/site/plugins/weathermap$ sudo chmod 775 output/
myAccount@CactiServer:/usr/share/cacti/site/plugins/weathermap$ls -al
..
drwxrwxr-x 2 root www-data 4096 2011-10-03 10:39 output

The second was that I needed to install the PHP GD function. To install php-gd use the following command.
sudo apt-get install php5-gd

• Dynagen and Dynamips Tutorial
• Installing GNS3 on Windows
• Installing Dynamips and Dynagen on Linux

Something that I found particularly helpful when using Dynamips / Dynagen was the ability to create a virtual pc from which you can send ping and traceroute packets. Virtual PC Simulator is a program that allows you to accomplish this whilst minimising the memory and CPU cycles required from the host operating system. For further information on setting up Virtual PC Simulator please refer to the following doco – Virtual PC Simulator

The show clock command was issued to verify that the switch is displaying the correct time. Yep, everything ok here.
Switch#show clock
14:46:56.898 ACST Mon Sep 5 2011

Next step is to confirm that NTP is working and we are associated with our NTP servers. Again everything seems good.
Switch#show run | in ntp|clock
.....
ntp server 192.168.10.10
ntp server 192.168.20.10
clock timezone ACST 9 30

Switch#show ntp status
Clock is synchronized, stratum 2, reference is 192.168.20.10
nominal freq is 119.2092 Hz, actual freq is 119.2086 Hz, precision is 2**18
reference time is D20EDA3E.6E1CD364 (14:48:54.430 ACST Mon Sep 5 2011)
clock offset is 0.1531 msec, root delay is 0.92 msec
root dispersion is 1.60 msec, peer dispersion is 1.05 msec

Ok time to check the running config again. Aha, there is the issue. We have not specified the timezone component for debugging and logging output.
Switch# show run | in timezone
service timestamps debug datetime msec
service timestamps log datetime msec

So in our running config we need to specify our debug and log output to use our local timezone.
Time to update the config.
Switch(config)#service timestamps debug datetime msec localtime show-timezone
Switch(config)#service timestamps log datetime msec localtime show-timezone
Switch(config)#exit

Now when we review our logs they will display the correct time.
Switch#show logg
......
Sep 5 14:47:22.590 ACST: %SYS-5-CONFIG_I: Configured from console by xxxx on vty0 (10.0.0.10)

Break Cisco Passwords
http://www.ifm.net.nz/cookbooks/passwordcracker.html

Etherchannel
Understanding EtherChannel Load Balancing and Redundancy on Catalyst Switches

UDP

• Connectionless
• Best effort delivery
• Unreliable – here is the data

UDP is a very simple protocol that is not reliable, nor does it provide data intgretiy or guarantee transmission of data. UDP assumes that error checking and correction will be provided by the upper layers in the OSI model (Application Layer), thereby avoiding processing overhead at the network layer. UDP is especially useful in time sensitive applications such as VOIP, where dropping packets is preferable to waiting for delayed packets.

TCP

• Connection orientated – establishes a session using the 3-way handshake
• Reliable – uses acknowlegements and will continue to retransmit until an ACK is received
• Maintains connections – utilises sequence numbers

Simple TCP Transmission between a client and a server – 3-way handshake
The client inititiates the session by sending a SYN packet to synchronise the conversation.
The server receives the SYN packet and responds with a SYN-ACK. This response states that the server synchornises with the client and they acknowledge the packet.
The client now sends an ACK stating they received the SYN-ACK and the connection is now established.

After the 3-way handshake
After the session is established via the 3-way handshake, the client and server can begin to send data. Sequence numbers are used to identify each segment of data as it is transferred between the two devices and are used to identify the order of segments. This allows the data to be reconstructed in order, regardless of any fragmentation, disordering or packet loss that may occur during transmission.

In the following example the client sends the first segment with sequence number 7. Once the server receives the segment, it sends its data back to the client with its own sequence number (in this case 14) and it also responds with acknowledgement 8 which is the next expected sequence number from the client. This process continues throughout the entire session.

In the event that one of the sessions is lost between the client and the server and either device does not receive the expected Sequence Number within a pre-determined period of time, the sender will retransmit the data.

TCP Windows
TCP Windowing allows the amount of data sent between the two devices to increase based on how reliable the link is as the window size continually increases until a problem arises. TCP also utilises “Sliding Windows” which allows the session window size to be continually adjusted.

Port Numbers
When a TCP or UDP session is generated port numbers are used to distinguish between different applications. Port numbers can range from 0 to 65535 and the Internet Assigned Numbers Authority (IANA) are responsible for maintaining the list of common port numbers 0 – 1023.

Common TCP Ports
21 – FTP
22 – SSH
23 – TELNET
25 – SMTP
53 – DNS
80 – HTTP
110 – POP3
443 – HTTPS

Common UDP Ports
53 – DNS
69 – TFTP

IP addressess can be broken down into classes. The following table defines the classes and subnet masks associated with each class.

Within Class A, Class B and Class C, IP ranges there are specific addresses that are reserved for private use.

I really like this solution because it is

• Simple
• Allows me to open and close the port as required
• Allows me to connect from anywhere
• Should cause most linear port scans (ascending or descending) to leave port 22 closed upon completion

Step 1 – Setup iptables to allow established connections
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Step 2 – Allow SSH access once port is knocked on
sudo iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -m recent --rcheck --name SSH -j ACCEPT

Step 3 – Create the entry port TCP 1600. Notice all 3 ports drop packets and do not provide any sort of acknowlegment.
sudo iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 1599 -m recent --name SSH --remove -j DROP
sudo iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 1600 -m recent --name SSH --set -j DROP
sudo iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 1601 -m recent --name SSH --remove -j DROP

Step 4 – Deny all other traffic
sudo iptables -A INPUT -j DROP

Step 5 – Save iptables rules to a file (or you will lose your rules on reboot)
sudo sh -c "iptables-save > /etc/iptables.rules"

Step 6 – Modify the /etc/network/interfaces configuration file to apply the rules automatically on restart by adding in the highlighted line.
auto eth0
iface eth0 inet static
address 192.168.1.253
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.254
pre-up iptables-restore < /etc/iptables.rules

The test – try to connect to SSH server
user@remoteClient:~$ ssh sshuser@192.168.1.253
.... Request times out

Enable SSH by knocking on port 1600. Notice there is no acknowledgement
user@remoteClient:~$ telnet 192.168.1.253 1600
Trying 192.168.1.253...

Verify SSH connectivity
user@remoteClient:~$ ssh sshaccount@192.168.1.253
sshaccount@192.168.1.253's password:
sshaccount@192.168.1.253:~$

Now once we have finished with SSH sessions, we can close the SSH port with the following
user@remoteClient:~$ telnet 192.168.1.253 1601

Verify SSH port is closed
user@remoteClient:~$ ssh sshaccount@192.168.1.253
.... Request times out

Create read only SNMP group, group password and restrict access to the src add 192.168.1.104
Router(config)#snmp-server community PASSWORD view servergroup RO 16
Router(config)#ip access-list standard 16
Router(config-std-nacl)#permit 192.168.1.104
Router(config-std-nacl)#deny any log


We can further restrict what OIDs the server group can walk with the following commands
Router(config)#snmp-server view servergroup ifInOctets.1 included
Router(config)#snmp-server view servergroup ifOutOctets.1 included
Router(config)#snmp-server view servergroup ifOperStatus.1 included
Router(config)#snmp-server view servergroup ifAlias.1 included

Now when the servergroup run an SNMPwalk on the device they get responses to the above OIDs only.
user@ubuntuDesktop:~$ snmpwalk -v 2c -u servergroup -c PASSWORD 192.168.1.252
IF-MIB::ifOperStatus.1 = INTEGER: up(1)
IF-MIB::ifInOctets.1 = Counter32: 12353827
IF-MIB::ifOutOctets.1 = Counter32: 12289619
IF-MIB::ifAlias.1 = STRING: : HTTP Server
IF-MIB::ifAlias.1 = No more variables left in this MIB View (It is past the end of the MIB tree)

You can also restrict access using the exclude command. The following command allows the OID IfOperStatus on all interfaces except ifOperStatus.2 and ifOperStatus.3 (FastEthernet0/1 and Serial1/0)
Router(config)#snmp-server view servergroup ifOperStatus included
Router(config)#snmp-server view servergroup ifOperStatus.2 excluded
Router(config)#snmp-server view servergroup ifOperStatus.3 excluded

SNMPwalk results
user@ubuntuDesktop:~$ snmpwalk -v 2c -u servergroup -c PASSWORD 192.168.1.252
IF-MIB::ifOperStatus.1 = INTEGER: up(1)
IF-MIB::ifOperStatus.4 = INTEGER: down(2)
IF-MIB::ifOperStatus.5 = INTEGER: down(2)
IF-MIB::ifOperStatus.6 = INTEGER: down(2)
IF-MIB::ifOperStatus.7 = INTEGER: down(2)
IF-MIB::ifOperStatus.8 = INTEGER: down(2)
IF-MIB::ifOperStatus.9 = INTEGER: down(2)
IF-MIB::ifOperStatus.10 = INTEGER: down(2)
IF-MIB::ifOperStatus.12 = INTEGER: up(1)
IF-MIB::ifInOctets.1 = Counter32: 12403623
IF-MIB::ifOutOctets.1 = Counter32: 12345497
IF-MIB::ifAlias.1 = STRING: : HTTP Server
IF-MIB::ifAlias.1 = No more variables left in this MIB View (It is past the end of the MIB tree)

Next time we look at SNMP it will be securing SNMP using version 3.