Netflow on the Endpoint?

So you probably most commonly think of Netflow as a router feature (where you can monitor chokepoints to identify top talkers), but over the long holiday weekend I've used it as a way to monitor behind crappy closed source SOHO APs that don't allow you to turn off NAT. I've started running netflow on some of the Linux endpoints and just for grins I enabled it on my work laptop. On the various systems I point them at a single Netflow receiver, but on my laptop I obviously point them a local receiver.

On Ubuntu/Debian it is as simple as:

apt-get install flow-tools softflowd fprobe

Softflowd and fprobe both allow you to generate Netflow datagrams to send to a netflow receiver such as flow-tools. In both cases the receivers have single configuration files in /etc/default that allow you to specify the interface to monitor and the address and UDP port of the receiver.

root@e6400:/var/flows/2010/2010-11/2010-11-28# cat /etc/default/softflowd
#
# configuration for softflowd
#
# note: softflowd will not start without an interface configured.

# The interface softflowd listens on.
INTERFACE="eth0"

# Further options for softflowd, see "man softflowd" for details.
# You should at least define a host and a port where the accounting
# datagrams should be sent to, e.g.
# OPTIONS="-n 127.0.0.1:9995"
OPTIONS="-n 127.0.0.1:3333"

root@e6400:/var/flows/2010/2010-11/2010-11-28# cat /etc/default/fprobe
#fprobe default configuration file

INTERFACE="wlan0"
FLOW_COLLECTOR="127.0.0.1:3333"

#fprobe can't distinguish IP packet from other (e.g. ARP)
OTHER_ARGS="-fip"

Since neither of these probes allow you to monitor multiple interfaces I'm having to use both to monitor my wired and wireless interfaces.

Next, I configured flow-tools by editing /etc/flow-tools/flow-capture.conf with a single line:

-w /var/flows -n 275 -N 3 127.0.0.1/127.0.0.1/3333

This stories the netflow data in the /var/flows directory and the receiver listens on 127.0.0.1:3333 which corresponds to what we had above

I found that if the directory isn't present the daemon will fail to start. This error message will show up in the logs but not on the console

When I go into work tomorrow and I plug into my dock, this should do the trick, but we'll see.

The only thing I'm not sure about is whether the daemons will correctly handled a downed interface so I may have to manually start the daemons.

Now you'll see the files are created

root@fe6400:/var/flows/2010/2010-11/2010-11-28# ls -alt | head -20
total 248
drwxr-xr-x 2 root root 4096 2010-11-28 18:10 .
-rw-r--r-- 1 root root 88 2010-11-28 18:10 tmp-v05.2010-11-28.181027-0500
-rw-r--r-- 1 root root 96 2010-11-28 18:10 ft-v05.2010-11-28.180515-0500
-rw-r--r-- 1 root root 96 2010-11-28 18:05 ft-v05.2010-11-28.180001-0500
-rw-r--r-- 1 root root 96 2010-11-28 18:00 ft-v05.2010-11-28.175448-0500
-rw-r--r-- 1 root root 96 2010-11-28 17:54 ft-v05.2010-11-28.174935-0500
-rw-r--r-- 1 root root 96 2010-11-28 17:49 ft-v05.2010-11-28.174422-0500
-rw-r--r-- 1 root root 96 2010-11-28 17:44 ft-v05.2010-11-28.173909-0500
-rw-r--r-- 1 root root 96 2010-11-28 17:39 ft-v05.2010-11-28.173356-0500
-rw-r--r-- 1 root root 96 2010-11-28 17:33 ft-v05.2010-11-28.172843-0500
-rw-r--r-- 1 root root 96 2010-11-28 17:28 ft-v05.2010-11-28.172330-0500
-rw-r--r-- 1 root root 96 2010-11-28 17:23 ft-v05.2010-11-28.171816-0500
-rw-r--r-- 1 root root 96 2010-11-28 17:18 ft-v05.2010-11-28.171304-0500
-rw-r--r-- 1 root root 96 2010-11-28 17:13 ft-v05.2010-11-28.170751-0500
-rw-r--r-- 1 root root 96 2010-11-28 17:07 ft-v05.2010-11-28.170237-0500
-rw-r--r-- 1 root root 96 2010-11-28 17:02 ft-v05.2010-11-28.165725-0500
-rw-r--r-- 1 root root 96 2010-11-28 16:57 ft-v05.2010-11-28.165212-0500
-rw-r--r-- 1 root root 346 2010-11-28 16:52 ft-v05.2010-11-28.164659-0500
-rw-r--r-- 1 root root 806 2010-11-28 16:46 ft-v05.2010-11-28.164146-0500

And most of these are empty. I should adjust the the rotation should it creates smaller files.

But I can see what sort of activity my laptop was up to while I was dealing with my youngest son's terrible in-between-two-and-three during supper.

root@e6400:/var/flows/2010/2010-11/2010-11-28# flow-cat ft-v05.2010-11-28.164146-0500| flow-print

srcIP dstIP prot srcPort dstPort octets packets
172.16.1.1 172.16.1.145 17 67 68 576 1
0.0.0.0 255.255.255.255 17 68 67 656 2
172.16.1.145 192.168.1.1 17 58772 53 61 1
192.168.1.1 172.16.1.145 17 53 34490 100 1
192.168.1.1 172.16.1.145 17 53 38384 51 1
192.168.1.1 172.16.1.145 17 53 39480 51 1
172.16.1.145 192.168.1.1 17 39480 53 51 1
172.16.1.145 192.168.1.1 17 34490 53 61 1
172.16.1.145 192.168.1.1 17 53304 53 60 1
192.168.1.1 172.16.1.145 17 53 34640 100 1
172.16.1.145 192.168.1.1 17 38384 53 51 1
192.168.1.1 172.16.1.145 17 53 58772 100 1
172.16.1.145 192.168.1.1 17 34640 53 61 1
192.168.1.1 172.16.1.145 17 53 38674 76 1
172.16.1.145 224.0.0.251 17 5353 5353 2611 9
172.16.1.145 192.168.1.1 17 38674 53 60 1

Five Quick Interview Tips for Security Folks

So I've been spending 1-2 days a week for the last month or two interviewing folks for some open reqs. And yes I'm still hiring.

I've done quite a bit of interviewing (on both sides of the table) over the years in both big and small companies. In terms of the "big guys" I probably view Microsoft's process as the "gold standard." I also interviewed onsite with Amazon a while back and definitely incorporated some of what I experienced as a candidate from these west coast firms in what I do as an interviewer. Early in my days at Cisco we also did some good interviewing of candidates.

But based on recent experience, here are some things I've noticed, both in terms of tips and turn-off's. Most of these are of these are common sense.

1) Speak in concrete and specific (vs. abstract and general) terms about deliverables, responsibilities, tasks, and accomplishments. Convey a clear sense of who you are, what you like to do, and what you have accomplished. What is your career trajectory? Connect the dots for me. Even if you are "paper security" person (as opposed to a hands-on technical type) you can and should speak in specific standards, documents, and processes and data.

2) If asked about a given technology, the wrong answer is "another team did that" or "we weren't allowed to do that." Even if it is true. Find another way. This is a common problem with IT/Operational types and makes it difficult for me to envision you working in consulting, R&D, or other roles where you need to be flexible and will fill gaps where you find them.

3) Admit that you have forgotten certain technical skills if you've been "doing security" (or anything technical) for any period of time. If you say you haven't forgotten anything, you are either lying or a robot. In the long run, it is better to communicate in clear terms what you do or do not know. Plus, if you do get hired, something you claimed you were able to do (but perhaps wasn't able to be verified during the interview process, for whatever reason) may come back to haunt you as you will most certainly be passed a task.

4) When asked a seemingly factual question, the wrong answer is "I don't know" or "I could google it and find out." That is not the point. The point is to figure out what you know "around" that problem space. Plus, you are not going to get off that easy. I will take the question down a notch.

5) If asked if you can code, never, ever say you took Java/C programming in college, but haven't done any coding since then. Even if it is true. The "Modern American Poetry" classes I took are just as relevant. And resumes should err on the side of fewer skills than more skills. It makes it a pleasant surprise when you happen to know something not listed on your resume. And realistically if you put Nmap or Nessus (and most security folks do) please know what these do, because I will ask.