iptables not dropping from specific device

boredazfcuk · 02-04-2018, 03:50 PM

Hi,

I've been scratching my head at this one for the past few weeks. No idea why it's happening. Maybe someone smarter than me can work it out...

So here's the background... I've got a smart TV with the YouTube Kids app on it in the kid's play room. I want to restrict the times of day that the kids can watch.

I've have a Debian 9 VM, which I've enabled ipv4 forwarding on. DHCP sets the TV's default gateway to the IP of the VM. I've created a couple of scripts which insert iptables rules, one to reject/drop traffic from the TV's IP and the other to allow traffic again.

block-tv:

Code:

/sbin/iptables -I FORWARD -s 192.168.1.x -i ens3 -j DROP
/sbin/iptables -I INPUT -s 192.168.1.x -i ens3 -j DROP
/sbin/iptables -I FORWARD -s 192.168.1.x -i ens3 -j REJECT
/sbin/iptables -I INPUT -s 192.168.1.x -i ens3 -j REJECT

allow-tv:

Code:

/sbin/iptables -D FORWARD -s 192.168.1.242 -i ens3 -j DROP
/sbin/iptables -D INPUT -s 192.168.1.242 -i ens3 -j DROP
/sbin/iptables -D FORWARD -s 192.168.1.242 -i ens3 -j REJECT
/sbin/iptables -D INPUT -s 192.168.1.242 -i ens3 -j REJECT

Using cron, I have set allow-tv to run at 6am and block-tv to run at 10am. I've confirmed that these scripts are being executed in syslog and can see the rules when running iptables -L

When the block rules are in place, the output of that command looks like this:

Code:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
REJECT     all  --  PlayRoomTV.home       anywhere             reject-with icmp-port-unreachable
DROP       all  --  PlayRoomTV.home       anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
REJECT     all  --  PlayRoomTV.home       anywhere             reject-with icmp-port-unreachable
DROP       all  --  PlayRoomTV.home       anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

I've opened up a few videos, run the scripts manually, and can confirm that it blocks the videos, prevents browsing, etc... But this morning, even though the blocking rules were in place, the kids were still watching at at 12:30pm. The stuff they watch is usually 30-45mins long so I'm certain it's not cached. They've also been using the search function which can't be cached either.

Why would iptables not be dropping the data? Is it because the script is being run from cron? Is it because it's UDP traffic? Is it due to the connection already being established?

I'm just at a loss as to why this doesn't work. Ideas welcome.

Thanks.

tocii. · 02-05-2018, 09:49 AM

Hi.

Debian VM is your router? Or your TV's packets go through the VM?
First give a static IP to your SMART tv, because if get another IP from DHCP, then you need to write another script...
Then make two simple bash script:

#!/bin/bash
iptables -D INPUT -s [your TV'S ip address] -j REJECT
iptables -D INPUT -s [your TV'S ip address] -j DROP and make then make ACCEPT script.

After you need to setup the schedule with crontab, and thats all.
Hope i can help yu. (sry for my english.)

boredazfcuk · 02-06-2018, 04:00 AM

Hi, thanks for your reply.

The TV's packets go through the VM. The Debian VM forwards them on to its gateway address.

The TV has a reserved IP address via the DHCP config file:

Code:

host PlayRoomTV-LAN {
  option host-name "PlayRoomTV.home";
  ddns-hostname "PlayRoomTV";
  hardware ethernet xx:xx:xx:xx:xx:xx;
  fixed-address 192.168.1.x;
  option routers 192.168.1.n;
}

My scripts are working as they're creating the rules to drop traffic. My 'allow' traffic rules just delete the drop rules.

I've created a 2nd set of scripts to block my mobile, and these work perfectly. It seems it's something about the way YouTube is operating. Does IP tables not block existing connections, or is it because it's UDP?

It just doesn't make sense to me.

tocii. · 02-06-2018, 08:50 AM

Add to the bash script last line: service iptables restart

boredazfcuk · 02-07-2018, 11:57 AM

Quote:

Originally Posted by tocii.

Add to the bash script last line: service iptables restart

iptables isn't a service on Debian so this doesn't work, unfortunately.

tocii. · 02-09-2018, 09:06 AM

systemctl restart firewall.service

boredazfcuk · 02-10-2018, 04:54 AM

I tried firewall.service and firewalld.service but these don't exist either

This system was installed with nothing but SSH server so it's only got core features/services on it.

I'm also running squid on there, but it's non transparent, and it's just so I can log the kids' mobile traffic (and block porn).