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 IPv6 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 router" sensor 1 goldenorb "cisco switch" sensor 2 trapdoor 'firewall' 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 IPv4 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 Internet, 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 hosting 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.