Netflow, nfdump and nfsen

In two previous posts I covered “What is netflow and when do you use it?” and “Use netflow with nfdump and nfsen“.

Nfsen provides a web interface on netflow data made available via nfdump. Because of the nature of the netflow data it is important to have strict access controls and extensive logging on the nfsen access. You should have a complete access and query log of who did what at any given time.

Access to the nfsen web interface is logged via the normal web server logging mechanism. This means you have the timestamp, the remote IP, the requested resource (nfsen.php) and some browser identification data.

The actual queries that you do in nfsen are send via a POST request. These queries are for example tracking connections towards a specific network port, connections from one host, etc.

Contrary to GET requests, the POST requests are not automatically logged. A GET request typically consist of a URL with a number of parameters and these get logged in the normal web server access logs. POST parameters are send as part of the ‘body’ of the request and as such do not end up in the logfile.

There is a solution to logging the POST variables. It is based on an ISC SANS post on Tracking HTTP POST data with ELK. You can use mod_security for logging all these variables.

Do note that logging the POST variables logs everything. Be aware of this if you enable POST logging on a site that submits confidential information via the POST request (creditcard numbers, user information, …).

mod_security for logging POST variables

mod_security is an open source web application firewall. You can use it to protect your web server but also to have more audit capabilities.

Apache – Installation

Installation (on Ubuntu) for Apache is straightforward

sudo apt-get install libapache2-mod-security2
sudo a2enmod security2

Nginx – Installation

The extensibility model of the nginx server does not include dynamically loaded modules, thus ModSecurity must be compiled with the source code. You need a couple of prerequisites to compile both nginx and ModSecurity.

sudo apt-get install libxml2 libxml2-dev libxml2-utils libaprutil1 libaprutil1-dev
sudo apt-get install libtool autoconf
sudo apt-get install apache2-dev

Although you’re building for nginx you still need the Apache development libraries. The next step is getting ModSecurity from GitHub, running the config script and compiling.

cd /usr/local/src
git clone https://github.com/SpiderLabs/ModSecurity.git mod_security
cd mod_security
./autogen.sh
./configure --enable-standalone-module --prefix=/usr/local/ --disable-mlogc
make
sudo make install

We don’t need mlogc. If you do then you should also install the curl libraries.

Once ModSecurity is build you should download the source of nginx and compile the server.

cd /usr/local/src
wget http://nginx.org/download/nginx-1.8.0.tar.gz
tar zxvf nginx-1.8.0.tar.gz
cd nginx-1.8.0/
./configure --user=www-data --group=www-data --add-module=../mod_security/nginx/modsecurity --with-ipv6 --prefix=/usr/local
make
sudo make install

I prefer to use the www-data user and group. It makes it easier to switch between Apache and Nginx if I decide to use another web server architecture.

If you use nginx for nfsen you will also have to install php-fpm and enable the PHP handler. You have to enable ModSecurity in the same section where you enable PHP (after all, the main script of nfsen is nfsen.php). Your PHP handler should look like this

location ~ \.php$ {
        ModSecurityEnabled on;
        ModSecurityConfig /etc/nginx/modsecurity.conf;
        proxy_pass http://localhost;
        proxy_read_timeout 180s;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;

        fastcgi_pass unix:/var/run/php5-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
}                

The core of the ModSecurity configuration for Nginx will be in the file /etc/nginx/modsecurity.conf.

Configuration

In this setup I’m not going to use mod_security to act as a web firewall but use it only for extra audit capabilities. This means I do not have to install extra rulesets etc.

Open the main mod_security configuration file. This is /etc/apache2/mods-enabled/security2.conf for Apache and /etc/nginx/modsecurity.conf for Nginx and add these configuration settings

SecRuleEngine On
SecRequestBodyAccess On
SecAuditLogParts ABCZ
SecAuditLog /var/log/apache2/modsec_audit.log
SecRule REQUEST_METHOD "POST" "id:1000,phase:2,ctl:auditEngine=On,nolog,pass"

• SecRuleEngine : Enable mod_security;
• SecRequestBodyAccess : Allow access to the body (needed for POST);
• SecAuditLogParts : Only log audit parts A, B and C (Z is mandatory);
• SecAuditLog : Path for the logfile;
• SecRule : Rule to apply to POST requests.

The audit log is only enabled when the SecRule triggers. This prevents log pollution. As you can see the parts that are audited are limited to A, B and C. These parts correspond with

• A : Audit log header (mandatory);
• B : Request headers;
• C : Request body;
• Z : Final boundary, signifies the end of the entry (mandatory).

Do not forget to restart your web server after committing these changes.

Logging nfsen queries

This is an example of the C-part of the audit log for an nfsen query

--cd9ee07d-C--
srcselector%5B%5D=local&filter=dst+host+192.168.218.1%0D%0A&filter_name=none&DefaultFilter=-1
&modeselect=1&listN=0&topN=0&stattype=0&statorder=0&aggr_srcselect=0&aggr_srcnetbits=24
&aggr_dstselect=0&aggr_dstnetbits=24&limitwhat=0&limithow=0&limitsize=0&limitscale=0
&output=auto&customfmt=&process=process

The parameters for the nfsen POST request are all concatenated into one large string but with some minor scripting you should be able to extract the parameters useful for your specific logging.

• srcselector : the netflow data source (in this case ‘local’);
• filter : the filter that was used in the query (in this case dst host 192.168.218.1);
• stattype : type of details fe. flow records, any IP, SRC or DST IP (in this case flow records);
• statorder : the sort order for the details.

Conclusion

Netflow data is a very useful source of data for incident investigation but it can also cause some privacy concerns. Because of this you should limit access to the netflow data and do full and proper logging of all the queries done on the netflow data.