orm@doc-tcpip.org

Erstellt: November 2001 - Letzte Modifikation: November 2003

[ Main | Local ]


DNS absichern

Darüber sollte man nachdenken....

DNS sicher aufbauen

Was man nicht machen sollte (Single Points of Failure):

Was man immer beachten sollte:

Mehrere physikalische Wege ins Netzwerk. Dabei kann es sein, daß verschiedene Provider auf demselben IP-Backbone operieren - das muß man prüfen.

Ein Off-Site Nameserver (Secondary/Slave) einrichten:

Dadurch wird es möglich, einen Fehler von Außen zu suchen, sowohl für die lokalen Administratoren wie auch für externe Administratoren, denen das Problem aufgefallen ist.

Außerdem geht keine Mail verloren. Kann ein externen Mail-Server die lokale Domäne wegen des DNS-Ausfalles nicht auflösen, so geht die Mail als unzustellbar (bounced) zurück. Funktioniert die Auflösung, so Queued der externe Mailserver die Mail und versucht es später nocheinmal - dazu muß der eigene Mailserver nicht erreichbar sein.

Gefahren für den Nameserver

Nameserver geben eigene Information heraus, für die sie verantwortlich und kompetent sind (authoritative data) sowie Informationen, die sie erfahren haben und in ihrem Cache halten (non-authoritative data). Für diese Daten sind sie nicht verantwortlich und auch nicht kompetent.

Ein Nameserver kann beide Aufgaben erfüllen; daß ist aber nicht empfehlenswert, da beide Arten des Zugriffs von unterschiedlichen Client-Gruppen erfolgen. Daher ist es ratsam, einen NS im lokalen Netz zu betreiben, der die eigene Zone verantwortlich bedient, alle anderen Anfragen rekursiv ermittelt und damit auch cached.

Für Anfragen aus dem Internet steht außerhalb des eigenen Netzes (oder in einer DMZ) ein weiterer NS zur Verfügung, der nicht rekursiv nur Anfragen zur eigenen Zone beantwortet - für diese ist er verantwortlich.

Dafür gibt es gute Gründe:

Sicheres Layout der Nameserver

Die Argumente aus dem vorigen Absatz führen zu folgendem Aufbau:

 
Netz                DMZ              GBI

DNS intern         DNS extern
(resolving Server) (advertising Server) 

eigene Clients

DNS intern

Kann, muß aber nicht Verantwortlich (Authoritär) sein für die eigene Zone.

Dieser Server ist ein rekursiver Server: Er verfolgt eigenständig die Anfrage, folgt also allen Verweisen anderer Nameserver und gibt dem Client eine vollständige Antwort, die er auch in seinem Cache ablegt. Diese Antworten sind dann nicht mehr authoritär.

Authoritär für eine Zone ist der Server, wenn er für mindestens eine Zone einen Zonen-Eintrag als master oder slave hat:

 
zone "bla.com" {
type master;
file "/named/files/bla.com";
};

Der Server cached, wenn für eine Zone ein hint-Statement existiert. Das ist normaleweise die root-Zone, der Server nimmt sich so aller Anfragen an:

 
zone "." {
type hint;
file "named.root";
};

Zusätzlich sind natürlich noch die Master-Einträge für 0.0.0.127.IN-ADDR.ARPA sowie alle privaten Netze (RFC 1918) nötig.

Dieser Server sollte nur von den lokalen Clients gesehen werden. Er steht also hinter der Firewall und wird zusätzlich noch über IP-Filter gesichert.

DNS extern

Ist Verantwortlich (Authoritär) für die eigene Zone. Dieser Server ist ein nicht-rekursiver Server: Er beantwortet nur Anfragen zur eigenen Zone. Er verfolgt Anfragen nicht weiter und sendet entweder eine Antwort (also einen gültigen RR), oder einen Fehler (NXDOMAIN bzw. SERVFAIL). Die Art des Fehlers hängt davon ab, ob der Server ein Root-Zone Hint-File nutzt, also ein Referral (einen Verweis) auf einen kompetenten Server bietet. Es wird empfohlen, keine Hints weiterzugeben.

 
options {
    recursion no;
    fetch-glue no;
};
 
zone "bla.com" {
type master;
file "/named/files/bla.com";
};

Dieser Server steht im Internet oder in der DMZ und wird zusätzlich über IP-Filterregeln geschützt.

Die Filterregeln

Der externe NS im Internet (Advertising Server) empfängt Anfragen und sendet Antworten. Es müßen also folgende Regeln existieren:

 
         Source IP    Port         Dest. IP  Dest. Port
Inbound    any        53 tcp/udp     NS IP     53 tcp/udp
                      > 1023 tcp/udp

Outbound   NS IP      53 tcp/udp     any       53 tcp/udp
                                               > 1023 tcp/udp

Der interne NS im lokalen Netz empfängt Anfragen aller interner Clients, stellt diese Fragen rekursiv an andere NS im Internet.

Es müßen also folgende Regeln existieren:

 
         Source IP    Port         Dest. IP  Dest. Port
Inbound    inter. Netz  > 1023 tcp/udp  NS IP   53 tcp/udp
Client                   

Outbound    NS IP      53 tcp/udp     inter. Netz   > 1023 tcp/udp
Client                 

Outbound    NS IP      53 tcp/udp         any       53 tcp/udp
rec. Anfragen          > 1023 tcp/udp 

Inbound      any      53 tcp/udp        NS IP      53 tcp/udp
rec. Anworten                                      > 1023 tcp/udp 

Am Ende der Seite findet sich ein Beispiel eines DNS Servers (AIX 5.1) im lokalen Netz, der stark abgesichert ist. Über das Token-Ring Interface ist nur DNS nach obiger Tabelle möglich, sowie Telnet und SSH. Man sollte das im eigenen Netz noch weiter Einschränken, sodaß nur noch Login per SSH von bestimmten Maschinen möglich ist.

Auf dem Server müssen dazu nur die entsprechenden IPSec Filesets (bos.net.ipsec.*) installiert sein. Die Regeln können dann mit den genfilter-Kommandos generiert werden. Zur Sicherheit sollte man das funktionierende Regelwerk exportieren und gut aufgebewahren.

Zonetransfer einschränken

Ein Zonentransfer ist die Übertragung von DNS Informationen von einem Server zum Anderen (Master zu Slave).

Alle authoritativen Server, egal ob Master oder Slave, sollten Zonen-Transfers verbieten. Die wirklich nötigen Transfers werden dann ermittelt und entsprechend verschlüsselt und authentifiziert zugelassen.

Ob ein Server Zonentranfers zuläßt, ist leicht mit einfachen Kommandos zu testen: host -l, dig axfr oder nslookup (-l auf die Zone).

Im Fall von BIND8/9 kann man den Transfer nach Server und Zone spezifizieren.

Server spezifisch:

 
options {
    allow-transfer { xxx.xxx.xxx.xxx; }; 
};

Zonen spezifisch:

 
zone "bla.com" {
type master;
file "/named/files/bla.com";
    allow-transfer { xxx.xxx.xxx.xxx; }; 
};

Zonen Transfer authentifizieren

Dazu gibt es ab BIND 8.2 die Transaction Signature (TSIG).

Die Authentifizierung erfolgt per kryptographischer Methode, zugleich eine Verifikation der Zonen-Information durch diese Methode.

TSIG ist also eine Shared Secret Cryptographic Signature zur authentifizierung von authoritativen Zonen-Informationen.

Dazu ist ein Shared Key auf Master und Slave zur Unterzeichnung der Zonen-Daten und der Session nötig.

Wichtig ist dabei: Beide Server brauchen eine synchrone Zeit!

Im Fall von BIND 8/9 stellt sich das Ganze so dar:

 
Name des Schlüssels: mein-schlüssel
Auf dem Master Server: 

key mein_schlüssel. {
     algorithm hmac-md5;
     secret "xyzurtsdfghjk";
};

zone "bla.com" {
type master;
file "/named/data/bla.com";
allow-transfer { key mein_schlüssel; };
};

Auf dem Slave Server: 

key mein_schlüssel. {
     algorithm hmac-md5;
     secret "xyzurtsdfghjk";
};

server xxx.xxx.xxx.xxx {
      transfer-format many-answers;
      keys { mein_schlüssel.; };
};

zone "bla.com" {
type slave;
file "/named/data/slave.bla.com";
allow-transfer { none; };
};

Einschänken dynamischer Updates

Das ist per individueller Adresse oder per TSIG Key möglich.

Dynamische Updates werden per UDP gemacht. Es reicht also ein gefälschtes Paket. Außerdem ist es relativ leicht, IP-Adressen zu fälschen. Daher verdient DDNS ein besonderes Augenmerk.

Erlauben von dynamischen Updates:

 
zone "bla.com" {
type master;
file "/named/data/dyn.bla.com";
allow-update {
      localhost;
      key user_allowed_updater.;
      };
};

Jetzt kann diese Zone von der Maschine Localhost (der IP-Adresse) und von jedem anderen User mit dem Key "user_allowed_updater" verändert werden. Der Key muß an anderer Stelle definiert sein.

Diese Einstellung gilt nun für die ganze Zone.

Einzelne RR erfordern eine neue, delegierte Zone (Beispiel seppel.bla.com).

Im Datenbank-File bla.com wird der entsprechende RR durch die Delegation auf den eigenen NS ersetzt:

 
IN    NS   ns1.bla.com.

In der named.conf wird eine neue (delegierte) Zone eingerichtet:

 
zone "seppel.bla.com" {
type master; 
file "/named/data/seppel.bla.com";
allow-update {
      key allowed_seppel_updater;
      };
};

Jetzt kann ein User mit diesem Key den RR der Adresse seppel.bla.com ändern.

In BIND 9 ist das etwas komfortabler:

Mit dem update-policy Statement:

 
zone "bla.com" {
type master;
file "/named/data/bla.com";
update-policy {
grant allowed-seppel-updater self seppel.bla.com A;
};
};

Der User mit dem Key allowed-seppel-updater kann den seppel.bla.com RR ändern. Er kann keine Subdomänen anlegen oder andere RR-Typen ändern.

Cache Poisioning

Zuerst nocheinmal eine Recursive Anfrage:

 
                                       NS 2 (auch keine
                                       / /   Ahnung)
                                      2 3
                                     / /
               Client  --- 1 --->  NSloc     --- 4 --->  NS 3
                       <-- 6 ---   hat keine <-- 5 ---   hat Ahnung
                                   Ahnung
3 = Referral oder SERVFAIL
5 = Antwort oder Error

Und eine nicht-Rekursive Anfrage:

 
               Client  --- 1 --->  NSloc     
                       <-- 2 ---   hat keine 
                                   Ahnung
2 = Referral oder SERVFAIL

Ein Server, der im GBI (großes, böses Internet) rekursive Name Resolution anbietet, läuft in die Gefahr, seinen Cache vergiftet zu bekommen.

Der NS hat dann gefälschte Daten (RR) mit einer hohe TTL in seinem Cache und bedient damit alle Anfragen.

Das kann zu Denial of Service oder Man in the Middle Angriffen führen, da man ohne es zu merken an eine andere Maschine umgeleitet wird.

Der Angreifer braucht dazu einen NS unter seiner Kontrolle, und er muß per rekursive Anfrage sein Opfer dazu bringen, bei diesem gefälschten Server anzufragen. Die Information landet dann automatisch im Cache des Opfers.

Gegenmaßnahmen:

Abschalten der Rekursion (Advertising Server)

Der NS wird passiv, sendet also für Andere keine Anfragen an weitere NS. Es werden nur direkte Anfragen beantwortet (kein Caching, nur die Datenfiles).

Damit kann der Server auch nicht als Multiplikator in einer DDoS Attacke dienen. (Anfrage auf eine Domäne, externe Zone, die weitergeleitet wird).

BIND 8/9

 
options {
...
recursion no;
...
};

Einschränken der Zahl der Clients für rekursive Anfragen

Das stumpfe Abschalten ist nicht immer eine Alternative. Daher kann man:

Adressen definieren, die Anfragen dürfen, sowie Zonen definieren, die Angefragt werden dürfen.

Meist ist es so, daß Anfragen auf authoritative Zonen von überall kommen können, rekursive Anfragen von Clients (also Anfragen, für die der Server nicht Authoritär ist) jedoch nur aus dem lokalen Netz kommen können.

Internes Netzwerk: 10.10.10.0/24, bla.com

Rekursiver Service für diesen Netzblock. Dazu müßen Access Control Listen (acl) eingerichtet werden:

 
acl intern { 10.10.10.0/24; };

Bei einem Caching Only NS, der nur mit anderen, internen NS redet:

 
acl intern { IP-NS1/32; IP-NS2/32; };

Der Server soll nur interne Clients bedienen:

 
option {
      ...
      allow-query { intern; };
      ...
};

Der Default wird für bla.com überspielt:

 
zone "bla.com" {
     type master;
     file "/named/data/bla.com";
     allow-query { any; };
};

Rekursion einschränken allow-recursion

Dient zur Einschränkung der Clients, die rekursive Anfragen stellen dürfen. Alle Anfragen von Adressen, die nicht in diesen Block fallen, werden automatisch als nicht-rekursive Anfragen behandelt - unabhängig vom Wunsch des Clients.

 
acl intern { 10.10.10.0/24; }; // Definition des internen Netzes

options {
     ...
     allow-recursion { internal; };
     ...
};

Die Definition der Domäne bleibt unverändert.

Mit BIND 9 kann man views einrichten. Das ermöglicht dem NS, je nach IP des anfragenden Clients/Servers eine andere Antwort zu geben.

Man kann also zwei Gruppen bilden, die zwar die gleichen Daten sehen (z.B. bla.com) aber in einem Fall (interne-view) als rekursive Anfrage, im anderen Fall (externe-view) als nicht-rekursive Anfrage.

Diese Einteilung der Domäne bezeichnet man als split DNS.

Welche Netzblöcke intern und extern sind, muß per acl definiert werden.

 
zone "bla.com" {
     type master;
     file "/named/data/bla.com";
};

view "interne-view" {
     match-clients { intern; };
     recursion yes;
};

view "externe-view" {
     match-clients { any; };
     recursion no;
};
 
Abschalten des Glue Fetching

Als Glue bezeichnet man bei der Delegation
einer Zone die Angabe der IP des für die
delegierte Zone verantwortlichen NS (sonst
hat man ein Problem, den der NS ist in dieser
Zone..).

Glue Fetching ist, wenn ein NS auf einen anderen,
verantwortlichen NS verweist (mit dem Namen),
und vorher noch versucht, per Lookup die IP-Adresse
in Erfahrung zu bringen. Das kann man zum Vergiften
des Cache nutzen.

BIND 9 tut das generell nicht mehr. Im Fall von 
BIND 8 kann man es unterbinden:

options {
...
fetch-glue no;
...
};

Message IDs zufällig erzeugen

Der NS vergibt für jede Anfrage eine Message ID,
damit er die Antworten entsprechend zuordnen kann.
Ein Angreifer kann relativ einfach die Sequenz
der ID Nummern erraten und so gefälschte 
Informationen an den Server übermitteln.

Man kann in BIND 8 die Nummern zufällig vergeben,
BIND 9 tut genau das per Default.

options {
...
use-id-pool yes;
...
};

User switch

BIND ermöglicht es, den Nameserver zwar als User 
root zu starten, dann aber als ein anderer User
weiterzuarbeiten. Dieser besondere Account hat 
dann nur die nötigsten Rechte.

Dazu muß man:

Einen User und seine Gruppe anlegen.

Der User muß die Zonen-Files lesen können.
(Die named.conf nicht, den der Service startet 
als root!)

Bei dynamischen Updates muß der User die Zonen-Files
schreiben können.

Der User muß das .pid File des named lesen können.
(meist in /var/run/named.pid - schwer zu lesen 
für einen einfachen User. Daher die Pid-file Option:
pid-file "/var/named/named.pid";)

Starten des named mit dem Flag -u:
named -u named   (<== Der User)

Möglich ist auch ein chroot()-Gefängnis.
Das ist aufwändig und soll hier nicht besprochen werden.


Wie prüfe ich, ob alles stimmt?
Wichtig ist der Zustand des Servers im Internet.
Bei Anfragen nach fremden Domänen sollte ein 
SERVFAIL kommen.

dig @127.0.0.1 blub.com soa
....

In den Flags taucht ra (recursion available) nicht 
auf.


Beispiele:

primary master, nicht rekursiv, kein forwarding,
Zonen-Tranfer an über die IP authentifizierte
Sklaven.

acl sklaven { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; };

options {
directory "/named";
recursion no;
fetch-glue no; // BIND 8
allow-query { any; };
};

zone "bla.com" {
type master;
file "/named/data/bla.com";
allow-transfer { sklaven; };
};

Zusätzlich mit TSIG Authentifizierung des Zonen-Transfers:

key master-sklave. {
algorithm hmac-md5;
secret "hkerwfklsdgnsdnnngktkjgk";
};

options {
directory "/named";
recursion no;
fetch-glue no; // BIND 8
allow-query { any; };
};

zone "bla.com" {
type master;
file "/named/data/bla.com";
allow-transfer { key master-sklave.; };
};

Ein primary master NS, der rekursive Anfragen zuläßt 

acl intern { xxx.xxx.xxx/24; };
acl sklaven { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; };
options {
directory "/named";
recursion yes;
allow-query { intern; };
use-id-pool yes; // BIND 8
};

zone "bla.com" {
type master;
file "/named/data/bla.com";
allow-transfer { sklaven; };
allow-query { any; };
};

slave NS, Forwarder


acl intern { xxx.xxx.xxx/24; };
options {
directory "/named";
recursion yes;
allow-recursion { intern; };
use-id-pool yes; // BIND 8
};

zone "bla.com" {
type slave;
masters { xxx.xxx.xxx.xxx; };
file "/named/data/second.bla.com";
allow-query { any; };
allow-transfer { none; };
};

Caching only Server

acl intern { xxx.xxx.xxx/24; };
options {
directory "/named";
recursion yes;
use-id-pool yes; // BIND 8
allow-query { intern; };
};

zone "." {
type hint;
file "/named/data/bla.cache";
};

Advertising Server

acl sklaven { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; };
options {
directory "/named";
recursion no;
fetch-glue no; // BIND 8
allow-query { any; };
};

zone "bla.com" {
type master;
file "/named/data/bla.com";
allow-transfer { sklaven; };
};

Resolving Server

acl intern { xxx.xxx.xxx/24; };
options {
directory "/named";
recursion yes;
use-id-pool yes; // BIND 8
allow-query { intern; };
};

zone "." {
type hint;
file "/named/data/bla.cache";
};

zone "bla.com" {
type slave;
masters { xxx.xxx.xxx.xxx; };
file "/named/data/second.bla.com";
allow-transfer { intern; };
};

IPSec Filterregeln für ein AIX (5.1, 5.2) System

 
# int. Netz, Port > 1023, udp ==> NS IP, Port 53, udp INBOUND
genfilt -v 4 -a P -s 10.55.17.0 -m 255.255.128.0 -d 10.55.17.115 -M 255.255.255.255 -c udp -o gt -p 1023 -O eq -P 53 -r L -w I -i tr0 ##-D "DNS anfrage udp"
# int. Netz, Port > 1023, tcp ==> NS IP, Port 53, tcp INBOUND
genfilt -v 4 -a P -s 10.55.17.0 -m 255.255.255.0 -d 10.55.17.115 -M 255.255.255.255 -c tcp -o gt -p 1023 -O eq -P 53 -r L -w I -i tr0 ##-D "DNS anfrage tcp"
# NS IP, Port 53, udp ===> int. Netz, Port > 1023, udp, OUTBOUND
genfilt -v 4 -a P -s 10.55.17.115 -m 255.255.255.255 -d 10.55.17.0 -M 255.255.128.0 -c udp -o eq -p 53 -O gt -P 1023 -r L -w O  -i tr0 #-D "DNS antwort udp"
# NS IP, Port 53, tcp ===> int. Netz, Port > 1023, tcp, OUTBOUND
genfilt -v 4 -a P -s 10.55.17.115 -m 255.255.255.255 -d 10.55.17.0 -M 255.255.128.0 -c tcp -o eq -p 53 -O gt -P 1023 -r L -w O -i tr0 #-D "DNS antwort tcp"

# NS IP, Port > 1023, udp ===> any DNS, Port 53, udp, OUTBOUND 
genfilt -v 4 -a P -s 10.55.17.115 -m 255.255.255.255 -d 0.0.0.0 -M 0.0.0.0 -c udp -o gt -p 1023 -O eq -P 53 -r B -w O -i tr0 #-D "DNS rec von p 1023 udp"
# NS IP, Port > 53, udp ===> any DNS, Port 53, udp, OUTBOUND 
genfilt -v 4 -a P -s 10.55.17.115 -m 255.255.255.255 -d 0.0.0.0 -M 0.0.0.0 -c udp -o eq -p 53 -O eq -P 53 -r B -w O -i tr0 #-D "DNS rec von p 53 udp"
# NS IP, Port > 1023, tcp ===> any DNS, Port 53, tcp, OUTBOUND 
genfilt -v 4 -a P -s 10.55.17.115 -m 255.255.255.255 -d 0.0.0.0 -M 0.0.0.0 -c tcp -o gt -p 1023 -O eq -P 53 -r B -w O -i tr0 #-D "DNS rec von p 1023 tcp"
# NS IP, Port > 53, tcp ===> any DNS, Port 53, tcp, OUTBOUND 
genfilt -v 4 -a P -s 10.55.17.115 -m 255.255.255.255 -d 0.0.0.0 -M 0.0.0.0 -c tcp -o eq -p 53 -O eq -P 53 -r B -w O -i tr0 #-D "DNS rec von p 53 tcp"

# any DNS, Port 53, tcp ===> NS IP, Port 53, tcp, INBOUND
genfilt -v 4 -a P -s 0.0.0.0 -m 0.0.0.0 -d 10.55.17.115 -M 255.255.255.255 -c tcp -o eq -p 53 -O eq -P 53 -r B -w I -i tr0 #-D "DNS ext answer p 53 tcp"
# any DNS, Port 53, tcp ===> NS IP, Port > 1023, tcp, INBOUND
genfilt -v 4 -a P -s 0.0.0.0 -m 0.0.0.0 -d 10.55.17.115 -M 255.255.255.255 -c tcp -o eq -p 53 -O gt -P 1023 -r B -w I -i tr0 #-D "DNS ext answer p 1023 tcp"
# any DNS, Port 53, udp ===> NS IP, Port 53, udp, INBOUND
genfilt -v 4 -a P -s 0.0.0.0 -m 0.0.0.0 -d 10.55.17.115 -M 255.255.255.255 -c udp -o eq -p 53 -O eq -P 53 -r B -w I -i tr0 #-D "DNS ext answer p 53 udp"
# any DNS, Port 53, udp ===> NS IP, Port > 1023, udp, INBOUND
genfilt -v 4 -a P -s 0.0.0.0 -m 0.0.0.0 -d 10.55.17.115 -M 255.255.255.255 -c udp -o eq -p 53 -O gt -P 1023 -r B -w I -i tr0 #-D "DNS ext answer p 1023 udp"

# SSH auf den DNS Server
# int. Netz, Port > 1023, tcp ==> NS IP, Port 22, tcp INBOUND
/usr/sbin/genfilt -v 4  -a 'P' -s '10.55.17.0' -m '255.255.128.0' -d '10.55.17.115' -M '255.255.255.255' -g 'y' -c 'tcp' -o 'gt' -p '1023' -O 'eq' -P '22' -r 'B' -w 'I' -l 'N' -f 'y' -t '0' -i 'tr0' #-D "SSH rein 1"
#
# NS IP, Port 22, tcp ===> int. Netz, Port 1023, tcp OUTBOUND
/usr/sbin/genfilt -v 4  -a 'P' -s '10.55.17.115' -m '255.255.255.255' -d '10.55.17.0' -M '255.255.128.0' -g 'y' -c 'tcp' -o 'eq' -p '22' -O 'gt' -P '1023' -r 'B' -w 'O' -l 'N' -f 'y' -t '0' -i 'tr0' #-D "SSH rein 2"
#
# SSH vom DNS Server
# int. Netz, Port 22, tcp ==> NS IP, Port > 1023, tcp INBOUND
/usr/sbin/genfilt -v 4  -a 'P' -s '10.55.17.0' -m '255.255.128.0' -d '10.55.17.115' -M '255.255.255.255' -g 'y' -c 'tcp' -o 'eq' -p '22' -O 'gt' -P '1023' -r 'B' -w 'I' -l 'N' -f 'y' -t '0' -i 'tr0' #-D "SSH raus 1"
#
# NS IP, Port > 1023, tcp ===> int. Netz, Port 22, tcp OUTBOUND
/usr/sbin/genfilt -v 4  -a 'P' -s '10.55.17.115' -m '255.255.255.255' -d '10.55.17.0' -M '255.255.128.0' -g 'y' -c 'tcp' -o 'gt' -p '1023' -O 'eq' -P '22' -r 'B' -w 'O' -l 'N' -f 'y' -t '0' -i 'tr0' #-D "SSH raus 2"
#
# Telnet auf den DNS Server
# int. Netz, Port > 1023, tcp ==> NS IP, Port 23, tcp INBOUND
/usr/sbin/genfilt -v 4  -a 'P' -s '10.55.17.0' -m '255.255.128.0' -d '10.55.17.115' -M '255.255.255.255' -g 'y' -c 'tcp' -o 'gt' -p '1023' -O 'eq' -P '23' -r 'B' -w 'I' -l 'N' -f 'y' -t '0' -i 'tr0' #-D "Telnet rein 1"
#
# NS IP, Port 23, tcp ===> int. Netz, Port 1023, tcp OUTBOUND
/usr/sbin/genfilt -v 4  -a 'P' -s '10.55.17.115' -m '255.255.255.255' -d '10.55.17.0' -M '255.255.128.0' -g 'y' -c 'tcp' -o 'eq' -p '23' -O 'gt' -P '1023' -r 'B' -w 'O' -l 'N' -f 'y' -t '0' -i 'tr0' #-D "Telnet rein 2"
#
# Telnet vom DNS Server
# int. Netz, Port 23, tcp ==> NS IP, Port > 1023, tcp INBOUND
/usr/sbin/genfilt -v 4  -a 'P' -s '10.55.17.0' -m '255.255.128.0' -d '10.55.17.115' -M '255.255.255.255' -g 'y' -c 'tcp' -o 'eq' -p '23' -O 'gt' -P '1023' -r 'B' -w 'I' -l 'N' -f 'y' -t '0' -i 'tr0' #-D "Telnet raus 1"
#
# NS IP, Port > 1023, tcp ===> int. Netz, Port 23, tcp OUTBOUND
/usr/sbin/genfilt -v 4  -a 'P' -s '10.55.17.115' -m '255.255.255.255' -d '10.55.17.0' -M '255.255.128.0' -g 'y' -c 'tcp' -o 'gt' -p '1023' -O 'eq' -P '23' -r 'B' -w 'O' -l 'N' -f 'y' -t '0' -i 'tr0' #-D "Telnet raus 2"
#

[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | SMTP | Tracing | GPS ]

Copyright 2001-2014 by Orm Hager - Es gilt die GPL
Feedback bitte an: Orm Hager (orm@doc-tcpip.org )