James, Yes, you are correct.
I seem to recall in the past that using --localtz working just fine, but now only --kerneltz is supported with the iptables manpage note: "... As such, using --kerneltz is highly discouraged." After some fiddling, this seems to work converting 12:34:56 from localtime to UTC suitable for iptables. $ date -u -d "@$(date -d 12:34:56 '+%s')" '+%H:%M:%S' Of course after a DST change the time rules will be an hour off until the firewall is restarted, better then having to reboot when using --kerneltz I guess. I also tested and if timestart is greater then timestop it properly wraps around 23:59:59-00:00:00 as one would expect. Almost required if doing automatic UTC conversions. David, I'll also work on a custom-rules version and later compare our results, possibly rolling it into a AIF plugin. I can see this as generally useful for a small business, blocking free WiFi during overnight hours, etc. . David, when using custom-rules you should use "iptables -A ..." since custom-rules is called just before plugins are called which is before any rules have been added but after the default chains are created. Indeed if you are testing from the shell you need to use -I then. I think you want to use raw MAC addresses, not names from the lease file. Doesn't changing the name in an iOS device change it's DHCP hostname unless you also include it into DNS Hosts ? We could use data from the STATICHOSTS rc.conf variable defined in /mnt/kd/rc.conf.d/gui.dnshosts.conf I suppose. Lonnie On May 2, 2013, at 10:58 AM, James Babiak wrote: > Yeah, I don't think it will work (as-is), which is why I mentioned doing it > in UTC time. Our version of busybox doesn't offer the '-k' option to set > kernel time either. > > Not sure if there is a simply work around or not. > > --James > > > On Thu, May 2, 2013 at 11:35 AM, David Kerr <[email protected]> wrote: > 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.209 20:c9:d0:5b:50:d8 Davids-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]. > > ------------------------------------------------------------------------------ > 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]. ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 _______________________________________________ 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].
