changing rules at a defined time

changing rules at a defined time

[Payal Rathod]

Hi,
I have a very basic LAN setup question like,

- till 16:00 p.m. all ips can just use ftp but ips 192.168.0.1
  and 192.168.0.100 can do anything

- after 4:00 afternoon all can do anything till 5:00 after which again
  the above [1st rules] are to be applied.

I am thinking of doing,

[For step 1]: - Policy ACCEPT for FORWARD

iptables -A FORWARD -s 192.168.0.1 -p tcp -j ACCEPT
iptables -A FORWARD -s 192.168.0.100 -p tcp -j ACCEPT
iptables -A FORWARD -s 192.168.0.0/32 -p tcp --dport 21 -j ACCEPT
iptables -A FORWARD -s 0/0 -p tcp -j DROP

[For step 2]: - Policy ACCEPT for FORWARD

iptables -A FORWARD -p tcp -j ACCEPT

Maybe same for udp.


Now my question is, 

1> Do the above steps look ok? I will refine them further. Right now are
they workable.

2> If I want to change the rules at 16:00 what is the best way to change
them? I was thing of flushing with iptables -F and iptables -F -t nat
and then running the second step.
Similary at 17:00 do the same kind of flushes and run 1st step from a
file? Is this approach ok or is there anything better?

Thanks a lot in advance and bye.

With warm regards,
-Payal

-- 
For GNU/Linux Success Stories and Articles visit:
          http://payal.staticky.com

Re: changing rules at a defined time

[Chris Brenton]

Greetings!

On Wed, 2003-12-24 at 04:29, Payal Rathod wrote:
>
> 1> Do the above steps look ok? I will refine them further. Right now are
> they workable.

At the very least, I would specify the receiving interface as well or
you may be subject to spoofing attacks. At the most, you are missing:

Any kind of logging
Deny inbound packets from loopback, private, etc.
Deny outbound unreachables, Timex, Echo-replies, critical services, etc.

There are probably others. The caffeine has not kicked in yet. ;-)

> 2> If I want to change the rules at 16:00 what is the best way to change
> them?

Two options:

1) Write up two sets of rules in two different shell scripts. Use cron
to implement them at the appropriate time. Use '-F' as you mentioned at
the beginning of the script to flush the existing rules.

2) Install patch-o-matic and implement the time patch. You can then do
something like:

iptables -A FORWARD -i eth0 -p tcp -m time --timestart 16:00 --timestop
17:00 --days Mon,Tue,Wed,Thu,Fri -s 192.168.0.0/32 -j ACCEPT

HTH,
C

Re: changing rules at a defined time

[Cedric Blancher]

Le mer 24/12/2003 à 10:29, Payal Rathod a écrit :
> - till 16:00 p.m. all ips can just use ftp but ips 192.168.0.1
>   and 192.168.0.100 can do anything
> - after 4:00 afternoon all can do anything till 5:00 after which again
>   the above [1st rules] are to be applied.
[...]
> [For step 1]: - Policy ACCEPT for FORWARD
> iptables -A FORWARD -s 192.168.0.1 -p tcp -j ACCEPT
> iptables -A FORWARD -s 192.168.0.100 -p tcp -j ACCEPT
> iptables -A FORWARD -s 192.168.0.0/32 -p tcp --dport 21 -j ACCEPT
> iptables -A FORWARD -s 0/0 -p tcp -j DROP
> [For step 2]: - Policy ACCEPT for FORWARD
> iptables -A FORWARD -p tcp -j ACCEPT
[...]
> 1> Do the above steps look ok? I will refine them further. Right now are
> they workable.

They won't work as you don't deal with returning packets. You should try
to use states that can improve your ruleset, particularly when dealing
with FTP.
You really should set FORWARD policy to DROP then get rid of your
iptables -A FORWARD -s 0/0 -p tcp -j DROP rule. What if someone wants to
do something else than TCP ? Such as UDP, ICMP, GRE or anything else ?

[For step 1]: - Policy DROP for FORWARD
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state NEW -s 192.168.0.1 -p tcp -j ACCEPT
iptables -A FORWARD -m state --state NEW -s 192.168.0.100 -p tcp \
		-j ACCEPT
iptables -A FORWARD -m state --state NEW -s 192.168.0.0/32 -p tcp \
		--dport 21 -j ACCEPT

[For step 2]: - Policy DROP for FORWARD
iptables -A FORWARD -m state --state NEW -s 192.168.0.0/32 -p tcp \
		-j ACCEPT

> 2> If I want to change the rules at 16:00 what is the best way to change
> them? I was thing of flushing with iptables -F and iptables -F -t nat
> and then running the second step.
> Similary at 17:00 do the same kind of flushes and run 1st step from a
> file? Is this approach ok or is there anything better?

I would use a full flushing script that issues :

	iptables -F
	iptables -t nat -F
	iptables -t mangle -F
	iptables -X
	iptables -t nat -X
	iptables -t mangle -X

After that, I would generate two ruleset files using iptables-save for
each case. Then, after flushing, you iptables-restore the appropriate
ruleset.

Have you tried Fabrice Marie patch-o-matic time match that allows you to
match time for a given rule ?

http://www.netfilter.org/documentation/pomlist/pom-base.html#time

You would have a single ruleset of this kind (if I understood what you
needed) :

Policy DROP for FORWARD
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state NEW -s 192.168.0.1 -p tcp -j ACCEPT
iptables -A FORWARD -m state --state NEW -s 192.168.0.100 -p tcp \
		-j ACCEPT
iptables -A FORWARD -m state --state NEW -s 192.168.0.0/32 -p tcp \
		--dport 21 -j ACCEPT
iptables -A FORWARD -m state --state NEW -m time --starttime 16:00 \
		--stoptime 17:00 -s 192.168.0.0/32 -p tcp -j ACCEPT

You can even match days using --day option if you need to, e.g. allowing
access only to working days.


-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread! 

Re: changing rules at a defined time

[Antony Stone]

On Wednesday 24 December 2003 9:29 am, Payal Rathod wrote:

> Hi,
> I have a very basic LAN setup question like,
>
> - till 16:00 p.m. all ips can just use ftp but ips 192.168.0.1
>   and 192.168.0.100 can do anything
>
> - after 4:00 afternoon all can do anything till 5:00 after which again
>   the above [1st rules] are to be applied.
>
> I am thinking of doing,
>
> [For step 1]: - Policy ACCEPT for FORWARD
>
> iptables -A FORWARD -s 192.168.0.1 -p tcp -j ACCEPT
> iptables -A FORWARD -s 192.168.0.100 -p tcp -j ACCEPT
> iptables -A FORWARD -s 192.168.0.0/32 -p tcp --dport 21 -j ACCEPT
> iptables -A FORWARD -s 0/0 -p tcp -j DROP
>
> [For step 2]: - Policy ACCEPT for FORWARD
>
> iptables -A FORWARD -p tcp -j ACCEPT
>
> Maybe same for udp.
>
>
> Now my question is,
>
> 1> Do the above steps look ok? I will refine them further. Right now are
> they workable.

I really disapprove of a default ACCEPT policy on FORWARD.

You should use a default DROP policy, and let the rules specify what you 
ACCEPT.

> 2> If I want to change the rules at 16:00 what is the best way to change
> them? I was thing of flushing with iptables -F and iptables -F -t nat
> and then running the second step.
> Similary at 17:00 do the same kind of flushes and run 1st step from a
> file? Is this approach ok or is there anything better?

For simplicity (?) I would use a cron job at 16:00 to Insert a rule, and 
another at 17:00 to Delete it.   For example:

iptables -P FORWARD DROP
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $INTIF -p tcp --dport 21 -j ACCEPT
iptables -A FORWARD -i $INTIF -s 192.168.0.1 -j ACCEPT
iptables -A FORWARD -i $INTIF -s 192.168.0.100 -j ACCEPT
iptables -A FORWARD -i $INTIF -p tcp --dport 53 -j ACCEPT
iptables -A FORWARD -i $INTIF -p udp --dport 53 -j ACCEPT

Then at 16:00, use a cron rule to run:

iptables -A FORWARD -i $INTIF -s 192.168.0.0/24 -j ACCEPT

At 17:00 use a cron rule to run:

iptables -D FORWARD -i $INTIF -s 192.168.0.0/24 -j ACCEPT

The only thing I can think of which this solution which you have to decide 
whether you're happy about is that connections currently in progress at 17:00 
will not be cut off - users simply won't be able to make new ones until 16:00 
the following day.

Hope this helps,

Antony.

-- 
Normal people think "If it ain't broke, don't fix it".
Engineers think "If it ain't broke, it doesn't have enough features yet".

                                                     Please reply to the list;
                                                           please don't CC me.

Re: changing rules at a defined time

[Payal Rathod]

Hi,

Thanks for the mails all of you. I am also going to look into
patch-o-matic later. I have a couple of doubts now.

On Wed, Dec 24, 2003 at 10:11:14AM +0000, Antony Stone wrote:
> I really disapprove of a default ACCEPT policy on FORWARD.

Why? I can DROP everything later.

> iptables -P FORWARD DROP
> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
[...]

> Then at 16:00, use a cron rule to run:
> 
> iptables -A FORWARD -i $INTIF -s 192.168.0.0/24 -j ACCEPT

Should that be iptables -I or specifically -A?

> At 17:00 use a cron rule to run:
> 
> iptables -D FORWARD -i $INTIF -s 192.168.0.0/24 -j ACCEPT
> 
> The only thing I can think of which this solution which you have to decide 
> whether you're happy about is that connections currently in progress at 17:00 
> will not be cut off - users simply won't be able to make new ones until 16:00 
> the following day.

You mean a person logged on to MSN can continue being logged on
throughout?
So, do I FLUSH the rules through cron to prevent this?

With warm regards,
-Payal

Re: changing rules at a defined time

[Antony Stone]

On Wednesday 24 December 2003 1:26 pm, Payal Rathod wrote:

> Hi,
>
> Thanks for the mails all of you. I am also going to look into
> patch-o-matic later. I have a couple of doubts now.
>
> On Wed, Dec 24, 2003 at 10:11:14AM +0000, Antony Stone wrote:
> > I really disapprove of a default ACCEPT policy on FORWARD.
>
> Why? I can DROP everything later.

1. If you first set a default DROP policy, then add rules for the packets you 
want to ACCEPT, there is no point at which your firewall is allowing traffic 
you don't want to pass.   This is a Good Thing.   If you set default ACCEPT, 
then add rules, and finish with a DROP, your firewall is allowing everything 
right up to the point when that final rule gets added - and depending on your 
ruleset, this time may or may not be significant.   Personally, I want it to 
be zero.

2. What if your script encounters some error whilst it is processing, before 
it gets to add the DROP rule?   Then you are left without one, and an open 
firewall (how quickly will you notice this?)

3. If you put a DROP rule at the end of your ruleset, you must be careful when 
adding more rules later on, since if they go after the DROP, they will not do 
anything useful.   A DROP policy is guaranteed to take effect *after* all the 
rules, so you don't have to worry about fitting them in before the final 
rule.   Position in the table becomes much less critical.

> > iptables -P FORWARD DROP
> > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> [...]
>
> > Then at 16:00, use a cron rule to run:
> >
> > iptables -A FORWARD -i $INTIF -s 192.168.0.0/24 -j ACCEPT
>
> Should that be iptables -I or specifically -A?

Well, if you use a default DROP policy, either will do.   If you have a final 
rule DROPping packets you don't want and an ACCEPT policy, then you must 
insert this rule somewhere before the existing final rule (so -I is a 
convenient way to do this, but that then prevents your ESTABLISHED, RELATED 
rule being the first one, which is a good idea for eficiency).   See my point 
3 above in reply to your first question.

> > At 17:00 use a cron rule to run:
> >
> > iptables -D FORWARD -i $INTIF -s 192.168.0.0/24 -j ACCEPT
> >
> > The only thing I can think of which this solution which you have to
> > decide whether you're happy about is that connections currently in
> > progress at 17:00 will not be cut off - users simply won't be able to
> > make new ones until 16:00 the following day.
>
> You mean a person logged on to MSN can continue being logged on
> throughout?

I don't know.   It depends whether such a session uses a single uninterrupted 
TCP connection, or multiple connections one after another.

An SSH session, for example, if started between 16:00 and 17:00, would be 
allowed to continue until the user logged out.

HTTP sessions, on the other hand are (nearly always) extremely brief, so a 
user browsing websites would find they couldn't continue after 17:00.

It depends what your users are doing as to whether preventing NEW connections 
after 17:00 will interfere with what they already started doing or not.

> So, do I FLUSH the rules through cron to prevent this?

No, you have to clear the connection tracking table, which is quite difficult 
to do (and cannot be done on a per-connection basis - either you keep them 
all, or you lose them all).

Regards,

Antony.

-- 
Anyone that's normal doesn't really achieve much.

 - Mark Blair, Australian rocket engineer

                                                     Please reply to the list;
                                                           please don't CC me.