Skip to content ↓ | Skip to navigation ↓

As a security engineer and security operations center manager you are always forced to look for new things to make sure your customers are satisfied. In this case we were using Tripwire Log Center to store firewall logs in the firewall database and all the other normal log management and SIEM capabilities that it does great.

In Europe, and especially Sweden where I live our customers are very interested in flows of various types. Obviously Netflow is the one most customers use and we were very eager to try to get it to work with TLC and through some customization we integrated the great open source tool flowd.

The first initial thought was to use some sort of third party device or software to convert Netflow to syslog and then send it to TLC. The problem there is that in the event of a DDoS you will absolutely kill TLC with enormous amounts of data since Netflow describes the way traffic is sent over the network.

Those enterprise solutions can also be very expensive and will add another device on your network to support and do life cycle management on.  After some more researching we had an idea, why not use the genius lightweight application written in C by Damien Miller at Google. Mr.Miller is heavily involved in OpenSSH so for me that was a very clear indication of what to expect from both the code and security of it.

By default flowd at its current version uses chroot and runs with a less privileged account, such as us security people like to see. As the description of the project states at Google code, “flowd – small, fast and secure NetFlow collector.”

The bad news with flowd in our case was that it did not support writing Netflow data to flat text files. Our plan was to write all the Netflow data to flat files and then use the throttle capabilities of the Tripwire VIA agent to send all flows to TLC using the encrypted communications channel and at the same time have TLC control of the amount of data the VIA agent sends.

That will solve a lot of issues when it comes to DDoS and any requirement of having a secure and connection oriented channel. The first step was to add some functionality of my own to flowd so I downloaded the source package, added some code to it so that it wrote all Netflow data to a flat file called today’s date, i.e. 2014-04-05.log.

Netflowd Tripwire

Simple tail –f of the .log which contains all the flow messages.

That enabled us to just point the VIA agent to the folder and listen for all files called *.log.

Newflowd & Tripwire Log Center

TLC Configuration of the same .log file which contains all the flow entries

Now when we had all the data in TLC as normal log data in the Audit Logger, we wanted it to be put in another firewall database so that we could graph our flows and use the geo-location information built into TLC.

Tripwire Log Center

Screenshot of Audit Logger example using the Advanced File Collector to retrieve flow data

To achieve this we only wrote a normalization rule to understand the logs and tell TLC that these are firewall related logs and you should put these in the firewall database which we called Flows.

About the Author: David Olander is the manager of the Security Operations Center at AddPro AB in Sweden. Being heavily involved in customer projects, David knows the importance of being flexible when adapting security to the needs of the customer. David holds numerous certifications such as CISSP, Tripwire Enterprise Professional and Log Center Foundation. In his spare time he enjoys programming and diving.


Editor’s Note: The opinions expressed in this and other guest author articles are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.


Related Articles:



picThe Executive’s Guide to the Top 20 Critical Security Controls

Tripwire has compiled an e-book, titled The Executive’s Guide to the Top 20 Critical Security Controls: Key Takeaways and Improvement Opportunities, which is available for download [registration form required].


Title image courtesy of ShutterStock