How to block Software P2P like as Bittorent?

Post your questions about VPN Gate Academic Experiment Service here. Please answer questions if you can afford.
Post Reply
Frangky
Posts: 2
Joined: Sun Aug 03, 2014 4:36 am

How to block Software P2P like as Bittorent?

Post by Frangky » Sun Aug 10, 2014 11:43 am

Dear All Master,

How to block Software P2P like as Bittorent from Softether VPN Server.

Thank you.

BoredAus
Posts: 115
Joined: Sun Nov 23, 2014 3:29 am

Re: How to block Software P2P like as Bittorent?

Post by BoredAus » Mon Jan 12, 2015 11:34 am

I haven't found an ideal fix to block VPN users from torrenting, however it appears that my crude form of blocking VPN users from torrenting seems to work. Though the downsides is that it not only blocks users from torrenting, it also blocks them from various other functionalities such as chatting which usually requires a high number port opened.

The real problem is the lack of free tools to block torrenters properly and with it one needs to have specific know how of networking and are able to fully utilise their firewalls. So far my crude way consists of three things that are required:

1: SoftEther VPN's LAN IP address to be used for blocking.
2: University of Tsukuba's IP netblock to be set to unblock as communications are required when volunteering one's connection as a public VPN volunteer server.
3: Specific range of ports to block. Also to test where possible if the methods are actually working or not, etc.

The first step is probably one of the most easiest step and doesn't require very intimiate knowledge of setting up, the other two are more specific to firewall setup.

In the first step, one needs to trace the LAN IP that SoftEther VPN Server Manager is using for SecureNAT. This is the default setup of SoftEther VPN Server Manager when VPN Gate functionality is enabled. So to find that out one can probably try using a packet monitoring software like wireshark for instance. Better yet, if say your case is for a general home connection, you can log into your router and see the DHCP leases, securenat would have its own unique name followed by the MAC address of its own virtual NIC. Ideally in this step, you might also want to look into giving securenat-* a static IP address lease, that way, you probably won't need to change the targeted IP address all the time.

The second step is a matter of adding appropriate netblock for University of Tsukuba. I have traced down the IP address and from there found the netblock. The netblock of University of Tsukuba is: 130.158.0.0 - 130.158.255.255 alternativatively CIDR notation is 130.158.0.0/16. Depending on your gateway device that you have, you basically need to know how to mess with the firewall software it has. In virtualised environment, it would most likely be the VM host that would be the gateway device and not necessarily the physical device between LAN computers and internet.

The last step is to add appropriate blocks and allows. Most home routers are essentially running on linux platform and their firewall is iptables. A fair few of those home routers may allow remote access to it other than the web interface. If your home router has alternative remote access methods such as telnet/ssh for instance, you might also want to look into that should the web configuration method proved to be inefficient. In my case I have found web configuration method of mine to be inefficient and was more or less forced to write my own rules up for it.

The way iptables works is as described by the manual, which states that packets run through the list of matching rules, if a rule listed matches the packets the packets will be subjected to whatever the rule says. If the rules does not contain anything to block/filter the packets, the packets will travel through the rules without being subjected to anything and consequentially be accepted. In other words, for default cases, we want to block packets as we do not want them to transverse through the list of rules and not be subject to filtering. Though however the first set of rules to apply in this case for iptables are to allow communications between SoftEther VPN Server Manager and University of Tsukuba.

In my own scenario, I have setup a static IP lease for securenat and it happens to be outside the DHCP scope of my DHCP leases. I have assigned securenat to be 192.168.0.11 and what I have found on my gateway's iptables setup is relatively easy to configure as the web interfaces lack finesse but has paved a way to allow customisations. My gateway device has setup from INPUT chain to also go through its own set of chains which I append to known as PKF_IN for INPUT chains and PKF_OUT for OUTPUT chains respectively:
iptables -A PKF_IN -s 130.158.0.0/16 -d 192.168.0.11 -j ACCEPT
iptables -A PKF_OUT -s 192.168.0.11 -d 130.158.0.0/16 -j ACCEPT

As noted above, 130.158.0.0/16 is the CIDR address for University of Tsukuba netblock, if you do not have this close to the top of the chain when setting up blocking, communications between your SoftEther VPN Server Manager with VPN Gate enabled and University of Tsukuba blocked. I have found that the communications between the two are mainly for examining your connectivity with the internet, such as IP address, IPv6 address, NAT address, etc. Possibly also, statistics from your host running the software along with logs are to be sent as well, also with communication for list of banned IPs from University of Tsukuba's master server list. However, some of those could be at a guess. In any rate you should not block these as it may spell trouble further down the road.

With the exceptions set in place, the next step is to add appropriate port blocks. Depending on how strict you want to be with your port blocking, it is up to you. Bittorrent for instance does not conform to any specific dedicated ports, it could listen and communicate with other nodes on virtually any specific random ports for both source and destination. Though in general cases, they usually work on fairly high port ranges. Say for instance ports 10000-65535 would be sufficient to whack out torrenters but allows some chatting functions to work and not online gaming for instance. You could be even more strict and restrict the port ranges from ports 10000 to ports 1000 to 65535 - that would also block lots of chat softwares plus a host of other things such as proxies. If you want to be extremely paranoid, you can start blocking ports from port 444 all the way to 65535 this probably would only allow VPN clients to basically visit web servers for both standard (port 80) and secure (port 443) plus a few other minor things.

Ideally, the rules should be setup in pairs as there are two typical ways of communication, if not TCP it is UDP. For torrenting, they could also use UDP route if TCP Is blocked, so blocking both is ideal:
iptables -A PKF_IN -p tcp -d 192.168.0.11 --sport 1000:65535 -j DROP
iptables -A PKF_IN -p udp -d 192.168.0.11 --sport 1000:65535 -j DROP
iptables -A PKF_OUT -p tcp -s 192.168.0.11 --dport 1000:65535 -j DROP
iptables -A PKF_OUT -p udp -s 192.168.0.11 --dport 1000:65535 -j DROP

In this case I have setup a sort of middle ground, not too paranoid but fairly paranoid. This should block incoming and outgoing ports for securenat from port 1000 to 65535 which of course include a range of services blocked for VPN clients. I have noticed apart from chatting some VPN users have been using steam, those usually run on ports 27017 or so and of course should be blocked as they are within the port ranges that I have defined as ports to block.

The final steps are to basically either test and/or monitor to see that your rules does work. Cases of a working setup would probably see VPN clients trying to connect away but has not heard any response, they may retry communication but because my rules are set to DROP, they will never hear a response back. You can also replace the DROP with REJECT, usually that may require extra parameters and probably demands more from whichever device that is doing the blocks.

Another problem is that these blocking methods maybe temporary, i.e. when the gateway device is restarted, settings are lost because they were not made through the web UI hence they were not written into some file. So if the setup is working, you might want to look into ways of storing the setup somewhere in case things like that exist.

Ultimately, your iptables setup should look something like this:
# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpts:bootps:bootpc
IDS_INP all -- anywhere anywhere
ISAP_INP icmp -- anywhere anywhere
PKF_IN all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
DROP all -- anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere base-address.mcast.net/4
TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU
PKF_OUT all -- anywhere anywhere
PKF_IN all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate DNAT
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
LOG tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 6/hour burst 5 LOG level alert prefix `Intrusion -> '
DROP all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
DROP all -- anywhere 239.255.255.250
DROP all -- anywhere 239.255.255.250
DROP all -- anywhere 239.255.255.250

Chain GRP_FWD (0 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere

Chain IDS_INP (1 references)
target prot opt source destination
RETURN tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 30/sec burst 5
LOG tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN LOG level alert unknown-flags prefix `Intrusion -> '

Chain ISAP_INP (1 references)
target prot opt source destination
ACCEPT icmp -- anywhere anywhere icmp echo-request

Chain PKF_IN (2 references)
target prot opt source destination
ACCEPT all -- tsukuba.ac.jp/16 securenat-daa29d2c67ee
LOG tcp -- anywhere anywhere destination IP range 192.168.0.11-192.168.0.11 tcp spts:1000:65535 LOG level info prefix `PacketFilter:'
DROP tcp -- anywhere securenat-daa29d2c67ee tcp spts:1000:65535
LOG udp -- anywhere anywhere destination IP range 192.168.0.11-192.168.0.11 udp spts:1000:65535 LOG level info prefix `PacketFilter:'
DROP udp -- anywhere securenat-daa29d2c67ee udp spts:1000:65535

Chain PKF_OUT (1 references)
target prot opt source destination
ACCEPT all -- securenat-daa29d2c67ee tsukuba.ac.jp/16
LOG tcp -- anywhere anywhere source IP range 192.168.0.11-192.168.0.11 tcp dpts:1000:65535 LOG level info unknown-flags prefix `PacketFilter:'
DROP tcp -- securenat-daa29d2c67ee anywhere tcp dpts:1000:65535
LOG udp -- anywhere anywhere source IP range 192.168.0.11-192.168.0.11 udp dpts:1000:65535 LOG level info unknown-flags prefix `PacketFilter:'
DROP udp -- securenat-daa29d2c67ee anywhere udp dpts:1000:65535
#

The wider the range of ports you set to block generally indicates the fewer the ports the VPN users have to available to play with. Blocking port 1000-65535 easily nails out Bittorrent but still allows around 999 or so ports for the VPN users to play with, and most of those requires administrator/root access as they are mainly reserved for services. Again, it is possible to substitute port 1000 with port 444, this would really be strict and subsequently give VPN users 443 ports to play with.

--EDIT--
tl;dr. I wanted to also point out there is another extra level of paranoia, blocking all the ports and allowing whatever ports you want your clients to access. This bit of setup is a bit like what one would normally do for setting up iptables on their own machines. Some ports that you should not block when attempting this sort of setup for starters: port 80 (HTTP), 443 (HTTPS), 20-21 (FTP), etc. Blocking HTTP and HTTPS ports basically inhibits the clients from viewing web pages, needless to say.

Ultimately, there is no guaranteed way of blocking with great success without looking into investing professional services. The guide here is primitive enough to basically deter an average user's capability to torrent or do some other malicious and potentially unwanted activity, it is not a foolproof guide that would stop a determined user circumventing your prevention mechanisms regardless of the costs.

Post Reply