SuSEfirewall2 - first ALPHA
For the desperate: SuSEfirewall2 v0.3 is available for testing from www.suse.de/~marc It installs without problem with a SuSEfirewall(1) installation, the only variable shared is the START_FW variable (well, with the result that both firewall will try to start when booting ;-) please note: due my current network probs at home I could not make real tests. so everyone who can check features, and if possible send me a fix for something which is not working - that would be great!! Q: What changed from SuSEfirewall(1) to SuSEfirewall2 A: Many things. Most important: it uses iptables (which is especially for 2.4 kernels) instead of ipchains. Visible changes: New commandline option "debug" which prints out the iptables commands, great to print the rules, and them modify them for you liking! Added the new options: FW_ALLOW_CLASS_ROUTING - allow routing between interfaces of the same class, e.g. two internal networks FW_ALLOW_FW_BROADCAST - allow broadcast packets to reach the firewall FW_ALLOW_PING_EXT - allow the internal/dmz to ping the internet FW_SERVICE_AUTODETECT - autodetect START_{NAMED,SMB,DHCPD} and DHCLIENT Renamed some variables, removed some, changed syntax (small changes) All forward,masquerading,trust definitions can now be very global or very fine-grained as you need it The logging looks different - hell this is iptables :-( It takes a bit longer to create the complex ruleset :-( Invisible changes: A packet has to traverse much less rules, so packet processing is faster Stateful packet checking is present now (thanks to the 2.4 kernel) More intelligent ICMP filtering and identd rejection Greets, Marc -- Marc Heuse, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: marc@suse.de Function: Security Research and Advisory PGP: "lynx -source http://www.suse.de/~marc/marc.pgp | pgp -fka" Key fingerprint = B5 07 B6 4E 9C EF 27 EE 16 D9 70 D4 87 B5 63 6C Private: http://www.suse.de/~marc SuSE: http://www.suse.de/security
Dear Marc, I hope it's ok that i sent this mail to the firewall mailing list. I see the following in /etc/init.d/setup status Chain forward_ext (1 references) pkts bytes target prot opt in out source destination 0 0 LOG all -- * * 192.168.2.0/24 0.0.0.0/0 LOG flags 6 level 4 prefix `SuSE-FW-DROP-ANTI-SPOOF' 0 0 DROP all -- * * 192.168.2.0/24 0.0.0.0/0 0 0 LOG all -- * * 192.168.2.0/23 0.0.0.0/0 LOG flags 6 level 4 prefix `SuSE-FW-DROP-ANTI-SPOOF' 0 0 DROP all -- * * 192.168.2.0/23 0.0.0.0/0 0 0 LOG all -- * * 0.0.0.0/0 192.168.2.1 LOG flags 6 level 4 prefix `SuSE-FW-DROP-CIRCUMVENTION' 0 0 DROP all -- * * 0.0.0.0/0 192.168.2.1 20 1120 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED icmp type 3 12 1008 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED icmp type 0 0 0 ACCEPT all -- * eth0 192.168.2.0/23 0.0.0.0/0 state NEW,RELATED,ESTABLISHED 75 4120 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 6 level 4 prefix `SuSE-FW-DROP-DEFAULT' 75 4120 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 The forward from the internet to my internal network is clearly dropped. I think there is something wrong with the line before the drop line. (direction, source destination witched). I didn't really have time to look into this. But i wanted to let you know that everything seems to work perfectly except this part. I think if the line would be: 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW,RELATED,ESTABLISHED It would already work, but it wouldn't be secure. I'm sorry for not be able to give you the answer right now. I will try later. Regards, Joop Boonen. I have attached the rc.firewall file and the status and the iptables -L file. Marc Heuse wrote:
For the desperate:
SuSEfirewall2 v0.3 is available for testing from www.suse.de/~marc It installs without problem with a SuSEfirewall(1) installation, the only variable shared is the START_FW variable (well, with the result that both firewall will try to start when booting ;-)
please note: due my current network probs at home I could not make real tests. so everyone who can check features, and if possible send me a fix for something which is not working - that would be great!!
Q: What changed from SuSEfirewall(1) to SuSEfirewall2 A: Many things. Most important: it uses iptables (which is especially for 2.4 kernels) instead of ipchains. Visible changes: New commandline option "debug" which prints out the iptables commands, great to print the rules, and them modify them for you liking! Added the new options: FW_ALLOW_CLASS_ROUTING - allow routing between interfaces of the same class, e.g. two internal networks FW_ALLOW_FW_BROADCAST - allow broadcast packets to reach the firewall FW_ALLOW_PING_EXT - allow the internal/dmz to ping the internet FW_SERVICE_AUTODETECT - autodetect START_{NAMED,SMB,DHCPD} and DHCLIENT Renamed some variables, removed some, changed syntax (small changes) All forward,masquerading,trust definitions can now be very global or very fine-grained as you need it The logging looks different - hell this is iptables :-( It takes a bit longer to create the complex ruleset :-( Invisible changes: A packet has to traverse much less rules, so packet processing is faster Stateful packet checking is present now (thanks to the 2.4 kernel) More intelligent ICMP filtering and identd rejection
Greets, Marc -- Marc Heuse, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: marc@suse.de Function: Security Research and Advisory PGP: "lynx -source http://www.suse.de/~marc/marc.pgp | pgp -fka" Key fingerprint = B5 07 B6 4E 9C EF 27 EE 16 D9 70 D4 87 B5 63 6C Private: http://www.suse.de/~marc SuSE: http://www.suse.de/security
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
# Copyright (c) 2001 SuSE GmbH Nuernberg, Germany. All rights reserved.
#
# Author: Marc Heuse
I'm sorry i forgot to mention what the problem is. When i want o set-up a masqueraded connection it doesn't work. But ping (icmp) does work. I get ping replies from servers in the internet. When i do a tcpdump and when i look in the logging than i see that the return traffic is dropped at eth0 (my external interface). Except for this problem i didn't experience any other problems. Regards, Joop Boonen. Joop Boonen wrote:
Dear Marc,
I hope it's ok that i sent this mail to the firewall mailing list.
I see the following in /etc/init.d/setup status
Chain forward_ext (1 references) pkts bytes target prot opt in out source destination 0 0 LOG all -- * * 192.168.2.0/24 0.0.0.0/0 LOG flags 6 level 4 prefix `SuSE-FW-DROP-ANTI-SPOOF' 0 0 DROP all -- * * 192.168.2.0/24 0.0.0.0/0 0 0 LOG all -- * * 192.168.2.0/23 0.0.0.0/0 LOG flags 6 level 4 prefix `SuSE-FW-DROP-ANTI-SPOOF' 0 0 DROP all -- * * 192.168.2.0/23 0.0.0.0/0 0 0 LOG all -- * * 0.0.0.0/0 192.168.2.1 LOG flags 6 level 4 prefix `SuSE-FW-DROP-CIRCUMVENTION' 0 0 DROP all -- * * 0.0.0.0/0 192.168.2.1 20 1120 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED icmp type 3 12 1008 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED icmp type 0 0 0 ACCEPT all -- * eth0 192.168.2.0/23 0.0.0.0/0 state NEW,RELATED,ESTABLISHED 75 4120 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 6 level 4 prefix `SuSE-FW-DROP-DEFAULT' 75 4120 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
The forward from the internet to my internal network is clearly dropped.
I think there is something wrong with the line before the drop line. (direction, source destination witched). I didn't really have time to look into this. But i wanted to let you know that everything seems to work perfectly except this part.
I think if the line would be: 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW,RELATED,ESTABLISHED It would already work, but it wouldn't be secure.
I'm sorry for not be able to give you the answer right now. I will try later.
Regards,
Joop Boonen.
I have attached the rc.firewall file and the status and the iptables -L file.
Marc Heuse wrote:
For the desperate:
SuSEfirewall2 v0.3 is available for testing from www.suse.de/~marc It installs without problem with a SuSEfirewall(1) installation, the only variable shared is the START_FW variable (well, with the result that both firewall will try to start when booting ;-)
please note: due my current network probs at home I could not make real tests. so everyone who can check features, and if possible send me a fix for something which is not working - that would be great!!
Q: What changed from SuSEfirewall(1) to SuSEfirewall2 A: Many things. Most important: it uses iptables (which is especially for 2.4 kernels) instead of ipchains. Visible changes: New commandline option "debug" which prints out the iptables commands, great to print the rules, and them modify them for you liking! Added the new options: FW_ALLOW_CLASS_ROUTING - allow routing between interfaces of the same class, e.g. two internal networks FW_ALLOW_FW_BROADCAST - allow broadcast packets to reach the firewall FW_ALLOW_PING_EXT - allow the internal/dmz to ping the internet FW_SERVICE_AUTODETECT - autodetect START_{NAMED,SMB,DHCPD} and DHCLIENT Renamed some variables, removed some, changed syntax (small changes) All forward,masquerading,trust definitions can now be very global or very fine-grained as you need it The logging looks different - hell this is iptables :-( It takes a bit longer to create the complex ruleset :-( Invisible changes: A packet has to traverse much less rules, so packet processing is faster Stateful packet checking is present now (thanks to the 2.4 kernel) More intelligent ICMP filtering and identd rejection
Greets, Marc -- Marc Heuse, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: marc@suse.de Function: Security Research and Advisory PGP: "lynx -source http://www.suse.de/~marc/marc.pgp | pgp -fka" Key fingerprint = B5 07 B6 4E 9C EF 27 EE 16 D9 70 D4 87 B5 63 6C Private: http://www.suse.de/~marc SuSE: http://www.suse.de/security
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
------------------------------------------------------------------------ Name: firewall2.rc.config firewall2.rc.config Type: Plain Text (text/plain) Encoding: quoted-printable
Name: iptabels2.txt iptabels2.txt Type: Plain Text (text/plain) Encoding: 7bit
Name: status.txt status.txt Type: Plain Text (text/plain) Encoding: 7bit
Part 1.5Type: Plain Text (text/plain)
Hi Joop, thanks for testing and reporting! I will try to fix this today or the next days and provide an update. Greets, Marc
I'm sorry i forgot to mention what the problem is.
When i want o set-up a masqueraded connection it doesn't work. But ping (icmp) does work. I get ping replies from servers in the internet.
When i do a tcpdump and when i look in the logging than i see that the return traffic is dropped at eth0 (my external interface).
Except for this problem i didn't experience any other problems.
Regards,
Joop Boonen.
Joop Boonen wrote:
Dear Marc,
I hope it's ok that i sent this mail to the firewall mailing list.
I see the following in /etc/init.d/setup status
Chain forward_ext (1 references) pkts bytes target prot opt in out source destination 0 0 LOG all -- * * 192.168.2.0/24 0.0.0.0/0 LOG flags 6 level 4 prefix `SuSE-FW-DROP-ANTI-SPOOF' 0 0 DROP all -- * * 192.168.2.0/24 0.0.0.0/0 0 0 LOG all -- * * 192.168.2.0/23 0.0.0.0/0 LOG flags 6 level 4 prefix `SuSE-FW-DROP-ANTI-SPOOF' 0 0 DROP all -- * * 192.168.2.0/23 0.0.0.0/0 0 0 LOG all -- * * 0.0.0.0/0 192.168.2.1 LOG flags 6 level 4 prefix `SuSE-FW-DROP-CIRCUMVENTION' 0 0 DROP all -- * * 0.0.0.0/0 192.168.2.1 20 1120 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED icmp type 3 12 1008 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED icmp type 0 0 0 ACCEPT all -- * eth0 192.168.2.0/23 0.0.0.0/0 state NEW,RELATED,ESTABLISHED 75 4120 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 6 level 4 prefix `SuSE-FW-DROP-DEFAULT' 75 4120 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
The forward from the internet to my internal network is clearly dropped.
I think there is something wrong with the line before the drop line. (direction, source destination witched). I didn't really have time to look into this. But i wanted to let you know that everything seems to work perfectly except this part.
I think if the line would be: 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW,RELATED,ESTABLISHED It would already work, but it wouldn't be secure.
I'm sorry for not be able to give you the answer right now. I will try later.
Regards,
Joop Boonen.
I have attached the rc.firewall file and the status and the iptables -L file.
Marc Heuse wrote:
For the desperate:
SuSEfirewall2 v0.3 is available for testing from www.suse.de/~marc It installs without problem with a SuSEfirewall(1) installation, the only variable shared is the START_FW variable (well, with the result that both firewall will try to start when booting ;-)
please note: due my current network probs at home I could not make real tests. so everyone who can check features, and if possible send me a fix for something which is not working - that would be great!!
Q: What changed from SuSEfirewall(1) to SuSEfirewall2 A: Many things. Most important: it uses iptables (which is especially for 2.4 kernels) instead of ipchains. Visible changes: New commandline option "debug" which prints out the iptables commands, great to print the rules, and them modify them for you liking! Added the new options: FW_ALLOW_CLASS_ROUTING - allow routing between interfaces of the same class, e.g. two internal networks FW_ALLOW_FW_BROADCAST - allow broadcast packets to reach the firewall FW_ALLOW_PING_EXT - allow the internal/dmz to ping the internet FW_SERVICE_AUTODETECT - autodetect START_{NAMED,SMB,DHCPD} and DHCLIENT Renamed some variables, removed some, changed syntax (small changes) All forward,masquerading,trust definitions can now be very global or very fine-grained as you need it The logging looks different - hell this is iptables :-( It takes a bit longer to create the complex ruleset :-( Invisible changes: A packet has to traverse much less rules, so packet processing is faster Stateful packet checking is present now (thanks to the 2.4 kernel) More intelligent ICMP filtering and identd rejection
Greets, Marc -- Marc Heuse, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: marc@suse.de Function: Security Research and Advisory PGP: "lynx -source http://www.suse.de/~marc/marc.pgp | pgp -fka" Key fingerprint = B5 07 B6 4E 9C EF 27 EE 16 D9 70 D4 87 B5 63 6C Private: http://www.suse.de/~marc SuSE: http://www.suse.de/security
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
------------------------------------------------------------------------ Name: firewall2.rc.config firewall2.rc.config Type: Plain Text (text/plain) Encoding: quoted-printable
Name: iptabels2.txt iptabels2.txt Type: Plain Text (text/plain) Encoding: 7bit
Name: status.txt status.txt Type: Plain Text (text/plain) Encoding: 7bit
Part 1.5Type: Plain Text (text/plain)
-- Greets, Marc -- Marc Heuse, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: marc@suse.de Function: Security Research and Advisory PGP: "lynx -source http://www.suse.de/~marc/marc.pgp | pgp -fka" Key fingerprint = B5 07 B6 4E 9C EF 27 EE 16 D9 70 D4 87 B5 63 6C Private: http://www.suse.de/~marc SuSE: http://www.suse.de/security
Dear Marc, I've fixed the problem. I've added the diff. I don't know if this is a good solution (security?), but it works. Regards, Joop Boonen. Marc Heuse wrote:
Hi Joop,
thanks for testing and reporting! I will try to fix this today or the next days and provide an update.
Greets, Marc
I'm sorry i forgot to mention what the problem is.
When i want o set-up a masqueraded connection it doesn't work. But ping (icmp) does work. I get ping replies from servers in the internet.
When i do a tcpdump and when i look in the logging than i see that the return traffic is dropped at eth0 (my external interface).
Except for this problem i didn't experience any other problems.
Regards,
Joop Boonen.
Joop Boonen wrote:
Dear Marc,
I hope it's ok that i sent this mail to the firewall mailing list.
I see the following in /etc/init.d/setup status
Chain forward_ext (1 references) pkts bytes target prot opt in out source destination 0 0 LOG all -- * * 192.168.2.0/24 0.0.0.0/0 LOG flags 6 level 4 prefix `SuSE-FW-DROP-ANTI-SPOOF' 0 0 DROP all -- * * 192.168.2.0/24 0.0.0.0/0 0 0 LOG all -- * * 192.168.2.0/23 0.0.0.0/0 LOG flags 6 level 4 prefix `SuSE-FW-DROP-ANTI-SPOOF' 0 0 DROP all -- * * 192.168.2.0/23 0.0.0.0/0 0 0 LOG all -- * * 0.0.0.0/0 192.168.2.1 LOG flags 6 level 4 prefix `SuSE-FW-DROP-CIRCUMVENTION' 0 0 DROP all -- * * 0.0.0.0/0 192.168.2.1 20 1120 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED icmp type 3 12 1008 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED icmp type 0 0 0 ACCEPT all -- * eth0 192.168.2.0/23 0.0.0.0/0 state NEW,RELATED,ESTABLISHED 75 4120 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 6 level 4 prefix `SuSE-FW-DROP-DEFAULT' 75 4120 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
The forward from the internet to my internal network is clearly dropped.
I think there is something wrong with the line before the drop line. (direction, source destination witched). I didn't really have time to look into this. But i wanted to let you know that everything seems to work perfectly except this part.
I think if the line would be: 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW,RELATED,ESTABLISHED It would already work, but it wouldn't be secure.
I'm sorry for not be able to give you the answer right now. I will try later.
Regards,
Joop Boonen.
I have attached the rc.firewall file and the status and the iptables -L file.
Marc Heuse wrote:
For the desperate:
SuSEfirewall2 v0.3 is available for testing from www.suse.de/~marc It installs without problem with a SuSEfirewall(1) installation, the only variable shared is the START_FW variable (well, with the result that both firewall will try to start when booting ;-)
please note: due my current network probs at home I could not make real tests. so everyone who can check features, and if possible send me a fix for something which is not working - that would be great!!
Q: What changed from SuSEfirewall(1) to SuSEfirewall2 A: Many things. Most important: it uses iptables (which is especially for 2.4 kernels) instead of ipchains. Visible changes: New commandline option "debug" which prints out the iptables commands, great to print the rules, and them modify them for you liking! Added the new options: FW_ALLOW_CLASS_ROUTING - allow routing between interfaces of the same class, e.g. two internal networks FW_ALLOW_FW_BROADCAST - allow broadcast packets to reach the firewall FW_ALLOW_PING_EXT - allow the internal/dmz to ping the internet FW_SERVICE_AUTODETECT - autodetect START_{NAMED,SMB,DHCPD} and DHCLIENT Renamed some variables, removed some, changed syntax (small changes) All forward,masquerading,trust definitions can now be very global or very fine-grained as you need it The logging looks different - hell this is iptables :-( It takes a bit longer to create the complex ruleset :-( Invisible changes: A packet has to traverse much less rules, so packet processing is faster Stateful packet checking is present now (thanks to the 2.4 kernel) More intelligent ICMP filtering and identd rejection
Greets, Marc -- Marc Heuse, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: marc@suse.de Function: Security Research and Advisory PGP: "lynx -source http://www.suse.de/~marc/marc.pgp | pgp -fka" Key fingerprint = B5 07 B6 4E 9C EF 27 EE 16 D9 70 D4 87 B5 63 6C Private: http://www.suse.de/~marc SuSE: http://www.suse.de/security
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
------------------------------------------------------------------------ Name: firewall2.rc.config firewall2.rc.config Type: Plain Text (text/plain) Encoding: quoted-printable
Name: iptabels2.txt iptabels2.txt Type: Plain Text (text/plain) Encoding: 7bit
Name: status.txt status.txt Type: Plain Text (text/plain) Encoding: 7bit
Part 1.5Type: Plain Text (text/plain)
--
Greets, Marc -- Marc Heuse, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: marc@suse.de Function: Security Research and Advisory PGP: "lynx -source http://www.suse.de/~marc/marc.pgp | pgp -fka" Key fingerprint = B5 07 B6 4E 9C EF 27 EE 16 D9 70 D4 87 B5 63 6C Private: http://www.suse.de/~marc SuSE: http://www.suse.de/security
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
--- /sbin/SuSEfirewall2-dist Sun Mar 4 10:38:41 2001 +++ /sbin/SuSEfirewall2 Sun Mar 4 11:28:07 2001 @@ -1111,6 +1111,8 @@ test -z "$PORT" || PORT="--dport $PORT" for DEV in $FW_MASQ_DEV; do for CHAIN in forward_ext forward_dmz forward_int; do + $LAA $IPTABLES -A $CHAIN -j LOG ${LOG}-ACCEPT-MASQ -d $NET1 $NET2 $PROTO $PORT -i $DEV + $IPTABLES -A $CHAIN -j "$ACCEPT" -m state --state NEW,ESTABLISHED,RELATED -d $NET1 $NET2 $PROTO $PORT -i $DEV $LAA $IPTABLES -A $CHAIN -j LOG ${LOG}-ACCEPT-MASQ -s $NET1 $NET2 $PROTO $PORT -o $DEV $IPTABLES -A $CHAIN -j "$ACCEPT" -m state --state NEW,ESTABLISHED,RELATED -s $NET1 $NET2 $PROTO $PORT -o $DEV done
Dear Marc, I improved the script a bit. I only don't know about the dmz as i don't have a dmz (So i don't know if it works or worked). Regards, Joop Boonen. Joop Boonen wrote:
Dear Marc,
I've fixed the problem. I've added the diff.
I don't know if this is a good solution (security?), but it works.
Regards,
Joop Boonen.
Marc Heuse wrote:
Hi Joop,
thanks for testing and reporting! I will try to fix this today or the next days and provide an update.
Greets, Marc
I'm sorry i forgot to mention what the problem is.
When i want o set-up a masqueraded connection it doesn't work. But ping (icmp) does work. I get ping replies from servers in the internet.
When i do a tcpdump and when i look in the logging than i see that the return traffic is dropped at eth0 (my external interface).
Except for this problem i didn't experience any other problems.
Regards,
Joop Boonen.
Joop Boonen wrote:
Dear Marc,
I hope it's ok that i sent this mail to the firewall mailing list.
I see the following in /etc/init.d/setup status
Chain forward_ext (1 references) pkts bytes target prot opt in out source destination 0 0 LOG all -- * * 192.168.2.0/24 0.0.0.0/0 LOG flags 6 level 4 prefix `SuSE-FW-DROP-ANTI-SPOOF' 0 0 DROP all -- * * 192.168.2.0/24 0.0.0.0/0 0 0 LOG all -- * * 192.168.2.0/23 0.0.0.0/0 LOG flags 6 level 4 prefix `SuSE-FW-DROP-ANTI-SPOOF' 0 0 DROP all -- * * 192.168.2.0/23 0.0.0.0/0 0 0 LOG all -- * * 0.0.0.0/0 192.168.2.1 LOG flags 6 level 4 prefix `SuSE-FW-DROP-CIRCUMVENTION' 0 0 DROP all -- * * 0.0.0.0/0 192.168.2.1 20 1120 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED icmp type 3 12 1008 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED icmp type 0 0 0 ACCEPT all -- * eth0 192.168.2.0/23 0.0.0.0/0 state NEW,RELATED,ESTABLISHED 75 4120 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 6 level 4 prefix `SuSE-FW-DROP-DEFAULT' 75 4120 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
The forward from the internet to my internal network is clearly dropped.
I think there is something wrong with the line before the drop line. (direction, source destination witched). I didn't really have time to look into this. But i wanted to let you know that everything seems to work perfectly except this part.
I think if the line would be: 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW,RELATED,ESTABLISHED It would already work, but it wouldn't be secure.
I'm sorry for not be able to give you the answer right now. I will try later.
Regards,
Joop Boonen.
I have attached the rc.firewall file and the status and the iptables -L file.
Marc Heuse wrote:
For the desperate:
SuSEfirewall2 v0.3 is available for testing from www.suse.de/~marc It installs without problem with a SuSEfirewall(1) installation, the only variable shared is the START_FW variable (well, with the result that both firewall will try to start when booting ;-)
please note: due my current network probs at home I could not make real tests. so everyone who can check features, and if possible send me a fix for something which is not working - that would be great!!
Q: What changed from SuSEfirewall(1) to SuSEfirewall2 A: Many things. Most important: it uses iptables (which is especially for 2.4 kernels) instead of ipchains. Visible changes: New commandline option "debug" which prints out the iptables commands, great to print the rules, and them modify them for you liking! Added the new options: FW_ALLOW_CLASS_ROUTING - allow routing between interfaces of the same class, e.g. two internal networks FW_ALLOW_FW_BROADCAST - allow broadcast packets to reach the firewall FW_ALLOW_PING_EXT - allow the internal/dmz to ping the internet FW_SERVICE_AUTODETECT - autodetect START_{NAMED,SMB,DHCPD} and DHCLIENT Renamed some variables, removed some, changed syntax (small changes) All forward,masquerading,trust definitions can now be very global or very fine-grained as you need it The logging looks different - hell this is iptables :-( It takes a bit longer to create the complex ruleset :-( Invisible changes: A packet has to traverse much less rules, so packet processing is faster Stateful packet checking is present now (thanks to the 2.4 kernel) More intelligent ICMP filtering and identd rejection
Greets, Marc -- Marc Heuse, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: marc@suse.de Function: Security Research and Advisory PGP: "lynx -source http://www.suse.de/~marc/marc.pgp | pgp -fka" Key fingerprint = B5 07 B6 4E 9C EF 27 EE 16 D9 70 D4 87 B5 63 6C Private: http://www.suse.de/~marc SuSE: http://www.suse.de/security
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
------------------------------------------------------------------------ Name: firewall2.rc.config firewall2.rc.config Type: Plain Text (text/plain) Encoding: quoted-printable
Name: iptabels2.txt iptabels2.txt Type: Plain Text (text/plain) Encoding: 7bit
Name: status.txt status.txt Type: Plain Text (text/plain) Encoding: 7bit
Part 1.5Type: Plain Text (text/plain)
--
Greets, Marc -- Marc Heuse, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: marc@suse.de Function: Security Research and Advisory PGP: "lynx -source http://www.suse.de/~marc/marc.pgp | pgp -fka" Key fingerprint = B5 07 B6 4E 9C EF 27 EE 16 D9 70 D4 87 B5 63 6C Private: http://www.suse.de/~marc SuSE: http://www.suse.de/security
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
------------------------------------------------------------------------ Name: SuSEfirewall2.diff SuSEfirewall2.diff Type: Plain Text (text/plain) Encoding: 7bit
Part 1.3Type: Plain Text (text/plain)
--- /sbin/SuSEfirewall2-dist Sun Mar 4 10:38:41 2001 +++ /sbin/SuSEfirewall2 Sun Mar 4 11:56:46 2001 @@ -1110,10 +1110,14 @@ test -z "$PROTO" || PROTO="-p $PROTO" test -z "$PORT" || PORT="--dport $PORT" for DEV in $FW_MASQ_DEV; do - for CHAIN in forward_ext forward_dmz forward_int; do + for CHAIN in forward_ext forward_dmz; do + $LAA $IPTABLES -A $CHAIN -j LOG ${LOG}-ACCEPT-MASQ -d $NET1 $NET2 $PROTO $PORT -i $DEV + $IPTABLES -A $CHAIN -j "$ACCEPT" -m state --state NEW,ESTABLISHED,RELATED -d $NET1 $NET2 $PROTO $PORT -i $DEV + done + for CHAIN in forward_dmz forward_int; do $LAA $IPTABLES -A $CHAIN -j LOG ${LOG}-ACCEPT-MASQ -s $NET1 $NET2 $PROTO $PORT -o $DEV $IPTABLES -A $CHAIN -j "$ACCEPT" -m state --state NEW,ESTABLISHED,RELATED -s $NET1 $NET2 $PROTO $PORT -o $DEV - done + done test -z "$PROTO" && \ $IPTABLES -A POSTROUTING -j MASQUERADE -t nat -s $NET1 $NET2 $PROTO $PORT -o $DEV test -z "$PROTO" || \
Hi Joop! thanks for the diffs! I'm pretty busy currently, I hope I'll have a revised version online until friday/weeking and fix your stuff and other things people reported. thanks you all! Greets, Marc -- Marc Heuse, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: marc@suse.de Function: Security Research and Advisory PGP: "lynx -source http://www.suse.de/~marc/marc.pgp | pgp -fka" Key fingerprint = B5 07 B6 4E 9C EF 27 EE 16 D9 70 D4 87 B5 63 6C Private: http://www.suse.de/~marc SuSE: http://www.suse.de/security
Dear Marc, I improved the script a bit. I only don't know about the dmz as i don't have a dmz (So i don't know if it works or worked). Regards, Joop Boonen. Joop Boonen wrote:
Dear Marc,
I've fixed the problem. I've added the diff.
I don't know if this is a good solution (security?), but it works.
Regards,
Joop Boonen.
Marc Heuse wrote:
Hi Joop,
thanks for testing and reporting! I will try to fix this today or the next days and provide an update.
Greets, Marc
I'm sorry i forgot to mention what the problem is.
When i want o set-up a masqueraded connection it doesn't work. But ping (icmp) does work. I get ping replies from servers in the internet.
When i do a tcpdump and when i look in the logging than i see that the return traffic is dropped at eth0 (my external interface).
Except for this problem i didn't experience any other problems.
Regards,
Joop Boonen.
Joop Boonen wrote:
Dear Marc,
I hope it's ok that i sent this mail to the firewall mailing list.
I see the following in /etc/init.d/setup status
Chain forward_ext (1 references) pkts bytes target prot opt in out source destination 0 0 LOG all -- * * 192.168.2.0/24 0.0.0.0/0 LOG flags 6 level 4 prefix `SuSE-FW-DROP-ANTI-SPOOF' 0 0 DROP all -- * * 192.168.2.0/24 0.0.0.0/0 0 0 LOG all -- * * 192.168.2.0/23 0.0.0.0/0 LOG flags 6 level 4 prefix `SuSE-FW-DROP-ANTI-SPOOF' 0 0 DROP all -- * * 192.168.2.0/23 0.0.0.0/0 0 0 LOG all -- * * 0.0.0.0/0 192.168.2.1 LOG flags 6 level 4 prefix `SuSE-FW-DROP-CIRCUMVENTION' 0 0 DROP all -- * * 0.0.0.0/0 192.168.2.1 20 1120 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED icmp type 3 12 1008 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED icmp type 0 0 0 ACCEPT all -- * eth0 192.168.2.0/23 0.0.0.0/0 state NEW,RELATED,ESTABLISHED 75 4120 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 6 level 4 prefix `SuSE-FW-DROP-DEFAULT' 75 4120 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
The forward from the internet to my internal network is clearly dropped.
I think there is something wrong with the line before the drop line. (direction, source destination witched). I didn't really have time to look into this. But i wanted to let you know that everything seems to work perfectly except this part.
I think if the line would be: 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW,RELATED,ESTABLISHED It would already work, but it wouldn't be secure.
I'm sorry for not be able to give you the answer right now. I will try later.
Regards,
Joop Boonen.
I have attached the rc.firewall file and the status and the iptables -L file.
Marc Heuse wrote:
For the desperate:
SuSEfirewall2 v0.3 is available for testing from www.suse.de/~marc It installs without problem with a SuSEfirewall(1) installation, the only variable shared is the START_FW variable (well, with the result that both firewall will try to start when booting ;-)
please note: due my current network probs at home I could not make real tests. so everyone who can check features, and if possible send me a fix for something which is not working - that would be great!!
Q: What changed from SuSEfirewall(1) to SuSEfirewall2 A: Many things. Most important: it uses iptables (which is especially for 2.4 kernels) instead of ipchains. Visible changes: New commandline option "debug" which prints out the iptables commands, great to print the rules, and them modify them for you liking! Added the new options: FW_ALLOW_CLASS_ROUTING - allow routing between interfaces of the same class, e.g. two internal networks FW_ALLOW_FW_BROADCAST - allow broadcast packets to reach the firewall FW_ALLOW_PING_EXT - allow the internal/dmz to ping the internet FW_SERVICE_AUTODETECT - autodetect START_{NAMED,SMB,DHCPD} and DHCLIENT Renamed some variables, removed some, changed syntax (small changes) All forward,masquerading,trust definitions can now be very global or very fine-grained as you need it The logging looks different - hell this is iptables :-( It takes a bit longer to create the complex ruleset :-( Invisible changes: A packet has to traverse much less rules, so packet processing is faster Stateful packet checking is present now (thanks to the 2.4 kernel) More intelligent ICMP filtering and identd rejection
Greets, Marc -- Marc Heuse, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: marc@suse.de Function: Security Research and Advisory PGP: "lynx -source http://www.suse.de/~marc/marc.pgp | pgp -fka" Key fingerprint = B5 07 B6 4E 9C EF 27 EE 16 D9 70 D4 87 B5 63 6C Private: http://www.suse.de/~marc SuSE: http://www.suse.de/security
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
------------------------------------------------------------------------ Name: firewall2.rc.config firewall2.rc.config Type: Plain Text (text/plain) Encoding: quoted-printable
Name: iptabels2.txt iptabels2.txt Type: Plain Text (text/plain) Encoding: 7bit
Name: status.txt status.txt Type: Plain Text (text/plain) Encoding: 7bit
Part 1.5Type: Plain Text (text/plain)
--
Greets, Marc -- Marc Heuse, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: marc@suse.de Function: Security Research and Advisory PGP: "lynx -source http://www.suse.de/~marc/marc.pgp | pgp -fka" Key fingerprint = B5 07 B6 4E 9C EF 27 EE 16 D9 70 D4 87 B5 63 6C Private: http://www.suse.de/~marc SuSE: http://www.suse.de/security
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
------------------------------------------------------------------------ Name: SuSEfirewall2.diff SuSEfirewall2.diff Type: Plain Text (text/plain) Encoding: 7bit
Part 1.3Type: Plain Text (text/plain)
--- /sbin/SuSEfirewall2-dist Sun Mar 4 10:38:41 2001 +++ /sbin/SuSEfirewall2 Sun Mar 4 12:02:55 2001 @@ -1110,10 +1110,14 @@ test -z "$PROTO" || PROTO="-p $PROTO" test -z "$PORT" || PORT="--dport $PORT" for DEV in $FW_MASQ_DEV; do - for CHAIN in forward_ext forward_dmz forward_int; do + for CHAIN in forward_ext forward_dmz; do + $LAA $IPTABLES -A $CHAIN -j LOG ${LOG}-ACCEPT-MASQ -d $NET1 $NET2 $PROTO $PORT -i $DEV + $IPTABLES -A $CHAIN -j "$ACCEPT" -m state --state NEW,ESTABLISHED,RELATED -d $NET1 $NET2 $PROTO $PORT -i $DEV + done + for CHAIN in forward_dmz forward_int; do $LAA $IPTABLES -A $CHAIN -j LOG ${LOG}-ACCEPT-MASQ -s $NET1 $NET2 $PROTO $PORT -o $DEV $IPTABLES -A $CHAIN -j "$ACCEPT" -m state --state NEW,ESTABLISHED,RELATED -s $NET1 $NET2 $PROTO $PORT -o $DEV - done + done test -z "$PROTO" && \ $IPTABLES -A POSTROUTING -j MASQUERADE -t nat -s $NET1 $NET2 $PROTO $PORT -o $DEV test -z "$PROTO" || \
* Joop Boonen wrote on Sun, Mar 04, 2001 at 12:08 +0100:
I improved the script a bit.
I haven't read the entire script. I just want to make some general comments.
@@ -1110,10 +1110,14 @@ test -z "$PROTO" || PROTO="-p $PROTO"
I think this will not work if $PROTO contains more than one proto. Did you checked that? Otherwise you will build "-p tcp udp" or similar, and the ipchains/iptables command will fail (I guess at least...). If I see a line 1110 it's quite a large script! That requires a useful design, otherwise it would be difficult to understand. That could have some functions to add an abstract layer and so on.
test -z "$PORT" || PORT="--dport $PORT" for DEV in $FW_MASQ_DEV; do - for CHAIN in forward_ext forward_dmz forward_int; do
I thing a little comment would not bad here, it's something cryptic following; especially in security it's very nessecary to optimize not for speed nor size but for readability.
+ for CHAIN in forward_ext forward_dmz; do + $LAA $IPTABLES -A $CHAIN -j LOG ${LOG}-ACCEPT-MASQ -d $NET1 $NET2 $PROTO $PORT -i $DEV
$LAA tells me i.e. nothing, but may it's explained before that patch. I don't understand how you check if this iptables command was successful or not. Of course it's very important to check that. Please notice, that a messages to console via echo ist NOT sufficient here. You will have to use at least syslog (logger), or sent a mail directly (which is not always the best), but you cannot assume that somebody reads console messages. The output of iptables (in case of error) gets lost, too. Maybe you should write that in some logfile. Linebreaks are missing (standard displays have a linewidth of 80 characters).
+ $IPTABLES -A $CHAIN -j "$ACCEPT" -m state --state NEW,ESTABLISHED,RELATED -d $NET1 $NET2 $PROTO $PORT -i $DEV + done [...] test -z "$PROTO" && \ $IPTABLES -A POSTROUTING -j MASQUERADE -t nat -s $NET1 $NET2 $PROTO $PORT -o $DEV test -z "$PROTO" || \
This is a "if-then-else" type thing? Then please write if-then-else, that's a lot more intuitive to understand. Did you checked the contents of the variables ($NET1, $PORT and so on)? What happens, if they include a "*"? The shell would expand that to the directory contents. Imagine, a user uses wildcard star for proto (and means all), and it gets expanded to root-directory files. Finally iptables fails when trying to block "etc" and "sbin", the user may or may not notice, and nothing gets blocked. For instance. At least you should quote the parameters: #install NAT rule for net1-->net2 "$IPTABLES" -A POSTROUTING \ --jump MASQUERADE \ --table nat \ --source "$NET1" "$NET2" \ "$PROTO" \ "$PORT" \ --out-interface "$DEV" #example error handler check_iptables $? Useing long options improved readability. Another hint: use not iptables directly, use a function. This function is declared in the script and acts as wrapper. The function evalutates results, checks for errors, keeps track of error messages. My firewall script has such a wrapper that counts rules and errors, and log a sum to syslog: Mar 5 10:12:58 dx S98firewall.std[1943]: Firewall set up successfully. Total number of rules: 97 Well, you flagged your script as ALPHA, so you might have changed the things already; I just wanted to give some comments. I would not call an own script that works with SuSE "SuSEFirewall", since this suggests me it's _from_ SuSE, not _for_ SuSE. But others may see this in a different way of course. I hope I'm not completly wrong ;) - Just some thoughts... Maybe the list could comment this. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Read all, This the whole script. Joop. Steffen Dettmer wrote:
* Joop Boonen wrote on Sun, Mar 04, 2001 at 12:08 +0100:
I improved the script a bit.
I haven't read the entire script. I just want to make some general comments.
@@ -1110,10 +1110,14 @@ test -z "$PROTO" || PROTO="-p $PROTO"
I think this will not work if $PROTO contains more than one proto. Did you checked that? Otherwise you will build "-p tcp udp" or similar, and the ipchains/iptables command will fail (I guess at least...).
If I see a line 1110 it's quite a large script! That requires a useful design, otherwise it would be difficult to understand. That could have some functions to add an abstract layer and so on.
test -z "$PORT" || PORT="--dport $PORT" for DEV in $FW_MASQ_DEV; do - for CHAIN in forward_ext forward_dmz forward_int; do
es trägt daher weder Unterschrift noch Siegel.
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
participants (3)
-
Joop Boonen
-
marc@suse.de
-
Steffen Dettmer