![[Inhalt]](../../Grundlagen/Firewall/images/toc.gif){kind=small}
|
|
Online Suche im Handbuch | LITTLE-IDIOT NETWORKING |
Die SINUS Firewall wird durch ein einziges Konfigurationsfile gesteuert. In diesem Abschnitt sind alle Möglichkeiten beschrieben und mit Beispielen unterlegt.
Details bezüglich der genauen Syntax sind am Ende dieses Abschnittes zu finden.
Das Konfigurationsfile ist in 3 Abschnitte aufgeteilt:
Alle Kommentare in dem Konfigurationsfile sind mit einem # zu Beginn, oder mit /*...*/ entsprechend dem C-Stil gekennzeichnet.
Es dürfen nur Kleinbuchstaben im Konfigurationsfile benutzt werden.
IP Adressen werden an verschiedensten Stellen in dem Konfigurationsfile benutzt. Es sind beide Schreibweisen für IP-Adressen erlaubt. Der DNS Name und die IP - Nummer als Dezimalzahl, durch Punkte getrennt (Also www.name.de oder 1.2.3.4). Hierzu muß der resolver Zugriff auf den DNS-Server haben, oder es müssen in der Datei /etc/hosts alle beteiligten Hostnamen eingetragen werden. Aus Gründen der Sicherheit sollte man mit den IP - Nummern und nicht mit den DNS-Namen arbeiten. Dies hat folgende Gründe:
Es kann nach jeder IP - Nummer oder jedem Hostnamen eine Netzmaske angegeben werden. Die Netzmaske ist, falls sie nicht speziell angegeben wird, die Zahl 255.255.255.255 . Die IP - Nummer ist gültig, wenn alle Bits der IP - Nummer mit derjenigen der Netzmaske übereinstimmen. Ein paar Beispiele:
129.132.1.18 mask 255.255.255.255 ist exakt für einen Host gültig 193.135.255.0 mask 255.255.255.0 ist für ein Class-C Netzwerk gültig 129.132.20.0 mask 255.255.0.0 ist für ein Class-B Netzwerk gültig
Die Netzmaske muß nicht angegeben werden, wenn die Adresse eine Hostadresse ist, oder keine Subnettierung des Netzwerks stattfindet. Folgende Beispiele zur Erläuterung:
129.132.1.18 = 129.132.1.18 mask 255.255.255.255 129.132.0.0 = 129.132.0.0 mask 255.255.0.0 193.135.255.0 = 193.135.255.0 mask 255.255.255.0
Aber Vorsicht: Die Adresse 129.132.20.0 ohne Netzmaske wird als Hostadresse angesehen, weil automatisch die Netzmaske 255.255.255.255 angenommen wird. Damit die Adresse als Netzwerkadresse angesehen wird, ist die Netzmaske 255.255.255.0 stets anzugeben !
In dem Konfigurationsfile startet dieser Abschnitt mit dem Schlüsselwort setup. Das als Option zu verwendende Schlüsselwort internalnets sagt der Firewall, welche IP - Nummern sich im internen Netzwerk befinden. Hier können sowohl IP - Nummern von Hosts als auch Netzwerkadressen miteinander kombiniert angegeben werden. Diese IP-Adressen werden normalerweise vom Provider zugewiesen. Für den Einsatz mit einer dynamischen IP - Nummer ist ein Router mit NAT oder Masquerading vor der SINUS Firewall einzusetzen. In diesem Falle können die Netzwerkadressen intern beliebig gewählt werden. Die Liste der Adressen ist durch Komma zu trennen und mit einem Semikolon (wie in "C" oder BASH üblich) abzuschießen.
Diese Information wird von der Firewall unbedingt zum Schutz vor gespooften Adressen benötigt. Die Firewall kann nur so feststellen, ob ein Paket korrekt seinem Interface zugeordnet worden ist, beispielsweise dürfen Pakete, die als Absender Adressen aus dem Bereich des Intranets tragen, nicht Zugang über das äußere Interface erhalten. In diesem Falle liegt entweder eine Fehlkonfiguration vor, oder ein Angreifer arbeitet mit adress spoofing, wobei ersteres die weit häufigere Ursache ist.
Es muß eine e-Mail Adresse angegeben werden, an welche die Firewall alle gewünschten Warnmeldungen, Einbruchsversuche, Meldungen über Scanversuche, oder Fehlermeldungen, wie Festplatte voll, o.ä. senden darf. Es dürfen ebenfalls mehrere e-Mail Adressen angegeben werden, die durch ein Leerzeichen getrennt sein müssen.
Diese Sektion wird durch das Schlüsselwort rules eingeleitet. Jede Regel in diesem Abschnitt beginnt mit einem der Schlüsselworte:
> Die Regel accept veranlaßt den Filter, die Pakete passieren zu lassen, falls die Regel zutrifft. Das Schlüsselwort block veranlaßt den Filter, das Paket stillschweigend zu verwerfen, ohne eine Fehlermeldung an die Quelladresse zurück zu senden. Die reject Regel sendet über ICMP die Nachricht ICMP_MESSAGE_UNREACHABLE an die Quelladresse zurück. Die Art der Nachricht kann frei bestimmt werden, um nicht zu viele aussagekräftige Informationen an einen Angreifer auszuliefern.
Zudem kann man eine Liste von IP Optionen den Regeln hinzufügen. Ein Paket erfüllt genau dann eine Regel, wenn mindesten ein der aufgeführten IP Optionen zutreffend ist.
Ein Spezialfall ist das TTL Feld (Time To Live), welches keine echte Option darstellt. Der Wert des TTL Feldes kann mit einer Konstanten verglichen werden. Ein Paket erfüllt eine solche Regel nur dann, wenn der Vergleich zutreffend ist, unabhängig davon, ob eine der Optionen zutrifft, oder nicht.
Informationen über das Protokoll werden mit folgenden Schlüsselworten angegeben:
Das letzte Schlüsselwort all beinhaltet alle vorhergehenden.
Eine weitere Möglichkeit ist, direkt die Protokollnummer in dem IP Header anzugeben, z.B. die 9 für IGP. Bei der Verwendung von icmp oder igmp kann die Regel auf einige Nachrichtentypen begrenzt werden. RIP ist hier ein Spezialfall des UDP Protokolls, wobei nur UDP Pakete berücksichtigt werden, die auf Port 520 eintreffen. Ein RIP Paket erfüllt eine Regel, wenn alle angekündigten Ziele auch zutreffend sind. Das folgende Beispiel beschreibt eine solche Regel:
accept rip outside /* trifft auf eine Regel zu*/ from 194.40.243.5 /* nächstes Gateway im Netz */ to 194.40.243.4; /* die eigene Adresse */
Das Paket erfüllt die Regel, wenn die Quelladresse eine der Adressen ist, die nach dem Schlüsselwort from und der Zieladresse eine der Adressen eine der Adressen nach dem Schlüsselwort to ist. Anstelle einer Liste von IP - Nummern kann auch das Schlüsselwort inside verwendet werden, welches der Ersatz für alle Adressen, die unter internalnets angegeben worden sind. Die Verwendung des Schlüsselwortes outside bezeichnet alle anderen, die nicht unter internalnets angegeben worden sind. Das könnte der Rest des Internets z.B. sein.
Für alle TCP und UDP Protokolle kann zusätzlich noch ein Port oder ein Bereich von Ports angegeben werden. Hierfür kann auch der Name des Dienstes angegeben werden, z.B. telnet. Hierfür greift die Firewall auf die Definitionen in der Datei /etc/services zurück. Die Angabe eines Ports ohne eines der Protokolle tcp oder udp wird ignoriert.
Hier ein Beispiel:
from inside port telnet to 129.132.0.0, port 2700,
130.103.24.0 mask 255.255.255.0 port 3000..4000;
Zum Schluß muß der notification level bestimmt werden, der der Firewall angibt, was zu tun ist, wenn die Regel erfüllt ist. Hier werden alle Aktionen definiert, die neben denjenigen stattfinden sollen, die über den Verbleib des Paketes entscheiden (accept, block oder reject).
Der Level 0 gibt an, daß der Firewall-Dämon und damit auch der User nicht über das Ereignis informiert wird. Wenn der Level größer als 0 ist, dann wird automatisch ein Logeintrag vorgenommen, und alle Aktionen ausgeführt, die in diesem notification level angegeben wurden.
Wiederum sind natürlich die Regeln in dem File sehr wichtig. Wenn zwei Regeln gleichzeitig erfüllt sind, dann hat die erste Regel Vorzug gegenüber der zweiten Regel. Die Konsequenz daraus ist, daß man stets zuerst die Speziellen Regeln definieren sollte, bevor man sich den allgemeinen Regeln zuwendet. Beispielsweise wenn alle UDP Pakete gesperrt sein sollen, außer diejenigen von dem Host 194.77.6.230, dann sollte man diese Regel in zwei Regeln aufteilen, und diese in der korrekten Reihenfolge notieren:
accept udp from 194.77.6.230 notification_level 0; block udp notification_level 1;
Diese Sektion wird mit dem Schlüsselwort notification eingeleitet. Jeder Abschnitt beginnt mit dem Schlüsselwort level, gefolgt von einer level number und einem Doppelpunkt. Es können verschiedenste Aktionen zu einer Liste zusammengefaßt werden. Folgende Aktionen sind möglich:
Eine Filterregel kann definiert werden, die dynamisch der bestehenden statischen Filterkonfiguration hinzugefügt wird. In Ergänzung zu den oben beschriebenen Eigenschaften für Filterregeln gibt es ein paar besondere Eigenheiten für dynamische Regeln zu beachten. Wenn das Schlüsselwort currentprotocol anstelle der Protokollbezeichnungen angegeben wird, dann wird dasjenige Protokoll desjenigen Paketes, welches die Regel erfüllt und somit die Aktion ausgelöst hatte, mit in die neue, dynamische Regel übernommen. Genauso können die Schlüsselworte sourcehost, sourcenet, desthost, destnet after to und from verwendet werden, um Informationen aus der alten Regel in die neue, dynamische Regel zu übernehmen. Zuletzt kann man noch einen Timout Wert (in Sekunden gemessen) am Ende der Regel hinzufügen (optional). Dieser Timout sorgt dann dafür, daß die Regel nach Ablauf einer bestimmten Zeit wieder gelöscht wird.
Man sollte dieses unglaublich mächtige Werkzeug nur mit größter Vorsicht einsetzen, da nur sehr schlecht vorherzusagen ist, welche Regel im Moment gerade aktiv ist, und warum. Es ist ebenfalls schwierig, genau die Einflüsse der dynamischen Regeln untereinander zu bestimmen, weil, wie bei statischen Regeln auch, die Reihenfolge ihrer Aktivierung Auswirkungen auf deren Abarbeitung in der Liste hat. Andererseits lassen sich hiermit komplexe Proxy-Mechanismen formulieren und sogar ausgewachsene Proxy's ersetzen.
Variablen können deklariert werden. Ihr Wert wird dann stets auf 0 gesetzt. Sie können nur Integerwerte speichern. Wenn also auf Variablen zugegriffen werden soll, dann kann optional einer der Begriffe sourcehost oder desthost nach dem Variablennamen angegeben werden, durch ein Doppelpunkt voneinander getrennt. Eine spezielle Instanz der Variablen wird erzeugt, wenn auf diese zugegriffen wird, wobei entweder die Quelladresse oder die Zieladresse desjenigen Paketes angegeben wird, welches diese Aktion ausgelöst hat. Wenn die Variable so verändert wird, dann werden die Variable und deren Instanz verändert. Diese Eigenschaft kann dazu genutzt werden, die Häufigkeit eines Ereignisses zu ermitteln, absolut und nach Quell-und Zieladresse aufgeschlüsselt.
Im folgenden Beispiel werden die Variablen und der Timeout Mechanismus für Variablen und dynamische Regeln gleichzeitig verwendet. Wenn ein Host die Firewall 100 mal in Folge in einem Abstand von maximal 2 Sekunden anpingt, dann werden alle Pakete von diesem Hosts für 10 Minuten gesperrt. Der notification level dieser dynamischen Regel wird auf 0 gesetzt, um die Menge der anfallenden Log-Einträge einzudämmen, die zwischen Filter und Firewall ausgetauscht werden:
accept icmp icmp_echo to inside notification_level 10;
notification level 10:
let pingcount:sourcehost := pingcount:sourcehost + 1 timeout 2;
if pingcount:sourcehost > 100 then
block all from sourcehost notification_level 0 timeout 600
endif;
In diesem Abschnitt werden alle oben nur definierten Filterregeln genauer abgehandelt. Es wird ausdrücklich das Buch von Bellovin und Cheswick als "Bibel" für das Erstellen von Filterregeln empfohlen. Im Kapitel firewallregeln sind aber auch die meisten dieser Filterregeln noch einmal genauestens aufgelistet. Meiner Meinung nach ist die "Bibel" von Bellovin und Cheswick inzwischen völlig veraltet, da sie sich ohnehin nur auf Probleme auf Circuit-Level bezieht.
Die erste Frage die hier geklärt werden soll ist die Frage nach block oder reject von Paketen.
In der Praxis ist diese Frage oft schwieriger zu beantworten, als es den Anschein hat. Wenn ein Paket geblockt wird, also der Sender keine Fehlermeldung erhält, dann könnte es sein, daß der Host meint, daß das Paket während der Übermittlung verloren gegangen ist. Ein normaler Algorithmus in einem Programm oder Protokoll besitzt einen Timeout Mechanismus, der nach einigen Versuchen abbricht. Wenn dieser eine ICMP Meldung zurückerhält, in welcher der Host darüber informiert wird, daß ein Paket nicht ausgeliefert werden kann (no route to host!), dann wird er sofort damit aufhören, welche zu senden. Man sollte aber niemals Pakete unbedacht mit einer Angabe einer Fehlermeldung (reject) ablehnen. Es könnte schließlich sein, daß die Anwendung, die die Pakete sendet, ICMP Fehlermeldungen nicht interpretieren kann. In diesem Fall würde eine Flut von Fehlermeldungen die freie Bandbreite der Leitungen unnötig belasten. Außerdem würde von der Firewall eine Unzahl von Fehlermeldungen gesendet werden. Die gängigen Implementierungen von TCP beachten sehr wohl ICMP Fehlermeldungen, aber in Abhängigkeit der Meldung (host unreachable), könnte der Sender meinen, daß der Host nur vorübergehend überlastet ist, und würde ständig die Pakete neu senden. Um also wirklich eine Verbindung zurückzuweisen, ist es notwendig, im TCP Paket noch ein Flag zu setzen, beispielsweise das RST Bit, welches das Ende einer TCP Verbindung einleitet.(reset)
Viele Programme unterscheiden nicht zwischen den verschiedenen ICMP unreachable Mitteilungen. Somit kann es passieren, daß ein Host völlig unerreichbar wird, was sicher nicht so beabsichtigt ist. ICMP Fehlermeldungen sollten also niemals einfach mit einem reject beantwortet werden. Um dieses Problem zu umgehen, benutzt die SINUS Firewall die Option reject with best, was bedeutet, daß die TCP Pakete mit einem RST Flag zurückgesandt werden. Eine ICMP port unreachable Nachricht wird für UDP und alle sonstigen Pakete erzeugt.
Wenn man die Regeln für TCP Pakete aufsetzt, gibt die from Adresse den Initiator der Verbindung an. Antwortpakete aus dem Internet, z.B. sofern sie von innen initiiert worden sind, dürfen die Firewall passieren. Sie haben alle das ACK Bit gesetzt. Ist der notification level größer 0, dann wird nur zu Begin des Verbindungsaufbaues, also wenn das SYN Bit gesetzt ist, ein Logeintrag erzeugt. Alle weiteren Antwortpakete werden nicht mehr mitgeloggt.
Das FTP Protokoll erfordert eine spezielle Behandlung, da hier ein zweiter Datenkanal geöffnet wird, welcher vom Server initiiert wird. Die erste Verbindung, die von innerhalb geöffnet wurde enthält den PORT Befehl, der vom Server zum Client intern übermittelt wird. Dieser Port ist derjenige, den der Server zwecks Datenaustasch mit dem Client zu benutzen gedenkt. Eine normaler, dynamischer Paketfilter würde diesen PORT Befehl nicht interpretieren können. Der Systemadministrator muß dann entweder alle Ports freischalten, oder sperren. Glücklicherweise unterstützen inzwischen fast alle Firewalls den PASV oder passive Modus. Hierbei wird der PORT Befehl aus dem Paket gelesen, und die Firewall kann dann diesen Port für Antwortpakete aus dem Internet freischalten.
Der Paketfilter wird bei jedem gesendeten Paket gebraucht. Ein geforwardetes Paket wird nur beim eintreffen analysiert. Zum Zeitpunkt des Sendens wird zunächst nur das Interface überprüft, um address spoofing zu verhindern. Lokale Pakete, die nicht den Host verlassen, wenden nur beim Senden analysiert.
Address Spoofing
Ein Alarm wegen address spoofing wird immer dann gegeben, wenn:
Eine wichtige Information: Class D (multicasting) und class E Adressen werde nicht auf adress spoofing untersucht, da diese in andere Pakete gekapselt wurden. Hierzu müsste die Firewall in alle Pakete hineinschauen, und dann erst filtern. Dies würde bei dieser Konzeption der Firewall einen großen Ballast bedeuten.
Fragmentierte IP Pakete Nur das erste Fragment eines IP-Paketes und das Ergebnis der Untersuchung wird gespeichert. Alle darauffolgenden Pakete werden verworfen, wenn das erste Paket nicht akzeptiert wurde. Wenn Fragmente nicht in der richtigen Reihenfolge eintreffen, dann werden diejenigen, die voreilig auf das Interface getroffen sind, geblockt, also verworfen.
configuration = setup_section
rules_section
[ notification_section ]
"end.".
setup_section = "setup"
[ internal_statement ]
mail_statement.
rules_section = "rules" { ( block_statement
| accept_statement
| reject_statement ) }.
setup_statement = "internalnets" address { "," address } ";".
mail_statement = "mail_default" """ mailaddress(es) """ ";".
block_statement = "block" rule ";".
accept_statement = "accept" rule ";".
reject_statement = "reject" [ "with" ( "icmp_net_unreachable"
| "icmp_host_unreachable"
| "icmp_protocol_unreachable"
| "icmp_port_unreachable"
| "tcp_reset"
| "best"
| "echo_reply" ) ]
rule ";".
rule = [ "options" ip_option { "," ip_option } ]
( "all"
| protocol_number
| "icmp" [ icmp_type { "," icmp_type } ]
| "igmp" [ igmp_type { "," igmp_type } ]
| "tcp"
| "udp"
| "rip" [ ( address { "," address } | inside | outside ) ] )
[ "from" ( fulladdr { "," fulladdr }
| "inside" [ "port" port [ ".." port ] ]
| "outside" [ "port" port [ ".." port ] ] ) ]
[ "to" ( fulladdr { "," fulladdr }
| "inside" [ "port" port [ ".." port ] ]
| "outside" [ "port" port [ ".." port ] ] ) ]
"notification_level" value.
ip_option = ( "record_route"
| "timestamp"
| "security"
| "loose_source_route"
| "strict_source_route"
| "sat_id"
| "time_to_live" ( "<" | "=" | ">" | "!=" ) value ).
icmp_type = ( "icmp_echo_reply"
| "icmp_destination_unreachable"
| "icmp_source_quench"
| "icmp_redirect"
| "icmp_echo_request"
| "icmp_time_exceeded"
| "icmp_parameter_problem"
| "icmp_timestamp"
| "icmp_timestamp_reply"
| "icmp_info_request"
| "icmp_info_reply"
| "icmp_address"
| "icmp_address_reply" ).
igmp_type = ( "igmp_host_membership_query"
| "igmp_host_membership_report"
| "igmp_host_leave_message" ).
fulladdr = ( address [ "port" port [ ".." port ] ]
| "port" port [ ".." port ] ).
address = ( ip_address | """ name """ ) [ "mask" mask ].
port = ( port_no | name ).
notification_section = "notification"
"level" ( value | "spoof" ) ":" ( { entry ";" } | ";" )
{ "level" ( value | "spoof" ) ":" ( { entry ";" } | ";" ) }.
entry = ( "message" """ text """ { """ text """ }
| "syslog"
| "report"
| "mail" [ """ mailaddress(es) """ ]
| "spy"
| "exec" """ command """
| "relevel" value
| "call" value
| "if" ( variable | value ) ( "<" | "=" | ">" | "!=" )
( variable | value ) "then"
{ entry ";" } "endif"
| "let" variable ":="
( value | "destport" | variable
[ ( "+" | "-" ) ( value | variable ) ] )
[ "timeout" seconds ]
| dynamic_rule [ "timeout" seconds ]
).
variable = name [ ":" qualifier ].
qualifier = ( "sourcehost" | "desthost" ).
[ special keywords allowed in dynamic_rule:
"currentprotocol" uses protocol of actual packet
"sourcehost" uses source host address
"sourcenet" uses source net address
"desthost" uses destination host address
"destnet" uses destination net address ]
Hier nun einige Beispiele die zeigen, wie leistungsfähig diese Programmiersprache ist.
Zuerst sollte man sorgfältig die Syntax studieren. In diesem Abschnitt wird ein praktisches, funktionierendes Beispiel einer Konfiguration beschrieben. Es ist als Konfigurationsfile in der Distribution unter samples/ zu finden.
setup
internalnets 193.194.195.0;
mail_default "adm@x.y.z";
rules
# Some simple alarming rules to detect hackers
block tcp to port 87, /* link */
port 95 /* supdup */
notification_level 99;
block options loose_source_route, strict_source_route all
notification_level 13;
# ...omit some more RIP statements
# detect secondary routes to the internet
block rip from inside notification_level 12;
# ...omit some more statements having notification level 0
# Permit incoming FTP requests to our FTP server only
accept tcp to 130.59.4.16 port 21 notification_level 1;
# Permit incoming Telnet requests to our Telnet/Login Server only
accept tcp to 130.59.4.16 port 23 notification_level 2;
accept all from 127.0.0.1 to 127.0.0.1 notification_level 0;
# block all other TCP connection requests and trigger the alarm
block tcp notification_level 99;
notification level 1: /* log all permitted incoming FTP connection requests */
message "FTP connection request.";
level 2: /* log all permitted incoming Telnet connection requests */
message "Telnet connection request.";
level 3: /* log all permitted incoming WWW connection requests */
message "WWW connection request.";
level 11:
message "ICMP redirect received.";
level 12:
message "There may be a secondary route to the internet.";
level 13:
message "IP packet with source route option detected";
let sr:sourcehost := sr:sourcehost + 1 timeout 300;
if sr:sourcehost = 1 then
message "IP packet with source route option detected";
spy;
endif;
level 99:
message "Illegal TCP connection.";
syslog;
let illtcp:sourcehost := illtcp:sourcehost + 1 timeout 600;
if illtcp:sourcehost = 1 then
message "Illegal TCP connection.";
mail;
spy;
endif;
end.
Diese Beispiele zeigen alle Möglichkeiten der Benutzung der Schlüsselwortes notification. Der Einsatz der Befehle ist einfach, z.B. exec /sbin/ifconfig eth0 down sorgt dafür, daß die Netzwerkkarte deaktiviert wird.
Im Gegensatz zu den nur zeitweise aktiven, dynamischen Regeln, die statische Regeln vorübergehend ersetzen, ist die Regel relevel permanent, also von Dauer.
Angenommen, level 100 war der notification level, der ausgelöst wurde, als die Firewall gepingt wurde. Das Logfile würde sehr schnell anwachsen, wenn wirklich jedes ping geloggt würde. Die erste Idee ist, ein relevel auf die Regel anzuwenden:
notification level 100: message "Wir sind gepingt worden"; relevel 0;
Genau dies ist aber eine schlechte Idee. Ein einzelnes ping würde ausreichen, um die Regel quasi außer Betrieb zu nehmen. Weitere ping Versuche würde nicht mehr entdeckt werden können. Da die Regel nach dem ersten Ping außer Funktion gesetzt wird, erscheinen in dem Logfile also alle weiteren Pings nicht mehr. Das ist so sicher nicht beabsichtigt. Damit auch alle weiteren Pings bemerkt werden können, muß die Regel so aussehen:
notification
level 100:
let pings:sourcehost := pings:sourcehost + 1 timeout 600; /* 10 minutes */
if pings:sourcehost = 1 then
message "We have been pinged";
endif;
Wenn wir einen versuchten DoS Angriff (Denial of Service) mitloggen möchten, dann können wird eine dynamische Regel hierfür verwenden, und danach alle weiteren Ping blocken.(block)
if pings:sourcehost > 1000 then
message "Möglicher denial-of-service attack";
spy;
block all from sourcehost notification_level 0 timeout 600;
endif;
Natürlich ist es so nicht möglich, einen echten DoS Angriff, der in der Folge oder abwechselnd ftp Verbindungen aufbaut, zu bekämpfen. Wichtig ist es jedoch, z.B. Hosts mit ftp Diensten vor einem solchen Angriff zu bewahren.
Wie man sieht, ist es mit der SINUS Firewall-1 möglich, aufgebaute Verbindungen in Variablen zu vermerken und daraufhin weitere Regeln zu aktivieren. Wer sich einmal in Kapitel Netmeeting Protokoll umschaut, der wird erkennen, daß man, um einen Netmeeting Proxy zu simulieren, genau diesen Mechanismus implementieren kann. Leider muß die SINUS Firewall-1 für die weiteren UDP Übertragungen über wechselnde Ports oberhalb von 1024 zu einem bestimmten Host im Internet alle UDP Ports zu dem Client im geschützten Intranet freigeben. Die Regel wird also etwas länger.
Um eine solche Regel implementieren zu können, muß man sich zuerst die DRAFTS der RFC´s über Netmeeting besorgen. Hierzu wendet man sich entweder an den Microsoft Server, oder man sucht im Internet nach den entsprechenden RFC´s. Darin ist genau beschrieben, welche Ports und Protokolle in welcher Reihenfolge geöffnet und geschlossen werden können, und welche Timeouts hier eine Rolle spielen. Danach erfolgt die Programmierung der Firewall. Hier sollte man alle DEBUG-Optionen aktiviert haben, d.h. stets sollte man von "message" Gebrauch machen, um aussagefähige Log-Einträge zu erhalten. Nun kann eine Testverbindung zu einem Netmeeting Server im Internet aufgebaut werden. Das wunderbare an Microsoft ist es, daß die Leute sich fast nie an ihre eigenen Dokumentationen und Standards halten. Daher ist es unabdingbar, die Meldungen der Firewall genau zu studieren und den Fehler im Mechanismus der Firewall zu korrigieren.
Die deduktive Methode unterscheidet sich nur ein wenig von der induktiven. Man arbeitet einfach ohne alle RFC´s und Dokumentationen und schert sich einen Dreck um Microsofts Unzulänglichkeiten. Hierzu schaltet man in der Firewall alle TCP und UDP Ports auf Durchgang und loggt mit. In den LOG-Einträgen sieht man dann schön sauber, wie der Mechanismus funktioniert. Diese Dokumentationen nimmt man dann als Vorlage für die Implementierung der Regeln in der SINUS Firewall-1. Da bei Microsoft typischerweise verschiedene Service-Packs auch Veränderungen bei Anwendungssoftware enthalten, kann es also passieren, daß die Firewallregeln von Zeit zu Zeit verändert werden müssen, weil Microsoft mal wieder irgendwelche Verbesserungen eingefallen sind. Wer eine kommerzielle Firewall, wie z.B. Firewall-1 von Checkpoint gekauft hat, der muß für die kleinen Änderungen der Regeln teuer bezahlen. Der Händler selber vor Ort schaut in der Support-Datenbank von Checkpoint nach, und kopiert das Makro auf die Firewall-fertig.
Für die SINUS Firewall-1 gibt es für viele Protokolle Makro´s, der Support ist gerade im Aufbau. Mit der Implementierung der SINUS Firewall-1 auf die Kernel 2.2 werden diese Makro´s auch frei verfügbar sein.
Zusammenfassend kann man sagen, daß die SINUS Firewall alle Protokolle absichern kann, einen hochwertigen PROXY ersetzt sie allerdings nicht. Aber auch Firewall-1 von Checkpoint beherrscht nicht alle Protokolle perfekt.
|
|
Online Suche im Handbuch | LITTLE-IDIOT NETWORKING |