Posted: Wed Sep 15, 2010 18:56 Post subject: Access restriction for "https"
I need to restrict access to some websites, when I configure these sites in "Access restriction", it works, but works only for HTTP. How can I restrict access for both protocols, HTTP and HTTPS?
Joined: 06 Jun 2006 Posts: 3757 Location: I'm the one on the plate.
Posted: Thu Sep 16, 2010 5:09 Post subject:
feliciano wrote:
https = tcp port 443
...and/or tcp port 8080
Still, access restrictions apply to the URL name, not the protocol or port #. Mebbe the https encryption is thwarting detection by the DD-wrt restiction rules. I'm gonna have to do some testing. Good heads up !
Joined: 06 Jun 2006 Posts: 3757 Location: I'm the one on the plate.
Posted: Thu Sep 16, 2010 18:25 Post subject:
I know IP tables firewall rules can drop packets based on the IP address but I don't know if it can be used to drop packets to a URL. If so then it would solve the problem.
I have been looking into this as well. I believe that "Access Restrictions" does not support https blocking.
That being said it does not mean there isn't a way to do it.
To block both hhtp and https traffic to the specific website do not use "Access Restrictions" but use the iptables command to insert ACL into your router to block the access to the specific website.
1. Login to your Router via webage
2. Navigate to the Administration -> Command Tab
3. Insert the following command:
iptables -I FORWARD -p tcp -d meebo.com -m multiport --dports 80,443 -j REJECT
Basically this command states to block both http and https traffic to the specific website. insted of meebo.com enter the IP address of meebo.com (208.81.191.110)
so the command is:
iptables -I FORWARD -p tcp -d 208.81.191.110 -m multiport --dports 80,443 -j REJECT
4. Click on Run Command
5. Save Firewall.
6. Log off.
You should not be able to access meebo.com any more
I have been looking into this as well. I believe that "Access Restrictions" does not support https blocking.
That being said it does not mean there isn't a way to do it.
To block both hhtp and https traffic to the specific website do not use "Access Restrictions" but use the iptables command to insert ACL into your router to block the access to the specific website.
1. Login to your Router via webage
2. Navigate to the Administration -> Command Tab
3. Insert the following command:
iptables -I FORWARD -p tcp -d meebo.com -m multiport --dports 80,443 -j REJECT
Basically this command states to block both http and https traffic to the specific website. insted of meebo.com enter the IP address of meebo.com (208.81.191.110)
so the command is:
iptables -I FORWARD -p tcp -d 208.81.191.110 -m multiport --dports 80,443 -j REJECT
4. Click on Run Command
5. Save Firewall.
6. Log off.
You should not be able to access meebo.com any more
Good Luck.
Interesting you note this. I have been having exactly the same problem on my e3000 with Build 15453. Tried blocking FB, but https:// gets around the block, either as a URL or a keyword restriction. The iptables idea is a good one, but some sites map to multiple IP addresses, so a single IP address block only works some of the time. I ended up going into the DNSMasq options in Services and entering:
I have the same problem. I was hoping we could get a fix made and publish it. I don't really have that Linux spirit of spending hours on end trying to work around a broken piece of software. I like the traditional UNIX method: fix it in the code.
So we all seem to agree that the default behavior should be to block all ports for a given domain. Also, if the backend software doesn't already do this, I believe we all agree that the filter should work on a domain level. If there is a single connection going to the facebook.com or meebo.com domain, then it should be blocked, no matter what port it uses or what protocol it uses.
Alternatively, a more granular approach would allow you to put in a specified protocol or port number to restrict all access on a specific port or protocol. It would basically give you the level of control that a regular URL gives you.
Who knows how to fix this? I want to help release a minor update to get this fixed.
i have very good suggestion for you .you just put in Google freeware restriction url software than you see what happened this is very usefull. _________________ Crown Moulding MDF HDF Wood Plaster Crown Moulding
Last edited by sakay on Sun Sep 04, 2011 23:17; edited 1 time in total
Posted: Tue Aug 30, 2011 2:17 Post subject: We don't do that here
sakay wrote:
Hey friends,
i have very good suggestion for you .you just put in Google freeware restriction url software than you see what happened this is very usefull.
There are quite a few things wrong with your suggestion. If you are trying to help, then just consider this a learning situation. If you were trying to be rude, then consider this a condemnation.
Freeware is junk. Why? It only works on a single user's computer, for a single platform, and users can easily overcome this software with a little thing called Windows Task Manager, where they can kill the application (I'm making an educated guess that this software only runs on Windows).
DD-WRT is built on Free and Open Source Software (FOSS), which is software that respects the users' rights to modify, improve, and redistribute improvements to the software (optionally with the assurance that no company will steal the software and use it to make billions on your hard work). Freeware, on the other hand, is like a whore. It comes when you're feeling desperate, and then it leaves in the morning. You don't get to improve its life-style or educate it. It's dead weight.
Also, the desired solution (the topic of this thread) is to be implemented on the router device, so that a network administrator can adjust restrictions without interfering with the target's use of their personal computer. Another IT consideration is that router modifications are transparent to the end users, don't require costly interruptions in work, etc.
It adds instructions on how to use cron together with iptables to better emulate what Access Restrictions does (and what it likely does under the covers). Though why it can't just be the default behavior for Access Restrictions, I'm not sure.
