Deny / Reject - Problem
![Urs [Ayahuasca] Traenkner's profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Urs [Ayahuasca] Traenkner
tut mir leid, diese daemliche Frage zu stellen, aber ich
stecke grad an anderer Stelle bei der Problematik, jemandem
erklaeren zu wollen, warum es sinnlos ist, Portscans mit
reject anstatt deny zu versehen. Also rein prinzipiell ist
es mir klar (Timeout = Bandbreitenverschwendung), aber ich
kriege das nicht so richtig sinnvoll ausformuliert :(
Kann mir jemand unter die Arme greifen? URL, Msg-ID oder
sowas... Kann mich daran entsinnen, dass schon gelesen zu
haben hier und an anderen Stellen, aber ich find's nimmer.
Gruss Urs...
--
"Es geht hier nicht um Firewalls."
Sebastian Schlueter in de.comp.security.firewalls
Rainer Weikusat
> warum es sinnlos ist, Portscans mit
> reject anstatt deny zu versehen.
"Warum soll ich jemandem, mit dem ich nicht reden will, mitteilen, daß
ich da bin?"
--
SIGSTOP
Heiko Ernst
Wir wollen uns weigern, das zu sagen, was wir nicht denken.
Solschenizyn, Alexander Issajewitsch
Geburtstag hat heute: Solschenizyn, Alexander Issajewitsch
(11.12.1918)
Funktion: Schriftsteller, "Ein Tag im Leben des Iwan Denissowitsch", "Der
erste Kreis der Hölle", "Krebsstation", "Der Archipel GULag", Nobelpreis
für Literatur/1970, wurde 1974 aus der Sowjetunion ausgewiesen und kehrte
1994 zurück (Rußland, 1918).
Heute ist: Montag, der 11. Dezember 2000
Der 346. Tag des Jahres
Der 730467. Tag unserer Zeitrechnung
Urs [Ayahuasca] Traenkner
Hoppla. Genau das sollte es nicht sein *schaem*
richtig:
"warum es sinnlos ist, deny statt reject zu verwenden"
Verdammt. Ich kann ja noch nichtmal die Frage richtig
formulieren :(
Thomas Kuehnert
>
> Mahlzeit,
>
also, ich habe mich mal mit Lutz "gestritten" er wollte REJECT,
ich wollte DENY
nach einigen Versuchen bin ich (nach seiner Antwort) selbst darauf
gegommen, dass DENY alles ausbremst, weil TIMEOUT ( evtl mal >=3)
abgewartet wird.
Eigenes Bsp. ftp - Port 113 DENY - dauert ewig -
gleichzeitig 3 Anfragen auf 113 bei mir. -> den auf REJECT gesetzt
gleiche URL -> geht schnell --> _meine_ Vorstellung falsch
Lernefekt erreicht - danke Lutz
Gruss Tommy
Carsten Schütte
> Verdammt. Ich kann ja noch nichtmal die Frage richtig
> formulieren :(
kriegst du vielleicht hin und wieder sowas wie 42 zur antwort?
SCNR.
carsten.
Lars Gebauer
> nach einigen Versuchen bin ich (nach seiner Antwort) selbst darauf
> gegommen, dass DENY alles ausbremst, weil TIMEOUT ( evtl mal >=3)
> abgewartet wird.
Genau.
> Eigenes Bsp. ftp - Port 113 DENY - dauert ewig -
> gleichzeitig 3 Anfragen auf 113 bei mir.
Das waren Anfragen nach einer authentication. Da das bei Dir (wahr-
scheinlich) nicht laeuft gingen die Anfragen in's Leere, die TIMEOUTs
wurden abgewartet...
> -> den auf REJECT gesetzt
> gleiche URL -> geht schnell
...waehrend REJECT klipp & klar & sofort sagt: Gibt's hier nicht.
--
toDuj 'oS rol.
Ein Bart ist ein Symbol des Mutes.
Sebastian Schlüter
>Eigenes Bsp. ftp - Port 113 DENY - dauert ewig -
>gleichzeitig 3 Anfragen auf 113 bei mir. -> den auf REJECT gesetzt
>gleiche URL -> geht schnell --> _meine_ Vorstellung falsch
Ist es mit iptables machbar, durch die Option RELATED ein REJECT auf
Ident-Anfragen selektiv nur für diejenigen Server zu verschicken, mit
denen man eine Verbindung hat?
Gruß Sebastian
Disclaimer: Ich will nicht den Gebrauch von DENY favorisieren.
Bernd Eckenfels
> stecke grad an anderer Stelle bei der Problematik, jemandem
> erklaeren zu wollen, warum es sinnlos ist, Portscans mit
> reject anstatt deny zu versehen. Also rein prinzipiell ist
> es mir klar (Timeout = Bandbreitenverschwendung), aber ich
> kriege das nicht so richtig sinnvoll ausformuliert :(
Hmm.. das ist nicht so trivial. Das sind sehr viele faktoren:
a) Reject hatte mal das Problem dass dies als DOS missbraucht werden konnte...
sollte dank Rate Limit behoben sein
b) Reject hat den vorteil, dass legale Verbindungen auf falsche Ports (z.b.
identd anfragen oder alte verbindungen) schneller resettet werden
c) Reect hat den Vorteil, dass man als Admin auf der Remote Seite
Netzwerkprobleme einfacher diagnostizieren kann
d) Reject hat den Nachteil, dass deine Firewall Policy etwas einfacher
auszuspähen ist.
Ich für meinen Teil mache Reject nach Intern und Deny nach extern, aber ich
weiss dass in einer Diskussion sicher beide Seiten gute Argumente für/wider
Reject vorbringen.
Übrigens verwendet Linux aus compat gruenden die falsche Deny Message.
Ausserdem gibt es auch die Möglichkeit RST zu schicken (auf Freefire gibt es
einen Daemon).
Das Thema Banbreite spielt hier weniger eine Rolle. Durch das Rate Limit
sind auch die Spoof Angriffe hier weniger kritisch. Eventuell sollte man die
Rate Limit Werte fuer ICMP etwas strenger einstellen als per RFC, weiss aber
nicht ob das speziell fuer die REJECT Pakete geht.
Gruss
Bernd
Bernd Eckenfels
> ...waehrend REJECT klipp & klar & sofort sagt: Gibt's hier nicht.
Wobei man natuerlich einfacherweise identd immer rejected, ebenso netbios,
und die anderen Ports dann auch Denyen könnte, da die Timeouts dann meistens
unkritischer sind.
Gruss
Bernd
Bernd Eckenfels
> Ist es mit iptables machbar, durch die Option RELATED ein REJECT auf
> Ident-Anfragen selektiv nur für diejenigen Server zu verschicken, mit
> denen man eine Verbindung hat?
Hmm.. interessanter Ansatz, aber wozu sich die Mühe machen?
Gruss
Bernd
Ulrich Eckhardt
>
> Thomas Kuehnert <tkue...@t-online.de> schrieb unter anderem:
>
> >Eigenes Bsp. ftp - Port 113 DENY - dauert ewig -
> >gleichzeitig 3 Anfragen auf 113 bei mir. -> den auf REJECT gesetzt
> >gleiche URL -> geht schnell --> _meine_ Vorstellung falsch
>
> Ist es mit iptables machbar, durch die Option RELATED ein REJECT auf
> Ident-Anfragen selektiv nur für diejenigen Server zu verschicken, mit
> denen man eine Verbindung hat?
AFAIK bezieht sich RELATED nur auf zu Verbindungen
zugehörige ICMP messages. Das wird also wohl nich klappen.
Ist meiner Meinung nach auch nicht nötig, da die betreffenden
Rechner ohnehin meist irgend einen Service anbieten, mit dem
man die Existenz des Rechners testen kann.
Grüße
Uli
--
Ulrich Eckhardt Tr@nscom
http://www.uli-eckhardt.de http://www.transcom.de
Lagerstraße 11-15 A8
64807 Dieburg Germany
Daniel Schmidt
"Urs [Ayahuasca] Traenkner" <Urs.Tr...@rz.tu-ilmenau.de> schrieb
im Newsbeitrag news:3A353262...@rz.tu-ilmenau.de...
> "warum es sinnlos ist, deny statt reject zu verwenden"
[Für mich zum Verständnis umformuliert]
Warum es besser ist, REJECT statt DENY zu verwenden?
<Beispiel aus dem Leben>
Sieh das Ganze doch so, wie in einer offenen Beziehung:
Es ist besser seinem Partner direkt zu sagen, daß man über ein
bestimmtes Thema nicht sprechen möchte (REJECT). => der Partner weiß
sofort, was Sache ist und und kann dann ohne Zeitverzögerung seine
Entscheidung darüber treffen, ob er die Beziehung fortsetzen möchte
oder nicht.
Geht man auf ein Thema allerdings gar nicht ein (DENY) und stellt die
Ohren auf Durchzug, kostet das a) einem selber Zeit dem Geschwafel des
Partners zuzuhören und b) dem Partner ebenfalls Zeit; er möchte
nämlich ein für ihn wichtiges Thema/Problem loswerden, und hätte das
dann ja wohl besser woanders getan.
</Beispiel aus dem Leben>
<Anderes Beispiel aus dem Leben>
Du gehst durch die Einkaufstraße deiner Stadt, und irgendein "Penner"
quatscht dich an, und will 'nen Euro.
Hier könnte man sagen "Ach ne, habe selbst kein Geld" (REJECT) oder es
einfach ignorieren.
</Anderes Beispiel aus dem Leben>
Zurück zum Thema ipchains:
Kann man das so pauschal überhaupt sagen, daß REJECT sinnvoller als
DENY ist?
-ds-
Lutz Donnerhacke
>[Für mich zum Verständnis umformuliert]
>Warum es besser ist, REJECT statt DENY zu verwenden?
Danke. In die FAQ übernommen.
http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Deny
Ist REJECT oder DENY sinnvoller?
Als REJECT bezeichnet man die aktive Ablehnung einer
Verbindungsanfrage mit einem ICMP Paket vom Inhalt "Der Admin
hat's verboten" oder "Dienst nicht verfügbar".
Als DENY bezeichnet man das kommentarlose Wegwerfen der
Verbindungsanfrage. Damit läuft der Anfragende in einen
Timeout.
Admins, die sich über Script Kiddies ärgern, glauben oft, diese
durch DENY aufhalten zu können. Dies ist jedoch falsch. Es ist
problemlos möglich, viele tausend Scans gleichzeitig zu starten
und so auf alle Timeout gleichzeitig zu warten. Ein Scanner
wird so nicht gebremst. Andererseits bremst man mit DENY alle
legitimen Nutzer und Server massiv aus. Das betrifft
insbesondere die ident Anfragen.
Ident dient dazu, dem Admin eines ordentlich gepflegten Systems
eine Hilfestellung bei der Identifizierung seiner, sich daneben
benehmenden Nutzer zur geben. DENY für ident bewirkt nur, daß
diese Hilfestellungen bei anderen Servern nicht mehr gesammelt
werden und ist so aktiver Spammer/Scriptkiddy-Schutz.
Sieh das Ganze doch so, wie in einer offenen Beziehung:
Es ist besser seinem Partner direkt zu sagen, daß man über ein
bestimmtes Thema nicht sprechen möchte (REJECT): Der Partner
weiß sofort, was Sache ist und und kann dann ohne
Zeitverzögerung seine Entscheidung darüber treffen, ob er die
Beziehung fortsetzen möchte oder nicht.
Geht man auf ein Thema allerdings gar nicht ein (DENY) und
stellt die Ohren auf Durchzug, kostet das a) einem selber Zeit
dem Geschwafel des Partners zuzuhören und b) dem Partner
ebenfalls Zeit; er möchte nämlich ein für ihn wichtiges
Thema/Problem loswerden, und hätte das dann ja wohl besser
woanders getan.
Ein anderes Beispiel aus dem Leben:
Du gehst durch die Einkaufstraße deiner Stadt, und irgendein
"Penner" quatscht dich an, und will 'nen Euro. Hier könnte man
sagen "Ach ne, habe selbst kein Geld" (REJECT) oder es einfach
die fortgesetzte Bettelei ertragen.
Urs [Ayahuasca] Traenkner
> Andererseits bremst man mit DENY alle
> legitimen Nutzer und Server massiv aus. Das betrifft
> insbesondere die ident Anfragen.
Ergo sollte man in Hinsicht auf ident deny vermeiden.
> DENY für ident bewirkt nur, daß diese
> Hilfestellungen bei anderen Servern nicht mehr gesammelt
> werden und ist so aktiver Spammer/Scriptkiddy-Schutz.
Ergo sollte man in Hinsicht auf ident deny favorisieren.
Wo steckt der Fehler?
Lutz Donnerhacke
>Lutz Donnerhacke wrote:
>> DENY für ident bewirkt nur, daß diese Hilfestellungen bei anderen
>> Servern nicht mehr gesammelt werden und ist so aktiver
>> Spammer/Scriptkiddy-Schutz.
>
>Ergo sollte man in Hinsicht auf ident deny favorisieren.
>
>Wo steckt der Fehler?
Wenn Du als Schutzpatron für Spammer und Scriptkiddies auftreten willst,
nimm DENY.
Urs [Ayahuasca] Traenkner
> * Urs [Ayahuasca] Traenkner wrote:
> >Lutz Donnerhacke wrote:
> >> DENY für ident bewirkt nur, daß diese Hilfestellungen bei anderen
> >> Servern nicht mehr gesammelt werden und ist so aktiver
> >> Spammer/Scriptkiddy-Schutz.
> >
> >Ergo sollte man in Hinsicht auf ident deny favorisieren.
> >
> >Wo steckt der Fehler?
> Wenn Du als Schutzpatron für Spammer und Scriptkiddies auftreten willst,
> nimm DENY.
Ah!
Ich hatte "aktiver Spammer/Scriptkiddy-Schutz" so
verstanden, dass man vor diesen geschuetzt ist, waehrend es
so gemeint ist, dass man auf diesem Wege diese schuetzt.
Ist etwas zweideutig. Ich wuerde folgende Aenderung
vorschlagen:
DENY für ident bewirkt nur, daß diese Hilfestellungen bei
anderen Servern nicht mehr gesammelt werden und ist so
aktiver Schutz von Spammern / Scriptkiddies, da
Informationen ueber "Angriffe" nicht protokolliert werden.
Statt Angriffe vielleicht auch "exzessive Portscans" oder
sowas.
Nur ein Vorschlag.
Nicolas Iselin
>
> * Urs [Ayahuasca] Traenkner wrote:
> >Lutz Donnerhacke wrote:
> >> DENY für ident bewirkt nur, daß diese Hilfestellungen bei anderen
> >> Servern nicht mehr gesammelt werden und ist so aktiver
> >> Spammer/Scriptkiddy-Schutz.
> >
> >Ergo sollte man in Hinsicht auf ident deny favorisieren.
> >
> >Wo steckt der Fehler?
>
> Wenn Du als Schutzpatron für Spammer und Scriptkiddies auftreten willst,
> nimm DENY.
Na, Lutz, jetzt warst du einmal zu knapp :-) Erst mit deinem zweiten
Posting wird klar, dass du mit Spammer-Schutz ein Schutz der Spammer
und nicht ein Schutz vor Spammern gemeint hast ... (Hiess das nicht
mal genitivus objectivus/subjectivus oder so ähnlich ?)
Nicolas
Lutz Donnerhacke
>Lutz Donnerhacke wrote:
>> Wenn Du als Schutzpatron für Spammer und Scriptkiddies auftreten willst,
>> nimm DENY.
>
>Na, Lutz, jetzt warst du einmal zu knapp :-) Erst mit deinem zweiten
>Posting wird klar, dass du mit Spammer-Schutz ein Schutz der Spammer
>und nicht ein Schutz vor Spammern gemeint hast ... (Hiess das nicht
>mal genitivus objectivus/subjectivus oder so ähnlich ?)
Ich sollte FAQs in Suomi schreiben. Fixed.
Daniel Schmidt
"Lutz Donnerhacke" <lu...@iks-jena.de> schrieb im Newsbeitrag
news:slrn93bs4...@taranis.iks-jena.de...
> * Daniel Schmidt wrote:
> >[Für mich zum Verständnis umformuliert]
> >Warum es besser ist, REJECT statt DENY zu verwenden?
>
> Danke. In die FAQ übernommen.
> http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Deny
Huch. Aber wenn's hilft, geht das in Ordnung.
-ds-
H. Gremming
Zusatzfrage: was ist mit icmp ? REJECT oder DENY ?
Ich tendiere da mehr zu DENY, z.B. bei Typ 5 (Redirect).
Ach ja, wo wir schon dabei sind: wie ist das mit Typ 4 (Source Quensch),
nehme ich eigentlich nur von meinem Provider an, bekomme ich
aber hin und wieder auch mal von wildfremden Rechnern. Was ist da los ?
Heinrich
--
http://felix2.2y.net/
Thomas Kaemer
>
> Zusatzfrage: was ist mit icmp ? REJECT oder DENY ?
> Ich tendiere da mehr zu DENY, z.B. bei Typ 5 (Redirect).
man ipchains:
(Note that DENY and REJECT are the same for ICMP packets)
CU Thomas
Ulrich Eckhardt
>
> Zusatzfrage: was ist mit icmp ? REJECT oder DENY ?
> Ich tendiere da mehr zu DENY, z.B. bei Typ 5 (Redirect).
Hi,
laut RFC's antwortet man entweder korrekt oder man ignoriert
das ICMP packet. Reject ist also sinnlos bei ICMP.
> Ach ja, wo wir schon dabei sind: wie ist das mit Typ 4 (Source Quensch),
> nehme ich eigentlich nur von meinem Provider an, bekomme ich
> aber hin und wieder auch mal von wildfremden Rechnern. Was ist da los ?
Harmlos,das besagt lediglich, dass ein Router nicht mehr
alle Packete bearbeiten konnte, die er erhalten hat.
Juergen Ilse
Daniel Schmidt <dsm...@gmx.net> wrote:
> [Für mich zum Verständnis umformuliert]
> Warum es besser ist, REJECT statt DENY zu verwenden?
> <Beispiel aus dem Leben>
> Sieh das Ganze doch so, wie in einer offenen Beziehung:
> Es ist besser seinem Partner direkt zu sagen, daß man über ein
> bestimmtes Thema nicht sprechen möchte (REJECT). => der Partner weiß
> sofort, was Sache ist und und kann dann ohne Zeitverzögerung seine
> Entscheidung darüber treffen, ob er die Beziehung fortsetzen möchte
> oder nicht.
> Geht man auf ein Thema allerdings gar nicht ein (DENY) und stellt die
> Ohren auf Durchzug, kostet das a) einem selber Zeit dem Geschwafel des
> Partners zuzuhören und b) dem Partner ebenfalls Zeit; er möchte
> nämlich ein für ihn wichtiges Thema/Problem loswerden, und hätte das
> dann ja wohl besser woanders getan.
> </Beispiel aus dem Leben>
Eben das kann aber der sinn und Zweck des deny sein.
Evt. kann damit ein unerwuenschter "Port-Scan" so sehr verzoegert werden,
dass ein potentieller Angreifer vorzeitig aufgibt (nunja, vielleicht nicht
SOOO wahrscheinlich), zumindest verzoegert er aber die Aktion (und mal
ganz ehrlich: welches Interesse sollte ich daran haben, einem potentiellen
Angreifer einen schnelleren Port-Scan zu ermoeglichen?).
Wenn es sich um Dienste handelt, an denen niemand etwas verloren hat,
ist nicht einzusehen, warum man nicht die Tests auf solche Dienste ggfs.
so weit wie moeglich erschweren oder verzoegern sollte (zumindest meiner
Meinung nach). Im Grunde genommen sind doch die "Teergruben" bei Mail
nicht unbedingt etwas grundsaetzlich anderes, oder?
Tschuess,
Juergen Ilse (il...@asys-h.de)
--
Eingedeutschte Fehlermeldungen sind doch etwas | Juergen Ilse
schoenes: "Kein Weltraum links auf dem Geraet" | Internet POP Hannover
-----------------------------------------------------| Vahrenwalder Str. 205
Neu in de.comp.os.unix.linux.*? Lies die infos-Gruppe| 30165 Hannover
Juergen Ilse
Urs [Ayahuasca] Traenkner <Urs.Tr...@rz.tu-ilmenau.de> wrote:
> Lutz Donnerhacke wrote:
>> Andererseits bremst man mit DENY alle
>> legitimen Nutzer und Server massiv aus. Das betrifft
>> insbesondere die ident Anfragen.
> Ergo sollte man in Hinsicht auf ident deny vermeiden.
>> DENY für ident bewirkt nur, daß diese
>> Hilfestellungen bei anderen Servern nicht mehr gesammelt
>> werden und ist so aktiver Spammer/Scriptkiddy-Schutz.
> Ergo sollte man in Hinsicht auf ident deny favorisieren.
Nein. Mit "scriptkiddie/Spammer-Schutz! ist hier nicht das schuetzen
dieses Personenkreises sondern der Schutz VOR diesen Personen gemeint.
> Wo steckt der Fehler?
In der falschen Interpretation des Begriffs "Spammer/Scriptkiddy-Schutz".
Moeglicherweise sollte man hier die formulierung aendern...
Tschuess,
Juergen Ilse (il...@asys-h.de)
--
Eingedeutschte Fehlermeldungen sind doch etwas | Juergen Ilse
schoenes: "Fundamentfehler" statt "socket error" | Internet POP Hannover
Lutz Donnerhacke
>Evt. kann damit ein unerwuenschter "Port-Scan" so sehr verzoegert werden,
>dass ein potentieller Angreifer vorzeitig aufgibt (nunja, vielleicht nicht
>SOOO wahrscheinlich), zumindest verzoegert er aber die Aktion (und mal
>ganz ehrlich: welches Interesse sollte ich daran haben, einem potentiellen
>Angreifer einen schnelleren Port-Scan zu ermoeglichen?).
Lies die FAQ. Es interessiert den Angreifer einen Feuchten.
Rainer Weikusat
> Danke. In die FAQ übernommen.
> http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Deny
>
> Ist REJECT oder DENY sinnvoller?
Vorbemerkung: Wenigstens Linux schickt in so einem Fall
port unreachable, nicht administratively prohibited.
> Admins, die sich über Script Kiddies ärgern, glauben oft, diese
> durch DENY aufhalten zu können.
Admins, die sich über sinnlosen Traffic ärgern, glauben gelegentlich,
auf unerwünschter Verbindungsversuche mit gar keinem Echo zu
reagieren, sei auch ganz ok. Warum soll ich meinen Computer für 5000
sinnlose connects 5000 ICMPs nach Weiß-der-Geier-wohin (IP spoofing
anyone) schicken lassen, nur um den Rechner dort auch noch ein bißchen
auf Trab zu halten und gleichzeitig aus voller Kehle "Ich bin hier!
Ich bin hier!" zu brüllen?
Mir bringt das gar nichts.
> Dies ist jedoch falsch.
Dies ist praktisch leider nicht falsch (pure Empirie allerdings):
Sobald ich mich irgendwie melde, fangen die Leute am anderen Ende an,
sich mehr Mühe zu geben. Falls jemand DTAG-BB1 durchscannt, wird er
sich im ersten Durchlauf darauf konzentrieren, zu ermitteln, welche IP
zZt tatsächlich von irgendwas benutzt wird.
> Andererseits bremst man mit DENY alle legitimen Nutzer und
> Server massiv aus.
'legitimer Nutzen' <=> 'erlaubter Port'. Der Rest ist Müll und kommt
in die Tonne.
> Ident dient dazu, dem Admin eines ordentlich gepflegten Systems
> eine Hilfestellung bei der Identifizierung seiner, sich daneben
> benehmenden Nutzer zur geben.
'identd' dient dazu, FTP- und SMTP-Server von überall auf der Welt mit
sinnlosem, inhaltlich nicht verifizierbarem Datenmüll zu beglücken,
sowie den Leuten, die auf diese Server zugreifen, mit Bitten um das
Herausgeben der erwähnten Nullinformation auf den Wecker zu fallen.
Eine gute Methode, das zeitsparend zu konterkarieren, besteht darin,
den auth-Port offen zu lassen, den identd selber aber abzudrehen.
-------------------- nmap(1) --------------
| -I This turns on TCP reverse ident scanning. As noted by Dave
| Goldsmith in a 1996 Bugtraq post, the ident protocol (rfc 1413)
| allows for the disclosure of the username that owns any process
| connected via TCP, even if that process didn't initiate the
| connection.
----------------------------------------------
> DENY für ident bewirkt nur, daß diese Hilfestellungen bei anderen
> Servern nicht mehr gesammelt werden und ist so aktiver
> Spammer/Scriptkiddy-Schutz.
ALLOW für identd bewirkt, daß das, was ein auf diesem Port laufender
Server an Informationen herausrückt, 'irgendwo' als goldene Wahrheit
abgespeichert wird. Ein zwingender Zusammenhang mit realen Ereignissen
auf der fraglichen Maschine besteht nicht.
> Sieh das Ganze doch so, wie in einer offenen Beziehung:
Beziehung impliziert bekannte Partner.
--
SIGSTOP
Lutz Donnerhacke
>> DENY für ident bewirkt nur, daß diese Hilfestellungen bei anderen
>> Servern nicht mehr gesammelt werden und ist so aktiver
>> Spammer/Scriptkiddy-Schutz.
>
>ALLOW für identd bewirkt, daß das, was ein auf diesem Port laufender
>Server an Informationen herausrückt, 'irgendwo' als goldene Wahrheit
>abgespeichert wird. Ein zwingender Zusammenhang mit realen Ereignissen
>auf der fraglichen Maschine besteht nicht.
Du hast Ident nicht verstanden. Lies Deinen Leitner hier in der Gruppe.
Bernd Eckenfels
> Vorbemerkung: Wenigstens Linux schickt in so einem Fall
> port unreachable, nicht administratively prohibited.
Kann man bei netfilter einstellen. Da kann man sogar Echo Reply auf ein Echo
Request ICMP schicken, oder ein TCP RST.
> anyone) schicken lassen, nur um den Rechner dort auch noch ein bißchen
> auf Trab zu halten und gleichzeitig aus voller Kehle "Ich bin hier!
> Ich bin hier!" zu brüllen?
> Mir bringt das gar nichts.
Deinen Usern schon. Denn die freuen sich über schnelle Logins mein FTP oder
IRC servern oder ueber schnelle Mails.
Gruss
Bernd
Rainer Weikusat
> * Rainer Weikusat wrote:
> >ALLOW für identd bewirkt, daß das, was ein auf diesem Port laufender
> >Server an Informationen herausrückt, 'irgendwo' als goldene Wahrheit
> >abgespeichert wird. Ein zwingender Zusammenhang mit realen Ereignissen
> >auf der fraglichen Maschine besteht nicht.
>
> Du hast Ident nicht verstanden. Lies Deinen Leitner hier in der
> Gruppe.
--------------------------------------
#!/bin/bash
#
exec 3<&0
cut -d: -f1 /etc/passwd | tr '[:space:]' ' ' | \
(
declare -a users;
N=`wc -l </etc/passwd`
read -a users
exec <&3
while true;
do
read input
echo "$input : UNIX : USERID : ${users[$(($RANDOM % $N))]}"
done
)
----------------------------------------
Du hast ein übermäßiges Gottvertrauen.
--
SIGSTOP
Rainer Weikusat
> Rainer Weikusat <weik...@mail.uni-mainz.de> wrote:
> > Vorbemerkung: Wenigstens Linux schickt in so einem Fall
> > port unreachable, nicht administratively prohibited.
>
> Kann man bei netfilter einstellen. Da kann man sogar Echo Reply auf ein Echo
> Request ICMP schicken, oder ein TCP RST.
Das hört sich gut an.
>
> > anyone) schicken lassen, nur um den Rechner dort auch noch ein bißchen
> > auf Trab zu halten und gleichzeitig aus voller Kehle "Ich bin hier!
> > Ich bin hier!" zu brüllen?
>
> > Mir bringt das gar nichts.
>
> Deinen Usern schon. Denn die freuen sich über schnelle Logins mein FTP oder
> IRC servern oder ueber schnelle Mails.
Ein Server, der sich zur Informationsermittlung darauf verläßt, was
irgendein Admin irgendwo auf der Welt auf einem bestimmten Port laufen
läßt, hat ein Konfigurationsproblem, denn dem kann ich alles schicken,
was ich möchte (das machen AFAIK zB die meisten Win-IRCs).
Für IRC stellt das allerdings ein Ärgernis dar, sonst schadet es nicht
wirklich:
| [rw@winter]:/tmp $ipch-select 'dport 113' /var/log/syslog.0
| Dec 12 12:43:24 winter kernel: 134.93.8.31:43587 134.93.42.91:113
| Dec 12 13:30:53 winter kernel: 209.10.41.242:2700
| Dec 12 13:31:01 winter kernel: 131.159.72.23:2715
| Dec 12 23:31:40 winter kernel: 134.93.8.31:37263
Wie man sieht, sind sie alle brav ;-).
--
SIGSTOP
Dietz Proepper
"Der Leitner" hat als Argument hierfür gebracht daß Ident nützlich sei
wenn "von einem Shellaccount jemand spammt". Wenn das die einzige
Argumentklasse ist dann muß ich zugeben daß mich dies in etwa sosehr
juckt wie unter nmap abstürzende Windowsrechner.
Irgendwer ist nicht in der Lage, seine Systeme ausreichend unter
Kontrolle zu haben & daraus wird für alle anderen eine
Handlungsvorgabe gebastelt? Sorry, Lutz, das ist lächerlich.
Dietz
Lutz Donnerhacke
>lu...@iks-jena.de (Lutz Donnerhacke) writes:
>> * Rainer Weikusat wrote:
>> >ALLOW für identd bewirkt, daß das, was ein auf diesem Port laufender
>> >Server an Informationen herausrückt, 'irgendwo' als goldene Wahrheit
>> >abgespeichert wird. Ein zwingender Zusammenhang mit realen Ereignissen
>> >auf der fraglichen Maschine besteht nicht.
>>
>> Du hast Ident nicht verstanden. Lies Deinen Leitner hier in der
>> Gruppe.
>
>Du hast ein übermäßiges Gottvertrauen.
Und Du hast ident nicht verstanden. Es dient dazu, dem Admin des System beim
identifizieren zu helfen. Betreibst Du als Admin diesen Fake identd, so ist
das auschließlich Dein Problem.
Lutz Donnerhacke
>Bernd Eckenfels <ec...@lina.inka.de> writes:
>> Deinen Usern schon. Denn die freuen sich über schnelle Logins mein FTP oder
>> IRC servern oder ueber schnelle Mails.
>
>Ein Server, der sich zur Informationsermittlung darauf verläßt, was
>irgendein Admin irgendwo auf der Welt auf einem bestimmten Port laufen
>läßt, hat ein Konfigurationsproblem, denn dem kann ich alles schicken,
>was ich möchte (das machen AFAIK zB die meisten Win-IRCs).
Du hast ident nicht verstanden, es hilft nicht dem Abfragenden, sondern dem
Abgefragten.
Lutz Donnerhacke
>Lutz Donnerhacke wrote:
>>Du hast Ident nicht verstanden. Lies Deinen Leitner hier in der Gruppe.
>
>"Der Leitner" hat als Argument hierfür gebracht daß Ident nützlich sei
>wenn "von einem Shellaccount jemand spammt". Wenn das die einzige
>Argumentklasse ist dann muß ich zugeben daß mich dies in etwa sosehr juckt
>wie unter nmap abstürzende Windowsrechner. Irgendwer ist nicht in der
>Lage, seine Systeme ausreichend unter Kontrolle zu haben & daraus wird für
>alle anderen eine Handlungsvorgabe gebastelt? Sorry, Lutz, das ist
>lächerlich.
Du generalisiertst unzulässig.
Stefan Heinecke
>Mir bringt das gar nichts.
Stimmt, denn Du verweschelst Ursache und Wirkung.
>ALLOW für identd bewirkt, daß das, was ein auf diesem Port laufender
>Server an Informationen herausrückt, 'irgendwo' als goldene Wahrheit
>abgespeichert wird. Ein zwingender Zusammenhang mit realen Ereignissen
>auf der fraglichen Maschine besteht nicht.
Wirf einen Blick auf include/linux/acct.h
Lars Gebauer
> lu...@iks-jena.de (Lutz Donnerhacke) writes:
>> Du hast Ident nicht verstanden. Lies Deinen Leitner hier in der
>> Gruppe.
>
> --------------------------------------
> #!/bin/bash
> #
> exec 3<&0
[...]
Und genau damit hast Du Dir selber in den Fuss geschossen. Wenn Du
nur Muell lieferst kann Dir natuerlich auch niemand helfen _Deine_
Boesen Buben[tm] leichter zu fangen. Du machst Dir Deine Arbeit un-
noetig schwer.
> Du hast ein übermäßiges Gottvertrauen.
Du solltest Daten liefern denen _Du_ vertraust. Mit dem Lieben Gott
hat das nix zu tun.
--
Heghlu'Dl' mobbe'lu'chugh QaQqu' Hegh wanl'.
Der Tod ist eine Erfahrung die man am besten teilt.
Dietz Proepper
>* Rainer Weikusat wrote:
>>lu...@iks-jena.de (Lutz Donnerhacke) writes:
>>> * Rainer Weikusat wrote:
>>> >ALLOW für identd bewirkt, daß das, was ein auf diesem Port laufender
>>> >Server an Informationen herausrückt, 'irgendwo' als goldene Wahrheit
>>> >abgespeichert wird. Ein zwingender Zusammenhang mit realen Ereignissen
>>> >auf der fraglichen Maschine besteht nicht.
>>>
>>> Du hast Ident nicht verstanden. Lies Deinen Leitner hier in der
>>> Gruppe.
>>
>[Beispiel eines Fake identd]
>>Du hast ein übermäßiges Gottvertrauen.
>
>Und Du hast ident nicht verstanden. Es dient dazu, dem Admin des System beim
>identifizieren zu helfen.
Lutz, vertrau' uns, auch andere können RFCs lesen. Nur scheint es
Leute zu geben die den RFC lesen, ihn nochmal lesen, schmunzeln und
für sich entscheiden daß derartiges zu unverläßlich ist um es zu
verwenden.
Ein Admin der ident-Lookups vom fernen Ende benötigt um seine Systeme
zu überwachen ist mit Verlaub ganz nahe an der vorsätzlichen Inkompetenz.
Ident ist ja ganz nett wenn ich Probleme auf Maschinen die ich
vollständig überblicke habe. Aber die "Forderung" aufzustellen, jeder
solle diesen Dienst "unterstützen" (d.h. implementieren oder rejecten)
ist imnsho bestenfalls als Windel für Inkompetenz sinnvoll. Und wenn
wir in den Bereich kommen, derartiges Nichtselberaufpassenkönnen zu
fördern dann fordere ich hiermit, "Portscanner an die Wand". Sind ja
auch schon Rechner wegen sowas abgestürzt.
Dietz
Dietz Proepper
Wo?
Mit Verlaub, auch wenn ich an der Stelle ein ausreichend sozialer
Mensch bin zu rejecten, es ändert nix daran daß ich die Begründung für
ausgesprochen lächerlich um nicht zu sagen an den Haaren herbeigezogen
halte.
Ich wart' ja nur darauf daß mir mal jemand sagt "hätten's ident
gefragt, dann könnt' ma ihnen jetzt sagen wer das war".
Dietz
Rainer Weikusat
> Ein Server, der sich zur Informationsermittlung darauf verläßt,
Um das etwas auszuführen: Kein remote laufender Dienst kann ermitteln,
welchem meiner lokalen Benutzer eine bestimmte TCP-Verbindung
gehört. Er kann einen Textstring abfragen, den ich mich ihm zu
schicken aus einem beliebigen Grund entschlossen habe. Das ist noch
etwas nutzloser als 'daytime', denn da kann ich wenigstens zur
Überprüfung auf die Uhr sehen.
Wenn also die gewünschte Information nicht zuverlässig zu haben ist
und ich die nicht selber als uninteressant behandle (sendmail, ftp),
habe ich einfach einen zusätzlich Kanal gegraben, durch den mir jemand
Wasser in meinen Daemon leiten kann, was dann mehr oder minder
unbeabsichtigte Effekte erzielt.
Als zusätzlicher Denkanstoß:
------------------------------------
#!/bin/bash
#
if [ "$1" != "sub" ];
then
HOST=$1
export IP=`host $HOST | awk '{ print $3; }'`
export PPPID=$$
declare -i PORT=1;
export PORT
while [ $PORT -lt 1024 ];
do
socket -r -p "$0 sub" $IP $PORT 2>/dev/null
PORT=$(($PORT + 1))
done
else
LOCAL_PORT=`netstat --ip -n | awk "/:[0-9]+.*$IP:$PORT/{ print \\$4; }" | cut -d: -f2`
echo "$PORT, $LOCAL_PORT" | nc $IP 113 >/proc/$PPPID/fd/1
kill $PPID
fi
-------------------------------------
Wen geht das warum was an?
F'up2 dcs.misc, wg allgemeinem Thema.
--
SIGSTOP
Rainer Weikusat
> # Rainer Weikusat wrote:
> > --------------------------------------
> > #!/bin/bash
> > #
> > exec 3<&0
> [...]
>
> Und genau damit hast Du Dir selber in den Fuss geschossen. Wenn Du
> nur Muell lieferst kann Dir natuerlich auch niemand helfen _Deine_
> Boesen Buben[tm] leichter zu fangen.
Meine bösen Buben stehen entweder in wtmp oder sie heißen alle root.
> > Du hast ein übermäßiges Gottvertrauen.
>
> Du solltest Daten liefern denen _Du_ vertraust.
Ich will aber nicht.
--
SIGSTOP
Rainer Weikusat
> >irgendein Admin irgendwo auf der Welt auf einem bestimmten Port laufen
> >läßt, hat ein Konfigurationsproblem, denn dem kann ich alles schicken,
> >was ich möchte (das machen AFAIK zB die meisten Win-IRCs).
>
> Du hast ident nicht verstanden, es hilft nicht dem Abfragenden, sondern dem
> Abgefragten.
Mir hilft er nichts und sonst geht das keinen was an.
--
SIGSTOP
Lutz Donnerhacke
>>Du generalisiertst unzulässig.
>
>Wo?
An der Stelle mit den Shell Accounts. Viele Server (auch unsere) haben
Dienste, die man sicher mißbrauchen kann. Mich würde dann schon
interessieren, welche Nutzerrechte der Prozeß hatte. Exploit in dem Sinne,
daß man zwar kein root bekommt, aber einen anderes Program starten kann.
>Ich wart' ja nur darauf daß mir mal jemand sagt "hätten's ident gefragt,
>dann könnt' ma ihnen jetzt sagen wer das war".
Das habe ich schon mal jemanden geschrieben.
Thomas Kaemer
>
> Ich will aber nicht.
Dann sag das doch: reject
CU Thomas
Lutz Donnerhacke
Und weil Du selbst keinen Nutzen siehst, verhinderst Du aktiv den Nutzeffekt
für Andere? Warum?
Rainer Weikusat
>
> Stimmt, denn Du verweschelst Ursache und Wirkung.
Und nun hätte ich gerne von Dir erklärt, welche Ursache ich hier mit
welcher Wirkung verwechselt habe.
> >ALLOW für identd bewirkt, daß das, was ein auf diesem Port laufender
> >Server an Informationen herausrückt, 'irgendwo' als goldene Wahrheit
> >abgespeichert wird. Ein zwingender Zusammenhang mit realen Ereignissen
> >auf der fraglichen Maschine besteht nicht.
>
> Wirf einen Blick auf include/linux/acct.h
Dann finde ich "BSD process accounting". Zusammenhang?
--
SIGSTOP
Dietz Proepper
>* Dietz Proepper wrote:
>>>Du generalisiertst unzulässig.
>>
>>Wo?
>
>An der Stelle mit den Shell Accounts. Viele Server (auch unsere) haben
Die Shell Accounts habe ich nur von jemandem als Beispiel
aufgegriffen.
>Dienste, die man sicher mißbrauchen kann. Mich würde dann schon
>interessieren, welche Nutzerrechte der Prozeß hatte. Exploit in dem Sinne,
>daß man zwar kein root bekommt, aber einen anderes Program starten kann.
Soweit: Ack.
Aber:
Du wirst ca. 3 Minuten benötigen, den Punkt im Linuxkern zu
finden wo Du das printk ... einfügen mußt. Die Parameter zu finden
sollte nochmal 10 Minuten kosten. Die Zeitabschätzung ist <meine Zeit>/2.
Ja, die 2 Monate Feldtest habe ich unterschlagen. Um ganz ehrlich
zu sein, ich hab's auch nicht umgesetzt, insofern bin ich mir nur
theoretisch sicher daß es praktisch trivial wäre ;). Bitte erzähl' mir
nicht daß ich damit einen Rattenschwanz an weiteren potentiellen
Problemen heraufbeschwöre, in dem Pfad sind einige weitere printks die
ich aus Userland zur Not auch erreichen kann.
Wenn Dir das zu blöd|aufwendig|sonstwas ist dann gäbe es da noch
etliche andere Methoden die es Dir erlauben, an der Stelle unabhängig
von Anderen zu sein. Aber wem sage ich das.
Nur, sich hinzustellen und von unbeteiligten Dritten Aktivität zu
fordern ist zunächst problematisch.
Dann Leuten die der Meinung anhängen, die ganze Idee sei hirntod und
daher weder Ident fragen noch Ident als "wichtigen Dienst" ansehen zu
sagen "dann bist Du asozial" geht mir entschieden zu weit. Abgesehen davon,
das "Ident denyen" wird man in aller Regel aus ganz egoistischen
Gründen nicht machen da es nachwievor Leute gibt die so asozial sind,
anderen unverläßliche, obsolete Dienste aufzuzwingen. Smiley.
>>Ich wart' ja nur darauf daß mir mal jemand sagt "hätten's ident gefragt,
>>dann könnt' ma ihnen jetzt sagen wer das war".
>
>Das habe ich schon mal jemanden geschrieben.
Und, hat er dann in der Anzeige gegen Unbekannt das "Unbekannt" durch
IKS Jena und die Tat durch "billigende Inkaufnahme" (IANAL) ersetzt?
Dietz
Dietz Proepper
[Ident nützlich?]
>Und weil Du selbst keinen Nutzen siehst, verhinderst Du aktiv den Nutzeffekt
>für Andere? Warum?
man PAL. S. anderes posting.
Lutz Donnerhacke
>Du wirst ca. 3 Minuten benötigen, den Punkt im Linuxkern zu
>finden wo Du das printk ... einfügen mußt. Die Parameter zu finden
>sollte nochmal 10 Minuten kosten.
Nur gibt es Systeme, denen ich nicht immer einen Kernelpatch verpassen
möchte, besonders, wenn sie nicht Linux heißen.
>Wenn Dir das zu blöd|aufwendig|sonstwas ist dann gäbe es da noch
>etliche andere Methoden die es Dir erlauben, an der Stelle unabhängig
>von Anderen zu sein. Aber wem sage ich das.
Nenn mir eine für OSF/1. Danke.
>Nur, sich hinzustellen und von unbeteiligten Dritten Aktivität zu
>fordern ist zunächst problematisch.
Ack.
>Dann Leuten die der Meinung anhängen, die ganze Idee sei hirntod und
>daher weder Ident fragen noch Ident als "wichtigen Dienst" ansehen zu
>sagen "dann bist Du asozial" geht mir entschieden zu weit.
Du mißinterpetierst. Ich sage das nur denen, die DENY drauf haben.
>>>Ich wart' ja nur darauf daß mir mal jemand sagt "hätten's ident gefragt,
>>>dann könnt' ma ihnen jetzt sagen wer das war".
>>
>>Das habe ich schon mal jemanden geschrieben.
>
>Und, hat er dann in der Anzeige gegen Unbekannt das "Unbekannt" durch
>IKS Jena und die Tat durch "billigende Inkaufnahme" (IANAL) ersetzt?
Nein, er konnte helfen. s/IKS/ThurNet/
Lars Gebauer
>> Du solltest Daten liefern denen _Du_ vertraust.
>
> Ich will aber nicht.
Na _dann_ ist es sowieso sinnlos.
--
mataHmeH maSachnlS.
Wir muessen uns ausdehnen um zu ueberleben.
Rainer Perske
> Ein Admin der ident-Lookups vom fernen Ende benötigt um seine Systeme
> zu überwachen ist mit Verlaub ganz nahe an der vorsätzlichen Inkompetenz.
Oder er hat beschlossen, die Gesetze zu beachten (Anonymisierungs- bzw.
Löschzwang, an verschiedenen Stellen in TKG, TDDSG, MDStV, BDSG usw.
vorhanden), welche verhindern, dass bestimmte Klassen von Vorfällen
nachträglich aufgeklärt werden können, welche aber durchaus erlauben, die
zu einer ggf. notwendigen Aufklärung Daten an die Gegenseite
weiterzugeben.
Wenn diese Gesetze nicht wären, hättet Dietz mit seiner Aussage
vollkommen Recht. So aber hat Lutz vollkommen Recht. IANAL.
cu
--
Rainer Perske
[] | ZENTRUM FÜR | Center for | Universität Münster University
[] [][][] | INFORMATIONS | Information | http://www.uni-muenster.de/ZIV
[][] [] | VERARBEITUNG | Processing |
Ulrich Eckhardt
> >Ein Server, der sich zur Informationsermittlung darauf verläßt, was
> >irgendein Admin irgendwo auf der Welt auf einem bestimmten Port laufen
> >läßt, hat ein Konfigurationsproblem, denn dem kann ich alles schicken,
> >was ich möchte (das machen AFAIK zB die meisten Win-IRCs).
>
> Du hast ident nicht verstanden, es hilft nicht dem Abfragenden, sondern dem
> Abgefragten.
Hi,
also wenn ich den ident rfc richtig verstanden habe, ist das Teil
eigentlich nur für "interne" zwecke zu gebrauchen, da es weder
für abgefragten noch für den abfragenden sichergestellt ist, das
die ausgetauschten Daten irgendwie was mit der Realität zu tun haben.
D.h. der normal paranoide sysadmin kann sich eigentlich die ident
Abfrage bei unseren Rechnern sparen, da ich ja falsche infos liefern
könnte. Ich kann mit den ident - daemon sparen, da der Abfragende
ja auch irgendwelchen Müll liefern kann. Und für die verbleibenden
internen Zwecke kann ich glaube ich getrost ident durch ein netcat
oder telnet <host> <port> ersetzen. Irgendwelche konkreten
Gegenbeispiele ?
Aus dem rfc 1413 :
The Identification Protocol is not intended as an authorization or
access control protocol. At best, it provides some additional
auditing information with respect to TCP connections. At worst, it
can provide misleading, incorrect, or maliciously incorrect
information.
The use of the information returned by this protocol for other than
auditing is strongly discouraged. Specifically, using Identification
Grüße
Uli
--
Ulrich Eckhardt Tr@nscom
http://www.uli-eckhardt.de http://www.transcom.de
Lagerstraße 11-15 A8
64807 Dieburg Germany
Lutz Donnerhacke
>D.h. der normal paranoide sysadmin kann sich eigentlich die ident
>Abfrage bei unseren Rechnern sparen, da ich ja falsche infos liefern
>könnte. Ich kann mit den ident - daemon sparen, da der Abfragende
>ja auch irgendwelchen Müll liefern kann. Und für die verbleibenden
>internen Zwecke kann ich glaube ich getrost ident durch ein netcat
>oder telnet <host> <port> ersetzen. Irgendwelche konkreten
>Gegenbeispiele?
Zwei verantwortungsvolle Admins, wie es zu Zeiten der Entstehung des RfCs
weltweit übich war.
> The use of the information returned by this protocol for other than
> auditing is strongly discouraged. Specifically, using Identification
Kein Grund für Deny.
Lutz Donnerhacke
>D.h. der normal paranoide sysadmin kann sich eigentlich die ident
>Abfrage bei unseren Rechnern sparen, da ich ja falsche infos liefern
>könnte. Ich kann mit den ident - daemon sparen, da der Abfragende
>ja auch irgendwelchen Müll liefern kann. Und für die verbleibenden
>internen Zwecke kann ich glaube ich getrost ident durch ein netcat
>oder telnet <host> <port> ersetzen. Irgendwelche konkreten
Zwei verantwortungsvolle Admins, wie es zu Zeiten der Entstehung des RfCs
weltweit übich war.
> The use of the information returned by this protocol for other than
> auditing is strongly discouraged. Specifically, using Identification
Es wird für Auditing verwendet. Du solltest es nur nicht nutzen, BEI DIR
Rechte aufgrund der Antwort zu vergeben.
Kein Grund für DENY.
Lars Gebauer
> D.h. der normal paranoide sysadmin kann sich eigentlich die ident
> Abfrage bei unseren Rechnern sparen, da ich ja falsche infos
> liefern könnte.
Das waere aber nicht in _Deinem_ Interesse.
--
reH 'eb tu'lu'.
Es gibt immer eine Chance.
Dietz Proepper
>* Dietz Proepper wrote:
>>Du wirst ca. 3 Minuten benötigen, den Punkt im Linuxkern zu
>>finden wo Du das printk ... einfügen mußt. Die Parameter zu finden
>>sollte nochmal 10 Minuten kosten.
>
>Nur gibt es Systeme, denen ich nicht immer einen Kernelpatch verpassen
>möchte, besonders, wenn sie nicht Linux heißen.
Ich wußte daß das kommt.
>>Wenn Dir das zu blöd|aufwendig|sonstwas ist dann gäbe es da noch
>>etliche andere Methoden die es Dir erlauben, an der Stelle unabhängig
>>von Anderen zu sein. Aber wem sage ich das.
>
>Nenn mir eine für OSF/1. Danke.
Willst Du ein Angebot?^H^H^W^W^W^W
Die Keulenlösung wäre, einen Socks-proxy davor zu stellen der das
Logging übernimmt. Bekommt man sogar überraschen performant hin.
Die nächste Idee wäre, den Verbindungsaufbau zu sniffen und daraus
Ident-Abfragen zu generieren, wird aber vermutlich zumindest in der
naiven Variante zu einfach am Timing scheitern.
Auch ein Pollen der entsprechenden Zustandstabellen wäre denkbar.
Wobei das natürlich schrecklich ineffizient und u.U. lückenhaft ist.
Wobei, wenn man es mit dem Sniffen kombiniert könnte sowas auch
funktionieren.
>>Dann Leuten die der Meinung anhängen, die ganze Idee sei hirntod und
>>daher weder Ident fragen noch Ident als "wichtigen Dienst" ansehen zu
>>sagen "dann bist Du asozial" geht mir entschieden zu weit.
>
>Du mißinterpetierst. Ich sage das nur denen, die DENY drauf haben.
Ack. Nur wäre mein Erklärungsansatz dann eher in der Art daß es zum
guten Ton gehört, daß es historisch gewachsen ist.
Die technischen Gründe verleiten imo zu sehr zu einem "warum machen
wir mit $BLAH nicht das selbe immerhin hat $BLAH einen Anteil von x%".
Dietz
Dietz Proepper
>On Wed, 13 Dec 2000, Dietz Proepper wrote:
>> Ein Admin der ident-Lookups vom fernen Ende benötigt um seine Systeme
>> zu überwachen ist mit Verlaub ganz nahe an der vorsätzlichen Inkompetenz.
>
>Oder er hat beschlossen, die Gesetze zu beachten (Anonymisierungs- bzw.
>Löschzwang, an verschiedenen Stellen in TKG, TDDSG, MDStV, BDSG usw.
>vorhanden), welche verhindern, dass bestimmte Klassen von Vorfällen
>nachträglich aufgeklärt werden können, welche aber durchaus erlauben, die
>zu einer ggf. notwendigen Aufklärung Daten an die Gegenseite
>weiterzugeben.
Welche Klassen? IAANAL.
>Wenn diese Gesetze nicht wären, hättet Dietz mit seiner Aussage
>vollkommen Recht. So aber hat Lutz vollkommen Recht. IANAL.
Ack.
Dietz
Rainer Weikusat
> On Wed, 13 Dec 2000, Dietz Proepper wrote:
> > Ein Admin der ident-Lookups vom fernen Ende benötigt um seine Systeme
> > zu überwachen ist mit Verlaub ganz nahe an der vorsätzlichen Inkompetenz.
>
> Oder er hat beschlossen, die Gesetze zu beachten (Anonymisierungs- bzw.
> Löschzwang, an verschiedenen Stellen in TKG, TDDSG, MDStV, BDSG usw.
> vorhanden),
Darf ich das jetzt so verstehen, daß 'lastlog' in der BRD illegal ist?
--
SIGSTOP
Lutz Donnerhacke
>Rainer Perske <per...@uni-muenster.de> writes:
>> Oder er hat beschlossen, die Gesetze zu beachten (Anonymisierungs- bzw.
>> Löschzwang, an verschiedenen Stellen in TKG, TDDSG, MDStV, BDSG usw.
>> vorhanden),
>
>Darf ich das jetzt so verstehen, daß 'lastlog' in der BRD illegal ist?
Im Sinne des TDDSG ist es unerwünscht. Zu Debugging aber erlaubt.
Rainer Weikusat
> Rainer Weikusat schrieb:
> > Ich will aber nicht.
>
> Dann sag das doch: reject
Ich sage 'RST', denn man kann nicht auschließen, am anderen Ende ein
Linux zu haben, das ICMP-Fehler freundlicherweise total ignoriert.
--
SIGSTOP
Ulrich Eckhardt
> >könnte. Ich kann mit den ident - daemon sparen, da der Abfragende
> >ja auch irgendwelchen Müll liefern kann. Und für die verbleibenden
> >internen Zwecke kann ich glaube ich getrost ident durch ein netcat
> >oder telnet <host> <port> ersetzen. Irgendwelche konkreten
> >Gegenbeispiele?
>
> Zwei verantwortungsvolle Admins, wie es zu Zeiten der Entstehung des RfCs
> weltweit übich war.
Du meinst solche die sich im Notfall auch mal eine ssh connection
zur Verfügung stellen ;-) . Was ich eigentlich sagen wollte ist,
dass ich ident für ein Protokoll halte, das eigentlich keiner braucht.
Da ich allerdings ein neugieriger Zeitgenosse bin, gibt es denn
Anwendungsfälle z.B. im internen vertrauungswürdigen Netz, wo ident
Vorteile gegebüber netstat/tcpdump & co bietet ? Ich hatte bisher
zumindest noch keinen Fall wo ich noch wissen musste welcher user
auf welchem Port eine Verbindung offen hatte. Oder verstehe ich irgendwo
was komplett falsch und sollte mir rfc1413 noch mal unters Kopfkissen
legen ?
> > The use of the information returned by this protocol for other than
> > auditing is strongly discouraged. Specifically, using Identification
>
> Es wird für Auditing verwendet. Du solltest es nur nicht nutzen, BEI DIR
> Rechte aufgrund der Antwort zu vergeben.
> Kein Grund für DENY.
Ich rejecte ident, allerdings bisher eher aus historischen als aus
technischen Gründen.
Lutz Donnerhacke
>Lutz Donnerhacke wrote:
>> Zwei verantwortungsvolle Admins, wie es zu Zeiten der Entstehung des
>> RfCs weltweit übich war.
>
>welcher user auf welchem Port eine Verbindung offen hatte.
Dann freu Dich und nimm den identd von Deinem System. Antworte mit RST/REJECT.
>> Es wird für Auditing verwendet. Du solltest es nur nicht nutzen, BEI DIR
>> Rechte aufgrund der Antwort zu vergeben.
>> Kein Grund für DENY.
>
>Ich rejecte ident, allerdings bisher eher aus historischen als aus
>technischen Gründen.
Fein.
Ulrich Eckhardt
Hi,
meinst du ein RST des IP stacks auf irgendwie vermurkste
ICMP packete z.B. ein echo reply das auf einem Rechner
eintrifft, der niemals ein echo request geschickt hat ?
Normalerweisse sollten doch fehlerhafte ICMP packete einfach
ignoriert werden (wenn ich den RFC zu ICMP richtig verstanden
habe).
Falls es wirklich Rechner gibt, die ein RST auf solche
ICMP packete verschickt, so würde das einige merkwürdige
ICMP packete die unser Firewall logt, doch als scanversuch
erklären.
Rainer Weikusat
> Rainer Weikusat wrote:
> > Ich sage 'RST', denn man kann nicht auschließen, am anderen Ende ein
> > Linux zu haben, das ICMP-Fehler freundlicherweise total ignoriert.
>
> Hi,
>
> meinst du ein RST des IP stacks auf irgendwie vermurkste
> ICMP packete z.B. ein echo reply das auf einem Rechner
> eintrifft, der niemals ein echo request geschickt hat?
<URL:http://rfc.fh-koeln.de/rfc/html_gz/rfc0761.html.gz>
--
SIGSTOP
Rainer Weikusat
> * Rainer Weikusat wrote:
> >Rainer Perske <per...@uni-muenster.de> writes:
> >> Oder er hat beschlossen, die Gesetze zu beachten (Anonymisierungs- bzw.
> >> Löschzwang, an verschiedenen Stellen in TKG, TDDSG, MDStV, BDSG usw.
> >> vorhanden),
> >
> >Darf ich das jetzt so verstehen, daß 'lastlog' in der BRD illegal ist?
>
> Im Sinne des TDDSG ist es unerwünscht.
Gut. Dann ist das TDDSG hier unerwünscht.
--
SIGSTOP
Lutz Donnerhacke
>>
>> Im Sinne des TDDSG ist es unerwünscht.
>
>Gut. Dann ist das TDDSG hier unerwünscht.
Du hast es kürzer nach Bonn gehabt. Warum beschwerst Du Dich erst jetzt?
Thomas Kuehnert
> ....
> Mir hilft er nichts und sonst geht das keinen was an.
Mal als Beispiel, evtl. koennen wir so erst mal Klarheit schaffen.
Teilweise habe ich den Eindruck, Ihr redet aneinander vorbei.
Ich habe das so verstanden:
Server A Admin AA 500 User hat identd laufen
Server B Admin BB 500 User hat keinen identd laufen
Fall 1: User XXX von A dringt in B ein und macht was boeses.
Admin BB bemerkt das und teilt AA das ganze mit und
kann ihm _zusaetzlich_ den Hinweis geben, das evtl.
der User 333 das angestellt hat.
Wenn AA jetzt auf die Suche geht, hat er einen Anhaltspunkt.
Wenn XXX den identd auf A auch manipuliert hat, dann hilft das
AA nix, aber er erhaelt dadurch evtl. neue Hinweise auf das
Ereignis.
Fall 2: User YYY von B dringt in A ein ....
BB erhaelt _keine_ Zusatzinfo von AA, weil er selbst den
identd nicht im Einsatz hat.
Fazit: * BB ist meist schlechter dran als AA
* fuer "weiter nix" ist identd (heute?) gedacht
* BB darf _keineswegs_ dem identd von A als "Garant" fuer
irgenwas
ansehen
Koennen wir uns erstmal auf diesen grob vereinfachten Stand einigen?
Gruss Tommy
Lutz Donnerhacke
>Fazit: * BB ist meist schlechter dran als AA
> * fuer "weiter nix" ist identd (heute?) gedacht
> * BB darf _keineswegs_ dem identd von A als "Garant" fuer
> irgenwas ansehen
>
>Koennen wir uns erstmal auf diesen grob vereinfachten Stand einigen?
Das ist die Aussage und der Sinn des RfC.
Johannes Segitz
>* Rainer Weikusat wrote:
>>lu...@iks-jena.de (Lutz Donnerhacke) writes:
>>> Du hast ident nicht verstanden, es hilft nicht dem Abfragenden, sondern dem
>>> Abgefragten.
>>
>>Mir hilft er nichts und sonst geht das keinen was an.
>
>Und weil Du selbst keinen Nutzen siehst, verhinderst Du aktiv den Nutzeffekt
>für Andere? Warum?
Ich denke, es hilft dem Abfragenden nicht?
cu
Jon'derdaswahrscheinlichniekapierenwird'ny
--
Unix was never designed to keep people from doing stupid things,
because that policy would also keep them from doing clever things.
-- Doug Gwyn
PGP/GPG-Key available at www.Johannes-Segitz.de | ICQ #94676997
Juergen Ilse
Rainer Weikusat <weik...@mail.uni-mainz.de> wrote:
> lu...@iks-jena.de (Lutz Donnerhacke) writes:
>> Admins, die sich über Script Kiddies ärgern, glauben oft, diese
>> durch DENY aufhalten zu können.
> Admins, die sich über sinnlosen Traffic ärgern, glauben gelegentlich,
> auf unerwünschter Verbindungsversuche mit gar keinem Echo zu
> reagieren, sei auch ganz ok. Warum soll ich meinen Computer für 5000
> sinnlose connects 5000 ICMPs nach Weiß-der-Geier-wohin (IP spoofing
> anyone) schicken lassen, nur um den Rechner dort auch noch ein bißchen
> auf Trab zu halten und gleichzeitig aus voller Kehle "Ich bin hier!
> Ich bin hier!" zu brüllen?
Zur Traffic-Reduzierung ist das aber keine wirklich geeignete Massnahme.
Statt auf ein Paket mit einer abschlaegigen Antwort zu reagieren, ignboriert
man eine ganze Reihe an Paketen (ja, meistens werden eine ganze Reihe an
Paketen gesendet, wenn KEINERLEI Reaktion kommt) bis schliesslich mit Fehler-
meldungen der Versuch abgebrochen wird. Wenn man tatsaehlich saemtliche
Bytes zaehlen wuerde, kaeme man ggfs. durch ignorieren sogar auf hoehere
(aber in aller Regel immer noch vernachlaessigbare) Mengen an uebertragenen
Daten...
> Dies ist praktisch leider nicht falsch (pure Empirie allerdings):
> Sobald ich mich irgendwie melde, fangen die Leute am anderen Ende an,
> sich mehr Mühe zu geben. Falls jemand DTAG-BB1 durchscannt, wird er
> sich im ersten Durchlauf darauf konzentrieren, zu ermitteln, welche IP
> zZt tatsächlich von irgendwas benutzt wird.
Der daraus resultierende Traffic derufte nicht wesentlich hoeher sein als
der Traffic durch die wiederholt gesendeten Pakete beim Versuch eines Ver-
bindungsaufbaus...
>> Andererseits bremst man mit DENY alle legitimen Nutzer und
>> Server massiv aus.
> 'legitimer Nutzen' <=> 'erlaubter Port'. Der Rest ist Müll und kommt
> in die Tonne.
Wobei aber eigentlich ident eine "legitime Benutzung" waere (und daran
hat sich AFAIK doch die Diskussion entzuendet, zumindest AUCH daran).
>> Ident dient dazu, dem Admin eines ordentlich gepflegten Systems
>> eine Hilfestellung bei der Identifizierung seiner, sich daneben
>> benehmenden Nutzer zur geben.
> 'identd' dient dazu, FTP- und SMTP-Server von überall auf der Welt mit
> sinnlosem, inhaltlich nicht verifizierbarem Datenmüll zu beglücken,
> sowie den Leuten, die auf diese Server zugreifen, mit Bitten um das
> Herausgeben der erwähnten Nullinformation auf den Wecker zu fallen.
Ich denke zwar auch nicht, dass in den meisten Faellen wirklich sinnvolle
Information von diesem Port kommt (nicht, solange eine erhebliche Zahl von
Script-Kiddies vom eigenen Rechner agiert und auf diesem root-Rechte be-
sitzt, oder auch von einem zuvor gecrackten Rechner auf dem sie die selben
Rechte haben), aber bei ident wuerde ich dazu neigen, dass dabei ein "reject"
sinnvoll ist. Bei einem nicht angebotenen SMTP-Service waere ich unter Um-
staenden anderer Meinung, aber lassen wir das...
>> DENY für ident bewirkt nur, daß diese Hilfestellungen bei anderen
>> Servern nicht mehr gesammelt werden und ist so aktiver
>> Spammer/Scriptkiddy-Schutz.
> ALLOW für identd bewirkt, daß das, was ein auf diesem Port laufender
> Server an Informationen herausrückt, 'irgendwo' als goldene Wahrheit
> abgespeichert wird.
Diese Diskussion ging AFAIK nicht um "DENY <--> ALLOW" sondern um
"DENY<-->REJECT", also gegenueber deiner letzten Bemerkung um einen
gaenzlich anderen Sachverhalt (oder habe ich jetzt etwas falsch ver-
standen?)...
Tschuess,
Juergen Ilse (il...@asys-h.de)
--
Eingedeutschte Fehlermeldungen sind doch etwas | Juergen Ilse
schoenes: "*** Fehlerrückkercode 1" (ld auf HP/UX) | Internet POP Hannover
-----------------------------------------------------| Vahrenwalder Str. 205
Neu in de.comp.os.unix.linux.*? Lies die infos-Gruppe| 30165 Hannover
Bernd Eckenfels
> Das ist die Aussage und der Sinn des RfC.
Wobei es dann nich identds gibt die etwas inteligenter sind und es
ermoeglichen sicherzustellen, dass ein admin keine falschmeldung machen kann
und nur tokens melden kann die wirklich vom indentd stammten. Und die sind
dann auch noch so "zufaellig" dass man daraus nix ablesen kann wenn man
nicht betreiber des identd is.
Gruss
Bernd
Juergen Ilse
Lutz Donnerhacke <lu...@iks-jena.de> wrote:
> * Juergen Ilse wrote:
>>Evt. kann damit ein unerwuenschter "Port-Scan" so sehr verzoegert werden,
>>dass ein potentieller Angreifer vorzeitig aufgibt (nunja, vielleicht nicht
>>SOOO wahrscheinlich), zumindest verzoegert er aber die Aktion (und mal
>>ganz ehrlich: welches Interesse sollte ich daran haben, einem potentiellen
>>Angreifer einen schnelleren Port-Scan zu ermoeglichen?).
> Lies die FAQ. Es interessiert den Angreifer einen Feuchten.
Ich habe die FAQ gelesen, ich weiss, dass mehrere Port-Abfragen parallel
laufen koennen, das koennen sie aber auch, wenn zusaetzlich die Abfragen
schneller zurueckkommen. Bei richtig massiven Scans (ich tue so etwas nicht,
und ich wuerde fuer mich auch keinen Sinn darin sehen) kann das die "Minimal-
Zeit" fuer die gesamte Aktion verlaengern. Ob das ausreicht, um irgendwelche
Effekte zu eruzielen (beim "boesen Buben") weiss ich nicht. Bei Ports, deren
Benutzung durch andere mir keinerlei Vorteile bringt (und bei denen es im
Grunde bei anderen genauso ist) sehe ich keinen Grund fuer ein Reject (obwohl
ich es i.d.R. trotzdem meistens tue). Ich habe hier bewusst NICHT ueber ident
geschrieben, ich habe nur "ganz allgemein" die "grundsaetzliche" Nuetzlich-
keit von Reject gegenueber Deny bezweifelt und statt dessen vorgeschlagen
das im einzelfall zu beurteilen.
Tschuess,
Juergen Ilse (il...@asys-h.de)
--
Eingedeutschte Fehlermeldungen sind doch etwas | Juergen Ilse
schoenes: "Kein Weltraum links auf dem Geraet" | Internet POP Hannover
Lars Gebauer
> Ich denke zwar auch nicht, dass in den meisten Faellen wirklich
> sinnvolle Information von diesem Port kommt [...]
Ich weiss zwar nicht wie viele Rechner mit wie vielen Usern Du admi-
nistrierst, aber nehmen wir der Einfachheit halber mal an es waeren
mehr als 100.
Wuerde es Dir im $PROBLEMFALL helfen wenn man Dir einigermassen ver-
nuenftige Informationen ueber moegliche Verursacher liefern kann?
Wenn ja solltest Du dafuer sorgen das Dein identd (fuer Dich) ver-
nuenftige Informationen hergibt.
--
jeghbe' tlhlnganpu'.
Klingonen ergeben sich nicht.
Lutz Donnerhacke
>On 13 Dec 2000 12:09:22 GMT, Lutz Donnerhacke wrote:
>>* Rainer Weikusat wrote:
>>>lu...@iks-jena.de (Lutz Donnerhacke) writes:
>>>> Du hast ident nicht verstanden, es hilft nicht dem Abfragenden, sondern dem
> ^^^^^^^^^^^^^^^^^^^^^
>>>> Abgefragten.
>>>
>>>Mir hilft er nichts und sonst geht das keinen was an.
>>
>>Und weil Du selbst keinen Nutzen siehst, verhinderst Du aktiv den Nutzeffekt
>>für Andere? Warum?
>
>Ich denke, es hilft dem Abfragenden nicht?
Ich habe auch nichts dagegen, daß er nicht abfragt, aber sollte er DENY
nehmen, so bringt er andere Abfragende darauf, es abzustellen und
unterschlägt so denen, denen es nützen würde, wertvolle Informationen.
Lutz Donnerhacke
>Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>> Lies die FAQ. Es interessiert den Angreifer einen Feuchten.
>
>Ich habe die FAQ gelesen, ich weiss, dass mehrere Port-Abfragen parallel
>laufen koennen, das koennen sie aber auch, wenn zusaetzlich die Abfragen
>schneller zurueckkommen. Bei richtig massiven Scans (ich tue so etwas nicht,
>und ich wuerde fuer mich auch keinen Sinn darin sehen) kann das die "Minimal-
>Zeit" fuer die gesamte Aktion verlaengern.
Ob bei Massen-Scans die Antworten teilweise drei Minuten länger brauchen,
ist wirklich irrelevant. Auf die 'Löcher' muß man sowieso warten.
>Ob das ausreicht, um irgendwelche Effekte zu eruzielen (beim "boesen
>Buben") weiss ich nicht.
Nein, keine Effekte.
>Bei Ports, deren Benutzung durch andere mir keinerlei Vorteile bringt (und
>bei denen es im Grunde bei anderen genauso ist) sehe ich keinen Grund fuer
>ein Reject (obwohl ich es i.d.R. trotzdem meistens tue).
Du meinst, Du solltest Deine private Meinung zum Anlaß nehmen, Dritte, die
diese nicht teilen, aktiv zu stören? Kennst Du das Robustness Principle?
>Ich habe hier bewusst NICHT ueber ident geschrieben, ich habe nur "ganz
>allgemein" die "grundsaetzliche" Nuetzlich- keit von Reject gegenueber
>Deny bezweifelt und statt dessen vorgeschlagen das im einzelfall zu
>beurteilen.
Traust Du Dir zu, zu wissen, was aktuell im Internet sinnvoll ist?
Ulrich Eckhardt
>
> # Juergen Ilse wrote:
>
> > Ich denke zwar auch nicht, dass in den meisten Faellen wirklich
> > sinnvolle Information von diesem Port kommt [...]
> nuenftige Informationen ueber moegliche Verursacher liefern kann?
>
> Wenn ja solltest Du dafuer sorgen das Dein identd (fuer Dich) ver-
> nuenftige Informationen hergibt.
Hi,
irgendwie habe ich's bisher den Sinn von ident nicht so recht
verstanden, aber bei obigem Posting kommt mir doch eine idee :
Angenommen ich hätte einen funktionierenden identd z.B. auf unserem
Firewall laufen.
Irgendein interner Luser/Böser Bube benutzt unseren Proxy dazu
z.B. via telnet an irgendwelchen Rechnern z.B. von Lutz rumzufummeln
(sollte hoffentlich nicht möglich sein, ist wirklich nur ein Beispiel).
Lutz bemerk das und schick mir einen entsprechenden abuse nebst
ident abfrage in der dann irgendwas in der form
"port xxx user squid" steht. Da ich Lutz für vertrauenswürdig
und kompetent halte, würde mich das sofort auf die idee bringen mal in
den logs unseres proxy nachzuschauen und da hoffentlich den
betreffenden User ausfindig zu machen.
Wäre das ein Szenario eines sinvollen Einsatzes von identd ?
Lutz Donnerhacke
>irgendwie habe ich's bisher den Sinn von ident nicht so recht
>verstanden, aber bei obigem Posting kommt mir doch eine idee :
>
>Angenommen ich hätte einen funktionierenden identd z.B. auf unserem
>Firewall laufen.
>
>Irgendein interner Luser/Böser Bube benutzt unseren Proxy dazu
>z.B. via telnet an irgendwelchen Rechnern z.B. von Lutz rumzufummeln
>(sollte hoffentlich nicht möglich sein, ist wirklich nur ein Beispiel).
>
>Lutz bemerk das und schick mir einen entsprechenden abuse nebst
>ident abfrage in der dann irgendwas in der form
>"port xxx user squid" steht. Da ich Lutz für vertrauenswürdig
>und kompetent halte, würde mich das sofort auf die idee bringen mal in
>den logs unseres proxy nachzuschauen und da hoffentlich den
>betreffenden User ausfindig zu machen.
>
>Wäre das ein Szenario eines sinvollen Einsatzes von identd ?
Ja. Und Du mußt nichtmal mir vertrauen, aber mein Tip wäre Dein Ansatzpunkt
für eine Suche.
Lars Gebauer
> Angenommen ich hätte einen funktionierenden identd z.B. auf
> unserem Firewall laufen.
>
> Irgendein interner Luser/Böser Bube benutzt unseren Proxy dazu
> z.B. via telnet an irgendwelchen Rechnern z.B. von Lutz
> rumzufummeln (sollte hoffentlich nicht möglich sein, ist wirklich
> nur ein Beispiel).
>
> Lutz bemerk das und schick mir einen entsprechenden abuse nebst
> ident abfrage in der dann irgendwas in der form
> "port xxx user squid" steht. Da ich Lutz für vertrauenswürdig
> und kompetent halte, würde mich das sofort auf die idee bringen
> mal in den logs unseres proxy nachzuschauen und da hoffentlich den
> betreffenden User ausfindig zu machen.
>
> Wäre das ein Szenario eines sinvollen Einsatzes von identd ?
Ja genau. Darum geht es, das ist der Sinn der ganzen Uebung. Es soll
_Dir_ im $PROBLEMFALL helfen.
Das funktioniert natuerlich nur wenn Dein identd auch Infos hergibt
mit denen _Du_ etwas anfangen kannst.
Wenn Du Deinen identd abgedreht hast oder wenn er nur Mist liefert
beraubst Du Dich dieser Moeglichkeit der schnelleren Problemer-
kennung.
Ob $LUTZ vertrauenswuerdig ist oder nicht ist dabei zweitrangig. Den
Versuch ist es allemal wert.
--
Heghlu'meH QaQ jajvam.
Heute ist ein guter Tag zum Sterben.
Ulrich Eckhardt
> >betreffenden User ausfindig zu machen.
> >
> >Wäre das ein Szenario eines sinvollen Einsatzes von identd ?
>
> Ja. Und Du mußt nichtmal mir vertrauen, aber mein Tip wäre Dein Ansatzpunkt
> für eine Suche.
Hi,
danke, ich bin jetzt bekehrt. Werde wenn ich wieder etwas mehr
Zeit habe mal wieder identd aktivieren.
Grüße
Ulrich Eckhardt
Hi,
obiges is der rcf zu TCP . Wir sprachen aber doch über
ICMP Fehler oder habe ich da was verpasst ?
Aus rfc777 ist ICMP auf IP ebene angesiedelt. :
purposes this protocol, the Internet Control Message Protocol (ICMP),
is used. ICMP, uses the basic support of IP as if it were a higher
level protocol, however, ICMP is actually an integral part of IP, and
must be implemented by every IP module.
Und was das error handling von ICMP messages angeht :
The ICMP messages typically report errors in the processing of
datagrams, to avoid the infinite regress of messages about messages
etc., no ICMP messages are sent about ICMP messages.
RST ist ein Handshake auf TCP ebene. ICMP läuft auf IP ebene. Ein RST
auf ein ICMP Packet würde da nun überhaupt keinen Sinn ergeben.
Rainer Weikusat
> Diese Diskussion ging AFAIK nicht um "DENY <--> ALLOW" sondern um
> "DENY<-->REJECT", also gegenueber deiner letzten Bemerkung um einen
> gaenzlich anderen Sachverhalt (oder habe ich jetzt etwas falsch ver-
> standen?)...
Verschiedene Leute werfen da mit Wonne unterschiedliches
durcheinander.
auth-Anfrage zu ignorieren ist leider sinnlos, weil es die Interaktion
mit sendmails oÄ allüberall auf der Welt kräftig verzögert. Den identd
abzudrehen hat leider unangenehme Nebeneffekte, weil 1003 IRC-Server
die dadurch gewonnene Nullinformation interpretieren und verarbeiten.
Ich fände es schöner, wenn weder das eine noch das andere
vorkäme. Wenn jemand einen Dienst anbietet, folgt daraus keine
Berechtigung, gültige Logins von meinem Rechner zu sammeln. Ansonsten
kann ich, vorausgesetzt ich bekomme Datum und Uhrzeit, jederzeit aus
meinen Logs (die ich im Zweifelsfall ohnehin durcharbeiten müßte) das,
was der identd angeblich zur Verfügung stellt, selber ermitteln. Die
Information, daß zu einem gegebenen Zeitpunkt ein unter der uid X
laufender Prozeß eine TCP-Verbindung nach da und dort aufgemacht hat,
bringt mich da leider überhaupt nicht weiter. Demnächst wird hier zB
'mal wieder' ein socks v5 in Betrieb gehen, dh alle identd-Abfragen
werden dieselbe id liefern, nämlich die, unter der der socks-Server
läuft. Anderes Beispiel: maskierender Linux-Router. In beiden Fällen
ist der identd absolut sinnlos, sowohl für mich, als auch für alle
anderen.
Der identd ist, genau wie die 'erweiterten Möglichkeiten' von ftp, ein
Relikt aus den Zeiten, als wir alle noch eine große glückliche Familie
waren. Schätzungsweise war das das letzte Mal der Fall, als ich in die
fünfte Klasse gekommen bin (1984). Das war so ungefähr zu den Zeiten,
als ich gerade dabei war, meinen Vater aktiv dazu zu überreden, mir zu
gestatten, einen Computer zu besitzen (war natürlich aus Prinzip
dagegen), deswegen fehlen mir leider die Erinnerungen an dies
vergangene goldene Zeitalter. Insofern stellt tcp/113 für mich
lediglich einen weiteren Netzdienst dar, der es jemandem potentiell
ermöglicht, auf einem Rechner unter meiner Fuchtel irgendwelchen Unfug
anzustellen => abdrehen.
--
SIGSTOP
Lutz Donnerhacke
>vorkäme. Wenn jemand einen Dienst anbietet, folgt daraus keine
>Berechtigung, gültige Logins von meinem Rechner zu sammeln.
Warum lieferst Du keine Token?
>kann ich, vorausgesetzt ich bekomme Datum und Uhrzeit, jederzeit aus
>meinen Logs (die ich im Zweifelsfall ohnehin durcharbeiten müßte) das,
>was der identd angeblich zur Verfügung stellt, selber ermitteln.
man Multiuser.
>bringt mich da leider überhaupt nicht weiter. Demnächst wird hier zB 'mal
>wieder' ein socks v5 in Betrieb gehen, dh alle identd-Abfragen werden
>dieselbe id liefern, nämlich die, unter der der socks-Server läuft.
>Anderes Beispiel: maskierender Linux-Router. In beiden Fällen ist der
>identd absolut sinnlos, sowohl für mich, als auch für alle anderen.
Dein Problem. Denk Dir ein anderes Schema aus.
>Der identd ist, genau wie die 'erweiterten Möglichkeiten' von ftp, ein
>Relikt aus den Zeiten, als wir alle noch eine große glückliche Familie
>waren.
Nein.
>vergangene goldene Zeitalter. Insofern stellt tcp/113 für mich
>lediglich einen weiteren Netzdienst dar, der es jemandem potentiell
>ermöglicht, auf einem Rechner unter meiner Fuchtel irgendwelchen Unfug
>anzustellen => abdrehen.
Nichts gegen abdrehen, aber sehr wohl was gegen 'ins Leere laufen' lassen.
Dr. Max Horneck
> "Penner" quatscht dich an, und will 'nen Euro. Hier könnte man
> sagen "Ach ne, habe selbst kein Geld" (REJECT) oder es einfach
^^es
streichen
--
Gruss,
Max Horneck
---
www.horneck.net
www.koehler-freiburg.de
Lutz Donnerhacke
>> "Penner" quatscht dich an, und will 'nen Euro. Hier könnte man
>> sagen "Ach ne, habe selbst kein Geld" (REJECT) oder es einfach
> ^^es
>streichen
Danke.
http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Tunnel
Ich bin Firewall-Admin. Einige Anwender haben Software im Einsatz, die
unerlaubte Zugriffe über erlaubte Protokolle tunnelt. Was soll ich tun?
Es ist praktisch nicht möglich halbwegs freien Zugriff auf
externe Ressourcen zu gestatten, ohne daß die Möglichkeit von
Tunnels besteht. Da diese Tunnel Gegenstellen benötigen, könnte
man versuchen, alle diese Gegenstellen zu sperren. Aber diesen
Wettlauf verliert man immer.
Es bleiben so nur die Möglichkeiten des LART gegenüber dem
Anwender, oder die Einrichtung von Weißlisten, d.h. es dürfen
nur als gutartig im Sinne der Policy bekannte Gegenstellen
erreicht werden. Von einem Internet-Zugang kann jetzt natürlich
keine Rede mehr sein.
Man muß sich darüber klar sein, daß es unmöglich ist soziale
Probleme technisch zu erschlagen, egal wieviel Geld man auf das
Problem wirft.
Rainer Perske
Hallo.
On Wed, 13 Dec 2000, Dietz Proepper wrote:
> Rainer Perske wrote:
> >On Wed, 13 Dec 2000, Dietz Proepper wrote:
> >> Ein Admin der ident-Lookups vom fernen Ende benötigt um seine Systeme
> >> zu überwachen ist mit Verlaub ganz nahe an der vorsätzlichen Inkompetenz.
> >
> >Oder er hat beschlossen, die Gesetze zu beachten (Anonymisierungs- bzw.
> >Löschzwang, an verschiedenen Stellen in TKG, TDDSG, MDStV, BDSG usw.
> >vorhanden), welche verhindern, dass bestimmte Klassen von Vorfällen
> >nachträglich aufgeklärt werden können, welche aber durchaus erlauben, die
> >zu einer ggf. notwendigen Aufklärung Daten an die Gegenseite
> >weiterzugeben.
>
> Welche Klassen? IAANAL.
Ich hoffe, folgendes Szenario macht meine Aussage verständlich:
Ein "Täter" baut von einem Dialogserver (mit vielen gleichzeitigen
Nutzern) aus eine Verbindung zu einem anderen Server ("Opfer") auf und
baut dort Mist.
Während der bestehenden Verbindung darf der Betreiber des Dialogservers
auf identd-Anfragen des "Opfers" antworten und erhält so ein Token
(Nutzerkennung oder was auch immer), welches der Betreiber des
Dialogservers auch nachträglich noch einer Person ("Täter") zuordnen
könnte.
Er darf jedoch (außer unter gewissen besonderen Umständen) kein
personenbezogenes Protokoll aller solcher Verbindungen führen, aus dem er
nachträglich den Täter herausfinden könnte.
(Diese besonderen Umstände sind im Gesetzestext einzeln beschrieben und
nicht sehr umfangreich.)
Das heißt:
Falls das "Opfer" eine ident-Abfrage gemacht hat, kann der
Dialogserverbetreiber hinterher, wenn der Staatsanwalt mit dem Token
kommt, Auskunft über den "Täter" geben. Falls das Opfer jedoch keine
solche Abfrage gemacht hat, kommt die Staatsanwaltschaft vergebens, denn
der Dialogserverbetreiber kann die Verbindung keiner Person mehr zuordnen.
Analog ist das übrigens bei WWW-Proxy-Servern: Es ist kein Problem,
mittels X-Forwarded-For die IP-Adresse des Clients dem WWW-Server zu
übermitteln. Da IP-Adressen jedoch meist Personen zugeordnet werden
können, müssen sie in den Proxy-Logs jedoch anonymisiert werden, so dass
eine nachträgliche Zuordnung einer Verbindung zu einer Person nicht mehr
möglich ist.
HTH
cu
- --
Rainer Perske
[] | ZENTRUM FÜR | Center for | Universität Münster University
[] [][][] | INFORMATIONS | Information | http://www.uni-muenster.de/ZIV
[][] [] | VERARBEITUNG | Processing |
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3in
Charset: latin1
iQDVAwUBOjjTR89UbnbjB8C5AQGptgYAn16VfaRv0FUbiaYpDr8RwmJ3zvtipXOr
yilQ4bJN8qs/IaVKJYySZIOs4FDK6dSNMr3/2IvcRcyLEjfgv0OvX2mPSJaRn/lN
JwF3tpjiUMnfROUZnbKbBEwB+NRxD9Gbc9x3loOFm72sdCRBOu8X6GeRQXL41/AD
zv3zKL+ZplfVa5uikBK4ErUF7mURB5ZlKvYU45/wFUq5VC4QGO0yPdQRTTFB3gD7
OhDybZ4ELNfPIPqfx73O66n3jz43RqLG
=AaYB
-----END PGP SIGNATURE-----
Goetz Babin-Ebell
> Man muß sich darüber klar sein, daß es unmöglich ist soziale
> Probleme technisch zu erschlagen, egal wieviel Geld man auf das
> Problem wirft.
Mit anderen Worten:
Soziale Probleme kann man nur sozial erschlagen: LART
;-)
Tschau
Götz
--
Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
Felix von Leitner
> irgendwie habe ich's bisher den Sinn von ident nicht so recht
> verstanden, aber bei obigem Posting kommt mir doch eine idee :
Ich habe meine Postings zu IDENT mal ins Web getan, weil die meisten
offenbar keine Usenet-Suchmaschinen bedienen können.
http://www.fefe.de/docs/ident.txt
> Wäre das ein Szenario eines sinvollen Einsatzes von identd ?
Ja.
Nur auf Proxy-Servern sollte natürlich eh nichts außer dem Proxy laufen,
d.h. du hättest auch ohne Ident-Daten erstmal im Proxy nachgeschaut.
Felix
Stefan Heinecke
>Und nun hätte ich gerne von Dir erklärt, welche Ursache ich hier mit
>welcher Wirkung verwechselt habe.
Dein Problem sind nicht die ICMP-Replies, sondern die eingehenden Pakete.
Auf der anderen Seite kannst Du das Problem auch auf aktiven Diensten
haben.
>Dann finde ich "BSD process accounting". Zusammenhang?
Es hilft (mir) im Zusammenhang mit Ident, zusehen was User auf der
Maschine treiben.
Ulrich Eckhardt
>
> Ulrich Eckhardt <Ulrich....@transcom.de> wrote:
> > irgendwie habe ich's bisher den Sinn von ident nicht so recht
> > verstanden, aber bei obigem Posting kommt mir doch eine idee :
>
> Ich habe meine Postings zu IDENT mal ins Web getan, weil die meisten
> offenbar keine Usenet-Suchmaschinen bedienen können.
>
> http://www.fefe.de/docs/ident.txt
Ich hatte den Thread von vorne bis hinten verfolgt, dieser
Teil des Threads hat sich allerdings nicht bis zu mir
durchgeschlagen <seufz> , Murpheys law halt.
Da ich mittlerweile aber anderweitig auf den Trichter gekommen
bin, werden diese Postings sicher Morgen zu mir durchdringen ...
Trotzdem Danke noch mal.
Rainer Weikusat
> Rainer Weikusat <weik...@mail.uni-mainz.de> wrote:
> >Und nun hätte ich gerne von Dir erklärt, welche Ursache ich hier mit
> >welcher Wirkung verwechselt habe.
>
> Dein Problem sind nicht die ICMP-Replies, sondern die eingehenden
> Pakete.
Irrtum. Die eingehenden Pakete kommen so oder so. Schicke ich deswegen
ICMPs zurück, kostet das zum einen Geld, zum anderen teile ich
demjenigen, der mir das fragliche Paket geschickt hat, mit, daß er
tatsächlich ein Ziel getroffen hat. Beides muß nicht sein.
> Auf der anderen Seite kannst Du das Problem auch auf aktiven Diensten
> haben.
>
> >Dann finde ich "BSD process accounting". Zusammenhang?
>
> Es hilft (mir) im Zusammenhang mit Ident, zusehen was User auf der
> Maschine treiben.
Was hat das mit 'identd' zu tun?
--
SIGSTOP
Rainer Weikusat
> * Rainer Weikusat wrote:
> >vorkäme. Wenn jemand einen Dienst anbietet, folgt daraus keine
> >Berechtigung, gültige Logins von meinem Rechner zu sammeln.
>
> Warum lieferst Du keine Token?
Gute Frage.
> >kann ich, vorausgesetzt ich bekomme Datum und Uhrzeit, jederzeit aus
> >meinen Logs (die ich im Zweifelsfall ohnehin durcharbeiten müßte) das,
> >was der identd angeblich zur Verfügung stellt, selber ermitteln.
>
> man Multiuser.
?
> >Der identd ist, genau wie die 'erweiterten Möglichkeiten' von ftp, ein
> >Relikt aus den Zeiten, als wir alle noch eine große glückliche Familie
> >waren.
>
> Nein.
YMMV.
> Nichts gegen abdrehen, aber sehr wohl was gegen 'ins Leere laufen'
> lassen.
Wovon ich zu keiner Zeit mit keiner Zeile gesprochen habe.
--
SIGSTOP
Lutz Donnerhacke
>lu...@iks-jena.de (Lutz Donnerhacke) writes:
>> * Rainer Weikusat wrote:
>> >vorkäme. Wenn jemand einen Dienst anbietet, folgt daraus keine
>> >Berechtigung, gültige Logins von meinem Rechner zu sammeln.
>>
>> Warum lieferst Du keine Token?
>
>Gute Frage.
Eben. Dein Problem.
>> >kann ich, vorausgesetzt ich bekomme Datum und Uhrzeit, jederzeit aus
>> >meinen Logs (die ich im Zweifelsfall ohnehin durcharbeiten müßte) das,
>> >was der identd angeblich zur Verfügung stellt, selber ermitteln.
>>
>> man Multiuser.
>
>?
Meine Logfiles enthalten nicht die Angaben, wer von wann bis wann welchen
Netzport offen hatte. Da hilft mir ident nachträglich. Wenn Du alle
Kernelcalls mitprotokollierst: Bitte.
Stefan Heinecke
>Ich fände es schöner, wenn weder das eine noch das andere
>vorkäme. Wenn jemand einen Dienst anbietet, folgt daraus keine
>Berechtigung, gültige Logins von meinem Rechner zu sammeln. Ansonsten
Das muss nicht sein, Du kannst auch einfach einen Ident einsetzen
der ein Token liefert, das nur der Administrator kennt, alternativ
z.B. die reine numerische UID.
>läuft. Anderes Beispiel: maskierender Linux-Router. In beiden Fällen
>ist der identd absolut sinnlos, sowohl für mich, als auch für alle
>anderen.
Hint: Es gibt Proxy-Idents, die die Anfrage weiterleiten. Das macht aber
nur Sinn wenn das andere Ende auch Ident spricht.
>Der identd ist, genau wie die 'erweiterten Möglichkeiten' von ftp, ein
>Relikt aus den Zeiten, als wir alle noch eine große glückliche Familie
>waren. Schätzungsweise war das das letzte Mal der Fall, als ich in die
>fünfte Klasse gekommen bin (1984). Das war so ungefähr zu den Zeiten,
Ident ist kein Relikt, es ist auf einem BS mit hoher Marktdurchdringung
einfach nicht im Lieferumfang enthalten.
>Insofern stellt tcp/113 für mich
>lediglich einen weiteren Netzdienst dar, der es jemandem potentiell
>ermöglicht, auf einem Rechner unter meiner Fuchtel irgendwelchen Unfug
>anzustellen => abdrehen.
Hmm, Du hast den Sinn von Ident nicht verstanden, es ist praktisch -
natuerlich ist ein Identd nur so gut wie die Informationen die es liefert,
aber fuer Dienste die keine Authentifikation benoetigen, kann es Dir
helfen, nur muss sich jemand auch helfen lassen wollen.
Bernd Eckenfels
> Wäre das ein Szenario eines sinvollen Einsatzes von identd ?
Richtig. Und wenn du einen crptografisch sicheren identd verwendest, dann
musst du Lutz nicht mal vertrauen, weil weder Lutz die Informationen bekommt
dass es dein Squid war noch Lutz dich ueber die Meldung des identds anluegen
kann. Du kekommst von ihm:
"FDGHFGHGFHDFHDHFHGFHFGH"
und ein Hilfsprogramm sagt dir:
"das war ein connect von squid am 14.3 lokaler port 3543 auf remote port 32"
Gruss
Bernd
Bernd Eckenfels
> Ich fände es schöner, wenn weder das eine noch das andere
> vorkäme. Wenn jemand einen Dienst anbietet, folgt daraus keine
> Berechtigung, gültige Logins von meinem Rechner zu sammeln.
Es ist eher umgekehrt. Wenn jemand einen dienst anbietet und du ihn nutzt
dann musst du dessen Bedingugnen akzeptieren oder den Dienst nicht nutzen.
Alles andere waere ein ziemliches Anspruchsdenken. Es gibt durchaus ein
Grund warum die Dienste diese Information abfragen, denn sie haben staendig
mit abuse zu kaempfen.
Gruss
Bernd
Juergen Ilse
Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>>Ich habe hier bewusst NICHT ueber ident geschrieben, ich habe nur "ganz
>>allgemein" die "grundsaetzliche" Nuetzlich- keit von Reject gegenueber
>>Deny bezweifelt und statt dessen vorgeschlagen das im einzelfall zu
>>beurteilen.
> Traust Du Dir zu, zu wissen, was aktuell im Internet sinnvoll ist?
Ich traue mir ein Urteil darueber zu, ob es fuer jemanden sinnvoll
ist am Telnet-Port meines Rechners herumzustochern (warum auch immer
er das versucht). Wenn ich kein Telnet bereitstellen moechte, niemand
darueber informiert habe, dass unter jener IP-Adresse ueberhaupt irgend-
etwas erreichbar ist, etc. traue ich mir zu diesen "well known service"
als "fuer andere nicht sinnvoll im Sinne meiner Interessen nutzbar"
einzustufen. Ich meinte solche (sicherlich extreme) Faelle.
Deswegen sprach ich nicht von ident (bei dem die Situation tatsaechlich
eine andere ist), deswegen sprach ich nicht von "High-Ports", ...
Tschuess,
Juergen Ilse (il...@asys-h.de)
--
Eingedeutschte Fehlermeldungen sind doch etwas | Juergen Ilse
schoenes: "Ausserhalb des Scheibenweltraums" | Internet POP Hannover
Bernd Eckenfels
> Ich traue mir ein Urteil darueber zu, ob es fuer jemanden sinnvoll
> ist am Telnet-Port meines Rechners herumzustochern (warum auch immer
> er das versucht).
Du kannst es nicht beurteilen da du nicht weiss warum er das tut.
die Connect versuche auf telnet und socks port von irc servern dienen zum
schutz des irc netzwerkes vor falsch konfigurierten proxies (meistens
wingate). Wenn du dieses nicht haben moechtest darfst du irc nicht nutzen.
Gruss
Bernd
Rainer Weikusat
> >Relikt aus den Zeiten, als wir alle noch eine große glückliche Familie
> >waren. Schätzungsweise war das das letzte Mal der Fall, als ich in die
> >fünfte Klasse gekommen bin (1984). Das war so ungefähr zu den Zeiten,
>
> Ident ist kein Relikt,
Es ist ein Netzdienst, der anderen Leuten irgendwelche Textstrings
schickt. Den darfst Du meinethalben so nennen, wie Du möchtest, und
ich nenne den so, wie ich möchte.
> es ist auf einem BS mit hoher Marktdurchdringung
> einfach nicht im Lieferumfang enthalten.
Da muß ich Dich trotz Deines beeindruckenden argumentative Schwunges
leider enttäuschen: Als ich das letzte mal sowas wie ein Programm
gekauft habe, gab es das noch nicht.
> >Insofern stellt tcp/113 für mich
> >lediglich einen weiteren Netzdienst dar, der es jemandem potentiell
> >ermöglicht, auf einem Rechner unter meiner Fuchtel irgendwelchen Unfug
> >anzustellen => abdrehen.
>
> Hmm, Du hast den Sinn von Ident nicht verstanden,
Sinn von identd ist es, daß jemand über den genannten Port einen
Textstring abfragen kann, den ich ihm gerne schicken möchte.
> es ist praktisch -
"$_ is not used by sendmail"
--
SIGSTOP
Rainer Weikusat
> Rainer Weikusat <weik...@mail.uni-mainz.de> wrote:
> > Ich fände es schöner, wenn weder das eine noch das andere
> > vorkäme. Wenn jemand einen Dienst anbietet, folgt daraus keine
> > Berechtigung, gültige Logins von meinem Rechner zu sammeln.
>
> Es ist eher umgekehrt. Wenn jemand einen dienst anbietet und du ihn nutzt
> dann musst du dessen Bedingugnen akzeptieren oder den Dienst nicht nutzen.
> Alles andere waere ein ziemliches Anspruchsdenken.
Wenn ich einen ISP dafür bezahlen, über seinen Mailserver relayen zu
dürfen, bekommt der von mir Geld für die Nutzung seines
Rechners. Möchte er meinen ebenfalls benutzen, darf er mir das gerne
auch bezahlen (Antwort: Du hast den identd nicht verstanden. Wird
hiermit prohpylaktisch zur Kenntnis genommen.)
> Es gibt durchaus ein Grund warum die Dienste diese Information
> abfragen, denn sie haben staendig mit abuse zu kaempfen.
Das ist ihr Problem und nicht meines.
--
SIGSTOP
Bernd Eckenfels
> Sinn von identd ist es, daß jemand über den genannten Port einen
> Textstring abfragen kann, den ich ihm gerne schicken möchte.
Falsch. Sinn ist es, dass du Leuten einen Text String sendest den sie dir,
wenn sie mit deinem Rechner Problem haben wieder zuruecksenden koennen.
spart DIR eine Menge Arbeit.
Gruss
Bernd