I'm not sure if the --kerneltz will work. I noticed a message in log
file...
May 2 10:58:24 pbx user.info kernel: xt_time: kernel timezone is -0000
Which prompted me to google and I found this...
https://dev.openwrt.org/ticket/9657
Lonnie, could you take a look and render an opinion on whether AstLinux is
affected?
Thanks
David
On Thu, May 2, 2013 at 11:04 AM, David Kerr <[email protected]> wrote:
> Lonnie,
> I think I would want to insert (-I LAN_INET_FORWARD_CHAIN) rather than
> append the rule? I think I would want curfew to trigger before any other
> rule. Currently I am controlling access to external DNS servers on this
> chain (so that an internal client cannot bypass my OpenDNS controls) but I
> needed to add a couple of exceptions (e.g. to let kindle devices access
> amazon.com's DNS as those devices were not configurable). But there could
> be other rules that explicitly grant access and I would that a curfew on a
> specific device would trigger first. Of course I suppose there could be a
> scenario where I would want to grant the curfew'd device access to a
> specific service even during curfew hours.
>
> This would be an interesting AIF plugin, input would be a list of devices
> and curfew hours for each. If you go down that path then would it be
> possible to identify device by name rather than mac address... for example
> my DHCP leases includes...
> 192.168.17.20920:c9:d0:5b:50:d8Davids-iPhone-5 2013-05-03 06:42:25 Apple
> Inc
>
> Would there be a way for a plugin to find the mac address from
> "Davids-iPhone-5"
>
> Anyway, for now I am trying this and will let you know in a few days if it
> works !!
>
> iptables -I LAN_INET_FORWARD_CHAIN -m mac
> --mac-source 68:96:7b:03:62:ce -m time --timestart 21:00 --timestop 06:00
> --kerneltz -j REJECT
>
> Chain LAN_INET_FORWARD_CHAIN (1 references)
> target prot opt source destination
>
> REJECT all -- anywhere anywhere MAC
> 68:96:7B:03:62:CE TIME from 21:00:00 to 06:00:00 reject-with
> icmp-port-unreachable
>
> ACCEPT tcp -- 192.168.17.0/24 165-149.amazon.com tcp dpt:domain
>
> ACCEPT tcp -- 192.168.17.7 anywhere tcp dpt:domain
>
> ACCEPT udp -- 192.168.17.0/24 165-149.amazon.com udp dpt:domain
>
> ACCEPT udp -- 192.168.17.7 anywhere udp dpt:domain
>
> ACCEPT icmp -- anywhere anywhere icmp
> echo-request limit: avg 20/sec burst 100
>
> DROP icmp -- anywhere anywhere icmp
> echo-request
>
> ACCEPT all -- anywhere anywhere
>
>
>
>
>
>
>
> On Thu, May 2, 2013 at 9:32 AM, Lonnie Abelbeck <[email protected]
> > wrote:
>
>> +1 to what James suggested.
>>
>> A couple more tips...
>>
>> Use the --kerneltz option to use local timezone, here are the iptables
>> time options:
>> --
>> time match options:
>> --datestart time Start and stop time, to be given in ISO 8601
>> --datestop time (YYYY[-MM[-DD[Thh[:mm[:ss]]]]])
>> --timestart time Start and stop daytime (hh:mm[:ss])
>> --timestop time (between 00:00:00 and 23:59:59)
>> [!] --monthdays value List of days on which to match, separated by
>> comma
>> (Possible days: 1 to 31; defaults to all)
>> [!] --weekdays value List of weekdays on which to match, sep. by comma
>> (Possible days: Mon,Tue,Wed,Thu,Fri,Sat,Sun or 1
>> to 7
>> Defaults to all weekdays.)
>> --kerneltz Work with the kernel timezone instead of UTC
>> --
>> I seem to recall a "--timestart 21:00 --timestop 10:00" did not work and
>> you needed two rules, one ending at 23:59:59, then one starting at
>> 00:00:00, but a quick test suggests this may now work with our current
>> iptables v1.4.17, need to test.
>>
>> In this case you may want to use "-j REJECT" instead of "-j DROP" since
>> it is a known internal device.
>>
>> With AIF in the custom-rules, if you use "iptables -A
>> LAN_INET_FORWARD_CHAIN ..." it will block only outgoing internet traffic
>> (which is probably what you want), though using "iptables -A FORWARD_CHAIN
>> ..." will block any forward.
>>
>> This would be a good addition to AIF as a plugin, coming up with a good
>> general syntax for the time code has stopped me so far.
>>
>> Lonnie
>>
>>
>> On May 1, 2013, at 11:14 PM, James Babiak wrote:
>>
>> > David,
>> >
>> > Interesting idea. I never tried it myself, but I just played around
>> with it and confirmed that it would work. The time has to be converted to
>> UTC, so based on your scenario, and assuming you live in the ET timezone
>> (currently -4 UTC), you could do something like this:
>> >
>> > iptables -I FORWARD -m mac --mac-source AA:BB:CC:DD:EE:FF -m time
>> --timestart 01:00 --timestop 10:00 -j DROP
>> >
>> > Obviously you would need to change the timestart/stop for a different
>> timezone and use the appropriate MAC address. And you could stack rules for
>> additional MACs. I don't believe you can use wildcards for MAC ranges,
>> which might have been a good solution if all the iDevices shared a common
>> OUI, so you would need a rule for each one. The above rule would block
>> access to the Internet, but still allow internal network access (which
>> wouldn't go through the router anyway).
>> >
>> > I imagine the best way to implement this in Astlinux would be to insert
>> the rules into /mnt/kd/arno-iptables-firewall/custom-rules
>> >
>> > --James
>> >
>> > On 05/01/2013 09:32 PM, David Kerr wrote:
>> >> Has anyone used iptables to block internet access for a specified
>> device between specified times. It looks like iptables has a capability to
>> match against time, but before I experiment I thought I would ask if anyone
>> has the necessary commands figured out already.
>> >>
>> >> Basically I want to impose a curfew on internet access for the kids
>> iDevices, say between 9pm and 6am every day. I could identify the device
>> by mac address.
>> >>
>> >> Any suggestion on how to go about this in AstLinux?
>> >>
>> >> Thanks,
>> >> David
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>> Get 100% visibility into your production application - at no cost.
>> Code-level diagnostics for performance bottlenecks with <2% overhead
>> Download for free and get started troubleshooting in minutes.
>> http://p.sf.net/sfu/appdyn_d2d_ap1
>> _______________________________________________
>> Astlinux-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to
>> [email protected].
>>
>
>
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Astlinux-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to
[email protected].