Now we have SiLK, let’s get it set up..

Now we have SiLK, let’s get it set up..

So Installation of SiLK from the ground up on Centos 7 is only part of the story. You need to configure it to actually collect some data, and then to process it.

I could use the rwflowcap tool to do this, but actually it seems easier just to use the rwflowpack tool as the first stage. In future, I might look at an rwflowcap step first, but this gets me off the ground running, without needing to learn lots of new commands and tooling.

So I have a couple of devices that can export Netflow v9 records (as I need capability). I also have a Cisco switch which can pass Netflow v5. So we'll need to be able to capture these flow-types.

Configuring SiLK

This is all done in the silk.conf initialisation file which is found in the base directory of the system (in my case, this is the default, /usr/share/silk. I used the twoway-silk.conf file from that directory as a template. In this file you need to define the various sensors that are in use, and group them in a class (surprisingly, this is also called sensors. The rest of the file you can leave almost untouched. In fact there is a line that reads "# Editing above this line is sufficient for sensor definition." Beyond lie dragons, you'll need some time to plan your journey. Take food, ropes and a sword.

# silk.conf for the "twoway" site
# RCSIDENT("$SiLK: silk.conf 1234abcd5678 2017-08-05 21:16:30Z jsd $")

# For a description of the syntax of this file, see silk.conf(5).

# The syntactic format of this file
# version 2 supports sensor descriptions, but otherwise identical to 1
version 2

# NOTE: Once data has been collected for a sensor or a flowtype, the
# sensor or flowtype should never be removed or renumbered. SiLK Flow
# files store the sensor ID and flowtype ID as integers; removing or
# renumbering a sensor or flowtype breaks this mapping.

sensor 0 tarantula "core "
sensor 1 goldenorb "cisco switch"
sensor 2 trapdoor ''

class all
 sensors tarantula goldenorb trapdoor
end class

# Editing above this line is sufficient for sensor definition.

...

Getting SiLK to understand your address space

Now we need have the system recognising that we're throwing some data at it, we need to help it understand the IP addresses it receives. You need to use /usr/share/silk/addrtype-templ.txt as a template. I moved 192.168.0.0/16 from non-routable to internal (since I'm using RFC1918 blocks, add more as required for your network). This is only needed for addresses. Save as addresses.txt

Convert this to SiLK's internal format using rwpmapbuild --input address.txt --ouput address_types.pmap. Now move address_types.pmap to /usr/share/silk/address_types.pmap once done).

Determining the countries accessing your systems from the , requires some additional files. Consequently Adding a geolocation database to SiLK will help setup these for you.

Defining sensors

Files in the /etc/sysconfig directory finally configure the system. The first one is the file sensor.conf. This defines the sensor types that are received, as well as allowing aggregation of IP address ranges. I'll consider if I need to use IP address ranges for interface selection later, but I think it would be beneficial in larger deployments where you're dealing with hosts of devices with similar configurations.

I've created a single port to receive traffic on, but differentiated by the source-address, which allows me to use a single port across the network for my NetFlow traffic and also to treat a particular quirk on one of my devices. I haven't yet added in the configuration for the goldenorb switch yet.

probe nfv9-tarantula netflow-v9
  listen-on-port 2056
  accept-from-host 192.168.a.b
  protocol udp
end probe

probe nfv9-trapdoor netflow-v9
  listen-on-port 2056
  accept-from-host 192.168.c.d
  protocol udp
end probe

sensor tarantula
   netflow-v9-probes nfv9-tarantula
   internal-interface remainder
end sensor

sensor trapdoor
   netflow-v9-probes nfv9-trapdoor
   internal-interface 1
   external-interface 2
end sensor

Modifying the rwflowpack.conf file

Now we need to add in the final file, which is how the data is collected, manipulated and stored. Since this is a simple configuration we can quickly modify the rwflowpack.conf file, which is provided as a template, again in /etc/sysconfig. There's only a few elements I changed in this one, so I'll just highlight the differences.

ENABLED=yes
# Oddly, it's not enabled by default.
SENSOR_CONFIG=/etc/sysconfig/sensor.conf
# Pointing at the local sensor.conf file we just created

# ******************************************
# we're disabling the archive for a while to test.
# Remove # from below to enable default /var/lib/rwflowpack/archive
# ******************************************
#ARCHIVE_DIR=${statedirectory}/archive

Check  the configuration works with sh /etc/init.d/rwflowpack start. Typical errors are because you've not defined directories, but it's good enough to report that for you. For example I needed to mkdir /var/lib/rwflowpack (to create the state directory, then add below mkdir /var/lib/rwflowpack/log. If storing local files, you might want to add /var/lib/rwflowpack/archive and /var/lib/rwflowpack/errors directories.. Alternatively enable the CREATE_DIRECTORIES=yes option to have it create all the ones you need, and some more that you might not.

Checking the configuration works

Now we just need to see if there is something listening on UDP port 2056. So here the fishy command is netstat -tuna to check we see things correctly. Remember we're looking for a udp line with the address 0.0.0.0:2056  or :::2056. We could remove the -t (tcp) flag from the command for this. The -n reports in numbers not DNS or service names, which is easier when the chosen port is reported as something else.

Now to the firewall – add in the NetFlow output to the Netflow config. We use the IP address of our chosen device for SilK, and port 2056 as the export destination. If we can we set the export address to the IP address configured in the sensor.conf file. (If not we make sure the file contains the address which routes towards the collector.)

Almost forgot, we need to open the firewall to support receiving the packets. So we add the right ports to the trusted interface zone (we've already changed this from the default public zone).

sudo firewall-cmd --zone=trusted --permanent --add-port=2056/udp
systemctl restart firewalld.service

Now we for messages in /var/log/messages for information. We should see the system flushing the flow cache to files after 120 seconds, with a line that reads: 'nfv9-tarantula': forward 656, reverse 0, ignored 0, nf9: missing-pkts 134667

Starting SiLK on device boot

Now it is working, we need to automatically start the collector when the device starts up. The command chkconfig --add rwflowpack sorts that out for us.

A check of the files now being collected in the /data directory with the command rwcount gives information on packets records and bytes recorded in each time slot. Similarly rwaddrcount --print-ips will give source IP addresses of the flows seen in the data file. If you've got data then all is well.

Leave things running for a while so we have abase of information to work from and analyse.

John Dixon

John Dixon is the Principal Consultant of thirteen-ten nanometre networks Ltd, based in Wiltshire, United Kingdom. He has a wide range of experience, (including, but not limited to) operating, designing and optimizing systems and networks for customers from global to domestic in scale. He has worked with many international brands to implement both data centres and wide-area networks across a range of industries. He is currently supporting a major SD-WAN vendor on the implementation of an environment supporting a major global fast-food chain.

Comments are closed.