blocking p2p traffic
-
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.
-
@crunch-0 said in blocking p2p traffic:
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.
-
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.
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. -
@crunch-0 said in blocking p2p traffic:
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?
-
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. -
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.
-
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.
-
@crunch-0 said in blocking p2p traffic:
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?
-
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)
-
@crunch-0 said in blocking p2p traffic:
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?
-
My main router lan = 192.168.1.0/24
test machine = 10.1.1.0/24I 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.
-
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.comYou 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.
-
Hi thanks for the snort rule. Yeah my test machine can catch it. So it proves that snort works and i have no alternate path to the internet. I see drop alerts in the alert tab and i cannot ping (Request timeout).
-
@crunch-0 said in blocking p2p traffic:
Hi thanks for the snort rule. Yeah my test machine can catch it. So it proves that snort works and i have no alternate path to the internet. I see drop alerts in the alert tab and i cannot ping (Request timeout).
Then that indicates the p2p rules you are using are insufficient to stop all of the Bit Torrent stuff. It is catching part of the conversation between client and peer, but not everything, so the client is still able to make the connection and download. It's not a problem with Snort itself. Instead, it is a problem with the rule or rules attempting to detect the traffic. The rules are apparently not picking up everything.
The PUA rules are really designed to detect the presence of the target application and not necessarily to block it totally. You may need other rules to completely block the traffic. Try a Google search for "blocking p2p with snort" to get some links. I found a few. Several are old, but some are newer. Here is a newer one: https://www.researchgate.net/publication/334213518_Interception_of_P2P_Traffic_in_a_Campus_Network.
Here is a SANS Institute paper from 2009 about detecting Bit Torrent with Snort: https://www.sans.edu/student-files/presentations/Pres_R_Wanner_Torrents_Snort_V2.pdf.
Blocking stuff like this is a whack-a-mole game. The developers of the torrent clients strive to make their traffic indistinguishable from regular network traffic (and thus unblockable). And the IDS/IPS rules creators strive to create new detection rules that trigger on the latest evasion techniques - and around and around it goes ....
.
