LinuxQuestions.org - Time limitations to online games

- Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)

- - Time limitations to online games (https://www.linuxquestions.org/questions/linux-security-4/time-limitations-to-online-games-402166/)

The easiest way would be to give your kids more chores around the house :)

Quote:

Originally Posted by Paulsuk

I had a look, and sure enough libipt_time.so is missing :scratch:

So I did a make clean on IPTABLES - no-go.

If I look in the IPTABLES source directory tree (I'm at the limits of my knowledge here!) there is a file in the extensions directory called libipt_time.c and a second one called libipt_time.man, but the .so file is nowhere to be found. :cry: I also notice that all the other extensions have an additional file with a ".d" extension, but there is no libipt_time.d - is this significant? Finally, out of desperation, I watched a complete make of IPTABLES and didn't spot libipt_time being compiled... why not?????:mad:

i'm not sure... maybe try compiling the latest version of iptables (1.3.5 at the time of this post) or something... hang in there, i'm sure you'll figure it out after some troubleshooting and stuff...

Quote:

Finally, I'm not sure I fully understand your modified file..

no problem, let me know which line you have doubts about and i'll try and explain what it's doing for you...

Quote:

My server is running DNS, DHCP, httpd, squid, SAMBA, postfix, ssh and ftp as well as squid, dansguardian and havp.

hehe, cool... i had no idea...

Quote:

Do I need to worry about exceptions for all of these using your config?

optimally, you should always write firewall scripts using the "default deny" methodology (instead of the "default permit")... in other words, yes, making exceptions for every kind of traffic you want to allow to flow... check "idea #1" at this link to understand why:

http://www.ranum.com/security/comput...itorials/dumb/

having said, considering it's just a home firewall, you might not want to go through the hassle of setting-up rules for all your daemons and stuff (even though it's a good idea to go through that hassle :) ), in which case you can easily do a "default permit" on your LAN interface... basically you'd just eliminate the relevant (LAN) INPUT rules and replace them with one to take care of everything.... like this:

Code:

#!/bin/sh



IPT="/sbin/iptables"



echo 0 > /proc/sys/net/ipv4/ip_forward

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route

echo 0 > /proc/sys/net/ipv4/tcp_syncookies

echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects

echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects

echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

echo 1 > /proc/sys/net/ipv4/conf/all/log_martians

echo 2 > /proc/sys/net/ipv4/ip_dynaddr

echo 0 > /proc/sys/net/ipv4/tcp_ecn



$IPT -F

$IPT -F -t nat

$IPT -F -t mangle



$IPT -X

$IPT -X -t nat

$IPT -X -t mangle



$IPT -P INPUT DROP

$IPT -P FORWARD DROP

$IPT -P OUTPUT ACCEPT



#/sbin/modprobe ip_conntrack_ftp

#/sbin/modprobe ip_nat_ftp



$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT



$IPT -A INPUT -i lo -j ACCEPT



$IPT -A INPUT -i eth0 -m state --state NEW -j ACCEPT



$IPT -A INPUT -m limit --limit 3/minute --limit-burst 3 \

-j LOG --log-prefix "INPUT DROP: "



$IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT



$IPT -A FORWARD -i eth0 -s 192.168.1.100 -m time \

--timestart 19:00 -j REJECT



$IPT -A FORWARD -i eth0 -s 192.168.1.100 -m time \

--timestop 15:30 --days Mon,Tue,Wed,Thu,Fri -j REJECT



$IPT -A FORWARD -i eth0 -s 192.168.1.100 -m time \

--timestop 07:00 --days Sat,Sun -j REJECT



$IPT -A FORWARD -i eth0 -s 192.168.1.101 -m time \

--timestart 19:00 -j REJECT



$IPT -A FORWARD -i eth0 -s 192.168.1.101 -m time \

--timestop 15:30 --days Mon,Tue,Wed,Thu,Fri -j REJECT



$IPT -A FORWARD -i eth0 -s 192.168.1.101 -m time \

--timestop 07:00 --days Sat,Sun -j REJECT



$IPT -A FORWARD -i eth0 -o eth1 -m state --state NEW -j ACCEPT



$IPT -A FORWARD -m limit --limit 3/minute --limit-burst 3 \

-j LOG --log-prefix "FORWARD DROP: "



$IPT -t nat -A POSTROUTING -o eth1 -j MASQUERADE



echo 1 > /proc/sys/net/ipv4/ip_forward

now, as far as your EXTERNAL interface is concerned: you definetly DO NOT want to do a "default permit" on that side... it would really really really suck to do that... if you don't wanna write the rules for the external side just let me know what you need to be listening on that side and i'll write the rules for you...

let me know how it goes with your iptables time match module issue...

i hope you work it out soon...

Quote:

Originally Posted by stress_junkie

You could just have a cron job that changes the iptables configuration by one rule. The cron job that allows access can run when they can start playing. The cron job that disallows access can run when they have to stop playing. Each cron job just adjusts one iptables rule. You can even have both jobs in one script to make it neat.

Here is an even simpler idea. Have one iptables setup script that is set up to allow games. Name that /etc/iptables-allow-script. Have another iptables setup script that denies games. Name that /etc/iptables-deny-script. These scripts are just the iptables commands to configure iptables. Then your cron job would just be one command. The command to run when they can start playing would just be iptables-restore < /etc/iptables-allow-script. The command to run when they have to stop playing would be iptables-restore < /etc/iptables-deny-script.

The cron job approach seems a lot easier to me than trying to get iptables to change it's behavior based on the time of day.

this is true... i hadn't thought about the iptables-save option... i had really only thought about cron-ing an iptables script to be executed at a certain time, etc... but one of the drawbacks of doing it like that was that the kids would just need to reboot the router to get the default firewall rules back online and play play play... but yeah, by doing an iptables-save after changing the rules then the firewall's configuration is saved across reboots, so that would work fine...

i think you're right, it's possible to do this with cron in a way which is still elegant and non-complicated... :)

using a cron approach with two (shell) scripts (one for allow play and one for no play), the scripts could look like these:

ALLOW PLAYING:

Code:

#!/bin/sh



IPT="/sbin/iptables"



echo 0 > /proc/sys/net/ipv4/ip_forward

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route

echo 0 > /proc/sys/net/ipv4/tcp_syncookies

echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects

echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects

echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

echo 1 > /proc/sys/net/ipv4/conf/all/log_martians

echo 2 > /proc/sys/net/ipv4/ip_dynaddr

echo 0 > /proc/sys/net/ipv4/tcp_ecn



$IPT -F

$IPT -F -t nat

$IPT -F -t mangle



$IPT -X

$IPT -X -t nat

$IPT -X -t mangle



$IPT -P INPUT DROP

$IPT -P FORWARD DROP

$IPT -P OUTPUT ACCEPT



#/sbin/modprobe ip_conntrack_ftp

#/sbin/modprobe ip_nat_ftp



$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT



$IPT -A INPUT -i lo -j ACCEPT



$IPT -A INPUT -i eth0 -m state --state NEW -j ACCEPT



$IPT -A INPUT -m limit --limit 3/minute --limit-burst 3 \

-j LOG --log-prefix "INPUT DROP: "



$IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT



$IPT -A FORWARD -i eth0 -o eth1 -m state --state NEW -j ACCEPT



$IPT -A FORWARD -m limit --limit 3/minute --limit-burst 3 \

-j LOG --log-prefix "FORWARD DROP: "



$IPT -t nat -A POSTROUTING -o eth1 -j MASQUERADE



echo 1 > /proc/sys/net/ipv4/ip_forward

DO NOT ALLOW PLAYING:

Code:

#!/bin/sh



IPT="/sbin/iptables"



echo 0 > /proc/sys/net/ipv4/ip_forward

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route

echo 0 > /proc/sys/net/ipv4/tcp_syncookies

echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects

echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects

echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

echo 1 > /proc/sys/net/ipv4/conf/all/log_martians

echo 2 > /proc/sys/net/ipv4/ip_dynaddr

echo 0 > /proc/sys/net/ipv4/tcp_ecn



$IPT -F

$IPT -F -t nat

$IPT -F -t mangle



$IPT -X

$IPT -X -t nat

$IPT -X -t mangle



$IPT -P INPUT DROP

$IPT -P FORWARD DROP

$IPT -P OUTPUT ACCEPT



#/sbin/modprobe ip_conntrack_ftp

#/sbin/modprobe ip_nat_ftp



$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT



$IPT -A INPUT -i lo -j ACCEPT



$IPT -A INPUT -i eth0 -m state --state NEW -j ACCEPT



$IPT -A INPUT -m limit --limit 3/minute --limit-burst 3 \

-j LOG --log-prefix "INPUT DROP: "



$IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT



$IPT -A FORWARD -i eth0 -s 192.168.1.100 \

-m state --state NEW -j REJECT



$IPT -A FORWARD -i eth0 -s 192.168.1.101 \

-m state --state NEW -j REJECT



$IPT -A FORWARD -i eth0 -o eth1 -m state --state NEW -j ACCEPT



$IPT -A FORWARD -m limit --limit 3/minute --limit-burst 3 \

-j LOG --log-prefix "FORWARD DROP: "



$IPT -t nat -A POSTROUTING -o eth1 -j MASQUERADE



echo 1 > /proc/sys/net/ipv4/ip_forward

just make sure you tell cron do do an "iptables-save" after executing each script...

you could also just execute each script manually and then generate an iptables configuration file for each setup and cron the iptables-restore to pick-up the rules from those, as was suggested by stress_junkie... in fact, that would probably be the elegant thing to do... :)

NOTE: keep in mind that iptables doesn't store kernel parameters in it's configuration files...

Phew!!!

Ok, to start off with, geeman2.0

Quote:

The easiest way would be to give your kids more chores around the house

I'd love to, but they just don't do them :mad: !!!

Next, the whole cron thing (stress junkie) et al. If that is how I have to go, then so be it, but I have 3 problems with this approach....

This leaves me with two IPTABLES configuration files to maintain if I want to add / remove / change any settings
It just isn't as elegant as the time method... This is also an educational exercise and I can see cases where I would want to do similar things on a larger-scale firewall.
I just don't want to let it beat me! ;)

Finally, win32sux, thanks again for all your help with this - you're a star! I'll try upgrading IPTABLES as you suggest and see if that helps, if not, then I think I may go down the cron route. Thanks also for your tips on firewalling - I don't think I need to protect the LAN interface at this stage TOO much (but who knows in the future) so I'll have a play there. The only things I need to go out on the 'net are NTP updates, web surfing from squid / directly, ftp downloads and incoming http and ssh requests (at this stage, but I'm learning fast!)

I'll post back and let you all know how it goes.

Damn I LOVE the LQ community :D

Paul

Upgrading to IPTABLES 1.1.5 didn't help. Still got exactly the same problem :(

Looks like it may well have to be cron :( :(

Thanks, everyone, for your help. If anyone DOES manage to solve this one....

Cheers,

Paul

after you apply the time patch to your kernel, you are running a "make xconfig" (using your old .config) and then setting the new time match option, right??

what does your config file's time options look like??

Code:

cat your_config | grep TIME

i've never used the time match (or any netfilter patch for that matter), but i would assume the steps would go like this:

- apply time patch to kernel source
- run make xconfig/gconfig/menuconfig with your current config file and set the new time match option
- save the new config
- compile the kernel and modules with the new config
- boot the new kernel
- recompile iptables while running the new kernel

is this pretty much what you are doing already??

i'm just making sure cuz it sounds like the time match module isn't getting compiled in the first place...

also, is there any documentation anywhere that specifies which kernel versions those netfilter patches are designed for??

BTW, if you're gonna give it another shot, you might as well download the latest kernel source (2.6.15.3), as a DoS vulnerability has recently been patched:

http://secunia.com/advisories/18766/

EDIT: 2.6.15.4 is out... :)

I may well look at the new kernel, but I don't want to go mucking around with that just yet! ;)

Anyway, the patch seems to have been applied to the kernel ok. Output from the grep is:

Quote:

# CONFIG_HPET_TIMER is not set
# CONFIG_X86_PM_TIMER is not set
CONFIG_IP_NF_MATCH_TIME=y
# CONFIG_HANGCHECK_TIMER is not set
CONFIG_SND_TIMER=y
# CONFIG_PRINTK_TIME is not set

it seems that I just can't activate the new filter because IPTABLES isn't compiling the required so :cry:

I'm just about to apply the cron solution (kids out of the way at the moment, so I can test it all! :D) I'm just going through your configs at the moment so I can understand them. I'm looking at the docs as well :study: , but if there's any lines I don't understand, I'll be sure to ask ;)

Cheers, Paul

Quote:

Originally Posted by Paulsuk

CONFIG_IP_NF_MATCH_TIME=y

just a shot in the dark: perhaps iptables wants you to have compiled the time match as a module rather than have it built into the kernel (before compiling iptables)??

I could give it a go, I s'pose, but to be honest I'm beginning to run out of patience with it. Sad, but I've got other, more pressing things on at the mo ;)

Cron, here I come!!!

BTW, what does the "mangle" chain do?

Paul