On Tuesday 02 March 2004 23:34, Gilmore, Eric wrote:
Well I totally understand what you're saying about "ease of setup". But I believe the reasons I was given for using iptables instead of SuSEfirewall went something like, "it's quicker to re-establish connectivity if the firewall machine burns down..." and "we want to standardize across all our systems...yada, yada". Even though I had a working instance of SuSEfirewall2 in place doing exactly what I needed it to do. <sigh>
I do understand. I myself sometimes use SuSEfirewall, sometimes I use some intelligent builder script, sometimes I just cut 'n paste something together. However, I have a very clear idea about what to put in and where and why. I'm not saying you don't, but I fear it when people first make a 'working solution' and then start to fill the holes later on... Oh yeah, another thing: If standardization is the goal, isn't there a working template already ? Also I would stronly advise you to add extensive comments inside the firewall scriptfile. Trust me, if you look at your own filter a year from now you will not recognize it (much less admit to writing it ;-) and documentation may make a very big difference.
And yes I do understand the security implications of doing it this way (Open then close) this was to be more of a test instance where access from the internet would only be given to certain machines, not sub-nets, not lans, machines. There will be approx. 3-4 attaching to it from the internet via FTP, ssh, AFP & SAMBA.
Ok. Well, my time is too short to help you design a filter. However, upon examination I found some errors (or at least inconsistencies). iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT You really should change this. Why not make policy DENY, and (for now) put a rule at the end of your script accepting anything that was not yet accepted ? It gives you the same result but without having to start all over by the time you change the default policy. And this way you can also have that logged. iptables -A INPUT -i $EXTIF -m state --state ESTABLISHED,RELATED -j ACCEPT This rule allows for return traffic TO the firewall (its irrelevant to the LANs though) As I need to reference this rule later, lets call this rule(1) iptables -A OUTPUT -o $EXTIF -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT Lets the firewall connect to internet. Ok. iptables -A INPUT -i $EXTIF -j ACCEPT Well, this rule makes rule(1) totally worthless, i.e. it supersedes it completely. In addition it allows for new connections which rule(1) did not. echo "Adding Masquerade support for 192.0.0.0 subnet..." iptables -A FORWARD -i $EXTIF -o $INTIF1 -m state --state ESTABLISHED,RELATED -j ACCEPT Hm, I see no masquerading being done here. This is just for return-traffic. Maybe I'm out on a limb here but why don't you make just 1 (one) rule that handles all state ESTABLISHED,RELATED traffic for the whole filter: iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i $INTIF1 -o $EXTIF -j ACCEPT Same here, where is the masquerading? I see no "-t nat" postrouting chain. echo "Adding Masquerade support for 192.0.5.0 subnet..." iptables -A FORWARD -i $EXTIF -o $INTIF2 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i $INTIF2 -o $EXTIF -j ACCEPT The same goes for that second LAN echo "Allowing traffic between internal networks..." iptables -A FORWARD -i $INTIF1 -o $INTIF2 -m state --state ESTABLISHED,RELATED -j ACCEPT If you omit state NEW how could anyone ever connect ? In fact why don't you get rid of this --state condition altogether ? (I call this one rule(2) btw) iptables -A FORWARD -i $INTIF2 -o $INTIF1 -j ACCEPT iptables -A FORWARD -i $INTIF2 -o $INTIF1 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i $INTIF1 -o $INTIF2 -j ACCEPT Hum. Again, you do weird things. The last rule overrules rule(2) totally, and the same goes for the two rules in between; one supersedes the other. However, LAN to LAN connections should hereby fully work now. (Provided your routing table entries are correct of course...!) iptables -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE Ah, here is the actual masquerading done (not above...) echo "Associating internal address 192.0.0.2 with external address 128.0.0.2" iptables -t nat -A PREROUTING -p tcp --dst 128.0.0.2 -j DNAT --to-destination 192.0.0.2 iptables -t nat -A PREROUTING -p udp --dst 128.0.0.2 -j DNAT --to-destination 192.0.0.2 iptables -t nat -A PREROUTING -p icmp --dst 128.0.0.2 -j DNAT --to-destination 192.0.0.2 These look okay... iptables -t nat -A POSTROUTING -p tcp --dst 128.0.0.2 -j SNAT --to-source 192.0.0.2 iptables -t nat -A POSTROUTING -p udp --dst 128.0.0.2 -j SNAT --to-source 192.0.0.2 iptables -t nat -A POSTROUTING -p icmp --dst 128.0.0.2 -j SNAT --to-source 192.0.0.2 If I'm not mistaken the main masquerading rule should've taken care of this, so these last 3 rules are fully redundant(?). AFAIK... Hum, then again, maybe not; you use three addresses at the external interface so -at second glance- these may indeed be needed not to fsck up the routing. <snip> I missed the parts where all the kernel anti spoofing and IP forwarding are being done. Where do you do that ? In fact, a lot seems to be missing, like dropping 'surely evil' traffic, some -possibly needed- conntrack modules, maybe a "--state state INVALID" rule, and also you would want to prevent all kind of leaking of [samba] broadcast traffic. However that might interfere with your ability to use samba from the internet (which remains a VERY BAD idea, I really cannot overstate that !) Still, from this script, with its inconsistencies, I cannot see why LAN to LAN connections wouldn't work. (And neither for samba.) Maarten