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 > > --state ESTABLISHED -j ACCEPT > > 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 ACCEPTRE -j LOGREJECT iptables -A FORWARD -i eth0 -s 192.168.0.0/24 -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 192.168.0.0/24 -i eth1 -p tcp --sport 80 -m time --timestart 14:00 --timestop 16:00 --days Mon,Tue,Wed,Thu,Fri -j ACCEPTRE 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