Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #170720 > unrolled thread

Limiting internet access by time

Back to article view | Back to linux.debian.user

Contents

  Limiting internet access by time Mark Fletcher <mark27q1@gmail.com> - 2016-08-05 02:10 +0200
    Re: Limiting internet access by time Lars Noodén <lars.nooden@gmail.com> - 2016-08-05 09:30 +0200
      Re: Limiting internet access by time Mark Fletcher <mark27q1@gmail.com> - 2016-08-05 17:40 +0200
    Re: Limiting internet access by time Brian <ad44@cityscape.co.uk> - 2016-08-05 12:50 +0200
      Re: Limiting internet access by time Lisi Reisz <lisi.reisz@gmail.com> - 2016-08-05 13:10 +0200
        Re: Limiting internet access by time Brian <ad44@cityscape.co.uk> - 2016-08-05 16:10 +0200
          Re: Limiting internet access by time David Wright <deblis@lionunicorn.co.uk> - 2016-08-05 18:00 +0200
          Re: Limiting internet access by time Mark Fletcher <mark27q1@gmail.com> - 2016-08-05 18:00 +0200
            Re: Limiting internet access by time Dan Ritter <dsr@randomstring.org> - 2016-08-05 19:50 +0200
              Re: Limiting internet access by time Brian <ad44@cityscape.co.uk> - 2016-08-05 21:10 +0200
                Re: Limiting internet access by time Brian <ad44@cityscape.co.uk> - 2016-08-06 03:40 +0200
              Re: Limiting internet access by time Mark Fletcher <mark27q1@gmail.com> - 2016-08-06 07:30 +0200
                Re: Limiting internet access by time Dan Ritter <dsr@randomstring.org> - 2016-08-07 03:00 +0200
                  Re: Limiting internet access by time Mark Fletcher <mark27q1@gmail.com> - 2016-08-07 05:40 +0200
                    Re: Limiting internet access by time Brian <ad44@cityscape.co.uk> - 2016-08-07 20:20 +0200
                      Re: Limiting internet access by time Mark Fletcher <mark27q1@gmail.com> - 2016-08-08 02:10 +0200
                    Re: Limiting internet access by time Dan Ritter <dsr@randomstring.org> - 2016-08-09 19:30 +0200
                      Re: Limiting internet access by time Stefan Monnier <monnier@iro.umontreal.ca> - 2016-08-09 21:20 +0200
                        Re: Limiting internet access by time Dan Ritter <dsr@randomstring.org> - 2016-08-10 15:40 +0200
                          Re: Limiting internet access by time Stefan Monnier <monnier@iro.umontreal.ca> - 2016-08-10 17:00 +0200
                            Re: Limiting internet access by time Dan Ritter <dsr@randomstring.org> - 2016-08-10 18:10 +0200
                              Re: Limiting internet access by time Stefan Monnier <monnier@iro.umontreal.ca> - 2016-08-10 22:40 +0200
            Re: Limiting internet access by time Brian <ad44@cityscape.co.uk> - 2016-08-05 20:50 +0200
              Re: Limiting internet access by time Mark Fletcher <mark27q1@gmail.com> - 2016-08-06 07:30 +0200
        Re: Limiting internet access by time Mark Fletcher <mark27q1@gmail.com> - 2016-08-05 16:30 +0200
          Re: Limiting internet access by time pv29@gatech.edu - 2016-08-08 01:10 +0200
            Re: Limiting internet access by time Curt <curty@free.fr> - 2016-08-08 09:00 +0200
              Re: Limiting internet access by time pascalv@sdf.org - 2016-08-08 10:30 +0200
                Re: Limiting internet access by time Karol Augustin <karol@augustin.pl> - 2016-08-08 12:00 +0200

Page 1 of 2  [1] 2  Next page →

#170720 — Limiting internet access by time

[Multipart message — attachments visible in raw view] — view raw

On a stretch box I have, I want to allow access to the Internet between the
hours of 9am and 9pm and block it between 9pm and 9am. Ideally allow local
network access throughout but block Internet access between 9pm and 9am,
but I can accept total network blockage in the off times if necessary.

The machine is used as a desktop, so it is not up all the time. It might be
brought up before 9am, in which case it should come up blocked and unblock
at 9am, or it may be brought up after 9am, in which case it should come up
unblocked and block if it is still up at 9pm. Time precision isn't
important.

An ideal solution would allow dhcp updates, ntp etc to continue but block
any normal user access eg web browsing etc.

I've got a solution in mind and would like to see if the community has any
better ideas.

I'm thinking of installing iptables, creating an iptables script that
blocks Internet access (not local addresses) except ntp and dhcp, and
another to open everything up again, and using a systemd service that runs
a script to check the time and run the appropriate iptables script. That
service then gets linked in multi-user.wants to get run at startup. Then
cron jobs can take care of the 9am and 9pm switch overs, calling the same
scripts as appropriate.

Is there a better way to do this?

Mark

[toc] | [next] | [standalone]

#170725

On 08/05/2016 03:02 AM, Mark Fletcher wrote:
> On a stretch box I have, I want to allow access to the Internet between the
> hours of 9am and 9pm and block it between 9pm and 9am. Ideally allow local
> network access throughout but block Internet access between 9pm and 9am,
> but I can accept total network blockage in the off times if necessary.
[snip]

iptables has some match extensions that will work with UTC time,
specifically the extensions --timestart and --timestop  Using those you
should be able to make rules that operate all the time but block traffic
during the specified hours.  The only issues there are the UTC itself
and, maybe, problems with standard time versus daylight savings time
locally.

It can also be modified to vary for certain days of the week using
--weekdays

See the manual page for iptables-extensions(8) for the details on those.

Regards,
Lars

[toc] | [prev] | [next] | [standalone]

#170741

[Multipart message — attachments visible in raw view] — view raw

On Fri, Aug 5, 2016 at 4:26 PM Lars Noodén <lars.nooden@gmail.com> wrote:

>
> iptables has some match extensions that will work with UTC time,
> specifically the extensions --timestart and --timestop  Using those you
> should be able to make rules that operate all the time but block traffic
> during the specified hours.  The only issues there are the UTC itself
> and, maybe, problems with standard time versus daylight savings time
> locally.
>
> It can also be modified to vary for certain days of the week using
> --weekdays
>
> See the manual page for iptables-extensions(8) for the details on those.
>
> Regards,
> Lars
>
>
Thanks for this suggestion Lars. I will look into iptables-extensions.

Mark

[toc] | [prev] | [next] | [standalone]

#170728

On Fri 05 Aug 2016 at 00:02:40 +0000, Mark Fletcher wrote:

> On a stretch box I have, I want to allow access to the Internet between the
> hours of 9am and 9pm and block it between 9pm and 9am. Ideally allow local
> network access throughout but block Internet access between 9pm and 9am,
> but I can accept total network blockage in the off times if necessary.

Your ideal is achievable.

  ip route del default via <gateway_IP>

Plus a cron job.

> The machine is used as a desktop, so it is not up all the time. It might be
> brought up before 9am, in which case it should come up blocked and unblock
> at 9am, or it may be brought up after 9am, in which case it should come up
> unblocked and block if it is still up at 9pm. Time precision isn't
> important.

If it came up unblocked before 9am cron could see to it that blocking
happens.

> An ideal solution would allow dhcp updates, ntp etc to continue but block
> any normal user access eg web browsing etc.

How essential is this? cron could

  ip route add default via <gateway_IP>

at specific times between 9pm and 9am and then remove the default route.
If the machine isn't up all the time it seems unnecessary to me.

[toc] | [prev] | [next] | [standalone]

#170729

On Friday 05 August 2016 11:40:28 Brian wrote:
> On Fri 05 Aug 2016 at 00:02:40 +0000, Mark Fletcher wrote:
> > On a stretch box I have, I want to allow access to the Internet between
> > the hours of 9am and 9pm and block it between 9pm and 9am. Ideally allow
> > local network access throughout but block Internet access between 9pm and
> > 9am, but I can accept total network blockage in the off times if
> > necessary.
>
> Your ideal is achievable.
>
>   ip route del default via <gateway_IP>
>
> Plus a cron job.
>
> > The machine is used as a desktop, so it is not up all the time. It might
> > be brought up before 9am, in which case it should come up blocked and
> > unblock at 9am, or it may be brought up after 9am, in which case it
> > should come up unblocked and block if it is still up at 9pm. Time
> > precision isn't important.
>
> If it came up unblocked before 9am cron could see to it that blocking
> happens.
>
> > An ideal solution would allow dhcp updates, ntp etc to continue but block
> > any normal user access eg web browsing etc.
>
> How essential is this? cron could
>
>   ip route add default via <gateway_IP>
>
> at specific times between 9pm and 9am and then remove the default route.
> If the machine isn't up all the time it seems unnecessary to me.

Perhaps he wants to stop his children/grandchildren/house guests surfing the 
web at 3:00 am.  

Lisi

[toc] | [prev] | [next] | [standalone]

#170734

On Fri 05 Aug 2016 at 12:00:28 +0100, Lisi Reisz wrote:

> On Friday 05 August 2016 11:40:28 Brian wrote:
> >
> > How essential is this? cron could
> >
> >   ip route add default via <gateway_IP>
> >
> > at specific times between 9pm and 9am and then remove the default route.
> > If the machine isn't up all the time it seems unnecessary to me.
> 
> Perhaps he wants to stop his children/grandchildren/house guests surfing the 
> web at 3:00 am. 

Possibly.

Let us look at this from a different angle. If the machine is given a
fixed address it negates the need for dhcp checking, If, additionally,
no gateway to the internet is specified there would be no access to the
internet at any time.

For an always-on machine cron jobs could switch routing at 9am and 9pm.
If the machine was rebooted after 9pm there would be no internet. A
reboot after 9am presents a problem. This could be solved by having cron
check every five minutes between 9am and 9pm and providing a gateway to
the internet.

Sticking with the idea of using a systemd service file, the script it
runs would check the time and alter the routing table when necessary.
Neither cron nor iptables need come into the picture.

[toc] | [prev] | [next] | [standalone]

#170744

On Fri 05 Aug 2016 at 15:03:47 (+0100), Brian wrote:
> On Fri 05 Aug 2016 at 12:00:28 +0100, Lisi Reisz wrote:
> 
> > On Friday 05 August 2016 11:40:28 Brian wrote:
> > >
> > > How essential is this? cron could
> > >
> > >   ip route add default via <gateway_IP>
> > >
> > > at specific times between 9pm and 9am and then remove the default route.
> > > If the machine isn't up all the time it seems unnecessary to me.
> > 
> > Perhaps he wants to stop his children/grandchildren/house guests surfing the 
> > web at 3:00 am. 
> 
> Possibly.
> 
> Let us look at this from a different angle. If the machine is given a
> fixed address it negates the need for dhcp checking, If, additionally,
> no gateway to the internet is specified there would be no access to the
> internet at any time.
> 
> For an always-on machine cron jobs could switch routing at 9am and 9pm.
> If the machine was rebooted after 9pm there would be no internet. A
> reboot after 9am presents a problem. This could be solved by having cron
> check every five minutes between 9am and 9pm and providing a gateway to
> the internet.

No need to wait for five minutes; cron has a @reboot parameter, eg,

@reboot /sbin/kbdrate -r 8 -d 500 -s

slows down the keyboard repeat key so that Cindy-Sue can login more easily.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#170745

[Multipart message — attachments visible in raw view] — view raw

On Fri, Aug 5, 2016 at 11:04 PM Brian <ad44@cityscape.co.uk> wrote:

> On Fri 05 Aug 2016 at 12:00:28 +0100, Lisi Reisz wrote:
>
> > On Friday 05 August 2016 11:40:28 Brian wrote:
>
> Let us look at this from a different angle. If the machine is given a
> fixed address it negates the need for dhcp checking, If, additionally,
> no gateway to the internet is specified there would be no access to the
> internet at any time.
>
> For an always-on machine cron jobs could switch routing at 9am and 9pm.
> If the machine was rebooted after 9pm there would be no internet. A
> reboot after 9am presents a problem. This could be solved by having cron
> check every five minutes between 9am and 9pm and providing a gateway to
> the internet.
>
> Sticking with the idea of using a systemd service file, the script it
> runs would check the time and alter the routing table when necessary.
> Neither cron nor iptables need come into the picture.
>
>
Thanks Brian. My thinking was that although this machine won't be on all
the time, it will be started and stopped at unpredictable times. I wanted
to have a situation where if it is brought up during allowed hours, the
internet works. If it is brought up during not-allowed hours, it doesn't,
until 9am arrives, at which point it starts working. So if my son gets out
of bed at 3am and fires up the computer, he gets nowhere (at least until he
figures out how to hack into my own machine and run an ssh session with X
forwarding... but if he figures that out without my help I'm almost
inclined to reward him by turning a blind eye :-) )

Similarly, if he is surfing away on it at 9pm, well by then he is supposed
to be at least in the bath if not in bed, so the computer's internet
connection sets an example by going to sleep...

If he leaves it on, I want it to connect and disconnect automatically at
the appropriate times, and if he doesn't, I want it to come up in the right
state. If I leave a hole in this that can be exploited without strong
technical skills, I'm confident he'll find it...

I could give the box a fixed IP but I have always used DHCP on my local
network and don't want to disturb my habits more than necessary for this.
Also this would get rid of the need for DHCP but wouldn't get rid of NTP
calls, and then I'd get them vomiting all over the logs when they fail to
connect. Not a big problem, certainly, but an elegant solution would avoid
it.

I didn't mention earlier, and I'm not sure if it is relevant, but the
computer connects via WiFi to my access point, which is also my network's
internet gateway -- with an LFS box between it and the cable modem as a
dedicated firewall. I don't trust the non-free firewall in the AP, although
I have left it on. The rest of my network is not to be subject to this 9pm
curfew. And I would ideally like connectivity between this machine and the
rest of my local network to remain even when the internet is denied to this
machine, so I can do remote maintenance when he's not using the machine,
for example. If I monkey around with the default routing as you are
suggesting, does that have any negative implications for connectivity to
the rest of my local network? Finally, I am afraid I did not understand the
point you made about how cron can be avoided. If the machine's up when 9pm
arrives, I want internet connectivity to die so I can prise him off the
computer and get him to bed. In your idea, how can I make that happen
without a cron job?

Thanks

Mark

[toc] | [prev] | [next] | [standalone]

#170749

On Fri, Aug 05, 2016 at 03:49:28PM +0000, Mark Fletcher wrote:
> On Fri, Aug 5, 2016 at 11:04 PM Brian <ad44@cityscape.co.uk> wrote:
> 
> I didn't mention earlier, and I'm not sure if it is relevant, but the
> computer connects via WiFi to my access point, which is also my network's
> internet gateway -- with an LFS box between it and the cable modem as a
> dedicated firewall. I don't trust the non-free firewall in the AP, although
> I have left it on. The rest of my network is not to be subject to this 9pm
> curfew. And I would ideally like connectivity between this machine and the
> rest of my local network to remain even when the internet is denied to this
> machine, so I can do remote maintenance when he's not using the machine,
> for example.


I have a new suggestion, based on this.

Do all the filtering on your LFS box.

Match your kid's machine by MAC address.

Write two tiny scripts:

#!/bin/sh
iptables -D FORWARD -m mac --mac-source 58:63:1a:af:71:72 -j DROP


#!/bin/sh
iptables -I FORWARD -m mac --mac-source 58:63:1a:af:71:72 -j DROP

(substituting in the appropriate MAC address for the machine, of
course)

and run the first one at 9 PM to disable internet access, and
run the second one at 8 AM or whatever to re-enable it. Cron is
your friend.

-dsr-

[toc] | [prev] | [next] | [standalone]

#170754

On Fri 05 Aug 2016 at 13:48:54 -0400, Dan Ritter wrote:

> On Fri, Aug 05, 2016 at 03:49:28PM +0000, Mark Fletcher wrote:
> > On Fri, Aug 5, 2016 at 11:04 PM Brian <ad44@cityscape.co.uk> wrote:
> > 
> > I didn't mention earlier, and I'm not sure if it is relevant, but the
> > computer connects via WiFi to my access point, which is also my network's
> > internet gateway -- with an LFS box between it and the cable modem as a
> > dedicated firewall. I don't trust the non-free firewall in the AP, although
> > I have left it on. The rest of my network is not to be subject to this 9pm
> > curfew. And I would ideally like connectivity between this machine and the
> > rest of my local network to remain even when the internet is denied to this
> > machine, so I can do remote maintenance when he's not using the machine,
> > for example.
> 
> 
> I have a new suggestion, based on this.
> 
> Do all the filtering on your LFS box.
> 
> Match your kid's machine by MAC address.
> 
> Write two tiny scripts:
> 
> #!/bin/sh
> iptables -D FORWARD -m mac --mac-source 58:63:1a:af:71:72 -j DROP
> 
> 
> #!/bin/sh
> iptables -I FORWARD -m mac --mac-source 58:63:1a:af:71:72 -j DROP
> 
> (substituting in the appropriate MAC address for the machine, of
> course)
> 
> and run the first one at 9 PM to disable internet access, and
> run the second one at 8 AM or whatever to re-enable it. Cron is
> your friend.

For this particular situation (LFS=Linux From Scratch?) this does appear
to be the easiest (less work) and most obvious solution.

[toc] | [prev] | [next] | [standalone]

#170769

On Fri 05 Aug 2016 at 20:02:58 +0100, Brian wrote:

> On Fri 05 Aug 2016 at 13:48:54 -0400, Dan Ritter wrote:
> 
> > I have a new suggestion, based on this.
> > 
> > Do all the filtering on your LFS box.
> > 
> > Match your kid's machine by MAC address.
> > 
> > Write two tiny scripts:
> > 
> > #!/bin/sh
> > iptables -D FORWARD -m mac --mac-source 58:63:1a:af:71:72 -j DROP
> > 
> > 
> > #!/bin/sh
> > iptables -I FORWARD -m mac --mac-source 58:63:1a:af:71:72 -j DROP
> > 
> > (substituting in the appropriate MAC address for the machine, of
> > course)
> > 
> > and run the first one at 9 PM to disable internet access, and
> > run the second one at 8 AM or whatever to re-enable it. Cron is
> > your friend.
> 
> For this particular situation (LFS=Linux From Scratch?) this does appear
> to be the easiest (less work) and most obvious solution.

But not foolproof. As was said earlier

 > If I leave a hole in this that can be exploited without strong                                                      
 > technical skills, I'm confident he'll find it...

Wicd and network-manager are popular, so one of them could be on the
system. Someone in possession of a USB wireless adapter can plug it in
or use it to replace the existing one. Either of the softwares can be
used to configure the new interface. This interface has a MAC address
unknown to the LFS box. The interface name can be found with 'ip link'
so a default route can still be controlled.

No wicd and network-manager on the machine? No problem; a USB stick with
Debian on it and a reboot solves that. Plus it could be used for MAC
spoofing. :)

[toc] | [prev] | [next] | [standalone]

#170771

[Multipart message — attachments visible in raw view] — view raw

On Sat, Aug 6, 2016 at 2:48 AM Dan Ritter <dsr@randomstring.org> wrote:

> On Fri, Aug 05, 2016 at 03:49:28PM +0000, Mark Fletcher wrote:
> > On Fri, Aug 5, 2016 at 11:04 PM Brian <ad44@cityscape.co.uk> wrote:
> >
> > I didn't mention earlier, and I'm not sure if it is relevant, but the
> > computer connects via WiFi to my access point, which is also my network's
> > internet gateway -- with an LFS box between it and the cable modem as a
> > dedicated firewall. I don't trust the non-free firewall in the AP,
> although
> > I have left it on. The rest of my network is not to be subject to this
> 9pm
> > curfew. And I would ideally like connectivity between this machine and
> the
> > rest of my local network to remain even when the internet is denied to
> this
> > machine, so I can do remote maintenance when he's not using the machine,
> > for example.
>
>
> I have a new suggestion, based on this.
>
> Do all the filtering on your LFS box.
>
> Match your kid's machine by MAC address.
>
> Write two tiny scripts:
>
> #!/bin/sh
> iptables -D FORWARD -m mac --mac-source 58:63:1a:af:71:72 -j DROP
>
>
> #!/bin/sh
> iptables -I FORWARD -m mac --mac-source 58:63:1a:af:71:72 -j DROP
>
> (substituting in the appropriate MAC address for the machine, of
> course)
>
> and run the first one at 9 PM to disable internet access, and
> run the second one at 8 AM or whatever to re-enable it. Cron is
> your friend.
>
> The LFS box (and yes that is Linux From Scratch, all my other "real"
computers are Debian) sits between my AP (wireless & wired) and the cable
modem ie the wilds of the Internet. Used to be that the AP was plugged
straight into the cable modem, but about 6 months ago or so I set up this
LFS box using an ASUS mini PC, about 10% out of concern for what weaknesses
my AP's firewall might have that I didn't and never would know about, and
90% just to see if I could. The WAN port of the AP goes into one interface
of the firewall, the other goes to the cable modem. All my computers other
than the firewall itself are connected, wired or wireless, to the AP. The
wireless card built into the firewall box is disabled.

Since the AP is doing NAT, as I believe is normal for such a device that
thinks it is the last line of defence between the network and the Internet,
I am not sure that the LFS firewall machine will be able to see the MAC
addresses of the computers on my LAN. I just tried to do an experiment
involving logging in iptables on the firewall, but the logged information
doesn't seem to include MAC address so I couldn't check.

If in fact, I can expect the firewall to be able to see source computer LAN
mac addresses in this configuration, that has all sorts of other positive
implications which I would get excited about. I'd just assumed it wouldn't
be possible due to the layer of indirection provided by the AP.

Mark

[toc] | [prev] | [next] | [standalone]

#170795

On Sat, Aug 06, 2016 at 04:56:06AM +0000, Mark Fletcher wrote:
> On Sat, Aug 6, 2016 at 2:48 AM Dan Ritter <dsr@randomstring.org> wrote:
> 
> > On Fri, Aug 05, 2016 at 03:49:28PM +0000, Mark Fletcher wrote:
> > > On Fri, Aug 5, 2016 at 11:04 PM Brian <ad44@cityscape.co.uk> wrote:
> > >
> > > I didn't mention earlier, and I'm not sure if it is relevant, but the
> > > computer connects via WiFi to my access point, which is also my network's
> > > internet gateway -- with an LFS box between it and the cable modem as a
> > > dedicated firewall. I don't trust the non-free firewall in the AP,
> > although
> > > I have left it on. The rest of my network is not to be subject to this
> > 9pm
> > > curfew. And I would ideally like connectivity between this machine and
> > the
> > > rest of my local network to remain even when the internet is denied to
> > this
> > > machine, so I can do remote maintenance when he's not using the machine,
> > > for example.
> >
> >
> > I have a new suggestion, based on this.
> >
> > Do all the filtering on your LFS box.
> >
> > Match your kid's machine by MAC address.
> >
> > Write two tiny scripts:
> >
> > #!/bin/sh
> > iptables -D FORWARD -m mac --mac-source 58:63:1a:af:71:72 -j DROP
> >
> >
> > #!/bin/sh
> > iptables -I FORWARD -m mac --mac-source 58:63:1a:af:71:72 -j DROP
> >
> > (substituting in the appropriate MAC address for the machine, of
> > course)
> >
> > and run the first one at 9 PM to disable internet access, and
> > run the second one at 8 AM or whatever to re-enable it. Cron is
> > your friend.
> >
> > The LFS box (and yes that is Linux From Scratch, all my other "real"
> computers are Debian) sits between my AP (wireless & wired) and the cable
> modem ie the wilds of the Internet. Used to be that the AP was plugged
> straight into the cable modem, but about 6 months ago or so I set up this
> LFS box using an ASUS mini PC, about 10% out of concern for what weaknesses
> my AP's firewall might have that I didn't and never would know about, and
> 90% just to see if I could. The WAN port of the AP goes into one interface
> of the firewall, the other goes to the cable modem. All my computers other
> than the firewall itself are connected, wired or wireless, to the AP. The
> wireless card built into the firewall box is disabled.
> 
> Since the AP is doing NAT, as I believe is normal for such a device that
> thinks it is the last line of defence between the network and the Internet,
> I am not sure that the LFS firewall machine will be able to see the MAC
> addresses of the computers on my LAN. I just tried to do an experiment
> involving logging in iptables on the firewall, but the logged information
> doesn't seem to include MAC address so I couldn't check.
> 
> If in fact, I can expect the firewall to be able to see source computer LAN
> mac addresses in this configuration, that has all sorts of other positive
> implications which I would get excited about. I'd just assumed it wouldn't
> be possible due to the layer of indirection provided by the AP.
> 

Got it. You can change that by removing NAT from the AP. For
instance, plug your switch into a LAN port instead of the WAN
port:

cable modem -- LFS -- switch ---- (LAN port) AP ---- wifi client
                             |                  \___ wifi client
                             |
                             ---- other wired machines

You can either set up a flat addressing space, perhaps with a
range reserved for DHCP machines and the rest doing static, or
you can route at the LFS machine and the AP. I would recommend
a flat space unless you have a really large (>25) number of
machines. That's what I do.

I also have my equivalent of your LFS running dhcpd for the
whole network, rather than having another configuration point
on the AP to worry about. All filtering can be done there.

-dsr-

[toc] | [prev] | [next] | [standalone]

#170797

[Multipart message — attachments visible in raw view] — view raw

On Sun, Aug 7, 2016 at 9:57 AM Dan Ritter <dsr@randomstring.org> wrote:

> On Sat, Aug 06, 2016 at 04:56:06AM +0000, Mark Fletcher wrote:
> > On Sat, Aug 6, 2016 at 2:48 AM Dan Ritter <dsr@randomstring.org> wrote:
>
> Got it. You can change that by removing NAT from the AP. For
> instance, plug your switch into a LAN port instead of the WAN
> port:
>
> cable modem -- LFS -- switch ---- (LAN port) AP ---- wifi client
>                              |                  \___ wifi client
>                              |
>                              ---- other wired machines
>
> You can either set up a flat addressing space, perhaps with a
> range reserved for DHCP machines and the rest doing static, or
> you can route at the LFS machine and the AP. I would recommend
> a flat space unless you have a really large (>25) number of
> machines. That's what I do.
>
> I also have my equivalent of your LFS running dhcpd for the
> whole network, rather than having another configuration point
> on the AP to worry about. All filtering can be done there.
>
> -dsr-
>

In the end I got what I needed by using Lars' pointer of the iptables
extensions. I copied the iptables systemd service unit from my LFS box to
the machine in question, and then created a script in /etc/systemd/scripts
that first sets the iptables output chain policy to DROP, then adds these
rules:

iptables -A OUTPUT -m time --starttime 00:00 --stoptime 12:00 -j ACCEPT
iptables -A OUTPUT -d 192.168.11.0/24 -j ACCEPT

followed by rules specifying protocols and ports to allow DHCP, NTP and
Avahi to work at all times.

The first of the above rules matches every single outgoing packet and lets
them through between the hours of 9am and 9pm JST (midnight to noon UTC)
and matches nothing the rest of the time. Since Japan does not observe
daylight saving time I don't have that wrinkle to worry about. So between
9am and 9pm the other rules are superfluous and get no exercise. Once 9pm
arrives the first rule stops matching anything and the others start getting
work to do. The second allows anything aimed at my local network through,
except connections to my firewall which isn't on the 192.168.11.xxx subnet,
but I don't need this box to be able to ssh into the firewall so that's no
problem. I could have made it 192.168.0.0/16 but then I would have been
allowing a bunch of other subnet addresses I don't need. In this case, not
a major problem, but generally a bad habit when it comes to packet filter
rules.

The other rules allow DHCP, NTP and Avahi to work (the second rule doesn't
allow Avahi to work as it uses a broadcast address). Without the Avahi
rule, I found that the machine could talk to the rest of my network by ip
address but not by network name during the out-of-hours period. Duh, hadn't
thought of that.

So between 9am and 9pm everything hits the first rule and gets allowed.
Between 9pm and 9am anything not specifically aimed at my local nework that
isn't DHCP, NTP or Avahi falls all the way through the rules and hits the
policy rule, which is DROP. No changes needed anywhere else on the network.
If the machine can't get requests out, it isn't going to get any responses
back. And the firewall at the front door of my network is blocking anything
trying to come in from the internet that wasn't invited.

# systemctl enable iptables.service

makes sure this gets run every time the machine is booted. And that's it.

However, I'm finding the discussion with Dan very interesting so I'd like
to continue it if you don't mind, albeit on a hypothetical basis.

The first problem I'd have with Dan's suggestion is that the firewall box
only has 2 network ports -- one built into it and one I added using a
USB3.0 to Ethernet adaptor. So the cable modem is plugged into the native
Ethernet port and the USB-to-Ethernet passes on through an Ethernet cable
to the WAN port of the AP. This would be the connection that Dan suggests
shifting to a LAN port of the AP. Despite some clucking from various
sources about the performance I'd get from using a USB to Ethernet adaptor,
in practice I see no practical difference in internet access speed by
having used such an adaptor. I guess I'd need to add a third Ethernet port
to the firewall to migrate the wired devices, using another USB to Ethernet
adaptor, and plug some kind of hub device into it so I could plug in more
than one wired Ethernet device.

Then the firewall would have to be a dhcp client of the AP, instead of the
other way round as now, as I can't turn the AP'S DHCP server off since I
need it to supply IP addresses to my wireless devices. But I'd need to keep
the DHCP server on the firewall so it could supply IP addresses to the
wired machines. I am not a fan of static IP addressing on a home LAN,
although I can see why it isn't a big problem for the wired part since
wired devices tend not to wander about. :)

But part of me is thinking that if I were going to migrate my wired devices
away from the AP and to the firewall, I might as well go the whole hog,
turn the firewall's WiFi device on, and serve up the WiFi from there too,
eliminating the AP altogether. Except that the WiFi card in the firewall
wasn't designed to be an AP and maybe its signal will be weaker. However,
the last time I cracked open a common-or-garden WiFi router and looked
inside, I found a PCMCIA WiFi adaptor of exactly the kind I was using in my
computer at the time, inside...

Mark

[toc] | [prev] | [next] | [standalone]

#170816

On Sun 07 Aug 2016 at 03:32:00 +0000, Mark Fletcher wrote:

> In the end I got what I needed by using Lars' pointer of the iptables
> extensions. I copied the iptables systemd service unit from my LFS box to
> the machine in question, and then created a script in /etc/systemd/scripts
> that first sets the iptables output chain policy to DROP, then adds these
> rules:
> 
> iptables -A OUTPUT -m time --starttime 00:00 --stoptime 12:00 -j ACCEPT
> iptables -A OUTPUT -d 192.168.11.0/24 -j ACCEPT

Would being able to alter UTC from the BIOS be reckoned to be a strong
technical skill? And, more to the point, would it work in your situation?

[toc] | [prev] | [next] | [standalone]

#170826

[Multipart message — attachments visible in raw view] — view raw

On Mon, 8 Aug 2016 at 03:15, Brian <ad44@cityscape.co.uk> wrote:

> On Sun 07 Aug 2016 at 03:32:00 +0000, Mark Fletcher wrote:
>
> > In the end I got what I needed by using Lars' pointer of the iptables
> > extensions. I copied the iptables systemd service unit from my LFS box to
> > the machine in question, and then created a script in
> /etc/systemd/scripts
> > that first sets the iptables output chain policy to DROP, then adds these
> > rules:
> >
> > iptables -A OUTPUT -m time --starttime 00:00 --stoptime 12:00 -j ACCEPT
> > iptables -A OUTPUT -d 192.168.11.0/24 -j ACCEPT
>
> Would being able to alter UTC from the BIOS be reckoned to be a strong
> technical skill? And, more to the point, would it work in your situation?
>
>
I don't think it would since ntp would just change it back on boot.

Now, telling Linux that the bios clock isn't utc -- now that would eff
things up. But if he gets the access he'd need to do that all bets are off
anyway as he could just change the firewall rules.

Mark

[toc] | [prev] | [next] | [standalone]

#170883

On Sun, Aug 07, 2016 at 03:32:00AM +0000, Mark Fletcher wrote:
> On Sun, Aug 7, 2016 at 9:57 AM Dan Ritter <dsr@randomstring.org> wrote:
> 
> > On Sat, Aug 06, 2016 at 04:56:06AM +0000, Mark Fletcher wrote:
> > > On Sat, Aug 6, 2016 at 2:48 AM Dan Ritter <dsr@randomstring.org> wrote:
> >
> > Got it. You can change that by removing NAT from the AP. For
> > instance, plug your switch into a LAN port instead of the WAN
> > port:
> >
> > cable modem -- LFS -- switch ---- (LAN port) AP ---- wifi client
> >                              |                  \___ wifi client
> >                              |
> >                              ---- other wired machines
> 
> However, I'm finding the discussion with Dan very interesting so I'd like
> to continue it if you don't mind, albeit on a hypothetical basis.

What is the Internet for, if not hypotheticals?


> The first problem I'd have with Dan's suggestion is that the firewall box
> only has 2 network ports -- one built into it and one I added using a
> USB3.0 to Ethernet adaptor. So the cable modem is plugged into the native
> Ethernet port and the USB-to-Ethernet passes on through an Ethernet cable
> to the WAN port of the AP. This would be the connection that Dan suggests
> shifting to a LAN port of the AP. Despite some clucking from various
> sources about the performance I'd get from using a USB to Ethernet adaptor,
> in practice I see no practical difference in internet access speed by
> having used such an adaptor. I guess I'd need to add a third Ethernet port
> to the firewall to migrate the wired devices, using another USB to Ethernet
> adaptor, and plug some kind of hub device into it so I could plug in more
> than one wired Ethernet device.

Nope. Buy a $20 5-8 port ethernet switch. Very reliable. That's
in the diagram above as "switch".


> Then the firewall would have to be a dhcp client of the AP, instead of the
> other way round as now, as I can't turn the AP'S DHCP server off since I
> need it to supply IP addresses to my wireless devices. But I'd need to keep
> the DHCP server on the firewall so it could supply IP addresses to the
> wired machines. I am not a fan of static IP addressing on a home LAN,
> although I can see why it isn't a big problem for the wired part since
> wired devices tend not to wander about. :)

If you turn off NAT, DHCP will pass through it. So having the
firewall run all your DHCP makes sense. It's also a good place
to run a DNS cache, and NTP.

> But part of me is thinking that if I were going to migrate my wired devices
> away from the AP and to the firewall, I might as well go the whole hog,
> turn the firewall's WiFi device on, and serve up the WiFi from there too,
> eliminating the AP altogether. Except that the WiFi card in the firewall
> wasn't designed to be an AP and maybe its signal will be weaker. However,
> the last time I cracked open a common-or-garden WiFi router and looked
> inside, I found a PCMCIA WiFi adaptor of exactly the kind I was using in my
> computer at the time, inside...

Yeah, they tend to be very similar. If you buy a PCI or PCI-E
wifi card with good external antennae, that's a perfectly
reasonable choice.

cable modem -- LFS -- (wifi nic) ---- wifi clients
                   |
                   -- (USB nic) -- switch - wired machines

Which will simplify your life a little more.

If you run into range problems, putting an ethernet cable out to
the other side of your dwelling and re-using the AP as a range
extender is not a bad move.

-dsr-

[toc] | [prev] | [next] | [standalone]

#170884

> Nope. Buy a $20 5-8 port ethernet switch. Very reliable. That's
> in the diagram above as "switch".

But it also means one more box.  If you had one box before, that doubles
the number of boxes, and might also double the 24/7 power consumption.


        Stefan

[toc] | [prev] | [next] | [standalone]

#170926

On Tue, Aug 09, 2016 at 03:14:27PM -0400, Stefan Monnier wrote:
> > Nope. Buy a $20 5-8 port ethernet switch. Very reliable. That's
> > in the diagram above as "switch".
> 
> But it also means one more box.  If you had one box before, that doubles
> the number of boxes, and might also double the 24/7 power consumption.

An 8 port ethernet switch, such as the one on my desk here, is
roughly the size of a paperback book. It sips electricity, with
a maximum consumption of about 3W, and has no configuration at
all. Lifetime warranties are reasonably common.

A typical AP needs 10-20W, is a full-fledged computer running a
configurable operating system and has an expected lifetime of
1-4 years.

-dsr-

[toc] | [prev] | [next] | [standalone]

#170938

> a maximum consumption of about 3W, and has no configuration at
[...]
> A typical AP needs 10-20W,

What kind of AP would consume 20W?  Mine consumes around 5W and that includes
a 2TB disk attached to it (and spinning).

> and has an expected lifetime of 1-4 years.

Where do you get those numbers?  In my world, if it dies on you before
5 years, then it was just a really bad quality AP.

The point about reliability and lack of configuration of a dumb switch is
well taken, tho.


        Stefan

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web