blocking p2p traffic

Crunch 0

Hi i have setup snort and have enabled all the rules in the following rule categories

snort_pua-p2p.rules
snort_pua-p2p.so.rules
emerging-p2p.rules
openappid-p2p_file_sharing.rules

I have snort running in legacy blocking mode yet i am able to download torrents.

Is there something that i can do to block torrents?

bmeeks

Are you actually seeing alerts for this traffic on the ALERTS tab? Not all traffic can be detected, especially if the P2P client is hiding the traffic in SSL (https).

For the OpenAppID rules, you must also enable the OpenAppID preprocessor on the PREPROCESSORS tab for the interface. Have you done that? And did you restart Snort on the interface after making that change?

Crunch 0

@bmeeks

Yes I am seeing a lot of P2P alerts in the alerts tab. And in the blocked tab and I have enabled OpenAppID on the preprocessors tab for all interfaces.

bmeeks

@crunch-0 said in blocking p2p traffic:

@bmeeks

Yes I am seeing a lot of P2P alerts in the alerts tab. And in the blocked tab and I have enabled OpenAppID on the preprocessors tab for all interfaces.

Okay, if you are seeing the alerts, and you have Legacy Mode Blocking enabled, and you have enabled the option to kill states for blocked IPs, then the only reason offending IPs would not be blocked is if they are on the default Pass List. The default Pass List will contain all locally-attached firewall networks (except the WAN network), the firewall's configured DNS server(s), the default gateway and all individual firewall interface IPs (including the WAN public IP address).

So how about posting up a screenshot of one of those alerts from the ALERTS tab so I can have a look?

Crunch 0

@bmeeks

here is the screenshot
i have removed the end of each ip addresses

netgate alerts.png

bmeeks

@crunch-0 said in blocking p2p traffic:

@bmeeks

here is the screenshot
i have removed the end of each ip addresses

It is blocking the source IP. The Red X under the Source IP column indicates that IP address was sent to the firewall for blocking. You should see that IP address listed on the BLOCKS tab, and it will also be showing in the snort2c pf table under DIAGNOSTICS > TABLES.

I'm going to make a guess and say the Destination IP is in your local network (likely your WAN IP if you are running Snort on the WAN interface). I usually suggest folks run the IDS/IPS on the LAN. That way it won't trigger on useless noise the firewall is going to block anway. Plus, local network addresses will show as their actual value instead of being shown after NAT is applied.

When you select the blocking mode, you also have the option of which IP to block. I recommend BOTH for that setting, but even then it won't block IPs which are local to your network (so it won't block IPs on your LAN nor will it block your WAN's public IP).

So the alert above means that IP address 222.32.xx.xx (whatever the full value is), is blocked and can no longer be contacted by clients on your network. However, with P2P traffic, there are literally dozens upon dozens of alternate IP addresses for your client to contact (hence the name, peer-to-peer). Each of those remote hosts will, in turn, get blocked. But your local client will not, so it can keep trying each of those dozens of potential peers.

You can override this by creating your own custom Pass List and omitting locally-attached networks, but that is a good way to lock yourself completely out of the firewall and is not recommended if you lack IDS/IPS experience.

Crunch 0

@bmeeks

Thanks for the reply.

I tested the untangle router and it seems to be able to stop my torrents. It has a feature called tarpit. I wished snort was able to do this.

bmeeks

@crunch-0 said in blocking p2p traffic:

@bmeeks

Thanks for the reply.

I tested the untangle router and it seems to be able to stop my torrents. It has a feature called tarpit. I wished snort was able to do this.

If your firewall hardware (the network cards and their drivers) supports the netmap kernel device, then you can switch to Inline IPS Mode and use the SID MGMT tab to change your p2p rules to DROP. Inline IPS Mode does not use a Pass List because instead of blocking all traffic to or from an IP, that mode only drops individual packets that match the rule.

There is a Sticky Post at the top of this sub-forum describing the Inline IPS Mode.

Crunch 0

@bmeeks

Hi i read your sticky note about using inline mode. I followed the instructions and I see several drop logs in the alert tab. Unfortunately i still cannot get it to stop torrents.

bmeeks

@crunch-0 said in blocking p2p traffic:

@bmeeks

Hi i read your sticky note about using inline mode. I followed the instructions and I see several drop logs in the alert tab. Unfortunately i still cannot get it to stop torrents.

If I may ask, what is your experience level with cyber security and network engineering? How is your network laid out, and where do you have the IDS/IPS running (WAN or LAN)?

To be honest, what you describe does not seem plausible with Inline IPS Mode. If you are seeing packets dropped on the ALERTS tab, and the IP address shown for the dropping rule matches the workstation where you are running a torrent client, then that client should not be able to successfully download. Are you sure you have the rule changed to DROP? You should be seeing a red "thumbs down" icon for those rule alerts on the ALERTS tab if the rule action is changed to drop.

Crunch 0

@bmeeks

Hi so i have snort setup only in the LAN now and i have all the p2p rules enabled.

Attached is the photo of a drop alert.

drop alert.png

All the 19 alerts in the alert tab are drops for p2p activity

Regarding my background. I am a software developer,
I have zero cyber security experience and little networking experience. I have had pfsense running for an year now with 3 interfaces.

bmeeks

@crunch-0 said in blocking p2p traffic:

@bmeeks

Hi so i have snort setup only in the LAN now and i have all the p2p rules enabled.

Attached is the photo of a drop alert.

Regarding my background. I am a software developer,
I have zero cyber security experience and little networking experience. I have had pfsense running for an year now with 3 interfaces.

There is no need to blackout a portion of that destination IP address. I assume in the screenshot that 10.1.1.12 is your client since that is RFC1918 space. The 109.250.x whatever IP is the destination bit torrent peer (out on the Internet).

So that conversation is blocked. Literally the packet, as it came into the firewall's LAN interface, was dropped by Snort such that the destination IP (the peer out on the Internet) never saw that packet. Now the client will then immediately try to find another peer, but Snort should identify and drop that one as well.

Now what other modes your client may switch to, I'm not sure since I don't know the client. But many of them will, when stymied with conventional p2p connection attempts, switch to "firewall evasion" modes such as using SSL on port 443, for example. Are you sure your client is not doing that? Snort will not necessarily catch that kind of traffic.

And I have to also ask if you are 100% sure that your client's traffic is traversing the firewall? Does the client have another method to the Internet (maybe like with a wireless connection) that is bypassing the firewall?

Crunch 0

@bmeeks

Yes 10.1.1.12 is the ip of my local machine. The other is a p2p peer.
I am running transmission 2.94 as the p2p client. I am 100% sure that i am connected only through this interface. My wifi is off and connected through ethernet.

bmeeks

I'm still not sure about your network setup. You mentioned earlier about switching to untangle and using its tarpit function to stop the torrenting. Did you physically remove the pfSense firewall when you did that and replace it with another box?

If you have rules triggering and showing drops on the ALERTS tab, that should be interrupting the torrents. If not, then that screams to me the traffic has another route to the Internet. Perhaps your pfSense box is really just seeing the traffic pass by since the IDS will, by default, put the LAN interface in promiscuous mode. That means it will see all traffic on the wire, even traffic not targeted for the firewall.

Crunch 0

@bmeeks

Iam running them on KVM on ubuntu server. I have pfsense and Untangle in KVM virtual machines. The NIC's are directly attached to the virtual machine they are not virtualized.

I am running pfsense 2.4.5 and have 3 intel 82576 NIC's. Pfsense sees them as igbx.

bmeeks

@crunch-0 said in blocking p2p traffic:

@bmeeks

Iam running them on KVM on ubuntu server. I have pfsense and Untangle in KVM virtual machines. The NIC's are directly attached to the virtual machine they are not virtualized.

I am running pfsense 2.4.5 and have 3 intel 82576 NIC's. Pfsense sees them as igbx.

But how are things actually connected to each other? You should have this in order for Snort to properly block --

Client PC --> pfSense LAN --> pfSense internals --> pfSense WAN --> Internet

So you have the NICs configured as passthrough hardware in KVM? If you have three NICs, how are you doing this with two firewall virtual machines? Each firewall virtual machine would need a minimum of two NICs (one for LAN and one for WAN). Then you need to get traffic to the Ubuntu Server, so does it have a fourth NIC to work with? I really think you have traffic bypassing the firewall and Snort is just seeing the traffic due to promiscuous mode being enabled.

What are the IP addresses on the firewall's LAN and WAN interfaces?

Crunch 0

@bmeeks

Really speaking my main router is running pfsense, and i am playing with a another test machine running with KVM.

Client PC --> Test Machine pfSense -> Main PfSense -> Internet

Regarding traffic bypassing firewall, How would confirm from pfsense ? Is there a setting that i can look out for ?

My ubuntu server doesnt see any network interface cards as they are directly connected to the virtual machine (PCI Passthrough)

bmeeks

@crunch-0 said in blocking p2p traffic:

@bmeeks

Really speaking my main router is running pfsense, and i am playing with a another test machine running with KVM.

Client PC --> Test Machine pfSense -> Main PfSense -> Internet

If you have it hooked up this way, then that would mean your torrent client would be working through double-NAT. That's because, by default, pfSense will be doing NAT. What are the IP addresses of the LAN and WAN interfaces on your "Test Machine pfSense"? And how do you have the client machine hooked up? Is there a network switch in the mix, or is it directly to the NIC that is passed to the pfSense virtual machine?

Regarding traffic bypassing firewall, How would confirm from pfsense ? Is there a setting that i can look out for ?

It surely sounds, from your description, that you might have an alternate path for the client to reach the web. Run a packet capture on the WAN of the Test Machine pfSense box and see if your torrent traffic is showing up there.

My ubuntu server doesnt see any network interface cards as they are directly connected to the virtual machine (PCI Passthrough)

This makes no sense to me. Are you saying the Ubuntu server has no network connection at all? You stated there were 3 NICs. To what is each connected? For example, your Test Machine pfSense will need at least two to function, so where is the third going?

Crunch 0

@bmeeks

My main router lan = 192.168.1.0/24
test machine = 10.1.1.0/24

I have setup snort on my main machine to block p2p and i see p2p events on it too. The traffic that my test pfsense machine fails to block.

When i turn on pfsense virtual machine on my test machine, those pci express nic's stops serving the host. The nic's get directly attached to the virtual machine. Ubuntu server doesnt get internet from those nic's.

bmeeks

Let's try a different test to see if simple blocking of traffic is working.

On your Test Machine (pfSense), go to the RULES tab, select Custom Rules in the Category drop-down, then copy and paste this rule into the box:

drop icmp any any -> 64.91.255.98 any (msg:"Ping to dslreports.com target address"; GID:1; SID:20000001; rev:1; classtype:icmp-event;)

That rule will drop ICMP traffic to the domain dslreports.com. You can choose any other address you want to and substitute it. Just be sure it is a site that normally responds to ping requests.

Click Save to save the rule and return to the RULES tab.
On the RULES tab, click Apply to send the rules change to Snort. Wait several seconds for Snort to reload the rules and process the change.
Now, on the client PC where you have the torrent client, open a CLI session and attempt this command:

ping dslreports.com

You should see it attempting to ping IP address 64.91.255.98. It should fail with each attempt. If you then look on the ALERTS tab in Snort, you should see those alerts listed with the DROP icon (Red thumbs-down) in the Action column. If the ping suceeds, then you have an alternate path to the Internet for the client PC.