Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement: Block by port, not applications #30

Closed
GoogleCodeExporter opened this issue Dec 17, 2015 · 13 comments
Closed

Enhancement: Block by port, not applications #30

GoogleCodeExporter opened this issue Dec 17, 2015 · 13 comments

Comments

@GoogleCodeExporter
Copy link

Like typical firewalls, allow blocking by port range, TCP/UDP instead of 
application.

Sometimes, I want to block a service.

Original issue reported on code.google.com by arthur.l...@gmail.com on 25 Jun 2010 at 11:33

@GoogleCodeExporter
Copy link
Author

Original comment by rodrigo...@gmail.com on 7 Jul 2010 at 12:51

  • Added labels: Type-Enhancement
  • Removed labels: Type-Defect

@GoogleCodeExporter
Copy link
Author

Should be pretty straightforward to implement as iptables has options for that.
The only problem I see is how to interpret such rules when overlapping with 
rules referring to applications. 
BTW, it's a bit unfortunate that there are several cases where several 
applications share the same ID.

Original comment by DvO...@gmail.com on 14 Aug 2010 at 11:59

@GoogleCodeExporter
Copy link
Author

allow users to set port rules first or application rules first.

Then there is no conflict

Original comment by arthur.l...@gmail.com on 15 Aug 2010 at 4:19

@GoogleCodeExporter
Copy link
Author

That would be great. Some providers offer free traffic on some ports only. For 
example, Bouygues Telecom (France) provides all their users with free traffic 
on port 993, but charges for traffic on port 80 or 25.

Original comment by guillaum...@gmail.com on 22 Aug 2010 at 3:18

@GoogleCodeExporter
Copy link
Author

This would be nice to have. Currently droidwall seems to block inbound ssh.

Original comment by chris.ku...@gmail.com on 17 Nov 2010 at 11:43

@GoogleCodeExporter
Copy link
Author

Hello all, I have just added a functionality called "Custom Script" on r210.
This will be officially released on the next version (DroidWall 1.5.3).

I know that this is more like a work-around rather than a real fix, but you can 
block by ports using custom scripts. This way we can keep a very simple user 
interface for non-technical users, but full power to advanced users.

I will add more information about CustomScripts in the wiki.

Original comment by rodrigo...@gmail.com on 23 Sep 2011 at 7:05

  • Changed state: Fixed

@GoogleCodeExporter
Copy link
Author

Rodrigo, your app is really great. CustomScripts make it even much more 
powerful.

Chris, DroidWall does not affect inbound connections at all.
Yet for blocking, e.g., ssh one could use the following rule:

$IPTABLES -A INPUT -p TCP --destination-port 22 -j DROP

Original comment by DvO...@gmail.com on 31 Jan 2012 at 7:28

@GoogleCodeExporter
Copy link
Author

I'm loving DroidWall. However, I've found the only way I can use DroidWall and 
sshDroid (sshd server on phone) simultaneously is to have DroidWall allow all 
root apps (presumably because it does all it's blocking by UID). I believe if I 
were more familiar with writing iptable rules, I could insert a rule before the 
default block to allow sshd in and out based on port # or some other criteria, 
and then still have all other root processes blocked. 

Can anyone with more knowledge advise me on a custom script I could run to 
achieve this? The linux man page for iptables just about gave me an aneurysm.

Original comment by thugdrum...@verizon.net on 8 Feb 2012 at 8:17

@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

For specifically allowing sshd, assuming that it listens on port 22, use this:
$IPTABLES -I OUTPUT -j ACCEPT -m owner --uid-owner 0 -p tcp --source-port 22

Original comment by DvO...@gmail.com on 8 Feb 2012 at 10:26

@GoogleCodeExporter
Copy link
Author

Thanks DvO! It looks obvious once someone's spelled it out for me. I'm not on a 
wifi network where I feel comfortable enabling sshd (paranoia being the better 
part of security), so I'll have to try it later.

BTW, I've been using the iptables command on the phone to list the current 
rules. Before I came across this thread, I hadn't noticed the CustomScripts 
option. I somehow found the executable iptables_armv5 in the 
/data/data/com.googlecode.droidwall.free/app_bin/ directory, and was running it 
from within Terminal Emulator. 

Original comment by thugdrum...@verizon.net on 9 Feb 2012 at 1:14

@GoogleCodeExporter
Copy link
Author

You can further restrict the use of ssh by allowing only certain machines to 
connect.
Assuming that your PC at home has local IP address 192.168.2.101, 
you may add "--destination 192.168.2.101" to the options.

One might add also some security by obscurity, using a different port than 22.

To block every process that is not an app (except for the kernel), 
you may add /after/ your rule a second one:
iptables -I OUTPUT 2 -j DROP -m owner --uid-owner 0:9999

BTW, using "-I OUTPUT" gives the rules top priority, and they will not be 
cleared by DroidWall. If you use instead as a custom script:

$IPTABLES -I droidwall -j ACCEPT -m owner --uid-owner 0 -p tcp --source-port 22 
--destination 192.168.2.101
$IPTABLES -I droidwall 2 -j droidwall-reject -m owner --uid-owner 0:9999

these rules will be automatically removed when disabling DroidWall. To be on 
the safe side, you may want to add the following as custom /shutdown/ script 
such that every process that is not an app (except for the kernel) will still 
be blocked:

$IPTABLES -I droidwall -j DROP -m owner --uid-owner 0:9999

Original comment by DvO...@gmail.com on 9 Feb 2012 at 7:42

@GoogleCodeExporter
Copy link
Author

Worked like a charm! I also put in the non-app block as well as the shutdown 
script. (I'm guessing Android reserves UIDs 0-9999 for non apps, yes?) Thanks!

Original comment by thugdrum...@verizon.net on 11 Feb 2012 at 5:21

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant