firewall-regeln für dhcpd

Lieber Besucher, herzlich willkommen bei: Linux Forum Linux-Web.de. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

linuxerr

Prof. Dr. Schlaumeier

Beiträge: 8 557

Wohnort: Mecklenburg, zur Entwicklungshilfe in Chemnitz/Sachsen ;-)

23.01.2006, 14:51

firewall-regeln für dhcpd

hallo,
ich habe eine frage zu firewallregeln mit iptables.
auf dem server läuft dhcpd auf eth0 (ip=192.168.0.1). die firewallregeln habe ich so eingestellt:

Quellcode

# dhcp auf eth0 freigeben
# anforderung reinlassen
iptables -A INPUT -i eth0 -s 0.0.0.0 -d 255.255.255.255 -p udp --dport 67 -j ACCEPT
# antwort ausgeben
iptables -A OUTPUT -o eth0 -s 192.168.0.1 -d 255.255.255.255 -p udp --dport 68 -j ACCEPT
# bestaetigung reinlassen
iptables -A INPUT -i eth0 -s 192.168.0.1 -d 255.255.255.255 -p udp --dport 68 -j ACCEPT

frage:
ist das eurer meinung nach korrekt so oder sollte ich etwas ändern?
wann wird auf port 67/68 tcp gefahren ? etwa bei größeren datenmengen? aber wann ist das der fall? muss ich das sicherheitshalber mit freigeben?

Die Rechtschreibfehler in diesem Beitrag sind nicht urheberrechtlich geschützt.
Jeder der einen findet darf ihn behalten und in eigenen Werken weiterverwenden.

Zum Seitenanfang

linuxerr

Prof. Dr. Schlaumeier

Beiträge: 8 557

Wohnort: Mecklenburg, zur Entwicklungshilfe in Chemnitz/Sachsen ;-)

28.01.2006, 15:15

RE: firewall-regeln für dhcpd

also ich habe bis jetzt immer noch keine informationen gefunden, wozu dhcp auf tcp-ports freigegeben werden soll. alle maschinen die ich ausprobiert habe nutzen udp. selbst bei diskless werden die daten komplett über udp übertragen und dann kommt tftp zum einsatz. also lass ich die firewallregeln erst einmal so.

Die Rechtschreibfehler in diesem Beitrag sind nicht urheberrechtlich geschützt.
Jeder der einen findet darf ihn behalten und in eigenen Werken weiterverwenden.

Zum Seitenanfang

epikur

... only human being

Beiträge: 589

28.01.2006, 20:26

hi linuxerr,

zu deinen ehren hab ich mich hinreissen lassen mal ne rfc zu lesen [in rfc2131] - wollte das jetzt auch wissen.
wenn ich das richtig verstanden habe gibt es netzwerkhardware [aber wohl eher selten] die die udp packeges nicht beantworten kann ...

Zitat

kleiner Auszug aus der 2131:

.............. Unfortunately, some
client implementations are unable to receive such unicast IP
datagrams until the implementation has been configured with a valid
IP address (leading to a deadlock in which the client's IP address
cannot be delivered until the client has been configured with an IP
address).

A client that cannot receive unicast IP datagrams until its protocol
software has been configured with an IP address SHOULD set the
BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or
DHCPREQUEST messages that client sends. The BROADCAST bit will
provide a hint to the DHCP server and BOOTP relay agent to broadcast
any messages to the client on the client's subnet. A client that can
receive unicast IP datagrams before its protocol software has been
configured SHOULD clear the BROADCAST bit to 0. The BOOTP .....

... in den rfc's wird sowas von um den heissen brei dokumentiert, dass erst nach dem 3. oder 4. Verweis auf ff-rfc's ein hinweis zu lesen ist, dass in diesem fall die protokelle frei gemaess [nochnerfc] behandelt werden ..... aber was die protokollschichten dann fuer schweinereien miteinander machen will ich gar nicht wissen - sonst fang ich noch an mit meinen rechnern zu reden :crazy:

gruß epikur

wie soll ich wissen, was ich denke?
... bevor ich hoere, was ich sage
... bevor ich lese, was ich schreibe

Zum Seitenanfang

linuxerr

Prof. Dr. Schlaumeier

Beiträge: 8 557

Wohnort: Mecklenburg, zur Entwicklungshilfe in Chemnitz/Sachsen ;-)

28.01.2006, 21:26

@epikur

vielen dank für deine antwort. es ist wirklich so, dass eben überall die abwicklung des dhcp protokolls nur über udp beschrieben wird. bei den geringen informationen ist das ja auch zu verstehen. wenn nichts ankommt, kann ja noch mal nachgefragt werden.
mich hatte eben nur stutzig gamacht, dass die tcp-ports in der services ebenfalls für dhcp reserviert wurden.
naja und in den rcf's (2132) in die ich reingeschaut habe stand zur nutzung von tcp unter dhcp auch nichts drin (jedenfalls nicht für mich erkennbar?)
ist die tcp eintragung in /etc/services nur ein joke

Die Rechtschreibfehler in diesem Beitrag sind nicht urheberrechtlich geschützt.
Jeder der einen findet darf ihn behalten und in eigenen Werken weiterverwenden.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »linuxerr« (28.01.2006, 21:37)

Zum Seitenanfang

bonsai

Prof.Dr. Klugschiss

Beiträge: 1 486

Wohnort: N.de

Beruf: Informatiker

29.01.2006, 01:42

Aeh...DHCP via UDP

?????

linuxerr: Das musste mir mal erklaeren, ein Rechner, der keine IP-Adresse hat, soll via UDP/IP eine IP-Adresse bekommen?

Musste aufpassen - das erste Paket geht nicht als IP-Paket ....somit auch ohne dport etc. auf den Weg. Da musst Du irgendeinen Service abfragen....

...halbwissen - werde aber demnaechst aehnliches tun - dann kann ich Dir mehr sagen.

Die erste programmgesteuerte Rechenmaschine (Z1) wurde Mitte der 30er Jahre als "nicht patentwürdig" eingestuft. Warum versaut mir das Ding 50 Jahre später immer noch den Tag?

Zum Seitenanfang

linuxerr

Prof. Dr. Schlaumeier

Beiträge: 8 557

Wohnort: Mecklenburg, zur Entwicklungshilfe in Chemnitz/Sachsen ;-)

29.01.2006, 08:57

RE: Aeh...DHCP via UDP

da der client weder netzwerkadresse noch netzmaske kennt, sendet er mit der absenderip 0.0.0.0 einen broadcastruf an die 255.255.255.255 mit diesem paket sendet der client seine macadresse und eine zufallszahl mit. der dhcpserver horcht auf der brodcast und gibt als bestätigung eine meldung mit der ip, der mac des rufenden clienten und der zufallszahl zurück. damit kann der rufende client erkennen, welches antwortpaket zu ihm gehört.
ein solches protokoll ist doch für udp prädestiniert. deshalb verstehe ich nicht, was man da mit tcp wil???

Die Rechtschreibfehler in diesem Beitrag sind nicht urheberrechtlich geschützt.
Jeder der einen findet darf ihn behalten und in eigenen Werken weiterverwenden.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »linuxerr« (29.01.2006, 08:58)

Zum Seitenanfang

bonsai

Prof.Dr. Klugschiss

Beiträge: 1 486

Wohnort: N.de

Beruf: Informatiker

29.01.2006, 19:25

ah ....

...stimmt so war das....

Sorry.

Aeh ob UDP // TCP hatte ich ja nicht gefragt.... ich fragte ob überhaupt IP. Die Frage ist aber beantwortet. Sorry, wegen der Stoerung.

Die erste programmgesteuerte Rechenmaschine (Z1) wurde Mitte der 30er Jahre als "nicht patentwürdig" eingestuft. Warum versaut mir das Ding 50 Jahre später immer noch den Tag?

Zum Seitenanfang

linuxerr

Prof. Dr. Schlaumeier

Beiträge: 8 557

Wohnort: Mecklenburg, zur Entwicklungshilfe in Chemnitz/Sachsen ;-)

29.01.2006, 19:50

RE: ah ....

na ja das problem ist ja momentan auch nicht lebensbedrohend für das system. für mich bleibt eben nur ein fader nachgeschmack, weil ich auch in keiner documentation (ausser in /etc/services) einen hinweis auf tcp gelesen habe. mir ist eben auch nicht klar, warum man ein handshaking-protokoll verwenden sollte, wenn die maschinen noch "fast" nichts voneinander wissen und auf broadcastrufe alle möglichen server sinnlos in die gegend brüllen sollen und dann vielleicht noch mehrmals, weil der client es sich anders überlegt hat. bei mehreren dhcp-servern würde ja auch nur einer (bei tcp) dann die bestätigung erhalten und alle anderen würden weiter rufen oder sinnlos warten.
vielleicht wurden ja die tcp-ports nach der devise "erst mal ham" reserviert????
ich hab mir erst mal eine regel definiert, die tcp-rufe auf den ports loggt. mal sehen ob was passiert.
weiterfahren und beobachten

Die Rechtschreibfehler in diesem Beitrag sind nicht urheberrechtlich geschützt.
Jeder der einen findet darf ihn behalten und in eigenen Werken weiterverwenden.

Zum Seitenanfang

bonsai

Prof.Dr. Klugschiss

Beiträge: 1 486

Wohnort: N.de

Beruf: Informatiker

30.01.2006, 09:52

Mh...

...dann ist dhcp wie dns?

(DNS ist UDP UND TCP)

Solange es geht - wuerde ich TCP NICHT zulassen.

Die erste programmgesteuerte Rechenmaschine (Z1) wurde Mitte der 30er Jahre als "nicht patentwürdig" eingestuft. Warum versaut mir das Ding 50 Jahre später immer noch den Tag?

Zum Seitenanfang