ISPs verhelfen "Stealth"-Modi von PFWs zur Funktion?
Felix M. Palmen
Unmöglichkeit von "Stealth"-Modi hingewiesen wurde möchte ich mal
folgende Beobachtung zur Diskussion stellen:
Normalerweise würde man ja erwarten, dass bei einem nicht vorhanden
Rechner der zuständige Router entsprechende ICMP-Fehlermeldungen
verschickt. Bei T-Online scheint das allerdings zu unterbleiben. Ich
konnte im Dialup-Bereich von T-Online nur eine einzige Möglichkeit
finden, wie man einen nicht vorhandenen Rechner von einem mit
"Stealth"-Mode unterscheiden kann: Traceroute spuckt bei letzterem
einen Hop mehr aus, das ist wohl die PPP-Gegenstelle.
Mehrere Fragen an euch:
- Weiß jemand, ob das andere ISPs genauso handhaben?
- Ist die Methode mit traceroute für PPP-Verbindungen zuverlässig oder
kann das auch schiefgehen?
- Würde das nicht bedeuten, dass "Stealth" - einen entsprechend
filternden ISP vorausgesetzt - doch funktionieren kann?
Das soll jetzt allerdings keine Diskussion über Sinn und Unsinn von
DROP werden, ich habe nicht vor, es bei mir zum default zu machen ;)
Grüße, Felix
--
| /"\ ASCII Ribbon | Felix M. Palmen (Zirias) http://zirias.ath.cx/ |
| \ / Campaign Against | f...@palmen.homeip.net encrypted mail welcome |
| X HTML In Mail | PGP key: http://zirias.ath.cx/pub.txt |
| / \ And News | ED9B 62D0 BE39 32F9 2488 5D0C 8177 9D80 5ECF F683 |
Malte J. Wetz
> Normalerweise würde man ja erwarten, dass bei einem nicht vorhanden
> Rechner der zuständige Router entsprechende ICMP-Fehlermeldungen
> verschickt. Bei T-Online scheint das allerdings zu unterbleiben.
Nicht nur T-Online. Das ist wohl im ganzen Telekom-Backbone so. Ich bin
da auch zufällig die Tage darauf gestoßen und habe es in den internen
T-Online-Gruppen erwähnt.
Gründe für dieses Setup konnte mir das T-Online-Team nicht nennen. Ich
konnte auch bisher keinen Standard finden, der das eindeutig regelt
(habe allerdings auch nicht allzu gründlich gesucht, weil es mich dann
doch nicht sooo wahnsinnig interessierte). RFC1812 wird das wohl mal
machen, wenn er denn so weit ist.
> Ich konnte im Dialup-Bereich von T-Online nur eine einzige Möglichkeit
> finden, wie man einen nicht vorhandenen Rechner von einem mit
> "Stealth"-Mode unterscheiden kann: Traceroute spuckt bei letzterem
> einen Hop mehr aus, das ist wohl die PPP-Gegenstelle.
Genau das gleiche habe ich auch gedacht! Aber laut Aussage des
T-Online-Teams besteht dort kein Zusammenhang. Der "letzte Hop", den Du
meinst, ist der RAR, der angeblich "blind" weiterleitet, egal, ob da
nun ein Host hintendran hängt oder nicht nicht.
Warum in einigen Traceroutes der RAR nicht zu sehen ist, in anderen
schon, konnte man mir allerdings nicht erklären.
> Mehrere Fragen an euch:
>
> - Weiß jemand, ob das andere ISPs genauso handhaben?
Alle Telekom-Reseller dürften das gleiche Problem haben, obwohl es wohl
keine bewußte Entscheidung ihrerseits ist. Das macht die Telekom halt
so und basta.
> - Ist die Methode mit traceroute für PPP-Verbindungen zuverlässig oder
> kann das auch schiefgehen?
Wie gesagt: Laut Aussage des Teams ist Deine (und meine) Schlußfolgerung
falsch.
> - Würde das nicht bedeuten, dass "Stealth" - einen entsprechend
> filternden ISP vorausgesetzt - doch funktionieren kann?
Für geeignete Werte von "funktionieren". Man kann keinen Unterschied
sehen zwischen einem filternden Host und einem nicht eingewählten Host
erkennen. Die anderen Probleme, die man sich mit DROP einfängt, bleiben
natürlich.
--
http://www.malte-wetz.de (Linux: ISDN-Anrufbeantworter, Text-To-Speech,
ISDN-Inhaltsdatenkomprimierung, yapsrc für alle dt. Netze, Sondertasten
von Multimedia-Tastaturen; Allgemein: Rechnersicherheit)
Oliver Schad
> Da gerade in einem anderen Thread wieder auf die prinzipbedingte
> Unmöglichkeit von "Stealth"-Modi hingewiesen wurde möchte ich mal
> folgende Beobachtung zur Diskussion stellen:
Nein, es ist nicht unmöglich unsichtbar zu sein, es klappt aber
oftmals nicht. Was viel wichtiger ist: Es ist schwachsinnig, selbst
wenn es klappt.
Szenario 1:
Stellen wir uns vor, jemand bietet keine Dienste an, der TCP/IP-Stack
hängt nackt im Internet. Jetzt bin ich ein pöser pöser Angreifer und
greife den TCP/IP-Stack mit ICMP-Paketen an. *manisches Gelächter*
Und ich freu mich wirklich, dass das Gegenüber so blöd ist und auf
ICMP-Request mit ICMP-Echo antwortet. Denn jetzt kann ich ja ... ja
was denn eigentlich? Ah ja, ich finde raus, wo die Drecksau wohnt und
hau der eins auf die Fresse. *g*
Stellen wir uns jetzt vor, jemand bietet Dienste an und verfällt dem
Unsichtbarkeitswahn. Jetzt bin ich ein pöser pöser Angreifer und
greife die PFW mit ICMP-Paketen an. *manisches Gelächter* Und ich
freu mich wirklich, dass das Gegenüber so blöd ist und auf
ICMP-Requests nicht antwortet. Ich probiere mal TCP-Pakete. Mmh,
vielleicht hat $TYP am anderen Ende eine PFW. Vielleicht ist da auch
keiner. Ich werf da einfach mal meine Exploitsammlung für PFWs drauf,
mal gucken was passiert.
Szenario 2:
Stellen wir uns vor, jemand bietet keine Dienste an, der TCP/IP-Stack
hängt nackt im Internet. Jetzt bin ich ein pöser pöser Wurm und
probiere einen Connect auf Port 135 TCP. Klappt nicht, Mist.
Stellen wir uns nun wieder vor, jemand bietet Dienste an und verfällt
dem Unsichtbarkeitswahn. Jetzt bin ich ein pöser pöser Wurm und
probiere einen Connect auf Port 135 TCP. Klappt nicht, Mist, aber der
TCP/IP-Stack der Quelle des Wurms versucht es einfach nochmal. Und
nochmal. Und nochmal. $TYP hat ja sicher keinen Volumentarif, das
macht also nix.
Szenario 3:
Stellen wir uns vor, jemand bietet keine Dienste an, der TCP/IP-Stack
hängt nackt im Internet. Jetzt bin ich ein pöser pöser Wurm, der PFWs
angreift. Ich schicke einen pösen Exploit (ein kaputtes IGMP-Paket)
und ... Toll, funktioniert nicht.
Stellen wir uns nun wieder vor, jemand bietet Dienste an und verfällt
dem Unsichtbarkeitswahn. Jetzt bin ich ein pöser pöser Wurm, der PFWs
angreift. Ich schicke einen pösen Exploit (ein kaputtes IGMP-Paket)
und das Ziel gehört mir. Jippi.
Ergebnis: Stealth-Modus ist schwachsinnig, selbst wenn er
funktioniert.
mfg
Oli
--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen.
Le Filou
"Oliver Schad" <o.s...@web.de> wrote:
> Stellen wir uns nun wieder vor, jemand bietet Dienste an und verfällt
> dem Unsichtbarkeitswahn. Jetzt bin ich ein pöser pöser Wurm, der PFWs
> angreift. Ich schicke einen pösen Exploit (ein kaputtes IGMP-Paket)
> und das Ziel gehört mir. Jippi.
Welche PFW ist für kaputte IGMP-Pakete von außen anfällig?
Oliver Schad
Mir nicht bekannt, das ist ein konstruiertes Beispiel.
Le Filou
"Oliver Schad" <o.s...@web.de> wrote:
>> Welche PFW ist für kaputte IGMP-Pakete von außen anfällig?
> Mir nicht bekannt, das ist ein konstruiertes Beispiel.
Etwas dürftig für deine vollmundig vorgetragene Behauptung:
Felix M. Palmen
* Oliver Schad <o.s...@web.de>:
> Ergebnis: Stealth-Modus ist schwachsinnig, selbst wenn er
> funktioniert.
Deine Meinung hierzu teile ich weitgehend, aber darum ging es mir nicht.
<news:N3e8I421e...@nexus.palmen.homeip.net>:
| Das soll jetzt allerdings keine Diskussion über Sinn und Unsinn von
| DROP werden, [...]
Die Diskussion gab es IMHO wirklich schon oft genug.
Interessant ist, dass die pauschale Aussage "Stealth funktioniert
nicht" in ihrem Wahrheitsgehalt offenbar in der Tat vom ISP abhängt.
Felix M. Palmen
* Malte J. Wetz <spa...@malte-wetz.de>:
> * Felix M. Palmen <zir...@despammed.com> wrote:
>> Ich konnte im Dialup-Bereich von T-Online nur eine einzige Möglichkeit
>> finden, wie man einen nicht vorhandenen Rechner von einem mit
>> "Stealth"-Mode unterscheiden kann: Traceroute spuckt bei letzterem
>> einen Hop mehr aus, das ist wohl die PPP-Gegenstelle.
>
> Genau das gleiche habe ich auch gedacht! Aber laut Aussage des
> T-Online-Teams besteht dort kein Zusammenhang. Der "letzte Hop", den Du
> meinst, ist der RAR, der angeblich "blind" weiterleitet, egal, ob da
> nun ein Host hintendran hängt oder nicht nicht.
>
> Warum in einigen Traceroutes der RAR nicht zu sehen ist, in anderen
> schon, konnte man mir allerdings nicht erklären.
Die Aussagen von T-Online-Technikern genieße ich für gewöhnlich mit
Vorsicht, allerdings hatte ich bisher den Eindruck, dass sich hinter
dem "T-Online-Team" in t-online.* die kompetenten Exemplare dieser
Gattung verbergen :)
Also wenn das so wirklich stimmt würde das ja bedeuten, dass "Stealth"
für T-Online-Kunden in der Tat funktioniert wie beworben, auch wenn das
eigentlich keiner braucht.
Man darf sich wohl bei T-Online bedanken für "tote" Verbindungen in
P2P-Netzen, die unnötig lange hängenbleiben :/ (Neben den bisher schon
angeklagten Herstellern und Propaganten von Stealth-PFWs). Wenn ich mir
da so meinen Host-Cache von Skype ansehe *argh*
Oliver Schad
Deine Logik ist kaputt. Die Komplexität einer PFW ist wesentlich
größer, als die eines TCP/IP-Stacks. Die Exploits in der
Vergangenheit geben mir auch praktisch recht.
Daraus leite ich korrekt ab, dass der Stealth-Modus nicht nur keinen
Sicherheitsgewinn, sondern im Gegenteil durch die Verwendung einer
PFW, eine Verringerung der Sicherheit mit sich bringt.
Diese Diskussion ist so alt, wie diese Gruppe, Google ist dein Freund.
Deswegen Fup2p
Oliver Schad
> Interessant ist, dass die pauschale Aussage "Stealth funktioniert
> nicht" in ihrem Wahrheitsgehalt offenbar in der Tat vom ISP abhängt.
Ja.
Le Filou
"Oliver Schad" <o.s...@web.de> wrote:
>> | Ergebnis: Stealth-Modus ist schwachsinnig, selbst wenn er
>> | funktioniert.
> Deine Logik ist kaputt.
Durchaus nicht. Du hast deine Behauptung aus einem konstruierten Beispiel
hergeleitet - nicht sehr überzeugend.
> Die Komplexität einer PFW ist wesentlich größer, als die eines
> TCP/IP-Stacks. Die Exploits in der Vergangenheit geben mir auch
> praktisch recht.
Auch hier die Frage: welche dieser Exploits basierten auf Paketen von
'außen'?
> Daraus leite ich korrekt ab, dass der Stealth-Modus nicht nur keinen
> Sicherheitsgewinn, sondern im Gegenteil durch die Verwendung einer
> PFW, eine Verringerung der Sicherheit mit sich bringt.
> Diese Diskussion ist so alt, wie diese Gruppe, Google ist dein Freund.
Bisher ging es nur um den Stealth-Mode und nicht um die grundsätzliche
Frage, ob der Einsatz einer PFW sinnvoll ist.
In <416186f8$0$3639$9b4e...@newsread2.arcor-online.net> ff. habe ich
gezeigt, daß das Nichtbeantworten unerwünschter Verbindungsversuche
(Stealth-Mode) durchaus sinnvoll sein kann, um unerwünschten Traffic zu
minimieren und keineswegs schwachsinnig ist, wie du behauptest.
Peter Moeckli
>Also wenn das so wirklich stimmt würde das ja bedeuten, dass "Stealth"
>für T-Online-Kunden in der Tat funktioniert wie beworben, auch wenn das
>eigentlich keiner braucht.
Aber in diesem Fall funktioniert es dann wohl auch bei denen, die
keine PFW verwenden.
CU
Peter
--
sLANp XI
24. bis 27. März 2005
Stadthalle Dietikon
http://www.slanp.ch für Infos
Oliver Schad
> In <416186f8$0$3639$9b4e...@newsread2.arcor-online.net> ff. habe
> ich gezeigt, daß das Nichtbeantworten unerwünschter
> Verbindungsversuche (Stealth-Mode) durchaus sinnvoll sein kann, um
> unerwünschten Traffic zu minimieren und keineswegs schwachsinnig
> ist, wie du behauptest.
Du redest über selektives Drop für kaputte TCP/IP-Stacks, ich rede
über Stealth-Modus. Dieses selektive Drop soll aber immer nur eine
temporäre Maßnahme sein, die aber sicherlich sinnvoll sein *kann*.
Das ist nicht der Punkt, um den es ging. Es gibt zudem auch noch
Limits mit denen man arbeiten kann, um unnötigen Datenverkehr zu
reduzieren.
Stealth-Modus ist immer noch schwachsinnig, denn es gibt immer noch
*keinen* Sicherheitsgewinn.
Stealth-Modus=weniger Verkehr ist auch flasch. Meine Logdateien zeigen
das. Je nach Netzwerk und Situation mag das aber temporär anders
sein.
Daraus abzuleiten, dass Stealth-Modus prinzipiell sinnhaft sei,
gelingt wohl nur dir. Wobei anzumerken bleibt, dass die Intention des
Stealth-Modus' nicht die Reduktion von Datenverkehr ist, sondern der
angebliche Sicherheitsgewinn.
Nochmal: Selektives Drop oder Limits können situtationsbedingt Sinn
machen. Es geht sich aber nicht darum, sondern um Stealth-Modus.
Wegen bereits erschöpfender Diskussion in dieser Gruppe in der
Vergangenheit Fup2p
Felix M. Palmen
* Peter Moeckli <delo...@datacomm.ch>:
> Felix M. Palmen schrieb:
>
>>Also wenn das so wirklich stimmt würde das ja bedeuten, dass "Stealth"
>>für T-Online-Kunden in der Tat funktioniert wie beworben, auch wenn das
>>eigentlich keiner braucht.
>
> Aber in diesem Fall funktioniert es dann wohl auch bei denen, die
> keine PFW verwenden.
Nein. Ohne PFW antwortet das System wie spezifiziert. Ohne eingewählten
Rechner sollte eigentlich der Router antworten. Tut er das nicht, ist
dieser Zustand nicht von einem Rechner mit entsprechender PFW zu
unterscheiden, wohl aber von einem ohne (oder eben mit sauber
konfiguriertem Paketfilter).
Alexander Skwar
> Mehrere Fragen an euch:
>
> - Weiß jemand, ob das andere ISPs genauso handhaben?
Das hatten wir vor einigen Monaten schonmal hier in dcsf.
Nicht nur T-Online + Reseller machen das so, sondern
auch andere Backbones, wie z.B. Arcor oder Citykom.
Alexander Skwar
--
Don't stop to stomp ants when the elephants are stampeding.
·_·¯·_·¯·_ ♘♞♟♙♖♜ аäöüßÄÖÜæœłø¼½¾¤¹²³¢€£¥¶§¬÷×±©®™¡¿ ♪♬♯♪♬♯♭ ¯·_·¯·_·¯·
Alexander Skwar
> Daraus leite ich korrekt ab, dass der Stealth-Modus nicht nur keinen
> Sicherheitsgewinn, sondern im Gegenteil durch die Verwendung einer
> PFW, eine Verringerung der Sicherheit mit sich bringt.
Wieso bezeichnest Du iptables als PFW? Es ist eigentlich eher
usus, sowas als HBPF zu bezeichnen.
Wenn, aus $Grund, eh schon ein HBPF läuft, dann gibt es keine
Verringerung der Sicherheit.
Alexander Skwar
--
I profoundly believe it takes a lot of practice to become a moral slob.
-- William F. Buckley
Alexander Skwar
> In <416186f8$0$3639$9b4e...@newsread2.arcor-online.net> ff. habe ich
> gezeigt, daß das Nichtbeantworten unerwünschter Verbindungsversuche
> (Stealth-Mode) durchaus sinnvoll sein kann, um unerwünschten Traffic zu
> minimieren und keineswegs schwachsinnig ist, wie du behauptest.
Die Rechnung ist falsch. Du hast dort gezeigt, das ein DROP
dazu führt, das ein Paket mehrfach gesendet wird und somit
DROP dazu führt, das mehr Traffic verbraucht wird.
Für Bandbreitensparer ist also REJECT das Mittel der Wahl.
Alexander Skwar
--
Women wish to be loved without a why or a wherefore; not because they are
pretty, or good, or well-bred, or graceful, or intelligent, but because
they are themselves.
-- Amiel
Le Filou
"Alexander Skwar" <alex...@skwar.name> wrote:
>> In <416186f8$0$3639$9b4e...@newsread2.arcor-online.net> ff. habe ich
>> gezeigt, daß das Nichtbeantworten unerwünschter Verbindungsversuche
>> (Stealth-Mode) durchaus sinnvoll sein kann, um unerwünschten Traffic zu
>> minimieren und keineswegs schwachsinnig ist, wie du behauptest.
> Die Rechnung ist falsch. Du hast dort gezeigt, das ein DROP
> dazu führt, das ein Paket mehrfach gesendet wird und somit
> DROP dazu führt, das mehr Traffic verbraucht wird.
Falsch - lies genauer. Wie die Logauszüge zeigen, werden diese Pakete an
Port 135/445 'IMMER' mehrfach geschickt; egal, ob sie mit REJECT
beantwortet werden oder nicht. Daran hat sich auch heute, Monate später,
nichts geändert.
Alexander Skwar
Bei einem REJECT muss kein Retransmit erfolgen. Und in der Regel
erfolgt auch keiner. Somit ist Deine Aussage falsch.
> Daran hat sich auch heute, Monate später,
> nichts geändert.
Eben.
Alexander Skwar
--
We all know that no one understands anything that isn't funny.
Peter Moeckli
>> Aber in diesem Fall funktioniert es dann wohl auch bei denen, die
>> keine PFW verwenden.
>
>Nein. Ohne PFW antwortet das System wie spezifiziert.
Ach so. Ich dachte, das würde dann generell so laufen.
Oliver Schad
> · Le Filou <loca...@nurfuerspam.de>:
>
>> Falsch - lies genauer. Wie die Logauszüge zeigen, werden diese
>> Pakete an Port 135/445 'IMMER' mehrfach geschickt; egal, ob sie mit
>> REJECT beantwortet werden oder nicht.
>
> Bei einem REJECT muss kein Retransmit erfolgen. Und in der Regel
> erfolgt auch keiner. Somit ist Deine Aussage falsch.
Tcpdump auf Port 135 TCP, DSL Telekom
217.255.186.107.4795 > 217.255.xxx.xxx.135: S
217.255.xxx.xxx.135 > 217.255.186.107.4795: R
217.255.186.107.4795 > 217.255.xxx.xxx.135: S
217.255.226.102.3336 > 217.255.xxx.xxx.135: S
217.255.xxx.xxx.135 > 217.255.226.102.3336: R
217.255.226.102.3336 > 217.255.xxx.xxx.135: S
217.255.28.4.4231 > 217.255.xxx.xxx.135: S
217.255.xxx.xxx.135 > 217.255.28.4.4231: R
217.255.22.109.3399 > 217.255.xxx.xxx.135: S
217.255.250.173.4610 > 217.255.xxx.xxx.135: S
217.255.xxx.xxx.135 > 217.255.250.173.4610: R
217.255.250.173.4610 > 217.255.xxx.xxx.135: S
217.255.175.63.2905 > 217.255.xxx.xxx.135: S
217.255.xxx.xxx.135 > 217.255.175.63.2905: R
217.255.175.63.2905 > 217.255.xxx.xxx.135: S
217.255.219.215.3616 > 217.255.xxx.xxx.135: S
217.255.xxx.xxx.135 > 217.255.219.215.3616: R
217.255.247.215.4308 > 217.255.xxx.xxx.135: S
217.255.xxx.xxx.135 > 217.255.247.215.4308: R
217.255.247.215.4308 > 217.255.xxx.xxx.135: S
217.255.169.120.3489 > 217.255.xxx.xxx.135: S
217.255.xxx.xxx.135 > 217.255.169.120.3489: R
217.255.169.120.3489 > 217.255.xxx.xxx.135: S
217.255.xxx.xxx.135 > 217.255.169.120.3489: R
Man sieht die wiederholten Anfragen trotz TCP-RST.
# iptables-save | grep 135
-A INPUT -p tcp -m tcp --dport 135 -m limit --limit 1/sec
--limit-burst 1 -j REJECT --reject-with tcp-reset
-A INPUT -p tcp -m tcp --dport 135 -j DROP
Wir sind also freundlich, aber mehr als 1x pro Sekunde geht mir zu
weit. Von diesen verwurmten Maschinen kommen *momentan* in der Regel
2 Anfragen, wenn man dropt, 3 Anfragen, wenn man rejected.
Alexander Skwar
> 217.255.169.120.3489 > 217.255.xxx.xxx.135: S
> 217.255.xxx.xxx.135 > 217.255.169.120.3489: R
>
> Man sieht die wiederholten Anfragen trotz TCP-RST.
Hierbei handelt es sich um einen Sonderfall:
> verwurmten Maschinen kommen *momentan* in der Regel
> 2 Anfragen, wenn man dropt, 3 Anfragen, wenn man rejected.
Das dieser Sonderfall inzwischen einen Großteil des
Traffics ausmacht, ist unbestritten.
Alexander Skwar
--
Serving coffee on aircraft causes turbulence.
Oliver Schad
> · Oliver Schad <o.s...@web.de>:
>
>> Daraus leite ich korrekt ab, dass der Stealth-Modus nicht nur
>> keinen Sicherheitsgewinn, sondern im Gegenteil durch die Verwendung
>> einer PFW, eine Verringerung der Sicherheit mit sich bringt.
>
> Wieso bezeichnest Du iptables als PFW?
Ich verstehe nicht ganz, wie du von Stealth-Modus auf Iptables kommst.
Sag nicht, dass man diesen Unsinn da auch schon so bewirbt.
> Wenn, aus $Grund, eh schon ein HBPF läuft, dann gibt es keine
> Verringerung der Sicherheit.
Ja, aber auch keine signifikante Erhöhung.
Oliver Schad
> · Oliver Schad <o.s...@web.de>:
>
>> 217.255.169.120.3489 > 217.255.xxx.xxx.135: S
>> 217.255.xxx.xxx.135 > 217.255.169.120.3489: R
>>
>> Man sieht die wiederholten Anfragen trotz TCP-RST.
>
> Hierbei handelt es sich um einen Sonderfall:
<loriot/>
>> verwurmten Maschinen kommen *momentan* in der Regel
>> 2 Anfragen, wenn man dropt, 3 Anfragen, wenn man rejected.
>
> Das dieser Sonderfall inzwischen einen Großteil des
> Traffics ausmacht, ist unbestritten.
Kommt drauf an, wo man im Netz ist.
Alexander Skwar
> Alexander Skwar schrieb:
>
>> · Oliver Schad <o.s...@web.de>:
>>
>>> Daraus leite ich korrekt ab, dass der Stealth-Modus nicht nur
>>> keinen Sicherheitsgewinn, sondern im Gegenteil durch die Verwendung
>>> einer PFW, eine Verringerung der Sicherheit mit sich bringt.
>>
>> Wieso bezeichnest Du iptables als PFW?
>
> Ich verstehe nicht ganz, wie du von Stealth-Modus auf Iptables kommst.
> Sag nicht, dass man diesen Unsinn da auch schon so bewirbt.
Bewirbt? Weiß nicht. Man kann aber mit iptables einen "Stealth"
Modus implementieren.
>> Wenn, aus $Grund, eh schon ein HBPF läuft, dann gibt es keine
>> Verringerung der Sicherheit.
>
> Ja, aber auch keine signifikante Erhöhung.
Wenn nicht erkennbar ist, das auf einer IP ein Rechner
ansprechbar ist, dann halte ich das schon für eine Erhöhung.
Alexander Skwar
--
Reality is nothing but a collective hunch.
-- Lily Tomlin
Le Filou
"Alexander Skwar" <alex...@skwar.name> wrote:
> Bei einem REJECT muss kein Retransmit erfolgen. Und in der Regel
> erfolgt auch keiner. Somit ist Deine Aussage falsch.
Die Praxis zeigt etwas anderes, wie dir auch von anderer Seite bestätigt
wurde. Ein 'REJECT' würde diesen unerwünschten Traffic glatt verdoppeln.
Andreas Beck
>> Ja, aber auch keine signifikante Erhöhung.
> Wenn nicht erkennbar ist, das auf einer IP ein Rechner
> ansprechbar ist, dann halte ich das schon für eine Erhöhung.
Aber doch nicht signifikant. Wenn der Rechner gegen $IRGENDWAS
verwundbar ist, wird früher oder später ein Wurm rumlaufen, der das
einfach per "blind exploit" versucht.
Die Scangeschwindigkeit sinkt dabei nicht wirklich. Die Methode "Ping
first, then try TCP connect()" ist schlicht antiquiert.
Mit der Methode von Scanrand kann man bandbreitenlimitiert nach
TCP-Ports scannen. UDP kann man eh prima blind angreifen, wie Slammer
zeigte.
Ist der Rechner gegen nix verwundbar, ist Verstecken auch nutzlos.
Bliebe also maximal der Nutzen, daß Fingerprinting erschwert wird.
Ach jo ... wenn's schee macht ...
CU, Andy
Oliver Schad
> Oliver Schad <o.s...@web.de>:
>> Alexander Skwar schrieb:
>>> Wenn, aus $Grund, eh schon ein HBPF läuft, dann gibt es keine
>>> Verringerung der Sicherheit.
>> Ja, aber auch keine signifikante Erhöhung.
> Wenn nicht erkennbar ist, das auf einer IP ein Rechner
> ansprechbar ist, dann halte ich das schon für eine Erhöhung.
Ich nicht.
mfg
Oli
Felix M. Palmen
* Oliver Schad <o.s...@web.de>:
> Alexander Skwar schrieb:
>> Wieso bezeichnest Du iptables als PFW?
netfilter ist je nach Verwendung eine vernünftig konfigurierbare PFW
oder eben auch Teil einer Firewall. iptables ist das Konfigurationstool
dazu.
> Ich verstehe nicht ganz, wie du von Stealth-Modus auf Iptables kommst.
> Sag nicht, dass man diesen Unsinn da auch schon so bewirbt.
Wenn netfilter.org nicht gerade down wäre könnte ich dir auch einen
Link zu einem sehr einfachen Beispielscript geben. Dort wird gedroppt.
DROP ist als Policy möglich, REJECT nicht (wohl weil REJECT nur für
tcp/udp definiert ist). DROP ist eben auch das einfachste, was der
Paketfilter mit nicht angenommenen Paketen tun kann.
Von "Stealth" steht da natürlich nichts :)
>> Wenn, aus $Grund, eh schon ein HBPF läuft, dann gibt es keine
>> Verringerung der Sicherheit.
>
> Ja, aber auch keine signifikante Erhöhung.
Ja, und? Je nach Randbedingungen kann es unerwünschten Traffic
verringern oder erhöhen. Bei dem was zur Zeit gerade im Internet
herumgeistert tippe auch ich eher auf verringern.
Ich DROPpe tcp/udp trotzdem nicht, denn ich biete ja auch Dienste an,
und wenn einige Ports erreichbar sind und andere mit einem DROP
reagieren ist das ja ein starkes Indiz für PFW oder ähnliches, was
eventuell einige Kiddies veranlassen könnte, den Rechner erst recht
genauer unter die Lupe zu nehmen.
Volker Birk
[something]
Wer bist Du eigentlich? Hier ist es üblich, mit Realname zu posten.
Viele Grüße,
VB.
--
"Note that Mac OS X uses the term kernel somewhat differently
than you might expect."
Apple Developer Connection, OS X Architecure
Le Filou
"Volker Birk" <bum...@dingens.org> wrote:
> Wer bist Du eigentlich? Hier ist es üblich, mit Realname zu posten.
Was soll dein Offtopic-Geschwätz? Hier ist es üblich, über Sachthemen zu
diskutieren. Piss off, Netcop!
Volker Birk
> > Wer bist Du eigentlich? Hier ist es üblich, mit Realname zu posten.
> Was soll dein Offtopic-Geschwätz? Hier ist es üblich, über Sachthemen zu
> diskutieren. Piss off, Netcop!
*PLONK*
Andreas Beck
*PLONK* Nicht wegen Realname, sondern wegen unglaublichem Ton.
Won't CU, Andy
Ansgar -59cobalt- Wiechers
>
> Was soll dein Offtopic-Geschwätz? Hier ist es üblich, über Sachthemen
> zu diskutieren. Piss off, Netcop!
Du hattest Deine Chance.
cu
59cobalt
--
"Those who would give up liberty for a little temporary safety
deserve neither liberty nor safety, and will lose both."
--Benjamin Franklin
Alexander Skwar
> Was soll dein Offtopic-Geschwätz? Hier ist es üblich, über Sachthemen zu
> diskutieren. Piss off, Netcop!
Ach, danke das Du mich daran erinnert hast, das pseudonyme Poster
zu plonken sind.
Alexander Skwar
--
"The first rule of magic is simple. Don't waste your time waving your
hands and hoping when a rock or a club will do."
-- McCloctnik the Lucid
Juergen Ilse
... und Mailadresse, die keine Mails annimmt in Kombination mit
fehlendem "reply-to" ... Ich schliesse mich an.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Andreas Kohlbach
>
> Le Filou <loca...@nurfuerspam.de>:
>
>> Was soll dein Offtopic-Geschwätz? Hier ist es üblich, über Sachthemen zu
>> diskutieren. Piss off, Netcop!
>
> Ach, danke das Du mich daran erinnert hast, das pseudonyme Poster
> zu plonken sind.
Um das vielleicht zu automatisieren, könnte man neben den
"Realnamenlosen" vielleicht auch noch auf alles filtern, was weniger als
zwei Buchstaben im ersten Wort hat. Ich glaube nicht, dass es viele Leute
gibt, deren wirklicher Vorname zwei Buchstaben hat. Und wenn doch
(vielleicht einige Asiaten?), könnte man von den wenigen besser eine
Ausnahmeregel erstellen, diese hochzuscoren, als einzelnd auf die anderen
Deppen zu filtern.
Keine Ahnung, ob Knode Regex kann. Wenn ja, würde ich mich über ein
Beispiel zum "Realnamenfiltern" freuen.
Das ist vermutlich besser in der Newsreadergruppe aufgehoben. F'up dcsn.
--
Andreas
Die FAQ dieser Gruppe unter http://www.stud.tu-ilmenau.de/~traenk/dcsm.htm
Linkliste zum Thema Computersicherheit http://www.linkblock.de/