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]

Original comment by peerbloc...@gmail.com on 13 Jul 2009 at 4:16

• Added labels: Priority-Medium
• Removed labels: Priority-Low

[GoogleCodeExporter]

Original comment by peerbloc...@gmail.com on 24 Jul 2009 at 5:47

• Added labels: Milestone-After1.0

[GoogleCodeExporter]

We should also consider for this Enhancement the ability to select which 
program to 
block/unblock... Which would give more control to users who don't know what 
ports to specifically block/unblock.

But of course only when we get there... ;-)

Original comment by mynameherebro on 28 Jul 2009 at 2:08

[GoogleCodeExporter]

Removing 'After1.0' release-targetting.

Original comment by peerbloc...@gmail.com on 29 Sep 2009 at 3:58

• Removed labels: Milestone-After1.0

[GoogleCodeExporter]

Original comment by peerbloc...@gmail.com on 30 Sep 2009 at 4:34

• Added labels: Milestone-1.1

[GoogleCodeExporter]

I agree to all comment here 
Prog et port can chhose to block

Original comment by gallax...@gmail.com on 29 Oct 2009 at 10:53

[GoogleCodeExporter]

Yes, I agree too!!
It would be great for server

Original comment by polloda@gmail.com on 31 Oct 2009 at 5:36

[GoogleCodeExporter]

It would be extremely useful if each IP range could be specific to a port range.

Original comment by wopeg...@tfea.co.cc on 19 Nov 2009 at 4:03

[GoogleCodeExporter]

Original comment by peerbloc...@gmail.com on 1 Dec 2009 at 3:07

• Changed state: Started

[GoogleCodeExporter]

by adding these features (primarily the "per-app" feature noted above), 
peerblock is 
really going on it's way to becoming a true "firewall" rather than a "Internet 
Protocol 
address blocker"....

I like the idea of allowing "other ports" to be unblocked/allowed, but to allow 
other 
application allows to it, could get messy?

Original comment by aho...@gmail.com on 5 Dec 2009 at 5:50

[GoogleCodeExporter]

I would think "allow" would be messy per-app.  All it's really telling 
peerblock is 
"this app isn't a p2p app so don't worry about filtering it's traffic."

It would be very useful if you are running a web-server or something like that, 
for 
instance.  Obviously (in most cases), you would want traffic that peerblock 
normally 
blocks to be able to see your website.  Instead of worrying about allowing the 
port(s) the web-server uses, you can just tell it to always allow the 
web-server 
program.

In fact, it may be beneficial to have a setting in peerblock to say "only block 
these 
programs and allow all others".  Then add the desired programs (p2p, etc) to 
that 
list.  The same thing could be done with ports as well.  "Only block port 37489 
because that's the only port I really care about filtering traffic on".

Original comment by ejthill@gmail.com on 5 Dec 2009 at 8:26

[GoogleCodeExporter]

IMHO, this discussion gets away from the initial point..
It's not about allowing foo.exe to connect via port X to IP 1.2.3.4 - it's about
improving unblocking of _ports_!

So, from my point of view, we should be able to define several ports we would 
like to
allow connections to/from while _all_ other ports remain being blocked..

Examples: add port 20 and 21 to "Allow HTTP" or maybe port 139 which is used 
for NTP..

Original comment by Eagle3...@gmail.com on 5 Dec 2009 at 8:54

[GoogleCodeExporter]

I agree with Eagle. Keep this discussion related to the issue at hand and don't 
go
off topic. This is about allowing us to unblock ports in the same way that we 
unblock
IPs. There are many practical uses for this. I personally need to allow 465 and 
995
for SSL purposes, and it would be nice to also have 110 (pop3) and 25 (smtp) 
allowed
as well. Instead, I constantly run into SSL errors and have to allow IPs on and 
on again.

Original comment by chi...@gmail.com on 5 Dec 2009 at 9:11

[GoogleCodeExporter]

night_stalker_z has submitted an initial patch against this issue; good 
progress is
being made.  Our intent at this point is to essentially let you create your own
"Allow HTTP" style rules.  We're still discussing the UI for this, but for 
example
you should be able to Allow HTTP, Allow FTP, Allow SMTP, or create your own 
custom
ports (or port sets) - identified by a name you give them - and "Allow 
Whatever".  We
hope to have this feature ready for inclusion in the next Beta Release, in 
another
week or two.

As far as the per-app rules go, I'd thought we already had an issue open to 
track
that but apparently not.  I've added Issue #222 for the "Application Whitelist" 
idea,
feel free to discuss the relative merits of that over in that bug.

Original comment by peerbloc...@gmail.com on 6 Dec 2009 at 2:51

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

 Allow Some Ports is a very good idea....  is a mast have option for PeerBlock.
I`m very happy with this software. Imagine PeerBlock well no`t block any more my
DNS(port 53. I run my own web DNS). Perfect configuration for all my servers 
and no
need to "work" my hosts file :D
 Thank You! Great Job !!! :) 

Original comment by asus3...@gmail.com on 22 Dec 2009 at 4:03

[GoogleCodeExporter]

i have PeerBlock running on a 2003 AD Box.  I have a DNS Server for AD, and 
some DNS 
requests (Port 53)  I would love it if you guys allow the ability to set 
specific 
port and or port ranges to include.  Having the ability to run the app of as a 
service would knock it out of the ballpark...

Great job on the software.  Nice clean interface and it's easy to use.

Original comment by david.bi...@gmail.com on 30 Dec 2009 at 7:58

[GoogleCodeExporter]

Count me in.  I would especially like port 123 unblocked for NTP.  I've been 
adding
IPs to Peerguardian for years because they come up in the us.pool.ntp.org 
address
pool.  From a security standpoint this is bad, allowing all traffic from a
potentially hijacked machine just because it appears to be a time server.

Thanks, all, for this great bundle of improvement on an already greatly useful 
program!

Original comment by bmar...@gmail.com on 15 Jan 2010 at 4:17

[GoogleCodeExporter]

Issue 255 has been merged into this issue.

Original comment by peerbloc...@gmail.com on 17 Jan 2010 at 4:53

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

It would be just as useful to be able to also specify what ports (both incoming 
and
outgoing) should always be filtered even if they are included in the allow port 
list.

Original comment by BigRedBr...@gmail.com on 17 Feb 2010 at 4:36

[GoogleCodeExporter]

I think the possibility to allow global unfiltered ports could be very useful 
(in the
sense of an application that needs a specific port). However, given the primary
nature of the program (block all these IPs), it would also be very useful to 
unblock
a specific port for an IP or IP range. For instance, perhaps I want to allow
adobe.com on port 80, but not on any other port. However, I don't want to allow 
all
HTTP because then it won't block things from doubleclick.net:80.

As an example: say I want to go get the newest flash player, but adobe's 
servers are
all blacklisted in the p2p list. Now, I could allow the specific IP in 
peerblock's
window temporarily, but adobe.com is on a server farm with quite a few 
different IP
addresses, so I keep having to go back and allow different IPs. However, this 
opens
me up to whatever else they may be running on those servers besides a web server
(which may be paranoid, but that's what this program's for). So, ideally, I 
would
like to unblock "adobe.com:80", either temporarily or permanently (bonus points 
if it
does DNS resolution for me and unblocks all IPs in that range).

Even a right-click option like "Allow xxx.xxx.xxx.xxx on <protocol><port> for 15
minutes/1 hour/perm" would be nice, where the port/protocol are the ones listed 
in
the destination/protocol columns. 

Original comment by lethalfa...@gmail.com on 8 Mar 2010 at 1:27

[GoogleCodeExporter]

(un)blocking an IP range is already implemented:
List Manager | Permallow list | Add ...

Original comment by jernejho...@gmail.com on 9 Mar 2010 at 2:17

[GoogleCodeExporter]

Noticed the Port (Allow?) Settings were hidden from r277, added back at r280, 
but
hidden again r320.  If there were a way, I would graciously help test it.  I 
haven't
programmed in decades, but I'm even considering (wretch) installing VC++ Express
(wretch) to try and compile if I could use it sooner.  Anxiously chompin' at 
the bit
here....

Original comment by bmar...@gmail.com on 10 Mar 2010 at 4:20

[GoogleCodeExporter]

This feature is still very much in-development at this stage - not something we 
feel
is ready for inclusion even in our Beta Release train yet.  Call it an Alpha 
quality
feature.  This is why we've been removing the "Port Settings" button from the 
UI for
each of our recent Beta Releases.

The biggest problem is that this can be a very dangerous feature, as it's 
completely
opening up one some number of ports on your machine.  That said, I'm all for 
giving
people a loaded gun and saying "Careful, don't shoot yourself in the foot with 
this!"
. . . so once the feature is just a little more stable we'll look into making a
special build of PeerBlock available to those of you who are highly interested.

Original comment by peerbloc...@gmail.com on 10 Mar 2010 at 4:33

[GoogleCodeExporter]

Color me "highly interested".  There's currently 48 users starred this 
enhancement. 
If you post when it's available, I expect some of us will step up.

Thanks so much!

Original comment by bmar...@gmail.com on 11 Mar 2010 at 12:01

[GoogleCodeExporter]

Same here! :)

Original comment by Eagle3...@gmail.com on 11 Mar 2010 at 7:51

[GoogleCodeExporter]

I would definitely like this as well, useful for my smtp server.

Original comment by BreakThe...@gmail.com on 30 Mar 2010 at 8:41

[GoogleCodeExporter]

night_stalker_z Wrote:
-------------------------------------------------------
> Both the destination and source ports will be
> checked against the ports that you allow 
> 
> e.g. if you allow port 5000 and either the source
> uses port 5000 or the destination uses 5000, it
> will be allowed to go through otherwise it gets
> blocked.

It sounds like this method of allowing will require an additional force 
filtering list.

From what I can tell this is going to require an additional force filtering 
list, so
that you can allow all the ports that you want to be allowed and then add ports 
to
the force filtering list that will override the port allow list forcing them 
again to
be filtered.

And on top of that, how about the option to specify in the list exactly what
direction and end the ports will be exempt from filtering for? So each port 
entry to
the allow list would have four additional options that could be added with check
boxes. The four additional options would be: Allow external source on incoming
connections, Allow local source on outgoing connections, Allow local source on
incoming connections, and Allow external source on outgoing connections.

Honestly I can not think of a simpler way to fix this problem other then to 
simply
add the ability to specify ports you want to make sure are always filtered even 
if
they are in the allow list. The ability to specify what direction and 
connection end
to always make sure are filtered would be useful in this force filtering list 
as well.

But even without all the control of being able to specify exactly what 
direction and
end to filter or allow, the ability to make sure some ports are always filtered 
even
if they are in the allow list is absolutely essential and a requirement for my 
needs.

Original comment by BigRedBr...@gmail.com on 14 Apr 2010 at 6:36

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I can not stress enough how important the ability to add a force port filtering 
list
that overrides the allow port list would be. You would simply add the ports you 
want
to allow into the allow list, and then add the ports you want to force 
filtering for
in the force port filtering list to have those ports filtered again. Without 
this
force port filtering list I would have no use what so ever for a port allowing 
list.
So please, I beg of you to add a force port filtering option along with this 
allow
port option.

I am sick to death of having ports being filtered that do not need to be, but 
without
a force port filtering list I would still need to have all ports filtered or 
risk an
external port being allowed when it should not be.

Original comment by BigRedBr...@gmail.com on 14 Apr 2010 at 6:52

[GoogleCodeExporter]

Theres been some changes since last time although it will work better for 
Vista/Win7 
due to the pbfilter is more reliable than the XP way.

You can specify ports and which direction they go in (i.e. imcoming port, 
outgoing port 
or both).

To get the force filtering, can't you just remove the port in the allow list? 
Or am I 
missing something here?

Original comment by nightstalkerz on 14 Apr 2010 at 8:02

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

As far as I knew a single connection can use two ports (source and 
destination). So
if both ports are being looked at, then if only one of them matches the allow 
list it
will be allowed. But what if the other port in that same connection is not in 
the
allow list and you never EVER wanted the other port to be unfiltered? Some way 
must
be included to make absolutely sure that some ports are ALWAYS filtered no 
matter what.

You mention being able to specify the direction for the port, but what about 
the side
that it belongs to such as source or destination? Are you also going to have the
option to specify the location of the port? Direction should be split into two
categories, so you could choose local and external underneath incoming and 
outgoing.

I am trying to logically understand how simply removing a port from the allow 
list
would make sure it would always be filtered, but since more then one port can 
be used
in a single connection a port that is included in the allow list could allow a 
port
that is not in the allow list. Please help me to understand how this is not the 
case.

Even if you can specify exactly what direction and location to allow for every
individual port except for those you want to filter, it would still allow ports 
that
are not in the allow list if the connection is also using a port that is in the 
allow
list.

My ideal configuration would be to allow all ports from all ends and 
directions, and
then force filtering on specific ports from the local side of both directions 
(but
all options should be available to allow all variations). The ability to force
filtering for specific ports is the only way I can logically think of to make 
sure
that some ports are always filtered.

It is almost the same concept as the allow IP list ability that allows IP 
addresses
that have been blocked in other lists. But unlike the allow IP list ability that
prevents you from having to manually remove IP addresses from public lists, this
force port filtering ability is not just a convenience, as far as I can tell it 
is a
mathematical requirement to be able to get the functionality that I require.

Please help me to understand if I am missing something, but as far as I can 
tell my
logic is not mistaken.

Original comment by BigRedBr...@gmail.com on 14 Apr 2010 at 8:56

[GoogleCodeExporter]

First off, the thing to remember is that we have two drivers - one for XP/2000, 
and
one for Vista/7 - and that they both work in different ways.  As far as the 
current
discussion goes, the Vista driver will allow us to specify "Allow outgoing port 
80
ONLY", while the XP driver will require "Allow outgoing port 80 and incoming 
port
80".  This is due to the way our XP driver receives notification of network
connections from the OS.  "Outgoing" means source=localip:<anyport>
destination=nonlocalip:<specifiedport>, and "Incoming" means
source=nonlocalip:<anyport> dest=localip:<specifiedport>.

So if you're running on Vista/7 you should have no problems, but if you're on 
XP/2000
this feature may not be the best in the world.  Note that this is how "Allow 
HTTP"
works on XP as well - actually it's worse, as you're allowing all traffic with
source/dest-port of 80/443.  To change this for XP we'd need to rewrite our 
driver
from being a firewall filter-hook driver to an NDIS Intermediate filter-driver, 
which
is expected to change our XP driver-code from 2-300 lines of code to 2-3000 
lines. 
If you (or anyone else reading this) are a Windows driver dev and would like to 
spend
a few weeks working on a driver rewrite, let us know!

The default will be to "block" (meaning "filter against your lists") all ports. 
 If
you want to configure PeerBlock to only filter traffic on one port (say 12345 
for
example purposes) in both directions, you can create an allow-port range of 
"port
0-12344 in both directions" and another allow-port range of "port 12346-65535 
in both
directions" . . . thereby leaving just port 12345 filtered, in both directions.

Many programs can also be configured to *only* send/receive traffic on a 
specific
port or port-range.  Once this feature is available, if you start using it we
strongly recommend auditing your network software to enable these features.  For
example, many people would want to prevent their P2P app from ever 
communicating out
one of those allowed-ports.

Hope that helps clarify the discussion - I really think your needs will be 
addressed
by the current in-progress solution...

Original comment by peerbloc...@gmail.com on 14 Apr 2010 at 12:54

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I see that this conversation has been mirrored on the Forums - that's probably 
the
best place for this discussion, so let's continue on there.  For anyone looking 
to
follow on: http://forums.peerblock.com/read.php?5,3940

Original comment by peerbloc...@gmail.com on 14 Apr 2010 at 9:04

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

The thing that I'd be scared about, is previously it's been discussed among the 
p2p community that "Allowing" HTTP traffic alone (Port 80) is opening a whole 
port on your system - this would allow a bad guy (antip2p, hacker, whatever) to 
sneak through this port, since you have it to "Allow"

NOW....my question is this....would this "Allow port set" feature only allow 
_Outgoing_ traffic?  Or Incoming traffic as well?

Surely, allowing only the Outgoing port use would be the safer 
alternative....cause if you allow BOTH directions, we'll likely see antis and 
hackers using Port 80 among the p2p networks to make it through this "hole".

Original comment by aho...@gmail.com on 24 Jun 2010 at 3:24

[GoogleCodeExporter]

On XP, it has to allow in both directions as the current driver does not 
support both directions.

On Vista and Win7, you get to choose which direction to allow.

Original comment by nightstalkerz on 24 Jun 2010 at 3:51

[GoogleCodeExporter]

Mindful, the machines should really rely on a hardware gateway or hw/sw 
firewall protecting it.  Any NAT'ing device should prevent inbound ports from 
reaching an inside machine.  And a machine still needs to have a service port 
open/listening for an inbound exploit to occur.

For example, most XP clients don't have a web server running. But port 80 is 
still the biggest hole since surfing (outbound) to a hijacked webpage still 
receives the exploit code, so using Peerblock against evil IPs is useful way to 
further block those sites.

But to whitelist port 123 is either because you have no port listening on 123, 
or you trust the service listening does not have security holes.  It's more a 
sysadmin support feature than anything else, allowing us to assume 
responsibility for an analyzed-small risk, but still using Peerblock for its 
intended purpose.

Original comment by bmar...@gmail.com on 24 Jun 2010 at 4:30

[GoogleCodeExporter]

If they include a force filter port list, then no security hole would exist. As 
long as all the programs you intend to be filtered are configured only to use 
those ports that are forced to be filtered no matter what, even if they are 
defined in the port allow list.

Original comment by BigRedBr...@gmail.com on 25 Jun 2010 at 6:56

[GoogleCodeExporter]

BigRedBrent, interesting idea, but what would be the difference of having it on 
the port allow list and also the force filter port list, versus not having it 
on the port allow list at all?  i.e. Couldn't you just not add it to the port 
allow list and get the same result?  I read the posts from Apr 13-14.  I think 
the currently functionality is already to "make absolutely sure that ... ports 
are ALWAYS filtered no matter what".  Can you give an example of needing to add 
something to the "port allow" list, and then still want it filtered?

You mentioned source vs target port, keep in mind the target port is the only 
interest, as it is the one used for routing.  The source port is generated 
randomly on the client IP stack, and must vary based on multiple applications, 
sessions, and even by user on a multi-user OS with a single IP.  Blocking based 
on source port can wreak unplanned havoc when a randomly-generated source port 
inadvertantly matches a blocked target port. You can google "tcp what is source 
port" (no quotes) for better info.

Original comment by bmar...@gmail.com on 25 Jun 2010 at 8:28

[GoogleCodeExporter]

I had thought that on Windows XP both incoming and outgoing ports are opened. I 
have already described in great detail the necessity of this force filtering 
port list. It is the only way to make sure specified ports are always filtered 
no matter what port is set to be allowed. A few have asked the question that 
you have asked.

If you allow lets say port 80, it will then be forced to allow other ports to 
be able to connect to port 80. With a peer to peer application that can be 
limited to specified incoming and outgoing ports, this will break peerblock's 
ability to alleyways filter the p2p traffic.

However if you set all ports to be allowed and then turn around and force only 
those ports that your peer to peer application will use as always filtered, 
then you would have almost no conflicts with peerblock blocking applications 
that you do not want blocked. Because you can choose ports for your p2p 
application to be restricted to (both incoming and outgoing) that are unlikely 
to be used by most other applications that you would prefer not to be filtered 
at all EVER.

I understand what you are saying, but a very large security hole exists without 
the ability to make sure that ports you always want filtered are always forced 
to be filtered (even if only by accident are added to the allow port list).

Original comment by BigRedBr...@gmail.com on 25 Jun 2010 at 9:08

[GoogleCodeExporter]

Your 2nd paragraph, it seems your confusing source and destination ports. 
(Sorry I called them target ports earlier.)  Nothing - gateways, firewalls, etc 
- blocks on source port, because that's not how TCP is designed.  On all TCP 
devices, only the destination port is open because it is the one used for 
initial routing, which is why it's critical.  The source port is only used for 
return traffic from a server once the connection is established.  Blocking on 
source ports would result in desired/expected connections randomly being broken.

Someone correct me if I'm wrong, but Peerblock should only be blocking based on 
destination port, as it is the port used for routing.  If correct, I think a 
backup always-filter function is not necessary, because you're not blocking a 
set of two ports with an if-then logic.

I'm just trying to clarify so this feature doesn't get needlessly delayed.  It 
sounded like it was near ready two betas ago.

Thanks.

Original comment by bmar...@gmail.com on 26 Jun 2010 at 1:04

[GoogleCodeExporter]

On XP we have an issue in that the Windows hooks our driver uses to filter 
network traffic sometimes gives us "flipped" source/destination information - 
so that for example if your machine is communicating via HTTP to a website, 
instead of that connection having a source=your_ip port=random, 
destination=website_ip, port=80 . . . it will instead show up as 
source=website_ip, port=80, desination=your_ip, port=random.  Bizarre, but we 
haven't yet found a way to be able to get Windows to give us the correct 
information.

If we were to throw away our current XP driver (a "filter hook" driver) and 
rewrite it to be an NDIS Intermediate Filter driver, this should work better.  
However that would be pretty major undertaking, as our driver would be bloating 
from 2-300 lines of code to an estimated 2-3000.  So it's unlikely to be 
happening anytime soon, though we'd love to do so at some point since that 
driver would be much better overall.

On Vista+ however, things work as you'd expect.

The feature is nearly ready, but most of the work has been going on in a 
different branch than the one we've been releasing - our "trunk" branch, as 
opposed to the "1.1.x" stabilization branch which will shortly be released as a 
new Stable Release.  After we release PeerBlock 1.1 Stable, we'll generate a 
new 1.1+ Beta Release which will contain this new feature.  

Given how "dangerous" this feature is if you're not careful what you're doing 
(and especially if you don't fully understand the ramifications of what you're 
doing), we've been erring on the side of caution here.  Maybe a bit too much 
so...  Either way, it shouldn't be too much longer until we have a version 
ready for y'all to test, even if we still consider the feature to be at an 
Alpha phase.

Original comment by peerbloc...@gmail.com on 26 Jun 2010 at 1:17

[GoogleCodeExporter]

I am keen to see this feature - but on steroids!

Black and white listed local and/or remote port ranges but on a _per_ list 
basis.

So you could have:
P2P  :   white list -  all protocols
         black list -  local: TCP/UDP (BT server port)   remote: *

Spyware :   black list  - all protocols
            white list  - none

So it would give you fine grained control over the protocol (say to simplify 
just TCP/UDP) and local+remote port range.

Blocked IP addresses could then be over-ridden by the global user generated 
white list as before.

You may not want Apple to see your local Bit Torrent server - but you want to 
be able to sync iTunes, etc.!!

I think you get the idea!!

Thanks for the great software! (BTW I'm on Windows 7 so the XP problems won't 
affect me :-) )

Bob

Original comment by robert.m...@gmail.com on 21 Aug 2010 at 7:41

[GoogleCodeExporter]

Issue 293 has been merged into this issue.

Original comment by nightstalkerz on 7 Sep 2010 at 9:20