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