redesigning my firewall -- concepts and suggestions for a more structured layout

redesigning my firewall -- concepts and suggestions for a more structured layout

[Alistair Tonner]

	Okay ... 
	    I've been reading, watching and sometimes chipping in on this list for a 
	while now.  I started with Oskar Andreassens (hope I got that right, and 
	I hope some deity somewhere blesses the man for his work)  basic script
	tutorial to set my firewall up originally.  My firewall has over time 	
	modified and grown, and twiddled its way into a morass of rules that last
	week gave me utter fits when I inserted a rule in which I goofed, and b0rked
	the internal network filesharing system.  And couldn't see it right off as to 
	why ... 

	I am endevouring to remake the basic "my multi-pc home lan needs
	a firewall" firewall into something more organized, and I intend, as an
	exercise to write it *cough* myself.  My question is .... given the above
	basic premise, and a DROP default policy across all chains, Is it more
	effcient, processing wise, to have all the rules in a flat line, or, since it
	can make things easier to debug, have it parsed up in user chains.

	My logic is this.  I can break my network traffic flow into 6 directionally
	oriented chains ( internet to server, internet to lan, lan to server, lan to
	internet, server to internet, and server to lan) ... I *feel* that it makes
	better logical sense to setup user chains for each direction, and 
	*then* have, at the top of each directional chain a jump to a chain
	that handles things that go in all directions ( i.e. established related 
	and dns and things), then append rules that apply to that specific direction.

	From a system load perspective I recall that minimizing the number of rules
	a packet must traverse lowers load.  Does my logic fall down somehwere here
	that I am missing?  From a facility point of view, does anyone have comments
	about ease of use/debug/tracing/problem solving?
	
	Is the use of -m multiport to put several accepted ports into one rule an 
	imporovement in efficiency (a la fewer rules to traverse) or a burden based
	on something in the multiport code adding load?

	Ummm ... okay .. there are several other questions boiling about in my brain,
	but 1) its too darned late at night to get them out coherently and 2) its 
	time for bed. (gotta get up at 05:15 fer work)

	Please don't suggest any packages that setup rules for me.  I want the
	challenge of doing this m'self. (with a little input from the list of course)

	Thanks for any and all assitance
-- 

	Alistair Tonner
	nerdnet.ca
	Senior Systems Analyst - RSS
	
     Any sufficiently advanced technology will have the appearance of magic.
	Lets get magical!

Re: redesigning my firewall -- concepts and suggestions for a more structured layout

[Chris Brenton]

On Fri, 2003-09-26 at 00:31, Alistair Tonner wrote:
>
> 	My firewall has over time 	
> 	modified and grown, and twiddled its way into a morass of rules that last
> 	week gave me utter fits when I inserted a rule in which I goofed, and b0rked
> 	the internal network filesharing system.  And couldn't see it right off as to 
> 	why ... 

One of the things I'm big on is testing policies when ever changes get
made. The old "nmap on one side, tcpdump on the other" to verify the
policy is what you expect it to be. I've caught a lot of nasty stuff
that way (like accidentally permitting the DNS on the DMZ to access
TCP/UDP 53 on all internal systems).

> 	I am endevouring to remake the basic "my multi-pc home lan needs
> 	a firewall" firewall into something more organized, and I intend, as an
> 	exercise to write it *cough* myself.  My question is .... given the above
> 	basic premise, and a DROP default policy across all chains, Is it more
> 	effcient, processing wise, to have all the rules in a flat line, or, since it
> 	can make things easier to debug, have it parsed up in user chains.

Unless you are talking a lot of rules (like a few hundred given decent
hardware) I think this is a personal choice. Really it comes down to
your thought process, is it liniar or multitask? If the former, keep the
rules in a row. If the latter, break them up what ever way makes the
most sense to you. The idea is to keep the rule base clear enough that
you don't shoot yourself in the foot. ;-)

> 	My logic is this.  I can break my network traffic flow into 6 directionally
> 	oriented chains ( internet to server, internet to lan, lan to server, lan to
> 	internet, server to internet, and server to lan) ... I *feel* that it makes
> 	better logical sense to setup user chains for each direction, and 
> 	*then* have, at the top of each directional chain a jump to a chain
> 	that handles things that go in all directions ( i.e. established related 
> 	and dns and things), then append rules that apply to that specific direction.

If this makes the most sense to you and will help you keep the flow
straight, do it this way. :-)

> 	From a system load perspective I recall that minimizing the number of rules
> 	a packet must traverse lowers load.  Does my logic fall down somehwere here
> 	that I am missing? 

Not at all. First off, this rule is a little fuzzy in that the break
point is at different spots for different firewalls. For example I've
seen a performance increase with Cisco IOS by reordering as few as 50
rules. I've reordered 500+ rules on Netscreen 1000's with no noticable
difference in performance.

The break point for Netscreen (in my experience) is around 150-200
rules. Hit that number of rules and it might make sense to reorder for
performance reasons. Your mileage may vary. 

Now with all that said, I think your idea makes a lot of sense and would
certainly help to minimize the number of rules that get processed.
Again, unless you are talking 150+ rules, the big thing you want to
focus on is setting up the rules in a way that makes sense to you. If
breaking it out by direction fits that for you, then that's the way to
go.

> 	Is the use of -m multiport to put several accepted ports into one rule an 
> 	imporovement in efficiency (a la fewer rules to traverse) or a burden based
> 	on something in the multiport code adding load?

Its a different purpose. If you are looking to process connection
establishment to multiple ports in a single rule, something like:
iptables -A INPUT -i eth0 -p tcp -d 0/0 --dport 135:139 -j LOG
--log-prefix " MS_CRAP "

will do the trick. The multiport option is designed to match people
hitting multiple server ports, for example during a port scan.

> 	Please don't suggest any packages that setup rules for me.  I want the
> 	challenge of doing this m'self. (with a little input from the list of course)

Would not think of it. ;-)

One thing I would suggest however is a set of rules that makes the log
review process a bit easier however. I have a bunch of rules like this:

iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL SYN -d 0/0 --dport
17300 -j LOG --log-prefix " KUANG2_SCAN "
iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL SYN -d 0/0 --dport
17300 -j REJECT --reject-with icmp-host-unreachable
iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL SYN,FIN -j LOG
--log-prefix " SYNFINSCAN "
iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL SYN,FIN -j REJECT
--reject-with icmp-host-unreachable

Now each morning I run a cron job that is basically a bunch of grep
commands that puts all kang2 traffic in a single file, synfinscans in a
single file, etc. I then focus on the interesting stuff that is left
over that I don't have a label for. This makes log review go 8much*
faster.

HTH,
C

RE: redesigning my firewall -- concepts and suggestions for a more structured layout

[Daniel Chemko]

I do this in the same way you suggest. The only thing my FORWARD chain
does is pass up rules to chains that handle interface-interface rules,
then do policy decisions once the packet has failed to be accepted by
the other chains.



-----Original Message-----
From: Alistair Tonner [mailto:Alistair@nerdnet.ca] 
Sent: Thursday, September 25, 2003 9:31 PM
To: netfilter@lists.netfilter.org
Subject: redesigning my firewall -- concepts and suggestions for a more
structured layout


	Okay ... 
	    I've been reading, watching and sometimes chipping in on
this list for a 
	while now.  I started with Oskar Andreassens (hope I got that
right, and 
	I hope some deity somewhere blesses the man for his work)  basic
script
	tutorial to set my firewall up originally.  My firewall has over
time 	
	modified and grown, and twiddled its way into a morass of rules
that last
	week gave me utter fits when I inserted a rule in which I
goofed, and b0rked
	the internal network filesharing system.  And couldn't see it
right off as to 
	why ... 

	I am endevouring to remake the basic "my multi-pc home lan needs
	a firewall" firewall into something more organized, and I
intend, as an
	exercise to write it *cough* myself.  My question is .... given
the above
	basic premise, and a DROP default policy across all chains, Is
it more
	effcient, processing wise, to have all the rules in a flat line,
or, since it
	can make things easier to debug, have it parsed up in user
chains.

	My logic is this.  I can break my network traffic flow into 6
directionally
	oriented chains ( internet to server, internet to lan, lan to
server, lan to
	internet, server to internet, and server to lan) ... I *feel*
that it makes
	better logical sense to setup user chains for each direction,
and 
	*then* have, at the top of each directional chain a jump to a
chain
	that handles things that go in all directions ( i.e. established
related 
	and dns and things), then append rules that apply to that
specific direction.

	From a system load perspective I recall that minimizing the
number of rules
	a packet must traverse lowers load.  Does my logic fall down
somehwere here
	that I am missing?  From a facility point of view, does anyone
have comments
	about ease of use/debug/tracing/problem solving?
	
	Is the use of -m multiport to put several accepted ports into
one rule an 
	imporovement in efficiency (a la fewer rules to traverse) or a
burden based
	on something in the multiport code adding load?

	Ummm ... okay .. there are several other questions boiling about
in my brain,
	but 1) its too darned late at night to get them out coherently
and 2) its 
	time for bed. (gotta get up at 05:15 fer work)

	Please don't suggest any packages that setup rules for me.  I
want the
	challenge of doing this m'self. (with a little input from the
list of course)

	Thanks for any and all assitance
-- 

	Alistair Tonner
	nerdnet.ca
	Senior Systems Analyst - RSS
	
     Any sufficiently advanced technology will have the appearance of
magic.
	Lets get magical!