Hello, I have set up a backup file server for a client. They are putting it in an ISP on two live IPs (against my strong recommendation not to). I'm tired of fighting them about it, it's their problem now. So I setup SuSEfirewall2. However, when I start SuSEfirewall2, it blocks of everything, even the ports I specified to be open. It's running SUSE 9.1 Pro with kernel-smp-2.6.4-52. Everything is up to date through YOU except the kernel itself (as the kernel update renders the box non-bootable). Any ideas? Is this SuSEfirewall2 making trouble, or is it kernel level? I didn't have this problem with any other boxen with 9.1 on the original release kernel (either default or smp). If it is in fact SuSEfirewall2 at fault, what is the best way to setup iptables? I need ports 22 139 445 and 10000 open on both interfaces. Thank you -- Kind regards Hans du Plooy Newington Consulting Services hansdp at newingtoncs dot co dot za
Hans wrote regarding '[SLE] SuSEfirewall2 misbehaving' on Thu, Aug 19 at 03:03:
Hello,
I have set up a backup file server for a client. They are putting it in an ISP on two live IPs (against my strong recommendation not to). I'm tired of fighting them about it, it's their problem now.
So I setup SuSEfirewall2. However, when I start SuSEfirewall2, it blocks of everything, even the ports I specified to be open.
It's running SUSE 9.1 Pro with kernel-smp-2.6.4-52. Everything is up to date through YOU except the kernel itself (as the kernel update renders the box non-bootable).
Any ideas? Is this SuSEfirewall2 making trouble, or is it kernel level? I didn't have this problem with any other boxen with 9.1 on the original release kernel (either default or smp).
If it is in fact SuSEfirewall2 at fault, what is the best way to setup iptables? I need ports 22 139 445 and 10000 open on both interfaces.
#!/bin/sh IPTABLES="/usr/sbin/iptables" # all output OK $IPTABLES -F OUTPUT $IPTABLES -P OUTPUT -j ACCEPT # all forward bad $IPTABLES -F FORWARD $IPTABLES -P FORWARD -j REJECT # most input bad, except for a few ports $IPTABLES -F INPUT $IPTABLES -P INPUT -j DROP $IPTABLES -A INPUT -i lo -j ACCEPT $IPTABLES -A INPUT -p tcp --dport 22 -j ACCEPT $IPTABLES -A INPUT -p tcp --dport 139 -j ACCEPT $IPTABLES -A INPUT -p tcp --dport 445 -j ACCEPT $IPTABLES -A INPUT -p tcp --dport 1000 -j ACCEPT $IPTABLES -A INPUT -j DROP # yes, this is redundant. --Danny
Thanks, I'll give it a shot as soon as I get back to that particular machine On Thursday 19 August 2004 15:55, Danny Sauer wrote:
#!/bin/sh IPTABLES="/usr/sbin/iptables" # all output OK $IPTABLES -F OUTPUT $IPTABLES -P OUTPUT -j ACCEPT # all forward bad $IPTABLES -F FORWARD $IPTABLES -P FORWARD -j REJECT # most input bad, except for a few ports $IPTABLES -F INPUT $IPTABLES -P INPUT -j DROP $IPTABLES -A INPUT -i lo -j ACCEPT $IPTABLES -A INPUT -p tcp --dport 22 -j ACCEPT $IPTABLES -A INPUT -p tcp --dport 139 -j ACCEPT $IPTABLES -A INPUT -p tcp --dport 445 -j ACCEPT $IPTABLES -A INPUT -p tcp --dport 1000 -j ACCEPT $IPTABLES -A INPUT -j DROP # yes, this is redundant.
--Danny
-- Kind regards Hans du Plooy Newington Consulting Services hansdp at newingtoncs dot co dot za
Thanks Danny, I had to modify it slightly, iptables didn't seem to like REJECT (weird?). I have one problem left. The machine has two network cards. This firewall works peachy on the first, but the second still seems to be completely blocked. Looks like this: #!/bin/sh IPTABLES="/usr/sbin/iptables" # all output OK $IPTABLES -F OUTPUT $IPTABLES -P OUTPUT ACCEPT # all forward bad $IPTABLES -F FORWARD $IPTABLES -P FORWARD DROP # most input bad, except for a few ports $IPTABLES -F INPUT $IPTABLES -P INPUT DROP $IPTABLES -A INPUT -i lo -j ACCEPT $IPTABLES -A INPUT -p tcp --dport 22 -j ACCEPT $IPTABLES -A INPUT -p tcp --dport 137 -j ACCEPT $IPTABLES -A INPUT -p tcp --dport 138 -j ACCEPT $IPTABLES -A INPUT -p tcp --dport 139 -j ACCEPT $IPTABLES -A INPUT -p tcp --dport 445 -j ACCEPT $IPTABLES -A INPUT -p tcp --dport 10000 -j ACCEPT $IPTABLES -A INPUT -p icmp -j ACCEPT $IPTABLES -A INPUT -j DROP # yes, this is redundant. Any idea why? If I read correctly, if I don't specify the interface, it should apply across all interfacess? Thanks -- Kind regards Hans du Plooy Newington Consulting Services hansdp at newingtoncs dot co dot za
Thanks Danny,
I had to modify it slightly, iptables didn't seem to like REJECT (weird?). I have one problem left. The machine has two network cards. This firewall works peachy on the first, but the second still seems to be completely blocked. Looks like this: Found the problem - I was using the same cable to test both interfaces. So I
On Friday 20 August 2004 14:20, Hans du Plooy wrote: ping the ip on eth1, but it tries to reply from eth0 (which was unplugged). -- Kind regards Hans du Plooy Newington Consulting Services hansdp at newingtoncs dot co dot za
Hans wrote regarding 'Re: [SLE] SuSEfirewall2 misbehaving' on Fri, Aug 20 at 07:21:
Thanks Danny,
I had to modify it slightly, iptables didn't seem to like REJECT (weird?). I
Doh. The REJECT target is an extension now, rather than being built in like I remember from ipchains/ipfw. If you throw a "/sbin/modprobe ipt_REJECT" in there somewhere (or otherwise make that module load at boot, like in /etc/modulex.conf or something) REJECT oughtta work. I think DROP is probably just fine on that, though. If you're blocking internal access and external access, you might stick another rule on the end there (just before the last rule) to REJECT stuff with an internal source, just so you're not waiting for a timeout. I prefer DROP on external interfaces so it slows down port scanners, but internally I usually REJECT so the connecting application can return immediately. :) I'm glad it worked for you, anyway. --Danny
On Friday 20 August 2004 17:13, Danny Sauer wrote:
I think DROP is probably just fine on that, though. If you're blocking internal access and external access, you might stick another rule on the end there (just before the last rule) to REJECT stuff with an internal source, just so you're not waiting for a timeout. I prefer DROP on external interfaces so it slows down port scanners, but internally I usually REJECT so the connecting application can return immediately. :)
Thanks for your reply. Both are external interfaces, servicing two different machines. If something other than the machines that are *supposed* to connect to this machine, tries to connect to them, I won't feel sorry for them if they have to wait for a timeout. They shouldn't be talking to it at all. I just don't see why they want to put the box on live IPs - it's completely unnecessary. I guess that's why there are guys like us! Thanks for your help - I've never done iptables by hand before - relied on SuSEfirewall2. But this is the second time that it's given me grief. On a previous occasion I used a SUSE 9.0 box as a gateway, and for some reason, after months of reliable working, it just stopped forwarding, and nothing would fix it - I ended up reloading it. -- Kind regards Hans du Plooy Newington Consulting Services hansdp at newingtoncs dot co dot za
participants (2)
-
Danny Sauer
-
Hans du Plooy