[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Firewall-troubleshooting

On Tuesday, 5 de July de 2005 14:11, Michael Stone wrote:
> On Tue, Jul 05, 2005 at 10:00:53PM +1000, Daniel Pittman wrote:
> >/sbin/iptables -t filter -A in_world_http_s1 -p tcp --sport 1024:65535
> > --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT /sbin/iptables -t
> > filter -A out_world_http_s1 -p tcp --sport 80 --dport 1024:65535 -m state
> IMHO, this is fairly redundant (and inefficient) unless you don't trust
> your firewall. (And in that case, why use it?) The examples of things
> that might require additional checking (e.g., ftp data connection) are
> arguably valid valid, but those are *RELATED* sessions, not
> *ESTABLISHED* sessions.

Let's write another example, where you allow navigation from 14 to 16 :

iptables -A ACCEPTRE -m state --state RELATED,ESTABLISHED -j ACCEPT

iptables -A FORWARD -i eth0 -s -o eth1 -p tcp --dport 80 -m 
time --timestart 14:00 --timestop 16:00 --days Mon,Tue,Wed,Thu,Fri -j ACCEPT

iptables -A FORWARD -o eth0 -d -i eth1 -p tcp --sport 80 -m 
time --timestart 14:00 --timestop 16:00 --days Mon,Tue,Wed,Thu,Fri -j 

Does that make any more sense? If you accept all R/E packets at the beggining 
of the script, you won't be able to stop the connections. May the user have a 
proxy somewhere, those time-based rules are easily fooled. If you accept the 
R/E packets at the end of the script, you must yet do exactly the same thing 
I've done or reject the incoming packets in all other time spans.

But the same applies to any other rule where you must control things down to 
the packet level. Think of packet size, marking, logging, level7 filtering, 
complicated routing (even load balancing/"bonding"), and so on.

About this being inefficient : current typical firewall computers are grossly 
overpowered, so some low-time-consuming additional rules won't make any 
difference. CPU consumtion in a firewall comes from squid, level7 filtering, 
logging, etc... not from some basic iptables rules. 

And about this cluttering the firewall: usually the FORWARD chain is splitted 
in source-destination chains, so not only the added rules don't clutter the 
chains, but also the *clarify* what's going on in them.

> If you're going to do something like the above
> you're better off just unloading the state module and setting up port
> filters (which is effectively what you're doing).

That's not true. Notice the STATE module. It's not the same as unstateful 
firewalling, where you can be easily fooled by tcp-flags weird games.
We talk about using the stateful filtering, without limiting ourselves 
by its easy shortcut.

When the ipchains to iptables switch is done, the first thing one thinks is : 
"yahoo! let's forget about states!" But the purpose of the STATE and 
CONNTRACK modules is to empower the user with the ability to deploy a 
stateful firewall, not to provide a single and universal shortcut that 
prevents the usage of other nifty modules.

Also think about debugging :
- With the "explicit R/E accepting" you get to know where (and so, why) a 
packet is accepted, and the path through there. It even enables you to do 
basic accounting.
- With the "accept R/E first" you only know that the packet belongs a 
established or related connection. And may a conntrack module misbehave,
not even that.
- With the "accept R/E last", you know the same as the 2nd case. The 
difference lies in that this way you can easily shoot yourself in your foot, 
and you won't easily know why.

All it takes is some discipline when handwriting your firewall.
And if you are using a tool, not even that. But for that the tools must not 
shoot their user's feet ;)

Eloi Granado  (eloi.granado@millorsoft.net)
PGP Key: http://eloi.millorsoft.es/pgp-publickey.asc

Attachment: pgpNHl0BG7xgD.pgp
Description: PGP signature

Reply to: