ram and processor cycles for a firewall machine

ram and processor cycles for a firewall machine

[Askar]

hi all,
im in the process of changing my fw machine for that atm im simulating
and testing. I got a very fair question
1) How much RAM and and processor would be best for moderate firewall box?
Unfortunatly currently my company running the fw on a P-III 500MHz
with 128MB of RAM.
I am wondering if I change to default DROP things (atm its default
ACCEPT) aren't these specification kinda makes problem?

right now 75 users online the /proc/net/ip_conntrack shows 

egrep 'ESTABLISHED|ASSURED' /proc/net/ip_conntrack | wc -l
   4888
cat /proc/net/ip_conntrack | wc -l
   6511

well these number would probably little higher when 120 users online.
Is my current fw machine specs adequate for such ip_conntrack load?

regards
Askar
(after bouncing head on desk for days trying to get mine working, I'll make
your life a little easier)

Re: ram and processor cycles for a firewall machine

[Jose Maria Lopez]

El vie, 01 de 10 de 2004 a las 08:35, Askar escribió:
> hi all,
> im in the process of changing my fw machine for that atm im simulating
> and testing. I got a very fair question
> 1) How much RAM and and processor would be best for moderate firewall box?
> Unfortunatly currently my company running the fw on a P-III 500MHz
> with 128MB of RAM.

With the actual price of RAM you could add some more RAM. The
processor can be OK, but I'd do some tests to see how it works.
I'm running a similar firewall in a Celeron 800Mhz and it works
well, but it's only used as a firewall and the rules are
optimized. I advice you to optimize the traversing of the rules
you have as much as you can. That can give you a performance
boost.

-- 
Jose Maria Lopez Hernandez
Director Tecnico de bgSEC
jkerouac@bgsec.com
bgSEC Seguridad y Consultoria de Sistemas Informaticos
http://www.bgsec.com
ESPAÑA

The only people for me are the mad ones -- the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn, burn
like fabulous yellow Roman candles.
                -- Jack Kerouac, "On the Road"

Re: ram and processor cycles for a firewall machine

[Jason Opperisano]

On Fri, 2004-10-01 at 02:35, Askar wrote:
> hi all,
> im in the process of changing my fw machine for that atm im simulating
> and testing. I got a very fair question
> 1) How much RAM and and processor would be best for moderate firewall box?
> Unfortunatly currently my company running the fw on a P-III 500MHz
> with 128MB of RAM.
> I am wondering if I change to default DROP things (atm its default
> ACCEPT) aren't these specification kinda makes problem?
> 
> right now 75 users online the /proc/net/ip_conntrack shows 
> 
> egrep 'ESTABLISHED|ASSURED' /proc/net/ip_conntrack | wc -l
>    4888
> cat /proc/net/ip_conntrack | wc -l
>    6511

(6511 * 360) / 1024 / 1024 = 2.235 MB

even if you need 5 times that number of conntrack entries at peak
load--you still would require about 11 MB of kernel memory for conntrack
entries.

if you machine has 128 MB RAM--the automatic setting for
ip_conntrack_max should be somewhere around 8192.  you could easily bump
that number up to 32768 or 65536.

keep in mind that this is *kernel* memory; and therefore, cannot be
paged.  if the machine needs to do "other things" (which is not a good
idea) you may want to bump up the memory just to be safe.

> well these number would probably little higher when 120 users online.
> Is my current fw machine specs adequate for such ip_conntrack load?

i would say so.  one thing that you might want to keep in mind is that
if going to a "default drop" is going to cause a huge amount of logging,
you might want to use the "-m limit" match in your "-j LOG" rules and
make the rotation of your log files more aggressive.

-j

-- 
Jason Opperisano <opie@817west.com>

Re: ram and processor cycles for a firewall machine

[Askar]

thanks jose alot, okay i will upgrade ram to 128 * 2 = 256MB thanks,
however where should I look for optimization the iptables rules?
any link will be greatly appreciated

On Fri, 01 Oct 2004 09:37:13 -0400, Jason Opperisano <opie@817west.com> wrote:
> On Fri, 2004-10-01 at 02:35, Askar wrote:
> > hi all,
> > im in the process of changing my fw machine for that atm im simulating
> > and testing. I got a very fair question
> > 1) How much RAM and and processor would be best for moderate firewall box?
> > Unfortunatly currently my company running the fw on a P-III 500MHz
> > with 128MB of RAM.
> > I am wondering if I change to default DROP things (atm its default
> > ACCEPT) aren't these specification kinda makes problem?
> >
> > right now 75 users online the /proc/net/ip_conntrack shows
> >
> > egrep 'ESTABLISHED|ASSURED' /proc/net/ip_conntrack | wc -l
> >    4888
> > cat /proc/net/ip_conntrack | wc -l
> >    6511
> 
> (6511 * 360) / 1024 / 1024 = 2.235 MB
> 
> even if you need 5 times that number of conntrack entries at peak
> load--you still would require about 11 MB of kernel memory for conntrack
> entries.
> 
> if you machine has 128 MB RAM--the automatic setting for
> ip_conntrack_max should be somewhere around 8192.  you could easily bump
> that number up to 32768 or 65536.
If i go with 128mb of ram which number should I choice for conntrack
32768 or 65536?
> 
> keep in mind that this is *kernel* memory; and therefore, cannot be
> paged.  if the machine needs to do "other things" (which is not a good
> idea) you may want to bump up the memory just to be safe.
sure I will move my apache to another machine which is atm running on
the same machine for MRTG.
> 
> > well these number would probably little higher when 120 users online.
> > Is my current fw machine specs adequate for such ip_conntrack load?
> 
> i would say so.  one thing that you might want to keep in mind is that
> if going to a "default drop" is going to cause a huge amount of logging,
> you might want to use the "-m limit" match in your "-j LOG" rules and
> make the rotation of your log files more aggressive.
okay I will to do fa few logging, however in starting I have to do
logging for testing and finalizing, however it would be nice of you if
you give me rules for -m limit for well known DROP ports that is 135,
445 etc hmm say 1 log in 5 minutes for these ports :)
Im getting lot of help and learning lot of new things through this great list :D
regards
askar
> 
> -j
> 
> --
> Jason Opperisano <opie@817west.com>
> 
> 



-- 
(after bouncing head on desk for days trying to get mine working, I'll make
your life a little easier)

Re: ram and processor cycles for a firewall machine

[Mike]

Me too--- I'd like to learn what it means to optimize my iptables. 
After using iptables for 2 years but never really taking the time to
digest what it means to filter data across tables, I'm trying to
really understand what's going on.  I've started with Oskar
Andreasson's tutorial, but I definitely don't see anything about
optimization in there.

Any links on the subject would be great.

Thanks,

Mike  


On Sat, 2 Oct 2004 01:29:41 +0600, Askar <askarali@gmail.com> wrote:
> thanks jose alot, okay i will upgrade ram to 128 * 2 = 256MB thanks,
> however where should I look for optimization the iptables rules?
> any link will be greatly appreciated
> 
>

Re: ram and processor cycles for a firewall machine

[Aleksandar Milivojevic]

Mike wrote:
> Me too--- I'd like to learn what it means to optimize my iptables. 
> After using iptables for 2 years but never really taking the time to
> digest what it means to filter data across tables, I'm trying to
> really understand what's going on.  I've started with Oskar
> Andreasson's tutorial, but I definitely don't see anything about
> optimization in there.

It can mean many things, and depends on actual configuration and needs. 
  Idea behind optimization is to minimize average number of rules that 
packets will traverse.

Simple example could be if you have bunch of rules with "-m state 
--state NEW" and than somewhere at the end you have catch-all "-m state 
--state ESTABLISHED", moving that rule to the top will make huge 
difference (because majority of packets will be matched by it).

On a very bussy site with simple set of rules (but huge number of 
simultanious connections) eliminating connection tracking could increase 
performance (if traversing couple of rules is faster than lookup into a 
huge table, of course).  I don't know how connection tracking table is 
organized and how the entries are looked up, so don't ask me for a 
numbers when it makes sense not to use connection tracking, but majority 
of people probably wouldn't benefit from turning it off.  However, do 
note that this will be tradeoff between performance and security.

Another example is if you have bunch of rules allowing access to service 
only from certain IP addresses (say there's 20 of them).  Creating user 
defined chain for that service (for example -p tcp --dport 80 -j HTTP), 
and than checking if packet is from one of 20 allowed IP addresses means 
that all other packets will have to be checked only by 1 rule, not by 20 
of them.  Or you can go the other way around, if you are checking single 
IP address agains number of services (in this case using multiport 
module can be usefull too).  Something like -s a.b.c.d -j CLIENT_A.

These are just some simple and obvious examples.  The idea is to 
minimize number of checks that need to be done on a packet before it is 
accepted or dropped.  Obviously, what can be done differs from one 
config to another.

P.S.
Offtopic: seems that Google mail is becoming quite popular on the 
mailinglist...

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

Re: ram and processor cycles for a firewall machine

[Askar]

Thanks Jason, Aleksandar now the things kinda clear to me about the
magic of "optimize" a ruleset :)

regards
askar

On Fri, 01 Oct 2004 16:09:03 -0500, Aleksandar Milivojevic
<amilivojevic@pbl.ca> wrote:
> Mike wrote:
> > Me too--- I'd like to learn what it means to optimize my iptables.
> > After using iptables for 2 years but never really taking the time to
> > digest what it means to filter data across tables, I'm trying to
> > really understand what's going on.  I've started with Oskar
> > Andreasson's tutorial, but I definitely don't see anything about
> > optimization in there.
> 
> It can mean many things, and depends on actual configuration and needs.
>   Idea behind optimization is to minimize average number of rules that
> packets will traverse.
> 
> Simple example could be if you have bunch of rules with "-m state
> --state NEW" and than somewhere at the end you have catch-all "-m state
> --state ESTABLISHED", moving that rule to the top will make huge
> difference (because majority of packets will be matched by it).
> 
> On a very bussy site with simple set of rules (but huge number of
> simultanious connections) eliminating connection tracking could increase
> performance (if traversing couple of rules is faster than lookup into a
> huge table, of course).  I don't know how connection tracking table is
> organized and how the entries are looked up, so don't ask me for a
> numbers when it makes sense not to use connection tracking, but majority
> of people probably wouldn't benefit from turning it off.  However, do
> note that this will be tradeoff between performance and security.
> 
> Another example is if you have bunch of rules allowing access to service
> only from certain IP addresses (say there's 20 of them).  Creating user
> defined chain for that service (for example -p tcp --dport 80 -j HTTP),
> and than checking if packet is from one of 20 allowed IP addresses means
> that all other packets will have to be checked only by 1 rule, not by 20
> of them.  Or you can go the other way around, if you are checking single
> IP address agains number of services (in this case using multiport
> module can be usefull too).  Something like -s a.b.c.d -j CLIENT_A.
> 
> These are just some simple and obvious examples.  The idea is to
> minimize number of checks that need to be done on a packet before it is
> accepted or dropped.  Obviously, what can be done differs from one
> config to another.
> 
> P.S.
> Offtopic: seems that Google mail is becoming quite popular on the
> mailinglist...
> 
> --
> Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
> Systems Administrator                           1499 Buffalo Place
> Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7
> 
> 



-- 
(after bouncing head on desk for days trying to get mine working, I'll make
your life a little easier)

Re: ram and processor cycles for a firewall machine

[Mike]

Sorry for the slow response.
My thanks also to Jason, Daniel, and Aleksandar for their thoughtful responses.
Joining this list and perusing others' daily networking/routing issues
has been a huge wake-up call to me.

I'm very thankful for this community of developers, admins., and users.

Mike


On Sat, 2 Oct 2004 12:19:27 +0600, Askar <askarali@gmail.com> wrote:
> Thanks Jason, Aleksandar now the things kinda clear to me about the
> magic of "optimize" a ruleset :)
> 
> regards
> askar
> 
> On Fri, 01 Oct 2004 16:09:03 -0500, Aleksandar Milivojevic
> 
> 
> <amilivojevic@pbl.ca> wrote:
> > Mike wrote:
> > > Me too--- I'd like to learn what it means to optimize my iptables.
> > > After using iptables for 2 years but never really taking the time to
> > > digest what it means to filter data across tables, I'm trying to
> > > really understand what's going on.  I've started with Oskar
> > > Andreasson's tutorial, but I definitely don't see anything about
> > > optimization in there.
> >
> > It can mean many things, and depends on actual configuration and needs.
> >   Idea behind optimization is to minimize average number of rules that
> > packets will traverse.
> >
> > Simple example could be if you have bunch of rules with "-m state
> > --state NEW" and than somewhere at the end you have catch-all "-m state
> > --state ESTABLISHED", moving that rule to the top will make huge
> > difference (because majority of packets will be matched by it).
> >
> > On a very bussy site with simple set of rules (but huge number of
> > simultanious connections) eliminating connection tracking could increase
> > performance (if traversing couple of rules is faster than lookup into a
> > huge table, of course).  I don't know how connection tracking table is
> > organized and how the entries are looked up, so don't ask me for a
> > numbers when it makes sense not to use connection tracking, but majority
> > of people probably wouldn't benefit from turning it off.  However, do
> > note that this will be tradeoff between performance and security.
> >
> > Another example is if you have bunch of rules allowing access to service
> > only from certain IP addresses (say there's 20 of them).  Creating user
> > defined chain for that service (for example -p tcp --dport 80 -j HTTP),
> > and than checking if packet is from one of 20 allowed IP addresses means
> > that all other packets will have to be checked only by 1 rule, not by 20
> > of them.  Or you can go the other way around, if you are checking single
> > IP address agains number of services (in this case using multiport
> > module can be usefull too).  Something like -s a.b.c.d -j CLIENT_A.
> >
> > These are just some simple and obvious examples.  The idea is to
> > minimize number of checks that need to be done on a packet before it is
> > accepted or dropped.  Obviously, what can be done differs from one
> > config to another.
> >
> > P.S.
> > Offtopic: seems that Google mail is becoming quite popular on the
> > mailinglist...
> >
> > --
> > Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
> > Systems Administrator                           1499 Buffalo Place
> > Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7
> >
> >
> 
> 
> --
> (after bouncing head on desk for days trying to get mine working, I'll make
> your life a little easier)
> 
>

RE: ram and processor cycles for a firewall machine

[Daniel Chemko]

Askar wrote:
> thanks jose alot, okay i will upgrade ram to 128 * 2 = 256MB thanks,
> however where should I look for optimization the iptables rules?
> any link will be greatly appreciated

This is more of a manual activity. Things to speed up the ruleset would
be:

Putting the ESTABLISHED,RELATED rule above all others in its respective
chain. This avoids the lookups for all the match rules.

If you have a match rule with a 100000 hits during an interval, put it
before a match rule with 100 hits. This way, the inefficiency of
processing the more obscure rule is minimized.

This isn't so much of a big deal unless you have either insane amounts
of traffic, or many very very small sessions. Hosting 'normal' users, I
have 99.97% of my traffic hitting the ESTABLISHED,RELATED filtering
rule, so the efficiency of the other rules in my stack is
unconsequential.


# All Traffic
AAA="`iptables -t filter -nvxL FORWARD | egrep -v 'FORWARD|pkts' | awk
'{print $2}' | sed s/"$"/"+"/`"; echo ${AAA}0| bc

# Only ESTABLISHED,RELATED traffic
AAA="`iptables -t filter -nvxL FORWARD | grep 'RELATED,ESTABLISHED' |
awk '{print $2}' | sed s/"$"/"+"/`"; echo ${AAA}0| bc

% of traffic in ESTABLISHED,RELATED is just the second number divided by
the first.  The larger the percentage, the less any subsequent rule
arrangement will matter.