1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

How to block all web access but allow only one or two website for some MAC?

Discussion in 'Tomato Firmware' started by kenyloveg, Jun 24, 2009.

  1. kenyloveg

    kenyloveg LI Guru Member

    Hi, Gurus
    I'd like to disable all web access except site www.abcd.com and www.dcba.com.
    And allow all web sites for MAC address in white list.
    The access restriction page only allow you to block certain site, or as alternative way DNSMASQ can help this?
    Thank you in advance, and have a good day.
     
  2. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Completely untested, but I think the following would work (in your firewall script):
    Code:
    # Allow these hosts unrestricted access
    iptables -A wanout -i `nvram get lan_ifname` -m mac --mac-source <allowed MAC #1> -j ACCEPT
    iptables -A wanout -i `nvram get lan_ifname` -m mac --mac-source <allowed MAC #2> -j ACCEPT
    
    # Allow everyone access to these sites
    iptables -A wanout -i `nvram get lan_ifname` -d www.abcd.com -j ACCEPT
    iptables -A wanout -i `nvram get lan_ifname` -d www.dcba.com -j ACCEPT
    
    # Everything else gets blocked
    iptables -A wanout -i `nvram get lan_ifname` -j DROP
    
    Give that a shot and see if it works for you.
     
  3. kenyloveg

    kenyloveg LI Guru Member

    lol
    SgtPepperKSU, I'd like some guru to help me, not geeks......
    Just kidding, will give it a try.
    Thank you!
     
  4. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    I missed that part of your original post, or I definitely wouldn't have responded :wink:
     
  5. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    For the record, I just added those lines to my firewall script, and it worked like a charm. The MAC addresses listed have unrestricted access, and the other computers are limited to linksysinfo.org and google.com (I'm posted from a limited computer right now :smile:).
     
  6. zoz2000

    zoz2000 Addicted to LI Member

    Hi!
    I would like to use this restriction too but in chosen period of time.
    Is there any solution for this?
     
  7. kenyloveg

    kenyloveg LI Guru Member

    Well, looks like it is not working.
    I'm wondering if the fault is caused by DNSMASQ. Since after i type in www.abcd.com, tomato would resolve it to ip address (if white list MAC once access abcd).
     
  8. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    I don't understand what the problem is. What is it that isn't working for you? You said everyone should be able to access www.abcd.com, and now your indicating that it's not working when one of them can access it (actually all you've said is that they can resolve it - they should have full access to www.abcd.com).

    Everyone would be able to resolve any DNS address to an IP address, but would only be able to access the ones allowed by the rules.

    Right now I have this computer as NOT matching a MAC address in the rules, and the only sites I can get to are the ones I listed. Running nslookup, I can resolve any of them to an IP address, but not contact them.

    EDIT: Since you keep going back to Dnsmasq, I should also point out that no Dnsmasq-based solution will be what I would consider satisfactory, since you cannot guarantee that the client computer will use the router for DNS at all. The only real way to block a site is to block the traffic to that site (which the script I provided does do).
     
  9. kenyloveg

    kenyloveg LI Guru Member

    Hi, SgtPepperKSU
    Well, MAC not in white list still can access any web sites. Or should I block port 80/8080/8000/443/ for MACs not in white list? And how to? Is there anyway to check how these iptables rules affect packages transmission?
    Thank you again.
     
  10. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    You shouldn't have to do anything else. Can you post the output of
    Code:
    service firewall restart
    #attempt to access web from non-matching MAC here
    iptables -vL
    ?

    This will show the packets traversing the firewall chains.

    EDIT: Just to double-check - are you rebooting after adding the firewall script (the service firewall restart will accomplish the same thing without actually rebooting)? I took that for granted and didn't explicitly mention it. The firewall script isn't read until the firewall is restarted.
     
  11. kenyloveg

    kenyloveg LI Guru Member

    here goes the result

    Code:
    Chain INPUT (policy DROP 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination
        0     0 DROP       0    --  br0    any     anywhere             192.168.1.108
        0     0 DROP       0    --  any    any     anywhere             anywhere            state INVALID
      133 10015 ACCEPT     0    --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED
        0     0 ACCEPT     0    --  br0    any     anywhere             anywhere
        1    60 ACCEPT     0    --  lo     any     anywhere             anywhere
        0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp dpt:https
        0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp dpt:1723
        0     0 ACCEPT     gre  --  any    any     anywhere             anywhere
    
    Chain FORWARD (policy DROP 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination
        0     0 ACCEPT     0    --  br0    br0     anywhere             anywhere
        0     0 DROP       0    --  any    any     anywhere             anywhere            state INVALID
        0     0 TCPMSS     tcp  --  any    any     anywhere             anywhere            tcp flags:SYN,RST/SYN tcpmss match 1461:65535 TCPMSS set 1460
        4   160 ACCEPT     0    --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED
        2    80 ACCEPT     0    --  br0    any     anywhere             anywhere
        0     0 wanin      0    --  eth1   any     anywhere             anywhere
        0     0 wanout     0    --  any    eth1    anywhere             anywhere
    
    Chain OUTPUT (policy ACCEPT 93 packets, 10030 bytes)
     pkts bytes target     prot opt in     out     source               destination
    
    Chain wanin (1 references)
     pkts bytes target     prot opt in     out     source               destination
        0     0 ACCEPT     tcp  --  any    any     anywhere             192.168.10.2        tcp dpt:51413
    
    Chain wanout (1 references)
     pkts bytes target     prot opt in     out     source               destination
        0     0 ACCEPT     0    --  br0    any     anywhere             anywhere            MAC 00:22:68:A8:4A:65
        0     0 ACCEPT     0    --  br0    any     anywhere             anywhere            MAC 00:19:5B:EE:C5:C5
        0     0 ACCEPT     0    --  br0    any     anywhere             anywhere            MAC 00:1B:24:B2:5C:7F
        0     0 ACCEPT     0    --  br0    any     anywhere             anywhere            MAC 00:1B:24:AF:77:8A
        0     0 ACCEPT     0    --  br0    any     anywhere             anywhere            MAC 00:EE:EE:13:51:08
        0     0 ACCEPT     0    --  br0    any     anywhere             anywhere            MAC 00:16:E6:9C:F8:B7
        0     0 ACCEPT     0    --  br0    any     anywhere             anywhere            MAC 08:00:1F:B2:5A:2F
        0     0 ACCEPT     0    --  br0    any     anywhere             anywhere            MAC 00:21:70:83:D8:B0
        0     0 ACCEPT     0    --  br0    any     anywhere             anywhere            MAC 00:19:DB:8B:E6:25
        0     0 ACCEPT     0    --  br0    any     anywhere             anywhere            MAC 00:0E:35:E8:57:1A
        0     0 ACCEPT     0    --  br0    any     anywhere             anywhere            MAC 00:19:DB:BF:7A:84
        0     0 ACCEPT     0    --  br0    any     anywhere             61.129.88.131
        0     0 ACCEPT     0    --  br0    any     anywhere             122.70.138.143
        0     0 DROP       0    --  br0    any     anywhere             anywhere
     
  12. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    What version are you using? Your FORWARD chain is very strange. The "ACCEPT 0 -- br0 any anywhere anywhere" line should not be until after "wanout 0 -- any eth1 anywhere anywhere". Your wanout chain is never used for WAN traffic from your LAN. Looking at the source code, this order is hard-coded and hasn't changed since at least 1.21 (the beginning of the code in the git repository), so I'm a bit puzzled why yours is in a different order.

    In any case, we can fix up your FORWARD chain by adding the following, too:
    Code:
    # Fix FORWARD chain order
    iptables -D FORWARD -i `nvram get lan_ifname` -j ACCEPT
    iptables -A FORWARD -i `nvram get lan_ifname` -j ACCEPT
    EDIT: also, what does the output of
    Code:
    cat /etc/iptables
    show? And is there anything else in your firewall script?
     
  13. kenyloveg

    kenyloveg LI Guru Member

    Here you go again

    Code:
    # cat /etc/iptables
    *mangle
    :PREROUTING ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    -A PREROUTING -j CONNMARK --restore-mark
    -A POSTROUTING -j CONNMARK --save-mark
    :IPTRAFFIC_I - [0:0]
    :IPTRAFFIC_O - [0:0]
    -A FORWARD -j IPTRAFFIC_I
    -A POSTROUTING -j IPTRAFFIC_O
    -A IPTRAFFIC_I -i eth1 -p tcp -j ACCOUNT --addr 192.168.10.1/255.255.255.0 --tname tf_tcp_wan1
    -A IPTRAFFIC_I -i eth1 -p udp -j ACCOUNT --addr 192.168.10.1/255.255.255.0 --tname tf_udp_wan1
    -A IPTRAFFIC_I -i eth1 -p icmp -j ACCOUNT --addr 192.168.10.1/255.255.255.0 --tname tf_icmp_wan1
    -A IPTRAFFIC_O -o eth1 -p tcp -j ACCOUNT --addr 192.168.10.1/255.255.255.0 --tname tf_tcp_wan1
    -A IPTRAFFIC_O -o eth1 -p udp -j ACCOUNT --addr 192.168.10.1/255.255.255.0 --tname tf_udp_wan1
    -A IPTRAFFIC_O -o eth1 -p icmp -j ACCOUNT --addr 192.168.10.1/255.255.255.0 --tname tf_icmp_wan1
    COMMIT
    *nat
    :PREROUTING ACCEPT [0:0]
    :POSTROUTING ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    -A PREROUTING -i eth1 -d 192.168.10.1/255.255.255.0 -j DROP
    -A PREROUTING -p icmp -d 192.168.1.108 -j ACCEPT
    -A PREROUTING  -p tcp -m tcp -d 192.168.1.108 --dport 443 -j DROP
    -A PREROUTING  -p tcp -m tcp -d 192.168.1.108 --dport 8080 -j DNAT --to-destination 192.168.1.108:443
    -A PREROUTING -p tcp  -d 192.168.1.108 --dport 51413 -j DNAT --to-destination 192.168.10.2:51413
    -A POSTROUTING -p tcp --dport 51413 -s 192.168.10.1/255.255.255.0 -d 192.168.10.2 -j SNAT --to-source 192.168.10.1
    -A POSTROUTING -o eth1 -j MASQUERADE
    COMMIT
    *filter
    :INPUT DROP [0:0]
    :OUTPUT ACCEPT [0:0]
    -A INPUT -i br0 -d 192.168.1.108 -j DROP
    -A INPUT -m state --state INVALID -j DROP
    -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
    -A INPUT -i br0 -j ACCEPT
    -A INPUT -i lo -j ACCEPT
    -A INPUT -p tcp  -m tcp --dport 443 -j ACCEPT
    -A INPUT -p tcp --dport 1723 -j ACCEPT
    -A INPUT -p 47 -j ACCEPT
    :FORWARD DROP [0:0]
    -A FORWARD -i br0 -o br0 -j ACCEPT
    -A FORWARD -m state --state INVALID -j DROP
    -A FORWARD -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1461: -j TCPMSS --set-mss 1460
    :wanin - [0:0]
    :wanout - [0:0]
    -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
    -A FORWARD -i br0 -j ACCEPT
    -A FORWARD -i eth1 -j wanin
    -A FORWARD -o eth1 -j wanout
    -A wanin  -p tcp -m tcp -d 192.168.10.2 --dport 51413 -j ACCEPT
    COMMIT
    
     
  14. kenyloveg

    kenyloveg LI Guru Member

    Hi,SgtPepperKSU
    It would be nice if you can clarify how rules in firewall script affect rules set in web interface. Which priority is high in Access Restriction and Firewall scripts? For example, I disable all internet access except certain MACs in Access Restriction, while allow certain web site by putting your rules in firewall script.
    Also, will user under br0 interface still can access internet through other protocol like UDP port, 8080 port, 4080 port? I'd like to allow MAC not in white list to use UDP/TCP port 8080/8000/4000/4080 to access outside instant message server.
    And how to not mess all these rules?
    Excuse for my bad English, thanks for your kindly help.
     
  15. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Well, the order in those rules is messed up, too. Again, what Tomato version are you using?

    You shouldn't use Access Restriction along with these firewall rules. Don't have anything to do with any of this in the GUI except in the firewall script.

    Have you tried it with the last set of rules to fix your FORWARD chain?

    The rules I originally provided blocks everything but traffic to those sites, but be we can certainly modify things to allow UDP. To only block TCP traffic, just add a "-p tcp" before the "-j DROP" in the last rule. If you want to allow only certain ports, we can do that, too.
     
  16. kenyloveg

    kenyloveg LI Guru Member

    Hi, SgtPepperKSU
    In order to make the MAC not in white list able to access Port 8000/4080/etc..., firstly block every packages then allow certain ports? Or the other order? Script would restric in which order, the last lines are effect or the up lines are?
    Thank you.
     
  17. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    As soon as a rule is matched with a DROP or ACCEPT, no more rules are run. So, the easiest way is to have rules to allow what you want to be allowed, then have a rule that blocks everything (the rule will only be executed if none of the "allow" rules matched).

    So, if you want to allow everyone unrestricted access to certain destination ports, add the following (substituting protocol and port number as approprate, and repeat as necessary) before the DROP rule:
    Code:
    #Allow everyone access to certain destination ports
    iptables -A wanout -i `nvram get lan_ifname` -p udp --dport 8000 -j ACCEPT
    Did adding the two FORWARD rules get things working for you?

    Also, you keep not replying with your Tomato version. I'm very curious what you're using that is making the FORWARD chain out of order like that.
     
  18. mstombs

    mstombs Network Guru Member

    He also posts in the Chinese DualWAN thread which is a mod (without sourcecode) on 1.23
     
  19. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    That's one of the reasons that makes me so curious. If that's what he's using, then they may have mixed up the FORWARD chain as some dirty hack to get dual WAN working, and fixing it would have a chance of breaking the dual WAN functionality (though, it shouldn't be terribly hard, in that case, to find a proper way to modify the firewall rules to allow it).
     
  20. mstombs

    mstombs Network Guru Member

    Suppose I should have looked at my own test router:-

    Code:
    Chain FORWARD (policy DROP 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination
        0     0 ACCEPT     0    --  br0    br0     0.0.0.0/0            0.0.0.0/0
        0     0 DROP       0    --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID
    26752 1492K TCPMSS     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x06/0x02 tcpmss match 1361:65535 TCPMSS set 1360
    2064K 1665M ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
    16843  951K ACCEPT     0    --  br0    *       0.0.0.0/0            0.0.0.0/0
        0     0 wanin      0    --  vlan1  *       0.0.0.0/0            0.0.0.0/0
        0     0 wanout     0    --  *      vlan1   0.0.0.0/0            0.0.0.0/0
        0     0 upnp       0    --  vlan1  *       0.0.0.0/0            0.0.0.0/0
    So yes it is an issue with

    Code:
    Tomato v1.23.0286
    
    
    BusyBox v1.12.3 (2009-05-24 05:00:28 CST) built-in shell (ash)
    Its broken!
     
  21. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    And 1.23.0286 is DualWAN? I wonder why they would have effectively neutered the wanin/wanout chains...
     
  22. mstombs

    mstombs Network Guru Member

    Yes

    It is now up to version
    but I see no changes mentioned in the change notes

    The main iptables routing mod for dualwan is an ASSIGNOUT chain which is used to tag packets for specific WANs, IPTRAFFIC used for per-IP traffic accounting (Victek also has a version working)

    Code:
    # iptables -nvL -t mangle
    Chain PREROUTING (policy ACCEPT 333 packets, 44442 bytes)
     pkts bytes target     prot opt in     out     source               destination
      281 22307 ASSIGNOUT  0    --  br0    *       0.0.0.0/0            0.0.0.0/0
    
    Chain INPUT (policy ACCEPT 734K packets, 77M bytes)
     pkts bytes target     prot opt in     out     source               destination
    
    Chain FORWARD (policy ACCEPT 2094K packets, 1672M bytes)
     pkts bytes target     prot opt in     out     source               destination
       92 27834 IPTRAFFIC  0    --  *      *       0.0.0.0/0            0.0.0.0/0
    
    Chain OUTPUT (policy ACCEPT 222 packets, 31314 bytes)
     pkts bytes target     prot opt in     out     source               destination
    
    Chain POSTROUTING (policy ACCEPT 2919K packets, 1776M bytes)
     pkts bytes target     prot opt in     out     source               destination
    
    Chain ASSIGNOUT (1 references)
     pkts bytes target     prot opt in     out     source               destination
      275 21945 RETURN     0    --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
        6   362 MARK       0    --  *      *       0.0.0.0/0            0.0.0.0/0           MARK-RETURN set 0x100
    
    Chain IPTRAFFIC (1 references)
     pkts bytes target     prot opt in     out     source               destination
       41 17507 ACCOUNT    tcp  --  vlan1  *       0.0.0.0/0            0.0.0.0/0           ACCOUNT addr 192.168.1.0/24 tname tf_tcp_wan1
        3   228 ACCOUNT    udp  --  vlan1  *       0.0.0.0/0            0.0.0.0/0           ACCOUNT addr 192.168.1.0/24 tname tf_udp_wan1
        0     0 ACCOUNT    icmp --  vlan1  *       0.0.0.0/0            0.0.0.0/0           ACCOUNT addr 192.168.1.0/24 tname tf_icmp_wan1
       45  9871 ACCOUNT    tcp  --  *      vlan1   0.0.0.0/0            0.0.0.0/0           ACCOUNT addr 192.168.1.0/24 tname tf_tcp_wan1
        3   228 ACCOUNT    udp  --  *      vlan1   0.0.0.0/0            0.0.0.0/0           ACCOUNT addr 192.168.1.0/24 tname tf_udp_wan1
        0     0 ACCOUNT    icmp --  *      vlan1   0.0.0.0/0            0.0.0.0/0           ACCOUNT addr 192.168.1.0/24 tname tf_icmp_wan1
    It appears that wanout is just not used in this code.
     
  23. kenyloveg

    kenyloveg LI Guru Member

    Hi, SgtPepperKSU
    Can you tell me if prefix like *.microsoft.com works in iptables?
    Thanks.
     
  24. kenyloveg

    kenyloveg LI Guru Member

    Almost forgot, your scripts works great.
    Thanks for your help.
    And looking foward to your new VPN build, especially IPSEC VPN^_^
     
  25. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    That would not work. iptables doesn't see any URLs, just IP addresses. It is just smart enough when you add rules to do a DNS lookup and add rules for all possible IP addresses for the host given. However, that isn't possible with wildcards ('*').
     
  26. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Oh, good! I was starting to wonder if it killed your internet completely :-P
    No promises on a timeline (or even that it will happen) there. I haven't even started looking into it...
     
  27. asammar

    asammar Network Guru Member

    So, is there a way to apply/disable the rules at specific time slots in the day?

    I manage the network for a small company and they would like to allow only a specific list of sites during the day (while blocking everything else) except during lunch hour where they want to open everything. Access restrictions won't do it because https traffic passes right through.

    Is there a way to do this?
     
  28. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    The iptables extensions that can trigger on time are not compiled into Tomato. So, I'm afraid not.

    It's a shame, too, because I'd sure think that it'd be a simpler way to implement even the access restrictions that are already in the GUI.
     
  29. asammar

    asammar Network Guru Member

    Thank you for the quick reply, SgtPepperKSU.

    I am new at this so please pardon this seemingly not-so-smart question; are these extensions available so they can be compiled with Tomato in a straight forward manner or do they require a lot of tinkering in the original source code and/or kernel code?
     
  30. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    The time module shouldn't be hard to compile in. iptables extensions are added to the iptables source and kernel source by just running Path-O-Matic-ng. I used it to add the ROUTE target to iptables a bit back, and it was pretty easy - once I figured out that the directions are out of date and you need to use the SVN repository (even though it is marked as obsolete), not the CVS (as the directions say) or git (as the repositories page indicates) netfilter repositories.

    EDIT: Looks like the time module should work fine using the git repository. I guess I just had to use the SVN repository for ROUTE since they're kind of trying to wash their hands of it and didn't move support to the newer git repository.
     

Share This Page