Viren, Spyware, Datenschutz 11.259 Themen, 94.816 Beiträge

Glaubensfrage: Paket deny oder return-reset

XPectIT / 37 Antworten / Baumansicht Nickles

Diese Frage ist so alt wie das Thema Paktefilter und dennoch stelle ich sie mal (wieder).
Angesichts der vielbesprochenen Wirmen (Würmer + Viren) stelle ich mir die Frage welche Vorgehensweise besser ist.
Soll ich die Pakete verwerfen und dem Sender keine Rückmeldung geben (vermutlich die gängige Praxis gerade von DTFWs) oder fein säuberlich jeder Paket mit einem "Ich will das nicht" beantworten (wie es AFAIK dem guten Anstand des Netzwerkes entspricht).
Vorteil der 1. Weise:
Ich verbrauche keine Bandbreite um Pakete an den Sender zurück zu schicken.
Der Sender weiß nicht ob ich das Paket erhalten habe und bekommt einen Timeout.
Vorteil der 2. Weise:
Ich gehe mit der RCF konform (bitte berichtigt mich wenn ich mich irre).
Die Pakete (gerade von Tauschbörsenclients) werden meist keine 4 mal sondern nur 1 oder 2 mal geschickt.

Gruss
XPectIT

bei Antwort benachrichtigen
xafford XPectIT „Glaubensfrage: Paket deny oder return-reset“
Optionen

zu 1. so würde ich nicht unbeding tunterschreiben, daß du bandbreite sparst, kommt auf protokoll und gegenstelle an. kommt auf eine anfrage keinerlei antwort, so sehen einige protokoll erneutes senden nach gewissen timeouts vor. befürchtet man allerdings einen DoS so ist diese vorgehensweise die einzige möglichkeit wenigstens halbwegs eine chance auf restbandbreite zu haben.
im allgemeinen bin ich aber auch dafür sich so weit möglich an die konventionen zu halten und es der gegenstelle nicht schwerer als nötig machen, zumal manche konfigurationen ICMP erfordern, z.b. einige MTAs pingen den client an um sicher zu gehen, daß kein spoofing vorliegt (was nicht unbedingt sicher sein muß, aber eine von vielen techniken).

Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen
-IRON- XPectIT „Glaubensfrage: Paket deny oder return-reset“
Optionen

Zu 1) Zustimmung zu xafford.
Häufig wird durch wiederholtes Anfragen beim Ausbleiben einer Antwort der Traffic erhöht.
Zu 2) GERADE bei Tauschbörsen werden wiederholte Anfragen gestartet.

Bei der Verwaltung größerer Netze mag es durchaus sinnvoll sein, Anfragen zu verwerfen, aber für den Traffic bei einem normalen Heim-PC oder -Netzwerk ist das kontraproduktiv.

Wer Trolle toleriert, toleriert Lügen.
bei Antwort benachrichtigen
XPectIT -IRON- „Zu 1 Zustimmung zu xafford. Häufig wird durch wiederholtes Anfragen beim...“
Optionen
Zu 1) Zustimmung zu xafford.
Häufig wird durch wiederholtes Anfragen beim Ausbleiben einer Antwort der Traffic erhöht.

Der Traffic allgemein ja, aber ich bin ja Egoist. Mir gehts um meine Bandbreite, nicht um den Netztraffic allgemein. (OK, ist nicht wirklich meine Einstellung) Zum Antworten (sprich: reject) brauche ich Bandbreite, zum deny nicht.

Zu 2) GERADE bei Tauschbörsen werden wiederholte Anfragen gestartet.
OK, falsch ausgedrückt. Das weiss ich auch. Aber wenn ich die Pakete rejecte bemerken die Tauschclients schneller das unter dieser IP keiner mehr tauschen will (sofern die Clients anständig programmiert sind).
bei Antwort benachrichtigen
Tyrfing XPectIT „Zu 1 Zustimmung zu xafford. Häufig wird durch wiederholtes Anfragen beim...“
Optionen

>>OK, falsch ausgedrückt. Das weiss ich auch. Aber wenn ich die Pakete rejecte bemerken die Tauschclients schneller das unter dieser IP keiner mehr tauschen will (sofern die Clients anständig programmiert sind). Und wenn der Client (es muss nicht einmal Filesharing sein, fast alle Programme sind darauf ausgelegt, bei einem Verbindungsversuch ohne Antwort noch drei Versuche zu starten) es nicht merkt leidet darunter deine höchsteigene Bandbreite, denn drei zusätzliche Anfragen verbrauchen definitv mehr als ein Reject...ich hatte zum Beispiel mal offenbar die IP eines Emule-Servers erwischt und dann trudelten bei mir in der Minute 200 UDP-Pakete an Port 4665 ein...wenn ich bei den Paketen die ICMP-Antwort blockiert hätte, wäre damit definitv keine Bandbreite gespart worden, ganz im Gegenteil

bei Antwort benachrichtigen
xafford XPectIT „Zu 1 Zustimmung zu xafford. Häufig wird durch wiederholtes Anfragen beim...“
Optionen

zu 1, nein, nicht wirklich. du sparst am uplink, nicht am downlink. ein ICMP paket hat im allgemeinen ca. 60Byte, ein eingehendes paket das ankommt, weil keine abweisung durch ein fehlerkontrollpaket kommt kann eine wesentlich größere datenmenge enthalten. insofern sparst du zwar unter umständen die 60Byte des ICMP paketes, dafür läuft dann vielleicht durch deine leitung ein TCP paket mit einer wesentlich größeren größe, das dein rechner zwar dropped, aber es belastet trotzdem die leitung.

Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen
Tyrfing XPectIT „Glaubensfrage: Paket deny oder return-reset“
Optionen

Reject...Deny ist wirklich nur sinnvoll, wenn man zugemüllt wird und ein DOS zu befürchrten ist, wenn man auf die Pakete auch noch antworten muss.
Ansonsten hat man von Deny keine Vorteile, sondern nur Probleme und insgesamt mehr Traffic durch die fehlenden Statusmeldungen

bei Antwort benachrichtigen
Teletom XPectIT „Glaubensfrage: Paket deny oder return-reset“
Optionen

Hi,

wenn man Blockierungen vornimmt --> Paket deny
Kann aber zu weiteren "Angriffen" provozieren (da gebe ich auch Xafford recht).

ansonsten keine Blockierungen vornehmen, wenn kein entsprechender Dienst läuft.

Gruß
Teletom

bei Antwort benachrichtigen
xafford Teletom „Hi, wenn man Blockierungen vornimmt -- Paket deny Kann aber zu weiteren...“
Optionen

wo bitte habe ich irgendetwas geschrieben, daß auch nur im entferntesten davon redet, daß "angriffe" provoziert werden? von so einer aussage distanziere ich mich vollkommen.

Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen
Teletom XPectIT „Glaubensfrage: Paket deny oder return-reset“
Optionen

>zu 1. so würde ich nicht unbeding tunterschreiben, daß du bandbreite sparst, kommt auf protokoll und gegenstelle an. kommt auf eine anfrage keinerlei antwort, so sehen einige protokoll erneutes senden nach gewissen timeouts vor. befürchtet man allerdings einen DoS so ist diese vorgehensweise die einzige möglichkeit wenigstens halbwegs eine chance auf restbandbreite zu haben.
DoS ist doch ein Angriff - nicht nur entfernt, oder weisst Du nicht mehr was Du schreibst?

Du kannst Dich gerne distanzieren, damit habe ich überhaupt kein Problem, doch Inhalt bleibt Inhalt.

bei Antwort benachrichtigen
xafford Teletom „ zu 1. so würde ich nicht unbeding tunterschreiben, daß du bandbreite sparst,...“
Optionen

ich weiß schon, was ich schreibe, aber anscheinend verstehst du es nicht.

Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen
Teletom xafford „ich weiß schon, was ich schreibe, aber anscheinend verstehst du es nicht.“
Optionen

Ich hab schon verstanden.

bei Antwort benachrichtigen
-IRON- XPectIT „Glaubensfrage: Paket deny oder return-reset“
Optionen

xafford schrieb:
...befürchtet man allerdings einen DoS so ist diese vorgehensweise die einzige möglichkeit wenigstens halbwegs eine chance auf restbandbreite zu haben

Du schriebst:
Kann aber zu weiteren "Angriffen" provozieren (da gebe ich auch Xafford recht).

xafford fragte:
wo bitte habe ich irgendetwas geschrieben, daß auch nur im entferntesten davon redet, daß "angriffe" provoziert werden?

Wer weiß hier nicht mehr, was er schrieb, hm?

Wer Trolle toleriert, toleriert Lügen.
bei Antwort benachrichtigen
Rika XPectIT „Glaubensfrage: Paket deny oder return-reset“
Optionen

Ich bin für 3.) ICMP-Meldung "Zielrechner nicht erreichbar" zurücksenden. Das würde so aussehen, als wärst du nur ein Router und der dahinterliegende Rechner wäre ausgeschaltet. Dann wird er es nicht mehr probieren.

bei Antwort benachrichtigen
Tyrfing Rika „Ich bin für 3. ICMP-Meldung Zielrechner nicht erreichbar zurücksenden. Das...“
Optionen

Wenn jemand auf eine IP zugreifen will, dürfte es ihm vielleicht etwas spanisch vorkommen, wenn von der IP auf einmal ein Signal kommt, dass wenn schon dann vom letzten Router vor der Adresse kommen sollte...

bei Antwort benachrichtigen
Teletom Rika „Ich bin für 3. ICMP-Meldung Zielrechner nicht erreichbar zurücksenden. Das...“
Optionen

(Vielen Dank nochmal für die iframe-Prinzessin.)

Zum Router:
Es handelt sich doch hier um das Internet oder?
Der Router hat entweder eine feste Internet-IP oder bekommt per DHCP eine Internet-IP-Nummer zugeteilt. Der andere Netzwerkadapter des Routers hat mit Sicherheit eine IP-Nummer aus dem privaten IP-Adressebereich und kommuniziert mit den Intranet-Computern, die ebenfalls private IP-Nummern besitzen.

Vom Internet aus kann man nur auf Internet-IP-Nummern zugreifen, da es private IP-Nummern im Internet nicht gibt. Jede online befindliche Internet-Ip-Nummer kann man entweder direkt oder durch die Verkettung von Internet-Routern erreichen. Wenn die ICMP-Antwort "destination unreachable" erscheint, ist definitiv die Ip-Nummer online und "es wird dafür gesorgt" (in der Regel durch den Einsatz einer Firewall), dass die Unerreichbarkeitsfehlermeldung erscheint.

Dann kannst Du gleich ein Schild aufstellen: Hallo ich bin da, aber ich hab eine Firewall.

Ohne Vorhandensein von Routern und ohne Verwendung von Firewalls kann die "destination unreachable" Meldung erscheinen, wenn die Ziel-IP online ist und nicht zum Quellsubnet passt.

Gruß
Teletom

bei Antwort benachrichtigen
Tyrfing Teletom „ Vielen Dank nochmal für die iframe-Prinzessin. Zum Router: Es handelt sich...“
Optionen

1.) "Destination unreachable: Port unreachable" (ICMP 3, Code 3) ist die Standardantwort des IP-Stacks auf ein eigehendes UDP-Paket an einen geschlossenen Port, dafür braucht man keinen Paketfilter und noch nicht einmal irgendwas zu konfigurieren.

2.) Es gibt verschiedene Unterarten von ICMP 3, du schmeißt Code 1 (host unreachable), Code 3 (port unreachable) und Code 0 (net unreachalbe) in einen Topf ;)

bei Antwort benachrichtigen
Teletom Tyrfing „1. Destination unreachable: Port unreachable ICMP 3, Code 3 ist die...“
Optionen

Hier geht es um Router und nicht um Ports und somit schon gar nicht um Port unreachable. Hast Du irgendwas falsch verstanden?

bei Antwort benachrichtigen
Tyrfing Teletom „Hier geht es um Router und nicht um Ports und somit schon gar nicht um Port...“
Optionen

1.) Die beiden ICMP-Antworten, die normalerweise auf die Anwesenheit eines Rechners schließen lassen sind "Port Unreachable" und "Keine Antwort", deshalb habe ich den Satz Wenn die ICMP-Antwort "destination unreachable" erscheint, ist definitiv die Ip-Nummer online und "es wird dafür gesorgt" (in der Regel durch den Einsatz einer Firewall), dass die Unerreichbarkeitsfehlermeldung erscheint. so verstanden, dass du ICMP 3, Code 3 aka. "Port unreachable" meintest...vielleicht habe ich auch etwas falsch verstanden, weil du die unterscheidlichen ICMP.Typen wild durcheinander scheißt

2.) Auch Router haben Ports

bei Antwort benachrichtigen
Teletom Tyrfing „1. Die beiden ICMP-Antworten, die normalerweise auf die Anwesenheit eines...“
Optionen

Du irrst Dich leider, Router haben keine Ports, weil Router auf der Netzwerkschicht (Schicht 3) des Osi-Schichten-Modells arbeiten und da gibt es keine Ports.
Firewalls haben Ports und NAT hat Ports.

bei Antwort benachrichtigen
Tyrfing Teletom „Du irrst Dich leider, Router haben keine Ports, weil Router auf der...“
Optionen

*gähn* willst du mal wieder ein "nee-doch-nee-wohl-...."-Spielchen provozieren wie bei DCOM, "Stealth-Modus" und diversen anderen Themen?
Naja, wenn man sonst nichts zu tun hat - ich wünsche dir jedenfalls noch viel Spaß mit deinen Theorien...

bei Antwort benachrichtigen
XPectIT Tyrfing „1. Die beiden ICMP-Antworten, die normalerweise auf die Anwesenheit eines...“
Optionen

Welchen Sinn sollte es generell haben selber diverse ICMP-Pakete zu senden um zu signalisieren das man nicht da ist?
Was hat das verwerfen von Pings für einen Sinn?

Ein Ping von nickles.de zeigt zwar die IP, jedoch erhält man keine Antwort. Und wenn ich jetzt mal die untere Statistik anschaue: Na, welcher Rechner antwortet hier wohl nicht, obwohl alle davor schön sagen "hinter mir stecker er"??

HOST____________________________________LOSS__RCVD_SENT____BEST_____AVG___WORST

undercover.otfa___________________________0%____10___10____0.66____3.08____7.89
217.5.111.65______________________________0%____10___10___28.85___34.96___66.05
217.5.111.46______________________________0%____10___10___27.44___50.76__178.73
WUE-EB1.WUE.DE.net.dtag.de________________0%____10___10___28.62___30.77___36.65
F-EA1.F.DE.NET.DTAG.DE____________________0%____10___10___30.58___34.81___39.59
ffm-s1-rou-1077.DE.eurorings.net__________0%____10___10___31.71___35.73___40.17
ffm-s1-rou-1001.DE.eurorings.net__________0%____10___10___45.91___48.02___50.28
nbg-s1-rou-1071.DE.eurorings.net__________0%____10___10___33.91___35.85___40.05
ge-3-0.c12008GSR-1.dhk-nbg.CORE.i-p-x.DE____0%____10___10___37.91___39.93___45.89
???_____________________________________100%_____0___10____0.00____0.00____0.00


Mir gehts nicht um verstecken oder nicht gefunden werden. Sondern die bessere Methode zu finden und ich werde beim verneinen bleiben und nicht stumm die Anfragen schlucken.

Gruss
bei Antwort benachrichtigen
Teletom XPectIT „Welchen Sinn sollte es generell haben selber diverse ICMP-Pakete zu senden um zu...“
Optionen

Bei ICMP: timeout entstehen lassen.

Bei Ports: nur Dienste port-blockieren, wenn das unbedingt nötig ist, z.B. wenn man weiß, dass RPC unsicher ist, RPC-Ports (135, 445,...) blockieren, dann wird an der Stelle festgestellt, dass eine Firewall vorhanden ist, das ist aber immer noch besser, als wenn der unsichere Port offen ist. Bei sicheren Diensten keine Blockierungen vornehmen, dann kann der Dienst ganz normal antworten. Wenn kein Dienst auf einem Port läuft (natürlich den Port auch nicht blockieren), dann wird festgestellt, dass kein Dienst vorhanden ist.

Gruß
Teletom

bei Antwort benachrichtigen
Tyrfing Teletom „Bei ICMP: timeout entstehen lassen. Bei Ports: nur Dienste port-blockieren, wenn...“
Optionen

Tom, tu der Menschheit einen Gefallen: Beschäftige dich mit den Konzepten Reject und Deny und poste erst dann. Dann würde dir selber auffallen, was für einen Mist du gerade geschrieben hast.
Übrigens: Wenn ein Router einfach nur als "Weiterleitung" fugiert, sind die Ports am Router unwichtig, trotzdem verwenden auch Router Ports, z.B. 179 (BGP)

bei Antwort benachrichtigen
xafford Tyrfing „Tom, tu der Menschheit einen Gefallen: Beschäftige dich mit den Konzepten...“
Optionen

zwar findet reines routing wirklich auf schicht 3 statt und kennt per definition keine ports, es ist aber unsinnig einen physikalischen router nur darauf zu beschränken. jeder ernstzunehmende router ist managed und bietet möglichkeiten zur filterung, zum portforwarding, port redirection, QoS, NAT, firewalling etc, insofern ist eine diskussion darüber wohl eher müßig.

Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen
XPectIT Nachtrag zu: „Glaubensfrage: Paket deny oder return-reset“
Optionen

Nochmal etwas genauer, da hier viele wohl denken das ich einen Rechner mit/ohne DTFW habe, hier meine grobe Konstllation.
Ich habe eine Linux Firewall und die hat, wie so jeder andere Rechner der am Internet hängt hängt Ports. Die Firewall betreibt NAT und ich kann mit meinem LAN dahinter ins Netz - alles klar, soweit?
Gut, mir geht es um die Firewall (das sich der Rechner dahinter ohne port-forwarding nicht um die Ports kümmern muss ist mir geläufig). Soll die Firewall sämtliche Pakete die an sie gerichtet sind verwerfen oder rejecten? Die Firewall bietet keinerlei Dienste (weder nach innen noch nach außen) an und das LAN dahinter soll auch nicht erreicht werden.
Die Rede ist hier von sämtlichen Paketen (ICMP, UDP, TCP, ...) oder sind für die verschiedenen Protokolle verschiedene Stratigieen sinnvoll? Die Firewall hat ja eine default-Regel, die zum Zuge kommt wenn keine andere trifft.
default-to-deny
oder
default-to-reject

Die ersten Paar Antworten haben mir aber deutlich weiter geholfen als Diskussionen über Ports, IP-Adressbereiche vor und hinter Routern, ICMP Typen, ...
Danke für einen wiedermal unterhaltsamen Thread. ;-)

bei Antwort benachrichtigen
Tyrfing XPectIT „Nochmal etwas genauer, da hier viele wohl denken das ich einen Rechner mit/ohne...“
Optionen

>>...das LAN dahinter soll auch nicht erreicht werden. Das hat aber eher mit eingehenden Paketen zu tun, die vom Router geblockt werden bzw. vom Router verworfen werden, weil er damit nichts anfangen kann.
Die Konzepte reject und deny beschäftigen sich ja damit, was passiert, nachdem ein Paket auf die eine oder andere Art und Weise nicht durchgekommen ist. Und da deny außer in Ausnahmensituationen (siehe Xaffs erstes posting) keine Vorteile bringt und im Normalfall sogar deinen Traffic erhöht, würde ich für ankommende Pakete aller Protokolle reject empfehlen...die Standards sind eben doch sinnvoll

bei Antwort benachrichtigen
XPectIT Tyrfing „ ...das LAN dahinter soll auch nicht erreicht werden. Das hat aber eher mit...“
Optionen
Das hat aber eher mit eingehenden Paketen zu tun, die vom Router geblockt werden bzw. vom Router verworfen werden, weil er damit nichts anfangen kann.
Genau um diese Pakete gehts mir ja. Da der Router keine Dienste anbietet und keine Daten aus dem Internet für sich anfordert (sondern nur für das LAN dahinter) und keine Ports offen hält um sie weiterzuleiten, sind das ja Pakete mit denen der Router nichts anfangen kann. - Oder hab ich einen Denkfehler?

OK, ich stelle fest das ich es schon richtig mache.
bei Antwort benachrichtigen
xafford XPectIT „Das hat aber eher mit eingehenden Paketen zu tun, die vom Router geblockt werden...“
Optionen

ich weiß nicht, ob du da einen denkfehle rhast, eventuell übersiehst du nur was:
der router bietet so oder so keine verbindung an, aber wie soll die gegenstelle dies bei einem drop erfahren? sie erfährt es erst, wenn das zeitlimit für die verbindung erreicht ist auf indirektem wege.

Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen
xafford XPectIT „Nochmal etwas genauer, da hier viele wohl denken das ich einen Rechner mit/ohne...“
Optionen

ich denke die frage muß man auch im zusammenhang mit dem betreffenden netz sehen. das internet verschmerzt es bestimmt, wenn jemand bei seinem heimlan alle pakete mit DROP stillschweigend verwirft, so lange er selbst dadurch keine kommunikationsprobleme bekommt, siehe MTAs, aktves FTP, etc.
anders sehe ich das allerdings bei routern im internet. ich kenne kaum provider, deren router z.b. icmp droppen, da es tödlich für eine fehlerdiagnose ist, bzw diese immens erschwert. wobei ich mich hier jetzt allerdings auf ICMP beziehe, da tcp und udp bei diesen routern irrelevant ist, denn bei NAT sieht das ganze ja auch noch einmal etwas anders aus. deiner router ist ja der stellvertreter für deine maskierten lan-rechner, hier kann es schon sinnvoll sein, wenn der router für sie die abweisung gewisser pakete bestätigt, bzw der außenwelt klar ist, daß hier kein diest zu erreichen ist. mal ein kleines konstruiertes beispiel:
ein user hatte kontakt mit einem webserver, geht dann offline, ohne daß der socket getrennt wurde, ein anderer kommt mit der selben IP online und der server sendet weiter. lehnt der rechner oder router des neuen users die verbindung standardkonform ab, dann wird die verbindung sauber beendet, der server spart ressourcen. antwortet er überhaupt nicht, so dauert die zurücksetzung des sockets länger und es fließen mehr datenpakete durch das netz.
im einzelfall kein problem, multipliziert man das aber, so trägt es um "hintergrundrauschen" im netz bei.
ergo meine vorgehensweise wäre ein höflicher reject, da dein router selbst ohnehin nichts zur verfügung stellt, die ablehnenden pakete meist kompakter als weitere irrläufer sind und die rechner hintendran ziemlich unerheblich sind (außer es kommt jemand mit nmap) ;o)

Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen
Teletom XPectIT „Glaubensfrage: Paket deny oder return-reset“
Optionen

Hi,

wenn ein externer Router/Firewall (sorry, konnte ich Deinem Thread nicht eindeutig entnehmen) vorhanden ist, ist empfehlenswert die Grundeinstellung reject vorzunehmen, mit der Ausnahme, dass der ICMP-Typ timeout entstehen lässt. Reject bedeutet der Sender bekommt eine Antwort und es wird somit der traffic nicht unnötig erhöht.

Mit Sicherheit weiß dann jedoch der Sender zumindest bei TCP und UDP, dass eine Firewall verwendet wird. Ist aber nicht so schlimm, ein eventuell folgender Angriff würde der externen Firewall gelten und nicht Deinen internen Computern.

Folgeangriffe sind mit Sicherheit selten, somit ist die bessere Performance aufgrund der Trafficverbesserung eine vorrangige Lösung. Denn eine bessere Performance dient der Systemausfallsicherung und eine Systemausfallsicherung kommt vor der Datenschutzsicherung.

Gruß
Teletom
PS: Übrigens wäre die Lösung, die Firewallsoftware auf dem externen Computer zu deaktivieren und ihn somit nur als Router mit NAT/Mascerading einzusetzen, eine überlegenswerte Alternative.

bei Antwort benachrichtigen
XPectIT Teletom „Hi, wenn ein externer Router/Firewall sorry, konnte ich Deinem Thread nicht...“
Optionen

Wahnsinn, Teletom und Tyrfing einer Meinung. ;-)

Systemausfallsicherung kommt vor der Datenschutzsicherung
Wobei das auf das Anwendungsgebiet ankommt, wenn Zahlungsdaten im Spiel sind bin ich der Meinung das ich die Daten lieber schütze anstatt zu versuchen die Erreichbarkeit zu garantieren.

bei Antwort benachrichtigen
Teletom XPectIT „Wahnsinn, Teletom und Tyrfing einer Meinung. - Systemausfallsicherung kommt vor...“
Optionen

Systemausfallsicherheit heißt, das System soll ohne Störungen arbeiten können. Wenn Deine Zahlungsdaten zerstört sind, weil das System ausgefallen ist, brauchst Du auch keinen Datenschutz mehr.

Gruß
Teletom

bei Antwort benachrichtigen
XPectIT Teletom „Systemausfallsicherheit heißt, das System soll ohne Störungen arbeiten...“
Optionen

OK, bei mir zählte die Zerstörung von Daten (besser die Verhinderung) in den Bereich Datensicherheit. Wenn ein System ausfällt sind noch lange keine Daten zerstört.

bei Antwort benachrichtigen
Teletom XPectIT „OK, bei mir zählte die Zerstörung von Daten besser die Verhinderung in den...“
Optionen

Bitte nicht Datenschutz mit Datensicherung verwechseln.

bei Antwort benachrichtigen
Tyrfing XPectIT „Wahnsinn, Teletom und Tyrfing einer Meinung. - Systemausfallsicherung kommt vor...“
Optionen

Nicht ganz...ICMP sollte man meiner Meinung nach auch durchlassen, weil es für diverse Statusmeldungen (z.B. das "kann ich nix mit anfangen" als Antwort auf UDP-Pakete) erforderlich ist

bei Antwort benachrichtigen
Teletom XPectIT „Glaubensfrage: Paket deny oder return-reset“
Optionen

Hi,

freut mich, dass überwiegend für reject gestimmt wird.

eine kleine Router-Geschichte:

ein reiner Router arbeitet tatsächlich in der Netzwerkschicht (3. Schicht des Osi-Schichten systems) natürlich ohne Ports, d.h.

es wird die Computerkennung und die Netzwerkkennung genommen und versucht das Ziel zu erreichen, auch wenn es nicht im entsprechenden Netzwerk sich befindet.

TCP/IP Computerkennung = IP-Nummer Netzwerkkennung = Subnetmask (egal ob im Paket TCP, UDP oder ICMP sich befindet).
IPX/SPX Computerkennung = Note-Adresse Netzwerkkennung = Netzwerknummer

Reine Router kann man beispielweise leicht mit Hilfe von Windows NT4.0 und Windows 95 einrichten, man braucht nur das IP-Forwarding zu aktivieren (Achtung! Nicht verwechseln mit dem Port-Forwarding). Bei diesen Systemen gab es noch kein NAT/Mascerading. Deshalb ist mit Hilfe des internen NT4.0-Routers noch kein Internet/privates Netzwerk-Routing möglich (da NAT fehlt).

Sehr viele Router ohne NAT werden im Internet eingesetzt, damit letztenendes jede Internet-Ip-Nummer erreichbar ist. In erster Linie wird zwischen den Netzwerken der einzelnen Provider geroutet.

Gruß
Teletom

bei Antwort benachrichtigen
Teletom XPectIT „Glaubensfrage: Paket deny oder return-reset“
Optionen

Hi,


ja ja, bei ICMP scheiden sich wieder die Geister:

Genaugenommen sollte man ICMP wie folgt einstellen:

# 8 Echo Request eingehend nicht zulassen
# 13 Timestamprequest eingehend nicht zulassen
# 17 Mask Request eingehend nicht zulassen RFC 950
# Routeranforderung eingehend nicht zulassen RFC 1256
# 3 Destination unreachable ausgehend nicht zulassen
# 4 Source Quench ausgehend nicht zulassen
# 12 Parameter Problem ausgehend nicht zulassen
# 11 Zeitüberschreitung ausgehend nicht zulassen
# 5 Redirect (Umleiten) nicht zulassen
Alle anderen ICMP-Typen zulassen, dann werden notwendige ICMP-Funktionen nicht unterdrückt.

Gruß
Teletom

bei Antwort benachrichtigen