Timed Access on Routers Supporting IPTABLES (aka “Parental Control”)

With two teenagers in the house and important exams always on the horizon, I needed to limit access to the Internet, particularly when they should be sleeping! Many parents will be familiar with this scenario – you say goodnight and then you hear the familiar “ping” as a Facebook/Instagram/SMS/… notification goes off on their phone. Not good.

I’m currently using OpenWRT on my Linksys WRT-1900ACS v1 router which doesn’t have this sort of access control built in. After much research, I started playing around with IPTABLES rules and hit a snag in that whilst new connections would be rejected, existing connections could keep opening links on the same website – as my youngest watches lots of gaming videos on YouTube, this wasn’t a solution.

Then in a stroke of luck, I stumbled across these 2 rules (which need to be placed in /etc/firewall.user):

iptables -I INPUT -m time --kerneltz --timestart 22:30 --timestop 08:00 -m mac --mac-source xx:xx:xx:xx:xx:xx -j REJECT
iptables -I FORWARD -m time --kerneltz --timestart 22:30 --timestop 08:00 -m mac --mac-source xx:xx:xx:xx:xx:xx -j REJECT

the –kerneltz switch means local time – without it, the times are UTC. You will need to replace xx:xx:xx:xx:xx:xx with the MAC address of the device you wish to control.

I tested this watching a YouTube video and it stopped when the rule triggered.

Result!

This should work with any router that allows you to configure IPTABLES manually or in the GUI.

VestaCP and Centos 7 Issues

I’ve been using VestaCP for about a year now ever since I switched from Hostgator to a VPS with OVH.

Today I upgraded the VPS OS to Centos 7 as VestaCP now supports that version as of v0.9.8 release 15.

Two problems became apparent immediately, one of which caused the CPU load to be consistently more than 1. Both are simple configuration errors to fix.

ClamAV

ClamAV caused the CPU to run amok. The error logs showed that it could not control /var/run/clamav/clamd.sock and checking this showed that the file and the directory (/var/run/clamav) had the wrong owner.

Stop the service from trying to start from the VestaCP control panel and then log into your server via ssh. Now set the ownership of both the directory and the file to clam:clam – if the socket file doesn’t exist you can create it with touch and then set the ownership.

Upon restarting the service you should see the CPU load drop dramatically.

NGINX

For some reason VestaCP’s installer puts a link to a configuration file for Apache in the nginx config. This stops the service from starting which is why no websites are served!

Edit /etc/nginx/conf.d/vesta.conf and comment out the line ending in /httpd.conf (there are only 5 lines in the file so it won’t take long).

The service should now start.

Links

Centos – http://www.centos.org
VestaCP – http://www.vestacp.com
OVH – http://www.ovh.com