Ich nutzte in der Vergangenheit sehr gerne FWBuilder, um iptables-Regeln zu generieren. Mit den aktuellen Paketen aus dem Repository
http://download.opensuse.org/repositories/security/openSUSE_12.3/
ergeben sich jedoch Schwierigkeiten. So erhält man – je nach Zustand des Zielsystems – Warnungen der Art
WARNING: The state match is obsolete. Use conntrack instead.
Dies gilt insbesondere für Server, die auf Basis von Opensuse 12.3 eingerichtet wurden. Dort wird iptables in einer Version > 1.4.16 verwendet. FWBuilder ist damit nicht kompatibel. Siehe hierzu u.a.:
http://www.mbse.eu/2012/11/iptables-1-4-16-and-fwbuilder-doesnt-work/
Der Bug ist auch schon seit einer ganzen Weile bekannt. Siehe:
http://sourceforge.net/p/fwbuilder/bug-reports-current-version/245/
http://sourceforge.net/p/fwbuilder/discussion/16372/thread/8789d909/
Die schlechte Nachricht
FWBuilder ist aus meiner bescheidenen Anwender-Sicht eine Perle von einem Programm gewesen. Stichworte: Sehr nützlich, gutes Layout, einfach zu bedienen, gut verständlich, etc. und bis Anfang des Jahres auch immer aktuell. Nun musste ich zur Kenntnis nehmen, dass die zwei tragenden Entwickler das Projekt und ihre ehemalige Firma verlassen haben. Siehe :
http://sourceforge.net/p/fwbuilder/news/2013/04/announcement-/
http://sourceforge.net/p/fwbuilder/discussion/16372/thread/54f339dc/
http://sourceforge.net/p/fwbuilder/news/2013/07/i-am-leaving-netcitadel/
Mir ist leider bislang völlig unklar geblieben, wie es z.Z. um den Status des FWBuilder-Projektes bestellt ist. Man kann jedenfalls nicht mehr so ohne weiteres erwarten, dass sich jemand der Sache mit den conntrack-Warnungen annimmt. Es gibt daher für mich als Endverbraucher 4 Alternativen:
- Man bleibt bei IPtables V1.15.X. Dies bedeutet bei Opensuse, dass man dafür Hand anlegen und kompilieren muss. Auf Dauer sicher keine gute Lösung.
- Man sieht sich nach einer Alternative zu FWBuilder um. In Frage käme etwa “shorewall”. Dabei wird man jedoch die komfortable grafische Oberfläche von FWBuilder vermissen. Zudem muss man sich in das dateibasierte Interface von Shorewall einarbeiten. Sollte sich niemand des FWBuilder Projekts annehmen, ist dieser Schritt vielleicht auf Dauer nicht zu vermeiden.
- Man findet sich mit den Warnungen ab. Zur Sicherheit sollte man dann aber testen, ob die Regeln noch tatsächlich wirksam sind. Der Grund ist, dass das Modul “state” früher oder später möglicherweise nicht mehr in allen Kernelkonfigurationen repräsentiert sein wird. S.u. Auf Dauer also auch nicht gut.
- Man nutzt FWBuilder weiter und baut als Workaround um die generierten fw-Installationsskripts ein Script herum, dass die notwendigen Änderungen an den von FWBuilder generierten iptables-Regeln vornimmt. Das wäre immerhin ein Workaround auf Zeit …
Nachfolgend widme ich mich nach ein paar Infos zu “conntrack” der Alternative 4.
Unterschiede zwischen “conntrack” und “state” ?
Bevor man sich mit
Eingriffen in sicherheitsrelevante Scripts befasst, sollte man sich wenigstens ein wenig dazu kundig machen, worum es geht. Also hier eine (sehr kurze) Kurzfassung:
Das Verfolgen eines Verbindungszustands ist ein elementarer Bestandteil von Paketfiltern. Unter Linux sind hierfür bestimmte Kernelkomponenten (Kernel Frameworks) verantwortlich, die z.T. und ggf. nicht fix in den Kernel integriert sondern als Kernel-Module kompiliert sein können. Das State-Modul wurde vor einer Weile durch eine ganze Kaskade von optionsreicheren “Conntrack”-Modulen abgelöst. Ob und wie nun ein System mit einer bestimmten Kernel- und Kernel-Modul-Konfiguration auf die alten “-m state” Optionen und zugehörige Suboptionen von IPtables-Filterregeln reagiert, hängt von Details der Implementierung ab. Siehe auch:
Eine Einführung in den Einsatz der Status-Analyse im Zusammenhang mit iptables findet man hier:
http://www.iptables.info/en/connection-state.html
Ich zitiere den dortigen “Original Author: Oskar Andreasson”:
“All of the connection tracking is done by special framework within the kernel called conntrack. conntrack may be loaded either as a module, or as an internal part of the kernel itself. Most of the time, we need and want more specific connection tracking than the default conntrack engine can maintain. Because of this, there are also more specific parts of conntrack that handles the TCP, UDP or ICMP protocols among others. These modules grab specific, unique, information from the packets, so that they may keep track of each stream of data. The information that conntrack gathers is then used to tell conntrack in which state the stream is currently in. For example, UDP streams are, generally, uniquely identified by their destination IP address, source IP address, destination port and source port. “
Entsprechend findet man auf einem Standard-Opensuse 12.3-System folgende Module:
os123:~ # lsmod | grep conntrack
nf_conntrack_ipv4 15013 66
nf_defrag_ipv4 12730 1 nf_conntrack_ipv4
nf_conntrack_netlink 35452 0
nfnetlink 14407 1 nf_conntrack_netlink
nf_conntrack_ftp 18680 0
nf_conntrack_snmp 12858 0
nf_conntrack_irc 13519 0
nf_conntrack_tftp 13122 0
nf_conntrack_pptp 19246 0
nf_conntrack_netbios_ns 12666 0
nf_conntrack_broadcast 12590 2 nf_conntrack_snmp,nf_conntrack_netbios_ns
nf_conntrack_slp 12648 0
nf_conntrack_h323 73846 0
nf_conntrack_sane 13144 0
nf_conntrack_proto_sctp 18823 0
nf_conntrack_amanda 13042 0
nf_conntrack_sip 33868 0
xt_conntrack 12761 66
nf_conntrack_proto_udplite 13282 0
nf_conntrack_proto_gre 14435 1 nf_conntrack_pptp
nf_conntrack_proto_dccp 13511 0
nf_conntrack 98519 19 nf_conntrack_ipv4,nf_conntrack_netlink,nf_conntrack_ftp,nf_conntrack_snmp,
nf_conntrack_irc,nf_conntrack_tftp,nf_conntrack_pptp,nf_conntrack_netbios_ns,
nf_conntrack_broadcast,nf_conntrack_slp,nf_conntrack_h323,nf_conntrack_sane,
nf_conntrack_proto_sctp,nf_conntrack_amanda,nf_conntrack_sip,xt_conntrack,
nf_conntrack_proto_udplite,nf_conntrack_proto_gre,nf_conntrack_proto_dccp
x_tables 34060 9 xt_LOG,xt_multiport,xt_tcpudp,xt_conntrack,ip6table_filter,ip6_tables,
iptable_filter,ip_tables,ebtables
Welche Konsequenzen hat das nun für IPtables-Regeln ?
Wie man conntrack verwendet, ergibt sich z.B. aus den Ausführungen dieser Webseiten:
http://www.iptables.info/en/iptables-matches.html#GENERICMATCHES
http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-3.html
Aus meiner Sicht sind daher bisherige IPtables-Regeln wie in folgendem Beispiel zu modifizieren:
Alte Syntax:
$IPTABLES -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
Neue Syntax:
$IPTABLES -A INPUT -m conntrack –ctstate ESTABLISHED,RELATED -j ACCEPT
Ich sage aber ausdrücklich, dass ich das noch nicht im Detail verifiziert habe. Für komplexe Prüfungen mögen mehr Anpassungen von Nöten sein, als in dem simplen Beispiel angegeben. Und zudem gilt:
Das conntrack-System hat wesentlich mehr Optionen als nur "–cstate" !!
Auf die ganzen Möglichkeiten kann und will ich an dieser Stelle nicht eingehen.
Ein Blick in mehrere meiner generierten fw-Scripts zeigte mir jedenfalls für meine Fälle, dass die Ersetzung funktionieren sollte.
Die gute Nachricht – einfache Modifikation der generierten Scripts von FWBuilder
Wenn die oben genannte Ersetzungsregeln richtig sein sollten, dann ist man insofern fein raus, als man zur Modifikation der Skripts, die FWBuilder generiert, auf den jeweiligen Zielmaschinen ein einfaches “sed”-Kommando laufen lassen kann, um die notwendigen Modifikationen vorzunehmen. Folgende sed-Ersetzungsregeln sollten dann ausreichen :
sed ‘s/-m state –state/-m conntrack –ctstate/g’
Siehe auch :
http://gentooligan.blogspot.de/2012/12/change-in-iptables-state-vs-conntrack.html
Tatsächlich passen die angegebenen Blanks in der Ersetzungsregel auch zu den FW-Scripts. “sed” nutzt den Pipe-Mechanismus. Hat man z.B. ein System namens “os123” und hat man dort über die Remote Installationsmechnismen von FWBuilder ein Skriptfile namens “/etc/os123.fw” installiert, so kann man auf diesem System folgendes Kommando durchführen:
sed ‘s/-m state –state/-m conntrack –ctstate/g’ < /etc/os123.fw > os123.fw.mod
Anschließend kann man das neue Script zur Installation der Firewall nutzen:
os123:~ # sh /etc/os123.fw
Um das ganze etwas handlicher zu machen, bastelt man dann ggf. ein Skript um das Ganze. Eine erste Primitiv-Version kann auf dem besagten System etwa so aussehen:
#!/bin/bash
SHORT_HOSTNAME=$(hostname -s)
FW_FILE=”/etc/”$SHORT_HOSTNAME”.fw”
FW_FILE_ORIG=$FW_FILE”.orig”
FW_MOD_FILE=$FW_FILE”.mod”
echo “***************************************************”
echo “Preparing and installing FW-Firewall on “$SHORT_HOSTNAME
if [ -e $FW_FILE ]
then
echo ” – Copying “$FW_FILE” to backup file “$FW_FILE_ORIG
cp $FW_FILE $FW_FILE_ORIG
echo ” – Starting to modify \””$FW_FILE”\” with SED”
sed ‘s/-m state –state/-m conntrack –ctstate/g’ < $FW_FILE > $FW_MOD_FILE
rm $FW_FILE
mv $FW_MOD_FILE $FW_FILE
echo ” – Modification of \””$FW_FILE”\” with conntrack statements
finalized”
echo “Executing the modified script …”
echo “***************************************************”
sh $FW_FILE
echo “***************************************************”
else
echo “Firewall file does not exist”
fi
exit
Ich überlasse es dem Leser, hieraus ein übersichtliches, dokumentiertes Skript zu bauen, das sich für den Produktiveinsatz eignet. Und natürlich muss man das noch mit systemd verheiraten …..
Auf einem realen System sieht das dann etwa so aus:
#sh install_fw
***************************************************
Preparing and installing FW-Firewall on os123
– Copying /etc/os123.fw to backup file /etc/os123.fw.orig
– Starting to modify “/etc/os123.fw” with SED
– Modification of “/etc/os123.fw” with conntrack statements finalized
Executing the modified script …
***************************************************
Activating firewall script generated Wed Aug 28 15:30:16 2013 by root
Running prolog script
Verifying interfaces: br0 lo
Rule 0 (br0)
Rule 1 (br0)
Rule 2 (lo)
Rule 3 (br0)
Rule 4 (br0)
Rule 5 (br0)
Rule 6 (global)
Rule 8 (br0)
Rule 9 (global)
Rule 10 (br0)
Rule 11 (br0)
Rule 12 (br0)
Rule 13 (br0)
Rule 14 (br0)
Rule 15 (br0)
Rule 16 (br0)
Rule 17 (br0)
Rule 18 (br0)
Rule 19 (br0)
Rule 21 (br0)
Rule 22 (br0)
Rule 23 (global)
Running epilog script
***************************************************
Viel Spaß weiterhin mit FWBuilder auf Opensuse-Systemen. Und hoffentlich nehmen sich bald irgendein Sponsor und interessierte Entwickler des verwaisten FWBuilder-Projekts an ….
