|
Joseph Mack wrote:
>
> Derek Glidden wrote:
>
> > If I understand the question, this would be the easiest way to go about
> > it. You'd start with something like this (INPUT or whatever default
> > table you're modifying):
> >
> > iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT
> > iptables -A INPUT -p tcp --dport 80 -s 192.168.1.0/24 -j ACCEPT
> > iptables -A INPUT -p tcp --dport 443 -s 192.168.1.0/24 -j ACCEPT
> > iptables -A INPUT -j SERVICES
> > iptables -A INPUT -j DROP
>
> > then change/modify the SERVICES chain to your heart's content to
> > add/remove new rules.
> .
> .
> > iptables -A SERVICES -p tcp --dport 25 -s 192.168.1.0/24 -j ACCEPT
>
> so the commands won't be traversed in the order I add them. If I start
> with an empty chain SERVICES as above (which is followed by the DROP rule),
> then I can later add/delete to the SERVICES chain and the packets
> will have to traverse all the SERVICES rules before they return
> to the default (here DROP) rule.
Not sure what you mean by this. They'll be traversed in the order in
which they are added into the INPUT (or whichever) table and then into
the SERVICES table. So if you add them to SERVICES in the order
"tcp/25", "tcp/23", "tcp/110", "tcp/143" they would be checked against
"tcp/22", "tcp/80" and "tcp/443" in the INPUT chain, in that order, then
against "tcp/25", "tcp/23", "tcp/110" and "tcp/143" in the SERVICES
chain and if they haven't matched any of those, they'll hit the DROP
rule and be bit-bucketed.
Do you need to be able to insert them in a particular order so they are
traversed in a particular order? In that case, your best bet is
probably, in whatever tool it is you're using to manipulate the iptables
rules, build up the appropriate ruleset "in memory" then 'iptables -F'
to flush the existing chains and recreate the tables with all your rules
in the "correct" order any time you need to manipulate the tables. It's
less elegant, but much easier than trying to "remember" where all the
rules fall into place in the tables so you can insert/remove by rule #.
It seems like it might be useful to have the most commonly used port be
the first rule so that if, for example, 95% of the traffic through the
firewall is http on port 80, it's not the last rule in your chain that
gets checked, causing extra overhead by running through all the
non-matching chains. But in some test situations we've done where I
work, I've managed to pretty much saturate a 100mbps connection into an
iptables-based firewall and a pretty hairy ruleset on a P-III 800Mhz
with very little CPU overhead. I'm sure you _could_ overload the CPU
with unecessarily complex iptables rules, but I think you'll overload
the network first.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
#!/usr/bin/perl -w
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map
{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;
$t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)
[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join
"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*
8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}
print+x"C*",@a}';s/x/pack+/g;eval
usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \
| extract_mpeg2 | mpeg2dec -
http://www.eff.org/ http://www.opendvd.org/
http://www.cs.cmu.edu/~dst/DeCSS/Gallery/
|
