BPF to filter out encrypted traffic

[Mil Spect]

I realize that there have been a few other posts, but I wasn't able to find one that specially addressed encrypted traffic and would welcome suggestions on how best to filter it out. We're more concerned with the pcap storage on disc than the number of alerts.

Due to limited hard drive space we are attempting to reduce the amount of pcap that is stored to disc so we can increase the number of days retained. The plan is to filter out things like encrypted traffic or back-ups.

After doing some research I believe this can be done by adding a bfp filter to the
/etc/nsm/rules/bpf.conf on the master sensor.

What I was wondering is something like the following good industry practice?

Such as the following filter:
tcp port not 443 (to ignore most SSL/encrypted traffic, obviously not all since it's not limited to this port)

The second question I have is if the bpf filter is applied before the network traffic is processed by Snort or after. In other words if I put an entry in bpf.conf would that cause certain rules not to fire since the Snort engine never saw the traffic that was filtered or will it trigger the event but then not write the packets to disc.

I did some research and testing with tcpreplay and I’m pretty sure if I put a filter in bpf.conf Snort never sees or alerts on the traffic (that's probably the intent)but wanted to be sure.

Referenced:
http://code.google.com/p/security-onion/wiki/BPF
http://blog.securityonion.net/2011/01/introduction-to-sguil-and-squert-part-3.html
https://groups.google.com/forum/#!searchin/security-onion/bpf/security-onion/PdCNskof5HQ/MmMKEYkqJrIJ

[Jeremy Hoel]

Doing it by port 443 means you also won't see clear text over 443 or
any other apps that are not web based and hide over 443.

The bpf tells snort to not even look at the traffic, so nothing fires
or gets written to disk.

I don't know if SO has a separate BPF for the packet capture, but if
it did then you could still allow snort to look at the 443 traffic but
not have the packet capture record it.

> --
> You received this message because you are subscribed to the Google Groups "security-onion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
> To post to this group, send email to securit...@googlegroups.com.
> Visit this group at http://groups.google.com/group/security-onion.
> For more options, visit https://groups.google.com/groups/opt_out.

[Doug Burks]

On Wed, Mar 5, 2014 at 1:28 PM, Jeremy Hoel <jth...@gmail.com> wrote:
> Doing it by port 443 means you also won't see clear text over 443 or
> any other apps that are not web based and hide over 443.
>
> The bpf tells snort to not even look at the traffic, so nothing fires
> or gets written to disk.
>
> I don't know if SO has a separate BPF for the packet capture, but if
> it did then you could still allow snort to look at the 443 traffic but
> not have the packet capture record it.

Yes, you can create a separate BPF for packet capture and this is
described on our BPF page:
https://code.google.com/p/security-onion/wiki/BPF#Granular_bpf.conf

[Mil Spect]

On Wednesday, March 5, 2014 1:34:28 PM UTC-5, Doug Burks wrote:

Sorry but I'm not understanding how to implement the information on the wiki to just affect the packet capture so that the traffic would still trigger alerts.

I understand that I can go in each interfaces file and remove the symlink in order to apply different bpf configurations to each interface - but wouldn't that also cause no alerts to trigger?

Or are you saying that I have to remove the symlink and add the filter to one of the other bpf files (I'm guessing bpf-pcap.conf), and this will only filter out writing the pcap to disc and not the alerts?

[Doug Burks]

Let's assume that your box is called "sensor" and your sniffing
interface is "eth1". So you should see something like this:

ls -l /etc/nsm/sensor-eth1/bpf*
lrwxrwxrwx 1 root root 8 Dec 14 20:41 bpf-bro.conf -> bpf.conf
lrwxrwxrwx 1 root root 23 Dec 14 20:41 bpf.conf -> /etc/nsm/rules/bpf.conf
lrwxrwxrwx 1 root root 8 Dec 14 20:41 bpf-ids.conf -> bpf.conf
lrwxrwxrwx 1 root root 8 Dec 14 20:41 bpf-pcap.conf -> bpf.conf
lrwxrwxrwx 1 root root 8 Dec 14 20:41 bpf-prads.conf -> bpf.conf

Notice that both bpf-ids.conf (BPF for Snort/Suricata IDS engine) and
bpf-pcap.conf (BPF for netsniff-ng full packet capture) are symlinked
to bpf.conf by default.

So if you want to specify a BPF that only applies to full packet
capture and *not* IDS alerts, you would do something like the
following:

# Delete the existing pcap symlink
sudo rm /etc/nsm/sensor-eth1/bpf-pcap.conf

# Create a regular file in its place and add your BPF using nano or
your favorite text editor
sudo nano /etc/nsm/sensor-eth1/bpf-pcap.conf

# Restart netsniff-ng to read new BPF
sudo nsm_sensor_ps-restart --only-pcap

Does that help?

> --
> You received this message because you are subscribed to the Google Groups "security-onion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
> To post to this group, send email to securit...@googlegroups.com.
> Visit this group at http://groups.google.com/group/security-onion.

> For more options, visit https://groups.google.com/d/optout.



--
Doug Burks

[Mil Spect]

Yes - Thank You so much I appreciate you taking the time to answer this.