| orm@doc-tcpip.org | Erstellt: November 2001 - Letzte Modifikation: November 2003 |
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.
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.
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:
Der Caching NS ist vor Angriffen und Ausnutzung geschützt (Cache Poisioning). Generell ist der Caching NS empfindlicher gegen Angriffen wie Buffer Overflow etc.
Der Verkehr über die Firewall läuft nur über den internen NS.
Das Caching vergrößert den Resourcen-Verbrauch des Servers. Der externe Nameserver ohne Caching hat einen nur von der Zahl der Anfragen abhängige Last - die authoritären Daten bleiben konstant.
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.
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; };
};
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; };
};
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.
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; };
};
# 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" #
[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]
Copyright 2001-2021 by Orm Hager - Es gilt die GPL