Frage zu DROP / REJECT
Benjamin Scharbau
Ich habe mich in der letzten Zeit ein wenig mit iptables und
möglichst sinnvoller Konfiguration eines Paketfilters ausein-
andergesetzt. Dabei wird in den FAQs dieser Group öfters
erwähnt, dass man lieber REJECTen als DROPpen sollten (Gründe
dafür kann ich nachvollziehen). Wenn ich hingegen andere Quellen
betrachte (z.B. iptables-HOWTO, Linux - Wegweiser für Netzwerker)
ist dort oft REJECT gar nicht, oder nur am Rande erwähnt, hier
ist dann häufig die Rede von DROPpen als blocken.
Was ich mich dabei frage: Warum diese unterschiedliche Sichtweise?
Ist es so, dass sich die Erkenntnis, dass REJECT sinnvoller ist als
DROP erst herausgestellt hat, nachdem die von mir genannten Quellen
geschrieben worden, bzw. habe ich veraltete Quellen gelesen, oder
gibt es in diesem Punkt verschiedene Sichtweisen von verschiedenen
Personen(kreisen)? Vielleicht habe ich auch bisher etwas Grund-
legendes missverstanden, weshalb diese Frage auf einem Miss-
verständnis beruht, ist dem so?
Gruß
Benjamin
--
Brain 1.0 sollte ja kein Problem sein. Dick 2.0
sollte aber nicht mit Brain 1.0 kombiniert
angewendet werden.
(Aus: de.org.ccc)
Andreas Kretschmer
> erwähnt, dass man lieber REJECTen als DROPpen sollten (Gründe
> dafür kann ich nachvollziehen). Wenn ich hingegen andere Quellen
> betrachte (z.B. iptables-HOWTO, Linux - Wegweiser für Netzwerker)
> ist dort oft REJECT gar nicht, oder nur am Rande erwähnt, hier
> ist dann häufig die Rede von DROPpen als blocken.
Möglicherweise bist Du durch die Policy-Regeln irritiert, diese lassen
nur ein DROP zu.
> Personen(kreisen)? Vielleicht habe ich auch bisher etwas Grund-
> legendes missverstanden, weshalb diese Frage auf einem Miss-
> verständnis beruht, ist dem so?
Ich ziehe z.B. auch ein REJECT vor, allerdings habe ich einige
ISDN-Systeme am laufen, die nach Zeittakt berechnet werden. Leider habe
ich dafür keine Lösung gefunden, die sauber auflegt trotz REJECT. Ich
nutze dort einen Patch, der mich allerdings zum DROP zwingt.
(bei der ganzen 135 und 445 - Klingelputzerei, die auf UNSERER Seite
horrende Kosten verursacht, bleibt nix anderes)
Ansonsten gibt es immer mal wieder Diskussion darum, ob man hirntot
programmierten Tausch-Diensten, die auf REJECT nicht reagieren, mittels
DROP bremsen sollte.
Also, wenn man davon ausgeht, daß man nicht mit Komplett-Idioten
kommuniziert und ansonsten keine Gründe wie bei mir mit ISDN sind,
sollte man ein höfliches REJECT einem asozialem DROP vorziehen, meine
Meinung.
end
Andreas
--
Diese Message wurde erstellt mit freundlicher Unterstützung eines freilau-
fenden Pinguins aus artgerechter Freilandhaltung. Er ist garantiert frei
von Micro$oft'schen Viren. (#97922 http://counter.li.org) GPG 7F4584DA
Was, Sie wissen nicht, wo Kaufbach ist? Hier: N 51.05082°, E 13.56889° ;-)
Benjamin Scharbau
> begin Benjamin Scharbau <XCS_A...@gmx.de> wrote:
>> erwähnt, dass man lieber REJECTen als DROPpen sollten (Gründe
>> dafür kann ich nachvollziehen). Wenn ich hingegen andere Quellen
>> betrachte (z.B. iptables-HOWTO, Linux - Wegweiser für Netzwerker)
>> ist dort oft REJECT gar nicht, oder nur am Rande erwähnt, hier
>> ist dann häufig die Rede von DROPpen als blocken.
>
> Möglicherweise bist Du durch die Policy-Regeln irritiert, diese lassen
> nur ein DROP zu.
Nein, das war mir eigentlich schon klar. Hab ich zu erwähnen vergessen.
Es ist vielmehr so, das der Linux Wegweiser für Netwerker (O'Reilly
Verlag, 2. Auflage) REJECT mit keinem Woret erwähnt, das gleiche gilt
auch für den Linux Network Administrators Guide auf http://www.tldp.org,
wie ich mich gerade noch mal vergewissert habe. Auch im iptables-HOWTO
(gefunden unter:
http://www.netfilter.org/unreliable-guides/packet-filtering-HOWTO/packet-filtering-HOWTO.linuxdoc-7.html)
wird die Möglichkeit des REJECTS nur in einem kurzen Abschnitt erwähnt.
Ersteres verwendet im mitgelieferten Beispiel auch ausschlisslich DROP,
um ungewünschte Pakete zu filtern. Dies ist der Punkt, der mich irritiert.
Zu den Policies: Wie ich das verstanden habe wird die Policy dann heran-
gezogen, wenn keine Regel matcht. D.h. mit einer Regel wie
iptables -A FORWARD -j REJECT sollte diese doch in jedem Fall matchen
und die Policy damit nicht mehr zum Einsatz kommen, oder? (Mir ist
klar, dass die Policy trotzdem eher auf DROP als auf ACCEPT stehen
sollte).
>> Personen(kreisen)? Vielleicht habe ich auch bisher etwas Grund-
>> legendes missverstanden, weshalb diese Frage auf einem Miss-
>> verständnis beruht, ist dem so?
>
[...]
>
> Ansonsten gibt es immer mal wieder Diskussion darum, ob man hirntot
> programmierten Tausch-Diensten, die auf REJECT nicht reagieren, mittels
> DROP bremsen sollte.
Trifft diese hirntote Programmierung generell auf alle Tauschdienste zu,
oder gibt es da auch welche, die auf REJECT reagieren?
> Also, wenn man davon ausgeht, daß man nicht mit Komplett-Idioten
> kommuniziert und ansonsten keine Gründe wie bei mir mit ISDN sind,
> sollte man ein höfliches REJECT einem asozialem DROP vorziehen, meine
> Meinung.
k, hab ich bisher auch immer so rausgelesen.
Zwei weitere Fragen haben sich da jetzt noch bei mir aufgeworfen:
1. Wenn ich REJECTen will, muss ich das extra in den Kernel kompi-
lieren (auf Linux 2.4.16 zumindest), DROP geht auch so. Wieso wird
REJECT da nicht auch gleich miteinkompiliert? Gab es anfänglich nur
DROP, und REJECT ist dann später dazugekommen, oder at sich der Nutzen
von REJECT erst später gezeigt?
2. In unserem Subnetz (Uni) wird am Paketfilter des Hauses alles nicht
erwünschte geDROPt. Als ich den (ehemals) zuständigen nach den Gründen
fragte, wieso DROP anstatt von REJECT bekam ich die Antwort, dass so
flooding-Attacken verhindert werden sollen. Kann dies bei REJECTS denn
auftreten? Sollte da nicht der Kernel entsprechende Schutzmaßnahmen
treffen, um das zu vermeiden, oder hat REJECT hier tatsächlich
Probleme mit?
Thomas Hertel
>
>2. In unserem Subnetz (Uni) wird am Paketfilter des Hauses alles nicht
>erwünschte geDROPt. Als ich den (ehemals) zuständigen nach den Gründen
>fragte, wieso DROP anstatt von REJECT bekam ich die Antwort, dass so
>flooding-Attacken verhindert werden sollen. Kann dies bei REJECTS denn
>auftreten? Sollte da nicht der Kernel entsprechende Schutzmaßnahmen
>treffen, um das zu vermeiden, oder hat REJECT hier tatsächlich
>Probleme mit?
Egal ob Reject oder Drop, der Paketfilter/Router muss sich anschauen,
was er da bekommt. IMO ist die Zeit, die er für die Antwort (Reject)
benötigt, vernachlässigbar gegen die Analyse des eingehenden Pakets.
Insofern kann ich mir nicht vorstellen, wie Drop gegen flooding helfen
sollte.
Gruß
Thomas
--
"The opinions expressed herein are subject to change without notice"
Aus dem Copyright-Vermerk einer Studie der Gartner Group
Email für Non-Spam: Meine_Initialen_bei_arcendo_punkt_com
Andreas Frackowiak
> ist dort oft REJECT gar nicht, oder nur am Rande erwähnt, hier
> ist dann häufig die Rede von DROPpen als blocken.
>
> Was ich mich dabei frage: Warum diese unterschiedliche Sichtweise?
> Ist es so, dass sich die Erkenntnis, dass REJECT sinnvoller ist als
> DROP erst herausgestellt hat, nachdem die von mir genannten Quellen
> geschrieben worden, bzw. habe ich veraltete Quellen gelesen, oder
> gibt es in diesem Punkt verschiedene Sichtweisen von verschiedenen
> Personen(kreisen)?
Das "klassische" RFC-konforme Verhalten eines TCP/IP
Geraetes bestand darin, bei nichtzustellbaren IP-Paketen
den Absender davon zu informieren.
Als packet-filter in Mode kamen hatten diese oft auch
eine Moeglichkeit, die Pakete ohne ICMP-Rueckpaket an
den Absender zu entsorgen.
"security by obscurity" ist zwar selten eine gute Idee,
dennoch steht hinter diesem "stillem entsorgen" das Konzept
dass der Firewall keine Informationen ueber sich selbst
an Unbefugte herauszugeben hat, und er von einem poten-
tiellem Angreifer auch nicht zum Senden von Paketen an
eine beliebige IP-Adresse (die Absender-IP kann ja falsch
sein) missbraucht werden kann.
Vor Jahren gab es allerdings darueber bereits hitzige
theoretische fast-religiose Diskussionen, die solche
Firewalls (die den Absender nicht per ICMP ueber
gedroppte Pakete informieren) als "nicht RFC-konform"
"boese" "unfreundlich" "falsch konfiguriert" etc.
beschimpften.... weshalb ich mich wundern wuerde,
wenn es heutzutage zu dem Thema nur eine Meinung
geben wuerde.
Gruesse
Andreas
--
extra interrete nulla vita, et si ulla, non est ita.
Jean Wolter
> Ich ziehe z.B. auch ein REJECT vor, allerdings habe ich einige
> ISDN-Systeme am laufen, die nach Zeittakt berechnet werden. Leider habe
> ich dafür keine Lösung gefunden, die sauber auflegt trotz REJECT. Ich
> nutze dort einen Patch, der mich allerdings zum DROP zwingt.
> (bei der ganzen 135 und 445 - Klingelputzerei, die auf UNSERER Seite
> horrende Kosten verursacht, bleibt nix anderes)
(ich nehmen einfach mal an, es geht um isdn und linux ...) Der active
filter Support der aktuellen Kerne loest das Problem mit dem Auflegen
nicht? Ich kenne zumindest einen, der ein 2.4.22 verwendet und bei dem
ISDN trotz staendigem Klinkenputzen zuverlaessig auflegt.
MfG,
Jean
Juergen Ilse
Benjamin Scharbau <XCS_A...@gmx.de> wrote:
> Ich habe mich in der letzten Zeit ein wenig mit iptables und
> möglichst sinnvoller Konfiguration eines Paketfilters ausein-
> andergesetzt. Dabei wird in den FAQs dieser Group öfters
> erwähnt, dass man lieber REJECTen als DROPpen sollten (Gründe
> dafür kann ich nachvollziehen). Wenn ich hingegen andere Quellen
> betrachte (z.B. iptables-HOWTO, Linux - Wegweiser für Netzwerker)
> ist dort oft REJECT gar nicht, oder nur am Rande erwähnt, hier
> ist dann häufig die Rede von DROPpen als blocken.
Sieh es doch einfach mal so: Wenn dich jemand am Bahnhof anhaut mit
"Haste mal 'nen Euro?" hast du prinzippiell 2 Moeglichkeiten:
Du antwortest dieser Person "Nein, habe ich nicht" oder du versuchst
so zu tun, als haettest du seine Frage nicht bemerkt. In ersterem Fall
wird er (evt. auch begleitet von nicht immer freundlichen Bemerkungen
dir gegenueber) aufgeben und sich dem naechsten zuwenden. In letzerem
Fall wird er aber evt. versuchen, mit seienr Frage doch noch von dir
bemerkt zu werden: er wird seine Frage mehrfach wiederholen und dich
hartnaeckiger belaestigen (verstaendlicherweise, denn er weiss ja nicht,
dass du ihn *bewusst* zu ignorieren versuchst).
Welche Variante ist nun (sogar fuer beide Seiten) schneller, unproble-
matischer stressfreier und daher empfehlenswerter: Variante 1 (klar
sagen "bei mir gibt es nichts") oder Variante 2 (versuchen, den anderen
zu ignorieren)? Variante 1 ist ein "Reject", Variante2 ein "Drop".
> Was ich mich dabei frage: Warum diese unterschiedliche Sichtweise?
> Ist es so, dass sich die Erkenntnis, dass REJECT sinnvoller ist als
> DROP erst herausgestellt hat, nachdem die von mir genannten Quellen
> geschrieben worden, bzw. habe ich veraltete Quellen gelesen, oder
> gibt es in diesem Punkt verschiedene Sichtweisen von verschiedenen
> Personen(kreisen)?
Es gibt Leute, die glauben, sich mit "Drop" (obenstehende Variante 2)
"verstecken" zu koennen, so dass ein potentieller Angreifer sie im Netz
nicht entdecken kann. Bei genauer Betrachtung hat das etwas von einem
kleinen Kind, dass sich die augen zuhaelt und dann der Ueberzeugung ist
"wenn du mich nicht siehst, sehe ich dich auch nicht". Genauso, wie man
das kleine Kind nur mit Muehe davon ueberzeugen kann, dass diese Annahme
falsch ist, kann man viele Laien im Umgang mit Netzwerken nur schwer
davon ueberzeugen, dass man nicht gleichzeitig am Internet teilnehmen
und trotzdem im Netz unsichtbar sein kann (was aber auch zu einem recht
grossen Teil daran liegt, dass angebliche "Fachzeitschriften" immer
wieder behaupten, dass so etwas doch moeglich waere, wobei der Autor
dies i.d.R. nicht belegen kann, waehrend die FAQ recht deutlich erklaert,
warum eben dieses "unsichtbar surfen" *nicht* moeglich ist).
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Das Netz ist Freude. Es ist Ekstase, die jeden einzelnen Nerv erglühen
läßt. Es ist Duft, den man fühlt. Es ist ein Bild, das man riecht.
Es ist Erfüllung - ein Geschmack, neben dem alles andere schal ist.
("Netzreiter-Preisung" aus dem Buch "Der Netzparasit" von Andreas Brandhorst)
Andreas Kretschmer
>> (bei der ganzen 135 und 445 - Klingelputzerei, die auf UNSERER Seite
>> horrende Kosten verursacht, bleibt nix anderes)
>
> (ich nehmen einfach mal an, es geht um isdn und linux ...) Der active
Ja.
> filter Support der aktuellen Kerne loest das Problem mit dem Auflegen
> nicht? Ich kenne zumindest einen, der ein 2.4.22 verwendet und bei dem
> ISDN trotz staendigem Klinkenputzen zuverlaessig auflegt.
Mmh, naja. Das sind Kisten, die z.T. einige hundert km entfernt sind,
und ansonsten klaglos als Gateway funktionieren. Kernel ist ein 2.4.18
oder so, ich verwende http://i4l.mediatronix.de/.
Große Verrenkungen will ich nun nicht mehr machen, es kommt eh
schrittweise DSL.
end
Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Arne Hauenschild
Hallo!
> Das "klassische" RFC-konforme Verhalten eines TCP/IP
> Geraetes bestand darin, bei nichtzustellbaren IP-Paketen
> den Absender davon zu informieren.
Aber bei TCP sollte das doch eine Schicht weiter oben geschehen. Warum
bei einem TCP SYN-Paket mit ICMP antworten, wenn es ein TCP RST doch
auch tut? Genau dafür bietet iptables ja die Option tcp-reset für
REJECT.
--
Arne
Juergen P. Meier
> Andreas Frackowiak <z0...@horga.de> wrote:
>
>> Das "klassische" RFC-konforme Verhalten eines TCP/IP
>> Geraetes bestand darin, bei nichtzustellbaren IP-Paketen
>> den Absender davon zu informieren.
>
> Aber bei TCP sollte das doch eine Schicht weiter oben geschehen. Warum
> bei einem TCP SYN-Paket mit ICMP antworten, wenn es ein TCP RST doch
> auch tut? Genau dafür bietet iptables ja die Option tcp-reset für
> REJECT.
RfC 1812 - Ein IPv4 Router muss auch bei TCP ein ICMP Paket schicken,
sofern es keine triftigen Gruende gibt, kein ICMP Paket zu schicken.
RfC 793 und 1122 sind hier nur fuer die Endpunkte relevant. Ein Server
darf darueberhinaus auch mit einem ICMP typ 3 Anstelle eines TCP/RST
Antworten, wenn er den Dienst nicht anbietet.
HTH,
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Marcus Ranum)
Ansgar -59cobalt- Wiechers
> Benjamin Scharbau <XCS_A...@gmx.de> schrieb:
>
>> 2. In unserem Subnetz (Uni) wird am Paketfilter des Hauses alles
>> nicht erwünschte geDROPt. Als ich den (ehemals) zuständigen nach den
>> Gründen fragte, wieso DROP anstatt von REJECT bekam ich die Antwort,
>> dass so flooding-Attacken verhindert werden sollen. Kann dies bei
>> REJECTS denn auftreten? Sollte da nicht der Kernel entsprechende
>> Schutzmaßnahmen treffen, um das zu vermeiden, oder hat REJECT hier
>> tatsächlich Probleme mit?
>
> Egal ob Reject oder Drop, der Paketfilter/Router muss sich anschauen,
> was er da bekommt. IMO ist die Zeit, die er für die Antwort (Reject)
> benötigt, vernachlässigbar gegen die Analyse des eingehenden Pakets.
> Insofern kann ich mir nicht vorstellen, wie Drop gegen flooding helfen
> sollte.
Du minimierst die Bandbreite nicht noch zusätzlich dadurch, dass Du zu
jedem eingehenden Paket ein ausgehendes erzeugst. Verhindern lässt sich
Flooding dadurch natürlich nicht.
cu
59cobalt
--
"Wir nehmen ständig an Glaubwürdigkeit zu."
--Darl McBride (SCO)
Oliver Föhr
>
> Mmh, naja. Das sind Kisten, die z.T. einige hundert km entfernt sind,
> und ansonsten klaglos als Gateway funktionieren. Kernel ist ein 2.4.18
> oder so, ich verwende http://i4l.mediatronix.de/.
>
> Große Verrenkungen will ich nun nicht mehr machen, es kommt eh
> schrittweise DSL.
>
Oder nimm SuSE 8.2 da iss?er mit drin
SCNR
olly
--
begin LOVE-LETTER-FOR-YOU.txt.vbs
end
Dominik Ruf
> 1. Wenn ich REJECTen will, muss ich das extra in den Kernel kompi-
> lieren (auf Linux 2.4.16 zumindest), DROP geht auch so.
Ich vermute, hier gibt es immer noch ein Missverständnis:
REJECT gibt es nur als Target, nicht als Policy.
DROP kann sowohl Target als auch Policy sein.
Beides sollte bei iptables-Support dabei sein, ohne extra kompilieren.
> 2. In unserem Subnetz (Uni) wird am Paketfilter des Hauses alles nicht
^^^^^^^^^^
Wohnheim? Oder "richtige" Uni aka RZ?
> erwünschte geDROPt. Als ich den (ehemals) zuständigen nach den Gründen
> fragte, wieso DROP anstatt von REJECT bekam ich die Antwort, dass so
> flooding-Attacken verhindert werden sollen. Kann dies bei REJECTS denn
> auftreten? Sollte da nicht der Kernel entsprechende Schutzmaßnahmen
> treffen, um das zu vermeiden, oder hat REJECT hier tatsächlich
> Probleme mit?
Bei Linux/netfilter werden die REJECT-Antworten automatisch
mit einem Ratelimit versehen, wie das scheinbar auch die RFCs fordern:
http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO-7.html#ss7.4
| REJECT
|
| This module has the same effect as `DROP', except that the sender
| is sent an ICMP `port unreachable' error message. Note that the
| ICMP error message is not sent if (see RFC 1122):
|
| * The packet being filtered was an ICMP error message in the
| first place, or some unknown ICMP type.
| * The packet being filtered was a non-head fragment.
| * We've sent too many ICMP error messages to that destination
| recently (see /proc/sys/net/ipv4/icmp_ratelimit).
Aber mit DROP spart man sich natürlich auch diese wenigen Antworten.
Ich wage aber zu bezweifeln, ob dieser vermeintliche Vorteil bei
Angriffen die Nachteile im alltäglichen Betrieb rechtfertigt.
Meinungen dazu?
Grüße, Dominik
Henryk Plötz
Am Fri, 17 Oct 2003 21:43:47 +0200 schrieb Dominik Ruf:
> * Benjamin Scharbau <XCS_A...@gmx.de>:
>
> > 1. Wenn ich REJECTen will, muss ich das extra in den Kernel kompi-
> > lieren (auf Linux 2.4.16 zumindest), DROP geht auch so.
>
> Ich vermute, hier gibt es immer noch ein Missverständnis:
> REJECT gibt es nur als Target, nicht als Policy.
> DROP kann sowohl Target als auch Policy sein.
> Beides sollte bei iptables-Support dabei sein, ohne extra kompilieren.
Was Benjamin wohl meint, ist, dass unter "Networking Options" -> "IP:
Netfilter Configuration" "REJECT target support" extra angewählt werden
muß (zum Beispiel als Modul ipt_REJECT.o), während DROP schon in "Packet
filtering" inbegriffen ist.
Das hängt natürlich mit den Policy-Auswahlmöglichkeiten zusammen, nur:
ob es REJECT nicht als Policy gibt, weil es extra an/abgewählt werden
kann, oder ob es extra an/abgewählt werden kann, weil es es eh nicht als
Policy gibt, ist daraus nicht ersichtlich.
--
Henryk Plötz
Grüße aus Berlin
~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~
~ Help Microsoft fight software piracy: Give Linux to a friend today! ~
Christian Vogel
On Wed, 15 Oct 2003 18:41:08 +0200, Andreas Kretschmer wrote:
> Ich ziehe z.B. auch ein REJECT vor, allerdings habe ich einige
> ISDN-Systeme am laufen, die nach Zeittakt berechnet werden. Leider habe
> ich dafür keine Lösung gefunden, die sauber auflegt trotz REJECT. Ich
> nutze dort einen Patch, der mich allerdings zum DROP zwingt.
ich benutze das hier, funktioniert wunderbar. (Ja, ich habe hier auch
iptables mit icmp-unreach/tcp-rst (="REJECT").
###
# packets that keep our connection allive must be...
###
# outbound, no icmp unreach, no echo reply and no tcp RST/FIN
# icmp[0(type)] != 3(dest unreach), != 0(echo reply)
# tcp[13(th_flags)] & 5(TH_RST=0x04 | TH_FIN=0x01) != 0
active-filter "outbound && not (
(icmp[0] == 3) ||
(icmp[0] == 0) ||
(tcp[13] & 5 != 0) ||
(udp and port 123)
)"
Andreas Kretschmer
> ich benutze das hier, funktioniert wunderbar. (Ja, ich habe hier auch
> iptables mit icmp-unreach/tcp-rst (="REJECT").
bekannt, funktioniert aber bei dem ISDN-ipppd nicht. Leider.
Raimund Specht
> bekannt, funktioniert aber bei dem ISDN-ipppd nicht. Leider.
Seit Linux 2.4.22 und den aktuellen CVS-isdn4k-utils schon :-)
By(e): Raimund.
Erhard Schwenk
> begin Benjamin Scharbau <XCS_A...@gmx.de> wrote:
>
>>erwähnt, dass man lieber REJECTen als DROPpen sollten (Gründe
>>dafür kann ich nachvollziehen). Wenn ich hingegen andere Quellen
>>betrachte (z.B. iptables-HOWTO, Linux - Wegweiser für Netzwerker)
>>ist dort oft REJECT gar nicht, oder nur am Rande erwähnt, hier
>>ist dann häufig die Rede von DROPpen als blocken.
>
>
> Möglicherweise bist Du durch die Policy-Regeln irritiert, diese lassen
> nur ein DROP zu.
>
>
>
>>Personen(kreisen)? Vielleicht habe ich auch bisher etwas Grund-
>>legendes missverstanden, weshalb diese Frage auf einem Miss-
>>verständnis beruht, ist dem so?
>
>
> Ich ziehe z.B. auch ein REJECT vor, allerdings habe ich einige
> ISDN-Systeme am laufen, die nach Zeittakt berechnet werden. Leider habe
> ich dafür keine Lösung gefunden, die sauber auflegt trotz REJECT. Ich
> nutze dort einen Patch, der mich allerdings zum DROP zwingt.
> (bei der ganzen 135 und 445 - Klingelputzerei, die auf UNSERER Seite
> horrende Kosten verursacht, bleibt nix anderes)
Mit Linux/iptables gibt es eine Lösung.
Man baut sich einen "accept-it"-Chain und schickt alle Daten, die man
normalerweise "ACCEPT" zuleiten würde, dort hin. Außer denen, die nicht
fürs Auflegen relevant sein sollen.
Dann baut man sich einen cron-Job, der diesen Chain im sagen wir mal
5-Minuten-Takt abfragt und auf Null zurücksetzt. Findet er schon 0
Pakete im Zähler dieses chain vor, setzt man halt entweder ein istnctrl
hangup ab oder killt den pppd. Damit legt die Kiste dann auf, auch wenn
auf unerwünschten Ports noch Filesharing-Traffic durchkommt. Den kann
man dann rejecten, aber man muß die Rejects nicht durch accept-it
schieben :-)
Unschön, ich weiß, aber eine Lösung für das Problem.
--
Erhard Schwenk
Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de
K-ITX Webhosting - http://webhosting.k-itx.net
Andreas Beck
> Benjamin Scharbau <XCS_A...@gmx.de> wrote:
>> [REJECT vs DROP]
> dennoch steht hinter diesem "stillem entsorgen" das Konzept
> dass der Firewall keine Informationen ueber sich selbst
> an Unbefugte herauszugeben hat,
Und mit Drop tut man in der Regel genau das.
Auf Masq-Routern, die nach außen als Endpoint auftreten, stellt man
daher ggf. REJECT-durch-RST ein, dann ist nicht zu unterscheiden, ob das
die Paketfilterregeln tun, oder der IP-Stack.
CU, Andy
Andreas Beck
> Andreas Kretschmer schrieb:
>> begin Benjamin Scharbau <XCS_A...@gmx.de> wrote:
>> Ansonsten gibt es immer mal wieder Diskussion darum, ob man hirntot
>> programmierten Tausch-Diensten, die auf REJECT nicht reagieren, mittels
>> DROP bremsen sollte.
> Trifft diese hirntote Programmierung generell auf alle Tauschdienste zu,
> oder gibt es da auch welche, die auf REJECT reagieren?
Nein. Es sind auch nur einzelne Clients, die zu blöd sind, bei einem
sofort mit Fehlermedlung zurückkehrenden connect() die betreffende IP
aus dem potentiellen Kandidatenpool zu werfen, sondern lieber ihre Zeit
damit vertun, das noch ganz oft nochmal zu versuchen.
> 1. Wenn ich REJECTen will, muss ich das extra in den Kernel kompi-
> lieren (auf Linux 2.4.16 zumindest), DROP geht auch so. Wieso wird
> REJECT da nicht auch gleich miteinkompiliert?
Also: DROPen _muß_ man können. Es ist eine einstellbare policy. Ebenso
wie ACCEPT. Alles andere ist optional.
> Gab es anfänglich nur DROP, und REJECT ist dann später dazugekommen,
IMHO nein - vielleicht von kurzen Phasen in der Entwicklung (da DROP
eben trivial zu implementieren ist und REJECT etwas tun muss) abgesehen.
> 2. In unserem Subnetz (Uni) wird am Paketfilter des Hauses alles nicht
> erwünschte geDROPt. Als ich den (ehemals) zuständigen nach den Gründen
> fragte, wieso DROP anstatt von REJECT bekam ich die Antwort, dass so
> flooding-Attacken verhindert werden sollen.
Nunja - man belastet seinen Outbound weniger. Außerdem nervt man
niemanden mit den unerwarteten ICMPs, wenn IP-Spoofing betrieben wird.
Es gibt auch Dinge, die man DROPen sollte (weil man gar nix sinnvolles
zurücksenden _kann_), wie unerwünschte ICMPs.
Aber bringen tuts net viel. Wenn man ne Leitung sättigen will, findet
man schon nen Dienst, der auch mit einem quatschen will.
CU, Andy
Jens Suelwald
> Aber bringen tuts net viel. Wenn man ne Leitung sättigen will, findet
> man schon nen Dienst, der auch mit einem quatschen will.
Das sollte doch auch egal sein, oder? Selbst wenn da kein Dienst iss,
bekomm ich (als Angreifer) wenigstens die Leitung in eine Richtung hin
dicht, oder?
Bis denne,
Jens Suelwald
--
"If this would be a military situation, you'd be taken outside and shot"
-- Malcolm Reed to Charles Tucker during a simulated tactical alert on
Enterprise (Enterprise - Singularity)
Juergen Ilse
Ansgar -59cobalt- Wiechers <usene...@planetcobalt.net> wrote:
> Thomas Hertel wrote:
>> Egal ob Reject oder Drop, der Paketfilter/Router muss sich anschauen,
>> was er da bekommt. IMO ist die Zeit, die er für die Antwort (Reject)
>> benötigt, vernachlässigbar gegen die Analyse des eingehenden Pakets.
>> Insofern kann ich mir nicht vorstellen, wie Drop gegen flooding helfen
>> sollte.
> Du minimierst die Bandbreite nicht noch zusätzlich dadurch, dass Du zu
> jedem eingehenden Paket ein ausgehendes erzeugst. Verhindern lässt sich
> Flooding dadurch natürlich nicht.
Tust du auch sonst nicht, wenn deine Internet-Anbindung "Full Dpulex" ist
(und ueblicherweise sind das sowohl SDSL, als auch ISDN-Festverbindungen
genau wie DialUp-Verbindungen, bei Ethernet nur bei geswitchtem Netz, aber
wenn da die Rejects zu einem Bandbreitenproblem werden, hast du vermutlich
ganz andere Probleme ...). Teilweise kann man auch ICMP-Antworten begrenzen
(was das von dir skizzierte Problem auch besser beheben wuerde als "DROP").
Thomas Hertel
>Teilweise kann man auch ICMP-Antworten begrenzen
>(was das von dir skizzierte Problem auch besser beheben wuerde als "DROP").
Was meinst du mit begrenzen? In der Anzahl oder in der Länge?
Jens Hektor
> Auf Masq-Routern, die nach außen als Endpoint auftreten, stellt man
> daher ggf. REJECT-durch-RST ein, dann ist nicht zu unterscheiden, ob das
> die Paketfilterregeln tun, oder der IP-Stack.
Gilt nur für TCP. Für UDP nimmt man dann besser ICMP/dest-unreach/port-unreach.
Andreas Beck
> On Sun, 19 Oct 2003, Andreas Beck wrote:
>> Aber bringen tuts net viel. Wenn man ne Leitung sättigen will, findet
>> man schon nen Dienst, der auch mit einem quatschen will.
> Das sollte doch auch egal sein, oder? Selbst wenn da kein Dienst iss,
> bekomm ich (als Angreifer) wenigstens die Leitung in eine Richtung hin
> dicht, oder?
Ja. Das war schon immer unstrittig. Es ging nur noch um den Fall, daß
man seinen outbound weniger belasten möchte. Könnte ein paar Cent
sparen.
CU, Andy
Andreas Beck
Latürnich. Denn: Wie sendet man ein RST für irgendwas ausser TCP? :-)
CU, Andy
Juergen Ilse
Thomas Hertel <Thomas...@gmx.net> wrote:
> Juergen Ilse <jue...@usenet-verwaltung.de> schrieb:
>>Teilweise kann man auch ICMP-Antworten begrenzen
>>(was das von dir skizzierte Problem auch besser beheben wuerde als "DROP").
> Was meinst du mit begrenzen? In der Anzahl oder in der Länge?
In der Frequenz (nicht mehr als xxx ICMP-Antworten pro Sekunde an den
selben Host, evt. auch nicht mehr als xxx ICMP-Antworten insgesamt pro
Sekunde).
Erhard Schwenk
> begin Christian Vogel <usenet...@hedonism.cx> wrote:
>>ich benutze das hier, funktioniert wunderbar. (Ja, ich habe hier auch
>>iptables mit icmp-unreach/tcp-rst (="REJECT").
> bekannt, funktioniert aber bei dem ISDN-ipppd nicht. Leider.
Kann man wie an anderer Stelle bereits beschrieben aber auch bei ISDN
recht bequem mit cron und iptables nachbauen.