Slow SSH connections

Recently I noticed that my ssh connections would stop for a few seconds before prompting for a password.  It turned out that the SSH command was checking the DNS servers for the Server host key. This would consume some time while the SSH daemon would try get the key from the DNS servers.

12:35PM zzz:~# ssh -v master@myswitch
OpenSSH_6.6.1p1, OpenSSL 1.0.1j-freebsd 15 Oct 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to myswitch [10.202.13.230] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: identity file /home/user/ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420
debug1: Remote protocol version 1.99, remote software version Comware-5.20
debug1: no match: Comware-5.20
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: RSA 41:3b:42:fd:ea:38:c8:27:f2:d4:7a:17:18:16:14:13
DNS lookup error: general failure  --> SSH stall here and does DNS requests (see tcpdump below)
debug1: Host 'myswitch' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:473
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent

 

The tcpdump shows that the daemon is doing SSHFP lookups but not getting any responses.

12:38:07.892258 IP zzz.xx.com.55994 > mydns.com.domain: 3790+ [1au] SSHFP? myswitch. (41)
12:38:12.910363 IP zzz.xx.com.33318 > vmydns.com.domain: 3790+ [1au] SSHFP? myswitch. (41)
12:38:17.926115 IP zzz.xx.com.25719 > vmydns.com.domain: 3790+ [1au] SSHFP? myswitch. (41)
12:38:22.965491 IP zzz.xx.com.29942 > mydns.domain: 3790+ [1au] SSHFP? myswitch. (41)

This can be easily turned off by editing /etc/ssh/ssh_config and setting “VerifyHostKeyDNS no”.  After setting this option, SSH skips the DNS lookups and goes straight to the known_hosts file.

 

debug1: Server host key: RSA 41:3b:42:fd:ea:38:c8:27:f2:d4:7a:17:18:16:14:13
debug1: Host 'myswitch' is known and matches the RSA host key.

Error mounting Samba Shares in FreeBSD

Over a number of years I’ve had an issue “reliably” mounting some samba shares from my Windows 7 machine. The FreeBSD machine and Windows machine are on the same LAN Subnet and have no firewalls between them. Generally I’ve also disabled the firewall on the win7 machine but still I cannot mount the samba shares (where as they were working previously).

The error given by the mount command does not help with troubleshooting.

root@zzz:~ # mount /data3
mount_smbfs: unable to open connection: syserr = Connection refused
root@zzz:~ # mount /data3
mount_smbfs: unable to open connection: syserr = Connection reset by peer

The options in the nsmb.conf file are nicely described in this man page. The default connectivity (port445 option) is normal which means it will attempt to connect via port 445. If that is unsuccessful, try to connect via NetBIOS over TCP/IP (ie TCP port 139).

In my case a wireshark shows that the connection to port 139 was being immediately dropped.

10:12:50.195293 IP 10.202.70.220.47946 > 10.202.70.162.139: Flags [S], seq 3682484936, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 4148422 ecr 0], length 0
10:12:50.195393 IP 10.202.70.162.139 > 10.202.70.220.47946: Flags [R.], seq 0, ack 3682484937, win 0, length 0

On the Windows machine I used the ifconfig command to check if NetBIOS over TCP/IP was enabled.

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Intel(R) 82579LM Gigabit Network Connection
   Physical Address. . . . . . . . . : A0-B3-CC-FC-34-A5
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::95e:16e8:af2f:2493%10(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.202.70.162(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.202.70.151
   DHCPv6 IAID . . . . . . . . . . . : 245412812
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-19-41-B0-3E-A0-B3-CC-FC-34-A5
   DNS Servers . . . . . . . . . . . : 10.48.2.160
                                       10.48.2.162
   NetBIOS over Tcpip. . . . . . . . : Enabled

However this isn’t enough. Microsoft, for some unknown reason, only allows netbios to bind to one ip address on my windows interface. So if you have two ip address: 10.202.70.162 and 10.10.10.5 then netbios will bind to the lowest ip address (ie 10.10.10.5). The best way to check this is to use netstat:

C:\Users\myuser>netstat -an | find /i "139"
  TCP    10.10.10.5:139         0.0.0.0:0              LISTENING
  TCP    169.254.178.132:139    0.0.0.0:0              LISTENING
  TCP    192.168.56.1:139       0.0.0.0:0              LISTENING
  TCP    192.168.195.1:139      0.0.0.0:0              LISTENING

This can be easily fixed by removing the secondary ip address and rebooting the machine. NetBios will now bind to the correct address:

C:\Users\agarg>netstat -an | find /i "139"
  TCP    10.202.70.162:139      0.0.0.0:0              LISTENING
  TCP    169.254.178.132:139    0.0.0.0:0              LISTENING
  TCP    192.168.56.1:139       0.0.0.0:0              LISTENING
  TCP    192.168.195.1:139      0.0.0.0:0              LISTENING

The netbios bind address changes only if the following events happen:

1) On reboot, netbios will bind to the lowest ip address

2) On restarting the netbios process it will bind to the lowest ip address (Control Panel->Network Connections -> Lan Adapter -> IPv4 -> Properties -> Advanced -> WINS -> Disable/Enable netbios)

3) Removing the lowest numbered ip address, netbios will bind to the next lowest ip address

If you just add a “lower” ip address to an exiting interface then it will not change till the next event defined above. This is where the problem is! I would add a temp address to test a config and then 4-6 weeks later reboot the windows machine (to apply patches or install software) and suddenly the SMB mounts are no long working because netbios isn’t listening on the primary address anymore.

 

 

 

 

SSH Key Exchange fails to Cisco devices

I upgraded my VM to use FreeBSD 10.1 and included with this was an upgrade to OpenSSH (OpenSSH_6.6.1p1). When you ssh to some Cisco devices using this version you cannot connect.

Debugging on the client side does not show much other than the connection is dropped.

OpenSSH_6.6.1p1, OpenSSL 1.0.1j-freebsd 15 Oct 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: ciphers ok: [aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc]
debug3: macs ok: [hmac-md5,hmac-sha1,hmac-ripemd160]
debug2: ssh_connect: needpriv 0
debug1: Connecting to rtr01.lpr [10.202.70.151] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/xx/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/xx/.ssh/id_rsa type 1
debug1: identity file /home/xx/.ssh/id_rsa-cert type -1
debug1: identity file /home/xx/.ssh/id_dsa type -1
debug1: identity file /home/xx/.ssh/id_dsa-cert type -1
debug1: identity file /home/xx/.ssh/id_ecdsa type -1
debug1: identity file /home/xx/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/xx/.ssh/id_ed25519 type -1
debug1: identity file /home/xx/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420
debug1: Remote protocol version 2.0, remote software version Cisco-1.25
debug1: no match: Cisco-1.25
debug2: fd 3 setting O_NONBLOCK
debug3: ssh_load_hostkeys: loading entries for host "rtr01.lpr" from file "/home/xx/.ssh/known_hosts"
debug3: ssh_load_hostkeys: found key type RSA in file /home/xx/.ssh/known_hosts:11
debug3: ssh_load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss
debug2: kex_parse_kexinit: aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
debug2: kex_parse_kexinit: aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: setup hmac-md5
debug1: kex: server->client aes256-cbc hmac-md5 none
debug2: mac_setup: setup hmac-md5
debug1: kex: client->server aes256-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<8192<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
Connection closed by 10.202.70.151

Debugging on the server site (ie on the cisco device) shows

Nov 24 05:46:22.944: SSH1: starting SSH control process
Nov 24 05:46:22.948: SSH1: sent protocol version id SSH-2.0-Cisco-1.25
Nov 24 05:46:22.952: SSH1: protocol version id is - SSH-2.0-OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420
Nov 24 05:46:22.960: SSH2 1: SSH2_MSG_KEXINIT sent
Nov 24 05:46:22.960: SSH2 1: SSH2_MSG_KEXINIT received
Nov 24 05:46:22.968: SSH2:kex: client->server enc:aes256-cbc mac:hmac-md5
Nov 24 05:46:22.972: SSH2:kex: server->client enc:aes256-cbc mac:hmac-md5
Nov 24 05:46:22.980: SSH2 1: SSH2_MSG_KEX_DH_GEX_REQUEST received
Nov 24 05:46:22.980: SSH2 1: Range sent by client is - 1024 < 8192 < 8192
Nov 24 05:46:22.980: SSH2 1:  Client DH key range mismatch with max built-in DH key on server!
Nov 24 05:46:23.084: SSH1: Session disconnected - error 0x00

The Cisco device supports a maximum key length of 2048 where as the client is requesting a keylength of 8192. A debug from an older client shows that is request a smaller key:

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 145/256
debug2: bits set: 505/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

This change seems to have been introduced in OpenSSH v6.6 and I can’t find a way to turn this off. Cisco has registered a bug CSCuo76464 for this.

The simplest workaround seems to be to reorganize the KexAlgorithms in /etc/ssh/ssh_config by adding the following line:

KexAlgorithms diffie-hellman-group14-sha1,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

 

 

 

 

 

 

 

 

Installing FreeBSD 10.1 in VMWare

Install FreeBSD 10.1

Create a new VM machine with

  • OS Type Other, then select FreeBSD 64bit
  • 1 CPU
  • 512M DRAM
  • 50 G Disk with can be allocate as we go along

Download the a FreeBSD 10.1 AMD64 Boot ISO and boot off this image. Then select the following

  • Standard Install (others don’t fully install unless you pick all the options manually)
  • All distributions
  • Yes to the mouse
  • No packages (will build them from the ports)
  • Use the full disk for FreeBSD
  • Accept all the default mount sizes and options
  • Set the root password
  • Add your first user and invite them to the “wheel” group

Let the VM complete install and reboot. Now do the initial tasks

  • Update the ports & source tree using the process described here, make sure to use the correct RELENG tag
  • Add a cronjob to the root user to get this happening weekly. The crontab below does the following
    • Update the time
    • Update the ports tree
    • Update the docs
    • Update src tree
    • Update the locate database (which the locate command uses)
# Update time at 1am
0 1 * * * /usr/sbin/ntpdate au.pool.ntp.org > /dev/null 2>&1

# Update ports tree at 2am
0 2 * * * portsnap fetch update > /dev/null 2>&1

# Update docs tree at 3am
0 3 * * * svn update /usr/doc > /dev/null 2>&1

# Update src tree at 4am
0 4 * * * svn update /usr/src > /dev/null 2>&1

# Update locate db at 5am
0 4 * * * /usr/libexec/locate.updatedb > /dev/null 2>&1
  • Build a specific kernel if you like as shown here
  • Update your ip addressing and resolve.conf as required
  • Update your fstab & SMB mounts

I then I like to install the following packages:

  • Install zsh (/usr/ports/shells/zsh)
  • Install vim without X11 support (/usr/ports/editors/vim-lite)
    • The editors/vim includes gvim, the gtk version of vim.  If you just want the command-line vim, install editors/vim-lite
  • Install net-snmp (/usr/ports/net-mgmt/net-snmp/)
  • Install nmap (/usr/ports/security/nmap/)
  • Install calc (/usr/ports/math/calc)
  • Install whatmask (/usr/ports/net-mgmt/whatmask)
  • Install expect (/usr/ports/lang/expect)
  • Install wget (/usr/ports/ftp/wget)
  • Install quagga (/usr/ports/net/quagga)
  • Install SOAP:Lite (/usr/ports/net/p5-SOAP-Lite)
  • Install Dumper (/usr/ports/devel/p5-Data-Dumper)
  • Install XML:Xpath (/usr/ports/textproc/p5-XML-XPath)
  • Install Expect for perl (/usr/ports/lang/p5-Expect)
  • Install Net::SNMP (/usr/ports/net-mgmt/p5-Net-SNMP)
  • Install Socket (/usr/ports/net/p5-Socket)
  • Move the users crontabs

Displaying SNMP OIDs in a MIB

The last time i tackled this issue I used the snmptranslate utility which is part of the net-snmp package.

While I was looking around the Internet I found this post which describes a better alternative to the snmptranslate utility. It uses the smidump tool in the libsmi package. So I proceeded to try it on a FreeBSD as follows:

1) Install libsmi (as root)

cd /usr/ports/net-mgmt/libsmi/
make install clean

2) Download the latest VMware mibs from here

3) Run the tool (for a simple MIB)

~/vmware/mib/vmw# /usr/local/bin/smidump -f identifiers BRIDGE-MIB.mib
# BRIDGE-MIB list of identifiers (generated by smidump 0.4.8)

BRIDGE-MIB BridgeId                           type
BRIDGE-MIB Timeout                            type
BRIDGE-MIB dot1dBridge                        node         1.3.6.1.2.1.17
BRIDGE-MIB dot1dNotifications                 node         1.3.6.1.2.1.17.0
BRIDGE-MIB newRoot                            notification 1.3.6.1.2.1.17.0.1
BRIDGE-MIB topologyChange                     notification 1.3.6.1.2.1.17.0.2
BRIDGE-MIB dot1dBase                          node         1.3.6.1.2.1.17.1
BRIDGE-MIB dot1dBaseBridgeAddress             scalar       1.3.6.1.2.1.17.1.1
BRIDGE-MIB dot1dBaseNumPorts                  scalar       1.3.6.1.2.1.17.1.2
BRIDGE-MIB dot1dBaseType                      scalar       1.3.6.1.2.1.17.1.3
BRIDGE-MIB dot1dBasePortTable                 table        1.3.6.1.2.1.17.1.4
BRIDGE-MIB dot1dBasePortEntry                 row          1.3.6.1.2.1.17.1.4.1
<SNIP>

4)  IF you run this on a VMware mib you may get the error below. This indicates that you will need to supply the additional mibs in the correct order

~/vmware/mib/vmw# /usr/local/bin/smidump -f identifiers VMWARE-SYSTEM-MIB.mib
VMWARE-SYSTEM-MIB.mib:15: failed to locate MIB module `VMWARE-ROOT-MIB'
VMWARE-SYSTEM-MIB.mib:46: unknown object identifier label `vmwSystem'
smidump: module `VMWARE-SYSTEM-MIB.mib' contains errors, expect flawed output
smidump: aborting due to severe parsing errors
smidump: use the -k option to force continuation
 1:06PM agarg@zzz:~/vmware/mib/vmw# /usr/local/bin/smidump -f identifiers VMWARE-SYSTEM-MIB.mib VMWARE-ROOT-MIB.mib
VMWARE-SYSTEM-MIB.mib:15: failed to locate MIB module `VMWARE-ROOT-MIB'
VMWARE-SYSTEM-MIB.mib:46: unknown object identifier label `vmwSystem'
smidump: module `VMWARE-SYSTEM-MIB.mib' contains errors, expect flawed output
smidump: aborting due to severe parsing errors
smidump: use the -k option to force continuation
 1:06PM agarg@zzz:~/vmware/mib/vmw# /usr/local/bin/smidump -f identifiers VMWARE-ROOT-MIB.mib VMWARE-SYSTEM-MIB.mib
# VMWARE-ROOT-MIB list of identifiers (generated by smidump 0.4.8)

VMWARE-ROOT-MIB   vmware                   node         1.3.6.1.4.1.6876
VMWARE-ROOT-MIB   vmwNotifications         node         1.3.6.1.4.1.6876.0
VMWARE-ROOT-MIB   vmwSystem                node         1.3.6.1.4.1.6876.1
VMWARE-ROOT-MIB   vmwVirtMachines          node         1.3.6.1.4.1.6876.2
VMWARE-ROOT-MIB   vmwResources             node         1.3.6.1.4.1.6876.3
VMWARE-ROOT-MIB   vmwProductSpecific       node         1.3.6.1.4.1.6876.4
VMWARE-ROOT-MIB   vmwLdap                  node         1.3.6.1.4.1.6876.40
VMWARE-ROOT-MIB   vmwTraps                 node         1.3.6.1.4.1.6876.50

Installing Nfsen 1.6.12 on Centos

As you might already know the last time I installed nfsen was in FreeBSD v9 and it used a special NSEL fork for nfdump. This version allowed us to capture the extra information generated by ASA v9 netflow records.

My initial build of nfsen in Feb 2012 has been in continuous use for over two years now. We collect data from 9 sources and only have two two profiles: the default live and one we called services. The services profile basically displays the traffic for each type of service (eg ssh, web, https, dns, vnc, DVR etc). We also have defined a number of alerts which send snmptraps to our network management systems.

image

Since the orignal install two years ago, the main version of nfdump as been rewritten to incorporate NSEL. This post describes how I installed my first prototype system with the latest version of nfdump (1.6.12) and nfsen (1.3.6p1). The only difference will be that I’m going to use CentOS release 6.5 (Final) as the base OS. As this is a prototype build, I’m being very brief with explaining the commands.

(I think the commands should be similar if you wanted to install this in a FreeBSD instance)

I copied the first 7 command from here.

1) Install a new Centos 6.5 System

2) Check iptables is off

iptables -t filter -L -v –n

3) Check SELinux is off

cat /etc/selinux/config
sestatus (show show disabled)
vi /etc/selinux/config
set SELINUX=disabled
reboot

4) Install Apache and other per-requisits
yum install -y httpd php wget gcc make rrdtool-devel rrdtool-perl perl-MailTools perl-Socket6 flex byacc
yum install libtool.x86_64

5) Start HTTPd
service httpd start

6) Enable HTTPd at boot
chkconfig httpd on

7)Get nfdump and nfsen
wget http://sourceforge.net/projects/nfdump/files/stable/nfdump-1.6.12/nfdump-1.6.12.tar.gz (latest version supports nsel)
wget http://sourceforge.net/projects/nfsen/files/stable/nfsen-1.3.6p1/nfsen-1.3.6p1.tar.gz/

8) Compile and install nfdump
tar -zxvf nfdump-1.6.12.tar.gz
./configure –enable-nfprofile –enable-nftrack –enable-sflow –enable-nsel
autoreconf
Make
Make install

9) Add a netflow user
adduser netflow
usermod -a -G apache netflow

10) Compile and install nfsen
tar -xvzf nfsen-1.3.6p1.tar.gz
cd nfsen-1.3.6p1/etc
cp nfsen-dist.conf nfsen.conf

(now make a /data/nfsen folder somwhere on the system, you need lots of space for this)

vi etc/nfsen.conf & change $WWWUSER to apache
vi etc/nfsen.conf & change $WWWGROUP to apache
vi etc/nfsec.conf & change $HTMLDIR    = “/var/www/nfsen/”; to /var/www/html/nfsen
vi etc/nfsec.conf & uncomment $EXTENSIONS = ‘all’; or add $EXTENSIONS = ‘nsel’;

cd ..
./install.pl etc/nfsen.conf

11) Configure ASA: -> https://supportforums.cisco.com/document/30471/netflow-asa

12)Add the data sources as described previously

/data/nfsen/bin/nfsen stop
vi /data/nfsen/etc/nfsen.conf
/data/nfsen/bin/nfsen reconfig
/data/nfsen/bin/nfsen start
chkconfig nfsen on (to make it autostart after reboot)

The web address should now be http:///nfsen/nfsen.php. If you have done everthing right then you can see the following:

image_001

  Once you have some data collected, pick a time slot and and select “List Flows” and hit process. You will then see the extended ASA information (Event / Extended Events)

image_002

One of the new features that the later version have introduced is that filers can now accept additional info other than standard tcpdump parameters. From the man page:

“The filter syntax is comparable to tcpdump  and  extended  for  netflow data.”

This mean you can have a filter that does the following:

“asa event deny and port 80”

image_003

Here is a sample from the nfdump man page:

NSEL/ASA specific filters:

NSEL/ASA Event
asa event
asa event [comp]
select NSEL/ASA event by name or number. If given as number it can be compared with a number

NSEL/ASA denied reason
asa event denied
Select a NSEL/ASA denied event by type

NSEL/ASA extended events
asa xevent [comp]
Select an extended NSELL ASA event by number, or optionally compared by a number.

X-late IP addresses and ports
[src|dst] xip
Select the translated IP address

[src|dst] xnet /
with as a valid translated IPv4 or IPv6 network and as maskbits.  The number of mask bits must
match  the  appropriate  address  familiy in IPv4 or IPv6. Networks may be abreviated such as 172.16/16 if
they are unambiguous.
[src|dst] xport
Select the translated port

NSEL/ASA ingress/egress
ingress [comp] number
Select/compare an ingress ACL

egress ACL [comp]
Select/compare an egress ACL

Installing Quagga on Freebsd

We needed to send some static route from my Freebsd host to a collegue on the next desk and it turned out that he didn’t know how to use BGP. So we decided that we would use this “overkill” method of sending the routes and in the process he could learn about BGP.

Below I’ve documented the steps I need to install and configure Quagga to send all my static routes from my Freebsd host.

1) Install Quagga

cd /usr/ports/net/quagga
make install

The install script outputs the following bits of useful information:

==========================================================
To enable quagga, add the following lines to rc.conf:

defaultrouter=”NO”
quagga_enable=”YES”

Also, you may wish to set the following options:”
quagga_daemons=”zebra bgpd etc…”
quagga_flags=”….”
quagga_extralibs_path=”… …”
router_enable=”NO”
watchquagga_enable=”YES”

zebrasrv      2600/tcp          # zebra service
zebra         2601/tcp          # zebra vty
ripd          2602/tcp          # RIPd vty
ripngd        2603/tcp          # RIPngd vty
ospfd         2604/tcp          # OSPFd vty
bgpd          2605/tcp          # BGPd vty
ospf6d        2606/tcp          # OSPF6d vty
ospfapi       2607/tcp          # ospfapi
isisd         2608/tcp          # ISISd vty

==========================================================

2) Setup Quagga to start when then host is powered on:

vi /etc/rc.conf
add
quagga_enable=”YES”
quagga_daemons=”zebra bgpd”

3) Do the basic configuration

vi /usr/local/etc/quagga/zebra.conf
add
hostname zzzRouter
password zzzpass
enable password zzzpass

vi /usr/local/etc/quagga/bgpd.conf
add
hostname zzzRouter
password zzzpass
enable password zzzpass

4) Start Quagga

/usr/local/etc/rc.d/quagga start

5)

You can access the zebra daemon as follows:

telnet localhost 2601 (and use passwords set above in zebra.conf)
or
telnet localhost zebra

This will present you with a standard Cisco IOS interface. The zebra daemon is used to set interface info and look at routing table. To configure the routing commands you will need to access the routing daemon, in this case BGP:

telnet localhost 2605 (and use passwords set above)
or
telnet localhost bgpd

Then to send all the configured static routes I did the following:

router bgp 65001
bgp router-id 10.202.70.220
redistribute kernel
neighbor 10.48.0.219 remote-as 65001
neighbor 10.48.0.219 route-map no_inbound in
!
route-map no_inbound deny 10
description Deny all inbound routes
match peer 10.48.0.219
!