RE: [suse-security] firewall help..
Sorry about that --> off list <-- 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> 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. -----Original Message----- From: Maarten J H van den Berg [mailto:maarten@vbvb.nl] Sent: Tuesday, March 02, 2004 4:49 PM To: suse-security@suse.com Subject: Re: [suse-security] firewall help.. Hi Eric, Please reply to the list, not to me directly. I read the list. There is no need to take this off-list. On Tuesday 02 March 2004 18:21, you wrote:
Maarten,
To answer: -if you mean allow routing between the networks, yes -the ip's I used in the note are examples
OK
-I did use SuSe firewall2, but my dept. wanted to use iptables instead
Does your dept. realize that SuSEfirewall is just a convenient (and complex) "wrapper" for iptables ?
:(
Indeed. Building filters from scratch is difficult. I tend to avoid it when possible, i.e. use some framework that more or less suits your needs.
-from anywhere means the internet also. I haven't gotten to the part
Whoa! I don't plan to reeducate your dept. but you really shouldn't be doing that, not even considering it. What is the goal here ? If it is offering access to remote offices / staff users then read up on deploying a VPN. If the goal is offering access to anybody, read up on using other means (http / ftp / whatever). Just my opinion of course, but my bet is you'll find that most anybody here will agree with me on this... I have not looked at your script in detail yet, but it seems to me you maybe had better rethink your strategy. You cannot "fix" things afterwards with firewallrules, you need to get it right and logical from the start. For instance, you need to draft policies. If you are not completely clear on what you have to do then I would suggest you are not well advised to build your own filter from scratch.
where you actually start blocking things yet. This is the initial setup.
That approach won't work. That would be akin to checking a door for leakage when it's open. In other words, if you do use that approach you get connectivity, but not security. Maarten
-----Original Message----- From: maarten van den Berg [mailto:maarten@vbvb.nl] Sent: Tuesday, March 02, 2004 11:52 AM To: suse-security@suse.com Subject: Re: [suse-security] firewall help..
On Tuesday 02 March 2004 17:05, Gilmore, Eric wrote:
Can anyone give me a clue? The basics are: 1 machine: SuSE 8.2 3 nics 2 internal networks (examples): $INTLAN1:> 192.0.0.2 $INTLAN2:> 192.0.5.2
Does LAN1 trust LAN2 and vice versa ?
3 good ip's (examples): eth0> 128.0.0.1 eth0:1> 128.0.0.2 eth0:2> 128.0.0.3
2 spoofed ip's: $INTIF1> 192.0.5.2 $INTIF2> 192.0.48.3
If by spoofed you mean reserved,internal adresses: be aware that you're outside the allowed range (192.168.0.0/16) (See RFC 1918)
works: -connecting from the internet/external LAN to all machines via (ssh,
FTP, HTTP) not: -connecting between $INTLAN1 & $INTLAN2
If full and mutual trust is expected / wanted: set FW_ALLOW_CLASS_ROUTING="yes" Hm... reading on I notice you don't use the Suse firewall filter. Why
not ?
-samba connections from anywhere
Explain. From ANYwhere implies "from internet". Surely you CAN not want that. If you mean from LAN1 <-> LAN2 then either the above class routing will fix it (when you use AD + properly configured DNS servers) or you may need to specify the exact share by IPnumber (net use * \\192....\C If both are not options you will need to find a way to relay the Netbios
broadcast(s) over the firewall. Dunno offhand how to do that (and wouldn't want to either).
-afp (apple) connections from anywhere
See samba, the services are fairly similar.
Maarten
-- Yes of course I'm sure it's the red cable. I guarante[^%!/+)F#0c|'NO CARRIER
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
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
participants (2)
-
Gilmore, Eric
-
Maarten J H van den Berg