Re: kleine verstaendisfrage zu iptables
Am Thu, 15 Apr 2004 23:50:14 +0200 schrieb Weinzierl Stefan: Zoli wrote: [...] Aber wenn ich -A OUTPUT -p tcp -m tcp --dport 22 --sport 1024: -m state --state ^^ falsch abgeschrieben? Oder falsche Regel... RELATED,ESTABLISHED -j ACCEPT ist IMHO besser in d.c.s.f aufgehoben ;-) -- gernot -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: kleine verstaendisfrage zu iptables
On 24.Apr 2004 - 22:03:43, Harald Weidner wrote: Hallo, Andreas Pakulat [EMAIL PROTECTED]: Im Übrigen gibt es durchaus SSH-Clients, die einen Sourceport 1024 verwenden, z.B. weil sie setuid root laufen. Mal aus Interesse: Aus welchem Grund laeuft ein ssh client setuid root? Um die .rhosts Semantik von rlogin/rsh/rcp nachbilden zu können. Diese besagt, dass sich User unter gleichem Benutzernamen auf der Zielmaschine ohne Passwort einloggen können, wenn die Zielmaschine der Quellmaschine entsprechend vertraut. Das klingt nach ssh public-key authentication und erfordert keinen Port 1024 auf der Quellmaschine. Das setzt authentische Informationen über den Benutzernamen auf der Quellmaschine voraus. Verbindungen von Quellports = 1024 sind dazu nicht geeignet, da prinzipiell jeder Benutzer einem modifizierten rlogin Client mit gefaktem Benutzernamen selber compilieren könnte. Das verstehe ich nicht so ganz, was hat ein Benutzername mit Ports zu tun, mal abgesehen davon dass man als Normalouser nur Ports 1024 kriegt? Oder willst du etwa als root ssh ausfuehren?? Wozu, gibt doch so huebsche Sachen wie su oder sudo? Andreas -- Spirtle, n.: The fine stream from a grapefruit that always lands right in your eye. -- Sniglets, Rich Hall Friends -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: kleine verstaendisfrage zu iptables
Hallo, Andreas Pakulat [EMAIL PROTECTED]: Um die .rhosts Semantik von rlogin/rsh/rcp nachbilden zu können. Diese besagt, dass sich User unter gleichem Benutzernamen auf der Zielmaschine ohne Passwort einloggen können, wenn die Zielmaschine der Quellmaschine entsprechend vertraut. Das klingt nach ssh public-key authentication und erfordert keinen Port 1024 auf der Quellmaschine. Lass mich raten: Du bist unter 25 und hast noch nie auf einem System ohne SSH mit rlogin, rsh und rcp gearbeitet? Das setzt authentische Informationen über den Benutzernamen auf der Quellmaschine voraus. Verbindungen von Quellports = 1024 sind dazu nicht geeignet, da prinzipiell jeder Benutzer einem modifizierten rlogin Client mit gefaktem Benutzernamen selber compilieren könnte. Das verstehe ich nicht so ganz, was hat ein Benutzername mit Ports zu tun, mal abgesehen davon dass man als Normalouser nur Ports 1024 kriegt? Es war einmal, in grauer Vorzeit, ein Betriebssystem namens UNIX, welches sich in Universitäten großer Beliebtheut erfreute. Computer waren teuer; kein Student, Assistent und auch kein Professor konnte sich einen eigenen leisten. Also loggten sich die Benutzer auf dem UNIX-Cluster ihrer Universität ein, verfassten ihre Diplomarbeiten, Doktorarbeiten und Vorlesungsmanuskripte mit ed, vi, troff und TeX, programmierten in C und sh, schrieben E-Mails mit mail und msg und unterhielten sich über talk. Um sich auf einem anderen Rechner im Cluster einzuloggen, gab es Telnet. Nach Eingabe des Benutzernamens und des Passwortes konnte man auf dem anderen Rechner weiter arbeiten. Dass das Passwort und die Nutzdaten im Klartext übertragen wurden, störte keinen, denn das Netzwerk wurde ohnehin von den gleichen, wenigen Personen verwaltet wie der Rechnercluster selbst. Die Eingabe von Benutzernamen und Passwort war aber lästig, denn die Accounts und Passwörter und Homeverzeichnisse waren sowieso überall im Cluster die selben. Wer einmal auf einem Rechner eingeloggt war, der hatte seine Identität bereits nachgewiesen. Dies brachte findige Köpfe an der Universität zu Kalifornien in Berkeley auf die Idee, ein Protokoll namens rlogin zu entwerfen, was dieses Problem löst. Der Client überträgt beim Login den Benutzernamen des lokalen Benutzers. Wenn die Gegenstelle der Meinung ist, dass der Rechner des Clients zum Cluster gehört (identifiziert über die IP-Nummer) und damit vertrauenswürdig ist, dann wird der Login auf dem Zielrechner erlaubt, ohne dass eine erneute Authentifikation notwendig ist. Problematisch daran war aber, dass es Studenten gab, die, anstatt ihre Seminararbeiten zu schreiben und auf die Prüfungen zu lernen, lieber Programme schrieben, mit denen sich die Authentifikation von rlogin austricksen lies. Genauer gesagt programmierten sie einen Client, der das genaue Protokoll von rlogin sprach und damit von der Gegenseite nicht vom echten rlogin zu unterscheiden war. Er übertrug aber anstelle des eigenen Login-Namens den des Professors. Die Gegenseite war der Meinung, dass der Professor auf dem Quellhost bereits eingeloggt war, und erlaubte ein Login ohne Authentifikation auf dem Zielhost. Hier fanden die Studenten dann die Prüfungsfragen oder modifizierten die Gutachten für ihre Diplomarbeiten. Sie bestanden das Examen mit Auszeichnung und sind heute Politiker, Richter, Anwälte oder Aufsichtsräte. Da eine Volkswirtschaft sich nur eine begrenzte Anzahl Nieten in führenden Positionen leisten kann, ohne aufzufallen, musste eine Lösung her. So ersannen die findigen Köpfe an der Universität Berkeley, dass der rlogin-Daemon auf dem Zielhost auch die Quell-Portnummer des rlogin Clients als Authentifikationsmerkmal verwenden kann. Verbindungen mit Portnummern = 1024 können von potenziell gefälschten rlogin Clients stammen, die einen falschen Benutzernamen angeben. Das unverfälschte Original-rlogin, welches vertrauenswürdig ist und immer den richtigen Benutzernamen übergibt, wird setuid-root gesetzt und öffnet damit seine Verbindungen immer von einer privilegierten Quellportnummer. Kein Student kann einen gefälschten rlogin-Client selber schreiben, der auch setuid-root läuft. Die Universitäten wurden wieder sicher und das Vertrauen in die Dekokratie kehrte zurück. Heute, viele Jahre nach dieser Idylle, reichen die Konzepte von rlogin, Telnet und Verwandten schon lange nicht mehr aus. Computer sind erschwinglich geworden; jeder Erstsemester bringt sein eigenes Notebook mit, auf dem er beliebige TCP-Verbindungen mit beliebigem Quellport erzeugen kann. Falls er selber nicht weiss, wie das geht, ergoogelt er sich ein Skript, zieht es von einem IRC Bot oder shared es in einer Tauschbörse. Merkmale wie Quellports oder auch IP-Nummern sind nicht mehr zu Zwecken der Authentifikation geeignet. Statt dessen gibt es Verschlüsselung, Public Key Authentifikation, Fingerprints und Zertifizierungshierarchien, die jede theoretische Angriffsmöglichkeit im Keim ersticken und allenfalls noch wegen ihrer ständigen
Re: kleine verstaendisfrage zu iptables
Am Sonntag, 25. April 2004 11:47 schrieb Harald Weidner: ihre Diplomarbeiten. Sie bestanden das Examen mit Auszeichnung und sind heute Politiker, Richter, Anwälte oder Aufsichtsräte. Wenn Politiker so programmieren wie sie reden, dann will ich diesen Quellcode nicht warten müssen. Wie soll ich mir das vorstellen? Politiker reden viel ohne was zu sagen, und wenn sie was sagen, dann so das niemand etwas versteht. Wenn sie jetzt Programmieren, dauert der Compilerlauf wahrscheinlich drei Stunden, erzeugt ein 2 GB Binary welches dann Hello World ausgibt. -- MfG usw. Werner Mahr registered Linuxuser: 295882 pgp0.pgp Description: signature
Re: kleine verstaendisfrage zu iptables
On 25.Apr 2004 - 09:47:28, Harald Weidner wrote: Hallo, Andreas Pakulat [EMAIL PROTECTED]: Um die .rhosts Semantik von rlogin/rsh/rcp nachbilden zu können. Diese besagt, dass sich User unter gleichem Benutzernamen auf der Zielmaschine ohne Passwort einloggen können, wenn die Zielmaschine der Quellmaschine entsprechend vertraut. Das klingt nach ssh public-key authentication und erfordert keinen Port 1024 auf der Quellmaschine. Lass mich raten: Du bist unter 25 und hast noch nie auf einem System ohne SSH mit rlogin, rsh und rcp gearbeitet? Richtig, deswegen fragte ich ja auch... [Maerchen ueber vergangene Zeiten] Danke, sehr informativ. Andreas -- If a man had a child who'd gone anti-social, killed perhaps, he'd still tend to protect that child. -- McCoy, The Ultimate Computer, stardate 4731.3 -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: kleine verstaendisfrage zu iptables
Andreas Pakulat schrieb: Generell ist die Angabe eines Sourceports in einer TCP-Regel fast immer sinnfrei. Wieso dass? Wenn ich z.B. verhindern moechte das bestimmte Dienste nach aussen angeboten werden ist der sport ja doch die einzig sinnvolle Moeglichkeit bei tcp oder? Nein, das wäre der --dport in der INPUT chain. Wenn Du --sport in der OUTPUT chain nutzt, kommen Pakete zu diesem bestimmten Port unbeschadet rein, aber auch wieder raus weil die Verbindung durch das reinlassen bereits ESTABLISHED ist (sein müsste(?)). -- Mit freundlichen Gruessen Bjoern Schmidt -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: kleine verstaendisfrage zu iptables
Hallo, Andreas Pakulat [EMAIL PROTECTED]: Im Übrigen gibt es durchaus SSH-Clients, die einen Sourceport 1024 verwenden, z.B. weil sie setuid root laufen. Mal aus Interesse: Aus welchem Grund laeuft ein ssh client setuid root? Um die .rhosts Semantik von rlogin/rsh/rcp nachbilden zu können. Diese besagt, dass sich User unter gleichem Benutzernamen auf der Zielmaschine ohne Passwort einloggen können, wenn die Zielmaschine der Quellmaschine entsprechend vertraut. Das setzt authentische Informationen über den Benutzernamen auf der Quellmaschine voraus. Verbindungen von Quellports = 1024 sind dazu nicht geeignet, da prinzipiell jeder Benutzer einem modifizierten rlogin Client mit gefaktem Benutzernamen selber compilieren könnte. Und selbst dann denke ich wird der client eher nicht auf nem Port 1024 die Verbindung aufmachen, solange man ihn nicht dazu zwingt (geht das ueberhaupt??) Programme, die unter root laufen, bekommen vom Betriebssystem per Default einen Source Port 1024, sofern sie nicht einen anderen explizit anfordern. Generell ist die Angabe eines Sourceports in einer TCP-Regel fast immer sinnfrei. Wieso dass? Wenn ich z.B. verhindern moechte das bestimmte Dienste nach aussen angeboten werden ist der sport ja doch die einzig sinnvolle Moeglichkeit bei tcp oder? Dienste idenzifizieren sich bei TCP immer über den Zielport eines initialen (SYN) Paketes. Der Quellport hat den Zweck, verschiedene Verbindungen vom selben Rechner auf den selben Dienst unterscheidbar zu machen. Wenn Du einen Dienst sperren willst, sperre in der INPUT Queue SYN Pakete bzw. --state NEW auf den entsprechenden Port. Die einzige zusätzliche Semantik des Quellports bei TCP besteht in der Unterscheidung zwischen den privilegierten und nicht privilegierten Ports (1-1023 bzw. 1024-65535). Diese wird aber mehr und mehr verwässert, da kaum noch Dienste im Einsatz sind, die diese Unterscheidung zu Authentifikationszwecken benutzen. Bei UDP sieht das alles ein bisschen anders aus. Hier wird der Quellport manchmal zur Unterscheidung des Nutzungsszenarios verwendet, z.B. bei DNS: Port 53 - Port 53: Server-zu-Server Kommunikation Port =1024 - Port 53: Client-zu-Server Kommunikation Oder bei bootp (DHCP), wo Clients immer den Port 68 (bootpc) und Server den Port 67 (bootps) verwenden sollen. Auch hier sollten aber keine sicherheitskritischen Entscheidungen aufgrund des Quellports getroffen werden, da er von jedem root gefälscht werden kann. Gruß, Harald -- Harald Weidner [EMAIL PROTECTED] -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: kleine verstaendisfrage zu iptables
Hallo, Zoli [EMAIL PROTECTED]: -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT [...] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT [...] -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT Diese kombination funktioniert Aber wenn ich -A OUTPUT -p tcp -m tcp --dport 22 --sport 1024: -m state --state RELATED,ESTABLISHED -j ACCEPT mach und die letzte Zeile auskomentiere geht es nicht mehr. Die erste Variante erlaubt alle ausgehenden Pakete zu existierenden TCP-Verbindungen. Das schliesst auch Antwortpakete zu den in der ersten Zeile erlaubten einkommenden SSH-Verbindungen ein. Die zweite Variante schließt diese explizit aus. Im Übrigen gibt es durchaus SSH-Clients, die einen Sourceport 1024 verwenden, z.B. weil sie setuid root laufen. Generell ist die Angabe eines Sourceports in einer TCP-Regel fast immer sinnfrei. Gruß, Harald -- Harald Weidner [EMAIL PROTECTED] -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: kleine verstaendisfrage zu iptables
On 23.Apr 2004 - 23:46:28, Harald Weidner wrote: Hallo, Im Übrigen gibt es durchaus SSH-Clients, die einen Sourceport 1024 verwenden, z.B. weil sie setuid root laufen. Mal aus Interesse: Aus welchem Grund laeuft ein ssh client setuid root? Und selbst dann denke ich wird der client eher nicht auf nem Port 1024 die Verbindung aufmachen, solange man ihn nicht dazu zwingt (geht das ueberhaupt??) Generell ist die Angabe eines Sourceports in einer TCP-Regel fast immer sinnfrei. Wieso dass? Wenn ich z.B. verhindern moechte das bestimmte Dienste nach aussen angeboten werden ist der sport ja doch die einzig sinnvolle Moeglichkeit bei tcp oder? Andreas -- I'm not prejudiced, I hate everyone equally. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
kleine verstaendisfrage zu iptables
Hallo! Ich habe für ssh folgende Regel erstellt. Mir geht es eigentlich um den OUTPUT Regel für ssh. -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -i ppp0 -m state --state INVALID,NEW -j DROP -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A OUTPUT -p tcp -m tcp --sport 1024:65535 -j ACCEPT -A OUTPUT -p tcp -m tcp --dport 22 --sport 1024: -j ACCEPT -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT Diese kombination funktioniert Aber wenn ich -A OUTPUT -p tcp -m tcp --dport 22 --sport 1024: -m state --state RELATED,ESTABLISHED -j ACCEPT mach und die letzte Zeile auskomentiere geht es nicht mehr. Wieso? es ist doch das selbe wie -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT nur das es sich ausschließlich auf Port 22 bezieht, oder hab ich da was nicht verstanden. Für eine kurze Erklärung bin ich euch sehr dankbar. Grüsse Zoli -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
