Improve Port-Unblocking

[GoogleCodeExporter]

We should improve PeerBlock's ability to block/unblock ports.  Currently
only HTTP/HTTPS ports (80/443) can be specifically blocked/unblocked; we
should permit any port to be blocked/unblocked, and include special-case
handling of known ports such as SMTP, FTP, etc.

Original issue reported on code.google.com by peerbloc...@gmail.com on 13 Jul 2009 at 4:13

[GoogleCodeExporter]

I definitely need this feature ASAP as well.  I need to allow all traffic on an 
uncommon HTTP port.

Original comment by psou...@gmail.com on 12 Oct 2010 at 4:36

[GoogleCodeExporter]

Has there been any progress on this? I have to turn PeerBlock off a lot in 
order to get certain applications to work. This is fairly annoying. 

Original comment by dgilb...@ggi.net on 23 Nov 2010 at 10:16

[GoogleCodeExporter]

Yes, our next Beta Release should include this feature.  Note that it can be 
"dangerous", since *all* traffic going out (or in/out, on XP) the specified 
port(s) will be completely unfiltered by PeerBlock.

Original comment by peerbloc...@gmail.com on 24 Nov 2010 at 4:15

[GoogleCodeExporter]

@peerblockproject "Yes, our next Beta Release should include this feature.  
Note that it can be "dangerous", since *all* traffic going out (or in/out, on 
XP) the specified port(s) will be completely unfiltered by PeerBlock."

I very much hope that an ability to have specified ports set to always be 
subject to the filters is added because of this. I would like to allow all 
ports and then add specific ports that I know should always be filtered. This 
would meet my needs 100% perfectly without danger, because the applications I 
need it for can have the incoming and outgoing ports limited to a specific 
range of ports.

Without a reverse force port filter list I would not be able to open up all 
ports but the ones I want filtered, because any port used in conjunction with 
the ports I want filtered would cause it to not be filtered because of the way 
the allow list will work. So a reverse force port filter list would be 
absolutely necessary.

Original comment by BigRedBr...@gmail.com on 24 Nov 2010 at 7:49

[GoogleCodeExporter]

Ideally there would be an "advanced" mode that allows you to choose which block 
mode PB uses. BigRedBrent would like to see the ability to allow everything 
except for specifically blocked ports. I can see the appeal of that. I would 
like to have the reverse. I would like to block every port except for certain 
ports/ranges that I need open. It would be ideal to be able to do either 
option. 

Any ETA on a beta build that will include port filtering?

Original comment by dgilb...@ggi.net on 29 Nov 2010 at 7:09

[GoogleCodeExporter]

For now we've concentrated on "Block all but these specified port-ranges".  
We'll certainly consider BigRedBrent's request going forward, but it's not 
gonna be in there for the short-term.

As far as official availability goes, the code's in our "trunk" branch right 
now . . . we simply need to generate a new build.  I've been holding off 
building trunk while we make sure that our 1.1 Stable Branch has fully 
stabilized, since we'll need to make some build-machine configuration tweaks 
before building a new "1.1+ Beta Release".  This should be coming soon, however.

What will likely happen is that I'll build a new 1.1+ release for internal 
testing - at that time, I'll also build an official Beta Release and post a 
link to it here for y'all to test.  (Note that this build may have a few extra 
bugs in it, since it will not have had much internal testing done on it yet!)  
Once everyone both internally and on here can confirm that nothing's seriously 
broken with the build, we'll release it as a new "official" Beta Release.

Original comment by peerbloc...@gmail.com on 29 Nov 2010 at 7:29

[GoogleCodeExporter]

Any update on this? Been 2 months and I haven't seen a new trunk out yet for us 
to beta test. I am definitely ready to do some testing.    :-)

Original comment by dgilb...@ggi.net on 3 Feb 2011 at 6:26

[GoogleCodeExporter]

As a member of the internal test team I can tell you that the feature is 
looking good to me. As soon as Mark has the time, I say release a new beta with 
the feature enabled.

Original comment by Keefaet...@gmail.com on 3 Feb 2011 at 11:55

[GoogleCodeExporter]

Issue 383 has been merged into this issue.

Original comment by nightstalkerz on 30 May 2011 at 9:37

[GoogleCodeExporter]

Is this feature ready or what? I can't find it in the current release or a beta 
release? Anyone know if/when this feature will be implemented? I run SimpleDNS 
as a local DNS cache and a HUGE percentage of the requests on port 53 are 
blocked so many websites don't resolve etc. Please add this feature as it will 
be super helpful!

Original comment by madtrade...@gmail.com on 3 Jul 2011 at 7:22

[GoogleCodeExporter]

R577 in the change log says "Remove port-profile branch as all the changes are 
in trunk."  Does that mean what it sounds like?

Original comment by bmar...@gmail.com on 18 Jul 2011 at 9:20

[GoogleCodeExporter]

It means they branched the code to work on a code featured called
'port-profile' which has now been merged back into the 'trunk' (main source)
so it can be removed.

And as to the question ... is port-profile related to this issue? I wish.

Original comment by madtrade...@gmail.com on 18 Jul 2011 at 9:23

[GoogleCodeExporter]

port-profile is related to this issue.

Currently there is only trunk which has all the changes. The branches are all 
very old.

Original comment by nightstalkerz on 19 Jul 2011 at 10:18

[GoogleCodeExporter]

I would like to join into this port block discussion.  Port blocking, or even 
better -  port searching in the logs, would be VERY helpful for me.  I do not 
use this excellent program in a P2P situation at all.  I run servers and 
manually scan the logs for attacks trying to penetrate our systems.  Sometimes 
I must jump to Event Viewer for this info, too.  So I will permanently BAN IPs 
that attack on 4899, 5900, 5800, and 110.
Please provide this type scan feature, and thanks.

Original comment by hankw....@gmail.com on 3 Sep 2012 at 10:53

[GoogleCodeExporter]

I'd also like to see this port range feature added as well, as I have about 10 
different web services running on other ports beside 80.

Original comment by rgste...@gmail.com on 7 Dec 2012 at 11:23

[GoogleCodeExporter]

Any update?

Original comment by krmarsha...@gmail.com on 24 May 2013 at 12:56

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

http://www.peerblock.com/releases/interim-releases/peerblock-1.1.0-r677

:D

Original comment by Aaron.Ha...@gmail.com on 8 Dec 2013 at 6:40

Attachments:

• Untitled.png

[GoogleCodeExporter]

Decent enough start, but why not a user-editable comma-separated list?

Original comment by psou...@gmail.com on 8 Dec 2013 at 4:48

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

#69 you can use the add button for an user editable list

Original comment by nightstalkerz on 8 Dec 2013 at 5:13

[GoogleCodeExporter]

Interesting.  The screen shot did not show an Add button.

Original comment by psou...@gmail.com on 8 Dec 2013 at 5:32

[GoogleCodeExporter]

My needs for this commonly is to whitelist NTP and DNS traffic.

Is there a special format for adding UDP packets?  I've added a few NTP server 
hosts from resolving <us.pool.ntp.org> to a new list TestBlock.p2p, but when 
using the new feature to allow port 123, they are still blocked possibly due to 
using UDP.  Removing the hosts from TestBlock.p2p allows them to received the 
UDP packets.

Also, I tried adding GoogleDNS hosts 8.8.8.8 and 8.8.4.4 to TestBlock.p2p, 
thinking I could test similarly with port 53.  But even though they are both in 
the new blocklist, I can successful use NSLookup against 8.8.8.8 at will. 
8.8.4.4 is blocked, however, and since DNS is using UDP, adding port 53 in the 
new functionality likewise does not whitelist the port.

But thank you for the work!

Original comment by bmar...@gmail.com on 8 Dec 2013 at 8:14

[GoogleCodeExporter]

UDP's inclusion into the user-defined allowed port list is essential for the 
ideal configuration of programs that use TCP and UDP interdependantly. I 
suppose an 'instant' fix would be to allow UDP by default on nominated ports 
(or read from a switch in the config whether to allow UDP)

In my humble opinion, with a properly configured Peerblock (and a sane mind), 
one doesn't need any security software. Please continue kicking digital ass
T

Original comment by djcup...@gmail.com on 4 Mar 2014 at 5:33

[GoogleCodeExporter]

I use the Dolby Axon client for voice communications with fellow online 
teammates and I find that Peerblock indeed blocks all incoming UDP packets 
carrying the voice data to the Axon client installed on my computer.  I've 
added all Dolby IPs that source these UDP packets, but Peerblock still denies 
them.  There should be a way to permit this traffic, especially since I've 
added the source IPs to my ACL allow list.  Please let me know if you expect to 
release such a feature anytime soon, or if I should continue my search for an 
IP blocker that will allow me to do so.  Keep up the great work!

Original comment by brian.ma...@gmail.com on 20 Aug 2014 at 5:36

[GoogleCodeExporter]

I use peerblock for both list blocking and port opening. I have a idea that may 
be of great use to people especially server side uses.
1. as of 1.2 you can add a port and nothing gets blocked which is great!
2. take this one step further and during the add or edit option allow blocking 
lists of choice to be enabled. This will allow the port to function as it 
should while still blocking attackers and crawlers. So as a example I can use 
port 53 as a open port but block the bad guys at the same time with either a 
single list or better yet a multi-list selection via check box. I would add 
though that the lists that are going to be used to block any opened port also 
be required active lists so that your not duplicating and the main code take 
care of updating and adding removing of lists. So in a sense I would like to 
see all the installed lists as just their names with a checkbox that would 
enable that list to still block on the opened port and have the option only in 
the edit and creation screen. This will allow choice if I need to still 
safeguard my ports from baddies and crawlers and/or any person looking to see 
if they can see any P2P files and my GUID which are required for a lawsuit so 
the lists will still safeguard and protect both the PC/Server and the person 
behind it. 

Please contact me back as i don't come here often enough to see what people say.

Original comment by worldsey...@gmail.com on 8 May 2015 at 8:37

[GoogleCodeExporter]

Wordsey, if you star this issue at the top, you can receive notifications when 
posts/answers occur.

I'm not a developer, but I'd like to suggest that the functionality you're 
describing is actually PeerBlock's primary function. For example, if you do not 
white list port 53 with the new Port Settings tab, then it will still allow 
port 53 unless the remote IP is in a block list.

If you do white list port 53 on the Port Settings tab, then sure, technically, 
an Anti-P2P can use the open 53 for its own purpose. However, the port white 
listing is mostly useful on servers (or clients) that are only using malware or 
antivirus block lists for added protection, not running sharing software. White 
listing specific ports allows a client process on the server to reach out to a 
service on the Internet such as NTP or SMTP/IMAP/POP3 on multiple hosts with 
unknown or dynamic IPs.

FYI, DNS on port 53 is still an issue because it generally uses UDP, and white 
listing seems to allow only TCP packets in v1.2. UDP is blocked regardless.

Original comment by bmar...@gmail.com on 9 May 2015 at 7:07

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This is more of what I ment
1)  Manually enter port to manage
a)  Choose 1 of 2 options
i)  Frist, BLOCKS all traffic
(1) Has the ability to add a list(s) to nullify effect for IP addresses/ranges 
in that list.
ii) Second, ALLOWS all traffic
(1) Has the ability to add a list(s) to nullify effect for IP addresses/ranges 
in that list.
2)  Save-done!  To change choose edit after highlighting the port you want to 
edit.
It only affects the port you selected and removes the port you selected from 
the general blocking main system.  This allows Full control over every port if 
you want to prevent sniffing, crawling, blacklisting, and all the other stuff 
no one likes to have to deal with.
This allows ports to be moved from the common block allow list and allows 
micromanagement of all 65k+ ports if you want/need to.  No program does this 
except maybe a firewall but this makes it much easier to add larger ranges of 
lists that are already made and in-use thus cutting down setup time and 
increasing security and allowing for single small changes or large changes at a 
single adding/removing/changing of a list.  In a sense, it is all about 
versatility!

Plus what is good for one port may be terrible for another like the DNS port 
53. Thus the FULL ALLOW/BLOCK and adding of list to get over the tcp to UDP 
problems

Original comment by worldsey...@gmail.com on 14 May 2015 at 1:59

[GoogleCodeExporter]

This has been on the to do list forever!
What you say is sensible but perhaps overly complicated? The idea of manually 
setting inc/exclusions for every port rule is too tedious
Seeing as Peerblock was essentially a filter for all ip addresses; its initial 
focus was on total filtration with exceptions only on common ports. A 
fundamental redesign is necessary instead of extending merely the port 
assignments
It really needs the block/allow list to be just that, with no on/off switches. 
Then each port group has a bitmask for the current block list that gives the 
user control to turn on and off the desired lists
Obviously things go pear shaped if one then modifies the lists, but if the 
assumption for new lists is that they are active for all port groups that 
haven't been explicitly configured, then it's only a small task to make any 
adjustments

While we're on the subject, don't we think that each list item should have 
numerous sources? It seems to me that reducing stress on servers providing the 
lists would be alleviated by more peers. Obviously it would be AMAZING if 
Peerblock itself had a built-in P2P system that took care of distribution 
(I.e.: torrents for block lists), but failing that I'd be more than happy to 
provide bandwidth for this endeavour, even on my crappy broadband
T

Original comment by djcup...@gmail.com on 15 May 2015 at 1:13

[GoogleCodeExporter]

Just the ability to specifically block a port to all addresses would be awesome!

Original comment by norff...@gmail.com on 20 May 2015 at 7:18

[GoogleCodeExporter]

Gee, if only there were something built into Windows that did just that... kind 
of like a firewall.... Yeah... a Windows Firewall.

I think wordsey's and norff's requirements can be accomodated with additional 
Windows Firewall configs.  If you like the command line, you can try googling 
the phrase:
netsh advfirewall firewall add rule

Original comment by bmar...@gmail.com on 20 May 2015 at 8:20

[GoogleCodeExporter]

The idea is to make peerblock a all in one place for blocking making it a
nicer tool and should it shape up and add a firewall type of blocking that
is overboard. whether you want to admit it or not. windows firewall acts
AFTER the data has already been downloaded and than checks. peerblock
checks first and allow/disallow connections based on the IP lists and after
that if not found in the disallow list permits connection. MS is so full of
holes that Swiss cheese is solid by comparison and you can't add lists that
update like peerblock does from iblock.

Original comment by worldsey...@gmail.com on 2 Aug 2015 at 4:00

[GoogleCodeExporter]

As of Aug 2015 PB ports only allow tcp protocol and not udp.

Original comment by RobrPatt...@gmail.com on 11 Aug 2015 at 3:38